【计算机网络—概述】协议栈和网卡

我们将探索操作系统中的网络控制软件（协议栈）和网络硬件（网卡）是如何将浏览器的消息发送给服务器的。

创建套接字

协议栈的内部结构

和浏览器不同的是，协议栈的工作我们从表面上是看不见的，可能比较难以想象。因此，在实际探索之前，我们先来对协议栈做个解剖，看看里面到底有些什么。

协议栈的内部如图所示，分为几个部分，分别承担不同的功能。这张图中的上下关系是有一定规则的，上面的部分会向下面的部分委派工作，下面的部分接受委派的工作并实际执行，这一点大家在看图时可以参考一下。当然，这一上下关系只是一个总体的规则，其中也有一部分上下关系不明确，或者上下关系相反的情况，所以也不必过于纠结。

上层会向下层逐层委派工作。图中最上面的部分是网络应用程序，也就是浏览器、电子邮件客户端、Web服务器、电子邮件服务器等程序，它们会将收发数据等工作委派给下层的部分来完成。应用程序的下面是Socket库，其中包括解析器，解析器用来向DNS服务器发出查询。再下面就是操作系统内部了，其中包括协议栈。协议栈的上半部分有两块，分别是负责用TCP协议收发数据的部分和负责用UDP协议收发数据的部分，它们会接受应用程序的委托执行收发数据的操作。像浏览器、邮件等一般的应用程序都是使用TCP收发数据的，而像DNS查询等收发较短的控制数据的时候则使用UDP。

下面一半是用IP协议控制网络包收发操作的部分。在互联网上传送数据时，数据会被切分成一个一个的网络包，而将网络包发送给通信对象的操作就是由IP协议来负责的。IP下面的网卡驱动程序负责控制网卡硬件，而最下面的网卡则负责完成实际的收发操作，也就是对网线中的信号执行发送和接收的操作。

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

我们已经了解了协议栈的内部结构，而对于在数据收发中扮演关键角色的套接字，让我们来看一看它具体是个怎样的东西。

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

套接字中记录了用于控制通信操作的各种控制信息，协议栈则需要根据这些信息判断下一步的行动，这就是套接字的作用。

在Windows中可以用netstat命令显示套接字内容，图中每一行相当于一个套接字。

比如第8行，它表示PID为4的程序正在使用IP地址为10.10.1.16的网卡与IP地址为10.10.1.80的对象进行通信。此外我们还可以看出，本机使用1031端口，对方使用139端口。我们再来看第1行，这一行表示PID为984的程序正在135端口等待另一方的连接，其中本地IP地址和远程IP地址都是0.0.0.0，这表示通信还没开始，IP地址不确定。

调用socket时的操作

我们的探索之旅将继续前进，看一看当浏览器调用socket、connect等Socket库中的函数时，协议栈内部是如何工作的。

首先是创建套接字的阶段。应用程序调用socket申请创建套接字，协议栈根据应用程序的申请执行创建套接字的操作。

在这个过程中，协议栈首先会分配用于存放一个套接字所需的内存空间。套接字刚刚创建时，数据收发操作还没有开始，因此需要在套接字的内存空间中写入表示这一初始状态的控制信息。到这里，创建套接字的操作就完成了。

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

连接服务器

创建套接字之后，应用程序（浏览器）就会调用connect，随后协议栈会将本地的套接字与服务器的套接字进行连接。

连接是什么意思

那么这里的“连接”到底是什么意思呢？一句话概括的话，连接实际上是通信双方交换控制信息，在套接字中记录这些必要信息并准备数据收发的一连串操作。

套接字刚刚创建完成的时候，里面并没有存放任何数据，也不知道通信的对象是谁。因此，我们需要把服务器的IP地址和端口号等信息告知协议栈，这是连接操作的目的之一。

