iOS网络经典知识点收录整理（OSI分层协议作用介绍和传输全过程）

重要知识点目录

从URL输入到网页显示的全过程解析

TCP底层三次握手解析

OSI分层知识点记录介绍

1.链路层

2.网络层  ARP IPv4 IPv6 ICMP（异常协议）

3.传输层

4.应用层

TCP/IP分层模型通信示例（不细分）

MAC和IP怎么理解？

---

前言

文章前部分是自己拖着玩的，可以直接按上面的跳转直接看就好了

直接开干，由于Mac电脑，搞了半天无法下载Packet Tracer的Mac版本，没办法，装个虚拟机

虚拟机下载使用，这里复习用，因此试用15天足够了，然后在虚拟机上安装Packet Tracker软件理解下通信原理

思科官网注册下下载个跟虚拟机系统匹配的Windows版本即可，安装完了，就可以开始了

通过学习，可以深入理解TCP和UDP的本质区别，明白为什么TCP稳定，而UDP不稳定，以及一些简单的名词和当你访问网站的时候到底发生了什么

简单组网

打开刚才的软件，左下角鼠标放上去可以选择设备和终端，都有英文名的，下面看下最简单的两台电脑组网

 

集线器和交换机组网

和上面的操作一样，只是左下角选择Network Device来进行机器选择，上面的集线器，链接之后端口都是绿色的，而交换机链接之后的端口颜色是橘黄色的，这也是他们两者的区别。先不管这个，如果左侧192.168.1.x网段的三台电脑自己ping都能ping通，左侧也一样，但是如果要左右侧通信，这样肯定不行，先看下简单的局域网链接介绍

 

1.两台电脑之间通信的前提是什么？ 同一网段内

2.多台电脑之间为什么不能把网线剪开连接在一起？ 数据是通过电型号传递的，例如数字3 0000 0011，和数字4 0000 0100
前几个信号相同，都是0，无差异，如果剪开网线在第五个信号的时候接收到数据不同，因此会导致数据紊乱
3.链接多台电脑的hub（集线器）有什么作用？链接多台电脑，组个局域网
4.集线器和交换机有什么区别？  都能组局域网，集线器收到的包都会以广播的形式发送 
交换机能够完成多个电脑的链接
集线器的每个数据包的发送都是以广播的形式进行的，容易堵塞网络
交换机一开始不知道Mac地址也是广播，然后进行缓存学习，通信过之后就定向发送，不会有堵塞
如果PC不知目标IP所对应的的MAC，那么可以看出，pc会先发送arp广播，得到对方的MAC然后，在进行数据的传送
当switch第一次收到arp广播数据，会把arp广播数据包转发给所有端口（除来源端口）；如果以后还有pc询问此IP的MAC，那么只是向目标的端口进行转发数据

 

根据最后一点的介绍，我们看下ping这个命令是如何进行的

 

PING命令的流程

1.组好网之后执行ping，这里是PC3 ping PC5

先介绍下方便理解

icmp  ---<> ping电脑的协议
arp  ---<> 根据IP获取硬件Mac地址（网卡号）的协议
rarp ---<> 根据Mac地址找IP
inbound PDU Details 收到的包（信封）
Outbound DPU Details 发送的包
 

能看到右侧有两个协议包，ARP和ICMP

点击右侧的Capture和Forward之后，ARP的包会发送给交换机，由于协议的底层都是通过Mac地址进行通信定位的，那为什么交换机能接收到包？原因是和局域网内的广播一样，如果发送给广播IP，那么局域网内的所有电脑都能接收到信息，如下解释

OSI 四层模型
应用层
传输层
网络层（同一网段例如 192.168.1.255 和 本机IP都能接收到信号）  ip arp icmp

链路层 (链路层也一样，FFFF FFFF FFFF 全为F的Mac地址和本机网卡的Mac地址都能接收到)

点开交换机上的信封可以看到以上信息，我们需要知道的就是TARGET MAC地址，ARP协议就是干的这个事情，然后继续点击下一步，交换机会进行广播，问一下局域网内的所有电脑，你们谁的IP地址是192.168.2.3，如果是就把你自己的Mac地址传给我，不是就把我的广播忽略

对应的IP地址电脑收到包之后，就会把刚才的包内容里面的Mac地址给填上，然后原路返回，这个时候ping的那台电脑通过ARP协议通过IP地址知道的对方的Mac地址，因此就可以用ICMP协议进行通信了

ping的时候icmp由于只有对方的ip地址，没有对方的Mac地址，是ping不通的，因此需要通过
arp协议，来获取到对方的Mac地址，根据上面介绍的链路层广播是全为F，发送arp协议过去，由于没有缓存，交换机
接收到arp协议的时候(里面带了源ip和源mac，以及目标ip和目标Mac地址，暂时未0)，然后进行广播，其他机器接收到
包的时候，根据包内容里面的ip地址，进行判断是不是自己，不是的话就丢弃，是的话把源ip和mac以及，刚才对称的信息
返回回去，ping的人接收到包的时候知道Mac地址，icmp就可以进行ping了，下一次传输交换机接收到的数据就不会广播，就会定向发送给ping的mac机器

 

