Linux网络编程：报文理解与传输层协议TCP

---

报文的核心理解

通过前面的学习，我们了解到，报文 = 报头 + 数据

以寄信为例子，数据=信的内容，报头=信封上的信息（地址，邮编），那么报文=信封+信的内容

也就是说，报文可以理解成一种数据的包裹。同时，我们需要知道，报文是一个通用术语，在不同网络层，它有不同的具体叫法。

• 传输层（如TCP协议）：通常叫 报文段。
• 网络层（如IP协议）：通常叫 数据包。
• 数据链路层（如以太网协议）：通常叫 帧。

通常，我们用“报文”或者“数据包”来泛指这些概念。

简单的概念回顾到此结束，接下来进入核心理解。

网络协议栈需要并发处理来自不同连接、不同应用的网络报文，这就导致OS内部，一定会同时存在多个“报文”，以及在网络协议栈的不同层（应用层，传输层，网络层...）也一定会同时存在多个报文。这么多报文，OS当然是需要将它们全部管理起来的。如何管理？先描述，再组织。

描述&组织

内核中一定存在描述报文的结构体，在linux中，描述报文的结构体是sk_buff(套接字缓冲区)，不管是应用层封装报文 沿着网络协议栈 从上往下传递到下层的过程中，还是从底层网卡接收到链路层，内核都会创建一个sk_buff结构体对象。该结构体的关键字段如下：

next和prev指针，就将所有报文以双链表的形式组织了起来。

sk_buff是Linux网络栈中最重要的数据结构，它代表一个网络报文。顾名思义，它不直接包含数据，而是管理数据缓冲区。在该结构体中，端口号啥的都没有。

sk_buff工作原理示意图

从上到下对应低地址（一段空间最开始的位置）到高地址，在data和head之间会预留部分空间，这部分空间用于封装报头以及解包。

封装与解包

所以封装报头其实就是，sk_buff->data-=sizeof(协议报头)，然后紧接着强转成对应报头，(struct 协议报头*)data，然后填充报头。

那么解包其实就是，强转成对应报头，提取数据，sk_buff->data+=sizeof(协议报头)就完成了解包。

所以封装和解包的核心就是data指针的移动，封装和解包的sk_buff对象自从创建出来，在内存里从始至终都没挪过窝。

socket和文件系统的关系

网络服务器本身是一个进程，是进程就有PCB（task_struct），有PCB就必须有文件描述符表，有文件描述符表就必定有文件对象file，file结构体内部的private_data指针指向socket对象。stock结构体中有回指向file的指针，以及一个wait_queue_head_t类型的等待队列（套接字读写条件不具备的时候，进程会在该队列中进行等待，比如调用recevfrom），以及一个struct sock类型的sk。sock内部具有sk_buff_head类型的接受和发送缓冲区，sk_buff_head内部的sk_buff类型的next和prev指针就和报文联系上了。

TCP协议

TCP 全称为 "传输控制协议( Transmission Control Protocol "). 顾名思义, 要对数据的传输进⾏⼀个详细的控制;

TCP协议格式

TCP报头当中各个字段的含义如下：

——源/目的端口号：表示数据是从哪个进程来，到发送到对端主机上的哪个进程。
——32位序号/32位确认序号：分别代表TCP报文当中每个字节数据的编号以及对对方的确认，是TCP保证可靠性的重要字段。
——4位TCP报头长度：表示该TCP报头的长度，长度就是大小的意思（ 表⽰该TCP头部有多少个32位bit(有多少个4字节)），以4字节为单位。
——6位保留字段：TCP报头中暂时未使用的6个比特位。
——16位窗口大小：保证TCP可靠性机制和效率提升机制的重要字段。
——16位检验和：由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部+TCP数据部分）
——16位紧急指针：标识紧急数据在报文中的偏移量，需要配合标志字段当中的URG字段统一使用。
——选项字段：TCP报头当中允许携带额外的选项字段，最多40字节。

TCP报头当中的6位标志位：

-URG：紧急指针是否有效。
-ACK：确认序号是否有效。
-PSH：提示接收端应用程序立刻将TCP接收缓冲区当中的数据读走。
-RST：表示要求对方重新建立连接。我们把携带RST标识的报文称为复位报文段。
-SYN：表示请求与对方建立连接。我们把携带SYN标识的报文称为同步报文段。
-FIN：通知对方，本端要关闭了。我们把携带FIN标识的报文称为结束报文段。

TCP报头在内核当中本质就是一个位段类型，给数据封装TCP报头时，实际上就是用该位段类型定义一个变量，然后填充TCP报头当中的各个属性字段，最后将这个TCP报头拷贝到数据的首部，至此便完成了TCP报头的封装。

如何分离报头和有效载荷？

如果是标准报头，TCP协议的报文的完整报头固定20个字节，提取前20个字节就拿到了TCP报头，余下的就是有效载荷。如果还带有选项，那么可以根据4位头部长度求出TCP头部总长度（总字节）（字段值x4），提取这些字节就拿到了报头，余下的就是有效载荷。

但是拿到TCP报文是无法判断是标准报头还是非标准包头的，所以TCP其实是这样分离有效载荷的：

当TCP从底层获取到一个报文后，虽然TCP不知道报头的具体长度，但报文的前20个字节是TCP的基本报头，并且这20字节当中涵盖了4位的首部长度。

当TCP获取到一个报文后，首先读取报文的前20个字节，并从中提取出4位的首部长度，此时便获得了TCP报头的大小size。
如果size的值大于20字节，则需要继续从报文当中读取size-20字节的数据，这部分数据就是TCP报头当中的选项字段。
读取完TCP的基本报头和选项字段后，剩下的就是有效载荷了。

需要注意的是，TCP报头当中的4位首部长度描述的基本单位是4字节。4位首部长度的取值范围是0000 ~ 1111，因此TCP报头最大长度为15 × 4 = 60 字节，因为基本报头的长度是20字节，所以报头中选项字段的长度最多是40字节。

如果TCP报头当中不携带选项字段，那么TCP报头的长度就是20字节，此时报头当中的4位首部长度的值就为20÷4=5，也就是0101。

确认应答机制（ACK）

确认应答机制就是由TCP报头当中的，32位序号和32位确认序号来保证的。需要再次强调的是，确认应答机制不是保证双方通信的全部消息的可靠性，而是通过收到对方的应答消息，来保证自己曾经发送给对方的某一条消息被对方可靠的收到了。

最新的一条消息发送方永远无法确认对方是否收到，所以说没有百分百可靠的协议。但有时并不需要这种确认。只要收到应答，那么就说明发送的消息对方百分百收到了，此时没必要再对应答做出应答。比如下面的通信模式

TCP常规的通信模式

在客户端和服务端的角度，客户端向服务端发送请求，服务端接受请求发回应答，客户端收到应答后就说明请求被服务端完整地接收到了，一次请求一次应答，就此终止，客户端不需要也没必要对服务端的应答再做应答了，客户端只需要关注下一次发送请求，以及请求是否收到（收到应答）。服务端向客户端发送请求，也是一次请求一次应答。这样只需要发送方确认收到对方应答即可，由此保证了通信在客户端到服务端，服务端到客户端两个方向上的可靠性。

发送方确认应答后，就说明消息对方收到了，应答只是保证了需要传输出去的数据，接收方收到了，接收方可以处理这些数据了。然后发送方需要知道数据发送到接收方，所以接收方需要作出应答，应答只是网络通信中的冗余数据，其目的是为了保证数据传输的可靠性。

