北京到上海的一条跨机房专线,单向传播时延(裸 ping 的 min RTT)稳定在 32ms 上下。业务是一个在线推理网关往远端参数服务拉权重、再回传打分结果的 RPC 调用,payload 从几十 KB 到几 MB 不等。压力一上来,同一条链路上这个调用的 srtt(内核给出的平滑 RTT)p50 还能维持在 40ms,p99 直接飙到 280–320ms,而且是抖的——同一个接口,连续两分钟采样,尾延迟能在 90ms 和 310ms 之间来回跳,没有任何规律。按常识排查了一圈,能想到的都不成立:CPU 没打满,GC 没有长停顿,业务线程的处理耗时(从收到请求到 write 出去)p99 只有 6ms;带宽没有打满,监控上这条 10Gbps 链路的平均利用率长期在 40% 以下,峰值也就 70%;丢包率极低,netstat -s里 retransmit 段占已发送段的比例不到 0.05%。这几条排除法很关键,因为它们把最常见的几个嫌疑犯都摘掉了。CPU 空着,不是算力问题;业务线程 6ms,不是代码或 GC 问题;带宽利用率 40%,不是"管子太细流量太大"的容量问题;丢包率万分之五,更不是"链路质量差、包一直在丢"的问题。一个系统慢,通常逃不出"算力不够/代码有锁/带宽打满/丢包严重"这四类,可这四类在这里全都不成立。当所有常规嫌疑犯都有不在场证明,剩下的那个再不可能,也是真凶。带宽没满、丢包几乎没有、CPU 空着,延迟却在 300ms 上下剧烈抖动。这不是一个"资源不够"的问题,是一个"资源用错了"的问题。把发送端的 TCP
