4000 字详解TCP超时与重传，看完没收获算我输

我们都知道 TCP 协议具有重传机制，也就是说，如果发送方认为发生了丢包现象，就重发这些数据包。很显然，我们需要一个方法来「猜测」是否发生了丢包。最简单的想法就是，接收方每收到一个包，就向发送方返回一个 ACK，表示自己已经收到了这段数据，反过来，如果发送方一段时间内没有收到 ACK，就知道很可能是数据包丢失了，紧接着就重发该数据包，直到收到 ACK 为止。

你可能注意到我用的是「猜测」，因为即使是超时了，这个数据包也可能并没有丢，它只是绕了一条远路，来的很晚而已。毕竟 TCP 协议是位于传输层的协议，不可能明确知道数据链路层和物理层发生了什么。但这并不妨碍我们的超时重传机制，因为接收方会自动忽略重复的包。

超时和重传的概念其实就是这么简单，但内部的细节却是很多，我们最先想到的一个问题就是，到底多长时间才能算超时呢？

超时是怎么确定的？

一刀切的办法就是，我直接把超时时间设成一个固定值，比如说 200ms，但这样肯定是有问题的，我们的电脑和很多服务器都有交互，这些服务器位于天南海北，国内国外，延迟差异巨大，打个比方：

• 我的个人博客搭在国内，延迟大概 30ms，也就是说正常情况下的数据包，60ms 左右就已经能收到 ACK 了，但是按照我们的方法，200ms 才能确定丢包（正常可能是 90 到 120 ms），这效率实在是有点低。
• 假设你访问某国外网站，延迟有 130 ms，这就麻烦了，正常的数据包都可能被认为是超时，导致大量数据包被重发，可以想象，重发的数据包也很容易被误判为超时。。。雪崩效应的感觉

所以设置固定值是很不可靠的，我们要根据网络延迟，动态调整超时时间，延迟越大，超时时间越长。

在这里先引入两个概念：

• RTT（Round Trip Time）：往返时延，也就是**数据包从发出去到收到对应 ACK 的时间。**RTT 是针对连接的，每一个连接都有各自独立的 RTT。
• RTO（Retransmission Time Out）：重传超时，也就是前面说的超时时间。

比较标准的 RTT 定义：

Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers tha