收到 ACK 后如何在 TCP 中设置/重置重传计时器?

网络工程 tcp
2022-02-23 01:14:40

我在阅读Forouzan 的书中的TCP 时遇到了以下问题

我们可以为重传定时器定义如下规则:

  1. 当 TCP 在发送队列前面发送段时,它会启动计时器。
  2. 当定时器超时时,TCP 重新发送队列前面的第一个段,并重新启动定时器。
  3. 当一个或多个段被累积确认时,将从队列中清除该段或多个段。
  4. 如果队列为空,TCP 停止定时器;否则,TCP 重新启动定时器。

我的疑问是,当我们收到启动计时器的段的 ACK 时,计时器会发生什么?它是否只是为将来发送的任何段重置?(请注意,我实际上是在询问第 3 点中所述的清除段后计时器会发生什么。)

2个回答

当收到一个 ACK​​ 时,相应的段就完成了。

当我们收到启动定时器的段的 ACK 时,定时器会发生什么?

我们为下一个段的 ACK 重新启动计时器,所以我们知道它什么时候过期了。计时器是对预期下一个 ACK​​ 的周期的保守估计。

如果计时器超时,则该段或 ACK 可能已丢失,并且该段被重新传输。如果 ACK 及时到达,一切都很好,队列中的下一个段移动到窗口中。它被发送,我们继续为下一个 ACK​​ 计时(实际上是针对先前发送的段)。

这是 Reno/Tahoe TCP。现在大多数系统都使用立方。但是算法是这样的。

  1. 新流程 - 设置 3 秒 rtxtimer
  2. 发送 syn,在 100ms 内得到 SYN ACK RTXtimer = .8 Rtxttimer + .2 100ms = 2.4 secs 所以,大部分旧值,一些新值
  3. Get Req to ack 100ms RTX timer = .8 Rtxttimer +.2 100ms = 1.9 secs
  4. 10 个数据包后 RTXtimer ~ 500ms
  5. 20 个数据包后 RTXtimer ~ 140ms

6 .if Loss double rtxtimer

很难找出真正的 RTT,这就是他们提出重复确认(快速重传请求)的原因。