网络是怎样连接的学习笔记（二）

第二章、用电信号传输TCP/IP数据-探索协议栈和网卡

2.1创建套接字

2.1.1协议栈的内部结构

操作系统的网络控制软件（协议栈）的内部结构如下：

图中最上面的部分是网络应用程序，它会将收发数据等操作委托给下层的部分来完成。

应用程序的下面是Socket库，其中包括解析器，解析器用来向DNS服务器发出查询。

在下面就是操作系统内部了，其中包括协议栈。协议栈的上半部分有两块，分别是用TCP协议收发数据的部分和用UDP收发数据的部分，他们会接受应用程序的委托，执行收发数据的操作。像浏览器、邮件等一般的应用程序使用都是使用TCP收发数据的，而像DNS等收发较短的控制数据的时候则使用UDP。

下面一半是用IP协议控制网络收发操作的部分。在互联网上传送数据时，数据会被切分为一个一个的网络包，而将网络包发送给通信对象的操作就是由IP来负责的。此外IP协议还包括ICMP协议和ARP协议。ICMP协议用来告知网络包传送过程中产生的错误以及各种控制信息，ARP协议用于根据IP协议查询相应的以太网MAC地址。

IP下面的网卡驱动程序负责控制网卡硬件，而最下面的网卡完成实际的收发操作，也就是对网线中的信号执行发送和接收操作。

2.1.2套接字的实体就是通信控制信息

在协议栈的内部有一块用于存储通信控制信息的内存空间。例如通信对象的IP地址、端口号、通信操作的进行状态等。本来套接字就是一个概念，并不存在真正的实体，如果一定要赋予它一个实体，可以说这些控制信息就是套接字的实体，或者说存放控制信息的内存空间就是套接字的实体。

协议栈在执行操作时需要参阅这些控制信息。例如，在发送数据时，需要看一下套接字中的通信对象的IP地址和端口号，以便向指定的IP地址和端口号发送数据。在发送数据后，协议栈需要等待对方收到数据返回的响应信息，但数据也有可能中途丢失，永远也等不到对方的响应。在这样的情况下，我们不能一直等下去，需要在等待一定时间之后重新发送丢失

的数据，这就需要协议栈能够知道执行发送数据操作后过了多长时间。为此，套接字中必须要记录是否已经收到响应，以及发送数据后经过了多长时间，才能根据这些信息按照需要执行重发操作。协议栈是根据套接字中记录的控制信息来工作的。

在Windows中可以用netstat -ano命令显示套接字内容。

2.1.3调用socket时的操作

浏览器通过Socket库向协议栈发出委托的一系列操作。浏览器委托协议栈使用TCP协议来收发数据。首先是创建套接字的阶段，应用程序调用socket申请创建套接字，协议栈根据应用程序的申请执行创建套接字的操作。在这个过程中，协议栈首先会分配用于存放一个套接字所需的内存空间。这相当于为控制信息准备一个容器。套接字刚刚创建时，数据收发操作还没有开始，因此需要在套接字的内存空间中写入表示这一初始状态的控制信息。到这里，创建套接字的操作就完成了。

接下来，需要将表示这个套接字的描述符告知应用程序。描述符相当于用来区分协议栈中的多个套接字的号码牌。收到描述符之后，应用程序在向协议栈进行收发数据委托时就需要提供这个描述符。由于套接字中记录了通信双方的信息以及通信处于怎样的状态，所以只要通过描述符确定了相应的套接字，协议栈就能够获取所有的相关信息，这样一来，应用程序就不需要每次都告诉协议栈应该和谁进行通信了。

2.2连接服务器

2.2.1连接的含义

创建套接字之后，应用程序（浏览器）就会调用connect，随后协议栈会将本地的套接字与服务器的套接字进行连接。连接实际上是通信双方交换控制信息，在套接字中记录这些必要信息并准备数据收发的一连串操作。套接字刚刚创建完成的时候，里面并没有存放任何数据，也不知道通信的对象是谁。浏览器可以根据网址来查询服务器的IP 地址，而且根据规则也知道应该使用80 号端口，但只有浏览器知道这些必要的信息是不够的，因为在调用socket 创建套接字时，这些信息并没有传递给协议栈。因此，我们需要把服务器的IP 地址和端口号等信息告知协议栈，这是连接操作的目的之一。

服务器上也有套接字，但服务器上的协议栈和客户端上的一样，只创建了套接字不知道和谁通信。并且服务器上的应用程序也不知道和谁通信。因此需要让客户端告知服务器必要的信息。所以，客户端向服务器传达开始通信的请求也是连接操作的目的之一。

此外，当执行数据收发操作时，还需要一块用来临时存放收发数据的内存空间，这块内存空间称为缓冲区，它也是连接操作的过程中分配的。

连接的目的：

（1）把服务器的IP 地址和端口号等信息告知协议栈。

（2）客户端向服务器传达开始通信的请求，将本机的IP地址和端口号告知服务器。

（3）创建用于执行数据收发操作的内存空间。

2.2.2负责保存控制信息的头部

通信操作中使用的控制信息分为两类。

（1）头部中记录的信息（以太网头部、IP头部、TCP头部）

（2）套接字（协议栈中的内存空间）中记录的信息

控制信息可以分为两类，第一类是客户端和服务器相互联络时交换的控制信息，这些内容在TCP 协议的规格中进行了定义。这些字段是固定的，在连接、收发、断开等各个阶段中，每次客户端和服务器之间进行通信时，都需要提供这些控制信息。这些信息会被添加在客户端与服务器之间传递的网络包的开头。在连接阶段，由于数据收发还没有开始，网络包中没有实际的数据，只有控制信息。

TCP头部的格式：

控制信息还有另外一类，那就是保存在套接字中，用来控制协议栈操作的信息。应用程序传递来的信息以及从通信对象接收到的信息都会保存在这里，还有收发数据操作的执行状态等信息也会保存在这里，协议栈会根据这些信息来执行每一步的操作。我们可以说，套接字的控制信息和协

议栈的程序本身其实是一体的，因此，“协议栈具体需要哪些信息”会根据协议栈本身的实现方式不同而不同，但这并没有什么问题。因为协议栈中的控制信息通信对方是看不见的，只要在通信时按照规则将必要的信息写入头部，客户端和服务器之间的通信就能够得以成立。例如，Windows 和Linux 操作系统的内部结构不同，协议栈的实现方式不同，必要的控制信息也就不同。但即便如此，两种系统之间依然能够互相通信，同样地，计算机和手机之间也能够互相通信。

2.2.3连接操作的实际过程

连接操作是从应用程序调用Socket库的connect开始的。

connect（< 描述符>, < 服务器IP 地址和端口号>, …）

上面的调用提供了服务器的IP地址和端口号，这些信息会传递给协议栈中的TCP模块。然后，TCP 模块会与该IP地址对应的对象，也就是与服务器的TCP模块交换控制信息。

