TCP全连接队列溢出：原理与快速定位指南

某次电商大促预热阶段，商品详情页服务出现大量客户端连接超时，负载监控显示服务端CPU、内存均无异常，初步排查发现是TCP全连接队列溢出导致服务端主动拒绝新连接。该问题在高并发场景下极为常见，核心矛盾往往出在内核参数配置与研发侧参数设置的错配，以及故障定位方法的不规范。

内核队列机制与核心参数

TCP三次握手过程中，服务端会维护两个独立队列：第一次握手收到的SYN请求会放入TCP半连接队列（SYN队列），待收到客户端的第三次握手ACK后，连接会被移入全连接队列（accept队列），等待应用层调用accept()消费。

内核中与队列长度直接相关的核心参数有三个：

1. net.ipv4.tcp_max_syn_backlog：半连接队列的最大长度，默认值随内核版本不同多为256或1024；

1. net.core.somaxconn：全连接队列的最大长度，默认值为128，是大多数生产环境溢出的核心诱因；

1. 服务端代码调用listen()时传入的backlog参数（研发侧通常通过SO_BACKLOG配置项设置），其实际生效值为min(传入的backlog值, somaxconn)。多数研发会忽略该规则，在代码中设置SO_BACKLOG=2048，但未调整内核somaxconn，导致配置完全不生效。

故障快速定位与配置落地

全连接队列溢出与半连接溢出的表现与定位方式有明显差异：半连接溢出通常伴随SYN洪水攻击，dmesg日志会打印TCP: possible SYN flooding on port xxxx；全连接溢出则多因应用层accept消费速度不足，表现为客户端连接超时、服务端日志出现大量ECONNREFUSED错误，dmesg可能打印TCP: listen backlog full。

最精准的定位方式是使用ss命令查看队列状态：

# 查看指定端口的TCP监听队列情况

$ ss -lnt sport = :8080

State      Recv-Q     Send-Q       Local Address:Port       Peer Address:Port

LISTEN     128        128          0.0.0.0:8080             0.0.0.0:*

其中Recv-Q列表示当前全连接队列中已建立但未被应用层accept的连接数，若该值持续等于或超过listen的backlog值，即可判定为全连接队列溢出。

配置落地时需注意两层对齐：内核侧可通过echo 1024 > /proc/sys/net/core/somaxconn临时调整全连接队列长度，永久生效需在/etc/sysctl.conf中添加net.core.somaxconn=1024并执行sysctl -p；研发侧配置SO_BACKLOG时需确保其值不超过内核somaxconn，例如Java Netty场景下需同步调整ChannelOption.SO_BACKLOG与内核参数，Go语言net.Listen的backlog参数同理。若应用层accept线程池配置过小，即使队列再大也会因消费不足导致溢出，需配合线程池调优共同解决。

为提升排查效率，可封装一键检测脚本，直接比对Recv-Q与somaxconn的大小，避免反复手动查询内核参数与队列状态。