请求偶发超时服务端却没日志:一次 Linux tcpdump 抓包定位连接队列溢出

2024 年,我负责的一个对外 API 出了个怪毛病:偶发超时。不是全挂,是大约百分之几的请求,客户端那边报连接超时;剩下九成多的请求,又快又好。我第一反应当然是服务端慢了,于是我扑进服务端去查:GC 日志,正常,没有长停顿;线程池,正常,没有排队;慢 SQL,正常,没有慢查询;接口的耗时监控,正常,P99 也就几十毫秒。我把服务端能查的指标翻了个底朝天,没有任何一项指标显示它"慢"。可就在我对着这些漂亮的指标发愣的时候,我才注意到一个被我忽略的、更要命的事实:那些客户端报超时的请求,在服务端的访问日志里——根本就找不到。一条都没有。我之前一直默认"超时"等于"服务端处理慢了",可如果服务端的日志里压根没有这条请求的记录,那它根本就不是"处理得慢",而是它从来就没被服务端处理过。一个请求,客户端发出来了,服务端却像没收到一样——它消失在了客户端和服务端【中间】的某个地方。我盯着这个"消失的请求"想了很久,意识到我必须跳出服务端的应用层,到更底下的网络层去看。这件事逼着我学会了用 tcpdump 抓包,也把 TCP 三次握手、半连接队列、全连接队列(accept 队列)这一整套彻底理清了。本文复盘这次实战。

问题背景

环境:CentOS 7,一个对外 HTTP API 服务(Java),并发不低
事故现象:
- 约百分之几的请求,客户端报 connection timeout
- 服务端 GC / 线程池 / 慢 SQL / 接口耗时监控,全部正常
- ★ 关键:这些超时的请求,服务端 access log 里【完全没有记录】

现场排查:
# 1. 服务端各项指标都正常,但日志里没有那些超时请求
$ grep '客户端那条超时请求的特征' access.log
#（空）—— ★ 请求根本没到应用层

# 2. ★ 既然应用层没收到,就到网络层抓包看
$ tcpdump -i any -nn 'tcp port 8080 and tcp[tcpflags] & tcp-syn != 0'
... IP 客户端.51000 > 服务端.8080: Flags [S], seq 1, ...   # SYN
... IP 客户端.51000 > 服务端.8080: Flags [S], seq 1, ...   # ★ 同一个 SYN 又来了
... IP 客户端.51000 > 服务端.8080: Flags [S], seq 1, ...   # ★ 再来一次
# ★ 客户端的 SYN 发了好几遍 —— 它在【重传】,因为没收到 SYN-ACK

# 3. ★ 看 8080 这个监听 socket 的队列状况
$ ss -lnt | grep 8080
State   Recv-Q   Send-Q   Local Address:Port
LISTEN  129      128      0.0.0.0:8080
#        ^^^      ^^^
#        ★ Recv-Q 满了(已超过 Send-Q 这个上限 128)

# 4. ★ 看队列溢出的计数器
$ netstat -s | grep -i 'listen'
    3721 times the listen queue of a socket overflowed   # ★ 队列溢出 3721 次
    3721 SYNs to LISTEN sockets dropped                   # ★ 丢了 3721 个连接

根因(后来想清楚的):
1. ★ 超时的请求,服务端 access log 没有 —— 因为它们
   根本没到应用层。它们死在了【TCP 连接建立】这一步。
2. 一个 socket 在 LISTEN 时,内核为它维护一个【全连接
   队列(accept 队列)】:三次握手【完成】的连接,
   先放进这个队列里排队,等应用程序调 accept() 取走。
3. ★ 这个队列有大小上限。我的服务并发一高,握手完成
   的连接涌进来的速度,超过了应用 accept() 取走的速度,
   队列【被塞满】了。
4. 队列一满,内核对新完成握手的连接,默认行为是
   【直接丢弃】—— 表现就是客户端的 SYN 收不到回应,
   只能不停重传,重传几次还不行,就是 connection timeout。
5. ★ 所以这是个"间歇性"问题:并发低、队列不满时,
   一切正常;并发一冲高、队列瞬间溢出,那一批请求
   就被丢 —— 百分之几的超时,就这么来的。
