Nginx采用事件驱动的同步非阻塞I/O模型，而非异步I/O；它基于epoll/kqueue等事件通知机制，通过非阻塞socket主动调用read/write，不使用aio_read/aio_write等真正异步接口。
Nginx 并不使用异步 I/O（如 Linux 的 io_uring 或 Windows 的 IOCP）来处理网络请求，它采用的是**事件驱动的同步非阻塞 I/O 模型**，核心依赖 epoll（Linux）、kqueue（FreeBSD/macOS）等高效事件通知机制。
为什么不是“异步 I/O”？
严格来说，“异步 I/O”在 POSIX 标准中指 aio_read/aio_write 等真正内核回调或完成通知的接口，其特点是：用户发起 I/O 后可立即返回，内核在数据就绪并完成读写后才通知应用。Nginx **从未基于这类 API 实现网络收发**——它的 socket 始终设置为 O_NONBLOCK，通过事件循环监听可读/可写状态，再主动调用 read() 或 write()。这属于“同步但非阻塞”，而非“异步”。
如何应对高延迟网络链路？
面对高延迟（如跨洲际、弱网、TCP 重传多）场景，Nginx 主要通过以下机制缓解影响：
-
连接复用（Keepalive）：复用 TCP 连接避免反复握手与慢启动，降低 RTT 放大效应；可通过
keepalive_timeout和keepalive_requests控制生命周期。 -
请求/响应缓冲与流式处理：用
client_body_buffer_size、proxy_buffering等控制内存缓冲行为，避免因下游延迟导致上游连接长时间挂起；支持proxy_buffering off启用流式透传，减少中间等待。 -
超时精细化控制：分别设置
client_header_timeout、client_body_timeout、send_timeout、proxy_read_timeout等，防止单个慢连接长期占用 worker 进程。 -
Worker 隔离与负载分散：每个 worker 独立事件循环，高延迟连接只阻塞当前 worker 的事件处理（实际是让出 CPU，继续处理其他就绪事件），不影响其他连接；配合
worker_connections合理调优，提升并发容忍度。
常见误解澄清
有人将 Nginx 的“高并发低资源占用”归因于“异步 I/O”，这是术语混淆。它的高效源于：
– 单线程事件循环避免上下文切换开销
– 非阻塞 socket + 内核事件通知（epoll/kqueue）实现海量连接的高效就绪判断
– 零拷贝优化（如 sendfile）、内存池管理、无锁共享结构等工程细节
这些与 POSIX AIO 或现代 io_uring 的异步语义无关。目前（截至 Nginx 1.25），官方仍未将异步 I/O 作为网络栈基础。
若需真正异步文件 I/O（如静态文件发送），Nginx 可选配 aio on（仅 Linux，且依赖 directio），但这仅用于磁盘读取加速，不涉及网络收发路径。
