为什么在RTO很长的时候重传会延迟？

Question

我对建立网络和学习TCP计时器管理很陌生，在我的教科书中读到了以下内容：

“如果超时(RTO)的值太小，则会发生不必要的重传。如果超时时间太长，则性能将下降，因为当数据包丢失时，重传将被延迟很长时间。”

我想知道为什么有必要或有理由延迟重传，而不是立即重新发送丢失的数据包？

Answer 1

您没有“立即重新发送丢失的数据包”的原因是，双方都不知道丢包了。

• 如果发送的数据包丢失了，发送方发送了一些东西，并且仍在等待ACK；接收方正在等待一个未到达的段，在接收方看来，该段与发送者保持安静完全相同。
• 如果ACK丢失了，发送方处于相同的情况下，但是接收方发送了ACK并认为它是最新的。

要想直观地理解这一点，请考虑发送电子邮件时的行为。你寄出了什么，期待着回复。过了一段时间，如果什么都没来，你再派一个。你等待多长时间( RTO)取决于你的期望，合理与否。类似的行为也发生在电话里，如果另一端暂时不说话(RTO)，你会问“你还在吗？”您会注意到，在电话中，您调整您的RTO取决于线的质量和你有多了解对方。

<#>Only发送者知道，已经发送了一些东西，等待了一段时间，而另一端现在肯定已经回复了。

RTO应该有多长时间？考虑一种理论上的情况，即发送数据包和返回ACK的时间正好为10 ms。RTO必须超过20 ms，否则发送将不断地、无意义地重传。假设是10.001毫秒。但在现实生活中，时间上会有变化和抖动。所以我们可以说，让我们取第99百分位数的时间，也就是11毫秒。或者1.1 x max(RTT)，假设我们以RTT的形式跟踪发送到ACK的时间，但这意味着在路由更改期间，一个非常长的延迟ACK会影响TCP连接的其余部分的吞吐量，所以我们最好跟踪随着时间的变化。由于RTO对网络吞吐量非常重要，因此对其进行了大量的研究。Kirk McKusick讲述了一个有趣的故事，讲的是他们在伯克利的时候，一个流体力学的人来告诉他们对此进行多项式计算--他们一开始对他嗤之以鼻--还有一个戏剧性的效果--在他们被说服尝试之后，又产生了一个术语。在实践中产生价值的一种方法非常好的描述是http://sgros.blogspot.com/2012/02/calculating-tcp-rto.html。