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

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

相关推荐
achene_ql1 小时前
select、poll、epoll 与 Reactor 模式
linux·服务器·网络·c++
黎相思2 小时前
应用层自定义协议与序列化
运维·服务器·网络
邪恶的贝利亚2 小时前
实现p2p的webrtc-srs版本
网络协议·webrtc·p2p
Lightning-py3 小时前
Linux命令cat /proc/net/snmp查看网络协议层面统计信息
网络·网络协议·tcp/ip
2501_915106323 小时前
iOS性能调优实战:借助克魔(KeyMob)与常用工具深度洞察App瓶颈
websocket·网络协议·tcp/ip·http·网络安全·https·udp
wo3258661453 小时前
浪潮交换机配置track检测实现高速公路收费网络主备切换NQA
开发语言·网络·php
光路科技5 小时前
TSN交换机正在重构工业网络,PROFINET和EtherCAT会被取代吗?
服务器·网络·重构
云盾安全防护6 小时前
CC攻击与WAF的对抗战
网络·安全·ddos
还是鼠鼠7 小时前
HTTP 请求协议简单介绍
java·开发语言·网络·网络协议·http
网硕互联的小客服8 小时前
如何在服务器上部署 Python Django 应用
linux·运维·服务器·网络·安全