Nginx 中 Event Loop 如何优化处理 TCP 握手队列

Nginx通过协同调优内核参数（somaxconn、tcp_max_syn_backlog）与配置（reuseport、backlog、deferred、accept_mutex off、multi_accept on）来缓解全连接队列溢出，核心是加快accept()调用速度并确保队列容量匹配，ss -lnt中Recv-Q持续非零即为积压证据。

Nginx 本身不实现传统意义上的“Event Loop”（如 Node.js 那样由用户代码驱动的单线程事件循环），而是基于操作系统提供的高效 I/O 多路复用机制（epoll、kqueue 等）构建了高度优化的事件驱动模型。它没有独立的 TCP 握手队列，但内核有 syn queue（SYN 队列）和 accept queue（全连接队列），而 Nginx 的行为会显著影响这两个队列的溢出风险。优化关键在于让 Nginx 更快地调用 accept()，避免队列堆积。

调大内核 TCP 连接队列长度

Linux 内核维护两个队列：

• SYN 队列（net.ipv4.tcp_max_syn_backlog）：存放收到 SYN、尚未完成三次握手的连接。若被填满，新 SYN 包会被丢弃（可能触发客户端重传或超时）。
• Accept 队列（net.core.somaxconn）：存放已完成三次握手、等待应用调用 accept() 取走的连接。Nginx 的 listen 指令中 backlog 参数不能超过该值。

建议同步调高两者（例如设为 65535），并确保 Nginx 配置中显式指定足够大的 backlog：

listen 80 backlog=65535;

启用 deferred accept 减少无效 accept 调用

开启 deferred accept 后，Nginx 不会在收到 SYN 就立即调用 accept()，而是等到 TCP 三次握手真正完成、内核把连接移入 accept 队列后才处理。这避免了在 SYN 队列未满但 accept 队列已满时，反复尝试取空连接却失败的问题，也降低 CPU 开销。

配置方式：

listen 80 deferred;

注意：仅适用于 Linux + epoll，且需内核支持（2.6.26+）。

提升 Nginx 工作进程处理能力

如果 worker 进程忙于其他任务（如 SSL 握手、磁盘 I/O、长连接保持），就无法及时从 accept 队列取连接，导致队列积压。关键措施包括：

• 设置 worker_processes auto;，让进程数匹配 CPU 核心数；
• 使用 worker_connections 充分利用每个 worker 的并发能力（通常设为 65535 或更高）；
• 对高 SSL 开销场景，启用 ssl_session_cache 和 ssl_buffer_size 降低握手延迟；
• 避免在配置中使用阻塞操作（如 auth_request 同步调用慢后端、大量正则匹配请求路径）。

监控与验证是否仍存在队列溢出

运行中可通过以下命令检查是否有连接被丢弃：

netstat -s | grep -i "listen overflows|drop"

若输出中 listen overflows 或 dropped 数值持续增长，说明 accept 队列或 SYN 队列已满。还可通过 ss -lnt 查看各监听端口的 Recv-Q（即当前 accept 队列中待取连接数），长期 > 0 是明显信号。

配合 nginx -t 和 nginx -s reload 确保新配置生效，再观察指标变化。