Nginx的非阻塞I/O通过事件驱动机制实现高并发：将每个连接各阶段注册为独立事件，由epoll/kqueue统一通知，状态机按需推进；连接全程事件化管理，轻量上下文降低内存占用；两级keepalive连接池提升复用效率；TLS握手、mTLS验证、OCSP检查均嵌入事件流；代理转发中结合多级缓冲与零拷贝，全链路保持可调度。
Nginx 的非阻塞 I/O 不是“省掉等待”，而是把等待变成可调度的事件。它不靠开线程抢资源，而是让一个工作进程同时盯住成千上万个连接——每个连接在读、写、握手、超时等各阶段都注册为独立事件，由 epoll（Linux）或 kqueue（BSD/macOS）统一通知，Nginx 再按需推进状态机。这种机制天然适配反向代理场景，尤其在长连接复用、TLS 握手、后端交互等环节体现得尤为清晰。
连接生命周期全程事件化管理
客户端与 Nginx 建立 TCP 连接后，并不会为该连接独占一个线程或进程。Nginx 将其文件描述符（fd）注册进事件循环，后续所有操作——接收 HTTP 请求头、解析 Host、匹配 location、发起 upstream 连接、等待后端响应、组装响应体、发送回客户端——全部拆解为一系列可中断、可恢复的状态跃迁。只要某一步涉及 I/O（比如读取请求体、等待后端 ACK），就主动让出控制权，转去处理其他就绪事件。
- 例如：一个 HTTPS 请求到达，Nginx 在 TLS 握手阶段收到 ClientHello 后，若尚未收到完整数据，就暂停该连接处理，立即响应另一个已就绪的连接请求
- 又如：proxy_pass 转发时，Nginx 向 upstream 发起连接，若对方未立即响应 SYN-ACK，它不会卡住，而是继续轮询其他 fd，待内核通知“连接建立成功”后再触发后续 SSL 握手流程
- 每个连接在内存中只保留轻量级上下文（如 request structure、connection structure），不含栈帧或线程私有存储，极大降低内存占用
上游连接池与空闲连接复用
Nginx 默认启用 keepalive 机制复用到后端的连接，但不是简单地“保持打开”，而是通过两级复用策略实现高效调度：
- 第一层：单个工作进程内维护 per-upstream 的空闲连接池（由 keepalive 指令配置，如
keepalive 32），这些连接处于 ESTABLISHED 状态但无活跃请求，可被新请求快速拾取 - 第二层：当新请求需要 upstream 连接时，优先从池中取可用连接；若池为空，则新建连接；请求结束后，若后端支持 HTTP/1.1 keepalive 且响应头含
Connection: keep-alive，该连接会被放回池中而非直接关闭 - 连接空闲超时由 keepalive_timeout 控制（默认 60s），超时后由事件循环主动 close，不依赖 TCP TIME_WAIT 或被动探测
TLS 握手与 mTLS 验证嵌入事件流
SSL/TLS 握手看似“同步”，但在 Nginx 中被完全事件驱动化：
- ClientHello 到 ServerHello 的往返、证书交换、密钥协商等步骤，均由 OpenSSL 回调触发，并映射为事件循环中的状态变更
- 启用双向认证（mTLS）时，
ssl_client_certificate和ssl_verify_client on配置会让 Nginx 在 handshake 阶段插入证书请求和校验逻辑，整个过程仍不阻塞其他连接 - OCSP stapling 或 CRL 检查若启用，会异步发起 DNS 查询和 HTTP 请求，结果缓存后更新证书状态，避免每次握手都同步拉取
- 私钥解密（如 RSA 密钥交换）在用户态完成，不触发系统调用，因此不干扰 I/O 多路复用主循环
代理转发中的零拷贝与缓冲协同
非阻塞不只是“不等”，更在于数据流动的精细控制：
- Nginx 使用多级缓冲区（如
proxy_buffering on时的 proxy_buffers + proxy_buffer_size），接收客户端请求体时边收边判，不等全部收完才转发 - 向后端转发时，若后端响应较快，Nginx 可能一边收响应、一边发给客户端，利用 sendfile 或 splice 实现内核态零拷贝（尤其静态文件）
- 当客户端或后端任一端出现慢速（如弱网下载、高延迟后端），Nginx 自动启用临时文件缓冲（
proxy_buffer溢出至磁盘），避免工作进程被拖住 - 所有缓冲行为均受事件驱动：buffer 满则暂停读，socket 可写则触发写，写完再注册可读事件——整条链路始终处于“可调度”状态
