TCP

【背景】 我负责一条跨机房 gRPC 长连接链路：A 机房（10.10.x.0/24，3 台业务机，Linux 5.15）→ 运营商专线（双上联，ToR 是 Cisco N9K，25G 光模块）→ B 机房（10.20.x.0/24）。业务

结论先行：跨机房 / 高 RTT 场景下「链路明明是 10G、实测却只跑到 5~6G、丢包 0、CPU 不高、换 BBR 也没用」，十有八九不是网络问题，而是 TCP 接收窗口（rwnd）小于带宽延迟积（BDP）——吞吐被 "窗口 / RT

TCP keepalive 默认要等 2 小时才发第一个探测包：一次内网"僵尸连接"打满连接池的排查 一、现象：P99 间歇性飙到 30s，但所有资源指标都"正常" 2024 年 11 月，我们一个支付网关服务（Java 17 + Hika

«一个 8 年性能老兵的线上复盘。不吹概念，只讲我真实排查过的一类"看不见"的延迟。» 一、现象与背景：一个 40ms 的幽灵 2024 年 3 月，某电商订单链路（下单 → 库存 → 价格 → 风控 → 支付路由，共 12 跳同步 RPC

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

«结论先行：Linux 默认的 "tcp_keepalive_time=1800 / intvl=75 / probes=9"，最坏判定死亡要 1800 + 9×75 = 2475 秒 ≈ 41 分钟。在 NAT 空闲超时 300 秒、LB

【背景】 我在 K8s（1.28 / Calico CNI）里跑一批 Java gRPC 微服务，客户端 → HAProxy（stream 模式，L4 TCP 透传）→ 后端 Pod。后端 Pod 单实例并发连接 500~1500，连接是长

«结论先行：偶发拒连、CPU 不高、连接池没满、GC 日志看着也"正常"——这时候第一嫌疑往往是第三队，也就是 accept 队列（listen backlog）溢了。三次握手已经完成的连接，得等应用主动 "accept()" 才真正"进店

一、现象：P50 正常，P99 却整齐地卡在 240ms 上个月我们给内部一套 RPC 网关做性能验收，目标 P99 < 200ms。压测结果反复出现一个诡异的现象： - QPS 稳定 3000，P50 = 180ms，P95 = 198m

先说结论：网络里只要有任意一段链路的 MTU 比你端到端的包小，且中间设备又不做分片、又不回 ICMP Frag Needed，你看到的就不是"丢包"，而是"间歇性 502 / 连接正常但传输卡住"。这类问题最容易骗过 ping、骗过抓包的