Nginx 高效请求转发依赖事件驱动模型而非多线程，每个 worker 进程通过 epoll/kqueue 监听万级 socket，内核通知就绪事件后快速处理；HTTP 请求被拆分为 accept、read、connect 等独立事件异步调度；结合 sendfile、内存池、keepalive 及 TCP 优化降低开销；合理配置 worker_processes、worker_connections 等参数激活异步能力。
Nginx 实现高效请求转发，靠的不是“多线程堆资源”，而是把每个 worker 进程变成一个精干的事件调度员——它不等连接、不等响应、不空转，只在数据就绪时出手。
单 worker 轮询万级连接，靠的是 epoll/kqueue
Linux 下默认启用 epoll，FreeBSD/macOS 用 kqueue，它们让一个 worker 进程能同时监听成千上万个 socket 的状态变化。比如客户端发来请求头、后端返回响应数据、TCP 连接断开……这些都不是主动轮询出来的，而是内核通知“哪个 socket 准备好了”。worker 收到列表后逐个处理，整个过程在用户态内存中快速完成，没有阻塞，也没有频繁的上下文切换。
请求各阶段拆成独立事件，不卡住整个流程
一次 HTTP 请求转发被切分成多个可调度单元：
- TCP 握手完成 → 触发 accept 事件
- 请求头到达 → 触发 read 事件，解析 Host、Path、Method
- 决定转发目标后 → 异步发起 upstream 连接（非阻塞 connect）
- 上游响应开始返回 → 注册 read 事件接收 chunk，同时注册 write 事件向客户端发送
- 任一环节未就绪（比如后端还没回包），worker 立刻转向处理其他就绪连接
减少搬运和等待，让数据“少走路、快出门”
高效转发不只是调度快，还要降低系统开销：
- 静态文件用 sendfile()：数据从磁盘直接送进 socket 缓冲区，绕过用户空间拷贝
- 动态响应用 内存池（slab allocator）管理 buffer，避免 malloc/free 频繁触发和碎片
- 开启 keepalive 复用到后端的 TCP 连接，省去重复握手与慢启动
- 配合 TCP_NOPUSH（合并小包）和 TCP_NODELAY（禁用 Nagle，优先低延迟）按场景调节
配置得当，异步能力才能真正落地
再好的模型也得靠配置激活：
- worker_processes auto;：自动匹配 CPU 核心数，避免进程过多争抢或过少闲置
- worker_connections 10240;：单 worker 并发上限，需同步调高系统 ulimit -n
- use epoll;：显式指定高性能 I/O 模型（Linux 必选）
- multi_accept on;：一次 accept 多个新连接，应对突发流量更稳
- proxy_buffering off;（流式场景）：禁用响应缓存，实现边收边发
本质上，Nginx 把“并发”转化成“事件调度 + 内存操作 + 内核能力复用”，不拼数量，拼的是每个环节的响应精度和资源利用率。