首先，客户端先创建一个包含表示开始数据收发操作的控制信息的头部。头部包含很多字段，这里要关注的重点是发送方和接收方的端口号。到这里，客户端（发送方）的套接字就准确找到了服务器（接收方）的套接字，也就是搞清楚了我应该连接哪个套接字。然后，我们将头部中的控制位的SYN比特设置为1，大家可以认为它表示连接。此外还需要设置适当的序号和窗口大小。

连接操作的第一步是在TCP模块处创建表示连接控制信息的头部。

通过TCP头部中的发送方和接收方端口号可以找到要连接的套接字。

当TCP头部创建好之后，接下来TCP模块会将信息传递给IP模块并委托它进行发送。IP模块执行网络包发送操作后，网络包就会通过网络到达服务器，然后服务器上的IP模块会将接收到的数据传递给TCP模块，服务器的TCP模块根据TCP头部中的信息找到端口号对应的套接字，也就是说，从处于等待连接状态的套接字中找到与TCP头部中记录的端口号相同的套接字就可以了。当找到对应的套接字之后，套接字中会写入相应的信息，并将状态改为正在连接。上述操作完成后，服务器的TCP模块会返回响应，这个过程和客户端一样，需要在TCP头部中设置发送方和接收方端口号以及SYN比特。此外，在返回响应时还需要将ACK控制位设为1（客户端向服务器发送第一个网络包时，由于服务器还没有接收过网络包，所以需要将ACK比特设为0），这表示已经接收到相应的网络包。网络中经常会发生错误，网络包也会发生丢失，因此双方在通信时必须相互确认网络包是否已经送达，而设置ACK比特就是用来进行这一确认的。接下来，服务器TCP模块会将TCP头部传递给IP模块，并委托IP模块向客户端返回响应。

然后，网络包就会返回到客户端，通过IP模块到达TCP模块，并通过TCP头部的信息确认连接服务器的操作是否成功。如果SYN为1则表示连接成功，这时会向套接字中写入服务器的IP地址、端口号等信息，同时还会将状态改为连接完毕。刚才服务器返回响应时将ACK比特设置为1，相应地，客户端也需要将ACK比特设置为1并发回服务器，告诉服务器刚才的响应包已经收到。当这个服务器收到这个返回包之后，连接操作才算全部完成。

建立连接之后，协议栈的连接操作就结束了，也就是说connect已经执行完毕，控制流程被交回到应用程序。

2.3收发数据

2.3.1将HTTP请求消息交给协议栈

当控制流程从connect回到应用程序之后，接下来就进入数据收发阶段了。数据收发操作是从应用程序调用write将要发送的数据交给协议栈开始的。协议栈收到数据后执行发送操作。

协议栈并不关心应用程序传来的数据是什么内容。协议栈也并不是一收到数据就马上发送出去，而是会将数据存放在内部的发送缓冲区中，并等待应用程序的下一段数据。一次将多少数据交给协议栈是由应用程序自行决定的，协议栈并不能控制这一行为。在这样的情况下，

如果一收到数据就马上发送出去，就可能会发送大量的小包，导致网络效率下降，因此需要在数据积累到一定量时再发送出去。至于要积累多少数据才能发送，不同种类和版本的操作系统会有所不同，不能一概而论，但都是根据下面几个要素来判断的。

（1）第一个判断要素是每个网络包能容纳的数据长度，协议栈会根据一个叫作MTU（Maximum TransmissionUnit，最大传输单元）的参数来进行判断。MTU表示一个网络包的最大长度，在以太网中一般是1500 字节。。MTU 是包含头部的总长度，因此需要从MTU 减去头部的长度，然后得到的长度就是一个网络包中所能容纳的最大数据长度，这一长度叫作MSS。当从应用程序收到的数据长度超过或者接近MSS（Maximum Segment Size，最大分段大小。 TCP 和IP 的头部加起来一般是40 字节，因此MTU减去这个长度就是MSS。例如，在以太网中，MTU为1500，因此MSS就是1460）时再发送出去，就可以避免发送大量小包的问题了。

MTU：一个网络包的最大长度，以太网中一般为1500 字节。

MSS：除去头部之后，一个网络包所能容纳的TCP 数据的最大长度。

（2）另一个判断要素是时间。当应用程序发送数据的频率不高的时候，如果每次都等到长度接近MSS 时再发送，可能会因为等待时间太长而造成发送延迟，这种情况下，即便缓冲区中的数据长度没有达到MSS，也应该果断发送出去。为此，协议栈的内部有一个计时器，当经过一定时间之后，就会把网络包发送出去。

MTU与MSS

2.3.2对较大的数据进行拆分

HTTP请求消息一般不会很长，一个网络包就能装得下，但如果其中要提交表单数据，长度就可能超过一个网络包所能容纳的数据量，这种情况下，发送缓冲区中的数据会被以MSS长度为单位进行拆分，拆分出来的每块数据会被放进单独的网络包中。

根据发送缓冲区中的数据拆分的情况，当判断需要发送这些数据时，就在每一块数据前面加上TCP头部，并根据套接字中记录的控制信息标记发送方和接收方的端口号，然后交给IP模块来执行发送数据的操作。

应用程序数据的拆分发送：

2.3.3使用ACK号确认网络包已收到

到这里，网络包已经装好数据并发往服务器了，但数据发送操作还没有结束。TCP具备确认对方是否成功收到网络包，以及当对方没收到时进行重发的功能，因此在发送网络包之后，接下来还需要进行确认操作。

首先，TCP模块在拆分数据时，会先算好每一块数据相当于从头开始的第几个字节，接下来在发送这一块数据时，将算好的字节数写在TCP头部中，“序号”字段就是派在这个用场上的。然后，发送数据的长度也需要告知接收方，不过这个并不是放在TCP 头部里面的，因为用整个网络包的长度减去头部的长度就可以得到数据的长度，所以接收方可以用这种方法来进行计算。有了上面两个数值，我们就可以知道发送的数据是从第几个字节开始，长度是多少了。

通过这些信息，接收方还能够检查收到的网络包有没有遗漏。例如，假设上次接收到第1460 字节，那么接下来如果收到序号为1461的包，说明中间没有遗漏；但如果收到的包序号为2921，那就说明中间有包遗漏了。像这样，如果确认没有遗漏，接收方会将到目前为止接收到的数据长度加起来，计算出一共已经收到了多少个字节，然后将这个数值写入TCP头部的ACK号中发送给发送方。这个返回ACK号的操作被称为确认响应，通过这样的方式，发送方就能够确认对方到底收到了多少数据。

在实际的通信中，序号并不是从1开始的，而是需要用随机数计算出一个初始值，这是因为

如果序号都从1开始，通信过程就会非常容易预测，有人会利用这一点来发动攻击。但是如果初始值是随机的，那么对方就搞不清楚序号到底是从多少开始计算的，因此需要在开始收发数据之前将初始值告知通信对象。大家应该还记得在我们刚才讲过的连接过程中，有一个将SYN控制位设为1并发送给服务器的操作，就是在这一步将序号的初始值告知对方的。服务器端向客户端发送数据的情况也是类似，只不过方向是相反的，客户端和服务器双方都需要各自计算序号，因此双方需要在连接过程中互相告知自己计算的序号初始值。

