《网络是怎么连接的》读书笔记-第2章 用电信号传输TCP/IP

《网络是怎么连接的》读书笔记

点击这里浏览全书目录。

第2章 用电信号传输TCP/IP——探索协议栈和网卡

2.1 创建套接字

2.1.1 协议栈的内部

操作系统中的网络控制软件（协议栈）和网络硬件（网卡）将浏览器的消息发送给服务器，但是协议栈的工作我们从表面上是看不见的。

协议栈内部分为几个部分，如下图所示：

这张图中的上下关系是有一定规则的，上面的部分会向下面的部分委派工作，下面的部分接受委派的工作并实际执行。当然，这一上下关系只是一个总体的规则，其中也有一部分上下关系不明确，或者上下关系相反的情况，不必过于纠结，只要大体上看出有哪些组成要素就可以了。

上层会向下层逐层委派工作。

上面的部分是网络应用程序，也就是浏览器、电子邮件客户端、Web服务器、电子邮件服务器等程序，
它们会将收发数据等工作委派给下层的部分来完成。当然，除了浏览器之外，其他应用程序在网络上
收发数据的操作也都是类似上面这样的，也就是说，尽管不同的应用程序收发的数据内容不同，但收
发数据的操作是共通的。

应用程序的下面是Socket库，其中包括解析器，解析器用来向DNS服务器发出查询，它的工作过程我
们在第1章已经介绍过了。

再下面就是操作系统内部了，其中包括协议栈。协议栈的上半部分有两块，分别是负责用TCP协议收
发数据的部分和负责用UDP协议收发数据的部分，它们会接受应用程序的委托执行收发数据的操作。

注：

浏览器、邮件等一般应用程序收发数据时用TCP;

DNS查询等收发较短的控制数据时用UDP。

提前了解：

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

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

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

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

协议栈在执行操作时需要参阅这些控制信息。例如，在发送数据时，需要看一看套接字中的通信对象IP地址和端口号，以便向指定的IP地址和端口发送数据。在发送数据之后，需要协议栈能够知道执行发送数据操作后过了多长时间。所以套接字中必须要记录是否已经收到响应，以及发送数据后经过了多长时间，才能根据这些信息按照需要执行重发操作。

注：

协议栈是根据套接字中记录的控制信息来工作的。

在Windows中可以用netstat命令显示套接字内容（上图）。

图中每一行相当于一个套接字，当创建套接字时，就会在这里增加一行新的控制信息，赋予“即将开始通信”的状态，并进行通信的准备工作，如分配用于临时存放收发数据的缓冲区空间。

注：

第8行，它表示PID为4的程序正在使用IP地址为10.10.1.16的网卡与IP地址为10.10.1.18的对象进行通信。此外我们还可以看出，本机使用1031端口，对方使用139端口，而139端口是Windows文件服务器使用的端口，因此我们就能够看出这个套接字是连接到一台文件服务器的。

第1行，这一行表示PID为984的程序正在135端口等待另一方的连接，其中本地IP地址和远程IP地址都是0.0.0.0，这表示通信还没开始，IP地址不确定。

2.1.3 调用socket时的操作

首先是创建套接字的阶段。如下图①所示，应用程序调用socket申请创建套接字，协议栈根据应用程序的申请执行创建套接字的操作。在这个过程中，协议栈首先会分配用于存放一个套接字所需的内存空间。用于记录套接字控制信息的内存空间并不是一开始就存在的，因此我们先要开辟出这样一块空间来。套接字刚刚创建时，数据收发操作还没有开始，因此需要在套接字的内存空间中写入表示这一初始状态的控制信息。到这里，创建套接字的操作就完成了。

按下来需要将表示这个套接字的描述符告知应用程序，描述符相当于用来区分协议栈中的多个套接字的号码牌。

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

注：

计算机内部会同时运行多个程序，如果每个程序都擅自使用内存空间的话，就有可能发生多个程序重复使用同一个内存区域导致数据损坏的问题。为了避免出现这样的问题，操作系统中有一个“内存管理”模块，它相当于内部的管理员，负责根据程序的申请分配相应的内存空间，并确保这些内存空间不会被其他程序使用。因此，分配内存的操作就是向内存管理模块提出申请，请它划分一块内存空间出来。

注：

socket：大写字母开头的Socket表示Socket库，

小写字母开头的socket表示Socket库中名为socket的程序组件。

2.2 连接服务器

2.2.1 连接是什么意思

套接字刚创建完成的时候，里面没有存放任何数据，也不知道通信的对象是谁。这里即使应用程序要求发送数据，协议栈也不是知道应该发送给谁。

浏览器可以根据网址来查询服务器的IP地址，而且根据规则也知道应该使用80端口，但是在调用socket创建套接字时，这些信息并没有传递给协议栈。因此，把服务器的IP地址和端口号等信息告知协议栈是连接操作的目的之一。

服务器程序一般会在系统启动时就创建套接字并等待客户端连接，但服务器上的协议栈和客户端一样，只创建套接字是不知道应该和谁进行通信的。于是客户端需要向服务器告知必要的信息，比如“我想和你开始通信，我的IP地址是xxx.xxx. xxx.xxx，端口号是yyyy“。可见，客户端向服务器传达开始通信的请求，也是连接操作的目的之一。

连接实际上是通信双方交换控制信息，在套接字中记录这些必要信息并准备数据收发的一连串操作，上面提到的客户端将IP地址和端口号告知服务器这样的过程就属于交换控制信息的一个具体的例子。

而除此之外还有其他一些控制信息，连接操作中所交换的控制信息是根据通信规则来确定的，只要根据规则执行连接操作，双方就可以得到必要的信息从而完成数据收发的准备。

