一、TCP协议简介

TCP全称为“传输控制协议（Transmission Control Protocol）”，TCP 是面向连接的、可靠的、基于字节流的传输层通信协议，同时TCP协议是当今互联网当中使用最为广泛的传输层协议，没有之一。

• 面向连接：使用TCP进行数据传输，不能像 UDP 协议一样直接发送数据，必须先进行建立连接才能够进行数据传输。

• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端。

• 字节流：用户消息通过TCP协议传输时，消息可能会被操作系统「分组」形成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法准确的读出一个有效的用户消息的。

• 有序性：TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。

TCP协议被广泛应用，其根本原因就是提供了详尽的可靠性保证，基于TCP的上层应用非常多，比如HTTP、HTTPS、FTP、SSH等，甚至MySQL底层使用的也是TCP。

1、浅谈可靠性

为什么网络中会存在不可靠呢？

现代的计算机大部分都是基于冯诺依曼体系结构的，输入设备、输出设备、内存、CPU都在一台机器上，但这几个硬件设备是彼此独立的，如果它们之间要进行数据交互，就必须要想办法进行通信。

因此这些设备实际是用“线”连接起来的，其中连接内存和外设之间的“线”叫做IO总线，而连接内存和CPU之间的“线”叫做系统总线。由于这几个硬件设备都是在一台机器上的，因此这里传输数据的“线”是很短的，传输数据时出现错误的概率也非常低。

但如果要进行通信的各个设备相隔千里，那么连接各个设备的“线”就会变得非常长，传输数据时出现错误的概率也会大大增高，此时要保证传输到对端的数据无误，就必须保证可靠性。

所以网络中存在不可靠的根本原因就是：因为通信双方距离变长了

数据在长距离传输过程中就可能会出现各种各样的问题，而TCP就是在此背景下诞生的，TCP就是一种保证可靠性的协议。

2、UDP协议存在的意义

按照道理来说TCP协议是一种可靠的传输协议，而UDP协议是一种不可靠的传输协议，那UDP协议这种不可靠的协议存在有什么意义呢？

在网络中不可靠和可靠是两个中性词，它们描述的都是协议的特点。

• TCP协议是可靠的协议，也就意味着TCP协议需要做更多的工作来保证传输数据的可靠性，因此TCP使用起来一定比UDP复杂，并且维护成本特别高。
• UDP协议是不可靠的协议，也就意味着UDP协议无论是使用还是维护都足够简单。

TCP和UDP各有各的适用场景，网络通信时具体采用TCP还是UDP完全取决于上层的应用场景。如果应用场景严格要求数据在传输过程中的可靠性，那么就必须采用TCP协议，如果应用场景允许数据传输出现少量丢包，那么肯定优先选择UDP协议，因为UDP协议足够简单而且维护成本极低。

UDP用于对高速传输和实时性要求较高的通信领域：

• 包总量较少的通信如： DNS 、SNMP 等；
• 视频、音频等多媒体通信；
• 广播通信；

而TCP用于可靠传输的情况，

• 应用于文件传输。
• 重要状态更新等场景。

二、TCP的协议格式

TCP报头当中各个字段的含义如下(此处只需要简单理解，后面会有详细解释)：

• 源/目的端口号：表示数据是从哪个进程来，到发送到对端主机上的哪个进程。

• 32位序号：分别代表TCP报文当中每个字节数据的编号。

• 32位确认序号：接收端对发送方发送的报文的确认序号，是TCP保证可靠性的重要字段。

• 4位TCP报头长度：表示该TCP报头的长度，它的单位是4字节。

• 6位保留字段：TCP报头中暂时未使用的6个比特位，后续TCP的更新可能会对这些比特位赋予新的含义。

• 6位标志位：一些特殊标记，我们后续进行讲解。

• 16位窗口大小：描述当前主机的TCP接收缓冲区剩余空间的大小，这是保证TCP可靠性机制和效率提升机制的重要字段。

• 16位检验和：由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部+TCP数据部分）

• 16位紧急指针：标识紧急数据在报文中的偏移量，需要配合标志字段当中的URG字段统一使用。

• 选项字段：TCP报头当中允许携带额外的选项字段，最多40字节，即TCP的报头长度为20~60。

TCP的解包和分用

TCP的解包：

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

因此TCP是「根据4位的首部长度」分离报头与有效载荷的：

1. 当TCP获取到一个报文后，首先读取报文的前20个字节，并从中提取出4位的首部长度：$len$，此时便获得了TCP报头的大小$size=len\ast 4byte$。

2. 如果$size$的值大于20字节，则需要继续从报文当中读取$size-20$字节的数据，这部分数据就是TCP报头当中的选项字段，读取完TCP的基本报头和选项字段后，剩下的就是有效载荷了。

4为首部长度的取值范围是 0000 ~ 1111，因此TCP报头最大长度为：$15\times 4=60byte$ ，因为基本报头的长度是20字节，所以报头中选项字段的长度最多是40字节。

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

TCP的分用：

TCP的报头中含有了目的端口号，因此TCP可以提取出报头中的目的端口号，找到对应的应用层进程，进而将有效载荷交给对应的应用层进程进行处理。

三、确认应答机制

TCP 实现可靠传输的方式之一，是通过「序列号与确认应答」。

确认应答的简单理解

在进行网络通信时，发送端发出的数据后，它不能保证该数据能够成功被接收端收到，因为数据在传输过程中可能会出现各种各样的错误，只有当发送端收到接收端主机发来的确认消息后，发送端主机才能保证上一次发送的数据被接收端真正的收到了。

所以在TCP中，当的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。

