接口 P99 突然多 42ms：Nagle 遇上延迟 ACK 的 TCP 经典坑，一次用 tcpdump 定位实录

一、现象：P50 正常，P99 却整齐地卡在 240ms

上个月我们给内部一套 RPC 网关做性能验收，目标 P99 < 200ms。压测结果反复出现一个诡异的现象：

• QPS 稳定 3000，P50 = 180ms，P95 = 198ms，P99 = 241ms；
• 把 P99 毛刺按时间轴铺开看，几乎全部落在 196ms ~ 212ms 这个区间，且集中在每次请求的第一个小响应包上；
• 服务端 CPU 31%、内存 42%、GC 日志干净（Young GC 最长 23ms）、连接池无等待；
• 客户端换了一台机器、换了一条机房内链路，毛刺依旧。

最初两个嫌疑人：服务端 GC（被日志排除了）、链路抖动（换链路复现，排除）。剩下最可疑的，是「请求-响应」本身的小包行为。

二、根因：Nagle 算法 × 延迟 ACK，一个 40ms 的「握手」

先讲机制，这是 TCP 里两个各自合理的特性撞在一起的经典事故：

1. Nagle 算法（RFC 896）：如果发送方有一笔未确认的小包在途，就不立刻发下一个小包，而是等新包攒够 MSS（通常 1448 字节）或等 ACK 回来。目的是把大量小包合并，省带宽。
2. 延迟 ACK（RFC 1122 建议）：接收方故意等最多 500ms（Linux 实际用 inet_min_rtt 相关的 40ms 下限，net.ipv4.tcp_delack_min）才回 ACK，希望「ACK 正好捎带一个数据包」双向都省。

两者相遇就死锁了：

• 发送方：「我有个 60 字节的小包发出去了，ACK 还没回，Nagle 说先等等；」
• 接收方：「我收到小包了，但延迟 ACK 说等 40ms 再确认。」
• 结果：每个「小请求 → 小响应」的往返，额外固定多等约 40ms。

这在大流量、大包的链路里几乎无感（Nagle 根本不触发）；但一旦你的业务模式是「小请求 + 小响应 + 长连接复用」（RPC、gRPC 内小 proto、Redis 短命令），每一次都会踩中——这就是为什么 P99 被整齐地顶到 240ms 而不是随机毛刺。

三、定位与修复：三条命令 + 一行代码

1. 抓包确认（服务端）

tcpdump -i bond0 -s 96 -nn 'tcp port 8080' -w /tmp/rpc.pcap

用 Wireshark / tshark 看：

tshark -r /tmp/rpc.pcap -Y 'tcp.analysis.retransmission or tcp.flags.ack==1' \
       -T fields -e frame.time_relative -e ip.src -e tcp.flags -e tcp.len \
       | awk '{print $1, $4, $5}' | head -50

关键证据：响应包发完后 40.0ms 左右才看到 ACK，且这个 ACK 是「空 ACK」（tcp.len=0）。这个 40ms 的下限就是 tcp_delack_min 的默认值。

2. 关闭发送端 Nagle（推荐做法）

Java / Netty：socket.setTcpNoDelay(true) 或 ChannelOption.TCP_NODELAY。 Go：net.Dialer{Control: ...} 里 setsockopt TCP_NODELAY，或用 net.TCPConn.SetNoDelay(true)。 Nginx upstream：proxy_socket_keepalive on; + 上游 socket 层设置；如果是自研网关，直接在 socket 建连时设。

3. 验证

ss -ti dst :8080 | grep -E 'unacked|retrans|nodelay'
# 复测：P50 = 178ms，P99 = 196ms，回到目标内

耗时对比（同压测条件，5 分钟窗口）：

| 指标 | 修复前 | 修复后 | |---|---|---| | P50 | 180ms | 178ms | | P95 | 198ms | 194ms | | P99 | 241ms | 196ms | | 40ms 级空 ACK 次数 | 12,431 | 0 |

四、踩过的坑（反直觉之处）

1. ping 完全正常：ping 是单包、无 Nagle 参与，永远测不出这类问题。这类 40ms 毛刺在链路层监控里零信号。
2. 抓包时毛刺消失了：抓包会打开 tcpdump 的 PROMISC 且让内核走 SOCK_RAW，部分内核路径会绕过 delayed-ACK 优化——必须在不抓包的状态下复现一次，再抓 30 秒做二次确认，否则你看到的 40ms 可能只是抓包副作用。
3. 不要关 tcp_delack_min：改内核参数 sysctl net.ipv4.tcp_delack_min=1000 把下限调小是全局副作用，会让所有短连接都变「快 ACK」，反而放大带宽压力。正确姿势是只在 RPC / 小响应场景关 Nagle（发送端单侧），接收端保持延迟 ACK。
4. TCP_NODELAY 不是万灵药：如果你的响应本身就是大包（> MSS），Nagle 根本不触发，开 TCP_NODELAY 没有任何效果——先确认响应包长再动手。
5. 压测报告里 P99 整齐卡在 240ms 是最强信号：随机毛刺是链路/调度问题，整齐落在某个固定偏移是协议栈行为，方向完全不同。

五、可复用清单

1. 诊断顺序：P99 整齐偏移 → 排除 GC → 排除链路 → 抓包看空 ACK 间隔 → 定位 Nagle/延迟 ACK。
2. 必查参数：net.ipv4.tcp_delack_min（默认 40）、发送端是否 TCP_NODELAY、响应包是否 < MSS。
3. 修复姿势：发送端单侧关 Nagle，不要动接收端、不要动内核全局参数。
4. 验证工具：tshark 过滤 tcp.len==0 && tcp.flags.ack==1 看空 ACK 间隔分布；ss -ti 看 unacked。
5. 红线：任何「改内核参数解决单服务问题」的方案都要过一遍副作用评估，尤其是 tcp_delack_*、tcp_no_metrics_save、tcp_mtu_probing 这三组。