瞬时 4000 连接打进来 137 个被 RST：listen backlog 溢出的定位与止血

结论先行：偶发拒连、CPU 不高、连接池没满、GC 日志看着也"正常"——这时候第一嫌疑往往是第三队，也就是 accept 队列（listen backlog）溢了。三次握手已经完成的连接，得等应用主动 accept() 才真正"进店"；应用一旦消费不及时，门口等位区满了，内核就会 RST 或丢 SYN。下面是一次真实的定位与止血记录。

一、现象：大促预热 3 秒，137 个请求被"赶出门"

2024 年某次支付网关预热压测，网关是 Go 1.21 + 一个 Java 17（JDK 17.0.9，G1）的下游聚合服务。压测脚本在 3 秒内打进来约 4200 个新 TCP 连接，结果客户端侧有 137 个请求收到 ECONNRESET (Connection reset by peer)，全部集中在尖峰开始后的 200ms 窗口内，之后迅速恢复。

诡异的地方在于：

• 网关 CPU 峰值才 61%，远没打满；
• HikariCP / 业务连接池都没满，active=14/50；
• 应用自己的超时日志一条都没有。

也就是说，从应用自己的视角看，它"什么都没干错"，可客户端就是被 RST 了。

二、原理：TCP 的"三队"，第三队最容易被人忘

很多人只记得前两队：

1. SYN 队列（半连接）：收到 SYN 回 SYN-ACK，等第三次 ACK；
2. accept 队列（全连接）：三次握手完成后，连接在这里排队，等应用 accept() 取走。

listen backlog 约束的是第 2 队的长度，受内核参数 net.core.somaxconn 与应用 listen(fd, backlog) 两者取较小值。

打个比方：三次握手 = 客人已到店门口；accept() = 服务员领位入座；backlog = 门口的等位区。等位区（backlog）满了之后，新来的客人要么被当场赶回去（内核直接发 RST），要么根本进不了门（丢 SYN，客户端表现为超时重传）。

两种表现由 net.ipv4.tcp_abort_on_overflow 决定：

• =1：队列满时内核直接回 RST → 客户端看到 ECONNRESET；
• =0（多数发行版默认）：丢弃该 SYN → 客户端表现为连接超时。

所以"偶发 reset"和"偶发超时"，可能背后是同一个队列在溢出，只是内核处理方式不同。

三、具体做法：从观测到止血

1. 先看内核上限

sysctl net.core.somaxconn
# 当时输出：net.core.somaxconn = 128   ← 内核默认值，太小

2. 用 ss 看 accept 队列的真实占用

关键陷阱：对 LISTEN 状态的 socket，Recv-Q 列就是 accept 队列当前长度，Send-Q 列就是 backlog 上限（不是未读数据！）

ss -lnt
# State   Recv-Q  Send-Q   Local Address
# LISTEN  96      128      *:8443      ← Recv-Q 已逼近上限 128

事故时我把 ss -lnt 的 Recv-Q 做成了 100ms 一次的采样，峰值打到了 128（正好顶到上限），这就是溢出的直接证据。

3. 抓包确认是内核发的 RST

tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-rst) != 0' -c 20
# 能看到 RST 的源端口正是 8443，且紧随在一段 SYN 风暴之后

4. 止血（治标）

# 内核侧
sysctl -w net.core.somaxconn=4096
echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow   # 让溢出显性化为 RST，便于监控
# 应用侧把 listen backlog 同步调大
#   Go:    net.Listen("tcp", addr, ...) 实际 backlog 受 somaxconn 限制，需配合上面的 4096
#   Java:  ServerSocket 默认即 somaxconn；Netty 设 channel.option(ChannelOption.SO_BACKLOG, 4096)
#   nginx: listen 8443 backlog=4096;

5. 治本：让 accept 跟得上

backlog 只是"加宽等位区"，真正要做的是缩短单次 accept 的消费延迟。这次根因是下游 Java 服务一次 G1 退化到串行 Old，STW 停顿 480ms，期间 accept 线程被冻住，3s 尖峰的连接全堆在第 2 队。修复：

• 把堆从 4G 提到 8G 并调 -XX:MaxGCPauseMillis=100，STW 从 480ms 降到 38ms；
• 用 ss -lnt 的 Recv-Q 峰值接入监控，> 上限 70% 就告警。

四、踩过的坑与反直觉

1. backlog 调大不是万能药。它只是把"等位区"加宽，如果 accept() 本身被 STW / 阻塞卡住，队列照样会满——相当于把等位区从 128 个座位扩到 4096，可服务员（accept 线程）一直睡着，照样爆。
2. ss 的 Recv-Q 对 LISTEN socket 不是"未读数据"，很多人拿它当 TCP 数据队列，方向就错了；对监听口它才是 accept 队列长度。
3. tcp_abort_on_overflow 默认值不同，故障长相完全不同：1 表现成"偶发 reset"，0 表现成"偶发超时"。同一根因，两种告警，排查时容易往两个方向跑偏。
4. 内核默认 somaxconn=128 在尖峰场景几乎必爆。4200 连接在 200ms 内挤进来，128 的等位区连一个波峰都吃不下。

五、结论与可复用清单

• 偶发拒连 / 超时 + CPU 不高 + 连接池没满 → 优先怀疑 accept 队列（listen backlog）溢出，别一上来就怪 GC 或下游。
• 三板斧观测：sysctl net.core.somaxconn 看上限；ss -lnt 看 LISTEN 口的 Recv-Q/Send-Q；tcpdump 抓 RST 确认是内核行为。
• 止血：net.core.somaxconn 与应用 SO_BACKLOG 同步调到 ≥4096，并显式设 tcp_abort_on_overflow=1 让溢出可观测。
• 治本：缩短单次 accept 延迟（减少 STW、避免 accept 线程被阻塞）。
• 监控：把 LISTEN 口 Recv-Q / 上限的比值接入告警，>70% 预警。
• 验收数据：调大 backlog + 修 GC 后，复测同样 4200 连接尖峰，RST=0，Recv-Q 峰值降到 96，约 20ms 内消化完毕。

一句话记住它：连接能"握上手"不等于能"被接住"，第三队的等位区满了，前两手都白搭。