接收端发送的确认应答消息一般情况下是一个TCP报头，这个TCP报头中标志位ACK被置为1，表示这是一个确认应答消息。

当然，发送端为了确保数据没有丢包，发送端是需要等待一定的时间来接收确认应答（ACK)的，当发送端收到了ACK以后，才能够进行下一次的传输，如果超时了还没有收到ACK(此时有两种情况，一种是数据丢了，一种是ACK丢了)，那么发送端就会判定此次通信出现了丢包，于是触发TCP的「超时重传机制」，进行数据的重新发送，然后继续等待ACK。

当发送端收到了ACK以后，不用对收到的ACK再做应答，因为双方通信时总有最新的一条消息得不到响应，我们只要保证双方通信时发送的每一个核心数据都有对应的ACK响应就可以了。

序列号

上面双方在进行数据通信时，只有收到了上一次发送数据的ACK才能发下一个数据，那么此时双方的通信过程就是串行的，效率比较低下。

因此双方在进行网络通信时，允许一方向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，此时也就能对确认应答的等待时间进行了并发的利用。

但在连续发送多个报文时，由于各个报文在进行网络传输时选择的路径可能是不一样的，那么其各个路径的转发能力也是不一样的，因此这些报文到达对端主机的先后顺序也就可能和发送报文的顺序是不同的。但报文有序也是可靠性的一种，因此TCP报头中的32位序号的作用之一就是用来保证报文的有序性的。

TCP将发送出去的每个字节数据都进行了编号，这个编号叫做序列号。

比如现在发送端要发送3000字节的数据，如果发送端每次发送1000字节，那么就需要用三个TCP报文来发送这3000字节的数据。此时这三个TCP报文当中的32位序号填的就是发送数据中首个字节的序列号，因此分别填的是1、1001和2001。

此时接收端收到了这三个TCP报文后，就可以根据TCP报头当中的32位序列号对这三个报文进行顺序重排（该动作在传输层进行），重排后将其放到TCP的接收缓冲区当中，此时接收端这里报文的顺序就和发送端发送报文的顺序是一样的了。

确认应答号

TCP报头当中的32位确认应答号是告诉对端，我当前已经收到了哪些数据，你的数据下一次应该从哪里开始发。

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

确认应答号的含义：

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

接收端可以根据：当前报文的32位序号与其报文的字节数，进而确定下一个报文对应的序号。

在TCP连续发送多个报文时，中间可能有某个报文出现了数据丢包，以上面的例子为例，主机A发送了三个报文给主机B，其中每个报文的有效载荷都是1000字节，这三个报文的32位序号分别是1、1001、2001。

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

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

序列号与确认序列号的意义 ：

• 序列号可以保证数据的「有序性」，同时根据序列号也能够对发送端发送的重复报文（可能由于超时重传机制而导致的重复报文）进行识别并丢弃。
• 确认序列号可以保证数据的「可靠性」。

一种应答方式——捎带应答

捎带应答是TCP通信时最常规的一种方式，例如客户端给服务端发送了一条消息，当服务端收到这条消息后需要对其进行ACK应答，但如果服务端此时正好也要给客户端发生消息，此时这个ACK就可以搭顺风车，而不用单独发送一个ACK应答，此时服务端发送的这个报文既发送了数据，又完成了对收到数据的进行响应，这就叫做捎带应答。

捎带应答的方式提高了发送数据的效率，将两次网络发送合并成了一次。

此外，由于捎带应答的报文携带了有效数据，因此对方收到该报文后会对其进行响应，当收到这个响应报文时不仅能够确保发送的数据被对方可靠的收到了，同时也能确保捎带的ACK应答也被对方可靠的收到了。

---

为什么要用两套序号机制？

我们可以对TCP报头中的字段进行进一步的思考，为什么要用两套序号机制呢？

1. 如果发送端在发送数据时，将该序号看作是32位序号。
2. 接收端在对发送端发来的数据进行响应时，将该序号看作是32位确认序号。

这样的话TCP的报头还能够减少一些字节的数据，提高一定的效率，但实际TCP却没有这么做，根本原因就是因为TCP是全双工的，双方可能同时想给对方发送消息。

1. 双方发出的报文当中，不仅需要填充32位序号来表明自己当前发送数据的序号。
2. 还需要填充32位确认序号，对对方上一次发送的数据进行确认，告诉对方下一次应该从哪一字节序号开始进行发送。（这种发送方式其实就是捎带应答）

因此在进行TCP通信时，双方都需要有确认应答机制，此时一套序号就无法满足需求了，因此需要TCP报头当中出现了两套序号。

---

四、超时重传机制

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

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

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

TCP 会在以下两种情况发生超时重传：

1. 数据包丢失
2. 确认应答丢失

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

超时等待时间

超时重传的时间是很有讲究的。

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

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

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

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。

• 如果重发一次之后，仍然得不到应答，下一次重传的等待时间就是 $2\times 500$ ms。如果仍然得不到应答，那么下一次重传的等待时间就是$4\times 500$ ms ，以此类推，以指数的形式递增。

• 即如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。
• 也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

• 当累计到一定的重传次数后，TCP就会认为是网络或对端主机出现了异常，进而强转关闭连接。

五、流量控制

1、TCP的缓冲区

TCP本身是具有接收缓冲区和发送缓冲区的：

• 接收缓冲区用来暂时保存接收到的数据。
• 发送缓冲区用来暂时保存还未发送的数据。

这两个缓冲区都是在TCP传输层内部实现的。