请求"超时但服务端没日志" = 它没进应用层,死在了 TCP 连接队列。

修复 1:"超时但没日志"——请求根本没进应用层

# === ★ 纠正第一个误区:超时 ≠ 服务端处理慢 ===

# === 我以为的 vs 真实的 ===
# 我以为:客户端报"超时",一定是服务端【收到了请求、
#   但处理得太慢】,慢到客户端等不及了。
# ★ 真相:"超时"只说明"客户端在规定时间内没等到
#   完整响应"。请求可能死在任何一环 ——
#   它可能根本没【到达】服务端,
#   它可能到了但没【进入应用层】,
#   它也可能进了应用层但处理慢。
#   "处理慢"只是其中【最后一种】可能。

# === ★ 一个决定性的线索:服务端日志里有没有它 ===
# 这是分水岭,一定要先确认:
$ grep '超时请求的特征(traceId/时间/路径)' access.log
# - ★ 日志里【有】这条请求 -> 它确实进了应用层。
#   那才轮到查 GC、线程池、慢 SQL 这些"处理慢"。
# - ★ 日志里【没有】这条请求 -> 它【压根没进应用层】。
#   再怎么查应用层指标都是白费 —— 问题在更下面。

# === 我的错:在错的楼层查了一整天 ===
# 我那些超时请求,access log 里一条都没有。这本该
#   第一时间就把我的排查方向【从应用层踢到网络层】。
#   可我惯性地认定"超时=慢",在应用层的 GC、线程池
#   里翻了一整天 —— 翻得越仔细,离真相越远。

# === ★ 请求到达服务的完整路径(每一段都可能丢)===
# 客户端
#   -> 网络(可能丢包)
#   -> 服务器网卡 / 防火墙(可能被拦)
#   -> 内核 TCP 三次握手(★ 半连接/全连接队列可能溢出)
#   -> 应用 accept() 取走连接
#   -> 应用层处理(这里才有 access log)
# ★ access log 是【应用层】的产物。日志里没有,
#   说明请求死在了"应用层之前"的某一段。

# === 认知 ===
# ★ 排查超时,第一步不是看 GC,是先回答一个问题:
#   "这个请求,到底进没进应用层?"
#   ——看服务端日志里有没有它。答案决定你该查哪一层。

修复 2:tcpdump 抓包——亲眼看见 SYN 在重传

# === ★ 应用层没有答案,就下到网络层:tcpdump 抓包 ===

# === tcpdump 最基础的用法 ===
$ tcpdump -i any -nn port 8080
#  -i any  :抓所有网卡。也可指定具体网卡 -i eth0
#  -nn     :★ 不把 IP 解析成域名、不把端口解析成服务名
#            (解析很慢、还会卡,排查时一律加 -nn)
#  port 8080 :只抓和 8080 端口相关的包
# ★ 抓包会刷屏,建议写文件慢慢分析:
$ tcpdump -i any -nn port 8080 -w /tmp/cap.pcap
#  -w 写成 pcap 文件,事后用 tcpdump -r 读,或拖进 Wireshark。

# === ★ 只盯连接建立:抓 SYN 包 ===
# 我怀疑问题在"连接建立"阶段,就专门抓 SYN:
$ tcpdump -i any -nn 'tcp port 8080 and tcp[tcpflags] & tcp-syn != 0'
# tcp[tcpflags] & tcp-syn != 0 = 只要带 SYN 标志的包。

# === ★ 抓到的现象:同一个 SYN,反复出现 ===
12:00:01.100  IP 客户端.51000 > 服务端.8080: Flags [S], seq 1
12:00:02.100  IP 客户端.51000 > 服务端.8080: Flags [S], seq 1   # 1 秒后重发
12:00:04.100  IP 客户端.51000 > 服务端.8080: Flags [S], seq 1   # 2 秒后又重发
# ★ 关键解读:
#  - 同一个 (客户端.51000, seq 1),一模一样地出现多次
#    —— 这是【SYN 重传】。
#  - 重传的间隔 1s、2s、4s…… 翻倍 —— 这是 TCP 重传的
#    标准指数退避节奏。
#  - 客户端为什么重传?★ 因为它发出 SYN 后,【没有
#    收到服务端的 SYN-ACK】。它以为 SYN 丢了,就重发。

