Nginx 中异步事件驱动怎样实现低延时转发

Nginx 实现低延时转发依靠事件驱动+同步非阻塞I/O，核心是单worker单线程、epoll/kqueue事件循环、非阻塞I/O、状态机驱动和零拷贝；典型陷阱包括proxy_buffering on、upstream keepalive关闭、resolver未设valid等；流式响应需禁用缓冲并保持HTTP/1.1。

Nginx 实现低延时转发，靠的不是“异步 I/O”（如 io_uring），而是事件驱动 + 同步非阻塞 I/O 的组合——它用极轻量的方式调度大量连接，把延迟压到毫秒级甚至接近百微秒的理想路径。关键不在“异步”，而在“不等、不卡、不拷贝”。

低延时转发依赖的核心机制

• 单 worker 单线程 + epoll/kqueue 事件循环：每个 worker 绑定一个 CPU 核心，用 epoll 监听成千上万个 socket 状态变化；有数据可读/可写时立即处理，没有就挂起，不空转也不阻塞
• 所有 I/O 操作设为非阻塞：accept()、recv()、send() 遇到无数据或缓冲满，立刻返回 EAGAIN/EWOULDBLOCK，Nginx 记录状态后切走，去处理其他就绪请求
• 状态机驱动请求生命周期：一个 HTTP 请求从建立连接、收 header、转发 upstream、收响应、发回客户端，全程由状态机推进，每一步只做最小必要动作，完成后立刻让出控制权
• 零拷贝优化静态响应：启用 sendfile 时，内核直接在 page cache 和 socket buffer 间搬运数据，不经过 Nginx 用户态内存，省掉一次 CPU 拷贝和内存分配

影响低延时的典型配置陷阱

• proxy_buffering on（默认）：Nginx 会攒完整响应体再发给客户端，破坏流式体验，延迟可能从几十毫秒升至数秒
• upstream keepalive off 或连接池过小：每次请求都新建 TCP 连接，握手 + TLS 握手耗时叠加，轻松增加 50–200ms
• resolver 未设 valid：DNS 查询同步阻塞，尤其上游域名变更时，可能卡住整个请求链路
• ssl_session_cache 未共享或过期太短：TLS 会话无法复用，每次都要完整握手，延迟翻倍

流式响应场景下的低延时关键设置

要让 Nginx 边收边发 chunked 响应（比如 FastAPI 或 SSE 接口），必须显式解除缓冲约束：

• proxy_buffering off; —— 关键！禁用响应体缓存，否则等后端吐完才转发
• proxy_http_version 1.1; + proxy_set_header Connection ''; —— 保持 HTTP/1.1 并透传 connection 控制，避免被降级为 HTTP/1.0
• proxy_buffer_size 4k;（可选）—— 缩小 header 缓冲区，防止首行被意外滞留
• proxy_cache off; —— 关闭缓存，避免引入额外校验与序列化开销

注意：proxy_buffering off 后，Nginx 不再校验响应完整性，后端中途断连或返回错误状态码会直接透传，需由上游保证健壮性。

不复杂但容易忽略