Linux TCP backlog 怎样区分监听队列和连接队列

Linux 服务出现“连接偶尔超时”时，backlog 往往被误认为只有一条队列。实际上，服务端要分别看两类压力：还没有完成三次握手的请求通常处于 SYN_RECV，已经建立连接但还没被应用调用 accept() 取走的连接则等待在监听 socket 的 accept 队列中。

官方文档：https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html

先看监听 socket 的 ss -lnt：LISTEN 行的 Recv-Q 可用来观察当前 accept 队列，Send-Q 通常表示该监听 socket 的 accept backlog 上限；再用 ss ... state syn-recv 统计半连接请求，并对照 tcp_max_syn_backlog。两边的数字不能混为一谈。

先把两个队列放回 TCP 建连路径

客户端发送 SYN 后，服务端还没有收到最终确认时，请求属于未完成握手的一侧，内核以 SYN_RECV 表示这类请求。Linux 内核文档把 tcp_max_syn_backlog 定义为每个监听器可记住的、尚未收到客户端确认的连接请求上限。

握手完成后，连接进入已建立状态，但应用还没有调用 accept() 取出它时，就会等待在 accept 队列中。这个队列的应用入口是监听 socket，取出后才成为应用可以读写的已接受连接。也就是说，前一侧更接近“握手请求积压”，后一侧更接近“应用消费不够快”。

图1：Linux TCP 两类 backlog 的静态结构说明图，左侧是未完成握手请求，右侧是等待应用取走的已建立连接；不是运行截图。

用 ss 读取监听 socket 的两个数字

先让输出保留数字地址和端口，并只看监听 socket。-l 过滤 LISTEN，-n 避免名称解析，-t 只看 TCP，-p 可以补充关联进程。

# 查看所有 TCP 监听 socket，先观察 LISTEN 行的 Recv-Q 和 Send-Q
ss -lnt

# 只看 8443 端口，并显示负责监听的进程信息
ss -lntp 'sport = :8443'

# 统计 8443 端口仍处于 SYN_RECV 的请求，观察未完成握手一侧
ss -ant state syn-recv '( sport = :8443 )'

对 LISTEN 行来说，可以把 Recv-Q 暂时理解为当前等待 accept() 的连接数量，把 Send-Q 理解为这一侧的队列上限。下面这行只是阅读格式的静态示意，不代表某台机器的实测结果：

State  Recv-Q  Send-Q  Local Address:Port
LISTEN 37      512     0.0.0.0:8443

在这个示意中，37 更接近已建立但尚未被应用取走的连接数量；512 是监听 socket 的 accept backlog 上限。它不能告诉你 SYN 队列当前有多少请求，所以还要单独看 state syn-recv。

把内核参数和应用 backlog 对上

accept 队列至少受两层输入影响：应用在 listen(fd, backlog) 里提出的 backlog，以及系统的 /proc/sys/net/core/somaxconn 上限。Linux 的 listen(2) 手册说明，当应用传入的 backlog 大于 somaxconn 时会被截断；内核文档当前把 somaxconn 的默认值写为 4096。

SYN 队列则看 /proc/sys/net/ipv4/tcp_max_syn_backlog。它是每个监听器保存未完成连接请求的上限，与 accept 队列的当前数量不是同一个指标。如果启用了 syncookies，内核文档说明该设置可能不再代表一个实际的逻辑最大队列，因此排查时要把它当作配置线索，而不是单独的结论。

# 查看系统对已建立连接队列和未完成握手队列的配置线索
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

# 读取指定监听端口的当前队列与上限，便于和参数放在同一张记录表里
ss -lntp 'sport = :8443'

# 查看关联进程及其监听端口，避免把别的服务的 SYN_RECV 算进来
ss -lntp | grep ':8443'

图2：内核参数、应用 listen(backlog) 与 ss 字段之间的静态依赖说明图；不是终端截图，也不表示某个固定默认值适用于所有发行版。

按现象选择排查方向

如果 ss -lnt 中某个 LISTEN socket 的 Recv-Q 长时间接近 Send-Q，优先检查应用是否没有及时调用 accept()：例如工作线程被慢请求拖住、事件循环阻塞、进程 CPU 饱和，或服务刚好处于重载阶段。此时只增大内核上限，不会自动提高应用消费速度。

如果 LISTEN 的 Recv-Q 不高，但同一端口的 SYN_RECV 请求很多，则更应检查握手流量、上游负载均衡、连接突发和 tcp_max_syn_backlog 的关系。SYN_RECV 数量是观察线索，不等于一定发生了攻击或一定需要调大参数。

调整前要先记录应用实际传入的 backlog、somaxconn、tcp_max_syn_backlog、监听端口和内存余量。不要把 tcp_abort_on_overflow 当成通用修复：内核文档明确提醒，监听服务太慢时启用它会直接复位连接，并可能伤害客户端。

可以用下面的最小排查表整理证据：

常见问题

为什么不能只看 tcp_max_syn_backlog？

因为它针对未完成握手请求，而很多“连接建立后卡住”的现象其实是 accept 队列或应用消费慢。两侧状态不同，应该分别使用 state syn-recv 和 LISTEN 行的队列字段观察。

ss -ant state established 能直接得到 accept 队列吗？

不能。它会列出已经建立的连接，其中既包含已经被应用接受的连接，也可能包含等待应用取走的连接；监听 socket 的 LISTEN 行更适合观察 accept 队列当前值。

把 somaxconn 调大后就一定有效吗？

不一定。应用的 listen(backlog) 仍然会参与限制，应用本身的 accept() 速度也不会因参数变大而自动提升。应先确认瓶颈属于哪一侧，再按内存与流量边界做小幅调整。

总结

记住三组对应关系：SYN_RECV 代表未完成握手请求，tcp_max_syn_backlog 是这侧的重要配置线索；LISTEN 的 Recv-Q 代表当前等待应用取走的连接，Send-Q 是 accept backlog 上限线索；listen(backlog) 还会受到 somaxconn 截断。排障时先按端口分组，再分别看两类队列，才能知道该查网络握手还是应用 accept。