此外，当执行数据收发操作时，我们还需要一块用来临时存放要收发的数据的内存空间，这块内存空间称为缓冲区，它也是在连接操作的过程中分配的。上面这些就是“连接”这个词代表的具体含义。

注："连接"这个词的由来

通信技术的历史已经有上百年，在此期间电话技术一直都是主流。而电话的操作过程主要分为三个阶段：（1）拨号与对方连接；（2）通话；（3）挂断。人们将电话的思路套用了在现在的计算机网络中，所以称通信开始之前的操作为“连接”。

因此，如果觉得“连接”这个词听起来有些怪，用“准备”这个词来替换也问题不大。

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

前面说的控制信息大体上可以分为两类。

第一类是客户端和服务器相互联络时交换的控制信息。这些信息不仅连接时需要，包括数据收发和断开连接操作在内，整个通信过程中都需要，这些内容在TCP协议的规格中进行了定义。

具体来说，上中的这些字段就是TCP规格中定义的控制信息。这些字段是固定的，在连接、收发、断开等各个阶段中，每次客户端和服务器之间进行通信时，都需要提供这些控制信息。

如下图（a）所示，这些信息会被添加在客户端与服务器之间传递的网络包的开头。在连接阶段，由于数据收发还没有开始，所以如下图（b）所示，网络包中没有实际的数据，只有控制信息。

这些控制信息位于网络包的开头，因此被称为头部。此外，以太网和IP协议也有自己的控制信息，这些信息也叫头部，为了避免各种不同的头部发生混淆，我们一般会记作TCP头部、以太网头部（MAC头部）、IP头部。

控制信息还有另外一类，那就是保存在套接字中，用来控制协议栈操作的信息。

应用程序传递来的信息以及从通信对象接收到的信息都会保存在这里，还有收发数据操作的执行状态等信息也会保存在这里，协议栈会根据这些信息来执行每一步的操作。

也可以说，套接字的控制信息和协议栈的程序本身其实是一体的，因此，“协议栈具体需要哪些信息”会根据协议栈本身的实现方式不同而不同，但这并没有什么问题。因为协议栈中的控制信息通信对方是看不见的，只要在通信时按照规则将必要的信息写入头部，客户端和服务器之间的通信就能够得以成立。

无论何种操作系统的协议栈都是共通的，通过理解这些重要信息，就能够理解协议栈的工作方式了。

注：

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

（1）头部中记录的信息

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

2.2.3 连接操作的实际过程

该过程从应用程序调用Socket库的connect开始。

connect(<描述符>，<服务器IP地址和端口号>，…)

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

首先，客户端先创建一个包含表示开始数据收发操作的控制信息的头部。如上表所示，头部包含很多字段，
这里要关注的重点是发送方和接收方的端口号。此时客户端（发送方）的套接字就准确找到了服务器（接收
方）的套接字。

然后将头部中的控制位的SYN比特设置为1，可以认为它表示连接。接下来TCP模块会将信息传递给IP模块
并委托它进行发送。

IP模块执行网络包发送操作,网络包通过网络到达服务器，然后服务器上的IP模块将接收到的数据传递给TCP
模块，服务器的TCP模块根据TCP头部中的信息找到端口号对应的套接字，即从处于等待连接状态的套接字
中找到与TCP头部中记录的端口号相同的套接字。并写入相应的信息，将状态改为正在连接。

上述操作完成后，服务器的TCP模块会返回响应，需要在TCP头部中设置发送方和接收方端口号以及SYN比
特（如果由于某些原因不接受连接，则不设置SYN，而将RST设置为1）。此外，在返回响应时还需要将ACK
控制位设为1，这表示已经接收到相应的网络包。这是因为网络中经常会发生错误，网络包也会发生丢失，
因此双方在通信时必须相互确认网络包是否已经送达，而设置ACK比特就是用来进行这一确认的。

接下来，服务器TCP模块会将TCP头部传递给IP模块，并委托IP模块向客户端返回响应。

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

最后，套接字就已经进入随时可以收发数据的状态了，可以认为这时有一根管子把两个套接字连接了起来，我们称这要管子为连接。只要数据传输过程在持续，也就是在调用close断开之前，连接是一直存在的。建立连接之后，协议栈的连接操作就结束了，也就是说connect已经执行完毕，控制流程被交回到应用程序。

注：

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

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

2.3 收发数据

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

数据收发操作是从应用程序调用write将要发送的数据交给协议栈开始的。

协议栈并不关心应用程序传来的数据是什么内容。应用程序在调用write时会指定发送数据的长度，在协议栈看来，要发送的数据就是一定长度的二进制字节序列而已。

协议栈并不是一收到数据就马上发出去，而是会将数据存放在内部的缓冲区中，并等待应用程序的下一段数据。因为程序交给协议栈发送的数据长度是由应用程序本身来决定的，不同的应用程序在实现上有所不同，有些程序会一次性传递所有的数据，而有些程序则会逐字节或者逐行传递数据。

至于要积累多少数据才能发送，不同各类和版本的操作系统会有所不同，要根据以下几个要素来判断。

第一个判断要素是每个网络包能容纳的数据长度，协议栈会根据一个叫作MTU（Maximum Transmission Unit，最大传输单元）的参数来进行判断。它表示一个网络包的最大长度，在以太网中一般是1500字节。MTU是包含头部的总长度，因此需要从MTU减去头部的长度，然后得到的长度就是一个网络包中所能容纳的最大数据长度，这一长度叫作MSS（Maximum Segment Size，最大分段大小）。

注：

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

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