• TCP发送缓冲区当中的数据由上层应用层进行写入。当上层调用write/send这样的系统调用接口时，实际不是将数据直接发送到了网络当中，而是将数据从应用层拷贝到了TCP的发送缓冲区当中。
• TCP接收缓冲区当中的数据最终也是由应用层来读取的。当上层调用read/recv这样的系统调用接口时，实际也不是直接从网络当中读取数据，而是将数据从TCP的接收缓冲区拷贝到了应用层而已。

TCP的发送缓冲区和接收缓冲区存在的意义

• 数据在网络中传输时可能会出现某些错误，此时就可能要求发送端进行数据重传，因此TCP必须提供一个发送缓冲区来暂时保存要发送出去的数据，只有当发出去的数据被对端可靠的收到后，发送缓冲区中的这部分数据才可以被覆盖掉。
• 接收端处理数据的速度是有限的，为了保证没来得及处理的数据不会被迫丢弃，因此TCP必须提供一个接收缓冲区来暂时保存未被处理的数据，因为数据传输是需要耗费资源的，我们不能随意丢弃正确的报文。此外，TCP的数据重排也是在接收缓冲区当中进行的。

经典的生产者消费者模型：

• 对于发送缓冲区来说，上层应用不断往发送缓冲区当中放入数据，下层网络层不断从发送缓冲区当中拿出数据准备进一步封装。此时上层应用扮演的就是生产者的角色，下层网络层扮演的就是消费者的角色，而发送缓冲区对应的就是“交易场所”。
• 对于接收缓冲区来说，上层应用不断从接收缓冲区当中拿出数据进行处理，下层网络层不断往接收缓冲区当中放入数据。此时上层应用扮演的就是消费者的角色，下层网络层扮演的就是生产者的角色，而接收缓冲区对应的就是“交易场所”。
• 因此引入发送缓冲区和接收缓冲区相当于引入了两个生产者消费者模型，该生产者消费者模型将上层应用与底层通信细节进行了解耦，此外，生产者消费者模型的引入同时也支持了并发和忙闲不均。

理解一些现象：

• 在编写TCP套接字时，我们调用read/recv函数从套接字当中读取数据时，可能会因为套接字当中没有数据而被阻塞住，本质是因为TCP的接收缓冲区当中没有数据了，我们实际是阻塞在接收缓冲区当中了。
• 而我们调用write/send函数往套接字中写入数据时，可能会因为套接字已经写满而被阻塞住，本质是因为TCP的发送缓冲区已经被写满了，我们实际是阻塞在发送缓冲区当中了。

2、TCP的窗口大小

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

因此TCP报头当中就有了16位的窗口大小，这个16位窗口大小当中填的是自身接收缓冲区中剩余空间的大小，也就是当前主机接收数据的能力，$2^{16}÷1024byte=64KB$。

实际上TCP报头当中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的。

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

问：在接收方接受能力为0的条件下，发送方怎么知道什么时候可以重新向接收方发送数据了呢？

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

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

问：第一次发送方发送数据时怎么保证数据量不会超过对方的窗口大小呢？

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

3、TCP的PSH标志位

TCP报头当中的PSH被设置为1，是在告诉对方尽快将你的接收缓冲区当中的数据交付给上层，用来让流量的速度快起来。

我们一般认为：

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

实际这种说法是不太准确的，其实接收缓冲区和发送缓冲区都有一个「水位线」的概念，只有当接收缓冲区当中有大于等于水位线以上字节的数据时才让read/recv函数读取这些数据并进行返回。

这样的设计是为了避免read/recv类似的系统调用频繁的进行读取和返回，进而影响读取数据的效率（在内核态和用户态之间切换也是有成本的）。

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

六、TCP的六个标志位

为什么会存在标志位？

1. TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文，以及断开连接时发送的断开连接的报文等等。
2. 收到不同种类的报文时完美需要执行对应动作，比如正常通信的报文需要放到接收缓冲区当中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作。

为了让不同种类的报文对应的是不同的处理逻辑，所以我们要能够区分报文的种类。而TCP就是使用报头当中的六个标志字段来进行区分的，这六个标志位都只占用一个比特位，为0表示假，为1表示真。

标志位	解释
SYN	报文当中的SYN被设置为1，表明该报文是一个连接建立的请求报文。 只有在连接建立阶段，SYN才被设置，正常通信时SYN不会被设置。
ACK	报文当中的ACK被设置为1，表明该报文是确认应答报文。 一般除了第一个请求报文没有设置ACK以外，其余报文基本都会设置ACK，因为发送出去的数据时可以采用捎带应答的方式进行发送
FIN	报文当中的FIN被设置为1，表明该报文是一个连接断开的请求报文。 只有在断开连接阶段，FIN才被设置，正常通信时FIN不会被设置。
PSH	报文当中的PSH被设置为1时，实际就是在告知对方操作系统，尽快将接收缓冲区当中的数据交付给上层
RST	报文当中的RST被设置为1，表示需要让对方重新建立连接。 1. 在通信双方在连接未建立好的情况下，一方向另一方发数据，此时另一方发送的响应报文当中的RST标志位就会被置1， 表示要求对方重新建立连接。 2. 在双方建立好连接进行正常通信时，如果通信中途发现之前建立好的连接出现了异常也会要求重新建立连接。
URG	报文当中的URG被设置为1 ，表示包含紧急数据，应该尽快传送， TCP会在报头字段中指定一个紧急指针，告诉接收端紧急数据在数据流中的位置。

URG字段的详细解释

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

TCP按序到达本身也是我们的目的，此时对端上层在从接收缓冲区读取数据时也必须是按顺序读取的。但是有时候发送端可能发送了一些“紧急数据”，这些数据需要让对方上层提取进行读取，此时就需要用到URG标志位，以及TCP报头当中的16位紧急指针。