实际的工作过程如下：

首先，客户端在连接时需要计算出与从客户端到服务器方向通信相关的序号初始值，并

将这个值发送给服务器。接下来，服务器会通过这个初始值计算出ACK号并返回给客户端。初始值有可能在通信过程中丢失，因此当服务器收到初始值后需要返回ACK号作为确认。同时，服务器也需要计算出与从服务器到客户端方向通信相关的序号初始值，并将这个值发送给客户端。接下来像刚才一样，客户端也需要根据服务器发来的初始值计算出ACK号并返回给服务器到这里，序号和ACK号都已经准备完成了，接下来就可以进入数据收发阶段了。

TCP采用这样的方式确认对方是否收到了数据，在得到对方确认之前，发送过的包都会保存在发送缓冲区中。如果对方没有返回某些包对应的ACK号，那么就重新发送这些包。

通过这一机制，我们可以确认接收方有没有收到某个包，如果没有收到则重新发送，这样一来，无论网络中发生任何错误，我们都可以发现并采取补救措施（重传网络包）。反过来说，有了这一机制，我们就不需要在其他地方对错误进行补救了。因此，网卡、集线器、路由器都没有错误补偿机制，一旦检测到错误就直接丢弃相应的包。应用程序也是一样，因为采用TCP传输，即便发生一些错误对方最终也能够收到正确的数据，所以应用程序只管自顾自地发送这些数据就好了。不过，如果发生网络中断、服务器宕机等问题，那么无论TCP怎样重传都不管用。因此TCP 会在尝试几次重传无效之后强制结束通信，并向应用程序报错。

通过“序号”和“ACK 号”可以确认接收方是否收到了网络包。

2.3.4根据网络包平均往返时间调整ACK号等待时间

网络的错误检测和补偿机制非常复杂。下面来说几个关键的点，首先是返回ACK号的等待时间（这个等待时间叫超时时间）。

当网络传输繁忙时就会发生拥塞，ACK号的返回会变慢，这时我们就必须将等待时间设置得稍微长一点，否则可能会发生已经重传了包之后，前面的ACK号才姗姗来迟的情况。这样的重传是多余的，因为ACK号的返回变慢大多是由于网络拥塞引起的，因此如果此时再出现很多多余的重传，对于本来就很拥塞的网络来说无疑是雪上加霜。那么等待时间是不是越长越好呢？也不是。如果等待时间过长，那么包的重传就会出现很大的延迟，也会导致网络速度变慢。

因此，TCP采用了动态调整等待时间的方法，这个等待时间是根据ACK号返回所需的时间来判断的。具体来说，TCP会在发送数据的过程中持续测量ACK号的返回时间，如果ACK号返回变慢，则相应延长等待时间；相对地，如果ACK号马上就能返回，则相应缩短等待时间。

2.3.5使用窗口有效管理ACK号

每发送一个包就等待一个ACK号的方式是最简单也最容易理解的，但在等待ACK号的这段时间中，如果什么都不做那实在太浪费了。为了减少这样的浪费，TCP采用滑动窗口的方式来管理数据发送和ACK号的操作。所谓滑动窗口，就是在发送一个包之后，不等待ACK号返回，而是直接发送后续的一系列包。这样一来，等待ACK号的这段时间就被有效利用起来了。

虽然这样做能够减少等待ACK号时的时间浪费，但是在一来一回方式中，接收方完成接收操作后返回ACK号，然后发送方收到ACK号之后才继续发送下一个包，因此不会出现发送的包太多接收方处理不过来的情况。但如果不等返回ACK号就连续发送包，就有可能会出现发送包的频率超过接收方处理能力的情况。

因为当接收方的TCP收到包后，会先将数据存放到接收缓冲区中。然后，接收方需要计算ACK号，将数据块组装起来还原成原本的数据并传递给应用程序，如果这些操作还没完成下一个包就到了，下一个包也会被暂存在接收缓冲区中。如果数据到达的速率比处理这些数据并传递给应用程序的速率还要快，最后就会溢出。导致后面的数据就进不来了，因此接收方就收不到后面的包了。所以，接收方需要告诉发送方自己最多能接收多少数据，然后发送方根据这个值对数据发送操作进行控制，这就是滑动窗口方式的基本思路。

一来一回方式和滑动窗口方式：

窗口的具体工作方式是接收方将数据暂存到接收缓冲区中并执行接收操作。当接收操作完成后，接收缓冲区中的空间会被释放出来，也就可以接收更多的数据了，这时接收方会通过TCP 头部中的窗口字段将自己能接收的数据量告知发送方。这样一来，发送方就不会发送过多的数据，导致超出接收方的处理能力了。

并且接收方在收到数据之后马上就会开始进行处理，如果接收方的性能高，处理速度比包的到达速率还快，缓冲区马上就会被清空，并通过窗口字段告知发送方。

前面提到的能够接收的最大数据量称为窗口大小（一般和接收方的缓冲区大小一致），它是TCP 调优参数中非常有名的一个。

滑动窗口与接收缓冲区：

2.3.6ACK与窗口的合并

要提高收发数据的效率，可以将ACK号和更新窗口大小的通知合并。当收到的数据刚刚开始填入缓冲区时，没必要每次都向发送方更新窗口大小，发送方在每次发送数据时减掉已发送的数据长度就可以自行计算出当前窗口的剩余长度。因此，更新窗口大小的时机应该是接收方从缓冲区中取出数据传递给应用程序的时候。因为这个时候接收方将数据传递给应用程序，会导致接收缓冲区剩余容量增加，而且发送方也不知道什么时候会进行这样的操作，这时需要告知发送方，这就是更新窗口大小的时机。

另一方面，当接收方收到数据时，如果确认内容没有问题，就应该向发送方返回ACK号，因此我们可以认为收到数据之后马上就应该进行这一操作。

这两个方面结合来看，发送方数据到达接收方，在接收方完成接收操作之后就会返回ACK号给发送方。再过一段时间，当数据传递给应用程序之后，才需要更新窗口大小。这样的话，每收到一个包，就需要向发送方分别发送ACK号和窗口更新这两个单独的包。这样一来，接收方发给发送方的包就太多了，导致网络效率下降。

因此，在等待发送ACK号的时候正好需要更新窗口，这时就可以把ACK号和窗口更新放在一个包里发送，从而减少包的数量。当需要连续发送多个ACK号时，也可以减少包的数量，这是因为ACK号表示的是已收到的数据量，也就是说，它是告诉发送方目前已接收的数据的最后位置在哪里，因此当需要连续发送ACK号时，只要发送最后一个ACK号就可以了，中间的可以全部省略。当需要连续发送多个窗口更新时也可以减少包的数量，因为连续发生窗口更新说明应用程序连续请求了数据，接收缓冲区的剩余空间连续增加。这种情况和ACK号一样，可以省略中间过程，只要发送最终的结果就可以了。

2.3.7接收HTTP响应消息