但是这样，客户端收到上一次请求的应答后，才能发送下一次请求，这样发送消息不就是串型的了，这会导致效率低下，所以TCP真实的通信模式不是这样滴，TCP真实通信模式中，通信的双方地位应该是对等的。

TCP的一般模式下，发送方一次可以发送多个请求，不需要发一个等应答再发下一个，从而提高效率，不过这依旧是确认应答机制。而且发送顺序和接收顺序不一定一致，这就导致数据传输的不可靠。解决方法就是给发送的消息带上序号，从而保证按序到达（可靠性）。

序号与确认序号

TCP将每个字节的数据都进⾏了编号. 即为序列号.

接收端在进行报文重排时，可以根据当前报文的32位序号与其有效载荷的字节数，进而确定下一个报文对应的序号。

• 比如现在发送端要发送3000字节的数据，如果发送端每次发送1000字节，那么就需要用三个TCP报文来发送这3000字节的数据。
• 此时这三个TCP报文当中的32位序号填的就是发送数据中首个字节的序列号，因此分别填的是1、1001和2001。
• 接收端收到了这三个TCP报文后，就可以根据TCP报头当中的32位序列号对这三个报文进行顺序重排（该动作在传输层进行），重排后将其放到TCP的接收缓冲区当中，此时接收端这里报文的顺序就和发送端发送报文的顺序是一样的了。

TCP报头中的确认序列号, 意思是告诉发送者, 接收端已经收到了哪些数据; 下⼀次发送端从确认序号开始发送.

eg：当主机B收到主机A发送过来的32位序号为1的报文时，由于该报文当中包含1000字节的数据，因此主机B已经收到序列号为1-1000的字节数据，于是主机B发给主机A的响应数据的报头当中的32位确认序号的值就会填成1001。

• 一方面是告诉主机A，序列号在1001之前的字节数据我已经收到了。
• 另一方面是告诉主机A，下次向我发送数据时应该从序列号为1001的字节数据开始进行发送。

ps：发送方的消息发送到网络，接收方接收到信息一直到接受缓冲区后，接收方的OS会自动完成应答，这些通信细节全部在应用层之下进行，上层应用也就是客户是感知不到的。

如果报文丢失怎么办？

还是以刚才的例子为例，主机A发送了三个报文给主机B，其中每个报文的有效载荷都是1000字节，这三个报文的32位序号分别是1、1001、2001。

如果这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了1-1000和2001-3000的字节数据。此时主机B在对主机A进行响应时，其响应报头当中的32位确认序号填的就是1001，告诉主机A下次向我发送数据时应该从序列号为1001的字节数据开始进行发送。

注意：

• 此时主机B在给主机A应答时，其32位确认序号不能填3001，因为1001-2000是在3001之前的，如果直接给主机A应答3001，就说明序列号在3001之前的字节数据全都收到了。
• 因此主机B只能给主机A应答1001，当主机A收到该确认序号后就会判定序号为1001的报文丢包了，此时主机A就可以选择进行数据重传。

因此发送端可以根据对端发来的确认序号，来判断是否某个报文可能在传输过程中丢失了。

来回互相发送的是什么？

来回发送的是TCP报文，发送方发送请求一定是带有TCP完整报头+有效载荷的，就收方发送应答不需要带数据，因此只有TCP报头。报头里就有序列号。

为什么要有两套序列号？

如果通信双方只是一端发送数据，另一端接收数据，那么只用一套序号就可以了。比如上面的客户端和服务端。

• 发送端在发送数据时，将该序号看作是32位序号。
• 接收端在对发送端发来的数据进行应答时，将该序号看作是32位确认序号。

但实际TCP却没有这么做，根本原因就是因为TCP是全双工的，双方可能同时想给对方发送消息。

• 双方发出的报文当中，不仅需要填充32位序号来表明自己当前发送数据的序号。
• 还需要填充32位确认序号，对对方上一次发送的数据进行确认，告诉对方下一次应该从哪一字节序号开始进行发送。

因此在进行TCP通信时，双方都需要有确认应答机制，此时一套序号就无法满足需求了，因此需要TCP报头当中出现了两套序号。所以一个报文，既是对上一个报文的确认告诉对方下一次从哪一字节开始发送（应答部分），也是一个数据报文，表明当前发送数据的序号（请求部分），这样效率才高，这才是TCP真实的通信场景模式。

总结一下：

• 32位序号的作用是，保证数据的按序到达，同时这个序号也是作为对端发送报文时填充32位确认序号的根据。
• 32位确认序号的作用是，告诉对端当前已经收到的字节数据有哪些，对端下一次发送数据时应该从哪一字节序号开始进行发送。
• 序号和确认序号是确认应答机制的数据化表示，确认应答机制就是由序号和确认序号来保证的。
• 此外，通过序号和确认序号还可以判断某个报文是否丢失。

窗口大小

当发送端要将数据发送给对端时，本质是把自己发送缓冲区当中的数据发送到对端的接收缓冲区当中。但缓冲区是有大小的，如果接收端处理数据的速度小于发送端发送数据的速度，那么总有一个时刻接收端的接收缓冲区会被打满，这时发送端再发送数据过来就会造成数据丢包，进而引起丢包重传等一系列的连锁反应。

因此TCP报头当中就有了16位的窗口大小，这个16位窗口大小当中填的是自身接收缓冲区中剩余空间的大小，也就是当前主机接收数据的能力。

接收端在对发送端发来的数据进行响应时，就可以通过16位窗口大小告知发送端自己当前接收缓冲区剩余空间的大小，此时发送端就可以根据这个窗口大小字段来调整自己发送数据的速度。

• 窗口大小字段越大，说明接收端接收数据的能力越强，此时发送端可以提高发送数据的速度。
• 窗口大小字段越小，说明接收端接收数据的能力越弱，此时发送端可以减小发送数据的速度。
• 如果窗口大小的值为0，说明接收端接收缓冲区已经被打满了，此时发送端就不应该再发送数据了。

六个标志位

标志位就是结构体位段中的比特位，0表示无效 1表示有效。

为什么会存在标志位？

• TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文，以及断开连接时发送的断开连接的报文等等。
• 收到不同种类的报文时需要执行对应动作，比如正常通信的报文需要放到接收缓冲区当中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作。
• 也就是说不同种类的报文对应的是不同的处理逻辑，所以我们要能够区分报文的种类。而TCP就是使用报头当中的六个标志字段来进行区分的，这六个标志位都只占用一个比特位，为0表示假，为1表示真。

ACK

• 报文当中的ACK被设置为1，表明该报文可以对收到的报文进行确认。
• 一般除了第一个请求报文没有设置ACK以外，其余报文基本都会设置ACK，因为发送出去的数据本身就对对方发送过来的数据具有一定的确认能力，因此双方在进行数据通信时，可以顺便对对方上一次发送的数据进行响应。

SYN

• 报文当中的SYN被设置为1（同步报文段），表明该报文是一个连接建立的请求报文。
• 只有在连接建立阶段，SYN才被设置，正常通信时SYN不会被设置。

FIN

• 报文当中的FIN被设置为1（结束报文段），表明该报文是一个连接断开的请求报文。
• 只有在断开连接阶段，FIN才被设置，正常通信时FIN不会被设置。

PSH

我们一般认为：

