nginx event loop 通过非阻塞 i/o、epoll 事件驱动及内核 tcp 参数协同优化，实现低延迟高吞吐；需合理配置缓冲区、连接队列、time_wait 复用与 fastopen，并规避 worker_connections、multi_accept 和 rewrite 等配置陷阱。
Nginx 的 Event Loop 本身不直接优化 TCP 传输，而是通过协同内核参数、非阻塞 I/O 模型和高效事件分发，为 TCP 连接提供低延迟、高吞吐的运行基础。真正的优化发生在 Event Loop 与 TCP 栈的交互层，而非协议栈内部。
利用非阻塞 socket 与事件驱动减少等待
Event Loop 基于 epoll（Linux）监听 socket 状态，所有连接使用非阻塞模式：
- 调用 recv() 时只读取当前内核缓冲区中已到达的数据，不阻塞等待完整报文；
- 调用 send() 若返回 EAGAIN/EWOULDBLOCK，说明发送缓冲区满，Event Loop 会暂存待发数据，并自动注册 EPOLLOUT 事件，等 socket 可写时再触发回调；
- 避免了传统阻塞模型中单连接卡住整个线程的问题，尤其适合突发小包或慢启动连接。
配合内核 TCP 参数提升传输效率
Event Loop 的响应速度高度依赖 TCP 栈行为，需同步调优关键内核参数：
- net.ipv4.tcp_rmem / tcp_wmem：设为 4096 65536 1048576，让内核根据带宽延时积动态扩缩缓冲区，避免小窗口限制吞吐；
- net.core.somaxconn 和 Nginx 的 listen backlog= 需一致设高（如 65535），防止全连接队列溢出导致 SYN-ACK 被丢；
- net.ipv4.tcp_tw_reuse = 1：在反向代理场景下复用 TIME_WAIT 状态 socket，缓解短连接端口耗尽问题；
- 启用 tcp_fastopen（需客户端支持），跳过首 RTT 的三次握手数据等待，加速首字节传输。
适配不同传输阶段的调度行为
Event Loop 对 TCP 连接各阶段“一视同仁”，但实际表现受网络状态影响：
- 慢启动初期：远端发包节奏慢 → 内核 rcvbuf 数据少 → read 事件触发稀疏 → 看似“响应慢”，实为数据未就绪，Event Loop 并未降权处理；
- 高吞吐稳定期：数据持续到达 → EPOLLIN 高频触发 → Event Loop 快速分发至 handler，配合 sendfile 或 AIO 实现零拷贝或异步落盘；
- 长连接空闲期：仅保持 keepalive 探测 → 无数据事件 → 不消耗 CPU，资源占用极低。
规避常见配置陷阱
错误配置会抵消 Event Loop 优势，需注意：
- worker_connections 设得过高，但 ulimit -n 或 fs.file-max 未同步提升，导致 accept 失败或日志报 “too many open files”；
- 未开启 multi_accept on，单次 epoll_wait 后只 accept 一个连接，加剧高并发下 accept 队列堆积；
- HTTP 重定向大量使用 rewrite redirect，触发正则匹配和多次 location 查找，增加每个请求的 CPU 开销，拖慢事件循环整体周转率；建议优先用 return 301/302。
