具体研究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) ack 4000 win 32678
+0 < . 1:1(0) ack 4000 win 32678
+0 < . 1:1(0) ack 4000 win 32678
// 因为ACK包丢失会触发快速重传等机制
+0.100 < . 4001:5001(1000) ack 1 <mss 1000,nop,nop,sackOK,nop,wscale 7>
// 但重传的包亦丢失
+0 < . 1:1(0) ack 4000 win 32678
+0 < . 1:1(0) ack 4000 win 32678
//这时就触发的超时重传是虚假的，超时重传没有必要
那么，TCP超时重传就会有虚假的趁机而入，这时TCP如同计算机被木马攻占一般，极速地降低着传输性能。
而TCP面对这种入侵，显然不能坐以待毙，于是乎，打假必然是TCP传输优化的重要一环。
这里呼应开头！
F-RTO 打假图解
F-RTO 很直白，TCP发送超时后，只要判断有“没有被重传的数据包”被确认了（ACK/SACK），就表示这是错误的超时重传。
探测结束，恢复原样。
（1）ACK的F-RTO探测
（2）SACK的F-RTO探测
（3）SACK 重复ACK的F-RTO探测
（4）SACK/ACK的F-RTO探测失效