• 当使用read/recv从缓冲区当中读取数据时，如果缓冲区当中有数据read/recv函数就能够读到数据进行返回，而如果缓冲区当中没有数据，那么此时read/recv函数就会阻塞住，直到当缓冲区当中有数据时才会读取到数据进行返回。

实际这种说法是不太准确的，其实接收缓冲区和发送缓冲区都有一个水位线的概念。

• 比如我们假设TCP接收缓冲区的水位线是100字节，那么只有当接收缓冲区当中有100字节时才让read/recv函数读取这100字节的数据进行返回。
• 如果接收缓冲区当中有一点数据就让read/recv函数读取返回了，此时read/recv就会频繁的进行读取和返回，进而影响读取数据的效率（在内核态和用户态之间切换也是有成本的）。
• 因此不是说接收缓冲区当中只要有数据，调用read/recv函数时就能读取到数据进行返回，而是当缓冲区当中的数据量达到一定量时才能进行读取。

当报文当中的PSH被设置为1时，实际就是在告知对方操作系统，尽快将接收缓冲区当中的数据交付给上层，尽管接收缓冲区当中的数据还没到达所指定的水位线。这也就是为什么我们使用read/recv函数读取数据时，期望读取的字节数和实际读取的字节数是不一定吻合的。

RST

• 报文当中的RST被设置为1，表示需要让对方重新建立连接。
• 在通信双方在连接未建立好的情况下(比如三次握手第三次握手失败，服务端发送应答报文中的标志位RST置为1)，一方向另一方发数据，此时另一方发送的响应报文当中的RST标志位就会被置1，表示要求对方重新建立连接。
• 在双方建立好连接进行正常通信时，如果通信中途发现之前建立好的连接出现了异常也会要求重新建立连接。

URG（实际中很少使用，因为不好用）

双方在进行网络通信的时候，由于TCP是保证数据按序到达的，即便发送端将要发送的数据分成了若干个TCP报文进行发送，最终到达接收端时这些数据也都是有序的，因为TCP可以通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中时是有序的。

TCP按序到达本身也是我们的目的，此时对端上层在从接收缓冲区读取数据时也必须是按顺序读取的。但是有时候发送端可能发送了一些“紧急数据”，这些数据需要**“插队”（本质）（“插队”的不是数据本身，而是“有紧急数据到达”的这个通知。​ 它打断了应用程序的正常工作流，告诉它：“快去看看你的TCP连接，有条重要消息在等着你，但它还排在缓冲区里。）**让对方上层提取进行读取，此时应该怎么办呢？

举一个实际例子：

往云盘中上传很大的资源，上传到一半，不想上传，终止上传，这个终止就是云盘服务器上层要读取的紧急数据，从而立刻终止上传，而不是等待资源上传完再终止。

此时就需要用到URG标志位，以及TCP报头当中的16位紧急指针。

• 当URG标志位被设置为１时，需要通过TCP报头当中的16位紧急指针来找到紧急数据，否则一般情况下不需要关注TCP报头当中的16位紧急指针。
• 16位紧急指针代表的就是紧急数据在报文段数据部分中的偏移量。
• 因为紧急指针只有一个，它只能标识数据段中的一个位置，紧急指针指向的是最后一个紧急字节的下一字节的位置，从数据部分的第一个字节开始，到紧急指针所指向的位置（但不包括这个位置）之前的所有数据，都被视为紧急数据。

如何读取排队中的紧急数据——>带外数据

recv函数的第四个参数flags有一个叫做MSG_OOB的选项可供设置，其中OOB是带外数据（out-of-band）的简称，带外数据就是一些比较重要的数据，因此上层如果想读取紧急数据，就可以在使用recv函数进行读取，并设置MSG_OOB选项。这样读取就不再按序读取，而是直接读取紧急数据的最后一个字节（对于某些非常特定的场景，只读取一个字节是足够的。但对于绝大多数现代应用需求来说，这远远不够，而且极不可靠），如果后续还有内容，这个位置就会出现缺漏，破坏了TCP的流式特性。**但紧急数据本身在接收缓冲区中仍然是按序存放的。**​ 这个机制由于设计复杂且容易出错，在实践中基本已被抛弃。

与之对应的send函数的第四个参数flags也提供了一个叫做MSG_OOB的选项，上层如果想发送紧急数据，就可以使用send函数进行写入，并设置MSG_OOB选项。

保证TCP的可靠性的机制

连接管理机制

TCP是面向连接的

TCP的各种可靠性机制实际都不是从主机到主机的，而是基于连接的，与连接是强相关的。比如一台服务器启动后可能有多个客户端前来访问，如果TCP不是基于连接的，也就意味着服务器端只有一个接收缓冲区，此时各个客户端发来的数据都会拷贝到这个接收缓冲区当中，此时这些数据就可能会互相干扰。

而我们在进行TCP通信之前需要先建立连接，就是因为TCP的各种可靠性保证都是基于连接的，要保证传输数据的可靠性的前提就是先建立好连接。连接的本质：为通信双方创建一个独立的“会话上下文”。这个会话包括独立的缓冲区，独立的状态变量，独立的控制逻辑。

操作系统对连接的管理

面向连接是TCP可靠性的一种，只有在通信建立好连接才会有各种可靠性的保证，而一台机器上可能会存在大量的连接，此时操作系统就不得不对这些连接进行管理。

• 操作系统在管理这些连接时需要“先描述，再组织”，在操作系统中一定有一个描述连接的结构体，该结构体当中包含了连接的各种属性字段，所有定义出来的连接结构体最终都会以某种数据结构组织起来，此时操作系统对连接的管理就变成了对该数据结构的增删查改。
• 建立连接，实际就是在操作系统中用该结构体定义一个结构体变量，然后填充连接的各种属性字段，最后将其插入到管理连接的数据结构当中即可。
• 断开连接，实际就是将某个连接从管理连接的数据结构当中删除，释放该连接曾经占用的各种资源。
• 因此连接的管理也是有成本的，这个成本就是管理连接结构体的时间成本，以及存储连接结构体的空间成本。

三次握手

在正常情况下, TCP要经过三次握⼿建⽴连接, 四次挥⼿断开连接，下面我们来介绍三次握手。

以服务器和客户端为例，当客户端想要与服务器进行通信时，需要先与服务器建立连接，此时客户端作为主动方会先向服务器发送连接建立请求，然后双方TCP在底层会自动进行三次握手。

• 第一次握手：客户端向服务器发送的报文当中的SYN位被设置为1，表示请求与服务器建立连接。
• 第二次握手：服务器收到客户端发来的连接请求报文后，紧接着向客户端发起连接建立请求并对客户端发来的连接请求进行响应，此时服务器向客户端发送的报文当中的SYN位和ACK位均被设置为1。
• 第三次握手：客户端收到服务器发来的报文后，得知服务器收到了自己发送的连接建立请求，并请求和自己建立连接，最后客户端再向服务器发来的报文进行响应。

就好比你和一个人表白，你对他说我喜欢你，我心里有你我们在一起吧（SYN），如果对方也喜欢你，他就会说我同意在一起，我心里也有你（ACK+SYN），等你知道后，回复好的（ACK），你俩就成一对了。

为什么客户端向服务端请求连接，服务端同意连接后还需要向客户端请求连接呢？

需要注意的是，客户端向服务器发起的连接建立请求，是请求建立从客户端到服务器方向的通信连接，而TCP是全双工通信，因此服务器在收到客户端发来的连接建立请求后，服务器也需要向客户端发起连接建立请求，请求建立从服务器到客户端方法的通信连接。换言之就是需要验证双方的通信通道，也就是为什么要三次握手问题。

