Nginx采用事件驱动的同步非阻塞I/O模型，而非异步I/O；它基于epoll/kqueue等机制实现高并发连接管理，通过Keepalive、超时控制、缓冲优化等方式应对高延迟网络，并需结合TLS调优、边缘部署等协同优化。
Nginx 并不使用异步 I/O（如 Linux 的 io_uring 或 Windows 的 IOCP）来处理网络请求，而是基于**事件驱动的同步非阻塞 I/O 模型**——具体来说，是利用 epoll（Linux）、kqueue（FreeBSD/macOS）等高效事件通知机制，配合单线程（或少量工作进程）循环处理就绪的连接和数据。
为什么不是“异步 I/O”？
严格意义上的异步 I/O（AIO）指：应用发起 I/O 请求后立即返回，内核在后台完成读写，并通过信号、回调或事件通知应用——整个过程无需应用主动轮询或等待。而 Nginx：
- 调用
read()/write()时仍属同步操作（只是因 socket 设为非阻塞，不会卡住）； - 依赖
epoll_wait()等系统调用等待“哪些 fd 就绪”，属于**同步事件通知**，不是内核代为完成 I/O； - 没有使用
io_submit()+io_getevents()这类真正异步接口（Linux AIO 对普通文件支持尚可，对 socket 基本不适用）。
它如何应对高延迟网络链路？
高延迟（如跨洲际、卫星链路、弱网移动环境）主要带来两个问题：连接建立慢、数据往返时间（RTT）长、易出现突发丢包和重传。Nginx 通过以下方式缓解影响：
- 连接复用（Keepalive）：复用 TCP 连接，避免反复三次握手和慢启动，显著减少延迟敏感操作次数；
- 高效事件分发：一个 worker 进程可同时管理数万空闲连接（如长轮询、WebSocket），连接挂起时不占 CPU，只在有数据/超时/关闭事件时响应；
-
合理的超时控制：精细配置
client_header_timeout、client_body_timeout、keepalive_timeout，防止慢客户端长期占用资源； -
缓冲与合并写入：启用
tcp_nodelay off（默认）可合并小包，减少 PSH 包数量；结合sendfile和tcp_nopush优化内核发送行为。
实际部署建议
面对高延迟链路，光靠 Nginx 模型不够，需结合网络与协议层协同优化：
- 前端接入 TLS 时启用
ssl_buffer_size 4k或更大值，降低小记录帧开销； - 对移动端或弱网用户，考虑开启
gzip_vary on并配合缓存策略，减少传输体积； - 避免在 Nginx 中做耗时逻辑（如复杂 Lua 脚本、同步 upstream 调用），否则会阻塞事件循环；
- 必要时在边缘部署（如 CDN 或区域 POP 点）前置 Nginx，缩短用户到第一跳的距离。
简言之，Nginx 的优势不在“异步 I/O”，而在用极轻量的同步非阻塞+事件驱动模型，把每个连接的等待成本降到最低——这比追求底层 AIO 更务实、更稳定、也更适合 HTTP 场景。