另一个判断要素是时间。当应用程序发送数据的频率不高的时候，如果每次都等到长度接过MSS时再发送，可能会因为等待时间太长而造成发送延迟。为此协议栈的内部有一个计时器，当经过一段时间之后，就会把网络包发出去（这个时间并没有多长，是以毫秒为单位来计算的）。

判断要素就是这两个，但它们其实是互相矛盾的。如果长度优先，那么网络的效率会提高，但可能会因为等待填满缓冲区而产生延迟；相反如果时间优先，那么延迟会变少，但又会降低网络的效率。因此在进行发送操作时需要综合考虑这两个要素以达到平衡。但是实际如何判断是由协议栈的开发者决定的，所以不同种类和版本的操作系统在相关操作上也就存在差异。

所以如果仅靠协议栈来判断发送的时机可能会带来一些问题，因此协议栈也给应用程序保留了一些控制发送时机的余地。比如可以在发送数据时指定“不等待填满缓冲区直接发送”，则协议栈就会按照要求直接发送数据。像浏览器这种会话型的应用程序在发送数据时，如果等待填满缓冲区导致延迟会产生很大影响，因此一般会使用直接发送的选项。

2.3.2 对较大的数据进行拆分

HTTP请求消息一般不会很长，一个网络包就能装得下，但如果其中要提交表单数据，长度就可能超过一个网络包所能容纳的数据量，比如在博客或者论坛上发表一篇长文就属于这种情况。

这种情况下 发送缓冲区中的数据就会超过MSS的长度，这里当时不需要等待后面的数据。发送缓冲区的数据会被以MSS长度为单位进行拆分，拆分出来的每块数据会被放进单独的网络包中。

注：

应用程序的数据一般都比较大，因此TCP会按照网络包的大小对数据进行拆分。

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

虽然网络包已经装好数据并发往服务器，但是此时发送操作还没有结束。

TCP具备确认对方是否成功收到网络包，以及当对方没收到时进行重发的功能 ，因此发送之后还需要进行确认操作。

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

简单来说，发送方说的是“现在发送的是从第××字节开始的部分，一共有××字节哦！”而接收方则回复说，“到第××字节之前的数据我已经都收到了哦！”这个返回ACK号的操作被称为确认响应，通过这样的方式，发送方就能够确认对方到底收到了多少数据。

然后实际上的序号并不是从1开始的，而是需要随机数计算出一个初始值，这是因为如果序号都从1开始，通信过程就会非常容易预测，有人会利用这一点来发动攻击。应该还记得在连接过程中，有一个将SYN控制位设为1并发送给服务器的操作，就是在这一步将序号的初始值告知对方的。实际上，在将SYN设为1的同时，还需要同时设置序号字段的值，而这里的值就代表序号的初始值。

又因为TCP数据收发是双向的，服务器也会向客户端发送数据的，此时只要增加一种左右相反的情形就可以了。如上图所示，首先客户端先计算出一个序号，然后将序号和数据一起发送给服务器，服务器收到之后会计算ACK号并返回给客户端；相反地，服务器也需要先计算出另一个序号，然后将序号和数据一起发送给客户端，客户端收到之后计算ACK号并返回给服务器。此外，如图所示，客户端和服务器双方都需要各自计算序号，因此双方需要在连接过程中互相告知自己计算的序号初始值。

原理讲完之后，来看一下实际的工作流程。

首先，客户端在连接时计算出与从客户端到服务器方向通信的序号初始值，将这个值发送给服务器（上图①）。

然后，服务器会通过这个初始值计算出ACK号并返回给客户端（上图②）。初始值有可能在通信过程中丢失，
因此当服务器收到初始值后需要返回ACK号作为确认。服务器也需要计算出与从服务器到客户端方向通信相
关的序号初始值，并将这个值发送给客户端（上图②）

接下来，客户端也需要根据服务器发来的初始值计算出ACK号并返回给服务器（上图③）。

到这里，序号和ACK号都已经准备完成了，接下来进入数据收发阶段。数据收发操作本身是可以双向同时进
行的，但Web中是先由客户端向服务器发送请求，序号也会跟随数据一起发送（上图④）。然后，服务器收
到数据后再返回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号

如上图（a）所示，每发送一个包就等待一个ACK号的方式，在等待ACK号的这段时间如果什么都不做是在浪费时间。为了减少这样的浪费，TCP采用上图（b）这样的滑动窗口方式来管理数据发送和ACK号的操作。即在发送一个包之后，不等待ACK号返回，而是直接发送后续的一系列包。这样一来，等待ACK号的这段时间就被有效利用起来了。

有一点需要注意，该方式下可能会出现发送包的频率超过接收方处理能力的情况。

​详细解释一下，当接收方的TCP收到包后，会先将数据存放到接收缓冲区中。然后，接收方需要
计算ACK号，将数据块组装起来还原成原本的数据并传递给应用程序，如果这些操作还没完成下
一个包就到了也不用担心，因为下一个包也会被暂存在接收缓冲区中。

​如果数据到达的速率比处理这些数据并传递给应用程序的速率还要快，那么接收缓冲区中的数据
就会越堆越多，最后就会溢出。

​缓冲区溢出之后，后面的数据就进不来了，因此接收方就收不到后面的包了，这就和中途出错的
结果是一样的，也就意味着超出了接收方处理能力。

​解决方案，接收方需要告诉发送方自己最多能接收多少数据，然后发送方根据这个值对数据发送
操作进行控制。

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

实际上，接收方在收到数据之后马上就会开始进行处理，如果接收方的性能高，处理速度比包的到达速率还快，缓冲区马上就会被清空，并通过窗口字段告知发送方。除此之外，上图中只显示了从右往左发送数据的操作，实际上和序号、ACK号一样，发送操作也是双向进行的。

