如果我们有 Fast Retransmit 是否意味着我们有 Fast Recovery?

网络工程 通讯协议 拥塞
2021-07-27 16:25:38

我的问题是,在哪些情况下启用快速恢复?

就像我们进行了快速重传一样,是否也必须使用快速恢复?例如,我们丢失了一个段,然后通过快速重传发送......是否有必要进行快速恢复?

1个回答

你应该明白TCP拥塞控制方案有很多种,其中“Reno”和“NewReno”是实现快速重传的,但其他的则没有,因为它不需要使用特定的拥塞控制方案。请注意 RFC 中“应该”一词的使用,这意味着这不是必需的。

快速恢复与快速重传一起使用。RFC 2581,TCP 拥塞控制在第 3.2 节的第三段中解释了这一点:

3.2 快速重传/快速恢复

当一个乱序段到达时,一个 TCP 接收者应该立即发送一个重复的 ACK。此 ACK 的目的是通知发送方收到的段是乱序的,以及预期的序列号。从发送方的角度来看,重复 ACK 可能是由许多网络问题引起的。首先,它们可能是由丢失的段引起的。在这种情况下,丢弃段之后的所有段都会触发重复的 ACK。其次,重复 ACK 可能是由网络对数据段重新排序引起的(沿某些网络路径并非罕见事件 [ Pax97])。最后,重复 ACK 可能是由网络复制 ACK 或数据段引起的。此外,当传入的段填充序列空间中的全部或部分间隙时,TCP 接收器应该立即发送 ACK。这将为发送方通过重传超时、快速重传或实验性丢失恢复算法(例如 NewReno [ FH98 ])从丢失中恢复生成更及时的信息

TCP 发送方应该使用“快速重传”算法来检测和修复丢失,基于传入的重复 ACK。快速重传算法使用 3 个重复 ACK 的到达(4 个相同的 ACK,没有任何其他介入数据包的到达)作为分段已丢失的指示。在收到 3 个重复的 ACK 后,TCP 会重新传输看似丢失的数据段,而无需等待重新传输计时器到期。

在快速重传算法发送看似丢失的数据段后,“快速恢复”算法将控制新数据的传输,直到非重复的 ACK 到达。不执行慢启动的原因是收到重复的 ACK 不仅表明段已经丢失,而且段很可能离开网络(尽管网络的大量段重复可以使这个结论无效)。换句话说,由于接收方只能在一个段到达时生成重复的 ACK,该段已经离开网络并在接收方的缓冲区中,所以我们知道它不再消耗网络资源。此外,由于 ACK “时钟” [ Jac88] 被保留,TCP 发送方可以继续传输新的段(尽管传输必须使用减少的 cwnd 继续)。

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

  1. 当收到第三个重复的 ACK 时,将 ssthresh 设置为不超过等式 3 中给出的值。

  2. 重传丢失的段并将cwnd设置为ssthresh加上3*SMSS。这人为地将拥塞窗口“膨胀”了离开网络且接收器已缓冲的段数(三个)。

  3. 对于收到的每个额外的重复 ACK,通过 SMSS 增加 cwnd。这人为地扩大了拥塞窗口,以反映已经离开网络的附加段。

  4. 如果 cwnd 的新值和接收者的广告窗口允许,则传输一个段。

  5. 当下一个确认新数据的 ACK 到达时,将 cwnd 设置为 ssthresh(在步骤 1 中设置的值)。这被称为“放气”窗口。

    这个 ACK​​ 应该是由步骤 1 的重传引起的确认,重传后一个 RTT(尽管它可能会在接收器处数据段出现明显无序交付的情况下更快到达)。此外,如果所有中间段都没有丢失,则此 ACK 应确认在丢失段和接收到第三个重复 ACK 之间发送的所有中间段。

注意:众所周知,该算法通常无法从单个数据包传输中的多次丢失中非常有效地恢复 [ FF96 ]。在 [ FH98 ] 中可以找到一组提议的修改来解决这个问题