Linux设置最大半连接数

首先介绍一个容易被忽略但至关重要的细节：TCP 三次握手中，服务器收到 SYN 之后、尚未等到 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，否则实际生效值会被截断为后者；因此务必先确认并同步调大 net.core.somaxconn
• 某些较新版本的内核会根据内存自动计算该值，手动设置后需验证是否真正写入：sysctl net.ipv4.tcp_max_syn_backlog
• 应用层监听 socket 的 backlog 参数（如 listen(fd, backlog) 中的 backlog）必须 ≤ tcp_max_syn_backlog，否则内核会静默截断——很多 Go/Python 服务默认使用 128，远低于调优后的系统值，需同步修改代码或启动参数

为什么调了之后仍然溢出？容易忽略的细节

半连接队列溢出并非仅由单一参数决定。以下情况可能导致配置“看似生效实则无效”：

• 未关闭 net.ipv4.tcp_syncookies：设为 1（默认开启）时，内核在队列满时会启用 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 三者对齐，并在关闭 syncookie 干扰后，实测 listen overflows 计数不再增长。