非阻塞I/O通过事件驱动+状态机+epoll/kqueue实现高效连接管理：每个连接由ngx_connection_t维护状态，内核就绪队列O(1)通知事件，红黑树管理超时，内存池复用结构体与buffer。
非阻塞 I/O 本身不直接“处理”连接状态变动，而是让 Nginx 能在单个 worker 进程中高效响应这些变动——不卡、不等、不丢，靠的是非阻塞调用 + 事件驱动 + 状态机三者咬合运转。
每个连接都处于可感知的状态机中
Nginx 不为连接分配线程或栈，而是用 ngx_connection_t 结构体维护其当前阶段：比如 NGX_HTTP_READING_REQUEST（正在收请求头）、NGX_HTTP_PROCESS_REQUEST（解析中）、NGX_HTTP_SENDING_RESPONSE（发响应中）。TCP 建立、数据到达、写缓冲腾出、超时触发……都对应明确的状态迁移，由回调函数驱动，不依赖阻塞等待。
- 客户端慢发请求头？每次
recv()返回EAGAIN后，连接仍保留在 epoll 监听列表，状态不变，只等下次就绪 - 后端响应未返回？当前连接挂起，worker 立刻转向其他就绪 fd，不空耗 CPU
- TCP 断连或 RST 到达？内核通知 EPOLLHUP/EPOLLRDHUP，Nginx 立即清理资源并关闭连接
epoll/kqueue 批量捕获真实就绪事件
Linux 下默认用 epoll，FreeBSD/macOS 用 kqueue。它们不是轮询，而是内核维护一个就绪队列：当 socket 状态真正变化（如收到 SYN、数据入接收缓冲区、发送缓冲区有空位），内核立刻把该 fd 加入就绪列表。Nginx 调用 epoll_wait() 一次就能拿到所有活跃事件，O(1) 时间复杂度，不随连接数增长而变慢。
- 10 万个连接里只有 300 个此刻有数据可读？Nginx 只遍历这 300 个，其余 99700 个安静待命，不占 CPU、不触发调度
- 新连接快速建立又断开？
multi_accept on允许一次accept()尽可能多地收下已排队的连接，减少事件唤醒次数 - 连接异常中断（如客户端断网）？内核通过
EPOLLRDHUP通知，Nginx 可及时回收，避免 fd 泄漏
超时与资源约束防止状态堆积
非阻塞不会让连接自动消失，慢连接或异常连接若不加约束，会持续占用 fd 和内存。Nginx 用红黑树统一管理各类超时，并主动干预：
-
client_header_timeout 5s：请求头 5 秒没收全，直接断连，防 Slowloris -
send_timeout 30s：向客户端发响应时，两次send()间隔超 30 秒，断开连接 -
keepalive_timeout 65s：空闲长连接最多保留 65 秒，到期自动 close -
reset_timedout_connection on：对超时连接发 RST，加速内核状态释放，不等 FIN 四次挥手
连接池与内存复用支撑高频状态切换
海量连接频繁建连/断连，若每次都 malloc/free，性能会急剧下降。Nginx 在启动时预分配连接池和 slab 内存池：
- 每个连接结构体从固定池中分配，生命周期结束后归还复用，无堆分配开销
- 读写 buffer（如
client_header_buffer_size）也来自共享内存池，避免反复申请释放 - 超时节点插入/删除使用红黑树，O(log n) 效率，比轮询检查快得多