对于响应消息，浏览器需要进行接收操作，这一操作也需要协议栈的参与。

首先，浏览器在委托协议栈发送请求消息之后，会调用read程序来获取响应消息。然后，控制流程会通过read转移到协议栈，然后协议栈会执行接下来的操作。和发送数据一样，接收数据也需要将数据暂存到接收缓冲区中，这里的操作过程如下。首先，协议栈尝试从接收缓冲区中取出数据并传递给应用程序，但这个时候请求消息刚刚发送出去，响应消息可能还没返回。因此这时接收缓冲区中并没有数据，那么接收数据的操作也就无法继续。这时，协议栈会将应用程序的委托，也就是从接收缓冲区中取出数据并传递给应用程序的工作暂时挂起B，等服务器返回的响应消息到达之后再继续执行接收操作。

协议栈的接收操作包括，协议栈会检查收到的数据块和TCP头部的内容，判断是否有数据丢失，如果没有问题则返回ACK号。然后，协议栈将数据块暂存到接收缓冲区中，并将数据块按顺序连接起来还原出原始的数据，最后将数据交给应用程序。然后将控制流程交回应用程序。将数据交给应用程序之后，协议栈还需要找到合适的时机向发送方发送窗口更新。

2.4从服务器断开并删除套接字

2.4.1数据发送完毕后断开连接

收发数据结束的时间点应该是应用程序判断所有数据都已经发送完毕的时候。这时，数据发送完毕的一方会发起断开过程，但不同的应用程序会选择不同的断开时机。以Web为例，浏览器向Web服务器发送请求消息，Web服务器再返回响应消息，这时收发数据的过程就全部

结束了，服务器一方会发起断开过程当然，可能也有一些程序是客户端发送完数据就结束了，不用等服务器响应，这时客户端会先发起断开过程。这一判断是应用程序作出的，协议栈在设计上允许任何一方先发起断开过程。

无论哪种情况，完成数据发送的一方会发起断开过程，以服务器为例，首先，服务器一方的应用程序会调用Socket库的close程序。然后，服务器的协议栈会生成包含断开信息的TCP头部，具体来说就是将控制位中的FIN比特设为1。接下来，协议栈会委托IP模块向客户端发送数据，同时，服务器的套接字中也会记录下断开操作的相关信息。接下来轮到客户端了。当收到服务器发来的FIN 为1的TCP头部时，客户端的协议栈会将自己的套接字标记为进入断开操作状态。然后，为了告知服务器已收到FIN为1的包，客户端会向服务器返回一个ACK号。这些操作完成后，协议栈就可以等待应用程序来取数据了。过了一会儿，应用程序就会调用read来读取数据。这时，协议栈不会向应用程序传递数据，而是会告知应用程序（浏览器）来自服务器的数据已经全部收到了。根据规则，服务器返回请求之后，Web通信操作就全部

结束了，因此只要收到服务器返回的所有数据，客户端的操作也就随之结束了。因此，客户端应用程序会调用close来结束数据收发操作，这时客户端的协议栈也会和服务器一样，生成一个FIN比特为1 的TCP包，然后委托IP模块发送给服务器。一段时间之后，服务器就会返回ACK号。到这里，客户端和服务器的通信就全部结束了。

断开连接的交互过程：

2.4.2删除套接字

和服务器的通信结束之后，用来通信的套接字也就不会再使用了，这

时我们就可以删除这个套接字了。不过，套接字并不会立即被删除，而是

会等待一段时间之后再被删除。等待这段时间是为了防止误操作，引发误操作的原因有很多，举一个最容易理解的例子。客户端先发起断开，则断开的操作顺序如下。

（1）客户端发送FIN

（2）服务器返回ACK号

（3）服务器发送FIN

（4）客户端返回ACK号

如果最后客户端返回的ACK号丢失了，这时，服务器没有接收到ACK号，可能会重发一次FIN。如果这时客户端的套接字已经删除了，那么套接字中保存的控制信息也就跟着消失了，套接字对应的端口号就会被释放出来。这时，如果别的应用程序要创建套接字，新套接字碰巧又被分配了同一个端口号，而服务器重发的FIN正好到达，本来这个FIN是要发给刚刚删除的那个套接字的，但新套接字具有相同的端口号，于是这个FIN就会错误地跑到新套接字里面，新套接字就开始执行断开操作了。之所以不马上删除套接字，就是为了防止这样的误操作。

至于具体等待多长时间，这和包重传的操作方式有关。网络包丢失之后会进行重传，这个操作通常要持续几分钟。如果重传了几分钟之后依然无效，则停止重传。在这段时间内，网络中可能存在重传的包，也就有可能发生前面讲到的这种误操作，因此需要等待到重传完全结束。协议中对于这个等待时间没有明确的规定，一般来说会等待几分钟之后再删除套接字。

2.4.3数据收发操作小结

数据收发操作的第一步是创建套接字。一般来说，服务器一方的应用程序在启动时就会创建好套接字并进入等待连接的状态。客户端则一般是在用户触发特定动作，需要访问服务器的时候创建套接字。在这个阶段，还没有开始传输网络包。

创建套接字之后，客户端会向服务器发起连接操作。首先，客户端会生成一个SYN为1的TCP包并发送给服务器这个TCP包的头部还包含了客户端向服务器发送数据时使用的初始序号，以及服务器向客户端发送数据时需要用到的窗口大小，当这个包到达服务器之后，服务器会返回一个SY为1的TCP包，这个包的头部中也包含了序号和窗口大小，此外还包含表示确认已收到包ACK号。当这个包到达客户端时，客户端会向服务器返回一个包含表示确认的ACK号的TCP包。到这里，连接操作就完成了，双方进入数据收发阶段。

数据收发阶段的操作根据应用程序的不同而有一些差异，以Web为例，首先客户端会向服务器发送请求消息。TCP会将请求消息切分成一定大小的块，并在每一块前面加上TCP头部，然后发送给服务器。TCP头部中包含序号，它表示当前发送的是第几个字节的数据。当服务器

收到数据时，会向客户端返回ACK号。在最初的阶段，服务器只是不断接收数据，随着数据收发的进行，数据不断传递给应用程序，接收缓冲区就会被逐步释放。这时，服务器需要将新的窗口大小告知客户端。当服务器收到客户端的请求消息后，会向客户端返回响应消息，这个过程和刚才的过程正好相反。

服务器的响应消息发送完毕之后，数据收发操作就结束了，这时开始执行断开操作。以Web为例，服务器会先发起断开过程。就会在这个过程中，服务器先发送一个FIN为1的TCP包，然后客户端返回一个表示确认收到的ACK号。接下来，双方还会交换一组方向相反的FIN为1的TCP包和包含ACK号的TCP包。

最后，在等待一段时间后，套接字会被删除。

TCP的整体流程：

2.5IP与以太网的包收发操作

2.5.1包的基本知识

TCP模块在执行连接、收发、断开等各阶段操作时，都需要委托IP模块将数据封装成包发送给通信对象。

