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 不再校验响应完整性，后端中途断连或返回错误状态码会直接透传，需由上游保证健壮性。
不复杂但容易忽略