• 当URG标志位被设置为１时，需要通过TCP报头当中的「16位紧急指针」来找到紧急数据，否则则不需要关注TCP报头当中的16位紧急指针。
• 16位紧急指针代表的就是紧急数据在发送来的报文中的偏移量。
• 因为紧急指针只有一个，而且没有指示结束位置，所以它只能标识数据段中的一个位置，因此紧急数据只能发送一个字节。

recv/send函数的第四个参数flags有一个叫做MSG_OOB的选项可供设置，其中OOB是带外数据（out-of-band）的简称，带外数据就是一些比较重要的数据，因此上层如果想读取紧急数据，就可以在使用recv函数进行读取，并设置MSG_OOB选项。

上层如果想发送紧急数据，就可以使用send函数进行写入，并设置MSG_OOB选项。

URG的一个应用场景

在网盘服务中，我们正在上传一个文件，但是我们现在突然不想上传这个文件了，于是我们发起取消请求，但是由于TCP的保证有序性，所以我们的取消请求不能够被立即处理，需要在接收缓冲区中排队，网盘继续执行上传任务，直到读取到了取消请求才进行取消上传，显然这种处理方式是不合理的。

为了让服务器能够尽快的响应我们的取消请求，我们可以将取消请求的报文设置为紧急数据，这样对于我们发送的取消请求，服务器就能够尽快处理了。

七、连接管理机制

TCP的各种可靠性机制是基于连接的，与连接是强相关的。比如一台服务器启动后可能有多个客户端前来访问，如果TCP不是基于连接的，也就意味着服务器端只有一个接收缓冲区，此时各个客户端发来的数据都会拷贝到这个接收缓冲区当中，此时这些数据就可能会互相干扰，所以我们在进行TCP通信之前需要先建立连接。

1、操作系统对连接的管理

一台机器上可能会存在大量的TCP连接，此时操作系统就必须对这些连接进行管理。

在操作系统中有一个描述连接的结构体，该结构体当中包含了连接的各种属性字段，所有定义出来的连接结构体最终都会以某种数据结构组织起来，此时操作系统对连接的管理就变成了对该数据结构的增删查改。

• 建立连接，实际就是在操作系统中用该结构体定义一个结构体变量，然后填充连接的各种属性字段，最后将其插入到管理连接的数据结构当中即可。
• 断开连接，实际就是将某个连接从管理连接的数据结构当中删除，释放该连接曾经占用的各种资源。

因此连接的管理也是有成本的，这个成本就是管理连接结构体的时间成本，以及存储连接结构体的空间成本。

2、三次握手

一开始，客户端和服务端都处于 CLOSE 状态。

1. 先是服务端主动监听某个端口，处于 LISTEN 状态，然后调用accept()等待客户端连接。
2. 然后客户端调用 socket()函数，分配一个文件描述符，然后调用 connect()发起连接请求，正式开始三次握手。

---

三次握手的过程，实际是由双方的操作系统中的TCP层自主完成的！

• connect函数，触发连接，等待完成。
• accept，等待建立完成，获取连接。

在编码角度看：

---

在原理角度看：

• 第一次握手：客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN_SENT 状态。

• 第二次握手：服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1(服务端向客户端发起连接建立请求并对客户端发来的连接请求进行响应)。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN_RCVD 状态。

• 第三次握手：客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。

• 服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。

一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了。

需要注意的是:

1. 客户端向服务器发起的建立连接请求，是请求建立从客户端到服务器方向的通信连接，而TCP是全双工通信，因此服务器在收到客户端发来的建立连接请求后，服务器也需要向客户端发起建立连接请求，请求建立从服务器到客户端方向的通信连接。
2. 从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的
3. 连接的建立不是百分之百能成功的，通信双方在进行三次握手时，其中前两次握手能够保证被对方收到，因为前两次握手都有对应的响应，但第三次握手是没有对应的响应报文的，如果第三次握手时客户端发送的ACK报文丢失了，那么连接建立就会失败。

如果第三次握手的ACK报文丢失导致，服务端也就不会进入ESTABLISHED 状态，但是客户端已经进入了ESTABLISHED 状态，然后客户端给服务器发送数据时，服务端就会检测到双方认知状态不一致，于是向客户端发送一个RST被置为1的TCP报文，让客户端重新建立连接。

3、为什么是三次握手

我们来进行依次考虑：

一次握手
TCP是全双工通信，需要两个方向上的通信信道都没有问题，一次握手在成功的情况下只能保证一个方向的通信信道没有问题，没有办法实现双向通信。

两次握手

如果只有两次握手，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到服务端的 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接。

这会造成什么情况呢？

如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

而且在这种情况下，建立连接时的异常连接是挂在服务端的，不管客户端有没有成功收到服务端发送的 SYN + ACK，服务端自己是先要维护好连接的（哪怕这是一个异常的连接），然后客户端收到服务端发送的 SYN + ACK以后才会建立连接，如果没有收到，客户端就不必建立连接进行维护。

于是利用这个特点就可以对TCP进行「SYN洪水攻击」：

攻击者用大量的假IP地址发送初始连接请求（SYN）数据包，让服务端建立连接，然后切换IP继续发，于是导致服务端上面挂满了异常连接，而攻击者的机器上是不需要维护任何连接的，这样被攻击的服务器的CPU和内存资源会迅速耗尽，就无法响应任何新的请求了。

所以两次握手：可能会造成双方资源的浪费，同时也是不安全的。

三次握手

• 没有明显的设计漏洞，一旦建立连接出现异常，异常连接成本嫁接到客户端。
• 握手的本质是在验证双方通信信道的通畅情况，而三次握手是验证全双工通信信道通畅的最小成本!

