【网络面试篇】TCP 相关——重传机制、滑动窗口、流量控制、拥塞控制、Keep-Alive、KeepAlive

一、问题综述

[1. TCP 的重传机制](#1. TCP 的重传机制)

（1）超时重传

（2）快速重传

[（3）SACK 方法](#（3）SACK 方法)

[（4）Duplicate SACK](#（4）Duplicate SACK)

[① ACK 丟包](#① ACK 丟包)

[② 网络延时](#② 网络延时)

[补充：D-SACK 的好处](#补充：D-SACK 的好处)

[（5）综述 TCP 重传机制是怎么实现的？](#（5）综述 TCP 重传机制是怎么实现的？)

[① 序号与确认号](#① 序号与确认号)

[② 超时检测](#② 超时检测)

[③ 重传策略](#③ 重传策略)

[④ 快速重传和快速恢复](#④ 快速重传和快速恢复)

[2. TCP 的滑动窗口](#2. TCP 的滑动窗口)

（1）发送方的滑动窗口

（2）接收方的滑动窗口

[3. TCP 的流量控制](#3. TCP 的流量控制)

（1）操作系统缓冲区与滑动窗口的关系

[（2）综述 TCP 流量控制是怎么实现的？](#（2）综述 TCP 流量控制是怎么实现的？)

[① 滑动窗口大小](#① 滑动窗口大小)

[② 接收方窗口大小](#② 接收方窗口大小)

[③ 流量控制的目标](#③ 流量控制的目标)

[④ 动态调整](#④ 动态调整)

[⑤ 确认机制](#⑤ 确认机制)

[4. TCP 的拥塞控制](#4. TCP 的拥塞控制)

（1）为什么要有拥塞控制，不是有流量控制了吗？

（2）什么是拥塞窗口？和发送窗口有什么关系呢？

[（7）综述 TCP 拥塞控制是怎么实现的？](#（7）综述 TCP 拥塞控制是怎么实现的？)

[① 慢启动（Slow Start）](#① 慢启动（Slow Start）)

[② 拥塞避免（Congestion Avoidance）](#② 拥塞避免（Congestion Avoidance）)

[③ 快速重传（Fast Retransmit）](#③ 快速重传（Fast Retransmit）)

[④ 快速恢复（Fast Recovery）](#④ 快速恢复（Fast Recovery）)

二、其他相关问题

[1. Keep-Alive 是什么？](#1. Keep-Alive 是什么？)

[2. Keep-Alive 的优缺点？](#2. Keep-Alive 的优缺点？)

（1）优点

（2）缺点

[3. TCP KeepAlive 是什么？](#3. TCP KeepAlive 是什么？)

[4. TCP 的 KeepAlive 和 HTTP 的 Keep-Alive 是一个东西吗？](#4. TCP 的 KeepAlive 和 HTTP 的 Keep-Alive 是一个东西吗？)

[（1）TCP 的 KeepAlive](#（1）TCP 的 KeepAlive)

[（2）HTTP 的 Keep-Alive](#（2）HTTP 的 Keep-Alive)

一、问题综述

1. TCP 的重传机制

（1）超时重传

重传机制的其中一个方式，就是++在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据++ ，也就是我们常说的 超时重传。TCP 会在以下两种情况发生超时重传：

数据包丢失。
确认应答丢失。

**超时时间应该设置为多少呢？**先来了解一下什么是 RTT（Round-Trip Time 往返时延）。

RTT 指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间。超时重传时间是以**RTO（Retransmission Timeout 超时重传时间）**表示。

上图中有两种超时时间不同的情况：

当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

精确的测量超时时间 RTO 的值是非常重要的，这可让我们的重传机制更高效。根据上述的两种情况，我们可以得知，超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。

实际上「报文往返 RTT 的值」是经常变化的，因为我们的网络也是时常变化的。也就因为「报文往返 RTT 的值」是经常波动变化的，所以「超时重传时间 RTO 的值」应该是一个动态变化的值。

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

超时触发重传存在的问题是，超时周期可能相对较长。

（2）快速重传

TCP 还有另外一种 快速重传（Fast Retransmit）机制 ，它++不以时间为驱动，而是以数据驱动重传++。

在上图，发送方发出了 1，2，3，4，5 份数据：

第一份 Seq1 先送到了，于是就 Ack 回 2；
结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；
后面的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
发送端收到了三个 Ack=2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
最后，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6。

所以，快速重传的工作方式是 ****当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。这解决了一个问题，就是超时时间的问题。

还有另外一个问题，就是 重传的时候，是重传一个，还是重传所有的问题。

举个例子，假设发送方发了 6 个数据，编号的顺序是 Seq1~Seq6，但是 Seq2、Seq3 都丢失了，那么接收方在收到 Seq4、Seq5、Seq6 时，都是回复 ACK2 给发送方，但是发送方并不清楚这连续的 ACK2 是接收方收到哪个报文而回复的，那是 ++选择重传 Seq2 一个报文，还是重传 Seq2 之后已发送的所有报文++（Seq2、Seq3、Seq4、Seq5、Seq6）呢？

如果只选择重传 Seq2 一个报文，那么重传的效率很低。因为对于丢失的 Seq3 报文，还得在后续收到三个重复的 ACK3 才能触发重传。
如果选择重传 Seq2 之后已发送的所有报文，虽然能同时重传已丢失的 Seq2 和 Seq3 报文，但是 Seq4、Seq5、Seq6 的报文是已经被接收过了，对于重传 Seq4 ~Seq6 折部分数据相当于做了一次无用功，浪费资源。

可以看到，不管是重传一个报文，还是重传已发送的报文，都存在问题。为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。

（3）SACK 方法

还有一种实现重传机制的方式叫：SACK（Selective Acknowledgment，选择性确认）。

这种方式 ++需要在 TCP 头部「选项」字段里加一个 SACK 的东西++ ，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

下图中，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

最后返回 ACK 600 表示为，600 之前的所有数据均被接收到了。

（4）Duplicate SACK

Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

① ACK 丟包

「接收方」发给「发送方」的两个 ACK 确认应答都丢失了，所以发送方超时后，重传第一个数据包（3000 ~3499）。
于是「接收方」发现数据是重复收到的，于是回了一个 SACK =3000~3500，告诉「发送方」3000~3500 的数据早已被接收了，因为 ACK 都到了 4000了，已经意味着 4000 之前的所有数据都已收到，所以这个 SACK 就代表着 D-SACK。
这样「发送方」就知道了，数据没有丢，是「接收方」的 ACK 确认报文丢了。

② 网络延时

数据包（1000~1499）被网络延迟了，导致「发送方」没有收到 ACK 1500 的确认报文。
而后面报文到达的三个相同的 ACK 确认报文，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）又到了「接收方」。
所以「接收方」回了一个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。
这样发送方就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，而是因为网络延迟了。

补充：D-SACK 的好处

可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了；

可以知道是不是「发送方」的数据包被网络延迟了；

可以知道网络中是不是把「发送方」的数据包给复制了；

（5）综述 TCP 重传机制是怎么实现的？

当发送方的数据在传输过程中丢失、损坏或延迟，接收方可以请求发送方重新传输这些数据。

① 序号与确认号

在 TCP 通信中，每个发送的字节都有一个唯一的****序号，而 每个接收的字节都有一个****确认号。发送方维护了一个 发送窗口 ，接收方维护了一个 接收窗口。发送方会持续发送数据，并等待接收方的确认。

② 超时检测

发送方为 每个发送的数据段设置一个定时器，这个定时器的时长称为超时时间。发送方假设在这个超时时间内，数据能够到达接收方并得到确认。如果在超时时间内没有收到确认，发送方会认为数据丢失或损坏，触发重传。

③ 重传策略

当发送方在超时时间内没有收到确认，它会认为数据丢失，然后 重新发送相应的数据段。如果只有一个数据段丢失，发送方只会重传丢失的数据段。如果有多个数据段丢失，发送方可能会 使用更复杂的算法来决定哪些数据需要重传。

④ 快速重传和快速恢复

为了更快地发现丢失的数据，接收方可以使用 快速重传策略。当接收方连续接收到相同的确认号时，它会立即向发送方发送冗余的确认，以触发发送方进行重传。此外，发送方在接收到快速重传的确认后，不需要等到超时再次发送，而是可以使用快速恢复算法继续发送未丢失的数据。

2. TCP 的滑动窗口

TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了，再发送下一个。这个模式就有点像我和你面对面聊天，你一句我一句。但这种方式的缺点是 效率比较低的。

这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。

为解决这个问题，TCP 引入了窗口这个概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。

有了窗口，就可以指定窗口大小，窗口大小 就是 指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」3 个 TCP 段，并且中途若有ACK 丢失，可以通过**「下一个确认应答进行确认」**。如下图：

图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通过下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。
TCP 头里有一个字段叫 window，也就是窗口大小。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。所以，通常窗口的大小是由接收方的窗口大小来决定的。发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

（1）发送方的滑动窗口

过程一：

下图就是发送方缓存的数据，根据处理的情况分成四个部分，其中 深蓝色方框是发送窗口，紫色方框是可用窗口：

过程二：

发送方把数据「全部」都一下发送出去后，可用窗口的大小就为 0 了，表明可用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据了。

过程三：

当收到之前发送的数据 32~36 字节的 ACK 确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被应答确认，接下来 52~56 字节又变成了可用窗口，那么后续也就可以发送 52~56 这 5 个字节的数据了。

（2）接收方的滑动窗口

3. TCP 的流量控制

发送方不能无脑的发数据给接收方，要考虑接收方处理能力。如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量 ，这就是所谓的 流量控制。

举个例子，假设以下场景：

客户端是接收方，服务端是发送方。

假设接收窗口和发送窗口相同，都为 200。

假设两个设备在整个传输过程中都保持相同的窗口大小，不受外界影响。

客户端向服务端发送请求数据报文。（本例子是把服务端作为发送方，所以没有画出服务端的接收窗口）

服务端收到请求报文后，发送 确认报文和 80 字节的数据 ，于是 可用窗口 Usable减少为 120 字节，同时 SND.NXT 指针也向右偏移 80 字节 后，指向 321，这意味着 下次发送数据的时候，序列号是 321。

客户端收到 80 字节数据后，于是 接收窗口往右移动 80 字节 ，RCV.NXT 也就指向 321 ，这意味着 客户端期望的下一个报文的序列号是 321，接着发送确认报文给服务端。

服务端再次发送了 120 字节数据，于是 可用窗口耗尽为 0 ，服务端无法再继续发送数据。

客户端收到 120 字节的数据后，于是接收窗口往右移动 120 字节，RCV.NXT 也就指向 441，接着发送确认报文给服务端。

++服务端收到对 80 字节数据的确认报文后++ ，SND.UNA 指针往右偏移后指向 321 ，于是可用窗口 usable 增大到 80。

++服务端收到对 120 字节数据的确认报文后++ ，SND.UNA 指针往右偏移后指向 441，于是 可用窗口 usable 增大到 200。

服务端可以继续发送了，于是发送了160 字节的数据后，SND.NXT 指向 601，于是可用窗口 usable 減少到 40。

客户端收到 160 字节后，接收窗口往右移动了 160 字节，RCV.NXT 也就是指向了 601，接着发送确认报文给服务端。

服务端收到对 160 字节数据的确认报文后，发送窗口往右移动了 160 字节，于是 SND.UNA 指针偏移了 160 后指向 601，可用窗口 usable 也就增大至了 200。

（1）操作系统缓冲区与滑动窗口的关系

上面的流量控制例子，我们 假定了发送窗口和接收窗口是不变的 ，但是实际上，发送窗口和接收窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。当应用进程没办法及时读取缓冲区的内容时，也会对我们的缓冲区造成影响。

那操作系统的缓冲区，是如何影响发送窗口和接收窗口的呢？

举个例子。当应用程序没有及时读取缓存时，发送窗口和接收窗口的变化。考虑以下场景：

客户端作为发送方，服务端作为接收方，发送窗口和接收窗口初始大小为 360。

服务端非常的繁忙，当收到客户端的数据时，应用层不能及时读取数据。

客户端发送 140 字节数据后，可用窗口变为 220（360 - 140）。

服务端收到 140 字节数据，但是服务端非常繁忙，应用进程只读取了 40 个字节，还有 100 字节占用着缓冲区 ，于是 接收窗口收缩到了 260（360 - 100），最后发送确认信息时，将窗口大小通告给客户端。

客户端收到确认和窗口通告报文后，发送窗口减少为 260。

客户端发送 180 字节数据，此时可用窗口减少到 80。

服务端收到 180 字节数据，但是 应用程序没有读取任何数据，这 180 字节直接就留在了缓冲区 ，于是 接收窗口收缩到了 80（260 - 180），并在发送确认信息时，通过窗口大小给客户端。

客户端收到确认和窗口通告报文后，发送窗口减少为 80。

客户端发送 80 字节数据后，可用窗口耗尽。

服务端收到 80 字节数据，但是 应用程序依然没有读取任何数据，这 80 字节留在了缓冲区 ，于是 接收窗口收缩到了 0，并在发送确认信息时，通过窗口大小给客户端。

客户端收到确认和窗口通告报文后，发送窗口减少为 0 。可见最后窗口都收缩为 0 了，也就是发生了 窗口关闭 。当发送方可用窗口变为 0 时，++发送方实际上会定时发送窗口探测报文，以便知道接收方的窗口是否发生了改变++。

当服务端系统资源非常紧张的时候，操作系统可能会直接减少了接收缓冲区大小，这时应用程序又无法及时读取缓存数据，那么这时候就有严重的事情发生了，会出现 数据包丢失的现象。

举个例子：

客户端发送 140 字节的数据，于是可用窗口减少到了 220。

服务端因为现在非常的繁忙，操作系统于是就 把接收缓存减少了 120 字节 ，当收到 140 字节数据后，又因为应用程序没有读取任何数据，所以 140 字节留在了缓冲区中 ，于是 接收窗口大小从 360 收缩成了 100（360 - 120 - 140），最后发送确认信息时，通告窗口大小给对方。

此时 ++客户端因为还没有收到服务端的通告窗口报文，所以不知道此时接收窗口收缩成了 100++，客户端只会看自己的可用窗口还有 220，所以客户端就发送了 180 字节数据，于是可用窗口减少到 40。

服务端收到了 180 字节数据时，发现数据大小超过了接收窗口的大小 ，于是就把数据包丢失了。

客户端收到第 2 步时，服务端发送的确认报文和通告窗口报文，尝试减少发送窗口到 100，把窗口的右端向左收缩了 80，此时 ++可用窗口的大小就会出现诡异的负值++。

所以，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象 。为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况。

（2）综述 TCP 流量控制是怎么实现的？

流量控制就是让发送方发送速率不要过快，让接收方来得及接收。利用滑动窗口机制 就可以实施流量控制，主要方法就是 动态调整发送方和接收方之间数据传输速率。

① 滑动窗口大小

在 TCP 通信中，每个 TCP 报文段都包含一个 窗口字段，该字段指示发送方可以发送多少字节的数据而不等待确认 。这个窗口大小是动态调整的。

② 接收方窗口大小

接收方通过 TCP 报文中的窗口字段 告诉发送方自己当前的可接收窗口大小 。这是 接收方缓冲区 中还有多少可用空间。

③ 流量控制的目标

流量控制的 目标是确保发送方不要发送超过接收方缓冲区容量的数据。如果接收方的缓冲区快满了，它会减小窗口大小，通知发送方暂停发送，以防止溢出。

④ 动态调整

++发送方会根据接收方的窗口大小动态调整发送数据的速率。++如果接收方的窗口大小增加，发送方可以加速发送数据。如果窗口大小减小，发送方将减缓发送数据的速率。

⑤ 确认机制

接收方会定期发送确认（ACK）报文，++告知发送方已成功接收数据++ 。这也与流量控制密切相关，因为接收方可以 ++通过 ACK 报文中的窗口字段来通知发送方它的当前窗口大小++。

4. TCP 的拥塞控制

（1）为什么要有拥塞控制，不是有流量控制了吗？

流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。 一般来说，计算机网络都处在一个共享的环境。因此也有可能会 因为其他主机之间的通信使得网络拥堵。

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等 ，这时 TCP 就会 重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大。

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。 于是，就有了拥塞控制 ，控制的目的就是 避免「发送方」的数据填满整个网络。

为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。

（2）什么是拥塞窗口？和发送窗口有什么关系呢？

拥塞窗口 cwnd 是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。++发送窗口 swnd 和接收窗口 rwnd++ 是约等于的关系 ，由于加入了拥塞窗口的概念后，此时 ++发送窗口的值是 swnd=min(cwnd, rwnd)++ ，也就是 拥塞窗口和接收窗口中的最小值。

拥塞窗口 cwnd 变化的规则：

只要网络中没有出现拥塞，cwnd 就会增大；

但网络中出现了拥塞，cwnd 就减少；

（3）慢启动

TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量，如果一上来就发大量的数据，会给网络添堵。

慢启动的算法规则，即当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。
假定拥塞窗口 cwnd 和发送窗口 swnd 相等，举个例子：

连接建立完成后，一开始初始化 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）状态变量。

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

（4）拥塞避免算法

**当拥塞窗口 cwnd「超过」慢启动门限 ssthresh 就会进入拥塞避免算法。**一般来说 ssthresh 的大小是 65535 字节。

进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。
接上慢启动的例子，现假定 ssthresh 为 8：

当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。拥塞避免算法的变化过程如下图：

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

就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。当触发了重传机制，也就进入了**「拥塞发生算法」**。

（5）超时重传、快速重传

当发生了**「超时重传」**，则就会使用 拥塞发生算法 。这个时候，ssthresh（慢启动门限）和 cwnd（拥塞窗口） 的值会发生变化：

SSthresh 设为 cwnd/2，
cwnd 重置 1（是恢复为 cwnd 初始化值，这里假定 cwnd 初始化值 1）

接着，就 重新开始慢启动，慢启动是会突然减少数据流的。一旦「超时重传」，马上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。

发生 快速重传的拥塞发生算法 还有更好的方式，就是**「快速重传算法」**。

当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：

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

（6）快速恢复

快速重传和快速恢复算法一般同时使用 ，快速恢复算法是认为，你 ++还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。++

进入快速恢复算法如下：

拥塞窗口 cwnd = ssthresh + 3（3 的意思是确认有 3 个数据包被收到了）；

重传丢失的数据包；

如果再收到重复的 ACK，那么 cwnd 增加 1；

如果收到新数据的 ACK 后，把 cwnd 设置第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

快速恢复算法的变化过程如下图：

也就是没有像「超时重传」一夜回到解放前，而是还在比较高的值，后续呈线性增长。

（7）综述 TCP 拥塞控制是怎么实现的？

**TCP 拥塞控制可以在网络出现拥塞时动态地调整数据传输的速率，以防止网络过载。**TCP 拥塞控制的主要机制包括以下几个方面：

① 慢启动（Slow Start）

初始阶段，TCP 发送方会以较小的发送窗口开始传输数据。随着每次成功收到确认的数据，发送方逐渐增加发送窗口的大小，实现 指数级的增长，这称为慢启动。这有助于在网络刚开始传输时谨慎地逐步增加速率，以避免引发拥塞。

② 拥塞避免（Congestion Avoidance）

一旦达到一定的阈值（通常是慢启动阈值），TCP 发送方就会进入 拥塞避免阶段 。在拥塞避免阶段，发送方 以线性增加的方式增加发送窗口的大小，而不再是指数级的增长。这有助于控制发送速率，以避免引起网络拥塞。

③ 快速重传（Fast Retransmit）

如果 发送方连续收到相同的确认，++它会认为发生了数据包的丢失，并会快速重传未确认的数据包，而不必等待超时++。这有助于更快地恢复由于拥塞引起的数据包丢失。

④ 快速恢复（Fast Recovery）

在发生快速重传后，TCP 进入快速恢复阶段。在这个阶段，发送方不会回到慢启动阶段，而是 将慢启动阈值设置为当前窗口的一半，并将拥塞窗口大小设置为慢启动阈值加上已确认但未被快速重传的数据块的数量。这有助于更快地从拥塞中恢复。

二、其他相关问题

1. Keep-Alive 是什么？

Keep-Alive 是一种 HTTP 协议的机制，也被称为 HTTP 长连接。

++在启用 Keep-alive 的情况下，客户端和服务器在完成一个 HTTP 请求和响应后，并不立即关闭连接，而是继续保持连接处于打开状态++。 在连接保持打开的情况下，客户端可以继续发送其他请求，服务器可以继续发送响应，而无需重新建立连接，减少了连接的建立和关闭的开销，从而提高性能和效率。

HTTP1.0 中需要配置长连接，在请求头中配置 connection:Keep-Alive，而 HTTP1.1 中默认开启了长连接。

2. Keep-Alive 的优缺点？

（1）优点

TCP 连接的建立和关闭需要时间和资源，通过保持连接打开，可以减少这些开销，从而提高性能和效率。
客户端 可以在同一个连接上同时发送多个请求 ，服务器可以并行地处理这些请求，提高并发性能。
Keep-alive 连接中的多个请求共享同一个连接的头部信息（如用户代理、Cookie 等），减少了头部信息的重复传输。

（2）缺点

长时间的持久连接可能会 占用服务器资源 ，特别是在高并发的情况下。为了平衡资源利用和性能，服务器和客户端通常会设置 Keep-alive 的超时时间，以便在一段时间内保持连接打开，超过该时间则关闭连接。

3. TCP KeepAlive 是什么？

TCP Keep-Alive 是在操作系统和网络协议栈级别实现的，它 通过发送特定的探测数据包来维护连接的活跃性。

在启用 TCP Keep-Alive 的情况下，操作系统会定期发送一些特定的探测数据包到连接的另一端。++这些数据包通常是空的，没有实际的数据内容。++
++如果一端收到了探测数据包，它会回复一个确认（ACK）数据包++。如果一段时间内没有收到确认数据包，发送端将认为连接可能已经断开，从而触发连接关闭。

TCP Keep-Alive 的主要目的是检测连接是否处于空闲状态，即没有实际数据传输。它不仅可以检测到连接断开，还可以在空闲连接超过一定时间时释放连接，从而释放资源。

4. TCP 的 KeepAlive 和 HTTP 的 Keep-Alive 是一个东西吗？

TCP 的 KeepAlive 和 HTTP 的 Keep-Alive 并不是同一个概念，它们实现的层面和意图均有所不同。

（1）TCP 的 KeepAlive

TCP 的 KeepAlive 是一个由**TCP 层（内核态）**实现的机制，用于检测 TCP 连接的状态，确保连接的有效性。
当 TCP 连接在一段时间内没有数据交互时，内核会发送探测报文来检测对方是否仍然在线。如果连续多个探测报文都没有回应，TCP 会报告连接已死亡。

目的：确保 TCP 连接的有效性，避免因为网络故障或对方宕机等原因导致的连接失效。

（2）HTTP 的 Keep-Alive

HTTP 的 Keep-Alive 是一个由 **应用层（用户态）**实现的机制，允许在单个 TCP 连接上发送多个 HTTP 请求和响应。
通过 HTTP 请求头和响应头中的 Connection 字段来指示是否要保持连接。如果值为 "keep-alive"，则表示希望保持连接；如果值为 "close"，则表示请求完成后关闭连接。

目的：提高网络效率，减少延迟，并降低服务器和客户端的资源消耗。