路由器组网（交换机，路由器，PC）

默认情况下，逻辑不同的两个网关是无法通信的，如果需要，就要借助路由器

 

路由器（Router）又称网关设备（Gateway）是用于连接多个逻辑上分开的网络

所谓逻辑网络是代表一个单独的网络或者一个子网。当数据从一个子网传输到另一个子网时，可通过路由器的路由功能来完成

 

例如上面的配置，左侧网络和右侧网络是无法直接通信，需要借助路由器，根据上面的配置，需要配置两个IP左右侧分别连接不同网段。一般路由器至少有两个网卡

 

路由器配置默认是关闭的，需要开启

这时候如果你只是配置了路由器两个网卡IP和简单的开启，你执行192.168.2.1 ping 192.168.1.1，会看到如下的叉叉

还有个点就是设置了路由器，需要在对应的PC上设置路由器连接的默认网关

到达路由器的默认网关后就需要在路由器进行正向或者反向的配置，一般链接网段的一端只要配置一个方向即可。

这里设置路由器里面的配置，其中Network是ping里面的网段地址，Mask是掩码，例如

192.168.2.1 ping 192.168.1.3  Network填写的就是192.168.1.0 Mask就是255.255.255.0

Next Hop就是路由器下一个链接的网段，这里就是192.168.4.254

以下就能通信了,可以看到第一个包还是ARP，根据对应PC的配置，为了获取到默认网关的Mac地址

到达路由器网关之后把带上mac地址，把包返回回来

具体过程如下

 

 

• 不在同一网段的pc，需要设置默认网关才能把数据传送过去 通常情况下，都会把路由器设置默认网关
• 当路由器收到一个其它网段的数据包时，会根据“路由表”来决定，把此数据包发送到哪个端口；路由表的设定有静态和动态方法
• 路由器设置网卡IP的时候需要手动开启，默认是关闭的

在网络通信过程中，包的传递信息中，不同网卡之间的Mac地址一致在变化，但是所需要传递的IP地址一直没有变化

IP：地址标记逻辑上的地址 （现阶段的住址）

Mac：标记物理上的地址（身份证号码）

Mask：和IP地址与能获取到网络号

默认网关：发送的ip不在统一网段内，那么会把这个数据转发给默认网关  

 

交换机，路由器，服务器组网

如上图所示，只是在上面的基础上加了两台服务器，一个用作http服务，一个做DNS服务器

Http服务配置如下

来看下直接通过IP地址访问的流程

这种访问方式是直接通过IP来进行的，那么一般我们输入域名的情况下是如何访问的？就需要用到DNS服务器，你把他理解为一个电话簿，成千上万的电话号码都对应好了，PC访问之前都需要从DNS服务器进行访问请求对应的IP，在进行访问

DNS配置如下

再来看下通过域名访问的流程

从URL输入到网页显示的全过程解析

1.首先了解下各种名词的意思

Mac地址：以太网卡物理上标记一台电脑

IP地址：逻辑上标记一台电脑

子网掩码：通过和IP地址与计算得出当前网段

默认网关：当一个网段需要访问另一个网段的时候，默认把数据先发送到路由器网关进行后续传递（官方介绍百度一堆）

DHCP服务器：插上网线的时候，寻找没有分配IP地址的电脑自动分配一个IP

DNS服务器：域名查找对应的IP（电话簿）

2.首先记录下各种设备相关的配置

PC：自带Mac地址，我们需要配置IP地址，还需要配置gateway网关地址，也就是两网卡一侧IP地址，发送的数据包的目的ip不是当前网络时，此数据包包转发的目的ip，还有个就是设置DNS服务器地址，当域名访问的时候，默认会先去DNS服务器解析

交换机：链接多台电脑，没啥好配置的，比集线器高级一点，另一端链接路由器网关

路由器：路由表设置，指定数据包下一跳的地址，static里面设置，路由器需要几个IP就给几个IP用

 

3.基本协议相关

arp：根据IP获取硬件Mac地址（网卡号）的协议

rarp：根据Mac地址找IP

icmp：ping电脑的协议

tcp：传输控制协议（有连接可靠）

udp：用户数据包协议（无连接，速度快，不可靠）

http：应用层协议传输数据

OSI四层模型
应用层
传输层
网络层（同一网段例如 192.168.1.255 和 本机IP都能接收到信号）  ip arp icmp
链路层 (链路层也一样，FFFF FFFF FFFF 全为F的Mac地址和本机网卡的Mac地址都能接收到)

 

