F(orward)-RTO Recovery：TCP传输优化的打假算法

具体研究F-RTO实现的有太多太多，所以不再展开，只想讲讲F-RTO为什么是一种TCP传输优化。抱着这种目的，有了本文。

引子

最近看了点《开端》，时间循环这个梗真的百看不厌，并非喜欢这种设定，而是在这个过程中找到解放自己的方式，寻觅破局之法，这点总能击中我的爽点。

可是现实中没有时间循环的设定。

我们只能期望，在最短的时间，用最确切的证据，去挽救错误的局面。

现实如此，TCP亦如此。

网络是个复杂的玩意，互联网兴起更是催生了这一头巨兽。要在这种盘根错节下充当能手，TCP做了第一个，顺理成章也成了最难的一个。我一直以为TCP的难点不在可靠传输，真正的困局是在传输优化上，而传输优化中有这样一个层面，即检测虚假的超时重传。

TCP虚假超时重传

TCP/IP 是一个端到端的系统，而中间是错综复杂的互联网，在这种处境中，基于统计的AI都很难不犯错误，更何况是触感极低的TCP。TCP一向以触发超时定时器重传兜底，但超时重传的效率极低，其产生的后果就有失序、冗余、断联等，里面的每一项都对互联网是深水炸弹。

在“精明”的互联网面前，TCP很笨，超时重传的触发只依赖RTO，对于其他的一无所知。

于是有：

• RTO过小造成的伪重传
• 物理层面导致的延迟，如弱网的RTT抖动，移动选路的路径延迟
• 一些关键包丢失引发的假重传

开始两个好理解，对于关键包丢失引发的假重传，我给出一个例子。

 +0 write(4,...,10000)=10000
 +0 > P. 1:10001(10000) ack 1 <mss 1000,nop,nop,sackOK,nop,wscale 7>
 +0 < . 1:1(0) ack 4000 win 32678
 // ack 5000的确认包丢失了，TCP包重复机制，接收的仍是重复的ack 4000
 +0 < . 1:1(0)