包是由头部和数据两部分构成的，发送方的网络设备会负责创建包，创建包的过程就是生成含有正确控制信息的头部，然后再附加上要发送的数据。接下来，包会被发往最近的网络转发设备。当到达最近的转发设备之后，转发设备会根据头部中的信息判断接下来应该发往哪里。这个过程需要用到一张表，这张表里面记录了每一个地址对应的发送方向，也就是按照头部里记录的目的地址在表里进行查询，并根据查到的信息判断接下来应该发往哪个方向。接下来，包在向目的地移动的过程中，又会到达下一个转发设备，然后又会按照同样的方式被发往下一个转发设备。就这样，经过多个转发设备的接力之后，包最终就会到达接收方的网络设备。

网络中有路由器和集线器两种不同的转发设备，它们在传输网络包时有着各自的分工。

（1）路由器根据目标地址判断下一个路由器的位置

（2）集线器在子网中将网络包传输到下一个路由

实际上，集线器是按照以太网规则传输包的设备，而路由器是按照IP规则传输包的设备，因此我们也可以作如下理解。

（1）IP协议根据目标地址判断下一个IP转发设备的位置

（2）子网中的以太网协议将包传输到下一个转发设备

TCP/IP包包含如下两个头部。

（a）MAC头部（用于以太网协议）

（b）IP头部（用于IP协议）

这两个头部分别具有不同的作用。首先，发送方将包的目的地，也就是要访问的服务器的IP地址写入IP头部中。这样一来，我们就知道这个包应该发往哪里，IP协议就可以根据这一地址查找包的传输方向，从而找到下一个路由器的位置。接下来，IP协议会委托以太网协议将包传输过去。这时，IP协议会查找下一个路由器的以太网地址（MAC地址），并将这个地址写入MAC头部中。这样一来，以太网协议就知道要将这个包发到哪一个路由器上了。

网络包在传输过程中会经过集线器，集线器是根据以太网协议工作的设备。为了判断包接下来应该向什么地方传输，集线器里有一张表（用于以太网协议的表），可根据以太网头部中记录的目的地信息查出相应的传输方向。

接下来，包会到达下一个路由器。路由器中有一张IP协议的表，可根据这张表以及IP头部中记录的目的地信息查出接下来应该发往哪个路由器。为了将包发到下一个路由器，我们还需要查出下一个路由器的MAC地址，并记录到MAC头部中，大家可以理解为改写了MAC头部（更准确地说，收到包的时候MAC头部会被舍弃，而当再次发送的时候又会加上包含新MAC地址的新MAC头部）。这样，网络包就又被发往下一个节点了。

前面讲了IP和以太网的分工，其中以太网的部分也可以替换成其他的东西，例如无线局域网、ADSL、FTTH等，它们都可以替代以太网的角色帮助IP协议来传输网络包。因此，将IP和负责传输的网络分开，可以更好地根据需要使用各种通信技术。像互联网这样庞大复杂的网络，在架构上需要保证灵活性，这就是设计这种分工方式的原因。

IP网络包的传输方式：

2.5.2包收发操作概览

IP模块仅仅是整个包传输过程的入口。实际上将包从发送方传输到接收方的工作是由集线器、路由器等网络设备来完成的。

包收发操作的起点是TCP模块委托IP模块发送包的操作。这个委托的过程就是TCP模块在数据块的前面加上TCP头部，然后整个传递给IP模块，这部分就是网络包的内容。

与此同时，TCP模块还需要指定通信对象的IP地址，也就是需要写清楚“将什么内容发给谁”。

收到委托后，IP模块会将包的内容当作一整块数据，在前面加上包含控制信息的头部。刚才我们讲过，IP模块会添加IP 头部和MAC头部这两种头部。IP头部中包含IP协议规定的、根据IP地址将包发往目的地所需的控制信息；MAC头部包含通过以太网的局域网将包传输至最近的路由器所需的控制信息。加上这两个头部之后，一个包就封装好了，这些就是IP模块负责的工作。

包收发操作的整体过程：

IP 模块负责添加如下两个头部。

（1） MAC头部：以太网用的头部，包含MAC地址

（2） IP头部：IP用的头部，包含IP地址

接下来，封装好的包会被交给网络硬件（网卡）。传递给网卡的网络包是由一连串0和1组成的数字信息，网卡会将这些数字信息转换为电信号或光信号，并通过网线（或光纤）发送出去，然后这些信号就会到达集线器、路由器等转发设备，再由转发设备一步一步地送达接收方。

包送达对方之后，对方会作出响应。返回的包也会通过转发设备发送回来，然后我们需要接收这个包。接收的过程和发送的过程是相反的，信息先以电信号的形式从网线传输进来，然后由网卡将其转换为数字信息并传递给IP模块。

接下来，IP模块会将MAC头部和IP头部后面的内容，也就是TCP头部加上数据块，传递给TCP模块。接下来的操作就是我们之前讲过的TCP模块负责的部分了。

在这个过程中IP 模块会将TCP头部和数据块看作一整块二进制数据，在执行收发操作时并不关心其中的内容，也不关心这个包是包含TCP头部和数据两者都有呢，还是只有TCP头部而没有数据。当然，IP模块也不关心TCP的操作阶段，对于包的乱序和丢失也一概不知。关于IP的工作方式，可适用于任何TCP委派的收发操作。

无论要收发的包是控制包还是数据包，IP对各种类型的包的收发操作都是相同的。

2.3.5生成包含接收方IP地址的IP头部

IP模块的具体工作过程如下。IP模块接受TCP模块的委托负责包的收发工作，它会生成IP头部并附加在TCP头部前面。其中最重要的内容就是IP地址，它表示这个包应该发到哪里去。这个地址是由TCP模块告知的，而TCP又是在执行连接操作时从应用程序那里获得这个地址的，因此这个地址的最初来源就是应用程序。

IP头部中还需要填写发送方的IP 地址（设置窗口或者配置文件中设置的IP地址，或者是由DHCP服务器自动分配的IP地址）。

一般的客户端计算机上只有一块网卡，因此也就只有一个IP地址，这种情况下我们可以认为这个IP地址就是计算机的IP地址。IP地址实际上并不是分配给计算机的，而是分配给网卡的，因此当计算机上存在多块网卡时，每一块网卡都会有自己的IP地址。很多服务器上都会安装多块网卡，这时一台计算机就有多个IP地址，在填写发送方IP地址时就需要判断到底应该填写哪个地址。这个判断相当于在多块网卡中判断应该使用哪一块网卡来发送这个包，也就相当于判断应该把包发往哪个路由器，因此只要确定了目标路由器，也就确定了应该使用哪块网卡，也就确定了发送方的IP地址。

IP头部的“接收方IP地址”填写通信对象的IP地址。发送方IP地址需要判断发送所使用的网卡，并填写该网卡的IP地址。

何判断应该把包交给哪块网卡和路由器使用IP表判断下一个路由器位置的操作是一样的。因为协议栈的IP模块与路由器中负责包收发的部分都是根据IP协议规则来进行包收发操作的，所以它们也都用相同的方法来判断把包发送给谁。这个“IP表”叫作路由表。我们可以通过routeprint命令来显示路由表。