OK。了解了上面的基本知识点，这些解释是我自己方便理解，官方介绍可以百度细细看，没必要说那么官方

1.访问www.bilibili.com（本机IP是私有192开头的C类的话会通过NAT协议再路由器进行公网本机IP转换）

2.PC上有配置了DNS（UDP方式）服务器，输入域名，一般都会去查找出对应的IP地址

3.而且配置了网关，这种不是本地网段访问，需要通过路由网关传输，因此第一次的时候，我们不知道路由网关的Mac地址，就会在TCP协议之前用ARP协议，发送到交换机上，然后交换机广播到网关，网关（交换机或者路由器或者目标主机）接收到包之后传回自己的Mac地址返回

4.组织数据，发送DNS（UDP）协议，带上域名发到网关（这里的IP还是DNS服务器IP，只是Mac地址是网关的Mac地址）

5.路由器根据自己的路由协议，选择一个较快的路径转发到目的网关

6.DNS所在服务器网关，发送包到DNS服务器，然后DNS服务器把域名对应的IP包返回（这里一样需要ARP获取返回的网关Mac）

7.客户端得到了www.bilibili.com的IP地址，然后发送TCP协议进行三次握手（TCP有序列号，校验和，ACK以及延时ACK，超时重发，连接管理，窗口控制，流量控制以及拥塞慢启动来保证是稳定的，连续的），三次握手的时候会根据链路层的MTU来确定数据是否需要分片，或者传输过程中通过ICMP协议来反馈处理异常信息

8.链接成功之后会使用HTTP协议请求服务器的数据

9.服务器接收到请求会后查询服务器，把对应的结果返回到浏览器，这里按Python DJango搭建的服务器为例，如果不是Nginx配置的静态资源，会进入DJango编写的URL路径匹配里面，然后根据业务返回对应的模板HTML或者是JSON数据

10.浏览器接收到数据，渲染显示网页

11.浏览器关闭。TCP四次挥手，结束，这里为什么不是三次挥手？由于TCP采用窗口模式来保证传输速度，这样就会有各自的缓冲区，例如客户端发送FIN包，服务端接收到放入缓冲区，这个时候不可能直接携带FIN包回去，肯定是要等待缓冲区数据处理完之后才进行FIN，这就是为什么需要四次，而不是三次。

 

TCP底层三次握手解析

上一篇用Python写了TCP和UDP的Demo，这就不介绍了 传送门

我们用网络拓扑图看下底层的三次握手是怎么形成的？上面的gif演示已经展示了所有的流程，里面也有TCP的握手过程，下面只是针对握手过程做个分析

1.下图是客户端发送给服务器的第一次握手，SYN进行同步确认

 

2.下图是服务端收到SYN包之后，返回的ACK（值是SYN序列号+1），然后再发送一个服务端的SYN包

、

3.第三次是客户端确认服务端的SYN，发送ACK包确认，但是很巧妙的是，此时准备好的HTTP包也跟着最后的ACK包一起发出（后面会介绍，由于TCP每次包的传递都会反馈信息，因此直接跟上HTTP包，对方接受与否都无所谓，正好也节省时间）

4.HTTP请求顺利到达服务器

5.这里服务器接收到数据之后回回传HTTP请求的数据

老版本的演示是会分开两个包，每次传递数据成功，会发送一个TCP ACK包和HTTP包的应答，现在新版本只会看到一个HTTP数据包，本身信息都放在包的头部序列号部分即可，两个一个都一样，一个还省点内存

由于之前的版本看到额是每次服务端和客户端接收到的对方的请求或者应答时，都会提前HTTP包发送一个TCP确认包，告诉对方我已经收到了数据，但是这个版本的工具看来貌似没有，还是我操作有问题，反正我个人觉得TCP的稳定在于每次数据传输的确认，每个包的头部呆了序列号，例如我是服务器，我把HTTP请求的数据包发回去的时候，序列号例如是1，同时我又确认了ACK包是2，那么客户端收到HTTP包的时候，会提前分析序列号是否和之前发出去的包+1进行对比确认，就能知道对方是否已经收到信息

TCP的稳定性在于三次握手建立的链接，之后每次发送数据的过程中，都会在包的头部带上序列号和ACK号，方便发送方和接收方确认对方是否成功收到自己的请求或者数据，而UDP中只是sendto发送数据，没有任何数据来标识和确认是否对方已经接收到

例如访问域名的时候DNS底层就是UDP包的发送，打开包如下可以看到没有任何确认信息，只有端口和IP

TCP四次挥手

一般都是客户端调用Socket的close()，主动断开连接，这里图就不贴了，和TCP握手一样，主动调用方会发送FIN包，收到的一样会发送ACK确认，然后对方再发送FIN包关闭，相互发送FIN和ACK之后，这个连接资源就结束了