# === ★ 再看服务端这边:它到底回没回 SYN-ACK ===
# 在抓包里找服务端发出的、带 SYN+ACK 的包:
$ tcpdump -i any -nn 'tcp port 8080 and tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)'
# ★ 我这次的结果:对那些重传的连接,服务端【根本
#   没有发出 SYN-ACK】。
# 这就把问题彻底锁死了:不是网线丢包(那样会随机),
#   是【服务端这边,收到了 SYN,却没有回应】——
#   内核主动把这个连接请求丢弃了。

# === 认知 ===
# ★ tcpdump 是网络问题的"X 光机"。应用层指标都正常、
#   请求却像凭空消失时,抓包能让你【亲眼看到】
#   数据包到底走到哪一步、是谁没回应。

修复 3:全连接队列溢出——握手完成了却没人接

# === ★ 真凶:accept 队列(全连接队列)满了 ===

# === 先理清:一个 LISTEN socket 背后有两个队列 ===
# 服务端 socket 一旦 listen(),内核为它维护【两个队列】:
# 1. ★ 半连接队列(SYN queue):
#    收到客户端 SYN、回了 SYN-ACK、但还在等客户端
#    最后那个 ACK 的连接 —— 握手【没完成】,放这里。
# 2. ★ 全连接队列(accept queue):
#    三次握手【已完成】的连接,放这里【排队】,
#    等应用程序调用 accept() 把它取走。
# 一个连接的旅程:SYN 到 -> 进半连接队列 -> 握手完成
#   -> 移到全连接队列 -> 应用 accept() 取走 -> 开始干活。

# === ★ 全连接队列满了会怎样 ===
# 全连接队列有大小上限。如果连接握手完成的速度,
#   快过应用 accept() 取走的速度,队列就会【堆积、
#   直至溢满】。
# ★ 队列一满,内核对又一个刚握手完成的连接,默认
#   行为(tcp_abort_on_overflow=0)是:把它【悄悄丢掉】,
#   就当没收到那个 ACK。
# 对客户端来说:它发了 ACK 以为连接建好了(甚至
#   把数据都发了),服务端却装没看见 —— 最后超时。

# === ★ 看全连接队列:ss -lnt 的 Recv-Q / Send-Q ===
$ ss -lnt
State   Recv-Q   Send-Q   Local Address:Port
LISTEN  129      128      0.0.0.0:8080
# ★ 对 LISTEN 状态的 socket,这两列的含义很特殊:
#  - Send-Q :★ 全连接队列的【最大长度】(上限)。
#  - Recv-Q :★ 全连接队列【当前的连接数】。
# ★ Recv-Q 持续接近、甚至超过 Send-Q -> 队列在溢出。
#   我这次 Recv-Q 129 > Send-Q 128 —— 实锤溢出。

# === ★ 看溢出的累计计数 ===
$ netstat -s | grep -i -e 'listen' -e 'overflow'
    3721 times the listen queue of a socket overflowed
    3721 SYNs to LISTEN sockets dropped
# ★ "listen queue overflowed" = 全连接队列溢出的次数。
#   这个数字如果【一直在涨】,就是它了。
$ nstat -az | grep -i -e TcpExtListenOverflows -e TcpExtListenDrops
# nstat 看得更清楚,可多跑几次看增量。

# === 认知 ===
# ★ "握手完成 ≠ 应用收到"。握手完成只是把连接放进了
#   全连接队列,还得应用 accept() 取走才算数。
#   队列满了,握手完成的连接照样被丢。

修复 4:连接队列的几个关键参数与坑

# === ★ 全连接队列的上限,到底由谁决定 ===

# === 它是两个值取【小】的那个 ===
# 全连接队列的实际上限 = min(应用 listen() 传的 backlog,
#                            内核的 net.core.somaxconn)
# ★ 这是最容易踩的坑:你以为调大就行,结果被另一个
#   值【按住了】。两个都得够大,才真的够大。

# === 1. 内核参数 somaxconn ===
$ cat /proc/sys/net/core/somaxconn
128                                # ★ 老系统默认才 128 —— 太小
# ★ 高并发服务,这个 128 经常是瓶颈。

