TCP往返估计与重传计时器

只取平均RTT会忽略抖动。偏差大时多留一些余量，可减少原包只是慢了一点却被大量重传的情况。超时越多，退避越长，避免没有反馈时仍用原速率不断加压。

一次重传之后，ACK没有写明“这是回应第一份还是第二份”。用第二次发送时间强行计算一个很短RTT，会让以后更容易过早重传。

取 $G=0.01$ 秒。第一有效样本为0.8秒，得到 $S=0.8,V=0.4$，RTO=$0.8+1.6=2.4$秒。第二样本为1.0秒，先算 $V=0.75\times 0.4+0.25\times 0.2=0.35$，再算 $S=0.825$，RTO=$0.825+1.4=2.225$秒。

第三样本为0.7秒：$V=0.75\times 0.35+0.25\times |0.825-0.7|=0.29375$；$S=0.875\times 0.825+0.125\times 0.7=0.809375$；RTO=1.984375秒。三次都高于本页1秒下限。若先更新 $S$ 再求偏差，第二行就会得到不同结果，违反指定次序。

在另一条时间线上，时刻10发出数据，RTO=2.225。到12.225仍无新确认，重传并退避至4.45秒；若继续无新确认，下一次到期是16.675。时刻12.4到达的ACK既可能回应原包，也可能回应重传，因此本页不把0.175秒加入估计。若ACK确认全部在途数据，停止计时器；若仍有未确认数据，则依新ACK规则重启。

初始SYN等待时若发生超时，并且实现使用小于3秒的RTO，RFC6298另要求握手完成后开始数据传输时把RTO重新初始化为3秒。这是握手特定条件，不能遗漏后仍称“覆盖该RFC全部初始化路径”。本页主要算例从已有有效数据RTT开始。

重传计时器为了修复传输缺口；应用deadline理路端到端deadline与剩余预算End-to-end deadline · Timeout budget · Deadline propagation把解析、建连、等待、退避和重试计入同一个本地截止点，计算剩余预算并界定跨机器传播与取消的含义。为了限制整个调用愿意等待多久。一个调用可以在TCP下一次重传之前就到达deadline；也可能经历多次TCP重传而仍在业务预算内。两者不应共用一个含糊的“超时”字段。

RTO到期是发送者的观察，不是原包必丢、对端必死或业务必未执行的证明。拥塞控制还规定超时后怎样降低发送窗口；那是另一个状态更新理路Reno拥塞窗口与丢失响应TCP Reno · Congestion window · Slow start · Fast retransmit · Fast recovery固定RFC5681的Reno式规则，按ACK、三次重复确认和RTO事件核算cwnd与ssthresh，区分FlightSize及接收窗口。，不能只加倍计时器而保持任意大的发送压力。