当一端收到一个FIN，内核让read返回0来通知应用层另一端已经终止了向本端的数据传送
发送FIN通常是应用层对socket进行关闭的结果

三次握手

1. 第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
2. 第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
3. 第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
   完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。

那四次分手呢？

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。

1. 第一次分手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
2. 第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
3. 第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
4. 第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。专业名词介绍在后半段文章

 

 

TCP长连接和短连接

这个其实很好理解，短连接就是每次数据的收发都会三次握手和四次挥手，而长连接就会建立一次连接，然后不断收发数据。很明显，前者耗时，每次都要握手和挥手，后者就是占服务器资源。但是各有使用场景。

 

• 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。

  每个TCP连接都需要三次握手，这需要时间，如果每个操作都是先连接，

  再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，

  再次处理时直接发送数据包就OK了，不用建立TCP连接。

  例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，

  而且频繁的socket 创建也是对资源的浪费。

• 而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，

  而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，

  如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，

  那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

很容易理解，比如你玩炉石传说，你登录客户端明显是长连接，然后你离开一段时间没玩，服务器就会强制断开你的长连接，避免不必要的资源占用，而普通的Web访问，就是短连接，拿到数据显示，下次需要再次连接即可

HTTP的版本也体现到了长短连接的改变，具体可以看下这个文章 点击打开链接

但是HTTP依然是无状态的，协议是不会记录上一次连接的信息的

 

1. HTTP/0.9

HTTP 1991 年发布的版本称为 HTTP/0.9，是一个很简单的协议，只有一个 GET 方法，不支持多媒体内容的 MIME 类型、各种 HTTP 首部，或者版本号。该协议定义的初衷是为了获取简单的 HTML 对象。

GET /index.html

服务端返回的响应内容格式

(response body) (connection closed)

它很快就被 HTTP/1.0 取代了。

2. HTTP/1.0（keep alive来保持长连接，多个请求多个TCP管道）

1996，HTTP1.0 大大改进了之前的协议版本，并得到广泛使用。

HTTP/0.9 只有 GET 方法，并且响应只能是 HTML，而 1.0 增加了更多的方法，比如 POST、HEAD；响应内容可以是图片视频文本或者其它类型。

1.0 的请求和响应都增加了版本号，头部信息，响应内容有状态码，引入字符集，授权认证，缓存，内容编码等。

