用电信号传输 TCP/IP 数据——探索协议栈和网卡
小虾米用电信号传输 TCP/IP 数据——探索协议栈和网卡
总结：
第 1 章，我们从解析浏览器中输入的网址开始，探索了生成 HTTP 请求消息、委托操作系统发送消息等步骤。本章，我们将讲解操作系统中的协议栈是如何处理数据发送请求的。
这一章主要讲述了TCP 模块，IP 模块，Mac 模块的工作，非常经典。
创建套接字
协议栈的内部结构
TCP: Transmission Control Protocol
UDP：User Datagram Protocol 详情请看本章:UDP 协议的收发操作
IP: Internet Protocol
ICMP：Internet Control Message Protocol 详情请看本章:将服务器的响应包从 IP 传递给 TCP
ARP：Address Resolution Protocol 详情请看本章:通过 ARP 查询目标路由器的 MAC 地址
这张图中的上下关系是有一定规则的，上面的部分会向下面的部分委派工作
浏览器、电子邮件客户端、Web 服务器、电子邮件服务器等程序，尽管不同的应用程序收发的数据内容不同，但收发数据的操作是共通的
协议栈的上半部分有两块，分别是负责用 TCP 协议收发数据的部分和负责用 UDP 协议收发数据的部分。浏览器、邮件等一般应用程序收发数据时用 TCP；DNS 查询等收发较短的控制数据时用 UDP。
下半部分是用 IP 协议控制网络包收发操作的部分。在互联网上传送数据时，数据会被切分成一个一个的网络包，而将网络包发送给通信对象的操作就是由 IP 来负责的。此外，IP 中还包括 ICMP 协议和 ARP 协议。ICMP 用于告知网络包传送过程中产生的错误以及各种控制消息，ARP 用于根据 IP 地址查询相应的以太网 MAC 地址。
如何理解协议栈这个叫法呢，在 Java 中，栈表示一个方法调用另一个方法的时候在内存中新开辟出来的空间，又叫栈帧（frame），协议栈也有类似的逻辑，比如，应用程序层会调用操作系统提供的接口来完成请求，而操作系统又是调用驱动程序来完成工作，从具体的协议上来说，HTTP 协议请求通过调用 TCP 协议，来完成，TCP 协议调用 IP 协议，IP 协议调用以太网协议。一层层得嵌套，一层层地委托，很类似于 Java 中的栈。所以，可以把这些协议地嵌套使用，称为协议栈。
第一章：解析器的内部原理小节也提到过这种类似的逻辑。
套接字的实体就是通信控制信息
书中出现了 Socket、socket、套接字（英文也是 socket）等看起来非常容易混淆的词，其中大写字母开头的 Socket 表示库，小写的 socket 表示程序组件的名称，而汉字的"套接字"则表示管道两端的接口。
在协议栈内部有一块用于存放控制信息的内存空间，这里记录了用于控制通信操作的控制信息，例如通信对象的 IP 地址、端口号、通信操作的进行状态等。（这部分在本章：负责保存控制信息的头部中有详细描述）
套接字就只是一个概念而已，并不存在实体，如果一定要赋予它一个实体，我们可以说这些控制信息就是套接字的实体，或者说存放控制信息的内存空间就是套接字的实体，（可以理解为存在内存上的一个对象），套接字中记录了用于控制通信操作的各种控制信息，协议栈则需要根据这些信息判断下一步的行动，这就是套接字的作用。
通过 netstat 查看套接字信息，一般 Windows 系统用netstat -ano表示查看所有状态的套接字，并且显示 IP 而不是域名，同时还显示对应的进程 ID，在 Linux 系统下，使用netstat -anp实现同样的查询效果（这个一命令在《监控网络状态》中也有记录）：
本地 IP 地址和远程 IP 地址都是 0.0.0.0，这表示通信还没开始，IP 地址不确定，进程的状态也是 LISTENING
192.168.1.68 是本地的 IP 地址，每一个网卡都会分配有一个 IP 地址，如果本地有多块网卡，这里就会有多个 IP 地址
UDP 协议中套接字不绑定对方的地址和端口，因此这里显示 *:* 。
UDP 协议的细节看本章:UDP 协议的收发操作小结
调用 socket 时的操作
书中出现了 Socket、socket、套接字（英文也是 socket）等看起来非常容易混淆的词，其中大写字母开头的 Socket 表示库，小写的 socket 表示程序组件的名称，而汉字的"套接字"则表示管道两端的接口。
在第一步创建套接字中，协议栈首先会分配用于存放一个套接字所需的内存空间，并返回一个描述符，（对应第一章：创建套接字阶段），套接字还没有连接，里面只有一些初始的信息
连接服务器
连接是什么意思
连接实际上是通信双方交换控制信息，在套接字中记录这些必要信息并准备数据收发的一连串操作，叫连接只是习惯叫法，实际上叫准备比较准确。
所谓控制信息，就是用来控制数据收发操作所需的一些信息，IP 地址和端口号就是典型的例子。除此之外还有其他一些控制信息，我们后面会逐一进行介绍。
连接操作中所交换的控制信息是根据通信规则来确定的，只要根据规则执行连接操作，双方就可以得到必要的信息从而完成数据收发的准备。此外，当执行数据收发操作时，我们还需要一块用来临时存放要收发的数据的内存空间，这块内存空间称为缓冲区，它也是在连接操作的过程中分配的。
负责保存控制信息的头部
之前我们说的控制信息其实可以大体上分为两类（这一点在本章：套接字的实体就是通信控制信息中其实已经说过了）
第一类是客户端和服务器相互联络时交换的控制信息。这些信息不仅连接时需要，包括数据收发和断开连接操作在内，整个通信过程中都需要，这些内容在 TCP 协议的规格中进行了定义。
这些字段是固定的，在连接、收发、断开等各个阶段中，每次客户端和服务器之间进行通信时，都需要提供这些控制信息。这些信息会被添加在客户端与服务器之间传递的网络包的开头。会记作 TCP 头部，此外，以太网和 IP 协议也有自己的控制信息，这些信息也叫头部，叫做以太网头部、IP 头部。（以太网头部又称"MAC 头部"）
头部的信息非常重要，理解了头部各字段的含义，就等于理解了整个通信的过程。
端口是 TCP 协议使用的，IP 是 IP 协议使用的
校验和：checksum
端口号为 16 位，即最大为 65536，也就是说，计算机上的端口号，范围就是 0-65535
控制信息还有另外一类，那就是保存在套接字中，用来控制协议栈操作的信息，应用程序传递来的信息以及从通信对象接收到的信息都会保存在这里，还有收发数据操作的执行状态等信息也会保存在这里，协议栈会根据这些信息来执行每一步的操作。即：套接字的控制信息和协议栈的程序本身其实是一体的。
TCP 协议在不同的操作系统的实现不一样，比如 Windows 操作系统和 Linux 操作系统的协议栈的实现肯定是不一样的，必要的控制信息肯定也不一样，但是这并不妨碍 Windows 操作系统和 Linux 操作系统相互通信，只要在通信时按照规则将必要的信息写入头部，客户端和服务器之间的通信就能够得以成立。这就是 TCP 协议的作用
TCP 报文头详解
数据偏移量只有 4 位，最大表示 15，乘以 32bit（4 字节）就是实际的偏移字节数，所以最大的偏移字节数是 60 字节，数据偏移量一定是 32 位的整倍数，不够的，填充的部分会补充，这样做的好处就是可以快速定位数据的部分的起点。
TCP 头部中，前面这些都是固定的部分，占用 20 个字节，选项（可选字段）是一个可变长的信息，这部分最多包含 40 字节，因为 TCP 头部最长 60 字节，
控制位：
连接操作的实际过程（三次握手）
截取表 2.1
首先，客户端先创建一个包含表示开始数据收发操作的控制信息的头部。如表 2.1 所示，头部包含很多字段，这里要关注的重点是发送方和接收方的端口号（端口号就对应了服务器上的套接字，回看第一章：连接阶段：把管道接上去）。然后，我们将头部中的控制位的 SYN 比特设置为 1，大家可以认为它表示连接。此外还需要设置序号字段（一个随机数，具体可查看本章:使用 ACK 号确认网络包已收到（TCP的精髓，三次握手详细版），控制位的 SYN 设为 1 的意义实际上就是为了跟服务器同步这个值）和窗口大小字段（本章:使用窗口有效管理 ACK 号），这一点我们会稍后详细讲解。
当 TCP 头部创建好之后，接下来 TCP 模块会将信息传递给 IP 模块并委托它进行发送，这个时候，客户端的套接字的状态是正在连接。IP 模块执行网络包发送操作后，网络包就会通过网络到达服务器，然后服务器上的 IP 模块会将接收到的数据传递给 TCP 模块，服务器的 TCP 模块根据 TCP 头部中的信息找到端口号对应的套接字，因为服务器中会有很多套接字监听着端口等待连接，我们只需要从处于等待连接状态的套接字中找到与 TCP 头部中记录的端口号相同的套接字就可以了。当找到对应的套接字之后，套接字中会写入相应的信息，并将状态改为正在连接（收到客户端发回确认信息之后才会改为连接完毕）。上述操作完成后，服务器的 TCP 模块会返回响应，这个过程和客户端一样，需要在 TCP 头部中设置发送方和接收方端口号以及 SYN 比特。此外，在返回响应时还需要将 ACK 控制位设为 1，这表示已经接收到相应的网络包（还会设置 ACK 号，同时也会设置序号，还有窗口）。网络中经常会发生错误，网络包也会发生丢失，因此双方在通信时必须相互确认网络包是否已经送达，而设置 ACK 比特就是用来进行这一确认的。接下来，服务器 TCP 模块会将 TCP 头部传递给 IP 模块，并委托 IP 模块向客户端返回响应。
然后，网络包就会返回到客户端，通过 IP 模块到达 TCP 模块，并通过 TCP 头部的信息确认连接服务器的操作是否成功。如果 SYN 为 1 则表示连接成功（我感觉这里检查返回的头部的 ACK 号应该更合理），这时会向套接字中写入服务器的 IP 地址、端口号等信息，同时还会将状态改为连接完毕。到这里，客户端的操作就已经完成，但其实还剩下最后一个步骤。刚才服务器返回响应时将 ACK 比特设置为 1，相应地，客户端也需要将 ACK 比特设置为 1（同时设置 ACK 号）并发回服务器，告诉服务器刚才的响应包已经收到。当这个服务器收到这个返回包之后，会将对应的套接字的连接状态设置为连接完毕，这时连接操作才算全部完成。
控制位的作用是用来表示这个数据包是用来干什么的，
SYN：表示连接，这个数据包用来表示连接的
ACK：表示数据已收到，这个数据包是用来表示我已经收到了的
以上就是三次握手的细节。
实际上序号和 ack 号都是一直在变的，而且其值都是有意义的，实际的详细过程看本章：使用 ACK 号确认网络包已收到（TCP的精髓，三次握手详细版）
三次握手和四次挥手的 TCP 抓包详情：TCP 三次握手抓包分析及 TCP 四次挥手过程_夕阳还在水边明的博客-CSDN 博客_ensp 的 tcp 三次握手实验
第一次握手：
第二次握手：
第三次握手：
收发数据
将 HTTP 请求消息交给协议栈
首先，协议栈并不关心应用程序传来的数据是什么内容。应用程序在调用 write 时（本章：调用 socket 时的操作小节，图 2.3 的第三步）会指定发送数据的长度，在协议栈看来，要发送的数据就是一定长度的二进制字节序列而已。
其次，协议栈并不是一收到数据就马上发送出去，而是会将数据存放在内部的发送缓冲区中，并等待应用程序的下一段数据。什么时候发出去看两个条件。
第一个判断要素是每个网络包能容纳的数据长度，MTU（Maximum Transmission Unit，最大传输单元）表示一个网络包的最大长度，在以太网中一般是 1500 字节（图 2.5）MTU 是包含头部的总长度，因此需要从 MTU 减去头部的长度，然后得到的长度就是一个网络包中所能容纳的最大数据长度，这一长度叫作 MSS（Maximum Segment Size，最大分段大小），TCP 和 IP 的头部加起来一般是 40 字节（IP 头部最少 20 个字节，TCP 头部最少 20 个字节），因此 MTU 减去这个长度就是 MSS。例如，在以太网中，MTU 为 1500，因此MSS 就是 1460。TCP/IP 可以使用一些可选参数（protocol option），如加密等，这时头部的长度会增加，那么 MSS 就会随着头部长度增加而相应缩短。当从应用程序收到的数据长度超过或者接近 MSS 时再发送出去，就可以避免发送大量小包的问题了。
注意：MTU 的头部不包含 Mac 头部，只包含 IP 头部和 TCP 头部，剩下的都是数据
另一个判断要素是时间。当应用程序发送数据的频率不高的时候，如果每次都等到长度接近 MSS 时再发送，可能会因为等待时间太长而造成发送延迟，这种情况下，即便缓冲区中的数据长度没有达到 MSS，也应该果断发送出去。为此，协议栈的内部有一个计时器，当经过一定时间之后，就会把网络包发送出去。（网络调优参数）
实际如何平衡这两个判断条件是由协议栈的开发者来决定的，也正是由于这个原因，不同种类和版本的操作系统在相关操作上也就存在差异。
同时，应用程序在发送数据时可以指定一些选项，比如如果指定"不等待填满缓冲区直接发送"，则协议栈就会按照要求直接发送数据。
对较大的数据进行拆分
当要发送的数据很大（一般存在于文件上传），发送缓冲区中的数据就会超过 MSS 的长度，这时我们当然不需要继续等待后面的数据了。发送缓冲区中的数据会被以 MSS 长度为单位进行拆分，拆分出来的每块数据会被放进单独的网络包中。根据发送缓冲区中的数据拆分的情况，当判断需要发送这些数据时，就在每一块数据前面加上 TCP 头部，并根据套接字中记录的控制信息标记发送方和接收方的端口号，然后交给 IP 模块来执行发送数据的操作（图 2.6）
这个时候，HTTP 协议层的数据（请求行、状态行、消息头、消息体）就是 TCP 后面的数据块，如果太大，会被分割成数据块 1、数据块 2。
使用 ACK 号确认网络包已收到（TCP 的精髓，三次握手详细版）
网络包已经装好数据并发往服务器了，但数据发送操作还没有结束。因此在发送网络包之后，接下来还需要进行确认操作，当对方没收到时进行重发
服务器返回的 Ack 号等于接收到的数据包的序号加上数据的长度，而这个数字就是客户端下一个应该发送数据块的序号
首先，TCP 模块在拆分数据时，会先算好每一块数据相当于从头开始的第几个字节，接下来在发送这一块数据时，将这个起点坐标写在 TCP 头部中，“序号”字段就是派在这个用场上的。然后，发送数据的长度也需要告知接收方，不过这个并不是放在 TCP 头部里面的，因为用整个网络包的长度减去头部的长度就可以得到数据的长度，所以接收方可以用这种方法来进行计算（TCP 头部有数据偏移量字段，只有 4 位，一位表示 4 字节，4 位二进制数最多表示 15，所以可以表达 hi 的最多偏移量位 60 个字节）。有了上面两个数值，我们就可以知道发送的数据是从第几个字节开始，长度是多少了。
通过这些信息，接收方还能够检查收到的网络包有没有遗漏。例如，假设上次接收到第 1460 字节，那么接下来如果收到序号为 1461 的包，说明中间没有遗漏（服务器返回的 Ack 号就是客户端下一个应该发送数据块的序号）；但如果收到的包序号为 2921，那就说明中间有包遗漏了，如果客户端没有接收到服务器发回的对应的 ack 号，那么就会重发。如果确认没有遗漏，接收方会将到目前为止接收到的数据长度加起来，计算出一共已经收到了多少个字节，然后将这个数值写入 TCP 头部的 ACK 号中发送给发送方 A。简单来说，发送方说的是"现在发送的是从第××字节开始的部分，一共有××字节哦！“而接收方则回复说，“到第××字节之前的数据我已经都收到了哦！"这个返回 ACK 号的操作被称为确认响应，通过这样的方式，发送方就能够确认对方到底收到了多少数据。
在实际的通信中，序号并不是从 1 开始的，而是需要用随机数计算出一个初始值（32 位随机数，Initial Sequence Number，简称 ISN，这是做为了避免数据被拦截监听），这个随机的初始值是什么时候同步的呢？我们在建立连接的时候，有一个将 SYN 控制位设为 1 并发送给服务器的操作，实际上，在将 SYN 设为 1 的同时，还需要同时设置序号字段的值，而这里的值就代表序号的初始值。将 SYN 设为 1 并告知初始序号这一操作仅在连接过程中出现，因此发送 SYN 为 1 的网络包就表示发起连接的意思。实际上，SYN 是 Synchronize（同步）的缩写，意思是通过告知初始序号使通信双方保持步调一致，以便完成后续的数据收发检查，这才是 SYN 原本的含义。
我们刚刚只考虑了单向的数据传输，但 TCP 数据收发是双向的，在客户端向服务器发送数据的同时，服务器也会向客户端发送数据，方法也很简单
实际的工作过程（图 2.9）。首先，客户端在连接时需要计算出与从客户端到服务器方向通信相关的序号初始值，并将这个值发送给服务器（图 2.9①，其实还会把窗口大小发送过去，详细请看 2.3.5）。接下来，服务器会通过这个初始值计算出 ACK 号并返回给客户端（图 2.9②）。初始值有可能在通信过程中丢失，因此当服务器收到初始值后需要返回 ACK 号作为确认。同时，服务器也需要计算出与从服务器到客户端方向通信相关的序号初始值，并将这个值发送给客户端（图 2.9②，其实还会把窗口大小发送过去，详细请看 2.3.5）。接下来像刚才一样，客户端也需要根据服务器发来的初始值计算出 ACK 号并返回给服务器（图 2.9③）。到这里，序号和 ACK 号都已经准备完成了，接下来就可以进入数据收发阶段了。数据收发操作本身是可以双向同时进行的，但 Web 中是先由客户端向服务器发送请求，序号也会跟随数据一起发送（图 2.9④）。然后，服务器收到数据后再返回 ACK 号（图 2.9⑤）。从服务器向客户端发送数据的过程则正好相反（图 2.9⑥⑦）。
TCP 采用这样的方式确认对方是否收到了数据，在得到对方确认之前，发送过的包都会保存在发送缓冲区中。如果对方没有返回某些包对应的 ACK 号，那么就重新发送这些包。这一机制非常强大。通过这一机制，我们可以确认接收方有没有收到某个包，如果没有收到则重新发送，这样一来，无论网络中发生任何错误，我们都可以发现并采取补救措施（重传网络包）。反过来说，有了这一机制，我们就不需要在其他地方对错误进行补救了。因此，网卡、集线器、路由器都没有错误补偿机制，一旦检测到错误就直接丢弃相应的包。应用程序也是一样，因为采用 TCP 传输，即便发生一些错误对方最终也能够收到正确的数据，所以应用程序只管自顾自地发送这些数据就好了。不过，如果发生网络中断、服务器宕机等问题，那么无论 TCP 怎样重传都不管用。这种情况下，无论如何尝试都是徒劳，因此 TCP 会在尝试几次重传无效之后强制结束通信，并向应用程序报错。
通过"序号"和"ACK 号"可以确认接收方是否收到了网络包
我猜TCP 的连接的复用的原理也是这个，第二个请求开始的时候，其序号只需要在第一个请求结束的时候服务器返回的 ACK 号上继续运算即可。
根据网络包平均往返时间调整 ACK 号等待时间（决定是否重传）
在等待时间之内，收到了接收端发回的 ACK 号，则发送下一个包，如果超过了等待时间还没有收到 ACK 号，则判断为包丢失，需要重新发包
这个等待时间不能太长，不然网络就会慢，不能太短，不然就会出现无意义的重传，所以需要一个合适的值
不同的环境 ACK 返回的时间差别很大，局域网内只需要几毫秒，互联网环境下可能又几百毫秒，所以将等待时间设置为一个固定值并不是一个好办法。因此，TCP 采用了动态调整等待时间的方法，这个等待时间是根据 ACK 号返回所需的时间来判断的。具体来说，TCP 会在发送数据的过程中持续测量 ACK 号的返回时间，如果 ACK 号返回变慢，则相应延长等待时间；相对地，如果 ACK 号马上就能返回，则相应缩短等待时间。
由于计算机的时间测量精度较低，ACK 返回时间过短时无法被正确测量，因此等待时间有一个最小值，这个值在每个操作系统上不一样，基本上是在 0.5 秒到 1 秒之间。
使用窗口有效管理 ACK 号
滑动窗口，就是在发送一个包之后，不等待 ACK 号返回，而是直接发送后续的一系列包。这样一来，等待 ACK 号的这段时间就被有效利用起来了，
但是要考虑数据处理过快，接收端处理不过来的情况。当接收方的 TCP 收到包后，会先将数据存放到接收缓冲区中。然后，接收方需要计算 ACK 号，将数据块组装起来还原成原本的数据并传递给应用程序，如果这些操作还没完成下一个包就到了，也不用担心，因为下一个包也会被暂存在接收缓冲区中。如果数据到达的速率比处理这些数据并传递给应用程序的速率还要快，那么接收缓冲区中的数据就会越堆越多，最后就会溢出。缓冲区溢出之后，后面的数据就进不来了，因此接收方就收不到后面的包了，这就和中途出错的结果是一样的，也就意味着超出了接收方处理能力。
滑动窗口方式的基本思路：接收方需要告诉发送方自己最多能接收多少数据，然后发送方根据这个值对数据发送操作进行控制。
接收端在缓冲区变大的时候（这个时机跟返回 ack 包的时机并不是完全相同，具体看 2.3.6），会发送一个设置了 TCP 头的窗口字段的包给发送端，里面设置了此时此刻自己能接收的数据量，发送端接着收到这个信号之后，将根据这个字段来发送数据包，这样一来，发送方就不会发送过多的数据，导致超出接收方的处理能力了。
窗口字段，是非常著名的 TCP 调优字段，一般和接收方的缓冲区大小一致。
这里有一个问题，如果在一个窗口中发送的一连串的包中有一个丢失了，那么是不是后面的都要重传，即单通道顺序传输，答案：不是的，具体请看《TCP 超时与重传》
ACK 与窗口的合并（信号发送的时机）
什么时候发送 ACK 号呢？当接收方收到数据时，如果确认内容没有问题，就应该向发送方返回 ACK 号，因此我们可以认为收到数据之后马上就应该进行这一操作。
什么时候需要更新窗口大小呢？当收到的数据刚刚开始填入缓冲区时（即发送 ACK 号的时候），其实没必要每次都向发送方更新窗口大小，因为只要发送方在每次发送数据时减掉已发送的数据长度就可以自行计算出当前窗口的剩余长度。因此，更新窗口大小的时机应该是接收方从缓冲区中取出数据传递给应用程序的时候。这个操作是接收方应用程序发出请求时才会进行的，而发送方不知道什么时候会进行这样的操作，因此当接收方将数据传递给应用程序，导致接收缓冲区剩余容量增加时，就需要告知发送方，这就是更新窗口大小的时机。
当然，如果不经过优化，每收到一个包，就需要往发送端发两个包，这样效率未免太低了，我们可以通过设计一个延迟时间来解决这个问题（这估计也是一个调优参数），接收方在发送 ACK 号和窗口更新时，并不会马上把包发送出去，而是会等待一段时间（当然，这个时间肯定不能太长，至少不能长于发送端的 ACK 号的等待的时间），在这个过程中很有可能会出现其他的通知操作也需要发送包，这样就可以把两种通知合并在一个包里面发送了。举个例子，在等待发送 ACK 号的时候正好需要更新窗口，这时就可以把 ACK 号和窗口更新放在一个包里发送，从而减少包的数量。当需要连续发送多个 ACK 号时，也可以减少包的数量，这是因为 ACK 号表示的是已收到的数据量，也就是说，它是告诉发送方目前已接收的数据的最后位置在哪里，因此当需要连续发送 ACK 号时，只要发送最后一个 ACK 号就可以了，中间的可以全部省略。当需要连续发送多个窗口更新时也可以减少包的数量，因为连续发生窗口更新说明应用程序连续请求了数据，接收缓冲区的剩余空间连续增加。这种情况和 ACK 号一样，可以省略中间过程，只要发送最终的结果就可以了。秒极！！
接收 HTTP 响应消息
其实接收端的操作前面都讲过了。
协议栈尝试从接收缓冲区中取出数据并传递给应用程序，但可能这个时候请求消息刚刚发送出去，响应消息可能还没返回。响应消息的返回还需要等待一段时间，因此这时接收缓冲区中并没有数据，那么接收数据的操作也就无法继续。这时，协议栈会将应用程序的委托，也就是从接收缓冲区中取出数据并传递给应用程序的工作暂时挂起（即阻塞），等服务器返回的响应消息到达之后再继续执行接收操作。
接收到数据之后，协议栈会检查收到的数据块和 TCP 头部的内容，判断是否有数据丢失，如果没有问题则返回 ACK 号。然后，协议栈将数据块暂存到接收缓冲区中，并将数据块按顺序连接起来还原出原始的数据，最后将数据交给应用程序。具体来说，协议栈会将接收到的数据复制到应用程序指定的内存地址中，然后将控制流程交回应用程序。将数据交给应用程序之后，协议栈还需要找到合适的时机向发送方发送窗口更新。
从服务器断开并删除套接字
数据发送完毕后断开连接（四次挥手）
协议栈在设计上允许任何一方先发起断开过程。
无论哪种情况，完成数据发送的一方会发起断开过程，这里我们以服务器一方发起断开过程为例来进行讲解。首先，服务器一方的应用程序会调用 Socket 库的 close 程序（2.1.3 小节，图 2.3 的第四步）。然后，服务器的协议栈会生成包含断开信息的 TCP 头部，具体来说就是将控制位中的 FIN 比特设为 1。接下来，协议栈会委托 IP 模块向客户端发送数据（图 2.12①）。同时，服务器的套接字中也会记录下断开操作的相关信息。接下来轮到客户端了。当收到服务器发来的 FIN 为 1 的 TCP 头部时，客户端的协议栈会将自己的套接字标记为进入断开操作状态。然后，为了告知服务器已收到 FIN 为 1 的包，客户端会向服务器返回一个 ACK 号（图 2.12②）。这些操作完成后，协议栈就可以等待应用程序来取数据了。不会再有后续的数据写入接收缓冲区了，接收缓冲区里的数据可以直接开始处理。根据规则，服务器发送 FIN 请求之后，Web 通信操作就全部结束了，因此只要收到服务器返回的所有数据，客户端的操作也就随之结束了。因此，客户端应用程序会调用 close 来结束数据收发操作，这时客户端的协议栈也会和服务器一样，生成一个 FIN 比特为 1 的 TCP 包，然后委托 IP 模块发送给服务器（图 2.12③）。一段时间之后，服务器就会返回 ACK 号（图 2.12④）。到这里，客户端和服务器的通信就全部结束了。
FIN：表示断开连接，这个数据包用来表示断开连接的
三次握手和四次挥手的 TCP 抓包详情：TCP 三次握手抓包分析及 TCP 四次挥手过程_夕阳还在水边明的博客-CSDN 博客_ensp 的 tcp 三次握手实验
一方挥手
确认
另一方挥手
确认
删除套接字
和服务器的通信结束之后，用来通信的套接字也就不会再使用了，这时我们就可以删除这个套接字了。不过，套接字并不会立即被删除，而是会等待一段时间之后再被删除。等待这段时间是为了防止误操作，因为网络有丢包的风险，在最后一步 ACK 号发出之后，如果这个包丢失了，对方会重发 FIN 包（对，没错，发送任何数据包都需要接受到返回的 ACK 号通信才算结束，不然就会重传，包括 FIN 包），这个时候，如果己方已经把这个端口对应的套接字删除了，那么将由新的套接字处理这个 FIN 信号，这个新建的套接字就直接关闭了，他自己该做的工作还没开始呢，这是不对的，所以套接字在断开连接之后需要保留一段时间（这个时间取决于对方的丢包重传时间 2.3.4，不会很长，往往有几分钟），防止网络丢包需要重发断开信号。
数据收发操作小结（TCP 连接与断开终极版）
数据收发操作的第一步是创建套接字。一般来说，服务器一方的应用程序在启动时就会创建好套接字并进入等待连接的状态（比如 Tomcat 启动的时候，监听 8080 端口）。客户端则一般是在用户触发特定动作，需要访问服务器的时候创建套接字。在这个阶段，还没有开始传输网络包。
创建套接字之后，客户端会向服务器发起连接操作。首先，客户端会生成一个 SYN 为 1 的 TCP 包并发送给服务器（图 2.13①）。这个 TCP 包的头部还包含了客户端向服务器发送数据时使用的初始序号，以及服务器向客户端发送数据时需要用到的窗口大小。当这个包到达服务器之后，服务器会返回一个 SYN 为 1 的 TCP 包（图 2.13②）。和图 2.13①一样，这个包的头部中也包含了序号和窗口大小，此外还包含表示确认已收到包①的 ACK 号。当这个包到达客户端时，客户端会向服务器返回一个包含表示确认的 ACK 号的 TCP 包（图 2.13③）。到这里，连接（或者说准备）操作就完成了，双方进入数据收发阶段。
数据收发阶段的操作根据应用程序的不同而有一些差异，以 Web 为例，首先客户端会向服务器发送请求消息。TCP 会将请求消息切分成一定大小的块，并在每一块前面加上 TCP 头部，然后发送给服务器（图 2.13④）。TCP 头部中包含序号，它表示当前发送的是第几个字节的数据。当服务器收到数据时，会向客户端返回 ACK 号（图 2.13⑤）。在最初的阶段，服务器只是不断接收数据，随着数据收发的进行，数据不断传递给应用程序，接收缓冲区就会被逐步释放。这时，服务器需要将新的窗口大小告知客户端。当服务器收到客户端的请求消息后，会向客户端返回响应消息，这个过程和刚才的过程正好相反（图 2.13⑥⑦）。
服务器的响应消息发送完毕之后，数据收发操作就结束了，这时就会开始执行断开操作。以 Web 为例，服务器会先发起断开过程。在这个过程中，服务器先发送一个 FIN 为 1 的 TCP 包（图 2.13⑧），然后客户端返回一个表示确认收到的 ACK 号（图 2.13⑨）。接下来，双方还会交换一组方向相反的 FIN 为 1 的 TCP 包（图 2.13⑩）和包含 ACK 号的 TCP 包（图 2.13k）。最后，在等待一段时间后，套接字会被删除。
TIME_WAIT 主要存在于主动关闭的乙方，因为主动关闭的一方需要发出最后一个 ACK 包。为了不发生误操作，需要进行等待。
IP 与以太网的包收发操作
包的基本知识（基础，很重要）
TCP 是传输控制协议，IP 是网络协议，控制网络数据包的打包和发送，
每一层有每一层的包的概念，IP 层有 IP 层的包，以太网层有以太网层的包，以太网包包含了 IP 包，我们说的最多的网络包（package），指的就是 IP 包，之前我们说的 MTU，指的就是 IP 包的大小。对 IP 包来说，TCP 头和数据块组成了 IP 包的内容。TCP 模块在执行连接、收发、断开等各阶段操作时，都需要委托 IP 模块将数据封装成包（封装成这样的结构）发送给通信对象。大部分的时候，我们通过以太网发送网络包，所以需要把 IP 包封装成以太网包，当我们用别的协议传出 IP 包的时候，就会把 IP 包封装成别的包，但是 IP 包始终都是最小单元。
包是由头部和数据两部分构成的（图 2.14（a））。头部包含目的地址等控制信息，大家可以把它理解为快递包裹的面单；头部后面就是委托方要发送给对方的数据，也就相当于快递包裹里的货物。
包的传输的基本过程，适用各种通信方式：
首先，发送方的网络设备会负责创建包，创建包的过程就是生成含有正确控制信息的头部，然后再附加上要发送的数据。接下来，包会被发往最近的网络转发设备。当到达最近的转发设备之后，转发设备会根据头部中的信息判断接下来应该发往哪里。这个过程需要用到一张表，这张表里面记录了每一个地址对应的发送方向，也就是按照头部里记录的目的地址在表里进行查询，并根据查到的信息判断接下来应该发往哪个方向。比如，如果查表的结果是"目标地址为××××的包应该发到××××号线路”，那么转发设备就会把这个包发到××××号线路去。接下来，包在向目的地移动的过程中，又会到达下一个转发设备，然后又会按照同样的方式被发往下一个转发设备。就这样，经过多个转发设备的接力之后，包最终就会到达接收方的网络设备
TCP/IP 协议中的实际过程（主要的不同就是为了可拓展性把确定路由和包传输分成了两个不同的协议）：
前提知识：网络中有路由器和集线器两种不同的转发设备，路由器的作用是根据目标地址判断下一个路由器的位置（即纯转发），集线器的作用是在子网中将网络包传输到下一个路由（将子网中的数据发送出子网）。集线器是按照以太网规则传输包的设备，而路由器是按照 IP 规则传输包的设备，因此我们也可以作如下理解。IP 协议根据目标地址判断下一个 IP 转发设备的位置，子网中的以太网协议将包传输到下一个转发设备。
这么说是对的，但是对没有掌握以太网基础的人来说可能有点混淆，实际上，以太网中的所有设备（只要有网卡）底层最终都是通过以太网协议收发数据，集线器、交换机，路由器都是如此，只是说在子网内部，不存在路由转发，主机之间可直接通信，而在子网与子网之间，需要通过路由转发，而路由需要用 IP 协议确定下一个路由 Mac 的地址，指导以太网协议的传输，这样提供了更高的效率，这有点像现在的快递网络中的二维码，虽然直接看具体地址也能送，但是有了二维码，可以更快地处理，效率更高。
包传输的整体思路是，通过（转发）设备的路由表用 IP 确定下一个（转发）设备（一般都是路由器）的 IP，然后用 ARP 协议（2.5.5）获取这个 IP 对应的 Mac，然后用以太网协议传输过去，为什么一定要用以太网协议呢，只用 IP 协议行不行呢？不行，原因请查看网络的进化
IP 的出现就是为了提高网络包的转发效率，在学习了 3.3.2 小节之后，我们会发现，使用 IP 来转发包的效率确实很高，使用 MAC 地址无法如此高效
实际过程：如图 2.14（b）所示，TCP/IP 包包含如下两个头部， MAC 头部（用于以太网协议）、IP 头部（用于 IP 协议），首先，发送方将包的目的地，也就是要访问的服务器的 IP 地址写入 IP 头部中。这样一来，我们就知道这个包应该发往哪里，IP 协议就可以根据这一地址查找包的传输方向，从而找到下一个路由器的位置，也就是图 2.16 中的路由器 R1。接下来，IP 协议会委托以太网协议将包传输过去。而委托以太网协议将包传输过去，IP 协议需要查找（通过 ARP 协议，2.5.5）下一个路由器即 R1 的以太网地址（MAC 地址），并将这个地址写入 MAC 头部中。这样一来，以太网协议就知道要将这个包发到哪一个路由器上了。网络包在传输过程中（图 2.16①）会经过集线器，集线器是根据以太网协议工作的设备。为了判断包接下来应该向什么地方传输，集线器里有一张表（用于以太网协议的表），可根据以太网头部中记录的目的地信息查出相应的传输方向。这张图中只有一个集线器，当存在多个集线器时（比如子网嵌套的时候），网络包会按顺序逐一通过这些集线器进行传输。这样，包就到了下一个路由器。包到达下一个路由器（图 2.16②）之后。路由器中有一张 IP 协议的表，可根据这张表以及 IP 头部中记录的目的地信息查出接下来应该发往哪个路由器。为了将包发到下一个路由器，我们还需要查出下一个路由器的 MAC 地址，并记录到 MAC 头部中，大家可以理解为改写了 MAC 头部（准确地说，收到包的时候 MAC 头部会被舍弃，而当再次发送的时候又会加上包含新 MAC 地址的新 MAC 头部。）。这样，网络包就又被发往下一个节点了。然后这个过程不断重复（有点像递归），最终网络包就会被送到目的地，当目的地设备成功接收之后，网络包的传输过程就结束了。
前面讲了 IP 和以太网的分工，其中以太网的部分也可以替换成其他的东西，例如无线局域网、ADSL、FTTH 等，它们都可以替代以太网的角色帮助 IP 协议来传输网络包，当使用除以太网之外的其他网络进行传输时，MAC 头部也会被替换为适合所选通信规格的其他头部。因此，将 IP 和负责传输的网络分开，可以更好地根据需要使用各种通信技术。像互联网这样庞大复杂的网络，在架构上需要保证灵活性，这就是设计这种分工方式的原因。
可跟本章：以太网的基本知识中的包传递的描述进行对比
PS：关于以太网协议和 mac 头部的细节，可查看本章：生成以太网用的 MAC 头部
包收发操作概览
尽管我们说 IP 模块负责将包发给对方，但实际上将包从发送方传输到接收方的工作是由集线器、路由器等网络设备来完成的，因此 IP 模块仅仅是整个包传输过程的入口而已。（IP 协议只负责确定下一个转发设备的 mac 地址）
包收发操作的起点是 TCP 模块委托 IP 模块发送包的操作（图 2.17 中的"①发送”）。这个委托的过程就是 TCP 模块在数据块的前面加上 TCP 头部，然后整个传递给 IP 模块，这部分就是网络包的内容。与此同时，TCP 模块还需要指定通信对象的 IP 地址，也就是需要写清楚"将什么内容发给谁"。收到委托后，IP 模块会将包的内容当作一整块数据，在前面加上包含控制信息的头部。刚才我们讲过，IP 模块会添加 IP 头部和 MAC 头部这两种头部。IP 头部中包含 IP 协议规定的、根据 IP 地址将包发往目的地所需的控制信息；MAC 头部包含通过以太网的局域网将包传输至最近的路由器所需的控制信息。这些就是 IP 模块负责的工作。
接下来，封装好的包会被交给网络硬件（图 2.17 中的"②发送"），例如以太网、无线局域网等。网络硬件即网卡（从这个意义上来看应该叫作"网络接口"比较准确）。传递给网卡的网络包是由一连串 0 和 1 组成的数字信息，网卡会将这些数字信息转换为电信号或光信号，并通过网线（或光纤）发送出去，然后这些信号就会到达集线器、路由器等转发设备，再由转发设备一步一步地送达接收方。接收的过程和发送的过程是相反的，信息先以电信号的形式从网线传输进来，然后由网卡将其转换为数字信息并传递给 IP 模块（图 2.17 中的"③接收"）。接下来，IP 模块会将 MAC 头部和 IP 头部后面的内容，也就是 TCP 头部加上数据块，传递给 TCP 模块。接下来的操作就是我们之前讲过的 TCP 模块负责的部分了。
在这个过程中，有几个关键的点。IP 模块会将 TCP 头部和数据块看作一整块二进制数据，在执行收发操作时并不关心其中的内容和内容的意义，对于包的乱序和丢失也一概不知。比如，TCP 中有各种不同的控制包，三次握手四次挥手等等，IP 模块一概不管，IP 的职责就是将委托的东西打包送到对方手里，或者是将对方送来的包接收下来，仅此而已。（这一点，跟以太网协议忽略 IP 模块的内容很像）因此，接下来我们要讲的这些关于 IP 的工作方式，可适用于任何 TCP 委派的收发操作。
生成包含接收方 IP 地址的 IP 头部
IP 模块接受 TCP 模块的委托负责包的收发工作，它会生成 IP 头部并附加在 TCP 头部前面。IP 头部包含的内容如表 2.2 所示，其中最重要的内容就是 IP 地址，它表示这个包应该发到哪里去。这个地址是由 TCP 模块告知的，而 TCP 又是在执行连接操作时从应用程序那里获得这个地址的，因此这个地址的最初来源就是应用程序。
协议号，它表示包的内容是来自哪个模块的。例如，如果是 TCP 模块委托的内容，则设置为 06（十六进制），如果是 UDP 模块委托的内容，则设置为 17（十六进制）
IP 头部中还需要填写发送方的 IP 地址，大家可以认为是发送方计算机的 IP 地址，实际上"计算机的 IP 地址"这种说法并不准确。IP 地址实际上并不是分配给计算机的，而是分配给网卡的，因此当计算机上存在多块网卡时，每一块网卡都会有自己的 IP 地址（虚拟网卡也有自己的 IP 地址）。那么，在填写发送方 IP 地址时就需要判断到底应该填写哪个地址。这个判断相当于在多块网卡中判断应该使用哪一块网卡来发送这个包，也就相当于判断应该把包发往哪个路由器（后文会提到网关其实就是路由器，而网卡和路由器是相绑定的，设置网卡的时候，都会设置网关），因此只要确定了目标路由器，也就确定了应该使用哪块网卡，也就确定了发送方的 IP 地址。
那么应该如何判断目标路由器呢？——查看 IP 表（路由表 Routing Table），和图 2.16 中路由器使用 IP 表（路由表）判断下一个路由器位置的操作是一样的。通过route print 命令查看路由表
（下面还有 Ipv6 路由表，省略了）
第一部分是接口列表，
接口表示网卡等网络接口，这些网络接口可以将包发送给通信对象。一般，电脑上至少会有两个网卡，一个以太网网卡，一个无线网卡，除此之外还会有很多虚拟网卡，上图中，Realtek PCIe 是以太网网卡，Realtek 8822BE Wireless 是无线网卡，像 Vmware 开头的那两个都是虚拟网卡
第二部分是 Ipv4 路由表
网络目标和网络掩码即表示了目标网段，网关表示要访问此网段需要经过的下一个路由器的 IP 地址，将包发给这个 IP 地址，该地址对应的路由器就会将包转发到目标地址。Gateway（网关）在 TCP/IP 的世界里就是路由器的意思。如果网关（Gateway）和接口（Interface）列的 IP 地址相同，就表示不需要路由器进行转发，可以直接将包发给接收方的 IP 地址。“在链路上"英文 On-Link，字面意思就是在链路上。表示不需要通过路由器转发，可以直接与其通信的意思。显示在链路上，表示该条路由表的网关 IP 和接口的 IP 是一样的，由本机接口直接决定数据包的去向，无需其他路由中转。一般都是目标的 ip 与本机接口 IP 在同一个网段。同一个网段，自然不需要路由转发，可以直接与同网段的 IP 进行通信，那么网关自然是自己本身（自己接口的 ip）。广播和组播 255.255.255.255,224.0.0.0 例外，虽然与接口 ip 不是同一个网段，但是也不需要其他路由器转发，同样由自己处理
接口就是上面的接口列表中的接口
路由表的第 1 行中，目标地址和子网掩码（第一章：IP 地址的基本知识小节介绍过）都是 0.0.0.0，这表示默认网关，如果其他所有条目都无法匹配，就会自动匹配这一行。
首先我们把目标 IP 地址跟 Ipv4 路由表的网络目标（Network Destination）栏和子网掩码确定的网段比较，找到对应的一行，比如如果目标地址是 192.168.1.3，那就应该匹配 192.168.1.0，具体的匹配规则我们将在第 3 章详细介绍（路由表中的信息）。然后我们就可以确定接口（网卡）了，确定了网卡，本机 IP 就确定了。
等我们学完了网络上的集线器，交换机，路由器这些设备之后再回过头看，你会发现跟计算机内部的网卡没什么区别，都是那些表，都是那些硬件，只不过组合不一样。
PS：
版本号（Version）：长度 4 比特。标识目前采用的 IP 协议的版本号。一般的值为 0100（IPv4），0110（IPv6）
IP 包头长度（Internet Header Length）：长度 4 比特。这个字段的作用是为了描述 IP 包头的长度，因为在 IP 包头中有变长的可选部分。该部分占 4 个 bit 位，单位为 32bit（4 个字节),一个 IP 包头的长度最长为 15=1111，即 15*4＝60 个字节。IP 包头最小长度为 20 字节即该字段至少为 5。这个跟 TCP 头中的数据偏移量一样
服务类型（Type of Service）：长度 8 比特。RFC 定义的该字段如图：
优先级 Precedence，取值越大数据越重要
000 普通 (Routine)
001 优先的 (Priority)
010 立即的发送 (Immediate)
011 闪电式的 (Flash)
100 比闪电还闪电式的 (Flash Override)
101 CRITIC/ECP
110 网间控制 (Internetwork Control)
111 网络控制 (Network Control)
D 时延：0:普通 1:延迟尽量小
T 吞吐量：0:普通 1:流量尽量大
R 可靠性：0:普通 1:可靠性尽量大
0 最后 2 位被保留，恒定为 0
3 位优先权字段 (现已被忽略) + 4 位 TOS 字段 + 1 位保留字段 (须为 0)。4 位 TOS 字段分别表示最小延时、最大吞吐量、最高可靠性、最小费用，其中最多有一个能置为 1。应用程序根据实际需要来设置 TOS 值，如 ssh 和 telnet 这样的登录程序需要的是最小延时的服务，文件传输 ftp 需要的是最大吞吐量的服务
IP 包总长（Total Length）：长度 16 比特。以字节为单位计算的 IP 包的长度 (包括头部和数据)，所以 IP 包最大长度 65535=2 的 15 次方 -1 字节。由于 MTU 的限制，长度超过 MTU 的数据报都将被分片传输，所以实际传输的 IP 分片数据报的长度远远没有达到最大值。
标识符（Identifier）:长度 16 比特。唯一地标识主机发送的每一个数据报，其初始值是随机的，每发送一个数据报其值就加 1。该字段和 Flags 和 Fragment Offest 字段联合使用，对较大的上层数据包进行分段（fragment）操作。路由器将一个包拆分后，所有拆分开的小包被标记相同的值，以便目的端设备能够区分哪个包属于被拆分开的包的一部分；
标记（Flags）：长度 3 比特。该字段第一位不使用。第二位是 DF（Don’t Fragment）位，DF 位设为 1 时表明路由器不能对该上层数据包分段。如果 IP 数据包的大小超过了 MTU（无法在不分段的情况下进行转发），则路由器会丢弃该上层数据包并返回一个 ICMP 类型的错误信息。第三位是 MF（More Fragments）位，当路由器对一个上层数据包分段，则路由器会在除了最后一个分段的 IP 包的包头中将 MF 位设为 1。
片偏移（Fragment Offset）：长度 13 比特。表示该 IP 包在该组分片包中位置，接收端靠此来组装还原 IP 包。分片相对原始 IP 数据报数据部分的偏移。实际的偏移值为该值左移 3 位后得到的，所以除了最后一个 IP 数据报分片外，每个 IP 分片的数据部分的长度都必须是 8 的整数倍。
关于分片的细节，查看第三章：通过分片功能拆分大网络包
生存时间（TTL）：长度 8 比特。当 IP 包进行传送时，先会对该字段赋予某个特定的值。当 IP 包经过每一个沿途的路由器的时候，每个沿途的路由器会将 IP 包的 TTL 值减少 1。如果 TTL 减少为 0，则该 IP 包会被丢弃。这个字段可以防止由于路由环路而导致 IP 包在网络中不停被转发。
协议（Protocol）：长度 8 比特。标识了上层所使用的协议。以下是比较常用的协议号：
1 ICMP
2 IGMP
6 TCP
17 UDP
88 IGRP
89 OSPF
头部校验（Header Checksum）：长度 16 位。用来做 IP 头部的正确性检测，但不包含数据部分。因为每个路由器要改变 TTL 的值，所以路由器会为每个通过的数据包重新计算这个值。
起源和目标地址（Source and Destination Addresses）：这两个地段都是 32 比特。标识了这个 IP 包的起源和目标地址。要注意除非使用 NAT，否则整个传输的过程中，这两个地址不会改变。
生成以太网用的 MAC 头部
本章：包的基本知识末尾也有介绍
IP 模块在生成 IP 头部之后，会在它前面再加上 MAC 头部。MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息。
发送方 Mac 地址：MAC 地址是在网卡生产时写入 ROM 里的，只要将这个值读取出来写入 MAC 头部就可以了
接收方 MAC 地址：我们只知道接收方的 IP（就是 gateway 路由器的 IP）这个时候，我们就需要执行根据 IP 地址查询 MAC 地址的操作。即 ARP，看本章:通过 ARP 查询目标路由器的 MAC 地址小结
每一个主机对应唯一的一个 MAC 地址，是由网卡决定的，长度是 48 位，所以这里的接收方 mac 地址和发送方 mac 地址都是 6 个字节，也就是 48 个比特位。在显示的时候，经常用 16 进制数表示，，一个 16 进制数用 4 比特表示，一个字节用 2 个 16 进制数表示，Mac 地址就是 12 个 16 进制数：
在数据发送传输的过程中，目的 IP 地址与源 IP 地址是永远不会变的，这是这个数据的起始与终点，而 MAC 地址是一直在变化的，由于数据在传输的过程中会经历很多的主机等，所以在这个过程中 MAC 地址一直在变（只要有转发就会变）。类似于我们坐车，要坐车从 A 出发，目的地是 D。这个过程中我们会经过 B C，从 A 出发前往 B 的时候，发送方 MAC 是 A，接收方 MAC 是 B，当我们从 B 前往 C 的时候，发送方 MAC 是 B，接收方 MAC 是 C，而目的 IP 地址与 源 IP 地址一直是 D 与 A，这样说的话就很好理解了。
MAC 地址与 IP 地址，一个代表的目的与终点，一个代表着途中的经过。所以在到达目的局域网后，数据包并不知道要传输给哪台主机，因为 MAC 地址的变化，但是目的 IP 地址一直没有变化，所以此时就需要 ARP 协议来确定目的主机的 MAC 地址。关于 ARP 的细节，查看本章：通过 ARP 查询目标路由器的 MAC 地址
通过 ARP 查询目标路由器的 MAC 地址
ARP：Address Resolution Protocol，地址解析协议
在以太网中，有一种叫作广播的方法，可以把包发给连接在同一以太网中的所有设备。ARP 就是利用广播对所有设备提问：“××这个 IP 地址是谁的？请把你的 MAC 地址告诉我。“然后就会有人回答：“这个 IP 地址是我的，我的 MAC 地址是××××。“A（图 2.19）。如果对方和自己处于同一个子网中，那么通过上面的操作就可以得到对方的 MAC 地址。然后，我们将这个 MAC 地址写入 MAC 头部，MAC 头部就完成了。如果路由表的设置正确，那么对方应该在同一子网，否则对方无法作出 ARP 响应，这时只能认为对方不存在，包的发送操作就会失败。
在查询路由器 Mac 地址的操作中，路由器肯定跟当前设备处于同一子网，不然当前计算机都无法访问它，它还怎么实现路由功能呢，所以是一定可以查询到 Mac 地址的。
查询到结果之后，将查询结果放到一块叫作 ARP 缓存的内存空间中留着以后用。也就是说，在发送包时，先查询一下 ARP 缓存，如果其中已经保存了对方的 MAC 地址，就不需要发送 ARP 查询，直接使用 ARP 缓存中的地址，而当 ARP 缓存中不存在对方 MAC 地址时，则发送 ARP 查询。如果总是使用 ARP 缓存中保存的地址也会产生问题。例如当 IP 地址发生变化时，ARP 缓存的内容就会和现实发生差异。为了防止这种问题的发生，ARP 缓存中的值在经过一段时间后会被删除，一般这个时间在几分钟左右。
我们可以通过arp -a查看所有的 ARP 缓存（每一块网卡上的 IP 对应的 MAC 地址）。arp -d <IP地址>表示删除这个的 IP 的 ARP 缓存。
有人认为，MAC 头部是以太网需要的内容，并不属于 IP 的职责范围，但从现实来看，如果在交给网卡之前，IP 模块就把整个网络包打好了，那么网卡只要将打好的包发送出去就可以了。对于别的协议的模块也是一样，对于网卡来说，它不关心包的内容，它只负责发送，这样，同一块网卡就可以支持各种类型的包。至于接收也是一样的道理。这一点跟 IP 模块忽略 TCP 模块打包的内容的性质很像。
以太网的基本知识（很重要的基础知识）
以太网是一种为多台计算机能够彼此自由和廉价地相互通信而设计的通信技术，它的原型如图 2.22（a）所示。
这种网络的本质其实就是一根网线。图上还有一种叫作收发器的小设备，它的功能只是将不同网线之间的信号连接起来而已。因此，当一台计算机发送信号时，信号就会通过网线流过整个网络，最终到达所有的设备。这就好像所有人待在一个大房间里，任何一个人说话，所有人都能够听到，同样地，这种网络中任何一台设备发送的信号所有设备都能接收到。不过，我们无法判断一个信号到底是发给谁的，因此需要在信号的开头加上接收者的信息，也就是地址。这样一来就能够判断信号的接收者了，与接收者地址匹配的设备就接收这个包，其他的设备则丢弃这个包，这样我们的包就送到指定的目的地了。为了控制这一操作，我们就需要使用表 2.3 中列出的 MAC 头部。通过 MAC 头部中的接收方 MAC 地址，就能够知道包是发给谁的；而通过发送方 MAC 地址，就能够知道包是谁发出的；此外，通过以太类型就可以判断包里面装了什么类型的内容。以太网其实就这么简单。实际上，多台设备同时发送信号会造成碰撞，当然也有相应的解决方案，不过这部分比较复杂。随着交换式集线器的普及，信号已经不会发生碰撞了，因此在实际工作中也不需要在意这个复杂的部分。
这个原型后来变成了图 2.22（b）中的结构。这个结构是将主干网线替换成了一个中继式集线器，将收发器网线替换成了双绞线。不过，虽然网络的结构有所变化，但信号会发送给所有设备这一基本性质并没有改变。
后来，图 2.22（c）这样的使用交换式集线器（后文统称交换机）的结构普及开来，现在我们说的以太网指的都是这样的结构。这个结构看上去和（b）很像，但其实里面有一个重要的变化，即信号会发送给所有设备这一性质变了，现在信号只会流到根据 MAC 地址指定的设备，而不会到达其他设备了。当然，根据 MAC 地址来传输包这一点并没有变，因此 MAC 头部的设计也得以保留。
尽管以太网经历了数次变迁，但其基本的 3 个性质至今仍未改变，即将包发送到 MAC 头部的接收方 MAC 地址代表的目的地，用发送方 MAC 地址识别发送方，用以太类型识别包的内容。因此，大家可以认为具备这 3 个性质的网络就是以太网。这些性质也适用于无线局域网。也就是说，将包发送到 MAC 头部的接收方 MAC 地址所代表的目的地，用发送方 MAC 地址识别发送方，在这些方面无线局域网和以太网是一样的。无线局域网没有以太类型，但有另一个具备同样功能的参数，可以认为它就是以太类型。因此，我们可以用无线局域网来代替以太网。
以太网中的各种设备也是基于以太网规格来工作的，因此下面的内容不仅适用于客户端计算机，同样也适用于服务器、路由器等各种设备。
更详尽的网络变迁史，网络的进化，其中讲解了另一个版本的 TCP/IP 协议中包的传递的描述，可跟本章:包的基本知识中描述进行对比：
将 IP 包转换成电或光信号发送出去
IP 生成的网络包只是存放在内存中的一串数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电或光信号，才能在网线上传输，也就是说，这才是真正的数据发送过程。（本章:包收发操作概览小节讲过）。网卡无法单独工作，要控制网卡还需要网卡驱动程序，不同厂商和型号的网卡在结构上有所不同，因此网卡驱动程序也是厂商开发的专用程序。
打开计算机启动操作系统的时候，网卡驱动程序会对硬件进行初始化操作，然后硬件才进入可以使用的状态。这些操作包括硬件错误检查、初始设置等步骤，这些步骤对于很多其他硬件也是共通的，但也有一些操作是以太网特有的，那就是在控制以太网收发操作的 MACA 模块中设置 MAC 地址。
MAC：Media Access Control 的缩写。MAC 头部、MAC 地址中的 MAC 也是这个意思。也就是说，通过 MAC 模块控制包收发操作时所使用的头部和地址就叫作 MAC 头部和 MAC 地址。
网卡的 ROM 中保存着全世界唯一的 MAC 地址，这是在生产网卡时写入的，将这个值读出之后就可以对 MAC 模块进行设置，MAC 模块就知道自己对应的 MAC 地址了。也有一些特殊的方法，比如从命令或者配置文件中读取 MAC 地址并分配给 MAC 模块。这里就不讨论了。
给网络包再加 3 个控制数据
网卡驱动从 IP 模块获取包之后，会将其复制到网卡内的缓冲区中，然后向 MAC 模块发送发送包的命令。接下来就轮到MAC 模块进行工作了。（前面又 TCP 模块、IP 模块，这里又有 MAC 模块，网卡中的软件核心就是 MAC 模块）
首先，MAC 模块会将包从缓冲区中取出，并在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列（图 2.24）。制定以太网标准的组织 IEEE 出于历史原因使用了"帧"而不是"包”，因此在以太网术语中都是说"帧”，其实我们基本没必要讨论两者的区别，大家可以认为包和帧是一回事，只是说法不同罢了。
报头 56 比特，起始帧分界符 8 比特，帧校验序列 32 比特
我们在传递电信号的时候，是将数据信号和时钟信号叠加在一起传送的。这样的信号如图 2.26（c）所示，发送方将这样的信号发给接收方。由于时钟信号是像图 2.26（b）这样按固定频率进行变化的，只要能够找到这个变化的周期，就可以从接收到的信号（c）中提取出时钟信号（b），进而通过接收信号（c）和时钟信号（b）计算出数据信号（a），这和发送方将数据信号和时钟信号进行叠加的过程正好相反。然后，只要根据时钟信号（b）的变化周期，我们就可以从数据信号（a）中读取相应的电压和电流值，并将其还原为 0 或 1 的比特了。
这里的重点在于如何判断时钟信号的变化周期。时钟信号是以 10 Mbit/s或者100 Mbit/s这种固定频率进行变化的，就像我们乘坐自动扶梯一样，只要对信号进行一段时间的观察，就可以找到其变化的周期。因此，我们不能一开始就发送包的数据，而是要在前面加上一段用来测量时钟信号的特殊信号，这就是报头的作用，即确定时钟信号的周期。
报头后面的起始帧分界符在图 2.25 中也已经画出来了，它的末尾比特排列有少许变化。接收方以这一变化作为标记，从这里开始提取网络包数据。也就是说，起始帧分界符是一个用来表示包起始位置的标记。
末尾的 FCS（帧校验序列）用来检查包传输过程中因噪声导致的波形紊乱、数据错误，它是一串 32 比特的序列，是通过一个公式对包中从头到尾的所有内容进行计算而得出来的。具体的计算公式在此省略，它和磁盘等设备中使用的 CRC 错误校验码（CRC：Cyclic Redundancy Check，循环冗余校验）是同一种东西，当原始数据中某一个比特发生变化时，计算出来的结果就会发生变化。在包传输过程中，如果受到噪声的干扰而导致其中的数据发生了变化，那么接收方计算出的 FCS 和发送方计算出的 FCS 就会不同，这样我们就可以判断出数据有没有错误。
向集线器发送网络包
发送信号的操作分为两种，一种是使用集线器的半双工模式，另一种是使用交换机的全双工模式。发送和接收同时并行的方式叫作"全双工”，相对地，某一时刻只能进行发送或接收其中一种操作的叫作"半双工”。现在用的大部分都是全双工的交换机。不必太仔细研究半双工的集线器。
在半双工模式中，会等待网线中已经存在的信号传输完毕（这是为了避免信号碰撞），然后当之前的信号传输完毕，或者本来就没有信号在传输的情况下，我们就可以开始发送信号了，在全双工模式下不需要考虑这个问题。首先，MAC 模块从报头开始将数字信息按每个比特转换成电信号，然后由 PHY，或者叫 MAU 的信号收发模块发送出去。注意，网卡的 MAC 模块生成通用信号，然后由 PHY（MAU）模块转换成可在网线中传输的格式，并通过网线发送出去，可以认为 PHY（MAU）模块的功能就是对 MAC 模块产生的信号进行格式转换。在这里，将数字信息转换为电信号的速率就是网络的传输速率，例如每秒将 10 Mbit 的数字信息转换为电信号发送出去，则速率就是 10 Mbit/s。参考图2.23。根据以太网信号方式的不同，有些地方叫MAU（Medium Attachment Unit，介质连接单元），有些地方叫 PHY（Physical Layer Device，物理层装置）。在速率为 100 Mbit/s以上的以太网中都叫PHY。
以太网不会确认发送的信号对方有没有收到。如果发生错误，协议栈的 TCP 负责搞定。
在半双工模式中，PHY（MAU）的职责并不是仅仅是将 MAC 模块传递过来的信号通过网线发送出去，它还需要监控接收线路中有没有信号进来。在开始发送信号之前，需要先确认没有其他信号进来，这时才能开始发送。如果在信号开始发送到结束发送的这段时间内一直没有其他信号进来，发送操作就成功完成了。如果有其他信号进来，两组信号就会相互叠加，无法彼此区分出来，这就是所谓的信号碰撞。这种情况下，继续发送信号是没有意义的，因此发送操作会终止。为了通知其他设备当前线路已发生碰撞，还会发送一段时间的阻塞信号，然后所有的发送操作会全部停止。等待一段时间之后，网络中的设备会尝试重新发送信号。但如果所有设备的等待时间都相同，那肯定还会发生碰撞，因此必须让等待的时间相互错开。具体来说，等待时间是根据 MAC 地址生成一个随机数计算出来的。
全双工模式不会有信号碰撞，可以同时接受和发送。
接收返回包
在使用集线器的半双工模式以太网中，一台设备发送的信号会到达连接在集线器上的所有设备。这意味着无论是不是发给自己的信号都会通过接收线路传进来，因此接收操作的第一步就是不管三七二十一把这些信号全都收进来再说。信号的开头是报头，通过报头的波形同步时钟，然后遇到起始帧分界符时开始将后面的信号转换成数字信息。这个操作和发送时是相反的，即 PHY（MAU）模块先开始工作，然后再轮到 MAC 模块。首先，PHY（MAU）模块会将信号转换成通用格式并发送给 MAC 模块，MAC 模块再从头开始将信号转换为数字信息，并存放到缓冲区中。当到达信号的末尾时，还需要检查 FCS。具体来说，就是将从包开头到结尾的所有比特套用到公式中计算出 FCS，然后和包末尾的 FCS 进行对比，正常情况下两者应该是一致的，如果中途受到噪声干扰而导致波形发生紊乱，则两者的值会产生差异，这时这个包就会被当作错误包而被丢弃。如果 FCS 校验没有问题，接下来就要看一下 MAC 头部中接收方 MAC 地址与网卡在初始化时分配给自己的 MAC 地址是否一致，以判断这个包是不是发给自己的。我们没必要去接收发给别人的包，因此如果不是自己的包就直接丢弃，如果接收方 MAC 地址和自己 MAC 地址一致，则将包放入缓冲区中。到这里，MAC 模块的工作就完成了，接下来网卡会通知计算机收到了一个包。
通知计算机的操作会使用一个叫作中断的机制。在网卡执行接收包的操作的过程中，计算机并不是一直监控着网卡的活动，而是去继续执行其他的任务。因此，如果网卡不通知计算机，计算机是不知道包已经收到了这件事的。网卡驱动也是在计算机中运行的一个程序，因此它也不知道包到达的状态。在这种情况下，我们需要一种机制能够打断计算机正在执行的任务，让计算机注意到网卡中发生的事情，这种机制就是中断。具体来说，中断的工作过程是这样的。首先，网卡向扩展总线中的中断信号线发送信号，该信号线通过计算机中的中断控制器连接到 CPU。当产生中断信号时，CPU 会暂时挂起正在处理的任务，切换到操作系统中的中断处理程序。然后，中断处理程序会调用网卡驱动，控制网卡执行相应的接收操作。
网卡驱动被中断处理程序调用后，会从网卡的缓冲区中取出收到的包，并通过 MAC 头部中的以太类型字段判断协议的类型。然后将包交给对应的协议栈进行处理。如果操作系统内不存在相应的协议栈，则会视作错误，直接丢弃这个包。
将服务器的响应包从 IP 传递给 TCP
服务器返回的包的以太类型应该是 0800，因此网卡驱动会将其交给 TCP/IP 协议栈来进行处理。接下来就轮到 IP 模块先开始工作了，第一步是检查 IP 头部，确认格式是否正确（如果有问题，会发送 ICMP 类型的数据）。如果格式没有问题，下一步就是查看接收方 IP 地址。如果接收网络包的设备是一台 Windows 客户端计算机，那么服务器返回的包的接收方 IP 地址应该与客户端网卡的地址一致，检查确认之后我们就可以接收这个包了。如果接收方 IP 地址不是自己的地址，那一定是发生了什么错误。客户端计算机不负责对包进行转发，因此不应该收到不是发给自己的包，当发生这样的错误时，IP 模块会通过 ICMP 消息将错误告知发送方（图 2.1）。如果是服务器就不一定了。服务器的操作系统具备和路由器相同的包转发功能，当打开这一功能时，它就可以像路由器一样对包进行转发。在这种情况下，当收到不是发给自己的包的时候，就会像路由器一样执行包转发操作。由于这一过程和路由器是相同的，因此我们将在第 3 章探索路由器时进行介绍。
如果接收方 IP 地址正确，则这个包会被接收下来，这时还需要完成另一项工作。IP 协议有一个叫作分片的功能，具体的内容我们将在第 3 章探索路由器时进行介绍。简单来说，网线和局域网中只能传输小包，因此需要将大的包切分成多个小包。如果接收到的包是经过分片的，那么 IP 模块会将它们还原成原始的包。分片的包会在 IP 头部的标志字段中进行标记，当收到分片的包时，IP 模块会将其暂存在内部的内存空间中，然后等待 IP 头部中具有相同 ID 的包全部到达，这是因为同一个包的所有分片都具有相同的 ID。此外，IP 头部还有一个分片偏移量（fragment offset）字段，它表示当前分片在整个包中所处的位置。根据这些信息，在所有分片全部收到之后，就可以将它们还原成原始的包，这个操作叫作分片重组。到这里，IP 模块的工作就结束了，
接下来包会被交给 TCP 模块。TCP 模块会根据 IP 头部中的接收方和发送方 IP 地址，以及 TCP 头部中的接收方和发送方端口号来查找对应的套接字（关于为什么查找套接字同时需要接收方和发送方的 IP 地址和端口号，我们会在第 6 章介绍端口号机制时一起讲解）。找到对应的套接字之后，就可以根据套接字中记录的通信状态，执行相应的操作了。例如，如果包的内容是应用程序数据，则返回确认接收的包，并将数据放入缓冲区，等待应用程序来读取；如果是建立或断开连接的控制包，则返回相应的响应控制包，并告知应用程序建立和断开连接的操作状态。
ICMP: Internet Control Message Protocol
计算机网络的知识体系，真的好庞大啊，操！
UDP 协议的收发操作
不需要重发的数据用 UDP 发送更高效
向 DNS 服务器查询 IP 地址的时候我们用的也是 UDP 协议。
TCP 的工作方式十分复杂，为什么要设计得如此复杂呢？因为我们需要将数据高效且可靠地发送给对方。为了实现可靠性，我们就需要确认对方是否收到了我们发送的数据，如果没有还需要再发一遍。要实现上面的要求，最简单的方法是数据全部发送完毕之后让接收方返回一个接收确认。这样一来，如果没收到直接全部重新发送一遍就好了，根本不用像 TCP 一样要管理发送和确认的进度。但是，如果漏掉了一个包就要全部重发一遍，怎么看都很低效。为了实现高效的传输，我们要避免重发已经送达的包，而是只重发那些出错的或者未送达的包。TCP 之所以复杂，就是因为要实现这一点。
不过，在某种情况下，即便没有 TCP 这样复杂的机制，我们也能够高效地重发数据，这种情况就是数据很短，用一个包就能装得下。如果只有一个包，就不用考虑哪个包未送达了，因为全部重发也只不过是重发一个包而已，这种情况下我们就不需要 TCP 这样复杂的机制了。而且，如果不使用 TCP，也不需要发送那些用来建立和断开连接的控制包了。此外，我们发送了数据，对方一般都会给出回复，只要将回复的数据当作接收确认就行了，也不需要专门的接收确认包了。
控制用的短数据
像 DNS 查询等交换控制信息的操作基本上都可以在一个包的大小范围内解决，这种场景中就可以用 UDP 来代替 TCP。
UDP 没有 TCP 的接收确认、窗口等机制，因此在收发数据之前也不需要交换控制信息，也就是说不需要建立和断开连接的步骤，只要在从应用程序获取的数据前面加上 UDP 头部，然后交给 IP 进行发送就可以了（表 2.5）。接收也很简单，只要根据 IP 头部中的接收方和发送方 IP 地址，以及 UDP 头部中的接收方和发送方端口号，找到相应的套接字并将数据交给相应的应用程序就可以了。除此之外，UDP 协议没有其他功能了，遇到错误或者丢包也一概不管。因为UDP 只负责单纯地发送包而已，并不像 TCP 一样会对包的送达状态进行监控，所以协议栈也不知道有没有发生错误。但这样并不会引发什么问题，因此出错时就收不到来自对方的回复，应用程序会注意到这个问题，并重新发送一遍数据（UDP 包的重发是由应用程序控制的）。这样的操作本身并不复杂，也并不会增加应用程序的负担。
UDP 可发送的数据最大长度为 IP 包的最大长度减去 IP 头部和 UDP 头部的长度。不过，这个长度与 MTU、MSS 不是一个层面上的概念。MTU 和 MSS 是基于以太网和通信线路上网络包的最大长度来计算的，而 IP 包的最大长度是由 IP 头部中的"全长"字段决定的。“全长"字段的长度为 16 比特，因此从 IP 协议规范来看，IP 包的最大长度为 65535 字节，再减去 IP 头部和 UDP 头部的长度，就是 UDP 协议所能发送的数据最大长度。如果不考虑可选字段的话，一般来说 IP 头部为 20 字节，UDP 头部为 8 字节，因此 UDP 的最大数据长度为 65507 字节。当然，这么长的数据已经超过了以太网和通信线路的最大传输长度，因此需要让 IP 模块使用分片功能拆分之后再传输。
音频和视频数据
音频和视频数据必须在规定的时间内送达，一旦送达晚了，就会错过播放时机，导致声音和图像卡顿。如果像 TCP 一样通过接收确认响应来检查错误并重发，重发的过程需要消耗一定的时间，因此重发的数据很可能已经错过了播放的时机。一旦错过播放时机，重发数据也是没有用的，因为声音和图像已经卡顿了，这是无法挽回的。当然，我们可以用高速线路让重发的数据能够在规定的时间内送达，但这样一来可能要增加几倍的带宽才行。此外，音频和视频数据中缺少了某些包并不会产生严重的问题，只是会产生一些失真或者卡顿而已，一般都是可以接受的。在这些无需重发数据，或者是重发了也没什么意义的情况下，使用 UDP 发送数据的效率会更高。