non-blocking io 不提升单次读写速度，而是通过避免线程阻塞、事件驱动调度、按需缓冲及参数协同，使 nginx 单 worker 处理数万连接，实现毫秒级响应与十毫秒级端到端延迟。
Non-blocking IO 本身不加快单次读或写的速度，但它让 Nginx 能在单位时间内处理更多连接、更快响应新请求、更及时调度就绪任务——响应处理速度的提升，本质是系统级吞吐与调度效率的优化结果。
避免线程阻塞，释放 CPU 调度资源
传统阻塞模式下，每个连接需独占一个线程（或进程），一旦等待数据（如 recv 等待客户端发包），线程就挂起，CPU 切换上下文、分配栈空间、维护状态，开销大且不可扩展。Nginx 全链路启用 non-blocking socket：
- 调用
recv()时若无数据，立即返回EAGAIN/EWOULDBLOCK，不等待 - 调用
send()时若内核发送缓冲区满，也立刻返回错误，而非卡住 - 所有 I/O 操作都交由 epoll/kqueue 统一监听，仅在 fd 就绪时才触发回调
这样，一个 worker 进程就能同时管理数万连接，CPU 时间几乎全用于实际业务处理，而不是空等或切换。
事件驱动调度，毫秒级响应就绪事件
Nginx 的事件循环（如 epoll_wait）持续监控所有 socket 状态。当客户端发来数据、TCP ACK 到达、或响应可写时，内核立刻通知事件循环，对应模块的回调函数（如 ngx_http_process_request_line）被即时调用：
- 新连接接入后，几毫秒内完成 accept + 设置 non-blocking + 注册读事件
- HTTP 头解析、请求体接收、响应生成等阶段均以“事件就绪→回调执行→再注册下一事件”方式推进
- 即使某个慢客户端上传极慢，也不会拖累其他连接的读写调度
缓冲区按需使用，减少内存与拷贝延迟
Non-blocking 模式配合精细的缓冲策略，让数据流动更高效：
- 读缓冲采用“试探性读取”：先用小 buffer 收 header，未收全再扩容，超限则转临时文件，避免内存暴涨
- 写响应时，若启用
sendfile on，静态文件直接由内核在磁盘和 socket 间传输，绕过用户态拷贝 - 若需构造动态响应，数据先进入内存 buffer；当 socket 可写或 buffer 满时才调用
send()，失败即挂起写事件，下次再试
整个过程无阻塞等待，无冗余内存分配，无跨事件锁持有，每一步都为快速流转设计。
连接复用与参数协同，放大非阻塞收益
Non-blocking 是基础，但真正体现响应速度提升的，是它与其它机制的配合：
-
keepalive_timeout和keepalive_requests让 TCP 连接复用，省去三次握手与慢启动，首字节延迟显著下降 -
worker_processes auto+worker_cpu_affinity把事件循环绑定到固定核心，减少 cache miss 和迁移开销 -
tcp_nodelay on关闭 Nagle 算法，小包（如 HTTP 响应头）无需等待合并，发出更及时
这些配置不是孤立生效，而是在 non-blocking 架构上叠加调度、网络、内存三层优化，共同把端到端响应压缩到十毫秒级。
