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,然后将经理扔向皮鞋👞。

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

相关推荐
是小满满满满吗2 小时前
传输层:udp与tcp协议
linux·服务器·网络
小刘同学++2 小时前
ECB(电子密码本,Electronic Codebook) 和 CBC(密码分组链接,Cipher Block Chaining)区分于用途
网络·ssl
CryptoPP2 小时前
使用WebSocket实时获取印度股票数据源(无调用次数限制)实战
后端·python·websocket·网络协议·区块链
gadiaola3 小时前
【计算机网络】第3章:传输层—TCP 拥塞控制
网络·网络协议·tcp/ip·计算机网络
猎板PCB厚铜专家大族3 小时前
多层PCB技术解析:从材料选型到制造工艺的深度实践
网络·制造
FakeOccupational5 小时前
【碎碎念】宝可梦 Mesh GO : 基于MESH网络的口袋妖怪 宝可梦GO游戏自组网系统
网络·游戏
fei_sun7 小时前
【计算机网络】三报文握手建立TCP连接
网络·tcp/ip·计算机网络
Johny_Zhao7 小时前
2025年6月Docker镜像加速失效终极解决方案
linux·网络·网络安全·docker·信息安全·kubernetes·云计算·containerd·yum源·系统运维
PypYCCcccCc7 小时前
支付系统架构图
java·网络·金融·系统架构
廖致君8 小时前
C/Python/Go示例 | Socket Programing与RPC
网络协议