*为什么是三次握手？

首先我们需要知道，连接建立不是百分之百能成功的，通信双方在进行三次握手时，其中前两次握手能够保证被对方收到，因为前两次握手都有对应的下一次握手对其进行响应，但第三次握手是没有对应的响应报文的，如果第三次握手时客户端发送的ACK报文丢失了，那么连接建立就会失败。

虽然客户端发起第三次握手后就完成了三次握手，但服务器却没有收到客户端发来的第三次握手，此时服务器端就不会建立对应的连接。所以建立连接时不管采用几次握手，最后一次握手的可靠性都是不能保证的。

既然连接的建立都不是百分之百成功的，因此建立连接时具体采用几次握手的依据，实际是看几次握手时的优点更多。

三次握手是验证双方通信信道的最小次数：

• 因为TCP是全双工通信的，因此连接建立的核心要务实际是，验证双方的通信信道是否是连通的。
• 在客户端看来，当它收到服务器发来第二次握手时，说明自己发出的第一次握手被对方可靠的收到了，证明自己能发以及服务器能收，同时当自己收到服务器发来的第二次握手时，也就证明服务器能发以及自己能收，此时就证明自己和服务器都是能发能收的。
• 在服务器看来，当它收到客户端发来第一次握手时，证明客户端能发以及自己能收，而当它收到客户端发来的第三次握手时，说明自己发出的第二次握手被对方可靠的收到了，也就证明自己能发以及客户端能收，此时就证明自己和客户端都是能发能收的。
• 三次握手恰好是验证双方通信信道的最小次数，通过三次握手后双方就都能知道自己和对方是否都能够正常发送和接收数据。
• 既然三次握手已经能够验证双方通信信道是否正常了，那么三次以上的握手当然也是可以验证的，但既然三次已经能验证了就没有必要再进行更多次的握手了。

如果是两次握手，我们无法确认客户端的接收能力。如果是四次握手，因为捎带应答（确认报文和数据报文合二为一）可以将四次握手的第二次（ACK）和第三次（SYN）合并，四次握手多余低效。

三次握手能够保证连接建立时的异常连接挂在客户端：

• 当客户端收到服务器发来的第二次握手时，客户端就已经证明双方通信信道是连通的了，因此当客户端发出第三次握手后，这个连接就已经在客户端建立了。
• 而只有当服务器收到客户端发来的第三次握手后，服务器才知道双方通信信道是连通的，此时在服务器端才会建立对应的连接。
• 因此双方在进行三次握手建立连接时，双方建立连接的时间点是不一样的。如果客户端最后发出的第三次握手丢包了，此时在服务器端就不会建立对应的连接，而在客户端就需要短暂的维护一个异常的连接。
• 而维护连接是需要时间成本和空间成本的，因此三次握手还有一个好处就是能够保证连接建立异常时，这个异常连接是挂在客户端的，而不会影响到服务器。
• 虽然此时客户端也需要短暂维护这个异常，但客户端的异常连接不会特别多，不像服务器，一旦多个客户端建立连接时都建立失败了，此时服务器端就需要耗费大量资源来维护这些异常连接。
• 此外，建立连接失败时的异常连接不会一直维护下去。如果服务器端长时间收不到客户端发来的第三次握手，就会将第二次握手进行超时重传，此时客户端就有机会重新发出第三次握手。或者当客户端认为连接建立好后向服务器发送数据时，此时服务器会发现没有和该客户端建立连接而要求客户端重新建立连接。

总结一下，建立两个连接采用三次握手的理由：

• 三次握手是验证双方通信信道的最小次数，能够让能建立的连接尽快建立起来。
• 三次握手能够保证连接建立时的异常连接挂在客户端（风险转移）。

三次握手时的状态变化

三次握手时的状态变化如下：

• 最开始时客户端和服务器都处于CLOSED状态。
• 服务器为了能够接收客户端发来的连接请求，需要由CLOSED状态变为LISTEN状态。
• 此时客户端就可以向服务器发起三次握手了，当客户端发起第一次握手后，状态变为SYN_SENT状态。
• 处于LISTEN状态的服务器收到客户端的连接请求后，将该连接放入内核等待队列中，并向客户端发起第二次握手，此时服务器的状态变为SYN_RCVD。
• 当客户端收到服务器发来的第二次握手后，紧接着向服务器发送最后一次握手，此时客户端的连接已经建立，状态变为ESTABLISHED。
• 而服务器收到客户端发来的最后一次握手后，连接也建立成功，此时服务器的状态也变成ESTABLISHED。

至此三次握手结束，通信双方可以开始进行数据交互了。

套接字和三次握手的关联

• 在客户端发起连接建立请求之前，服务器需要先进入LISTEN状态，此时就需要服务器调用对应listen函数。
• 当服务器进入LISTEN状态后，客户端就可以向服务器发起三次握手了，此时客户端对应调用的就是connect函数。
• 需要注意的是，connect函数不参与底层的三次握手，connect函数的作用只是发起三次握手。当connect函数返回时，要么是底层已经成功完成了三次握手连接建立成功，要么是底层三次握手失败。
• 如果服务器端与客户端成功完成了三次握手，此时在服务器端就会建立一个连接，但这个连接在内核的等待队列当中，服务器端需要通过调用accept函数将这个建立好的连接获取上来。accept函数也不参与三次握手，只获取已经建立好的连接。
• 当服务器端将建立好的连接获取上来后，双方就可以通过调用read/recv函数和write/send函数进行数据交互了。

四次挥手

由于双方维护连接都是需要成本的，因此当双方TCP通信结束之后就需要断开连接，断开连接的这个过程我们称之为四次挥手。

还是以服务器和客户端为例，当客户端与服务器通信结束后，需要与服务器断开连接，此时就需要进行四次挥手。

• 第一次挥手：客户端向服务器发送的报文当中的FIN位被设置为1，表示请求与服务器断开连接。
• 第二次挥手：服务器收到客户端发来的断开连接请求后对其进行响应。
• 第三次挥手：服务器收到客户端断开连接的请求，且已经没有数据需要发送给客户端的时候，服务器就会向客户端发起断开连接请求。
• 第四次挥手：客户端收到服务器发来的断开连接请求后对其进行响应。

四次挥手结束后双方的连接才算真正断开。

为什么是四次挥手？

• 由于TCP是全双工的，建立连接的时候需要建立双方的连接，断开连接时也同样如此。在断开连接时不仅要断开从客户端到服务器方向的通信信道，也要断开从服务器到客户端的通信信道，其中每两次挥手对应就是关闭一个方向的通信信道，因此断开连接时需要进行四次挥手。
• 需要注意的是，四次挥手当中的第二次和第三次挥手不能合并在一起，因为第三次挥手是服务器端想要与客户端断开连接时发给客户端的请求，而当服务器收到客户端断开连接的请求并响应后，服务器不一定会马上发起第三次挥手，因为服务器可能还有某些数据要发送给客户端，只有当服务器端将这些数据发送完后才会向客户端发起第三次挥手。

四次挥手状态变化

四次挥手时的状态变化如下：