注：

能够接收的最大数据量称为窗口大小，它是TCP调优参数中非常有名的一个。

2.3.6 ACK与窗口的合并

返回ACK号和更新窗口的时机，这两个参数可以是相互独立的，但是这样肯定会影响到收发效率。

什么时候需要更新窗口大小呢？

当收到的数据刚刚开始填入缓冲区时，其实没必要每次都向发送方更新窗口大小，因为只要发送方在每次发送数据时减掉已发送的数据长度就可以自行计算出当前窗口的剩余长度。

因此，更新窗口大小的时机应该是接收方从缓冲区中取出数据传递给应用程序的时候。这个操作是接收方应用程序发出请求时才会进行的，而发送方不知道什么时候会进行这样的操作，因此当接收方将数据传递给应用程序，导致接收缓冲区剩余容量增加时，就需要告知发送方，这就是更新窗口大小的时机。

什么时候返回ACK号？

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

结合前面两个因素结合看，发送方的数据到达接收方，在接收操作完成之后就需要向发送方返回ACK号，而再经过一段时间（很短，微秒级），当数据传递给应用程序之后才需要更新窗口大小。但如果根据这样的设计来实现，每收到一个包，就需要向发送方分别发送ACK号和窗口更新这两个单独的包。这样一来，接收方发给发送方的包就太多了，导致网络效率下降。

因此，接收方在发送ACK号和窗口更新时，并不会马上把包发送出去，而是会等待一段时间，在这个过程中很有可能会出现其他的通知操作，这样就可以把两种通知合并在一个包里面发送了。

当需要连续发送多个ACK号时，也可以减少包的数量，这是因为ACK号表示的是已收到的数据量，也就是说，它是告诉发送方目前已接收的数据的最后位置在哪里，因此当需要连续发送ACK号时，只要发送最后一个ACK号就可以了。

当需要连续发送多个窗口更新时也可以减少包的数量，因为连续发生窗口更新说明应用程序连续请求了数据，接收缓冲区的剩余空间连续增加。这种情况和ACK号一样，可以省略中间过程，只要发送最终的结果就可以了。

2.3.7 接收HTTP响应消息

发送HTTP请求消息后，接下来还需要等待Web服务器返回响应消息，这一操作也需要协议栈的参与。

浏览器在委托协议栈发送请求消息之后，会调用read程序来获取响应消息。控制流程会通过read转移到协议栈，然后协议栈会执行接下来的操作。

和发送数据一样，接收数据也需要将数据暂存到接收缓冲区中，这里的操作过程如下。首先，协议栈会检查收到的数据块和TCP头部的内容，判断是否有数据丢失，如果没有问题则返回ACK号。然后，协议栈将数据块暂存到接收缓冲区中，并将数据块按顺序连接起来还原出原始的数据，最后将数据交给应用程序。具体来说，协议栈会将接收到的数据复制到应用程序指定的内存地址中，然后将控制流程交回应用程序。

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

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

收发数据结束的时间点应该是应用程序判断所有数据都已经发送完毕的时候。这时，数据发送完毕的一方会发起断开过程，但不同的应用程序会选择不同的断开时机。可能也有一些程序是客户端发送完数据就结束了，不用等服务器响应，这时客户端会先发起断开过程。这一判断是应用程序作出的，协议栈在设计上允许任何一方先发起断开过程。

无论哪种情况，完成数据发送的一方会发起断开过程。

举例服务器断开

首先服务器一方的应用程序会调用Socket库的close程序。

然后，服务器的协议栈会生成包含断开信息的TCP头部，具体来说就是将控制位中的FIN比特设为1。接下来，协议栈
会委托IP模块向客户端发送数据（上图①）。同时，服务器的套接字中也会记录下断开操作的相关信息。

当收到服务器发来的FIN为1的TCP头部时，客户端的协议栈会将自己的套接字标记为进入断开操作状态。

然后，为了告知服务器已收到FIN为1的包，客户端会向服务器返回一个ACK号（上图②）。这些操作完成后，协议栈
就可以等待应用程序来取数据了。

应用程序就会调用read来读取数据。这时，协议栈不会向应用程序传递数据，而是会告知应用程序（浏览器）来自服
务器的数据已经全部收到了。客户端应用程序会调用close来结束数据收发操作，这时客户端的协议栈也会和服务器
一样，生成一个FIN比特为1的TCP包，然后委托IP模块发送给服务器（上图③）。一段时间之后，服务器就会返回
ACK号（上图④）。到这里，客户端和服务器的通信就全部结束了。

2.4.2 删除套接字

和服务器的通信结束之后，用来通信的套接字也就不会再使用了，但是它会等待一段时间之后才被删除。

等待这段时间是为了防止误操作，引发误操作的原因有很多，这里无法全部列举，下面来举一个最容易理解的例子。假设和图2.12的过程相反，客户端先发起断开，则断开的操作顺序如下。

（1）客户端发送FIN

（2）服务器返回ACK号

（3）服务器发送FIN

（4）客户端返回ACK号

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

注：

协议中对于这个等待时间没有明确的规定，一般来说会等待几分钟之后再删除套接字。

2.4.3 数据收发操作小结

1. 创建套接字

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

2. 客户端发起连接操作

客户端会生成一个SYN为1的TCP包并发送给服务器（上图①）。这个TCP包的头部还包含了客户端向服务器发送数据时使用的初始序号，以及服务器向客户端发送数据时需要用到的窗口大小。当这个包到达服务器之后，服务器会返回一个SYN为1的TCP包（上图②）。和上图①一样，这个包的头部中也包含了序号和窗口大小，此外还包含表示确认已收到包①的ACK号。当这个包到达客户端时，客户端会向服务器返回一个包含表示确认的ACK号的TCP包（上图③）。

