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

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

为了直观地理解这一点，请考虑您发送电子邮件时的行为。你发送一些东西，期待回复。过了一会儿，如果什么都没有，你再发送一个。您等待的时间 (the RTO) 取决于您的期望，合理的或其他的。类似的行为发生在电话上，如果另一端有一段时间没有说话 ( RTO) ，你会说“你还在吗？”。您会注意到，在电话上您会RTO根据线路质量以及您对对方的了解程度来调整您的电话。

只有发送方知道，已经发送了一些东西，等待了一会儿，那肯定另一端现在应该已经响应了。

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