Nginx Worker Process 不直接合并数据包，而是通过 sendfile on 与 tcp_nopush on 配合内核 TCP_CORK 机制实现响应头与文件起始数据同包发送；需禁用 gzip、proxy_pass 等干扰项，并在特定 location 中精细化配置，同时满足 output_buffers 和系统资源要求。
Nginx 的 Worker Process 本身**不直接实现数据包合并处理**。它不负责 TCP 层的数据包拼接或“攒包”，这个动作发生在内核协议栈，Worker 进程只是通过特定配置**触发并配合**内核完成这一行为。
核心机制：Worker 进程靠配置协同内核完成合并
所谓“数据包合并”，实际是指让 HTTP 响应头和文件开头部分尽可能塞进同一个 TCP 报文段发出（即减少小包、提升吞吐）。这依赖两个关键条件在 Worker 进程处理静态文件时同时满足：
- 启用 sendfile on：使 Nginx 跳过用户态拷贝，走内核零拷贝路径，把响应头 + 文件起始数据视作连续字节流
- 启用 tcp_nopush on：在 sendfile 生效前提下，才可触发内核的 TCP_CORK（Linux）机制，延迟发送直到缓冲区满或显式刷新
Worker 进程在处理一个匹配 location 的静态文件请求时，若上述配置存在且生效，就会调用内核 sendfile() 系统调用，并携带 TCP_CORK 标志——此时合并逻辑完全交由内核执行，Worker 不参与具体分包或组装。
Worker 进程必须关闭干扰项才能让合并生效
以下配置若开启，会直接导致 sendfile 失效，tcp_nopush 彻底被忽略，Worker 就只能走常规 read/write 流程，无法触发合并：
- gzip on：压缩必须在用户态做，强制绕过 sendfile
- proxy_pass / fastcgi_pass / lua 处理：动态内容不走静态文件路径，不触发该优化链路
- tcp_nodelay on：与 tcp_nopush 互斥，开启后立即发包，抵消“攒包”效果
- 缺失 Content-Length 或使用 chunked 编码：Nginx 无法预知长度，sendfile 调用失败，回退到普通模式
Worker 进程需按场景精细化启用，不能全局开
tcp_nopush 的收益集中在大体积静态资源（如视频、安装包、高清图），对小文件或文本类资源效果有限甚至增加延迟。因此 Worker 进程的配置应限定在具体 location 块中：
- 视频：location ~ \.(mp4|webm|avi)$ { sendfile on; tcp_nopush on; tcp_nodelay off; gzip off; }
- 安装包：location ~ \.(zip|iso|tar\.gz)$ { sendfile on; tcp_nopush on; tcp_nodelay off; gzip off; }
- 避免在 root 或 server 级别全局启用，否则可能影响 HTML/JS/CSS 等小资源的首屏延迟
Worker 进程还依赖底层资源支持
即使配置正确，Worker 要稳定触发合并，还需系统级配合：
- output_buffers 至少设为 2 128k：默认 2×32k 对大文件不够，缓冲区太小会导致提前 flush，无法攒够数据
- 系统文件描述符限制足够：worker_connections × worker_processes 需 ≤ ulimit -n，否则连接建立失败，根本走不到 sendfile 阶段
- 内核 TCP 参数未被强行覆盖：如 net.ipv4.tcp_slow_start_after_idle=0 可避免空闲后重置拥塞窗口，间接利于大块传输