• 在挥手前客户端和服务器都处于连接建立后的ESTABLISHED状态。
• 客户端为了与服务器断开连接主动向服务器发起连接断开请求，此时客户端的状态变为FIN_WAIT_1。
• 服务器收到客户端发来的连接断开请求后对其进行响应，此时服务器的状态变为CLOSE_WAIT。
• 当服务器没有数据需要发送给客户端的时，服务器会向客户端发起断开连接请求，等待最后一个ACK到来，此时服务器的状态变为LAST_ACK。
• 客户端收到服务器发来的第三次挥手后，会向服务器发送最后一个响应报文，此时客户端进入TIME_WAIT状态。
• 当服务器收到客户端发来的最后一个响应报文时，服务器会彻底关闭连接，变为CLOSED状态。
• 而客户端则会等待一个2MSL（Maximum Segment Lifetime，报文最大生存时间）才会进入CLOSED状态。

至此四次挥手结束，通信双方成功断开连接。

套接字与四次挥手的关联

• 客户端发起断开连接请求，对应就是客户端主动调用close函数。
• 服务器发起断开连接请求，对应就是服务器主动调用close函数。
• 一个close对应的就是两次挥手，双方都要调用close，因此就是四次CLOSE_WAIT

CLOSE_WAIT

• 双方在进行四次挥手时，如果只有客户端调用了close函数，而服务器不调用close函数，此时服务器就会进入CLOSE_WAIT状态，而客户端则会进入到FIN_WAIT_2状态。
• 但只有完成四次挥手后连接才算真正断开，此时双方才会释放对应的连接资源。如果服务器没有主动关闭不需要的文件描述符，此时在服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少。
• 因此如果不及时关闭不用的文件描述符，除了会造成文件描述符泄漏以外，可能也会导致连接资源没有完全释放，这其实也是一种内存泄漏的问题。
• 因此在编写网络套接字代码时，如果发现服务器端存在大量处于CLOSE_WAIT状态的连接，此时就可以检查一下是不是服务器没有及时调用close函数关闭对应的文件描述符。

TIME_WAIT

四次挥手丢包都会引发超时重传：

• 第一次挥手丢包：客户端收不到服务器的应答，进而进行超时重传。
• 第二次挥手丢包：客户端收不到服务器的应答，进而进行超时重传。
• 第三次挥手丢包：服务器收不到客户端的应答，进而进行超时重传。
• 第四次挥手丢包：服务器收不到客户端的应答，进而进行超时重传。

如果客户端在发出第四次挥手后立即进入CLOSED状态，如果发生丢包，此时服务器即使进行了超时重传，但已经得不到客户端的响应了，因为客户端已经将连接关闭了。

服务器在经过若干次超时重发后得不到响应，最终也一定会将对应的连接关闭，但在服务器不断进行超时重传期间还需要维护这条废弃的连接，这显然浪费服务器资源。

为了避免这种情况，因此客户端在四次挥手后没有立即进入CLOSED状态，而是进入到了TIME_WAIT状态进行等待，此时要是第四次挥手的报文丢包了，客户端也能收到服务器重发的报文然后进行响应。

TIME_WAIT存在的意义

• 客户端在进行四次挥手后进入TIME_WAIT状态，如果第四次挥手的报文丢包了，客户端在一段时间内仍然能够接收服务器重发的FIN报文并对其进行响应，能够较大概率保证最后一个ACK被服务器收到。
• 客户端发出最后一次挥手时，双方历史通信的数据可能还没有发送到对方。因此客户端四次挥手后进入TIME_WAIT状态，还可以保证双方通信信道上的数据在网络中尽可能的消散。

TIME_WAIT的等待时间

• 太长会让等待方维持一个较长的时间的TIME_WAIT状态，在这个时间内等待方也需要花费成本来维护这个连接，这也是一种浪费资源的现象。
• 太短可能没有达到我们最初目的，没有保证ACK被对方较大概率收到，也没有保证数据在网络中消散，此时TIME_WAIT的意义也就没有了。

TCP协议规定，主动关闭连接的一方在四次挥手后要处于TIME_WAIT状态，等待两个MSL（Maximum Segment Lifetime，报文最大生存时间）的时间才能进入CLOSED状态。

可以通过cat /proc/sys/net/ipv4/tcp_fin_timeout命令来查看MSL的值

TIME_WAIT的等待时长设置为两个MSL的原因

• MSL是TCP报文的最大生存时间，因此TIME_WAIT状态持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或发送的报文段都已经消散。
• 同时也是在理论上保证最后一个报文可靠到达的时间。（如果2MSL时间内主动关闭连接的一方都没有收到接收端的超时重传，就说明最后携带ACK的报文接收端收到了）

这也就是为什么服务端主动关闭后，立即重启服务端会绑定失败，等待一段时间后再重启才能成功的原因，因为服务端主动关闭四次挥手后处于TIME_WAIT状态！需要等待2MSL时间后才能变成CLOSED状态才能绑定从而重启。

这时只有服务器更换端口号或者等待2MSL后才能重启，服务器不能随意更改端口号，但如果因为连接超出上限导致服务器关闭，2MSL的等待时间势必会造成损失。那有没有办法可以让关闭的服务器不更改端口号的情况下立即重启呢？

使用 SO_REUSEADDR套接字选项

服务器在创建监听套接字后、绑定端口前，可以设置一个套接字选项：

setsockopt(listen_sock, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, ...);

• SO_REUSEADDR：允许一个新的套接字绑定到一个端口，即使该端口已经被处于TIME-WAIT状态的套接字占用
• SO_REUSEPORT：允许服务器端启动多个进程，并且让每个进程都能同时、独立地监听在完全相同的IP和端口上

**所以，在生产环境中，几乎所有服务器程序都会设置 SO_REUSEADDR选项，以避免重启时的等待。**​ 更换端口通常是不得已而为之的最后手段。

---

超时重传机制

双方在进行网络通信时，发送方发出去的数据在一个特定的事件间隔内如果得不到对方的应答，此时发送方就会进行数据重发，这就是TCP的超时重传机制。

需要注意的是，TCP保证双方通信的可靠性，一部分是通过TCP的协议报头体现出来的，还有一部分是通过实现TCP的代码逻辑体现出来的。

比如超时重传机制实际就是发送方在发送数据后开启了一个定时器，若是在这个时间内没有收到刚才发送数据的确认应答报文，则会对该报文进行重传，这就是通过TCP的代码逻辑实现的，而在TCP报头当中是体现不出来的。

重新理解丢包：丢包的两种情况

丢包分为两种情况，一种是发送的数据报文丢失了，此时发送端在一定时间内收不到对应的响应报文，就会进行超时重传。

另一种情况就是对方发来的响应报文丢包了，此时发送端也会因为收不到对应的响应报文，而进行超时重传。

注意：

• 所以，当出现丢包时，发送方是无法辨别是发送的数据报文丢失了，还是对方发来的响应报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时发送方就只能进行超时重传。
• 如果是对方的响应报文丢失而导致发送方进行超时重传，此时接收方就会再次收到一个重复的报文数据，但此时也不用担心，接收方可以根据报头当中的32位序号来判断曾经是否收到过这个报文，从而达到报文去重的目的。
• 需要注意的是，当发送缓冲区当中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区当中删除或覆盖，而会让其保留在发送缓冲区当中，以免需要进行超时重传，直到收到该数据的响应报文后，发送缓冲区中的这部分数据才可以被删除或覆盖。

超时重传的等待时间

• 超时重传的时间设置的太长，会导致丢包后对方长时间收不到对应的数据，进而影响整体重传的效率。
• 超时重传的时间设置的太短，会导致对方收到大量的重复报文，可能对方发送的响应报文还在网络中传输而并没有丢包，但此时发送方就开始进行数据重传了，并且发送大量重复报文会也是对网络资源的浪费。