那么，服务器这边又是怎样的情况呢？服务器上也会创建套接字，但服务器上的协议栈和客户端一样，只创建套接字是不知道应该和谁进行通信的。而且，和客户端不同的是，在服务器上，连应用程序也不知道通信对象是谁。于是，我们需要让客户端向服务器告知必要的信息。可见，客户端向服务器传达开始通信的请求，也是连接操作的目的之一。

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

负责保存控制信息的头部

关于控制信息，这里再补充一些。之前我们说的控制信息其实可以大体上分为两类。

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

这些字段是固定的，在连接、收发、断开等各个阶段中，每次客户端和服务器之间进行通信时，都需要提供这些控制信息。具体来说，如图（a）所示，这些信息会被添加在客户端与服务器之间传递的网络包的开头。在连接阶段，由于数据收发还没有开始，所以如图（b）所示，网络包中没有实际的数据，只有控制信息。这些控制信息位于网络包的开头，因此被称为头部。

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

连接操作的实际过程

连接操作的第一步是客户端的TCP模块创建表示连接控制信息的头部，通过TCP头部中的发送方和接收方端口号可以找到要连接的套接字。然后，我们将头部中的控制位的SYN比特设置为1，目前大家可以认为它是表示连接。此外还需要设置适当的序号和窗口大小。

当TCP头部创建好之后，接下来TCP模块会将信息传递给IP模块并委托它进行发送。IP模块执行网络包发送操作后，网络包就会通过网络到达服务器，然后服务器上的IP模块会将接收到的数据传递给TCP模块，服务器的TCP模块根据TCP头部中的信息找到端口号对应的套接字。也就是说，从处于等待连接状态的套接字中找到与TCP头部中记录的接收方端口号相同的套接字就可以了。当找到对应的套接字之后，套接字中会写入相应的信息，并将状态改为正在连接。

上述操作完成后，服务器的TCP模块会返回响应，这个过程和客户端一样，需要在TCP头部中设置发送方和接收方端口号以及SYN比特。此外，在返回响应时还需要将ACK控制位设为1，这表示已经接收到相应的网络包。接下来，服务器TCP模块会将TCP头部传递给IP模块，并委托IP模块向客户端返回响应。

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

收发数据

当控制流程从connect回到应用程序之后，接下来就进入数据收发阶段了。

将HTTP请求消息交给协议栈

数据收发操作是从应用程序调用write将要发送的数据交给协议栈开始的，协议栈收到数据后执行发送操作。应用程序在调用write时会指定发送数据的长度，在协议栈看来，要发送的数据就是一定长度的二进制字节序列而已。

协议栈并不是一收到数据就马上发送出去，而是会将数据存放在内部的发送缓冲区中，并等待应用程序的下一段数据。一次将多少数据交给协议栈是由应用程序自行决定的，协议栈并不能控制这一行为。在这样的情况下，如果一收到数据就马上发送出去，就可能会发送大量的小包，导致网络效率下降，因此需要在数据积累到一定量时再发送出去。至于要积累多少数据才能发送，不同种类和版本的操作系统会有所不同，不能一概而论，但都是根据下面几个要素来判断的。

第一个判断要素是每个网络包能容纳的数据长度，协议栈会根据一个叫作MTU的参数来进行判断。MTU表示一个网络包的最大长度，在以太网中一般是1500字节。MTU是包含头部的总长度，因此需要从MTU减去头部的长度，然后得到的长度就是一个网络包中所能容纳的最大数据长度，这一长度叫作MSS。当从应用程序收到的数据长度超过或者接近MSS时再发送出去，就可以避免发送大量小包的问题了。

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

判断要素就是这两个，但它们其实是互相矛盾的。如果长度优先，那么网络的效率会提高，但可能会因为等待填满缓冲区而产生延迟；相反地，如果时间优先，那么延迟时间会变少，但又会降低网络的效率。因此，在进行发送操作时需要综合考虑这两个要素以达到平衡。

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

对较大的数据进行拆分

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

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

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

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

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

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