• 客户端通过①和②就能够验证自己的通信的收和发的通信信道是没有问题的。
• 服务端通过①和③就能够验证自己的通信的收和发的通信信道是没有问题的。

四次握手

三次握手在理论上就已经能够完成可靠连接建立，所以不需要使用更多的通信次数。

4、四次挥手

由于双方维护连接都是需要成本的，因此当双方TCP通信结束之后就需要断开连接（双方都可以主动断开连接），断开连接后主机中的「资源」将被释放，断开连接的这个过程我们称之为四次挥手。

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

• 第一次挥手：客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
• 第二次挥手：服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSE_WAIT 状态。
• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
• 第三次挥手：等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
• 第四次挥手：客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态。
• 服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
• 客户端在经过 2MSL (两个报文最大生存时间，单位是秒) 时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

---

报文最大生存时间在Linux中是可以查看的，通过下面的命令

cat /proc/sys/net/ipv4/tcp_fin_timeout

当然这个值也是可以修改的，修改以后想要生效需要重新编译 Linux 内核。

---

至此四次挥手结束后双方的连接才算真正断开，此外你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

为什么是四次挥手？

由于TCP是全双工的，建立连接的时候需要建立双方的连接，断开连接时也同样如此。

• 关闭连接时(客户端主动调用close函数)，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据的。
• 服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时(服务器主动调用close函数)，才发送 FIN 报文给客户端，表示表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。但是在特定情况下，四次挥手是可以变成三次挥手的。

5、四次挥手中的一些状态

CLOSE_WAIT

• 双方在进行四次挥手时，如果只有客户端调用了close函数，而服务器不调用close函数，此时服务器就会进入CLOSE_WAIT状态，而客户端则会进入到FIN_WAIT_2状态。

• 但只有完成四次挥手后连接才算真正断开，此时双方才会释放对应的连接资源。如果服务器没有主动关闭不需要的文件描述符，随着是时间的积累，在服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少，因此一定要及时关闭不用的文件描述符！！！

LAST_ACK

如果客户端给服务器发送了FIN报文并收到了ACK以后会进入FIN_WAIT_2状态，这个状态并不稳定，这个状态会等待服务端发送FIN报文，如果服务端一直长时间不调用close函数不发送FIN报文，客户端会强制断开连接直接进入CLOSE状态，于是等客户端已经进入CLOSE状态了，服务器才调用close函数，此时，服务器的状态变为LAST_ACK，但是客户端是不会再对服务器进行响应（ACK），由于服务端一直收不到ACK，就会不断进行重传(此时一直处于LAST_ACK状态)，直到达到指定次数，于是服务器也就主动进入了CLOSE状态了。

当服务器中存在大量CLOSE_WAIT的情况下关闭服务器进程（文件描述符是随进程的，进程关闭相当于主动调用close）就会发现CLOSE_WAIT状态变为了大量的LAST_ACK状态。

TIME_WAIT

主动断开连接的一方在发送完最后一个ACK以后，就会进入TIME_WAIT状态，然后等待2MSL时间以后才会进入CLOSE状态。

那么为什么要有TIME_WAIT状态呢，为什么不是发送完最后一个ACK以后直接进入进入CLOSE状态呢？

主要有下面的两个原因：

• 保证「被动关闭连接」的一方，能被正确的关闭。

如果客户端（主动关闭方）最后一次 ACK 报文（第四次挥手）在网络中丢失了，那么按照 TCP 可靠性原则，服务端（被动关闭方）会重发 FIN 报文。

假设客户端没有 TIME_WAIT 状态，而是在发完最后一次回 ACK 报文就直接进入 CLOSE 状态，如果该 ACK 报文丢失了，服务端则重传的 FIN 报文，而这时客户端已经进入到关闭状态了，对于收到服务端重传的 FIN 报文不会进行响应，于是服务器在经过若干次超时重发后得不到响应，最终也会将对应的连接关闭，但在服务器不断进行超时重传期间还需要维护这条废弃的连接，这样对服务器是非常不友好的。

• 保证双方通信信道上的数据在网络中尽可能的消散。

假设 TIME-WAIT 没有等待时间或时间过短，当一个服务器重启以后，服务端以相同的四元组(源IP，目的IP，源端口，目的端口)重新打开了新连接，重启之前的被延迟的数据包这时抵达了服务端，而且该数据报文的序列号刚好在客户端接收窗口内，因此客户端会正常接收这个数据报文，但是这个数据报文是上一个连接残留下来的，这样就产生数据错乱等严重的问题。

为了防止历史连接中的数据，被后面相同四元组的连接错误的接收，因此 TCP 设计了 TIME_WAIT 状态，状态会持续 2MSL 时长，这个时间足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

TIME_WAIT的优化

TIME_WAIT状态的设计是好事，但是在有些情况下却可能带来糟糕的影响，例如当我们的服务器挂掉了，这时主动断开连接的一方就变成了服务器，由于TIME_WAIT状态导致我们的服务器不能够立即启动，这时我们重新启动服务器就会显示端口已经被占用了。

由于我们是服务器程序，我们又不能随意改变端口，于是我们只能等待120s，但是这对于服务器程序来说是不允许的，因此我们要想办法让服务器程序在成为主动断开连接的一方时也能够忽略TIME_WAIT状态立即启动。

我们知道计算机中被使用的端口，还是可以继续对另外一个主机发起连接的，于是Linux给我们提供了一个函数，通过这个函数我们能够复用套接字。

#include <sys/types.h>        
#include <sys/socket.h>

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);

