首先，让我们聚焦一个常被忽视却至关重要的技术细节：TCP 三次握手过程中，服务端收到 SYN 并发出 SYN-ACK 后、尚未等到客户端 ACK 返回的“悬空”状态，实际上隐藏着不少性能瓶颈。很多开发者在调优服务器时，只关注修改 net.core.somaxconn 参数，却忽略了半连接队列本身的管理。结果在高并发场景下，客户端频频超时，而服务端却难以定位问题。本文将全面解析如何有效配置和优化半连接队列。
什么是半连接（SYN Queue）？
半连接并非指已建立的连接，而是 TCP 三次握手过程中，服务端收到 SYN 包、发送 SYN+ACK 后、尚未收到客户端 ACK 的中间过渡状态。这些未完成握手的连接被临时存放在内核的 syn queue（即 SYN backlog）中，其队列长度由内核参数 net.ipv4.tcp_max_syn_backlog 决定。它与 net.core.somaxconn（全连接队列上限）常被混淆，但两者功能截然不同：前者管理的是正在握手阶段的请求，后者管理的是已完成握手、正等待应用程序调用 accept() 的连接。
如何查询当前半连接队列大小？
直接读取内核参数：
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
系统默认值通常为 128 或 256，具体取决于内核版本和内存配置。如果该值设置过小，在高并发短连接场景下，SYN 包可能被直接丢弃，导致客户端超时或触发重传。服务端通过 ss -s 或 netstat -s | grep -i "listen overflows" 输出进行判断，当出现 listen overflows 时，即表明半连接队列已溢出。
如何永久增大半连接队列？
修改 /etc/sysctl.conf 配置文件，添加或调整以下行：
net.ipv4.tcp_max_syn_backlog = 65535
然后执行：
sudo sysctl -p
需要特别注意以下三个关键点：
tcp_max_syn_backlog的设置值必须小于或等于net.core.somaxconn，否则内核会自动将其截断为somaxconn的值。因此，在调大tcp_max_syn_backlog之前，务必先同步增大net.core.somaxconn- 部分较新版本的内核会根据系统内存自动计算该参数，手动设置后建议通过
sysctl net.ipv4.tcp_max_syn_backlog验证是否已生效 - 应用程序监听 socket 时传入的
backlog参数（例如listen(fd, backlog)中的backlog）必须小于等于tcp_max_syn_backlog，否则内核会静默截断。许多 Go 或 Python 服务默认的 backlog 值为 128，远低于调优后的系统值，因此需要同步修改代码或启动参数
为什么调优后仍然出现溢出？常见被忽略的因素
半连接队列溢出不只取决于单个参数，以下情况可能导致配置“看似生效实则无效”：
- 未关闭
net.ipv4.tcp_syncookies。当该参数为1（默认值）时，内核在队列满时会启用 SYN Cookie 机制，伪造 SYN+ACK 响应，虽然能掩盖溢出问题，但会增加延迟和 CPU 开销。如需真实测试队列容量，可临时关闭：echo 0 > /proc/sys/net/ipv4/tcp_syncookies - 服务监听时使用了过小的
backlog值。例如 Nginx 默认的listen ... backlog=511，即使系统设定了 65535，实际起作用的仍是应用层的 511。需要在nginx.conf的listen指令中显式指定backlog=65535 net.core.somaxconn设置过低。该参数不仅限制全连接队列，也会间接影响半连接队列的最大值。建议将两者设为相同量级，例如都设置为65535
真正有效的半连接队列优化，需要确保 tcp_max_syn_backlog、somaxconn 以及应用层的 backlog 三者保持一致或适当对齐，并在关闭 SYN Cookie 干扰后，通过实际测试确认 listen overflows 的计数不再增长。