3. 客户端发送请求消息，服务器给出响应

TCP会将请求消息切分成一定大小的块，并在每一块前面加上TCP头部，然后发送给服务器（上图④）。TCP头部中包含序号，它表示当前发送的是第几个字节的数据。当服务器收到数据时，会向客户端返回ACK号（上图⑤）。在最初的阶段，服务器只是不断接收数据，随着数据收发的进行，数据不断传递给应用程序，接收缓冲区就会被逐步释放。这时，服务器需要将新的窗口大小告知客户端。当服务器收到客户端的请求消息后，会向客户端返回响应消息，这个过程和刚才的过程正好相反（上图⑥⑦）。

4. 执行断开操作

此处以服务器会先发起断开过程为例。在这个过程中，服务器先发送一个FIN为1的TCP包（上图⑧），然后客户端返回一个表示确认收到的ACK号（上图⑨）。接下来，双方还会交换一组方向相反的FIN为1的TCP包（上图⑩）和包含ACK号的TCP包（上图⑪）。最后，在等待一段时间后，套接字会被删除。

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

2.5.1 包的基本知识

本节讲解IP模块如何将包发送给对方。

如上图所示，包是由头部和数据两部分构成的。

头部包含目的地址等控制信息，可以理解为快递包裹的面单；头部后面就是委托方要发送给对方的数据，也就相当于快递包裹里的货物。一个包发往目的地的过程如下图所示。

首先，发送方的网络设备会负责创建包，即生成含有正确控制信息的头部，然后再附加上要发送的数据。

接下来，包会被发往最近的网络转发设备。

当到达最近的转发设备之后，转发设备会根据头部中的信息判断接下来应该发往哪里。这个过程需要用到
一张表，这张表里面记录了每一个地址对应的发送方向，也就是按照头部里记录的目的地址在表里进行查
询，并根据查到的信息判断接下来应该发往哪个方向。经过多个转发设备的接力之后，包最终就会到达接
收方的网络设备。

注：

发送方向接收方发送一个包，接收方可能也会向发送方返回一个包，此时的发送方到了接下来的某个时刻就会变成接收方。因此，我们不需要把发送方和接收方明确区分开来，在这里我们把发送方和接收方统称为终端节点，相应地转发设备被称为转发节点或者中间节点。

前面介绍的这些基本知识对于各种通信方式都是适用的，不过TCP/IP包的结构是在这个基本结构的基础上扩展出来的。网络中有路由器和集线器两种不同的转发设备，它们在传输网络包时有着各自的分工。

此处是重点，此处是重点，此处是重点。

（1）路由器根据目标地址判断下一个路由器的位置
（2）集线器在子网中将网络包传输到下一个路由

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

（1）IP协议根据目标地址判断下一个IP转发设备的位置
（2）子网中的以太网协议将包传输到下一个转发设备

如上图所示，TCP/IP包包含如下两个头部。
（a）MAC头部（用于以太网协议）
（b）IP头部（用于IP协议）

首先，发送方将包的目的地，也就是要访问的服务器的IP地址写入IP头部中。IP协议根据这一地址查找包的传输方向，从而找到下一个路由器的位置，也就是下图中的路由器R1，然后IP协议会查找路由器R1的以太网地址（MAC地址），并将这个地址写入MAC头部中。接下来，IP协议会委托以太网协议将包传输过去。这样一来以太网协议就知道要将这个包发到哪一个路由器上了。

网络包在传输过程中（下图①）会经过集线器，集线器是根据以太网协议工作的设备。为了判断包接下来应该向什么地方传输，集线器里有一张表（用于以太网协议的表），可以根据以太网头部中记录的目的地信息查出相应的传输方向。下图中只有一个集线器，当存在多个集线器时，网络包会按顺序逐一通过这些集线器进行传输。

接下来包会到下一个路由器（下图②）。路由器中有一张IP协议的表，可以根据这张表以及IP头部中记录的目的地信息查出接下来应该发往哪个路由器。除此之外还需要查出下一个路由器的MAC地址，并记录到MAC头部中（收到包的时候MAC头部会被舍弃，当再次发送的时候又会加上包含新MAC地址的新MAC头部）。

再往后网络包会通过路由器到达下一个路由器R2。这个过程不断重复，最终网络包就会被送到目的地，当目的地设备成功接收之后，网络包的传输过程就结束了。

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

2.5.2 包收发操作概览

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

包收发操作的起点是TCP模块委托IP模块发送包的操作（下图中的“①发送”）。这个委托过程就是TCP模块在数据块前面加上TCP头部，然后整个传递给IP模块，这部分就是网络包的内容。与此同时，TCP模块还需要指定通信对象的IP地址，也就是需要写清楚“将什么内容发送给谁”。

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

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

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

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

接下来，封装好的包会被交给网络硬件（上图中的“②发送”），例如以太网、无线局域网等。不同形态的硬件名字不一样，本书将它们统称为网卡。传递给网卡的网络包是由一连串0和1组成的数字信息，网卡会将这些数字信息转换为电信号或光信号，并通过网线（或光纤）发送出去，然后这些信号就会到达集线器、路由器等转发设备，再由转发设备一步一步地送达接收方。

包送达对方之后，对方会作出响应，然后我们需要接收这个包。接收的过程和发送的过程是相反的，信息先以电信号的形式从网线传输进来，然后由网卡将其转换为数字信息并传递给IP模块（上图中的“③接收”）。接下来，IP模块会将MAC头部和IP头部后面的内容，也就是TCP头部加上数据块，传递给TCP模块。接下来的操作就是TCP模块负责的部分了。