• 作用： 设置套接字有关信息

• 参数 ：
  sockfd：将要被设置的套接字。
  level：要设置的选项所在的协议层，这里我们设置为SOL_SOCKET。
  optname：需要访问的选项名，这里我们设置为SO_REUSEADDR。
  optval：对选项要设置的的值的起始地址，这里我们定义一个变量opt为1，然后填写这个opt变量的地址就行了。
  optlen：optval指向的缓冲区的长度，这里的长度为sizeof(opt)。

• 返回值
  成功返回0，失败返回-1，错误码被设置。

至此TCP的连接管理机制讲解完毕，下面是一张TCP的完整的连接过程：

八、滑动窗口

我们在前面说过：双方在进行TCP通信时可以一次向对方发送多条报文，这样可以将发送和等待多个响应的时间重叠起来，进而提高数据通信的效率。

虽然双方在进行TCP通信时可以一次向对方发送多条的报文，但是其必须收到「流量控制」的限制，即一次发送多条数据时不能超出接收方的接收能力。

1、滑动窗口的一般原理介绍

首先滑动窗口是在发送方的发送缓冲区里面的，为了便于理解我们可以将发送缓冲区看作是一个char类型的数组（便于体现其字节流的特性）其有两个下标，winstart指向滑动窗口的起始位置，winend指向滑动窗口的结束位置。

窗口里面的数据就是指这部分数据是可以进行并发发送，暂时不用收到应答的数据。

根据滑动窗口可以将发送缓冲区当中的数据分为三部分：

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

问：那么这个滑动窗口的大小是多少呢？

由于TCP有「流量控制」和「拥塞控制」，所以滑动窗口的机制不能违背其他机制，结论是其大小为：

对方的16位窗口大小和拥塞窗口的值中的最小值

min(对方的16位窗口大小，拥塞窗口的值)

在这里为了方便我们理解滑动窗口我们可以先认为这个滑动窗口的大小等于对方16位窗口大小。

例如我们现在连续发送 1001-2000、2001-3000、3001-4000、4001-5000这四个段的时候，不需要等待任何ACK，可以直接进行发送。

当收到对方响应的确认序号为2001时，说明1001-2000这个数据段已经被对方收到了，此时该数据段应该被纳入发送缓冲区当中的已发送且已经ACK中，我们假设对方的窗口大小一直是4000，因此滑动窗口现在可以向右移动，继续发送5001-6000的数据段，以此类推就可以提高数据的发送效率。

滑动窗口的几个注意点：

• 当发送方发送出去的数据段陆陆续续收到对应的ACK时，就可以将收到ACK的数据段归置到滑动窗口的左侧，并根据当前滑动窗口的大小来决定，是否需要将滑动窗口右侧的数据归置到滑动窗口当中。

• TCP的重传机制要求暂时保存发出但未收到确认的数据，而这部分数据实际就位于滑动窗口当中，只有滑动窗口左侧的数据才是可以被覆盖或删除的，因为这部分数据才是发送并被对方可靠的收到了，所以滑动窗口除了限定可以不收到ACK直接发送的数据之外，滑动窗口也可以支持TCP的重传机制

2、滑动窗口的一些常见问题以及回答

问：1.滑动窗口只能向右滑动吗? 向左可以吗？

答案是：只能向右滑动！滑动窗口的左侧表示已经发送且受到ACK的数据，这部分数据以后是要被覆盖的，滑动窗口向左滑动没有意义！

问：2.滑动窗口能变，能变小吗? 能变0吗? 变0之后，表示什么意思？

答案是：能！滑动窗口的大小是：

min(对方的16位窗口大小，拥塞窗口的值)

为了方便我们理解滑动窗口我们可以先认为这个滑动窗口的大小等于对方16位窗口大小，所以当对方的窗口大小变大了，我们的滑动窗口也会变大，所以当对方的窗口大小变小了，我们的滑动窗口也会变小，当滑动窗口为0时代表对方已经没有接收能力了！滑动窗口也就不能发送数据了。

问：3.能一直滑动吗? 越界怎么办?

答案是：能！TCP的设计者很聪明，实际的发送缓冲区是一个环形缓冲区，所以能够一直向右滑动。

问：4.滑动窗口的大小更新的依据是什么?

答案是：依据响应报头（ACK）中的16位窗口大小和确认序列号

由于TCP是保证可靠性的，所以应答也能按序到达，所以我们就可以对按序到达的响应报文提取出「确认序列号」和「16位窗口大小」。然后按照下面的公式进行更新窗口。

$$winstart=确认序列号;winend=winstart+16位窗口大小;$$

问：5.滑动窗口内部的报文既然可以直接发送多个报文，如果第一个丢失了呢? 中间的丢失了呢? 最后一个丢失呢?

这里分应该两种情况讨论：

情况一: 数据包已经抵达， ACK被丢了

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认。

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

• 第一个ACK丢失，可能能够通过后续报文的ACK来消除影响，实在不行就「超时重传」。
• 中间ACK的丢失了，说明前面的ACK没有丢失，于是滑动窗口向右进行滑动就转化为第一个ACK丢失的情况。
• 最后一个ACK丢失，说明前面的ACK没有丢失，于是滑动窗口向右进行滑动就转化为第一个ACK丢失的情况。

情况二： 数据包真的丢了

当1001-2000的数据包丢失后，发送端会一直收到确认序号为1001的响应报文，就好像提醒发送端“下一次应该从序号为1001的字节数据开始发送”。

如果发送端连续收到三次确认序号相同（本例这里是1001）的响应报文，此时就会将对应的（本例这里是1001-2000）的数据包重新进行发送，这种机制被称为 高速重发控制(也叫 快重传).

