worker_connections 是 Nginx 单 worker 能同时管理的连接总数上限，决定事件驱动模型的调度容量；它不实现零拷贝或非阻塞 I/O，但为二者提供连接状态承载基础，超限连接将被静默丢弃。
worker_connections 本身不直接参与零拷贝或非阻塞 I/O 的实现，但它定义了事件驱动模型的“调度容量”，是连接管理与底层 I/O 机制协同工作的关键接口。
worker_connections 是非阻塞 I/O 的承载边界
非阻塞 I/O（如 epoll + O_NONBLOCK）让单个 worker 进程能轮询并响应大量 socket 事件，但每个活跃连接仍需一个 ngx_connection_t 结构体来维护状态（读写缓冲区、事件标志、超时定时器等）。
worker_connections 就是这个结构体池的最大数量——它不是“并发请求数”的粗略估算，而是该 worker 能同时跟踪的**就绪/等待/传输中连接总数**的硬上限。
超过此值的新连接会被内核拒绝（SYN 包丢弃或返回 RST），即便系统文件描述符（ulimit -n）还富余，Nginx 也不会分配连接槽位。
- 例如：设
worker_connections 10240，一个 worker 正在处理 8000 个 HTTP 请求、1500 个长连接 WebSocket、700 个慢速上传，则剩余 40 个空位；第 10241 个新 TCP 握手将被静默丢弃 - 若 client_header_timeout 设为 60s，而客户端迟迟不发请求头，该连接会持续占用一个 connection 槽位达一分钟，直到超时回收
零拷贝依赖连接状态，但不受 worker_connections 数值约束
零拷贝（如 sendfile）发生在数据从磁盘到网卡的路径上，由内核 DMA 控制器完成，全程不经过用户空间。它是否启用，取决于配置（sendfile on）、文件类型（仅静态文件）、以及当前连接所处的处理阶段（如 content phase 中的 static module）。
worker_connections 不影响 sendfile 是否触发，但它决定了有多少连接能**同时进入可发送状态**——比如 10000 个连接都在请求同一个大图片，Nginx 会为每个连接调用一次 sendfile()，但内核实际执行是并行且无锁的。只要这些连接都处于“可写”事件就绪态，epoll 就会把它们批量通知给 worker，事件循环逐个 dispatch，不阻塞。
- 注意：若使用 open_file_cache，频繁访问的小文件可能缓存在内存，此时走的是内存 copy 路径，不触发 sendfile；但这也正说明零拷贝只在合适场景自动生效，无需 worker_connections 配合干预
- 真正受 worker_connections 影响的是“有多少连接能排队等待 sendfile 执行完成”——因为每个连接必须保持在连接池中，直到 TCP 窗口允许下一段数据发出
三者真正的协作链条：从连接接入到数据发出
当一个请求抵达时，整个流程体现三者分工：
-
接入层：accept() 成功后，Nginx 立即将 socket 设置为 O_NONBLOCK，并从 connection pool 分配一个
ngx_connection_t实例——这步受 worker_connections 限制 - 事件层：该连接被注册进 epoll，等待 EPOLLIN；数据到达时，epoll_wait 返回，Nginx 在非阻塞模式下调用 recv()；若返回 EAGAIN，立即转去处理下一个就绪事件
- 输出层：若响应为静态文件且满足条件，Nginx 调用 sendfile()；此时连接仍保留在 pool 中，直到 sendfile 完成并收到 TCP ACK 后，才释放 connection 槽位
整个过程没有线程创建、没有阻塞等待、没有用户态数据拷贝——worker_connections 是这张高效流水线的“工位数”，非阻塞 I/O 是“不停机的机械臂”，零拷贝则是“直连仓库与货车的传送带”。