这样一来，我们就可以判断出应该使用哪块网卡来发送包了，然后就可以在IP头部的发送方IP地址中填上这块网卡对应的IP地址。接下来还需要填写协议号，它表示包的内容是来自哪个模块的。例如，如果是TCP模块委托的内容，则设置为06（十六进制），如果是UDP模块

委托的内容，则设置为17（十六进制），这些值都是按照规则来设置的。在现在我们使用的浏览器中，HTTP请求消息都是通过TCP来传输的，因此这里就会填写表示TCP的06（十六进制）。

IP头部的格式：

2.5.4生成以太网用的MAC头部

生成了IP头部之后，接下来IP模块还需要在IP头部的前面加上MAC头部。IP头部中的接收方IP地址表示网络包的目的地，通过这个地址我们就可以判断要将包发到哪里，但在以太网的世界中，TCP/IP的这个思路是行不通的。以太网在判断网络包目的地时和TCP/IP 的方式不同，因此必须采用相匹配的方式才能在以太网中将包发往目的地，而MAC头部就是干这个用的。它包含了接收方和发送方的MAC地址等信息。MAC和IP头部中的接收方和发送方IP地址的功能差不多，只不过IP地址的长度为32 比特，而MAC地址为48 比特。此外，IP地址是层次化的结构，而MAC地址中的48比特可以看作是一个整体。

第3个以太类型字段和IP 头部中的协议号类似。在IP中，协议号表示IP头部后面的包内容的类型；而在以太网中，我们可以认为以太网类型后面就是以太网包的内容，而以太类型就表示后面内容的类型。以太网包的内容可以是IP、ARP等协议的包，它们都有对应的值，这也是根据规则来确定的。

MAC头部的字段：

生成MAC头部时，“以太类型”，这里填写表示IP协议的值0800（十六进制）。接下来是发送方MAC地址，这里填写网卡本身的MAC地址。MAC地址是在网卡生产时写入ROM里的，只要将这个值读取出来写入MAC头部就可以了。而接收方MAC地址需要查一下路由表。在路由表中找到相匹配的条目，确定转发路由器的IP地址。还需要执行根据IP地址查询MAC地址。

IP模块根据路由表Gateway栏的内容判断应该把包发送给谁。

2.5.5通过ARP查询目标路由器的MAC地址

在以太网中，有一种叫作广播的方法，可以把包发给连接在同一以太网中的所有设备。ARP（Address ResolutionProtocol，地址解析协议）就是利用广播对所有设备提问：“××这个IP地址是谁的？请把你的MAC地址告诉我。”然后就会有人回答：“这个IP地址是我的，我的MAC地址是××××。

如果对方和自己处于同一个子网中，那么通过上面的操作就可以得到对方的MAC地址（如果路由表的设置正确，那么对方应该在同一子网，否则对方无法作出ARP响应，这时只能认为对方不存在，包的发送操作就会失败）。然后，我们将这个MAC地址写入MAC头部，MAC

头部就完成了。

用ARP查询MAC地址：

查询结果放到一块叫作ARP缓存的内存空间方便再用，在发送包时，先查询一下ARP缓存，如果其中已经保存了对方的MAC地址，就不需要发送ARP查询，直接使用ARP缓存中的地址，而当ARP缓存中不存在对方MAC地址时，则发送ARP查询。

如果总是使用ARP缓存中保存的地址也会产生问题。例如当IP地址发生变化时，ARP缓存的内容就会和现实发生差异。为了防止这种问题的发生，ARP缓存中的值在经过一段时间后会被删除，一般这个时间在几分钟左右。当地址从ARP缓存中删除后，只要重新执行一次ARP 查询就可以再次获得地址了。上面这个策略能够在几分钟后消除缓存和现实的差异，但IP地址刚刚发生改变的时候，ARP缓存中依然会保留老的地址，这时就会发生通信的异常（遇到这种情况，可以查看ARP缓存的内容，并手动删除过时的条目）。

查询ARP缓存的内容：

查询MAC 地址需要使用ARP

将MAC头部加在IP头部的前面，整个包就完成了。到这里为止，整个打包的工作是由IP模块负责的。MAC头部是以太网需要的内容，但是交给IP模块负责的原因是，如果在交给网卡之前，IP模块能够完成整个打包工作，那么网卡只要将打好的包发送出去就可以了。而不用管是不是IP类型的包。这样一来，同一块网卡就可以支持各种类型的包。

2.5.6以太网的基本知识

以太网是一种为多台计算机能够彼此自由和廉价地相互通信而设计的通信技术。

以太网的基本结构：

图中（a）是原型，这种网络的本质其实就是一根网线。图上还有一种叫作收发器的小设备，它的功能只是将不同网线之间的信号连接起来而已。因此，当一台计算机发送信号时，信号就会通过网线流过整个网络，最终到达所有的设备。同样地，这种网络中任何一台设备发送的信号所有设备都能接收到。需要在信号的开头加上接收者的信息，也就是地址。这样一来就能够判断信号的接收者了，与接收者地址匹配的设备就接收这个包，其他的设备则丢弃这个包。

（b）是将主干网线替换成了一个中继式集线器，将收发器网线替换成了双绞线。不过，虽然网络的结构有所变化，但信号会发送给所有设备这一基本性质并没有改变。

（c）使用交换式集线器（交换机）是我们现在以太网使用的结构，现在信号只会流到根据MAC地址指定的设备，而不会到达其他设备了。当然，根据MAC地址来传输包这一点并没有变，因此MAC头部的设计也得以保留。

尽管以太网经历了数次变迁，但其基本的3个性质至今仍未改变，即将包发送到MAC头部的接收方MAC地址代表的目的地，用发送方MAC地址识别发送方，用以太类型识别包的内容。因此，大家可以认为具备这3个性质的网络就是以太网。

2.5.7将IP包转换为电信号或光信号发送出去

IP生成的网络包只是存放在内存中的一串数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电或光信号，才能在网线上传输。负责执行这一操作的是网卡，但网卡也无法单独工作，要控制网卡还需要网卡驱动程序。网卡并不是通上电之后就可以马上开始工作的，而是和其他硬件一样，都需要进行初始化。也就是说，打开计算机启动操作系统的时候，网卡驱动程序会对硬件进行初始化操作，然后硬件才进入可以使用的状态。这些操作包括硬件错误检查、初始设置等步骤，这些步骤对于很多其他硬件也是共通的，但也有一些操作是以太网特有的，那就是在控制以太网收发操作的MAC（Media Access Control）模块中设置MAC地址。

网卡的ROM中保存着全世界唯一的MAC地址，这是在生产网卡时写入的，将这个值读出之后就可以对MAC模块进行设置，MAC模块就知道自己对应的MAC地址了。也有一些特殊的方法，比如从命令或者配置文件中读取MAC地址并分配给MAC模块。这种情况下，网卡会忽略ROM 中的MAC地址。有人认为在网卡通电之后，ROM中的MAC地址就自动生效了，其实不然，真正生效的是网卡驱动进行初始化时在MAC模块中设置的那个MAC地址。在操作系统启动并完成这些初始化操作之后，网卡就可以等待来自IP的委托了。