此时当接收端收到1001-2000的数据包后，就会直接发送确认序号为7001的响应报文，因为2001-7000的数据接收端其实在之前就已经收到了。

• 第一个ACK丢失，通过「快重传」进行补发，实在不行就「超时重传」。
• 中间ACK的丢失了，说明前面的ACK没有丢失，于是滑动窗口向右进行滑动就转化为第一个ACK丢失的情况。
• 最后一个ACK丢失，说明前面的ACK没有丢失，于是滑动窗口向右进行滑动就转化为第一个ACK丢失的情况。

3、快重传与超时重传

• 快重传是当发送端连续收到三次相同的应答时就会触发快重传，而不像超时重传一样需要通过设置重传定时器，在固定的时间后才会进行重传，所以快重传的效率比较高。

• 超时重传以时间为驱动，而快速重传是以数据为驱动，虽然快重传能够快速判定数据包丢失，但快重传并不能完全取待超时重传，因为有时数据包丢失后可能并没有收到对方三次重复的应答，此时快重传机制就触发不了，而只能进行超时重传。

• 因此快重传虽然是一个效率上的提升，但超时重传却是所有重传机制的保底策略，也是必不可少的。

九、拥塞控制

1、拥塞控制的简单介绍

Ⅰ、为什么要有拥塞控制？

对于TCP通信的双方，有了「流量控制」来保证通信数据的传输速度，有了「滑动窗口」来保证数据传输的效率，但是这些机制考虑的都是通信的双方，而没有考虑通信时的网络。

例如两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发，但如果双方在通信时出现了大量丢包，此时就不能认为是正常现象了，大概率是网络出现了问题。

• 例如大面积断电，导致各种网络设备瘫痪了（硬件的问题）。
• 或者是路由器转发压力过大宕机了（软件和硬件结合的问题）。
• 或者是网络中出现了网络拥塞，导致报文超时了（软件的问题）等。

所以需要有其他的机制来保证网络的可用性，于是就有了「拥塞控制」，其核心就是提供一个拥塞窗口来尽可能保证不会出现网络拥塞。

TCP不是万能的，对于一些硬件导致出现网络问题TCP无法解决，对于软件上面的一些问题，TCP能够提供一些解决方案。

Ⅱ、什么是拥塞窗口？

拥塞窗口是可能引起网络拥塞的阈值，如果一次发送的数据超过了拥塞窗口的大小就可能会引起网络拥塞

在编码中，拥塞窗口是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

我们在前面提到过滑动窗口的大小是：

min(对方的16位窗口大小，拥塞窗口的值)

这样设计的目的就是：保证通信数据在通过「网络」到达对方的「接收缓冲区」时都不会发生问题。

Ⅲ、如何解决网络拥塞？

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

例如网络中的主机在同一时间节点都大量向网络当中塞数据，此时位于网络中某些关键节点的路由器下就可能排了很长的报文，最终导致报文无法在超时时间内到达对端主机，此时也就导致了丢包问题。

• 当网络出现拥塞问题时，通信双方虽然不能提出特别有效的解决方案，但双方主机可以做到不加重网络的负担，例如通信双方可以少发数据甚至不发数据，等待网络状况恢复后双方再慢慢恢复数据的传输速率。

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

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

2、拥塞控制的策略

拥塞控制的策略主要是四个算法：

• 慢启动
• 拥塞避免
• 拥塞发生
• 快速恢复

Ⅰ、慢启动

TCP引入了慢启动机制，在出现网络拥塞时或者刚开始通信时先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

慢启动的算法规则：当发送方每收到一个 ACK，拥塞窗口的大小就会加 1。

这里我们先假定拥塞窗口 cwnd和发送窗口（滑动窗口）相等，下面举个例子：

• 连接建立完成后，一开始初始化cwnd = 1，表示可以传一个 MSS 大小的数据。

• 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个。

• 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个。

• 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。

• …

可以看出慢启动算法，拥塞窗口的大小是指数性的增长！

因此慢启动实际只是初始时增长的比较慢，但是后续增长速度非常快，慢启动利用指数增长的特点有下面的两点好处。

• 在初期时，保证网络拥塞的情况不能加重。
• 在中期时，网络拥塞有起色的情况下，尽快恢复网络通信。

但是拥塞窗口的值一直以指数的方式进行增长，在后期时就会出现其增长的幅度过大，导致拥塞窗口的值难以被较为准确的探测。

所以有一个叫慢启动阈值ssthresh （slow start threshold）状态变量，一般来说TCP刚开始启动的时候 ssthresh 的大小是 65535 (对方窗口大小的最大值) 。

• 当 cwnd < ssthresh 时，使用慢启动算法。
• 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

Ⅱ、拥塞避免算法

进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

接上前面的慢启动的例子，现假定 ssthresh 为 8：

• 当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。

拥塞避免算法的变化过程如下图：

所以，我们可以发现，拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。

就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。

当触发了重传机制，也就进入了「拥塞发生算法」。

Ⅲ、拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种，这两种使用的拥塞发送算法是不同的。

• 超时重传的拥塞发生算法

当发生了「超时重传」时，就会使用「超时重传的拥塞发生算法」。

这个时候，ssthresh 和 cwnd 的值会发生变化：

• ssthresh 设为 cwnd/2。
• cwnd 通常会被重置为1，但是有些时候「超时重传的拥塞发生算法」可能会选择恢复到初始的cwnd值，但这并不常见。通常，当发生「超时重传」时，网络拥塞已经很严重，因此将cwnd重置为1更加合理。

---

问 ：怎么查看系统的 cwnd 初始化值？