因此超时重传的时间一定要是合理的，最理想的情况就是找到一个最小的时间，保证“确认应答一定能在这个时间内返回”。但这个时间的长短，是与网络环境有关的。网好的时候重传的时间可以设置的短一点，网卡的时候重传的时间可以设置的长一点，也就是说超时重传设置的等待时间一定是上下浮动的，因此这个时间不可能是固定的某个值。

TCP为了保证无论在任何环境下都能有比较高性能的通信，因此会动态计算这个最大超时时间。

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
• 如果重发一次之后，仍然得不到应答，下一次重传的等待时间就是2 × 500 ms。
• 如果仍然得不到应答，那么下一次重传的等待时间就是4 × 500 ms。以此类推，以指数的形式递增。
• 当累计到一定的重传次数后，TCP就会认为是网络或对端主机出现了异常，进而强转关闭连接。

就像当初动态开辟数组空间，每次开2倍大小。

流量控制

TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度，这个机制叫做流量控制（Flow Control）。

接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，此时发送端继续发送数据，就会造成丢包，进而引起丢包重传等一系列连锁反应。

因此接收端可以将自己接收数据的能力告知发送端，让发送端控制自己发送数据的速度。

• 接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端。
• 窗口大小字段越大，说明网络的吞吐量越高。
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端。
• 发送端接收到这个窗口之后，就会减慢自己发送的速度。
• 如果接收端缓冲区满了，就会将窗口值设置为0，这时发送方不再发送数据，但需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据。

• 等待告知。接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将自己的窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了。
• 主动询问。发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了。

16位数字最⼤表⽰65535, 那么TCP窗⼝最⼤就是65535字节么?

实际上, TCP⾸部40字节选项中还包含了⼀个窗⼝扩⼤因⼦M, 实际窗⼝⼤⼩是 窗⼝字段的值左移 M 位。

第一次向对方发送数据时肯定需要提前得知对方的窗口大小，如何做到的？

双方在进行TCP通信之前需要先进行三次握手建立连接，而双方在握手时除了验证双方通信信道是否通畅以外，还进行了其他信息的交互，其中就包括告知对方自己的接收能力，因此在双方还没有正式开始通信之前就已经知道了对方接收数据能力，所以双方在发送数据时是不会出现缓冲区溢出的问题的。

滑动窗口

上一次见到这个名词还是在算法题里啊~

前面我们讨论了确认应答策略, 对每⼀个发送的数据段, 都要给⼀个ACK确认应答. 收到ACK后再发送下⼀个数据段. 这样做有⼀个⽐较⼤的缺点, 就是性能较差. 尤其是数据往返的时间较⻓的时候

既然这样⼀发⼀收的⽅式性能较低, 那么我们⼀次发送多条数据, 就可以⼤大提⾼性能(其实是将多个段的等待时间重叠在⼀起了).

何谓滑动窗口

滑动窗口描述的是 发送方不用等待ACK一次所能发送的数据最大量。

滑动窗⼝⼤⼩指的是暂时⽆需等待确认应答⽽可以继续发送数据的最⼤值.

上图的滑动窗⼝⼤⼩就是4000个字节(四个段).

• 发送前四个段的时候, 不需要等待任何ACK, 直接发送;

• 收到第⼀个ACK后, 滑动窗⼝向后移动, 继续发送第五个段的数据; 依次类推;

• 操作系统内核为了维护这个滑动窗⼝, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;

• 窗⼝越⼤, 则⽹络的吞吐率就越⾼;

滑动窗口位于发送缓冲区

既然**滑动窗⼝指的是暂时⽆需等待确认应答⽽可以继续发送的数据.**那滑动窗口就是位于发送缓冲区了。

其实可以将发送缓冲区当中的数据分为三部分：

• 已经发送并且已经收到ACK的数据。
• 已经发送还但没有收到ACK的数据。
• 还没有发送的数据。

这里发送缓冲区的第二部分就叫做滑动窗口。（也有人把这三部分整体称之为滑动窗口，而将其中的第二部分称之为窗口大小）

已发送收到ACK的数据就无效了，这些数据是可以覆盖的。

因为缓冲区其实就是一个数组，那么滑动窗口其实就是两个下标中间的区间，下标++就是滑动，这在滑动窗口算法中别无二致。

滑动窗口只能向右移动吗？

是的，因为要发送的数据在右边。但并不是一定整体向右移动，因为滑动窗口大小是不固定的。

滑动窗口大小是否固定？

否。

滑动窗口=对方ACK报文中的win窗口大小决定（即对方的接收能力）。

所以流量控制是基于滑动窗口实习的。

所以滑动窗口大小是这样确定的：

start=确定序号，end=start+win窗口大小。

窗口大小>=0，所以end>=start

举例说明滑动窗口何时变大变小不变：

变小：给对发送数据，但对方应用上层还不取数据，导致接收缓冲区剩余大小变小，于是滑动窗口变小。

以刚才的例子为例，假设对方已经收到了1001-2000的数据段并进行了响应，但对方上层一直不从接收缓冲区当中读取数据，此时当对方收到1001-2000的数据段时，对方的窗口大小就由4000变为了3000。

当发送端收到对方的响应序号为2001时，就会将1001-2000的数据段归置到滑动窗口的左侧，但此时由于对方的接收能力变为了3000，而当1001-2000的数据段归置到滑动窗口的左侧后，滑动窗口的大小刚好就是3000，因此滑动窗口的右侧不能继续向右进行扩展。

不变就是：发送到对方接收缓冲区的数据，对方立马读取了，接收缓冲区剩余大小不变，滑动窗口大小就不变。

变大就是：对方接收缓冲区可能有积累，本来我是发一个数据段对方就读取一个数据段，这样维持滑动窗口大小不变。但是对方可能连着前面积累的数据段一起读取，接收缓冲区剩余大小变大，滑动窗口变大。

*丢包问题

当发送端一次发送多个报文数据时，此时的丢包情况也可以分为两种。

情况一： 数据包已经抵达，ACK丢包。

在发送端连续发送多个报文数据时，部分ACK丢包并不要紧，此时可以通过后续的ACK进行确认。

比如图中2001-3000和4001-5000的数据包对应的ACK丢失了，但只要发送端收到了最后5001-6000数据包的响应，此时发送端也就知道2001-3000和4001-5000的数据包实际上被接收端收到了的，因为如果接收方没有收到2001-3000和4001-5000的数据包是设置确认序号为6001的，确认序号为6001的含义就是序号为1-6000的字节数据我都收到了，你下一次应该从序号为6001的字节数据开始发送。

情况二： 数据包丢了。

• 当1001-2000的数据包丢失后，发送端会一直收到确认序号为1001的响应报文，就是在提醒发送端“下一次应该从序号为1001的字节数据开始发送”。
• 如果发送端连续收到三次确认序号为1001的响应报文，此时就会将1001-2000的数据包重新进行发送。
• 此时当接收端收到1001-2000的数据包后，就会直接发送确认序号为6001的响应报文，因为2001-6000的数据接收端其实在之前就已经收到了。

这种机制被称为“高速重发控制”，也叫做“快重传”。

需要注意的是，快重传需要在大量的数据重传和个别的数据重传之间做平衡，实际这个例子当中发送端并不知道是1001-2000这个数据包丢了，当发送端重复收到确认序号为1001的响应报文时，理论上发送端应该将1001-7000的数据全部进行重传，但这样可能会导致大量数据被重复传送，所以发送端可以尝试先把1001-2000的数据包进行重发，然后根据重发后的得到的确认序号继续决定是否需要重发其它数据包。