TCP模块在收发数据时会分为好几个阶段，并为各个阶段设计了实现相应功能的网络包，但IP的包收发操作都是相同的，因为IP模块会将TCP头部和数据块看作一整块二进制数据，在执行收发操作时并不关心其中的内容。总之，IP的职责就是将委托的东西打包送到对方手里，或者是将对方送来的包接收下来。

注：

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

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

IP模块接受TCP模块的委托负责包的收发工作，它会生成IP头部并附加在TCP头部前面。

IP头部包含的内容如下表所示，其中最重要的内容就是IP地址，它表示这个包应该发到哪里去。

这个地址是由TCP模块告知的，而TCP又是在执行连接操作时从应用程序那里获得这个地址的，因此这个地址的最初来源就是应用程序。

注：

IP头部的“接收方IP地址”填写通信对象的IP地址。

发送方IP地址需要判断发送方所使用的网卡，并填写该网卡的IP地址。

把包应该交给哪块网卡呢？

因为协议栈的IP模块与路由器中负责包收发的部分都是根据IP协议规则来进行包收发操作的，所以它们也都用相同的方法来判断把包发送给谁。

这个“IP表”叫作路由表，如下图所示，我们可以通过route print命令来显示路由表。首先，我们对套接字中记录的目的地IP地址与路由表左侧的Network Destination栏进行比较，找到对应的一行。例如，TCP模块告知的目标IP地址为192.168.1.21，那么就对应图2.18中的第6行，因为它和192.168.1的部分相匹配。右起第2列Interface列，表示网卡等网络接口，这些网络接口可以将包发送给通信对象。右起第3列Gateway列表示下一个路由器的IP地址，将包发给这个IP地址，该地址对应的路由器（Gateway在TCP/IP的世界里就是路由器的意思）就会将包转发到目标地址。路由表的第1行中，目标地址和子网掩码都是0.0.0.0，这表示默认网关，如果其他所有条目都无法匹配，就会自动匹配这一行。

如此可以判断出应该使用哪块网卡来发送包了，然后就可以在IP头部的发送方IP地址中填上这块网卡对应的IP地址。

接下来还需要填写协议号，它表示包的内容是来自哪个模块的。例如，如果是TCP模块委托的内容，则设置为06（十六进制），如果是UDP模块委托的内容，则设置为17（十六进制），这些值都是按照规则来设置的。其他字段内也需要填写相应的值，后面会讲。

2.5.4 生成以太网用的MAC头部

IP头部中的接收方IP地址表示网络包的目的地，通过这个地址我们就可以判断要将包发到哪里，但以太网在判断网络包目的地时和TCP/IP的方式不同，因此必须采用相匹配的方式才能在以太网中将包发往目的地，而MAC头部就是干这个用的，它包含了接收方和发送方的MAC地址等信息。

MAC头部的开头是接收方和发送方的MAC地址，大家可以认为它们和IP头部中的接收方和发送方IP地址的功能差不多，只不过IP地址的长度为32比特，而MAC地址为48比特。第3个以太类型字段和IP头部中的协议号类似。在IP中，协议号表示IP头部后面的包内容的类型；而在以太网中，我们可以认为以太网类型后面就是以太网包的内容，而以太类型就表示后面内容的类型。以太网包的内容可以是IP、ARP等协议的包，它们都有对应的值，这也是根据规则来确定的。

在生成MAC头部时，只要设置上表的3个字段就可以了。

（1）以太类型：这里填写表示IP协议的值0800（十六进制）。

（2）发送方MAC地址：这里填写网卡本身的MAC地址。MAC地址是在网卡生产时写入ROM里的，只要将这个值读取出来写入MAC头部即可。

（3）查路由表获取Gateway列中的IP地址，但是需要根据IP地址查询MAC地址。

注：

实际上，只有在操作系统启动过程中对网卡进行初始化的时候才会读取MAC地址，读取出来之后会存放在内存中，每次执行收发操作时实际上使用的是内存中的值。此外，读取MAC地址的操作是由网卡驱动程序来完成的，因此网卡驱动程序也可以不从网卡ROM中读取地址，而是将配置文件中设定的MAC地址拿出来放到内存中并用于设定MAC头部，或者也可以通过命令输入MAC地址。

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

ARP（Address Resolution Protocol，地址解析协议）其实非常简单。

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

如果对方和自己处于同一个子网中，那么通过上面的操作就可以得到对方的MAC地址。然后我们将这个MAC地址写入MAC头部，MAC头部就完成了。

如果路由表的设置正确，那么对方应该在同一子网，否则对方无法作出ARP响应，这里只能认为对方不存在，包的发送操作就会失败。

如果每次发送包都要这样查询一次，网络中就会增加很多ARP包，因此我们会将查询结果放到一块叫作ARP缓存的内存空间中留着以后用。当ARP缓存中不存在对方MAC地址时才发送ARP查询。显示ARP缓存的方法和MAC地址的写法如下面两张图所示。

总是使用ARP缓存中保存的地址也会产生问题，如果IP地址发生变化时，ARP缓存的内容就会和现实发生差异。为了防止这种问题的发生，ARP缓存中的值在经过一段时间后会被删除，一般这个时间在几分钟左右。这个删除的操作非常简单粗暴，不管ARP缓存中的内容是否有效，只要经过几分钟就全部删掉，当地址从ARP缓存中删除后，只要重新执行一次ARP查询就可以再次获得地址了。

但是当IP地址刚刚发生改变的时候，ARP缓存中依然会保留老的地址，这里通信就会发生异常，可以查看ARP缓存的内容，并手动删除过时的条目。