然而，图中的例子和实际情况还是有些出入的。在实际的通信中，序号并不是从1开始的，而是需要用随机数计算出一个初始值，因此需要在开始收发数据之前将初始值告知通信对象。大家应该还记得在我们刚才讲过的连接过程中，有一个将SYN控制位设为1并发送给服务器的操作，就是在这一步将序号的初始值告知对方的。实际上，在将SYN设为1的同时，还需要同时设置序号字段的值，而这里的值就代表序号的初始值。

TCP数据收发是双向的，在客户端向服务器发送数据的同时，服务器也会向客户端发送数据，过程也类似。

我们来总结一下实际的工作过程，如下图。首先，客户端在连接时需要计算出与从客户端到服务器方向通信相关的序号初始值，并将这个值发送给服务器。接下来，服务器会通过这个初始值计算出ACK号并返回给客户端。同时，服务器也需要计算出与从服务器到客户端方向通信相关的序号初始值，并将这个值发送给客户端。接下来像刚才一样，客户端也需要根据服务器发来的初始值计算出ACK号并返回给服务器。到这里，序号和ACK号都已经准备完成了，接下来就可以进入数据收发阶段了。数据收发操作本身是可以双向同时进行的，但Web中是先由客户端向服务器发送请求，序号也会跟随数据一起发送。然后，服务器收到数据后再返回ACK号。从服务器向客户端发送数据的过程则正好相反。

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

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

前面说的只是一些基本原理，实际上网络的错误检测和补偿机制非常复杂。下面来说几个关键的点，首先是返回ACK号的等待时间（这个等待时间叫超时时间）。

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

等待时间需要设为一个合适的值，不能太长也不能太短。根据服务器物理距离的远近，ACK号的返回时间也会产生很大的波动，而且我们还必须考虑到拥塞带来的影响。正因为波动如此之大，所以将等待时间设置为一个固定值并不是一个好办法。因此，TCP采用了动态调整等待时间的方法，这个等待时间是根据ACK号返回所需的时间来判断的。具体来说，TCP会在发送数据的过程中持续测量ACK号的返回时间，如果ACK号返回变慢，则相应延长等待时间；相对地，如果ACK号马上就能返回，则相应缩短等待时间。

使用窗口有效管理ACK号

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

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

当接收方的TCP模块收到包后，会先将数据存放到接收缓冲区中。然后，接收方需要计算ACK号，将数据块组装起来还原成原本的数据并传递给应用程序，如果这些操作还没完成下一个包就到了也不用担心，因为下一个包也会被暂存在接收缓冲区中。如果数据到达的速率比处理这些数据并传递给应用程序的速率还要快，那么接收缓冲区中的数据就会越堆越多，最后就会溢出。缓冲区溢出之后，后面的数据就进不来了，因此接收方就收不到后面的包了，也就意味着超出了接收方处理能力。我们可以通过下面的方法来避免这种情况的发生。首先，接收方需要告诉发送方自己最多能接收多少数据，然后发送方根据这个值对数据发送操作进行控制，这就是滑动窗口方式的基本思路。

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

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

ACK与窗口的合并

要提高收发数据的效率，还需要考虑另一个问题，那就是返回ACK号和更新窗口的时机。如果假定这两个参数是相互独立的，分别用两个单独的包来发送，结果会如何？

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

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

那么ACK号又是什么情况？当接收方收到数据时，如果确认内容没有问题，就应该向发送方返回ACK号。

如果将前面两个因素结合起来看，每收到一个包，就需要向发送方分别发送ACK号和窗口更新这两个单独的包。这样一来，接收方发给发送方的包就太多了，导致网络效率下降。

因此，接收方在发送ACK号和窗口更新时，并不会马上把包发送出去，而是会等待一段时间，在这个过程中很有可能会出现其他的通知操作，这样就可以把两种通知合并在一个包里面发送了。举个例子，在等待发送ACK号的时候正好需要更新窗口，这时就可以把ACK号和窗口更新放在一个包里发送。当需要连续发送多个ACK号时，也可以只发送最后一个ACK号，从而减少包的数量。