# === 2. ★ 应用 listen() 时传的 backlog ===
# 应用代码里 listen(fd, backlog) 那个 backlog 参数。
#  - Java 原生 ServerSocket(port, backlog) 可传。
#  - Tomcat:acceptCount 参数,默认才 100。
#  - Nginx:listen 指令的 backlog= 参数。
#  - Netty:option(ChannelOption.SO_BACKLOG, n)。
# ★ 就算 somaxconn 调到 65535,应用只传了 100,
#   最终上限还是 100 —— 被应用按住了。

# === ★ 半连接队列与 SYN flood ===
# 半连接队列也会满。正常业务下少见,但要警惕:
#  - 真有 SYN flood 攻击:大量只发 SYN 不回 ACK 的连接,
#    把半连接队列占满。
$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog   # 半连接队列大小
$ netstat -s | grep -i 'SYN.*dropped'
# ★ 开 syncookies 能扛半连接队列满(不占队列也能握手):
$ cat /proc/sys/net/ipv4/tcp_syncookies         # 1 = 已开启,保持

# === ★ 坑:队列溢出时,内核怎么处理那个连接 ===
$ cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0
# - 0(默认):队列满,★ 把连接【悄悄丢弃】,装作没
#   收到 ACK。客户端会重传 ACK,有可能"等一下就好了"
#   —— 但表现为偶发超时、难排查。
# - 1:队列满,直接发 RST 把连接【明确拒绝】。客户端
#   立刻收到 "connection reset",失败得很干脆。
# ★ 一般保持 0。它只是"如何报错",不是解决问题 ——
#   真正要做的是把队列【调大】,别让它溢出。

# === ★ 别忘了排查链路上的其他环节 ===
# 请求到应用前还可能经过 Nginx、LVS、云 LB ——
#   它们各自也有连接数、队列、超时配置。
# ★ 如果你的服务前面有反代,这些中间件的 backlog /
#   连接上限,同样要一起检查。

修复 5:正确解法——把连接队列调够,并接得够快

# === ★ 解法:队列调大 + 应用 accept 够快,两手都要 ===

# === ★ 解法 1:调大内核的 somaxconn ===
# 临时生效:
$ sysctl -w net.core.somaxconn=1024
# 永久生效,写进配置文件:
$ echo 'net.core.somaxconn = 1024' >> /etc/sysctl.d/99-net.conf
$ sysctl -p /etc/sysctl.d/99-net.conf
# ★ 高并发服务,1024 起步,按压测结果再往上调。

# === ★ 解法 2:调大应用的 backlog —— 别漏了这一半 ===
# somaxconn 调大后,必须同步把应用的 backlog 也调大,
#   否则上限还是被应用按住。按你的服务改:
# - Tomcat(server.xml 的 Connector):
#     acceptCount="1024"
# - Nginx:
#     listen 8080 backlog=1024;
# - Netty:
#     bootstrap.option(ChannelOption.SO_BACKLOG, 1024);
# - Java 原生:
#     new ServerSocket(8080, 1024);
# ★ 改完重启服务,再 ss -lnt 看 Send-Q 是不是真变大了:
$ ss -lnt | grep 8080
LISTEN  0  1024  0.0.0.0:8080      # ★ Send-Q 变成 1024 才算生效

# === ★ 解法 3:治本 —— 让应用 accept() 取得够快 ===
# 队列调大只是"加大缓冲池",治标。如果应用 accept()
#   之后处理慢、迟迟不回来接下一个,池子再大也会满。
# 根本上要让"取走连接"这一步【足够快】:
#  - accept 之后,尽快把连接交给【工作线程池】处理,
#    别在 accept 线程里做耗时的事。
#  - 工作线程池别太小,别让它成为新瓶颈。
#  - 处理逻辑里的慢操作(慢 SQL、慢的下游调用)要治
#    —— 它们会反压,最终拖慢 accept。

# === 解法 4:扩容,把并发分摊掉 ===
# 单机队列和处理能力终归有上限。并发确实超出单机
#   承载时,加机器、上负载均衡,把连接分摊出去。