快重传vs超时重传

• 快重传是能够快速进行数据的重发，当发送端连续收到三次相同的应答时就会触发快重传，而不像超时重传一样需要通过设置重传定时器，在固定的时间后才会进行重传。
• 虽然快重传能够快速判定数据包丢失，但快重传并不能完全取待超时重传，因为有时数据包丢失后可能并没有收到对方三次重复的应答，此时快重传机制就触发不了，而只能进行超时重传。
• 因此快重传虽然是一个效率上的提升，但超时重传却是所有重传机制的保底策略，也是必不可少的。

二者是不可替代，相互补充的。

与滑动窗口的联系

滑动窗⼝指的是暂时⽆需等待确认应答⽽可以继续发送的数据.

那么丢包无非是以下三种情况：

1.最左侧报文丢包

2.中间报文丢包

3.最右侧报文丢包

真实情况就是上三者的自由组合。

最左侧报文丢包，那么滑动窗口的左侧不会移动。之前我们提到，发送缓冲区的数据在发送出去后以防发生丢包需要重传，并不会立即删除，而是会暂存一段时间，其实对应的就是滑动窗口的左侧不移动，从而实现的。所以重传也是基于滑动窗口实现的！

中间报文丢包和最右侧报文丢包，其实也都会转换成滑动窗口最左侧报文丢包。

滑动窗口会存在越界的情况吗？

不存在，逻辑上我们可以将发送缓冲区想象成一个环形队列，如果移动到末尾，会根据内部的算法移动到缓冲区开头的位置。所以既然是环状的，就不存在越界的情况发生了。

为啥滑动窗口的数据，不打包成一个报文发送，而是采用分成一个个小报文发送呢？

涉及链路层。。。未完待续。。

总结一下：

是什么？滑动窗口是输出缓冲区中的一小段，可以暂时不用应答，可以直接发送的数据区域。

为什么？滑动窗口是流量控制，重传机制的底层实现。

如何实现？int start = sck_seq , end=start + win ;

拥塞控制

为何要有拥塞控制？

两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发。但如果双方在通信时出现了大量丢包（差不多丢包率1％左右一般拥堵，5％左右严重拥堵），此时就不能认为是正常现象了。

TCP不仅考虑了通信双端主机的问题，同时也考虑了网络的问题。

• 流量控制：考虑的是对端接收缓冲区的接收能力，进而控制发送方发送数据的速度，避免对端接收缓冲区溢出。
• 滑动窗口：考虑的是发送端不用等待ACK一次所能发送的数据最大量，进而提高发送端发送数据的效率。
• 拥塞窗口：考虑的是双方通信时网络的问题，如果发送的数据超过了拥塞窗口的大小就可能会引起网络拥塞。

双方网络通信时出现少量的丢包TCP是允许的，但一旦出现大量的丢包，此时量变引起质变，这件事情的性质就变了，此时TCP就不再推测是双方接收和发送数据的问题，而判断是双方通信信道网络出现了拥塞问题。此时就需要拥塞控制了。

如何解决网络拥塞问题，网络拥塞如何控制？

网络出现大面积瘫痪时，通信双方作为网络当中两台小小的主机，看似并不能为此做些什么，但“雪崩的时候没有一片雪花是无辜的”，网络出现问题一定是网络中大部分主机共同作用的结果。

• 如果网络中的主机在同一时间节点都大量向网络当中塞数据，此时位于网络中某些关键节点的路由器下就可能排了很长的报文，最终导致报文无法在超时时间内到达对端主机，此时也就导致了丢包问题。
• 当网络出现拥塞问题时，通信双方虽然不能提出特别有效的解决方案，但双方主机可以做到不加重网络的负担。
• 双方通信时如果出现大量丢包，不应该立即将这些报文进行重传，而应该少发数据甚至不发数据，等待网络状况恢复后双方再慢慢恢复数据的传输速率。

需要注意的是，网络拥塞时影响的不只是一台主机，而几乎是该网络当中的所有主机，此时所有使用TCP传输控制协议的主机都会执行拥塞避免算法。

因此拥塞控制看似只是谈论的一台主机上的通信策略，实际这个策略是所有主机在网络崩溃后都会遵守的策略。一旦出现网络拥塞，该网络当中的所有主机都会受到影响，此时所有主机都要执行拥塞避免，这样才能有效缓解网络拥塞问题。通过这样的方式就能保证雪崩不会发生，或雪崩发生后可以尽快恢复。

拥塞窗口，拥塞控制！

虽然TCP有了滑动窗⼝这个⼤杀器, 能够⾼效可靠的发送⼤量的数据. 但是如果在刚开始阶段就发送⼤量的数据, 仍然可能引发问题.
因为⽹络上有很多的计算机, 可能当前的⽹络状态就已经⽐较拥堵. 在不清楚当前⽹络状态下, 贸然发送⼤量的数据, 是很有可能引起雪上加霜的.
TCP引⼊ 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的⽹络拥堵状态, 再决定按照多⼤的速度传输数据;

• 此处引⼊⼀个概念称为拥塞窗⼝(本质等同一个int变量)

• 发送开始的时候, 定义拥塞窗⼝⼤⼩为1;

• 每次收到⼀个ACK应答, 拥塞窗⼝加1;

• 每次发送数据包的时候, 将拥塞窗⼝和接收端主机反馈的窗⼝⼤⼩做⽐较, 取较⼩的值作为实际发

送的窗⼝;此乃滑动窗口之真意。start=ack_seq; end= start + min( win, 拥塞窗口 ).

像上⾯这样的拥塞窗⼝增⻓速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增⻓速度⾮常快.

• 为了不增⻓的那么快, 因此不能使拥塞窗⼝单纯的加倍.

• 此处引⼊⼀个叫做慢启动的阈值

• 当拥塞窗⼝超过这个阈值的时候, 不再按照指数⽅式增⻓, ⽽是按照线性⽅式增⻓

• 当TCP开始启动的时候, 慢启动阈值等于拥塞窗⼝理论最⼤值**（相当于取消阈值限制）**;

把网络想象成一个管道，假设是一个矩形，那么宽度就是带宽，长度就是RTT（一次消息发送并收到ACK的时间）。那么拥塞窗口的理论最大值就是 带宽*RTT

• 在每次超时重发的时候, 慢启动阈值会变成原来的⼀半（既然在当前的 cwnd大小下发生了拥塞，那就说明网络的承受能力大概只有当前值的一半。****）, 同时拥塞窗⼝置回1（给网络足够的时间去排空缓存中的数据包，相当于让网络“重启”****）; 少量的丢包, 我们仅仅是触发超时重传; ⼤量的丢包, 我们就认为⽹络拥塞; 当TCP通信开始后, ⽹络吞吐量会逐渐上升; 随着⽹络发⽣拥堵, 吞吐量会⽴刻下降;

拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对⽅（慢启动但指数级增长）, 但是⼜要避免给⽹络造成太⼤压⼒的折中⽅案（慢启动，慢启动阈值）.

TCP拥塞控制这样的过程, 就好像 热恋的感觉

写着写着突然思考，如果我的慢启动阈值设置到很低了，但是网络突然间变得特别好了，这会影响我传输的效率啊，那是怎么解决的？

