RTO 不能拍固定值：太短会无谓重传加剧拥塞，太长则丢包后恢复慢。TCP 动态估计 RTT 并据此计算：对每次确认的样本 RTT 做指数加权移动平均得到 SRTT（平滑 RTT，系数典型 1/8），同时估计偏差 RTTVAR，最终 RTO = SRTT + max(G, 4×RTTVAR)（G 为时钟粒度），并限制在 [1s, 60s] 区间。每次超时重传后 RTO 还要指数退避（×2），避免在网络恶化时火上浇油。
两个经典算法点：1）Karn 算法——重传段的 ACK 无法区分是对原始发送还是重传的确认（重传二义性），所以重传样本不参与 RTT 估计，且退避期间只放大 RTO 不更新估计；开启 TCP 时间戳选项后可用时间戳区分，解除该限制。2）超时重传只是兜底，快速重传（收到 3 个重复 ACK 立即重传不等超时）+ 快速恢复让多数丢包不必等 RTO，RTO 主要兜底「整批丢失」的尾部场景。追问方向：SACK 如何让重传更精确（只重传真正丢的段）、Linux 的 RTO 最小值 200ms 对数据中心低延迟的影响（因此有了 TCP_USER_TIMEOUT 与 RTO 微秒化的讨论）。
（约 430 字）