接收HTTP响应消息

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

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

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

数据发送完毕后断开连接

毫无疑问，收发数据结束的时间点应该是应用程序判断所有数据都已经发送完毕的时候。这时，数据发送完毕的一方会发起断开过程，但不同的应用程序会选择不同的断开时机。以Web为例，在HTTP1.0时代，服务器一方会在发送完响应后发起断开过程。

无论哪种情况，完成数据发送的一方会发起断开过程，这里我们以服务器一方发起断开过程为例来进行讲解。首先，服务器一方的应用程序会调用Socket库的close程序。然后，服务器的协议栈会生成包含断开信息的TCP头部，具体来说就是将控制位中的FIN比特设为1。接下来，协议栈会委托IP模块向客户端发送数据。同时，服务器的套接字中也会记录下断开操作的相关信息。

当收到服务器发来的FIN为1的TCP头部时，客户端的协议栈会将自己的套接字标记为进入断开操作状态。然后，为了告知服务器已收到FIN为1的包，客户端会向服务器返回一个ACK号。过了一会儿，应用程序就会调用read来读取数据。这时，协议栈会告知应用程序（浏览器）来自服务器的数据已经全部收到了。

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

删除套接字

和服务器的通信结束之后，用来通信的套接字也就不会再使用了，这时我们就可以删除这个套接字了。不过，套接字并不会立即被删除，而是会等待一段时间之后再被删除。

等待这段时间是为了防止误操作，引发误操作的原因有很多，下面来举一个最容易理解的例子。在HTTP 1.1中，客户端先发起断开，服务器返回ACK号；然后服务器也发送FIN请求断开，客户端返回ACK号。

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

至于具体等待多长时间，这和包重传的操作方式有关。协议中对于这个等待时间没有明确的规定，一般来说会等待几分钟之后再删除套接字。

数据收发操作小结

到这里，用TCP协议收发应用程序数据的操作就全部结束了。一图胜千言，下图描述了整个过程。

IP与以太网的包收发操作

TCP模块在执行连接、收发、断开等各阶段操作时，都需要委托IP模块将数据封装成包发送给通信对象。我们就来讨论一下IP模块是如何将包发送给对方的。

包的基本知识

包是由头部和数据两部分构成的。头部包含目的地址等控制信息，头部后面就是委托方要发送给对方的数据。

发送方的网络设备会负责创建包，创建包的过程就是生成含有正确控制信息的头部，然后再附加上要发送的数据。接下来，包会被发往最近的网络转发设备。当到达最近的转发设备之后，转发设备会根据头部中的信息判断接下来应该发往哪里。

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

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

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

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

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

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

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

包收发操作概览

包收发操作的起点是TCP模块委托IP模块发送包的操作。这个委托的过程就是TCP模块在数据块的前面加上TCP头部，然后整个传递给IP模块，这部分就是网络包的内容。与此同时，TCP模块还需要指定通信对象的IP地址。

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

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

包送达对方之后，对方会作出响应。返回的包也会通过转发设备发送回来，然后我们需要接收这个包。接收的过程和发送的过程是相反的。

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

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

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

那么，我们应该如何判断应该把包交给哪块网卡呢？其实和路由器使用IP表判断下一个路由器位置的操作是一样的。

这个“IP表”叫作路由表，这里先简单介绍一下。如图所示，我们可以通过route print命令来显示路由表。首先，我们对套接字中记录的目的地IP地址与路由表左侧的Network Destination栏进行比较，找到对应的一行。例如，TCP模块告知的目标IP地址为192.168.1.21，那么就对应图中的第6行，因为它和192.168.1的部分相匹配。

