您指的是 TCP Reno 实现中的“快速重传”。这基本上是一个假设。

RFC 2001、TCP 慢启动、拥塞避免、快速重传和快速恢复算法涵盖了以下内容：

由于 TCP 不知道重复 ACK 是由丢失的段引起的还是只是段的重新排序引起的，因此它等待接收少量重复的 ACK。

假设如果只是对段进行重新排序，则在处理重新排序的段之前将只有一个或两个重复的 ACK，然后将生成新的 ACK。如果连续收到三个或更多重复的 ACK，则强烈表明段已丢失。

这里的关键是 Reno 希望避免慢启动，它假设接收到 3 个没有任何中间数据包的 dup-ack 是接收器，表明它希望重新发送该单段（快速重传）。如果发生超时，则 Reno 将触发慢启动。

RFC 2001，TCP 慢启动、拥塞避免、快速重传和快速恢复算法，第 4 节，快速恢复：

在快速重传发送看似丢失的段后，会执行拥塞避免，但不会执行慢启动。这就是快速恢复算法。这是一种改进，可以在中等拥塞情况下实现高吞吐量，尤其是对于大窗口。

在这种情况下不执行慢启动的原因是收到重复的 ACK 告诉 TCP 不仅仅是一个数据包已经丢失。由于接收器只能在接收到另一个段时生成重复的 ACK，因此该段已离开网络并在接收器的缓冲区中。即两端之间仍有数据流动，TCP不想通过进入慢启动来突然减少流量。

快速重传和快速恢复算法通常如下一起实现。

1. 当接收到连续第三个重复的 ACK 时，将 ssthresh 设置为当前拥塞窗口的一半，cwnd，但不少于两个段。重传丢失的段。将 cwnd 设置为 ssthresh 加上段大小的 3 倍。这会根据离开网络且另一端已缓存的段数 (3) 来扩大拥塞窗口。

2. 每次另一个重复的 ACK 到达时，将 cwnd 增加段大小。这增加了离开网络的附加段的拥塞窗口。如果 cwnd 的新值允许，则传输数据包。

3. 当下一个确认新数据的 ACK 到达时，将 cwnd 设置为 ssthresh（在步骤 1 中设置的值）。这个 ACK​​ 应该是对来自步骤 1 的重传的确认，重传后的一个往返时间。此外，此 ACK 应确认在丢失数据包和收到第一个重复 ACK 之间发送的所有中间段。这一步是拥塞避免，因为 TCP 的速率下降到数据包丢失时的一半。

快速重传算法最早出现在 4.3BSD Tahoe 版本中，紧随其后的是慢启动。快速恢复算法出现在 4.3BSD Reno 版本中。