注：

查询MAC地址需要使用ARP。

到这里为止，整个打包的工作是由IP模块负责的。在交给网卡之前，IP模块能够完成整个打包工作，那么网卡只要将打好的包发送出去就即可。对于除IP以外的其他类型的包也是一样，如果在交给网卡之前完成打包，那么对于网卡来说，发送的操作和发送IP包是完全相同的。与其机械地设计模块和设备之间的分工，导致网卡只能支持IP包，不如将分工设计得现实一些，让网卡能够灵活支持各种类型的包。

2.5.6 以太网的基本知识

以太网是一种为多台计算机能够彼此自由和廉价地相互通信而设计的通信技术，它的原型如下图（a）所示。这种网络的本质其实就是一根网线，当一台计算机发送信号时，信号就会通过网线流过整个网络，最终到达所有的设备。MAC头部的设置的接收者地址与接收者的地址匹配的设备就接收这个包，其他的设备则丢弃这个包。

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

后来，下图（c）这样的使用交换式集线器（即交换机）的结构普及开来，现在我们说的以太网指的都是这样的结构。这个结构看上去和（b）很像，但其实里面有一个重要的变化，即信号会发送给所有设备这一性质变了，现在信号只会流到根据MAC地址指定的设备。当然，根据MAC地址来传输包这一点并没有变，因此MAC头部的设计也得以保留。

尽管以太网经历了数次变迁，但其基本的3个性质至今仍未改变。

1. 将包发送到MAC头部的接收方MAC地址代表的目的地。
2. 用发送方MAC地址识别发送方。
3. 用以太类型识别包的内容。

注：

以太网和IP一样，并不关心网络包的实际内容，因此以太网的收发操作也和TCP的工作阶段无关。

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

IP生成的网络包只是存放在内存中的一串数字信息，没有办法直接发送给对方。因此需要将数字信息转换为电或光信号，才能在网线上传输，这才是真正的数据发送过程。

网卡并不是通上电之后就可以马上开始工作的，而是和其他硬件一样，都需要进行初始化。

打开计算机启动操作系统的时候，网卡驱动程序会对硬件进行初始化操作，然后硬件才进入可以使用的状态。这些操作包括硬件错误检查、初始设置等步骤，这些步骤对于很多其他硬件也是共通的，但也有一些操作是以太网特有的，那就是在控制以太网收发操作的MAC模块中设置MAC地址。

网卡的ROM中保存着全世界唯一的MAC地址，这是在生产网卡时写入的，将这个值读出之后就可以对MAC模块进行设置。也可以从命令或者配置文件中读取MAC地址并分配给MAC模块，此时网卡会忽略ROM中的MAC地址。网卡通电之后，ROM中的MAC地址并没有自动生效，真正生效的是网卡驱动进行初始化时在MAC模块中设置的那个MAC地址。在操作系统启动并完成这些初始化操作之后，网卡就可以等待来自IP的委托了。

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

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

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

网卡驱动从IP模块获取包之后，会将其复制到网卡内的缓冲区中，然后向MAC模块发送发送包的命令。

MAC模块会将包从缓冲区中取出，并在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列，如下图所示。

注：

MAC头部很容易被误解为是由网卡来处理的，实际上它是由TCP/IP软件来负责的。

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

用电信号来表达数字信息时，我们需要让0和1两种比特分别对应特定的电压和电流，如下图（a）这样的电信号就可以表达数字信息。通过电信号来读取数据的过程就是将这种对应关系颠倒过来。

但是实际的信号并不像下图所示的那样有分隔每个比特的辅助线，因此在测量电压和电流时必须先判断出每个比特的界限在哪里。当1和0连续出现的信号，由于电压和电流没有变化，我们就没办法判断出其中每个比特到底应该从哪里去切分。要解决这个问题，最简单的方法就是在数据信号之外再发送一组用来区分比特间隔的时钟信号。如下图（b）所示，当时钟信号从下往上变化时读取电压和电流的值，然后和0或1进行对应就可以了。

但是当距离较远，网线较长时，两条线路的长度会发生差异，数据信号和时钟信号的传输会产生时间差，时钟就会发生偏移。要解决这个问题，可以采用将数据信号和时钟信号叠加在一起的方法。这样的信号如下图（c）所示，发送方将这样的信号发给接收方。只要根据时钟信号（b）的变化周期，可以从数据信号（a）中读取相应的电压和电流值，并将其还原为0或1的比特。

报头是一串像10101010…这样1和0交替出现的比特序列，长度为56比特，它的作用是确定包的读取时机。当这些1010的比特序列被转换成电信号后，会形成如下图这样的波形。接收方在收到信号时，遇到这样的波形就可以判断读取数据的时机。

对信号进行一段时间的观察，才可以找到其变化的周期。所以不能一开始就发送包的数据，而是要在前面加上一段用来测量时钟信号的特殊信号，这就是报头的作用。

报头后面的起始帧分界符在上图中也已经画出来了，它的末尾比特排列有少许变化。接收方以这一变化作为标记，从这里开始提取网络包数据。

注：

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

末尾的FCS（帧校验序列）用来检查包传输过程中因噪声导致的波形紊乱、数据错误，它是一串32比特的序列，是通过一个公式对包中从头到尾的所有内容进行计算而得出来的。

在包传输过程中，如果受到噪声的干扰而导致其中的数据发生了变化，那么接收方计算出的FCS和发送方计算出的FCS就会不同，这样我们就可以判断出数据有没有错误。

2.5.9 向集线器发送网络包