Linux 针对每一个 TCP 连接的 cwnd 初始化值是 10，也就是 10 个 MSS，我们可以用 ss -nli | grep cwnd 命令查看每一个 TCP 连接的 cwnd 初始化值，但是要记住在发生「超时重传」时大概率不会使用这个初始值来给cwnd 重新赋值的。

如下图：

---

拥塞发生算法的变化如下图：

• 少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为发生了网络拥塞。
• 当TCP通信开始后， 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
• 拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。

• 快速重传的拥塞发生算法

前面我们讲过「快速重传」，发送端连续收到三次相同的应答时就会触发快重传，不必等待超时再重传。

当发生快速重传时，说明因为大部分都没有没丢，只丢了一小部分，TCP 认为这种情况网络拥塞不严重，则 ssthresh 和 cwnd 变化如下：

• cwnd = cwnd/2 ，也就是设置为原来的一半。
• ssthresh = cwnd。
• 进入快速恢复算法。

Ⅳ、快速恢复

快速重传和快速恢复算法一般同时使用，快速恢复算法是认为：你还能收到 3 个重复 ACK ，说明网络拥塞的情况也不那么糟糕，所以没有必要像 「超时重传」那么强烈的将cwnd置为1。

正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了，然后，进入快速恢复算法如下：

• 拥塞窗口 cwnd = ssthresh + n （ n 的意思是确认有 n 个数据包被收到了）；
• 重传丢失的数据包；
• 如果再收到重复的 ACK，那么 cwnd 增加 1；
• 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从重复 ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

---

首先，快速恢复是拥塞发生后慢启动的优化，其首要目的仍然是降低 cwnd 来减缓拥塞，所以必然会出现 cwnd 从大到小的改变。

其次，cwnd逐渐加1的过程的存在是为了尽快将丢失的数据包发给目标，从而解决拥塞的根本问题（三次相同的 ACK 导致的快速重传），所以这一过程中 cwnd 反而是逐渐增大的 。

---

1. 在快速恢复的过程中，首先 ssthresh = cwnd/2，然后 cwnd = ssthresh + 3，表示网络可能出现了阻塞，所以需要减小 cwnd 以避免，加 3 代表快速重传时已经确认接收到了 3 个重复的数据包；
2. 随后继续重传丢失的数据包，如果再收到重复的 ACK，那么 cwnd 增加 1。加 1 代表每个收到的重复的 ACK 包，都已经离开了网络。这个过程的目的是尽快将丢失的数据包发给目标。
3. 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，恢复过程结束。

这样的话「快速重传」也就没有像「超时重传」那样直接将cwnd变为1，而是还在比较高的值，后续呈线性增长，快速恢复还是一个不错的优化。

十、TCP的一些杂项讨论

1、一种应答方式——延迟应答

TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能比较小。

• 假设对方接收端缓冲区剩余空间大小为1M，对方一次收到500K的数据后，如果立即进行ACK应答，此时返回的窗口就是500K。
• 但实际接收端处理数据的速度很快，10ms之内就将接收缓冲区中500K的数据消费掉了。
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
• 如果接收端稍微等一会再进行ACK应答，比如等待200ms再应答，那么这时返回的窗口大小就是1M。

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

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

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

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

2、面向字节流

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

• 调用write时, 数据会先写入发送缓冲区中;
• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出；如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去。
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区；然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据， 这个概念叫做 全双工

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

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

3、粘包问题

Ⅰ、什么是粘包？

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

Ⅱ、如何解决粘包问题 ？

归根结底就是一句话： 明确两个包之间的边界。

• 对于定长的包, 保证每次都按固定大小读取即可。
• 对于变长的包：
  • 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
  • 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

Ⅲ、UDP是否存在粘包问题？

• UDP是一个一个把数据交付给应用层的，具有有很明确的数据边界。
• 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在，于是在交付时就可以根据 ：udp报文长度字段 - udp8字节固定首部长度 得到一个完整的报文。

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

4、TCP异常情况

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

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

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

和进程终止的情况相同的，例如我们在windows中关机/重启时，系统会给我们提示当前系统还有未关闭的进程，是否关闭进程？

所以系统关机/重启之前会关闭所有的进程，这就和进程终止的情况相同的，另外我们会发现当我们在关机之前运行的有多个网络程序时，关机的速度就会变慢，这是因为操作系统在底层进行四次挥手时也要消耗时间的！当挥手完毕才能够进行关机。

• 机器掉电/网线断开
  当客户端正常访问服务器时，如果将客户端主机突然掉电/网线断开，此时建立好的连接会怎么样？

当客户端掉线后，服务器端在短时间内无法知道客户端掉线了的。

会有以下这些情况：

• 接收端认为连接还在， 一旦接收端有写入操作， 接收端发现连接已经不在了, 就会进行reset。
• 服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的，TCP自己内置了一个保活定时器，会定期询问对方是否还在，如果对方不在，也会把连接释放。
• 此外，应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态。

另外，TCP的连接长短其实是由应用层决定的，因为TCP虽然进行连接管理工作，但是它是没有办法确定用户想要连接的时长的！

十一、TCP总结

1、TCP小结

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

可靠性：

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

提高性能：

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

需要注意的是，TCP的这些机制有些能够通过TCP报头体现出来的，但还有一些是通过代码逻辑体现出来的，此外，TCP当中还设置了各种定时器。

TCP定时器：

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

2、基于TCP的应用层协议

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

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

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

3、理解传输控制协议

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

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

参考资料：

[1] TCP 重传、滑动窗口、流量控制、拥塞控制

[2] 传输层协议 ——— TCP协议