找到相应的条目之后，接下来看从右边数第2列和第3列的内容。右起第2列，也就是Interface列，表示网卡等网络接口，这些网络接口可以将包发送给通信对象。右起第3列，即Gateway列表示下一个路由器的IP地址，将包发给这个IP地址，该地址对应的路由器就会将包转发到目标地址。路由表的第1行中，目标地址和子网掩码都是0.0.0.0，这表示默认网关，如果其他所有条目都无法匹配，就会自动匹配这一行。

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

生成以太网用的MAC头部

IP模块在生成IP头部之后，会在它前面再加上MAC头部。MAC头部是以太网使用的头部，它包含了接收方和发送方的MAC地址等信息。

在生成MAC头部时，只要设置上图中的3个字段就可以了。首先是“以太类型”，这里填写表示IP协议的值0800。接下来是发送方MAC地址，这里填写网卡本身的MAC地址。MAC地址是在网卡生产时写入ROM里的，只要将这个值读取出来写入MAC头部就可以了。

前面这些还比较简单，而接收方MAC地址就有点复杂了，因为我们还需要执行根据IP地址查询MAC地址的操作。

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

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

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

不过，如果每次发送包都要这样查询一次，网络中就会增加很多ARP包，因此我们会将查询结果放到一块叫作ARP缓存的内存空间中留着以后用。也就是说，在发送包时，先查询一下ARP缓存，如果其中已经保存了对方的MAC地址，就直接使用ARP缓存中的地址，而当ARP缓存中不存在对方MAC地址时，则发送ARP查询。显示ARP缓存的方法如下。

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

上面这个策略能够在几分钟后消除缓存和现实的差异，但IP地址刚刚发生改变的时候，ARP缓存中依然会保留旧的地址，这时就会发生通信的异常。

以太网的基本知识

完成IP模块的工作之后，下面就该轮到网卡了，不过在此之前，我们先来了解一些以太网的基本知识。

以太网是一种为多台计算机能够彼此自由和廉价地相互通信而设计的通信技术，它的原型如图（a）所示。这种网络的本质其实就是一根网线，图上还有一种叫作收发器的小设备，它的功能只是将不同网线之间的信号连接起来而已。因此，当一台计算机发送信号时，信号就会通过网线流过整个网络，最终到达所有的设备。

不过，我们无法判断一个信号到底是发给谁的，因此需要在信号的开头加上接收者的信息，也就是地址。这样一来就能够判断信号的接收者了，与接收者地址匹配的设备就接收这个包，其他的设备则丢弃这个包，这样我们的包就送到指定的目的地了。为了控制这一操作，我们就需要使用MAC头部。通过MAC头部中的接收方MAC地址，就能够知道包是发给谁的；而通过发送方MAC地址，就能够知道包是谁发出的；此外，通过以太类型就可以判断包里面装了什么类型的内容。

这个原型后来变成了图（b）中的结构。这个结构是将主干网线替换成了一个中继式集线器，将收发器网线替换成了双绞线。不过，虽然网络的结构有所变化，但信号会发送给所有设备这一基本性质并没有改变。后来，图（c）这样的使用交换式集线器的结构普及开来，现在我们说的以太网指的都是这样的结构。这个结构看上去和（b）很像，但其实里面有一个重要的变化，即信号会发送给所有设备这一性质变了，现在信号只会流到根据MAC地址指定的设备，而不会到达其他设备了。

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

下面来看看以太网的包收发操作。IP生成的网络包只是存放在内存中的一串数字信息，我们需要将数字信息转换为电或光信号，才能在网线上传输。负责执行这一操作的是网卡，要控制网卡还需要网卡驱动程序。下面是一张网卡主要构成要素的概念图。

网卡并不是通上电之后就可以马上开始工作的，而是和其他硬件一样，都需要进行初始化。也就是说，打开计算机启动操作系统的时候，网卡驱动程序会对硬件进行初始化操作，然后硬件才进入可以使用的状态。其中包括在MAC模块中设置MAC地址。

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

网卡驱动从IP模块获取包之后，会将其复制到网卡内的缓冲区中，然后向MAC模块发送发送包的命令。接下来就轮到MAC模块进行工作了。

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

