Nginx Event Loop 是由操作系统事件通知、非阻塞 I/O 和轻量连接管理构成的高效协作体系，单 worker 可承载万级连接，依赖 epoll 批量就绪通知、2–4 KB/连接内存占用、三层非阻塞设计、红黑树超时管理及内核参数协同优化。
Nginx 的 Event Loop 不是“单线程扛高并发”的噱头，而是由操作系统事件通知机制、非阻塞 I/O 和轻量连接管理共同支撑的高效协作体系。它不靠并行，而靠快速响应与状态流转，在资源有限的前提下把每个连接的开销压到最低。
单 worker 进程承载万级连接的核心逻辑
每个 worker 进程运行一个持续循环（for(;;) { epoll_wait(); 处理就绪事件; }），不创建线程，也不为连接分配独立栈。所有客户端 socket 被抽象为文件描述符（fd），统一注册进内核事件表（如 Linux 的 epoll）。一次 epoll_wait() 就能批量获知哪些连接有数据可读、可写或已断开，避免轮询浪费 CPU。
- 空闲连接几乎不触发事件，CPU 不做无谓等待
- 每个连接仅占用约 2–4 KB 内存（含缓冲区和连接结构体 ngx_connection_t）
- HTTP/1.1 keepalive 让连接长期存在但大部分时间处于“静默监听”状态
三重非阻塞设计让 I/O 不卡主线程
Event Loop 的高效依赖于网络、磁盘和逻辑三层均不阻塞：
- 网络 I/O 非阻塞：socket 设为 non-blocking，recv/send 立即返回 EAGAIN/EWOULDBLOCK，立刻转向其他就绪事件
- 磁盘 I/O 尽量规避：静态文件用 sendfile() 零拷贝直送内核 socket 缓冲区；需处理的内容才启用异步读（AIO）
- 逻辑处理轻量无锁：HTTP 解析、路由匹配、header 修改全部在内存中完成，无 GC、无复杂对象生命周期管理
超时与连接生命周期由红黑树精准控制
Event Loop 并非只管“来了就处理”，还通过一棵按时间排序的红黑树（ngx_event_timer_rbtree）管理所有连接级定时器：
- 每个活跃连接最多挂一个超时节点（如 read timeout、keepalive timeout）
- 插入/查找/删除均为 O(log n)，支持数万连接的超时管理
- 典型防护场景：client_header_timeout 断 Slowloris，send_timeout 防响应中断挂起
配置与内核协同才能释放全部潜力
Event Loop 的能力上限，取决于 Nginx 配置与操作系统底层参数是否匹配：
- worker_connections 要 ≤ 当前进程 ulimit -n 值，否则新连接被拒绝
- fs.epoll.max_user_watches 应 ≥ 总连接数 × 1.2，防止 epoll_ctl() 失败
- net.core.somaxconn 需 ≥ listen 指令的 backlog 值，避免 accept 队列溢出
- 启用 listen ... deferred 可跳过 SYN 泛洪干扰，让内核只在首包完整时通知