# === ★ 验证:压一压,看队列还溢不溢 ===
$ ss -lnt | grep 8080                       # Recv-Q 远低于 Send-Q
$ watch -n1 "netstat -s | grep -i overflow"  # 溢出计数不再增长
$ tcpdump -i any -nn 'tcp port 8080 and tcp[tcpflags] & tcp-syn != 0'
# ★ 抓包确认:不再有大量重复 SYN(重传)。
# 三个一起看,才算这次偶发超时真的根治了。

修复 6:网络层超时排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ "超时"不等于"服务端处理慢",先确认进没进应用层 ===
$ grep '超时请求特征' access.log     # 日志里没有 = 没进应用层

# === 2. ★ 服务端日志没有这条请求,就别在应用层 GC 里找了 ===
# 问题在更下面 —— 网络层 / TCP 连接建立阶段。

# === 3. ★ 应用层没答案,就 tcpdump 抓包看网络层 ===
$ tcpdump -i any -nn port 端口 -w /tmp/cap.pcap

# === 4. 大量重复 SYN = SYN 重传 = 客户端没收到 SYN-ACK ===

# === 5. ★ ss -lnt 看 LISTEN socket:Recv-Q 是当前队列,Send-Q 是上限 ===
$ ss -lnt | grep 端口     # Recv-Q 接近/超过 Send-Q = 全连接队列溢出

# === 6. netstat -s 看 listen queue overflowed 计数,涨就是它 ===

# === 7. ★ 队列上限 = min(应用 backlog, somaxconn),两个都得调大 ===

# === 8. 治本是让应用 accept 取得够快,队列调大只是治标 ===

# === 9. 排查"偶发超时、服务端却没日志"的步骤链 ===
$ grep 请求 access.log               # ① 进没进应用层
$ tcpdump -nn port 端口               # ② 没进就抓包,看 SYN 重传
$ ss -lnt | grep 端口                 # ③ 看全连接队列 Recv-Q/Send-Q
$ netstat -s | grep overflow          # ④ 看队列溢出计数
$ 调大 somaxconn + 应用 backlog       # ⑤ 两个一起调,并加快 accept
# 按这个顺序,网络层的偶发超时基本能定位、能根治。

命令速查

需求                        命令
=============================================================
抓某端口的包                tcpdump -i any -nn port 端口
抓包写文件慢慢分析          tcpdump -i any -nn port 端口 -w /tmp/cap.pcap
读抓包文件                  tcpdump -nn -r /tmp/cap.pcap
只抓 SYN 包                 tcpdump -nn 'tcp[tcpflags] & tcp-syn != 0'
看 LISTEN socket 的队列     ss -lnt | grep 端口
看队列溢出累计计数          netstat -s | grep -i overflow
看 TCP 计数器(看增量)     nstat -az | grep -i ListenOverflows
看 somaxconn               cat /proc/sys/net/core/somaxconn
调大 somaxconn              sysctl -w net.core.somaxconn=1024
看半连接队列大小            cat /proc/sys/net/ipv4/tcp_max_syn_backlog
看 syncookies 是否开启      cat /proc/sys/net/ipv4/tcp_syncookies

口诀:超时不等于处理慢,先看服务端日志有没有这条请求,没有就是没进应用层
      应用层没答案就 tcpdump 抓包,SYN 重传查全连接队列,somaxconn 和 backlog 一起调

避坑清单

1. 客户端报超时只说明它没在规定时间等到响应,请求可能死在任何一环,处理慢只是最后一种
2. 排查超时第一步是确认请求进没进应用层,看服务端日志里有没有它,这决定该查哪一层
3. 服务端日志没有这条请求说明它没进应用层,再查 GC 线程池慢 SQL 都是白费方向错了
4. 应用层查不出就下到网络层用 tcpdump 抓包,它是网络问题的 X 光机能看到包走到哪一步
5. 抓包看到同一个 SYN 反复出现就是 SYN 重传,间隔 1 秒 2 秒翻倍是 TCP 重传的退避节奏
6. SYN 重传说明客户端没收到 SYN-ACK,要确认是服务端没回还是回了在路上丢了
7. LISTEN socket 有半连接和全连接两个队列,握手完成的连接进全连接队列等应用 accept 取走
8. ss -lnt 看 LISTEN socket 时 Recv-Q 是全连接队列当前连接数,Send-Q 是队列上限
9. 全连接队列上限是应用 backlog 和内核 somaxconn 取较小值,只调一个会被另一个按住
10. 队列调大只是治标,治本是让应用 accept 取得够快,处理慢会反压最终把队列拖满