GET / HTTP/1.0 Host:baidu.cn User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) Accept:*/*

HTTP/1.0 200 OK Content-Type:text/plain Content-Length:123582 Expires:Wed, 17 Jan 2018 14:37:52 GMT Server:tengine (response body) (connection closed)

HTTP 1.0 一个主要的缺点就是，一个连接只能有一个请求，即每次请求都会重新建立一个 TCP 连接，TCP 建立连接需要三次握手，加上慢启动的特性，这将是很耗资源和性能的一个步骤，于是有些 HTTP 1.0 的实现版本，在请求头中添加了一个 Connection:keep-alive的标记，但是并没有被广泛支持。

因为 HTTP 1.0 的无连接，使得它也是一种无状态的协议。服务端没法维护客户端的信息，致使每个请求都得额外的去携带一些必要的信息，在连接很多的情况下，造成很多带宽的压力。

3. HTTP/1.1（默认长连接  + 断点续传基础分片）

1999 年，HTTP 1.1 发布了，相比 1.0，同样改进很大，也是现在用的最为广泛的一个版本。

3.1 持久连接

Connection: Keep-Alive Keep-Alive: max=5, timeout=120

HTTP 1.1 建立连接后，默认不会被断开，它允许多个有序的请求，客户端如果想要关闭连接，可以在最后一个请求的请求头中，加上 Connection:close来安全关闭这个连接。或者连接闲置达到指定时间，也可以自动断开连接。

3.2 管道机制

https://www.kancloud.cn/digest/web-performance-http2/74823

HTTP 1.1 引入了管道机制，即在一个连接上，客户端请求时不需要等待服务器响应后，才去发送下一个请求，客户端可以连续发送几个请求，服务端按照接受请求的顺序，依次把响应返回回来。

这里有一个问题，即客户端如何区分哪里是第一个响应的内容，哪里是下一个响应的内容呢？HTTP 1.1 为此添加了 Content-Length首部，用它来标记响应内容的结束位置，以及下一个响应内容的开始位置。

Content-Length:1234

3.3 分块传输

使用 Content-Length 字段，前提是服务端必需要知道返回数据的长度，对于一些耗时的数据操作，服务端如果等所有操作都做完，才返回数据，效率非常不高，为此，采用了一种分块传输的处理方法，即产生一块数据，就发送一块。

具体的形式是，在响应头部返回 Transfer-Encoding 字段，表明数据是有未定的数据块组成。

Transfer-Encoding:chunked

每一个分块，都添加一个 Content-Length，当所有的数据块都传输完成时，范湖一个空的 chunked，Content-Length 设为 0，来表示传输完成。

4. HTTP/2.0

https://www.kancloud.cn/digest/web-performance-http2/74828

4.1多路复用

---

HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。

关于多路复用，可以参看学习NIO 。

---

4.2数据压缩

---

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

---

4.3服务器推送

---

意思是说，当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。

 

问：HTTP1.0 HTTP 1.1 HTTP 2.0主要区别

1.1和1.0的区别

长连接

HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。

HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的,有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用个长连接来发多个请求。

节约带宽

HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。

这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。

HOST域

现在可以web server例如tomat，设置虚拟站点是非常常见的，也即是说，web server上的多个虚拟站点可以共享同一个ip和端口。

HTTP1.0是没有host域的，HTTP1.1才支持这个参数。

1.1和2.0的区别

多路复用

HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。

关于多路复用，可以参看学习NIO 。

数据压缩

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

服务器推送

意思是说，当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。

 

 

 

问题一：HTTP报文结构

大汇总

https://blog.csdn.net/yankai0219/article/details/8212475

问题二：HTTP 报文头部含有什么，multipart了解吗

multipart/form-data web提交表单，客户端提交图片资源

multipart/byteranges 断点续传 

要实现该功能需要制定下载的实体范围，这种制定范围发送请求叫做范围请求。
针对范围请求，服务器会返回状态码为206的报文，多重范围请求 响应会在头部 Content-Type 表明 multipart-byteranges 返回报文主体。如果服务端不支持范围请求则返回状态码200 OK并将所有报文一并返回。
执行范围时会使用头部字段 Range 来指定资源 byte 的范围。
Range格式：
5001-10000字节
Range : byte = 5001-10000
5000之后的
Range : byte = 5001-
0-3000字节，5001-10000字节
Range : byte=-3000,5001-10000

问题三：GET POST区别和作用，Cookies和Seesion原理介绍

https://blog.csdn.net/Deft_MKJing/article/details/53762277

问题四： POST四种常见传输格式

https://imququ.com/post/four-ways-to-post-data-in-http.html

我们知道，HTTP 协议是以 ASCII 码传输，建立在 TCP/IP 协议之上的应用层规范。规范把 HTTP 请求分为三个部分：状态行、请求头、空行、消息主体。类似于下面这样：

服务端通常是根据请求头（headers）中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码，再对主体进行解析。所以说到 POST 提交数据方案，包含了 Content-Type 和消息主体编码方式两部分

1.application/x-www-form-urlencoded

默认表单类型，例如登录，传参就是这种

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

2.multipart/form-data

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束，主要用来上传文件

3.application/json

POST http://www.example.com HTTP/1.1 
Content-Type: application/json;charset=utf-8

{"title":"test","sub":[1,2,3]}

4.text/xml

它是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范。典型的 XML-RPC 请求是这样的：

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml



    examples.getStateName
    
        
            41
        
    

问题五：HTTPS相关

• https有几次握手和挥手？https的原理。http有几次挥手和握手？TLS在哪一网络层，基本原理是什么？

• https与中间人攻击

• HTTPS，安全层除了SSL还有，最新的？ 参数握手时首先客户端要发什么额外参数

• HTTPS是什么？握手过程，SSL原理，非对称加密了解多少

• 证书是干什么用的

自己另外总结的HTTPS全攻略

https://blog.csdn.net/Deft_MKJing/article/details/82868900
 

相关术语介绍

MTU 
Maximum Transfer Unit 最大传输单元 
链路层的帧（frame）中的数据部分的最大字节数 
以太网中的一般为1500字节

MSS 
Maximum Segment Size 最大报文段大小 
TCP的报文段中的数据部分的最大字节数，MTU减去IPv4的Header和TCP的Header 
IPv4的Header和TCP的Header一般都是20字节，则MSS=1500-20-20 = 1460字节

MSL 
Maximum Segment Lifetime 报文最大生存时间 
报文在网络上存在的最长时间，TCP四次挥手是主动断开连接的一方再发送完最后一个ACK后进入TIME_WAIT状态时，需要等待2MSL时间后才变成CLOSED状态 
RFC 793建议为2分钟

RTT 
Round-Trip Time 
从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延 
TCP中保留了RTT的加权平均值RTTS（下标S表示Smoothed） 
对于i=1，RTTS[i]=新RTT样本 
对于i>1，RTTS[i]=(1-a) * RTTS[i-1] + a * 新RTT样本，RFC2988建议a=1/8

TTL 
Time To Live 
该字段指定IP包被路由器丢弃之前允许通过的最大网段数量。TTL是IPv4包头的一个8 bit字段。

RTO 
Retransmission Timeout 超时重传时间 
TCP中触发超时重传机制的时间，应略大于RTT 
RFC2988中建议RTO = RTTS + 4 * RTTD 
RTTD时RTT的偏差的加权平均值 
对于i=1，RTTD[i] = 新RTT样本/2 
对于i>1，RTTD[i] = (1 - b) * RTTD[i-1] + b * | 新RTT样本 - RTTD[i] |，建议b=1/4
--------------------- 

OSI分层知识点记录介绍

很多时候我们会被问到什么是Socket？一般来讲Socket连接需要提供ip和端口，那么传输层提供的是端口，而网络层则提供的ip地址，因此，Socket就是操作系统封装的API,我们只要调用抽象出来的Socket API，不需要管底层是如何实现的，就可以进行数据的传输。

1.链路层

以太网 ，无线LAN，PPP 数据链路不同 MTU（每种链路最大传输单元）大小不同，TCP在发送包的时候都会进行MTU路径发现，来确保发送的数据是否需要分片

Maximum Transfer Unit 最大传输单元 
链路层的帧（frame）中的数据部分的最大字节数 
以太网中的一般为1500字节

示例图1 ICMP会异常返回是否需要分片

2.网络层  ARP IPv4 IPv6 ICMP（异常协议）

IPv4目前地址有点紧缺，因此现在统一网段内都给分配私有IP，C类一般以192开头，如果私有IP访问外网的时候，会用到NAT私有转公网IP的技术机型转换

DNS UDP传输方式返回IP

ARP 获取IP对应的MAC

ICMP 辅助IP，确认包是否成功送达，包为何没被处理等异常信息反馈搜集，例如上面一开始按最大MTU-FDDI发送，对端接收的包过大直接丢弃，ICMP告诉发送端接收端最大MTU，然后根据ICMP报告的重发即可

DHCP 自动分配IP

NAT IPv4枯竭开发的技术，私有IP转换公网IP

3.传输层

TCP：面向连接，可靠的流协议。保证发送顺序。丢包重发。

通过校验和，序列号，确认应答，重发控制，链接管理以及窗口控制来实现可靠性传输

1.通过序列号和确认应答提高可靠性 ACK，收到数据之后返回给发送端告知已送达。如果在接收端收到数据后，再返回过程中正好在特定时间之外，发送端又重复发送，因此序列号可以保证同一个数据不会重复接收

2.重发超时6秒左右

3.连接管理（三次握手，四次挥手）

为什么三次握手？但是要四次挥手？

三次握手很好理解，例如两个人通话，我发送一句话，我准备好发数据了，你准备接受了么，你接收到之后回复我准备好接受了，然后同步发送我也准备发送数据了，你准备好接受数据了么，我收到后回复，我准备好接受数据了

而四次挥手为什么不同步发送FIN包，因为，TCP滑动窗口控制情况下，数据是会在BUFFER区域等待处理的，只有等该窗口数据都确认之后，才会从缓存中移除，如果客户端主动FIN，服务端接收到之后，由于接收到数据缓冲区内还有数据等待处理（可能很耗时），因此需要等待数据buffer处理好之后，再发送FIN断开服务端。

这里在TCP三次握手协商时，最理想的状态是根据链路层的MTU（最大传输单元），这里叫MSS，最大消息长度一个意思，如果数据小于等于MTU或者MSS，就是理想状态，但是一般都会根据实际合理的MTU进行数据分片处理。

 

4.窗口控制

如果每次数据收到都要按每一段来确认，就会导致网性能下降。因此我们用更大的单位进行确认。一段----窗口

也就是发送段不需要发送一段之后等待确认，而是继续发送，窗口大小就是无法等待确认应发的数据发送最大值

这个机制会用到大量缓冲区，通过对多个段进行同时确认的功能。例如发送端发送一组数据，一组有五个段，这个五个段都会缓存起来，因为如果发送失败，就可以重传。如果全部应答数据确认完毕才会清缓存。一段数据传输之后，窗口就会滑动到下一个控制数据组，继续循环操作。

如果窗口控制出现某一段丢失怎么办？

1.一种是数据是收到了，但是应答未能返回。不需要重发的，因为五组应答只要有应答返回，就能保证这一组里面数据是全部收到了的，发送端收到序列号确认就不会重发

2.某一段数据丢失

例如图中的数据某一段丢失，接收端会在窗口内部，一直返回丢失数据段的序列号，如果有三次同一个序列号的应答，接收端就会重发数据，这种机制比超时重发更高效，因此被称作高速重发控制。

 

5.流控制

http://mrpeak.cn/blog/tcp-flow-control00/

当接收端收到数据时，可能处理了很久，高负荷运转，如此一来，接收端如果又在不断接受数据，那么数据全部丢弃，造成网络大量浪费，因此TCP有个发送端根据接收端的当时实际接受数据能力来控制数据量。这就是所谓的流量控制。

在包头部分,专门有字段控制，接收端会事实告诉发送端实际接受数据的窗口大小。上面提到的窗口大小就是根据接收端来控制的，接收端把自身的buffer处大小返回给发送端，这个值越大，网络吞吐量越大。可以根据接收端随意控制。

根据图可以看到，接收端从3001开始后缓冲区满了，因此不能接受数据了，然后返回给发送端的确认包中窗口大小是0，发送端不会发送数据，等待，但是等待到什么时候？这里就出现了窗口探测，发送端时不时发送一个探测数据包，仅此而已，来获取可以用窗口大小。

6.拥塞控制：

http://mrpeak.cn/blog/network-speed/

虽然有了 TCP窗口控制，但是如果一开始就发送大量数据包，有可能在一开始就会引发网络问题。

因此有了慢启动，在发送端调节所要发送数据的量，定义了一个叫做拥塞窗口的概念，关于慢启动的时候，这个窗口大小为1，随后的一次确认之后，窗口大小就会根据一定的比例增长，然后根据接收端通知的窗口大小进行比较，用小的值进行数据传递。如果遇到超时重发，窗口大小会降为1，然后再进行慢启动修正。这个机制就能减少连续发包导致网络拥堵。还可以避免网络拥塞。

根据图来看TCP一开始没有慢启动阀值，而是在超时重发的时候有了阀值（拥塞窗口大小的一半）。由于窗口里的重复确认应答触发的高速重发机制与超时重发不同。窗口的吞吐量是不断变化的。

 

7.提高网络利用率（延迟发送确认应答）

如果接收端接收到数据立刻应答，有可能返回一个很小的窗口，因为缓冲区可能快满了或者已满。这样降低网络利用率。因此需要延迟一段时间发送，没有收到两倍最大长度的数据为止不做应答，其他一般延迟0.5秒即

具体示例：

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;

第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;

第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。

 

问题1：为什么第四次挥手需要两倍MSL

2MSL即两倍的MSL，TCP的TIME_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次握 手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，

第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
第二，A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

问题2：为什么需要三次握手？

首先假设两次握手，那么任何一段发送数据，代表新的连接就建立了，那么就会一直等待对方的应答，因此就会有后面出现的资源浪费现象了

谢希仁网络如下解释：

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

问题3：为什么需要进行四次分手

那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

• FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
• FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
• CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
• LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
• TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
• CLOSED: 表示连接中断。

注意：

这里所写的SYN FIN ACK只是TCP报文头部的标志位（可以理解为开关），具体的序列号是写在序号和确认号里面的

上面就是TCP协议头部的格式，由于它太重要了，是理解其它内容的基础，下面就将每个字段的信息都详细的说明一下。

• Source Port和Destination Port:分别占用16位，表示源端口号和目的端口号；用于区别主机中的不同进程，而IP地址是用来区分不同的主机的，源端口号和目的端口号配合上IP首部中的源IP地址和目的IP地址就能唯一的确定一个TCP连接；

• Sequence Number:用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节在数据流中的序号；主要用来解决网络报乱序的问题；

• Acknowledgment Number:32位确认序列号包含发送确认的一端所期望收到的下一个序号，因此，确认序号应当是上次已成功收到数据字节序号加1。不过，只有当标志位中的ACK标志（下面介绍）为1时该确认序列号的字段才有效。主要用来解决不丢包的问题；

• Offset:给出首部中32 bit字的数目，需要这个值是因为任选字段的长度是可变的。这个字段占4bit（最多能表示15个32bit的的字，即4*15=60个字节的首部长度），因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度是20字节；

• TCP Flags:TCP首部中有6个标志比特，它们中的多个可同时被设置为1，主要是用于操控TCP的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。每个标志位的意思如下：

URG：此标志表示TCP包的紧急指针域（后面马上就要说到）有效，用来保证TCP连接不被中断，并且督促中间层设备要尽快处理这些数据；

ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中；有两个取值：0和1，为1的时候表示应答域有效，反之为0；

PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队；

RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包；

SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被响应的时候，SYN=1，ACK=1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手；

FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

• Window:窗口大小，也就是有名的滑动窗口，用来进行流量控制；这是一个复杂的问题，这篇博文中并不会进行总结的；

其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表 示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开 连接。RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而 当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。

   1、 MSL 是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
   2、ip头中有一个TTL域，TTL是 time to live的缩写，中文可以译为“生存时间”，这个生存时间是由源主机设置初始值但不是存的具体时间，而是存储了一个ip数据报可以经过的最大路由数，每经 过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。
MSL要大于等于TTL。MSL是设置的最大值，TTL是实际生存时间
   3、 RTT是客户到服务器往返所花时间（round-trip time，简称RTT），TCP含有动态估算RTT的算法。TCP还持续估算一个给定连接的RTT，这是因为RTT受网络传输拥塞程序的变化而变化

FB杂货铺哥们写的网络相关

 

4.应用层

这个没什么介绍的，到时候记录下https原理

 

UDP 用户数据包协议，不提供复杂的控制机制，利用IP提供面向无连接的通信服务。应用程序发送来的数据，原样发送给对端。即使出现网络拥堵，UDP也无法进行流量控制。如果出现丢包，不负责重发。甚至包到了顺序乱了也不纠正。如果要实现就要自己在应用程序写。

1.DNS服务

2.视频，音频多媒体及时通信

3.广播多播（推送）

 

TCP/IP分层模型通信示例（不细分）

首先，每一层都会对数据进行一层包装，分数据部首和实际数据，报头里面会有协议信息和参数，可以理解数据的脸在报头体现。

1.应用层处理

例如应用层发送一个内容 ‘Hello xxx’，首先发送端打开应用程序，然后点击发送，就一层层开始传递了。一开始应用程序会对数据进行编码。这也就是表示层所要做的事情。编码完成之后，信息不会立马发出去，例如有些软件有一次同时发送多个的功能或者点击接收才可以接收。想这种何时建立通信何时发送数据的功能宽泛点讲就是回话层功能了。

2.TCP模块的处理

负责建立连接，发送数据和断开连接。TCP提供将应用层发来的数据顺利发送给对端的可靠传输。传输层拿到应用层的数据，然后向下传递，TCP包头部包含源端口号和目标端口号，序号，用来分片传输的时候区分是第几个序列号以及校验和，判断数据是否损坏。组装好数据之后发送IP层

3.IP模块的处理

一般每一层会把接收到的数据直接当成本层的数据，然后继续按照格式，给数据包装一层头部。这里就给数据添加IP。IP包生成后，参考路由控制表决定接收IP包的路由或者主机。虽有IP包就会发送给对应路由或主机的驱动进行接收。这里如果只有IP，在第一次的时候，需要发送ARP来获取对端的MAC地址进行链路层传递。

4.数据链路层（以太网驱动）

从IP传来的IP包，对以太网驱动来讲就是数据。给数据再加上以太网部首。这里的部首就是之前ARP或者缓存获取到的MAC地址，再加上本层以太网类型数据协议。之后把数据交给物理层，传输给对端。发送数据的时候会在宝最后添加FCS，为了判断包是否由于噪音而被损坏。

从右往左是数据流动方向，左往右是数据处理方向。可以看到，没经过一层，会添加上对应层里面的信息和协议号

5.对端以太网驱动接收

主机收到以太网包以后，首先从以太网包里面找到MAC地址，判断是否是我的数据。不是则丢弃。如果收到了数据，出去包头，把剩下的交由IP处理，或者是ARP处理

6.对端IP模块处理

和上层一样，IP层是拿到对应的IP地址，判断是否和本金吻合，否则一样丢弃。这里根据包头判断是TCP还是UDP，再交由对应的协议模块处理。如果是需要转发，就借助路由控制表进行转发。

7。对端TCP模块

首先会判断校验和，判断数据是否损坏。然后检查序列号，最后检查端口，给对应的端口。这里TCP接收完数据之后，就会发送一个确认回执给发送端。如果在给定时间内没有收到确认，发送端会重发。如果确认包已经接收，但是确认过程中正好超时，发送端有发了同样的一份数据，这时候序列号就有用了，避免接收重复的数据。

8.对端应用程序

这里应用程序接收到TCP获取到的数据传递上来，然后进行解码UI显示出来给用户

 

MAC和IP怎么理解？

当地址总数不是很多的情况下，有了唯一地址就可以定位相互通信的主体，然而，当地址总是非常多时，高效的找出目标地址就非常关键。类似电话区号，都是地址层次性的体现。Mac地址和IP地址的区别就是只有IP地址具备有效的层次性。虽然Mac地址根据制造商等信息也有层次性，但是对网络查找没有一点卵用，因此IP才是寻址过程中实现分层的具体体现。可以理解为Mac是身份证，IP是你现在住的地址，IP能通过省市区等层次进行快速寻址，这也是我认为这两位最大的关系和区别。通俗来讲，链路层（MAC）就是火车飞机等交通工具，网络层（IP）是你手上的攻略,如果你只用MAC地址，是能到达目的地，但是有个问题，你没到一个十字路口，你要检索整个区域每个角落，然后找到我要去的下一个十字路口，这也太耗时了，因此不可行，就引入了IP地址，IP能在物理传输过程中下一跳由路由器告诉（攻略）我们怎么走下一步。这就能说明为什么IP地址不变，但是数据传输过程中MAC地址一直在变化

为什么既要IP又要MAC？

上面通俗的说了，其实A主机和B主机在不同网段，如都知道对方的MAC，但是中间有其他设备例如路由器，交换机上面的，即使知道发送端和接收端的MAC，我们在物理层传输时以及需要知道路由器的MAC，因此需要IP地址可以来确认路由控制表里面的下一跳是哪个MAC地址。