TCP 重传演进：TCP RACK Timer 能替代 RTO 吗

本文的建议适用于想改变 TCP 行为的新协议设计，还是那句话，不要抄 TCP 做 yet another TCP。

RTO 一直是 TCP 传输过程所要尽量避免的，因为它会将状态带入 Loss 进而 Go-Back-N，这是一个昂贵的操作。But 在 Fast-Retransmit 被引入 TCP 前这显然是唯一的 Recovery 手段，请不要数典忘祖。

按照最初的 TCP 拥塞状态机，进入 Loss 状态后 loss_cwnd = 1，然而近年来在 RACK 被引入后，loss_cwnd = inflt + 1，那么这个 inflt 从何而来？

如下图所示，懂的不用看，不懂的单独讨论，不赘述：

这个多出来的 inflt 就是 “RACK 刚刚重传出去的那些报文”，为了能让 RTO “至少还能再传输一个报文(比如 UNA)”，所以 cwnd = inflt + 1，非常合理。

但是…

所以说 RTO 兜底还好吗？统一到 RACK 不行吗，用本地时钟替代 ACK Self 时钟 rearm timer 即可了，毕竟在 RTO 时代没能力对重传数据包单独计时，没法用本地时钟驱动单独数据包重传，只能 RTO。整个链条如下：

• 最初的 TCP 没有 ACK 时钟驱动的重传，只能通过本地时钟驱动重传；
• 引入 Fast-Retransmit 后可 ACK 时钟驱动重传，但由于无法区分 orig 和 retrans，只能使用一次；
• 引入 RACK- Retransmit 后可对每次重传计时，可统一以 ACK 时钟和本地时钟处理重传；
• So？…

RACK timer 完全可替代 RTO timer，而 RTO = SRTT + 4 * RTTVAR 可近似为 RTO = iRTT + ReoWIN(虽然 MDEV 和 Reorder 并不是一回事)。VJ 算法不合理的地方在于，SRTT 已经考虑了方差，再单独计算肯定就谨慎保守了，这也导致了 TCP 此后的行为一直谨慎保守，而 iRTT + ReoWIN 才更合理，或许应该为 ReoWIN 单独叫做 ReoWIN_and_Jitter，即 RTO = iRTT + ReoWIN_and_Jitter，一起合入 RACK，然后将经理扔向皮鞋👞。

浙江温州皮鞋湿，下雨进水不会胖。