总结

这次"百分之几的请求莫名超时"的事故,纠正了我一个关于"超时"的、几乎是条件反射般的理解。在我的脑子里,"超时"这个词,长久以来只对应着一幅画面:服务端收到了我的请求,然后它在里面慢吞吞地、磨磨蹭蹭地处理,处理得太久了,久到客户端那头失去了耐心,一甩手断开了连接。在这幅画面里,请求是一定【到达】了服务端的,服务端也一定是【在处理】它的——"超时"无非是这场处理的进度条走得太慢。正因为这幅画面在我心里根深蒂固,所以当超时发生时,我整个人是被一种惯性推着走的:我想都没想,就一头扎进了服务端的应用层,扎进了 GC、线程池、慢 SQL 这些"处理慢"的经典嫌疑里。我查得很投入、很仔细,可我查的所有东西,都建立在一个我从未拿出来检验过的前提上——这些请求,确实进到服务端来了。直到我无意中发现,那些超时的请求,在服务端的访问日志里一条都找不到,我才被狠狠地敲了一下:如果服务端的日志里根本没有这条请求,那它就不是"被处理得慢",它是【从来没有被处理过】。我查了一整天的应用层,而真相是,那些请求,连应用层的门都没摸到。复盘到根上,我才明白,我把一个请求"到达服务"这件事,想得太简单、太一步到位了。在我原来的认知里,客户端发出请求,服务端的应用代码就收到了请求——中间是直通的,没有台阶。可真实的路径,是有一连串台阶的:请求要先穿过网络,要经过服务器的网卡和防火墙,然后——这是我从来没有正眼看过的一段——它要先在内核的 TCP 层,完成三次握手,被放进一个叫"全连接队列"的地方排队,一直要等到应用程序亲手调用 accept() 把它从队列里取走,它才算真正踏进了应用层的大门,才会在访问日志里留下第一行记录。我一直以为的"服务端收到请求",其实被切成了两件事:一件是【内核】替应用把连接的握手完成了,把连接放进了队列;另一件,才是【应用】自己把这个连接从队列里取走。这两件事之间,隔着一个有容量上限的队列。而我的事故,恰恰就发生在这道我从不知道其存在的台阶上:当并发冲高,内核完成握手、往队列里塞连接的速度,超过了应用 accept() 取走连接的速度,队列就被塞满了;队列一满,内核对后面再来的、明明已经握手成功的连接,二话不说就【丢掉】——丢得无声无息,客户端那边只能干等,等到超时。所以这是一种间歇性的病:并发低、队列不满时,风平浪静;并发一冲高、队列一溢出,那一小批撞上的请求就被悄悄丢弃。那百分之几的超时,就是这么来的。当我学会用 tcpdump 抓包,亲眼看到客户端的同一个 SYN 包,以 1 秒、2 秒、4 秒翻倍的节奏一遍遍重传、而服务端那边对它始终保持沉默时,我才算真正地、用眼睛"看见"了这个过程。这次最大的收获,是我意识到,排查问题时,我最该警惕的不是那些我答不上来的难题,而是那些我"想都不用想就知道答案"的地方——因为恰恰是在那些地方,藏着我从未检验过的前提。"超时就是处理慢",这个我脱口而出、深信不疑的等式,本身就是一个未经证实的假设;而我一整天的辛苦,全都白白耗在了这个错误假设撑起的空中楼阁里。一个请求从客户端到服务端应用代码,中间是一条有许多段、每一段都可能让它"消失"的长路;"超时"只是这条长路某处断裂后,传回到客户端的一个最终信号,它本身并不告诉你断点在哪。所以下一次,当一个请求又超时了,我不会再凭直觉冲进应用层。我会先问一个最朴素、却最关键的问题:这个请求,到底走到了这条路的哪一段?它进没进应用层?——答案是"没有"的那一刻,我就知道,真正的战场,在我习惯性忽略的、应用层下面的那些台阶上。

—— 别看了 · 2026