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

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

相关推荐
qq192572302713 分钟前
网络协议传输层
网络·网络协议
芯盾时代14 分钟前
安全大模型智驱网络和数据安全效能跃迁
网络·人工智能·安全·网络安全
玩转4G物联网4 小时前
零基础玩转物联网-串口转以太网模块如何快速实现与MQTT服务器通信
服务器·物联网·网络协议·tcp/ip·信息与通信·iot·fs100p
dalerkd5 小时前
企业产品网络安全日志6月10日-WAF资费消耗排查
网络·安全·web安全
shawn085 小时前
内网有猫和无线路由器,如何做端口映射从而实现外网访问
网络·智能路由器
云布道师6 小时前
云服务运行安全创新标杆:阿里云飞天洛神云网络子系统“齐天”再次斩获奖项
网络·人工智能·安全·阿里云·云计算·云布道师
晴天¥7 小时前
第二部分-IP及子网划分
服务器·网络·tcp/ip
wanhengidc7 小时前
高防服务器中高防和硬防之间的区别
运维·服务器·网络
wanhengidc7 小时前
服务器硬防的应用场景都有哪些?
运维·服务器·网络
前端.火鸡8 小时前
记录一篇HTTPS的文章
网络协议·http·https