TCP拥塞控制的演进史，就是一部在**“稳定性”​ 和“效率”**​ 之间不断寻找新平衡点的历史。

延迟应答

如果接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能比较小。

延迟应答的目的不是为了保证可靠性，而是留出一点时间让接收缓冲区中的数据尽可能被上层应用层消费掉，此时在进行ACK响应的时候报告的窗口大小就可以更大，从而增大网络吞吐量，进而提高数据的传输效率。

此外，不是所有的数据包都可以延迟应答。

• 数量限制：每个N个包就应答一次。
• 时间限制：超过最大延迟时间就应答一次（这个时间不会导致误超时重传）。

延迟应答具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms。

捎带应答

捎带应答也是为了提高数据的传输效率。

捎带应答其实是TCP通信时最常规的一种方式，就好比主机A给主机B发送了一条消息，当主机B收到这条消息后需要对其进行ACK应答，但如果主机B此时正好也要给主机A发生消息，此时这个ACK就可以搭顺风车，而不用单独发送一个ACK应答，此时主机B发送的这个报文既发送了数据，又完成了对收到数据的响应，这就叫做捎带应答。三次握手里第二次握手就是捎带应答。

面向字节流

当创建一个TCP的socket时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。

• 调用write函数就可以将数据写入发送缓冲区中，此时write函数就可以进行返回了，接下来发送缓冲区当中的数据就是由TCP自行进行发送的。
• 如果发送的字节数太长，TCP会将其拆分成多个数据包发出。如果发送的字节数太短，TCP可能会先将其留在发送缓冲区当中，等到合适的时机再进行发送。
• 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区，可以通过调用read函数来读取接收缓冲区当中的数据。
• 而调用read函数读取接收缓冲区中的数据时，也可以按任意字节数进行读取。

由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：

• 写100个字节数据时，可以调用一次write写100字节，也可以调用100次write，每次写一个字节。
• 读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read100个字节，也可以一次read一个字节，重复100次。

实际对于TCP来说，它并不关心发送缓冲区当中的是什么数据，在TCP看来这些只是一个个的字节数据，它的任务就是将这些数据准确无误的发送到对方的接收缓冲区当中就行了，而至于如何解析这些数据完全由上层应用来决定，这就叫做面向字节流。

粘包问题

• 首先要明确，粘包问题中的“包”，是指的应用层的数据包。
• 在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段。
• 站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中。
• 但站在应用层的角度，看到的只是一串连续的字节数据。
• 那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。就是说数据发过来是一整坨，你不知道按照数据发来的时候是怎么分的。

如何解决？

要解决粘包问题，本质就是要明确报文和报文之间的边界。

• 对于定长的包，保证每次都按固定大小读取即可。
• 对于变长的包，可以在报头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。比如HTTP报头当中就包含Content-Length属性，表示正文的长度。
• 对于变长的包，还可以在包和包之间使用明确的分隔符。因为应用层协议是程序员自己来定的，只要保证分隔符不和正文冲突即可。

相比之下UDP就不存在粘包问题，因为UDP面向数据报

• 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在，同时，UDP是一个一个把数据包交付给应用层的，有很明确的数据边界。
• 站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现“半个”的情况。

因此UDP是不存在粘包问题的，根本原因就是UDP报头当中的16位UDP长度记录的UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了，而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界。

TCP异常情况介绍

进程终止

当客户端正常访问服务器时，如果客户端进程突然崩溃了，此时建立好的连接会怎么样？

当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。也就是说，进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别。

机器重启

当客户端正常访问服务器时，如果将客户端主机重启，此时建立好的连接会怎么样？

当我们选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源。

机器掉电/网络断开

当客户端正常访问服务器时，如果将客户端突然掉线了，此时建立好的连接会怎么样？

当客户端掉线后，服务器端在短时间内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的。

比如你打游戏的时候突然断网了会显示断线重连中，嗷了个嗷......

• 服务器会定期客户端客户端的存在状况，检查对方是否在线，如果连续多次都没有收到ACK应答，此时服务器就会关闭这条连接。
• 此外，客户端也可能会定期向服务器“报平安”，如果服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭。

其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，是由TCP实现的。此外，应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态。

TCP小结

TCP协议这么复杂就是因为TCP既要保证可靠性，同时又尽可能的提高性能。

可靠性：

• 检验和。
• 序列号。
• 确认应答。
• 超时重传。
• 连接管理。
• 流量控制。
• 拥塞控制。

提高性能：

• 滑动窗口。
• 快速重传。
• 延迟应答。
• 捎带应答。

TCP的这些机制有些能够通过TCP报头体现出来的，但还有一些是通过代码逻辑体现出来的。

TCP定时器

此外，TCP当中还设置了各种定时器。

• 重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。
• 坚持定时器：专门为对方零窗口通知而设立的，也就是向对方发送窗口探测的时间间隔。
• 保活定时器：为了检查空闲连接的存在状态，也就是向对方发送探查报文的时间间隔。
• TIME_WAIT定时器：双方在四次挥手后，主动断开连接的一方需要等待的时长。

理解传输控制协议

TCP的各种机制实际都没有谈及数据真正的发送，这些都叫做传输数据的策略。TCP协议是在网络数据传输当中做决策的，它提供的是理论支持，比如TCP要求当发出的报文在一段时间内收不到ACK应答就应该进行超时重传，而数据真正的发送实际是由底层的IP和MAC帧完成的。

TCP做决策和IP+MAC做执行，我们将它们统称为通信细节，它们最终的目的就是为了将数据传输到对端主机。而传输数据的目的是什么则是由应用层决定的。因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式。

基于TCP的应用层协议

常见的基于TCP的应用层协议如下：

• HTTP（超文本传输协议）。
• HTTPS（安全数据传输协议）。
• SSH（安全外壳协议）。
• Telnet（远程终端协议）。
• FTP（文件传输协议）。
• SMTP（电子邮件传输协议）。

当然，也包括你自己写TCP程序时自定义的应用层协议。

TCP/UDP对比

我们说了TCP是可靠连接, 那么是不是TCP⼀定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进⾏⽐较

• TCP⽤于可靠传输的情况, 应⽤于⽂件传输, 重要状态更新等场景;

• UDP⽤于对⾼速传输和实时性要求较⾼的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以

⽤于⼴播;

归根结底, TCP和UDP都是程序员的⼯具, 什么时机⽤, 具体怎么⽤, 还是要根据具体的需求场景去判定.

之前刷视频还刷到个有意思的对比

1. TCP 与 UDP 协议对比

   • UDP 轻量、快速、延迟低，无需连接确认，常用于实时场景（如直播、游戏）；
   • TCP 通过三次握手保证数据可靠传输，但可能因重传、等待响应导致延迟。

2. 情感隐喻延伸

   • UDP 式情感表达：直接、真实，不执着于回应；
   • TCP 式情感表达：小心翼翼等待确认，依赖对方回应推进关系；
   • 真正的关系障碍是对方不想建立连接，而非自身表达方式错误。

核心结论：关系中若对方始终沉默，不是你的 “数据格式” 或坚持不够，而是对方未将你纳入 “连接表”。

如何用UDP实现可靠传输

参考TCP的可靠性机制, 在应⽤层实现类似的逻辑;

例如:

• 引⼊序列号, 保证数据顺序;

• 引⼊确认应答, 确保对端收到了数据;

• 引⼊超时重传, 如果隔⼀段时间没有应答, 就重发数据;

• ......

此篇完，感谢收看。