加上报头、起始帧分界符和FCS之后，下一步就是将包通过网线发送出去了（下图）。发送信号的操作分为两种，一种是使用集线器的半双工模式，另一种是使用交换机的全双工模式。

注：

发送和接收同时并行的方式叫作“全双工”；

某一时刻只能进行发送或接收其中一种操作叫作“半双工”。

在半双工模式中，为了避免信号碰撞，首先要判断网线中是否存在其他设备发送的信号。如果有，则需要等待该信号传输完毕，因为如果在有信号时再发送一组信号，两组信号就会发生碰撞。

首先，MAC模块从报头开始将数字信息按每个比特转换成电信号，然后由PHY，或者叫MAU的信号收发模块发送出去。在这里，将数字信息转换为电信号的速率就是网络的传输速率，例如每秒将10 Mbit的数字信息转换为电信号发送出去，则速率就是10 Mbit/s。

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

注：

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

注：

全双工模式中不需要像半双工模式这样考虑这么多复杂的问题，即便接收线路中有信号进来，也可以直接发送信号。

2.5.10 接收返回包

在使用集线器的半双工模式以太网中，一台设备发送的信号会到达连接在集线器上的所有设备，这意味着无论是不是发给自己的信号都会通过接收线路传进来。

信号的开头是报头，通过报头的波形同步时钟，然后遇到起始帧分界符时开始将后面的信号转换成数字信息。
这个操作和发送时是相反的，即PHY（MAU）模块先开始工作，然后再轮到MAC模块。

PHY （MAU）模块会将信号转换成通用格式并发送给MAC模块，MAC模块再从头开始将信号转换为数字信息，
并存放到缓冲区中。

当到达信号的末尾时，还需要检查FCS。就是将计算出的FCS和包末尾的FCS进行对比，如果中途受到噪声干
扰而导致波形发生紊乱，则两者的值会产生差异，这时这个包就会被当作错误包而被丢弃。

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

注：

通知计算机的操作会使用一个叫作中断的机制。在网卡执行接收包的操作的过程中，计算机并不是一直监控着网卡的活动，而是去继续执行其他的任务。

因此如果网卡不通知计算机，计算机是不知道包已经收到了这件事的。

在这种情况下，需要一种机制能够打断计算机正在执行的任务，让计算机注意到网卡中发生的事情，这种机制就是中断。

网卡驱动被中断处理程序调用后，会从网卡的缓冲区中取出收到的包，并通过MAC头部中的以太类型字段判断协议的类型。不同的协议被分配了不同的以太类型，如0080（十六进制）代表IP协议，网卡驱动就会把这样的包交给TCP/IP协议栈。

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

服务器返回的包的以太类型应该是0800，因此网卡驱动会将其交给TCP/IP协议栈来进行处理。

IP模块先开始工作，第一步是检查IP头部，确认格式和接收方IP地址。

如果接收方IP地址不是自己的地址，IP模块会通过ICMP消息将错误告知发送方。客户端计算机不负责对包进行转发，因此不应该收到不是发给自己的包。ICMP规定了各种类型的消息，如下表所示。当我们遇到这个错误时，IP模块会通过表中的Destination unreachable消息通知对方。

如果接收方IP地址正确，则这个包会被接收下来，这时还需要完成另一项工作。

IP协议有一个叫作分片的功能，网线和局域网中只能传输小包，因此需要将大的包切分成多个小包，同理接收包时IP模块会将它们还原成原始的包。

分片的包会在IP头部的标志字段中进行标记，当收到分片的包时，IP模块会将其暂存在内部的内存空间中，然后等待IP头部中具有相同ID的包全部到达，这是因为同一个包的所有分片都具有相同的ID。IP头部还有一个分片偏移量（fragment offset）字段，它表示当前分片在整个包中所处的位置，在所有分片全部收到之后将它们还原成原始包，这个操作叫作分片重组。

接下来包会被交给TCP模块。TCP模块会根据IP头部中的接收方和发送方IP地址，以及TCP头部中的接收方和发送方端口号来查找对应的套接字，就可以根据套接字中记录的通信状态执行相应的操作了。

注：

（1）如果包的内容是应用程序数据，返回确认接收的包并将数据放入缓冲区，等待应用程序来读取；

（2）如果是建立或断开连接的控制包，则返回相应的响应控制包，并告知应用程序操作状态。

2.6 UDP协议的收发操作

2.6.1 不需要生性的数据用UDP更高效

TCP将数据高效且可靠地发送给对方，需要确认对方是否收到了我们发送的数据，如果没有还需要再发一遍。为了实现高效的传输，我们要避免重发已经送达的包，而是只重发那些出错的或者未送达的包。TCP之所以复杂，就是因为要实现这一点。而UDP则没有这些繁琐的东西。

2.6.2 控制用的短数据

UDP没有TCP的接收确认、窗口等机制，因此在收发数据之前也不需要交换控制信息，也就是说不需要建立和断开连接的步骤，只要在从应用程序获取的数据前面加上UDP头部，然后交给IP进行发送就可以了（下表）。接收也很简单，只要根据IP头部中的接收方和发送方IP地址，以及UDP头部中的接收方和发送方端口号，找到相应的套接字并将数据交给相应的应用程序就可以了。除此之外，UDP协议没有其他功能了，遇到错误或者丢包也一概不管。

2.6.3 音频和视频

还有另一个场景会使用UDP，就是发送音频和视频数据的时候。音频和视频数据必须在规定的时间内送达，一旦送达晚了，就会错过播放时机，导致声音和图像卡顿。如果像TCP一样通过接收确认响应来检查错误并重发，重发的过程需要消耗一定的时间，因此重发的数据很可能已经错过了播放的时机。