Nginx通过非阻塞I/O（如epoll/kqueue）实现高并发低延时，其核心是让单worker进程同时监控数万连接，read/write立即返回并依赖事件通知处理就绪I/O，避免线程挂起；需配合worker_connections、sendfile、keepalive等配置才能发挥实效，但无法解决后端慢或CPU密集型瓶颈。
Non-blocking IO 是 Nginx 实现高并发低延时的核心机制之一，它不直接降低单次请求的处理时间，但能显著减少因等待 I/O 而产生的空闲阻塞，从而提升单位时间内可服务的请求数，间接压低整体响应延时——尤其在高并发、慢客户端或大量静态资源场景下效果明显。
Non-blocking IO 如何减少线程/进程挂起
传统 blocking IO 中，一个连接读取数据时，工作进程会全程阻塞，直到数据到达并拷贝完成。Nginx 默认启用 non-blocking socket，并配合 epoll（Linux）或 kqueue（BSD）等事件驱动机制，让单个工作进程可同时监控成千上万个连接的状态变化。
- socket 设置为 O_NONBLOCK 后，read/write 系统调用立即返回，即使没有数据可读或暂时无法写入
- 内核通过事件通知（如 EPOLLIN/EPOLLOUT）告知哪些 fd 已就绪，Nginx 仅对就绪连接做实际 I/O 操作
- 避免了“一个连接卡住，整条线程停摆”的问题，CPU 时间被更均匀地分配给活跃连接
对响应延时的实际影响路径
延时（latency）不是单纯由 CPU 计算决定，更多受 I/O 等待拖累。Non-blocking IO 主要从三个层面缓解延时压力：
- 连接建立阶段：accept() 非阻塞 + 多路复用，使新连接能快速被接入，避免 accept 队列积压导致 SYN timeout 或重传
- 请求读取阶段：慢客户端（如移动网络上传大文件）不会长期占用 worker 进程；Nginx 可暂停读取、转而处理其他请求，等数据就绪再继续
- 响应发送阶段：当 TCP 发送缓冲区满时，非阻塞 write 返回 EAGAIN，Nginx 将连接加入写就绪监听队列，而非死等，保障其他响应及时发出
需配合的关键配置才能发挥效果
Non-blocking IO 本身是底层 socket 行为，但它的延时收益依赖 Nginx 的事件模型与资源调度策略：
- 确保使用
epoll（Linux）或kqueue（macOS/BSD）作为 events 模块，避免 select/poll 的性能瓶颈 - 合理设置
worker_connections（如 4096–16384），匹配系统 ulimit -n，否则连接数受限会引发排队延时 - 启用
sendfile on和tcp_nopush on，减少用户态/内核态拷贝次数和小包发送开销，放大 non-blocking 的吞吐优势 - 对长连接（keepalive）启用
keepalive_timeout和keepalive_requests，避免频繁建连带来的 handshake 延时叠加
注意边界：它不能解决所有延时问题
Non-blocking IO 优化的是 I/O 等待环节，但以下情况它无能为力：
- 后端应用处理缓慢（如 PHP-FPM 响应慢），Nginx 只是更快地把请求转过去，延时瓶颈仍在 upstream
- 磁盘 I/O 密集型操作（如未开启 sendfile 的大文件读取），non-blocking 对 read() 的阻塞缓解有限，需结合 aio 或缓存优化
- SSL 握手耗时高（尤其 TLS 1.2 且无 session resumption），此时 CPU 加解密成为瓶颈，non-blocking 不减少计算时间
不复杂但容易忽略：non-blocking IO 的价值不在单请求变快，而在让有限 worker 更“忙得过来”，从而把 P95/P99 延时稳在可控范围内。
