TCP中丢失恢复的快速恢复技术

当 RTO 定时器超时但未收到 ACK 时，发送方确认数据包因中间设备拥塞而丢失。现在发送方必须小心处理这种拥塞状态。快速恢复是丢包恢复技术。恢复意味着变为非活动状态并且在一段时间内不传输任何新数据包。

当检测到数据包丢失时，TCP 发送方会做 4 件事：

将 cwnd 减少 50%。
将 ssthresh 值减少 cwnd 的 50%。
重新传输丢失的数据包。
进入快速恢复阶段。

快速恢复阶段：

这包括两部分：

寂静的半窗
保持 inflight=cwnd 直到新的 ACK 到达发送方。

沉默的半窗口是发送者变得沉默（非活动）并等待飞行变为等于 cwnd 的时间量。因为当检测到丢包时，cwnd 会减半。之前 inflight 正好等于 cwnd，但现在 inflight 大约是 cwnd 值的两倍。因此，发送方不会发送任何新数据包，也不会将每个 ACK 的 cwnd 增加 1。发送方将继续获得 DUP-ACK，直到接收方收到重传的数据包。

在 inflight 等于 cwnd之后，半个静音窗口到此结束，现在 DUP-ACK 也会不断到来，因此发送方不会增加其 cwnd，但会保持等于 cwnd 的 inflight 值。当一个 DUP-ACK 到来时，inflight 变得比之前的值小 1，所以为了保持 inflight=cwnd，发送方会向网络发送一个新的数据包。当最终接收方收到重传的数据包并向发送方发送新的 ACK 时，发送方将退出快速恢复阶段并立即进入 AIMD 阶段。发送方退出恢复阶段，因为它已确认丢失的数据包已被接收方接收，因此网络不再拥塞。但是，它必须小心增加 cwnd 以避免过早的后续拥塞，从而进入 AIMD 之后。

快速恢复技术：

TCP Reno 和 TCPNewreno 中使用的快速恢复技术：

它面临一个称为“沉默的半窗”的问题。它导致可用网络资源的利用不足。因为当发送者保持沉默时，网络带宽被浪费了。另一个问题是它会停止应用程序，导致最终用户感到沮丧。如果发送方没有发送数据，那么接收方将不得不等待，这会导致数据延迟和糟糕的用户体验。那么，解决方案是什么？

一种解决方案是通过使用 SACK（接收缓冲区中的间隙知识）来改进对“飞行中”数据的估计。如果发送者知道更新后的“飞行”值，那么沉默的半窗口将很快结束。另一种解决方案是速率减半技术（以前是 Linux 中的默认值）。一种更高级的解决方案是Proportional Rate Reduction （Linux 中的当前默认设置，并在 RFC 6937 中定义）。

无需 SACK 的快速恢复：

无需 SACK 的快速恢复

Before Fast Recovery:
cwnd = 10, inflight = 10

Initial stage when Fast Recovery begins:
cwnd = 5, ssthresh = 5, inflight = pipe = 10

直到管道等于 cwnd 的半个静默窗口。

DUP-ACK 到达发送方：pipe=10-1=9
DUP-ACK 到达发送方：pipe=9-1=8
DUP-ACK 到达发送方：pipe=8-1=7
DUP-ACK 到达发送方：pipe=7-1=6
DUP-ACK 到达发送方：pipe=6-1=5。现在，cwnd=pipe，沉默现在打破。
DUP-ACK到达发送方：pipe=5-1=4，pipe
DUP-ACK到达发送方：pipe=5-1=4，pipe

这将继续，直到重新传输的数据包被接收方确认。

使用 SACK 快速恢复：

它受到突发传输的影响。当网络丢失数据包时，发送方同时发送一堆数据包，这对网络造成了严重影响。

使用 SACK 快速恢复

初始状态：

pipe = 5 segments
cwnd= 5 segments
ssthresh = 5 segments

这是当一半的静音窗口结束并且 pipe=cwnd 时的情况。

DUP-ACK 与 SACK 块一起到达，SACK 块告诉 3 个数据包丢失。

pip= 5-1-3= 1
pipe < cwnd

需要传输新数据包 = cwnd-pipe

现在，发送方将发送 4 个新数据包。这称为突发传输。