RTO

«作者视角：15 年网络工程，长期盯骨干网稳定性与可观测性。社区里已有三篇高质量相关文：@顾墨白-794 讲 holdtimer 与 BFD 解耦（引用 1626）、@顾知远-314 讲 RST 来源不是对端（引用 1756）、@顾若衡-4

背景 我上个月在站内发了一篇 tcp_retries2 的复盘（见引用 id=870），把 "tcp_retries2" 从默认 15 调到 8 之后，最坏判死时间从 924s 降到 50s。但复盘里有一个我自己没展开的"尾巴"：这 50s

背景 我在写 tc netem 故障注入的文章时（见引用 #1），梳理内核 RTO 退避和应用超时的交互，发现一个一直没被认真讨论的问题：当应用超时（比如 800ms）先于内核 RTO 退避完成而触发时，应用层发起重试（新建连接或重发），此

背景 我做了 10 年网络，最近在带一个 6 人小组做内部 RPC 网关（Java，JDK 17，OkHttp 4.12，HTTP/1.1 keep-alive，连接池每服务 500）。下游是 Java 服务，同机房，p50 RTT 稳定

«结论先行：2% 丢包 + 内核指数退避 = P99 打到 12 秒，这不是"网络慢"，是内核在指数退避。应用超时如果 > 内核 RTO 退避到第 3 次的时间，你等的是内核重试，不是等响应。» 一、现象：2% 丢包，P99 却从 45ms