网卡：

网卡的ROM中保存着全世界唯一的MAC地址，这是在生产网卡时写入的。

网卡中保存的MAC地址会由网卡驱动程序读取并分配给MAC模块。

2.5.8给网络包再加3个控制数据

网卡驱动从IP模块获取包之后，会将其复制到网卡内的缓冲区中，然后向MAC模块发送发送包的命令。接下来就轮到MAC模块进行工作了。首先，MAC模块会将包从缓冲区中取出，并在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。

网卡发送出去的包：

报头是一串像10101010…这样1和0交替出现的比特序列，长度为56比特，它的作用是确定包的读取时机。当这些1010的比特序列被转换成电信号后，会形成下图这样的波形。

每个包的前面都有报头和起始帧分界符（SFD），报头用来测定时机，SFD用来确定帧的起始位置。

接收方在收到信号时，遇到这样的波形就可以判断读取数据的时机。用电信号来表达数字信息时，我们需要让0和1两种比特分别对应特定的电压和电流例下图（a）这样的电信号就可以表达数字信息。通过电信号来读取数据的过程就是将这种对应关系颠倒过来。也就是说，通过测量信号中的电压和电流变化，还原出0 和1 两种比特的值。然而，实际的信号并不像下图所示的那样有分隔每个比特的辅助线，因此在测量电压和电流时必须先判断出每个比特的界限在哪里。但是，像下图（a）右边这种1和0连续出现的信号，由于电压和电流没有变化，我们就没办法判断出其中每个比特到底应该从哪里去切分。

图中，通过时钟测量读取信号的时机，当信号连续为1或连续为0时，比特之间的界限就会消失，如果将时钟信号叠加进去，就可以判断出比特之间的界限了。

要解决这个问题，最简单的方法就是在数据信号之外再发送一组用来区分比特间隔的时钟信号。如上图（b）所示，当时钟信号从下往上变化时读取电压和电流的值，然后和0或1进行对应就可以了。但是这种方法存在问题。当距离较远，网线较长时，两条线路的长度会发生差异，数据信号和时钟信号的传输会产生时间差，时钟就会发生偏移。

要解决这个问题，可以采用将数据信号和时钟信号叠加在一起的方法。这样的信号如上图（c）所示，发送方将这样的信号发给接收方。由于时钟信号是像上图（b）这样按固定频率进行变化的，只要能够找到这个变化的周期，就可以从接收到的信号（c）中提取出时钟信号（b），进而通过接收信号（c）和时钟信号（b）计算出数据信号（a），这和发送方将数据信号和时钟信号进行叠加的过程正好相反。然后，只要根据时钟信号（b）的变化周期，我们就可以从数据信号（a）中读取相应的电压和电流值，并将其还原为0或1的比特了。

这里的重点在于如何判断时钟信号的变化周期。时钟信号是以10 Mbit/s或者100 Mbit/s这种固定频率进行变化的，就像我们乘坐自动扶梯一样，只要对信号进行一段时间的观察，就可以找到其变化的周期。因此，我们不能一开始就发送包的数据，而是要在前面加上一段用来测量时钟信号的特殊信号，这就是报头的作用。

起始帧分界符是一个用来表示包起始位置的标记。

末尾的FCS（帧校验序列）用来检查包传输过程中因噪声导致的波形紊乱、数据错误，它是一串32比特的序列，是通过一个公式对包中从头到尾的所有内容进行计算而得出来的。当原始数据中某一个比特发生变化时，计算出来的结果就会发生变化。在包传输过程中，如果受到噪声的干扰而导致其中的数据发生了变化，那么接收方计算出的FCS和发送方计算出的FCS就会不同，这样我们就可以判断出数据有没有错误。

2.5.9向集线器发送网络包

加上报头、起始帧分界符和FCS之后，我们就可以将包通过网线发送出去了发送信号的操作分为两种，一种是使用集线器的半双工（某一时刻只能进行发送或接收其中一种操作的叫作“半双工”）模式，另一种是使用交换机的全双工（发送和接收同时并行的方式叫作“全双工”）模式。

在半双工模式中，为了避免信号碰撞，首先要判断网线中是否存在其他设备发送的信号。如果有，则需要等待该信号传输完毕，因为如果在有信号时再发送一组信号，两组信号就会发生碰撞。当之前的信号传输完毕，或者本来就没有信号在传输的情况下，我们就可以开始发送信号了。首先，MAC模块从报头开始将数字信息按每个比特转换成电信号，然后由PHY（PHY（Physical Layer Device，物理层装置，在速率为100Mbit/s以上的以太网中都叫PHY），或者叫MAU（Medium Attachment Unit，介质连接单元）的信号收发模块发送出去。在这里，将数字信息转换为电信号的速率就是网络的传输速率，例如每秒将10Mbit的数字信息转换为电信号发送出去，则速率就是10Mbit/s。

接下来，PHY（MAU）模块会将信号转换为可在网线上传输的格式，并通过网线发送出去。以太网规格中对不同的网线类型和速率以及其对应的信号格式进行了规定，但MAC模块并不关心这些区别，而是将可转换为任意格式的通用信号发送给PHY（MAU）模块，然后PHY（MAU）模块再将其转换为可在网线上传输的格式。大家可以认为PHY（MAU）模块的功能就是对MAC 模块产生的信号进行格式转换。

10BASE-TX的信号：

网卡的MAC模块生成通用信号，然后由PHY（MAU）模块转换成可在网线中传输的格式，并通过网线发送出去。

2.5.10接收返回包

在使用集线器的半双工模式以太网中，一台设备发送的信号会到达连接在集线器上的所有设备。这意味着无论是不是发给自己的信号都会通过接收线路传进来，因此接收操作的第一步就是不管三七二十一把这些信号全都收进来再说。

信号的开头是报头，通过报头的波形同步时钟，然后遇到起始帧分界符时开始将后面的信号转换成数字信息。这个操作和发送时是相反的，即PHY（MAU）模块先开始工作，然后再轮到MAC模块。首先，PHY（MAU）模块会将信号转换成通用格式并发送给MAC模块，MAC 模块再从头开始将信号转换为数字信息，并存放到缓冲区中。当到达信号的末尾时，还需要检查FCS。具体来说，就是将从包开头到结尾的所有比特套用到公式中计算出FCS，然后和包末尾的FCS 进行对比，正常情况下两者应该是一致的，如果中途受到噪声干扰而导致波形发生紊乱，则两者的值会产生差异，这时这个包就会被当作错误包而被丢弃。

如果FCS校验没有问题，接下来就要看一下MAC头部中接收方MAC地址与网卡在初始化时分配给自己的MAC地址是否一致，以判断这个包是不是发给自己的。我们没必要去接收发给别人的包，因此如果不是自己的包就直接丢弃，如果接收方MAC地址和自己MAC地址一致，则将包放入缓冲区中。到这里，MAC模块的工作就完成了，接下来网卡会通知计算机收到了一个包。