报头是一串像10101010…这样1和0交替出现的比特序列，长度为56比特，它的作用是确定包的读取时机，SFD则是用来确定帧的起始位置。

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

向集线器发送网络包

加上报头、起始帧分界符和FCS之后，我们就可以将包通过网线发送出去了。发送信号的操作分为两种，一种是使用集线器的半双工模式，另一种是使用交换机的全双工模式。半双工模式需要考虑信号的碰撞问题，不过现在所使用的基本上都是全双工模式。

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

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

接收返回包

我们继续看看接收网络包时的操作过程。

信号的开头是报头，通过报头的波形同步时钟，然后遇到起始帧分界符时开始将后面的信号转换成数字信息。首先，PHY （MAU）模块会将信号转换成通用格式并发送给MAC模块，MAC模块再从头开始将信号转换为数字信息，并存放到缓冲区中。当到达信号的末尾时，还需要检查FCS。如果计算得出的FCS和包末尾的FCS不一致，这个包就会被当作错误包而被丢弃。

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

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

服务器返回的包的以太类型应该是0800，因此网卡驱动会将其交给TCP/IP协议栈来进行处理。接下来就轮到IP模块先开始工作了，第一步是检查IP头部，确认格式是否正确。如果格式没有问题，下一步就是查看接收方IP地址。

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

如果接收方IP地址正确，则这个包会被接收下来，这时还需要完成另一项工作。IP协议有一个叫作分片的功能，如果接收到的包是经过分片的，那么IP模块会将它们还原成原始的包。

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

UDP协议的收发操作

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

大多数的应用程序都像之前介绍的一样使用TCP协议来收发数据，但当然也有例外。有些应用程序不使用TCP协议，而是使用UDP协议来收发数据。向DNS服务器查询IP地址的时候我们用的也是UDP协议。下面就简单介绍一下UDP协议。

TCP的工作方式十分复杂，为什么要设计得如此复杂呢？因为我们需要将数据高效且可靠地发送给对方。为了实现可靠性，我们就需要确认对方是否收到了我们发送的数据，如果没有还需要再发一遍。

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

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

控制用的短数据

这种情况就适合使用UDP。像DNS查询等交换控制信息的操作基本上都可以在一个包的大小范围内解决，这种场景中就可以用UDP来代替TCP。UDP没有TCP的接收确认、窗口等机制，因此在收发数据之前也不需要交换控制信息，也就是说不需要建立和断开连接的步骤，只要在从应用程序获取的数据前面加上UDP头部，然后交给IP进行发送就可以了。

接收也很简单，只要根据IP头部中的接收方和发送方IP地址，以及UDP头部中的接收方和发送方端口号，找到相应的套接字并将数据交给相应的应用程序就可以了。除此之外，UDP协议没有其他功能了，遇到错误或者丢包也一概不管。因为UDP只负责单纯地发送包而已，并不像TCP一样会对包的送达状态进行监控，所以协议栈也不知道有没有发生错误。但这样并不会引发什么问题，因此出错时就收不到来自对方的回复，应用程序会注意到这个问题，并重新发送一遍数据。

音频和视频数据

还有另一个场景会使用UDP，就是发送音频和视频数据的时候。音频和视频数据必须在规定的时间内送达，一旦送达晚了，就会错过播放时机，导致声音和图像卡顿。

如果像TCP一样通过接收确认响应来检查错误并重发，重发的过程需要消耗一定的时间，因此重发的数据很可能已经错过了播放的时机。一旦错过播放时机，重发数据也是没有用的，因为声音和图像已经卡顿了，这是无法挽回的。

此外，音频和视频数据中缺少了某些包并不会产生严重的问题，只是会产生一些失真或者卡顿而已，一般都是可以接受的。在这些无需重发数据，或者是重发了也没什么意义的情况下，使用UDP发送数据的效率会更高。