通知计算机的操作会使用一个叫作中断的机制。中断的工作过程是这样的。首先，网卡向扩展总线中的中断信号线发送信号，该信号线通过计算机中的中断控制器连接到CPU。当产生中断信号时，CPU会暂时挂起正在处理的任务，切换到操作系统中的中断处理程序B。然后，中断处理程序会调用网卡驱动，控制网卡执行相应的接收操作。

中断是有编号的，网卡在安装的时候就在硬件中设置了中断号，在中断处理程序中则将硬件的中断号和相应的驱动程序绑定。例如，假设网卡的中断号为11，则在中断处理程序中将中断号11和相应的网卡驱动绑定起来，当网卡发起中断时，就会自动调用网卡驱动了。现在的硬件设备都遵循即插即用规范自动设置中断号，我们没必要去关心中断号了，在以前需要手动设置中断号的年代，经常发生因为设置了错误的中断号而导致网卡无法正常工作的问题。

网卡驱动被中断处理程序调用后，会从网卡的缓冲区中取出收到的包，并通过MAC头部中的以太类型字段判断协议的类型。现在我们在大多数情况下都是使用TCP/IP协议，但除了TCP/IP 之外还有很多其他类型的协议，这些协议都被分配了不同的以太类型，如0080（十六进制）代表IP协议，网卡驱动就会把这样的包交给TCP/IP协议栈。接下来，协议栈会判断这个包应该交给哪个应用程序，并进行相应的处理。

2.5.11将服务器的响应包从IP传递给TCP

接下来就轮到IP模块先开始工作了，第一步是检查IP头部，确认格式是否正确。如果格式没有问题，下一步就是查看接收方IP地址。如果接收网络包的设备是一台Windows客户端计算机，那么服务器返回的包的接收方IP地址应该与客户端网卡的地址一致，检查确认之后我们就可以接收这个包了。

如果接收方IP地址不是自己的地址，那一定是发生了什么错误。客户端计算机不负责对包进行转发，因此不应该收到不是发给自己的包。当发生这样的错误时，IP模块会通过ICMP消息将错误告知发送方。

ICMP规定了各种类型的消息，如下图所示。当我们遇到这个错误时，IP模块会通过图中的Destinationunreachable消息通知对方。从这张表的内容中我们可以看到在包的接收和转发过程中能够遇到的各种错误。

主要的ICMP消息：

如果接收方IP地址正确，则这个包会被接收下来，这时还需要完成另一项工作。IP协议有一个叫作分片的功能，网线和局域网中只能传输小包，因此需要将大的包切分成多个小包。如果接收到的包是经过分片的，那么IP模块会将它们还原成原始的包。分片的包会在IP头部的标志字段中进行标记，当收到分片的包时，IP模块会将其暂存在内部的内存空间中，然后等待IP头部中具有相同ID的包全部到达，这是因为同一个包的所有分片都具有相同的ID。此外，IP头部还有一个分片偏移量（fragment offset）字段，它表示当前分片在整个包中所处的位置。根据这些信息，在所有分片全部收到之后，就可以将它们还原成原始的包，这个操作叫作分片重组。

到这里，IP模块的工作就结束了，接下来包会被交给TCP模块。TCP模块会根据IP头部中的接收方和发送方IP地址，以及TCP头部中的接收方和发送方端口号来查找对应的套接字。找到对应的套接字之后，就可以根据套接字中记录的通信状态，执行相应的操作了。例如，如果包的内容是应用程序数据，则返回确认接收的包，并将数据放入缓冲区，等待应用程序来读取；如果是建立或断开连接的控制包，则返回相应的响应控制包，并告知应用程序建立和断开连接的操作状态。

2.6UDP协议的收发操作

2.6.1不需要重发的数据用UDP发送更高效

有些应用程序不使用TCP协议，而是使用UDP协议来收发数据。向DNS服务器查询IP地址的时候我们用的也是UDP协议。

为了实现可靠性，我们就需要确认对方是否收到了我们发送的数据，如果没有还需要再发一遍。要实现上面的要求，最简单的方法是数据全部发送完毕之后让接收方返回一个接收确认。这样一来，如果没收到直接全部重新发送一遍就好了，根本不用像TCP一样要管理发送和确认的进度。但是，如果漏掉了一个包就要全部重发一遍，怎么看都很低效。为了实现高效的传输，我们要避免重发已经送达的包，而是只重发那些出错的或者未送达的包。TCP之所以

复杂，就是因为要实现这一点。

不过，在某种情况下，即便没有TCP这样复杂的机制，我们也能够高效地重发数据，这种情况就是数据很短，用一个包就能装得下。如果只有一个包，就不用考虑哪个包未送达了，因为全部重发也只不过是重发一个包而已，这种情况下我们就不需要TCP这样复杂的机制了。而且，如果不使用TCP，也不需要发送那些用来建立和断开连接的控制包了。此外，我们发送了数据，对方一般都会给出回复，只要将回复的数据当作接收确认就行了，也不需要专门的接收确认包了。

2.6.2控制用的短数据

像DNS查询等交换控制信息的操作基本上都可以在一个包的大小范围内解决，这种场景中就可以用UDP来代替TCP。UDP没有TCP的接收确认、窗口等机制，因此在收发数据之前也不需要交换控制信息，也就是说不需要建立和断开连接的步骤，只要在从应用程序获取的数据前面加上UDP头部，然后交给IP进行发送就可以了。接收也很简单，只要根据IP头部中的接收方和发送方IP地址，以及UDP头部中的接收方和发送方端口号，找到相应的套接字并将数据交给相应的应用程序就可以了。除此之外，UDP 协议没有其他功能了，遇到错误或者丢包也一概不管。因为UDP只负责单纯地发送包而已，并不像TCP一样会对包的送达状态进行监控，所以协议栈也不知道有没有发生错误。但这样并不会引发什么问题，因此出错时就收不到来自对方的回复，应用程序会注意到这个问题，并重新发送一遍数据。这样的操作本身并不复杂，也并不会增加应用程序的负担。

UDP头部中的控制信息：

2.6.3音频和视频数据

还有另一个场景会使用UDP，就是发送音频和视频数据的时候。音频和视频数据必须在规定的时间内送达，一旦送达晚了，就会错过播放时机，导致声音和图像卡顿。如果像TCP一样通过接收确认响应来检查错误并重发，重发的过程需要消耗一定的时间，因此重发的数据很可能已经错过了播放的时机。一旦错过播放时机，重发数据也是没有用的，因为声音和图像已经卡顿了，这是无法挽回的。当然，我们可以用高速线路让重发的数据能够在规定的时间内送达，但这样一来可能要增加几倍的带宽才行。

此外，音频和视频数据中缺少了某些包并不会产生严重的问题，只是会产生一些失真或者卡顿而已，一般都是可以接受的。

在这些无需重发数据，或者是重发了也没什么意义的情况下，使用UDP发送数据的效率会更高。