sendfile与tcp_nopush必须成对启用且满足四个前提（sendfile on、含Content-Length、禁用用户态处理、命中静态路径）才能协同生效，构建内核零拷贝通路并合并TCP报文提升吞吐。
sendfile 与 tcp_nopush 配合使用，能在特定条件下显著提升大静态文件的网络吞吐效率，但这种提升不是“开就变快”的通用加速器——它只在零拷贝路径畅通时生效，且效果取决于数据规模、协议栈行为和配置协同程度。
核心机制：一条从磁盘到网卡的“直通链路”
sendfile 的作用是让内核直接把文件内容从磁盘页缓存复制到 socket 发送队列，绕过用户态内存拷贝；tcp_nopush 则在此基础上，让内核把 HTTP 响应头和文件开头数据合并进同一个 TCP 报文发出。两者配合的本质，是构建一条“内核态直达”通路，并减少小包数量。
- 单个 TCP 报文若未填满 MSS（通常 1448 字节），协议开销占比高；合并后载荷率上升，同等带宽下有效数据更多
- 小包越少，ACK 流量越低，接收端处理压力越小，尤其在高并发下载场景下更明显
- 该优化不提升物理带宽上限，但能压榨已有链路的利用率，实测吞吐可提升 15%–30%（针对 >1MB 的 MP4、ZIP、安装包等）
生效前提：缺一不可的四个条件
这两个指令不是独立开关，而是强依赖组合。任意一项不满足，tcp_nopush 就会被 Nginx 忽略（日志中明确提示 “tcp_nopush is ignored”）。
- sendfile 必须开启：仅在 root / alias 直接服务本地文件，或 proxy_buffering off + upstream 返回 Content-Length 的代理场景下才真正启用
- 响应必须含准确 Content-Length：Nginx 需预知大小才能走 sendfile 路径；chunked 编码或动态生成内容会自动退回到 read/write 模式
- 禁用所有用户态处理模块：gzip、sub_filter、ssi、access_by_lua_block 等都会强制数据进入用户态缓冲区，切断零拷贝链路
- 请求需命中静态资源路径：如 location ~ \.(mp4|zip|iso|webp)$，而非 proxy_pass、FastCGI 或 API 接口
配套参数必须对齐，否则优化失效
tcp_nopush 不是孤立配置，它需要底层行为配合才能“攒包成功”。常见错误是只开 tcp_nopush，却忽略协同参数。
- tcp_nodelay 必须设为 off：Nagle 算法默认关闭，但建议显式声明。若设为 on，它会抢在“攒满 MSS”前强行发包，直接抵消 tcp_nopush 效果
- output_buffers 建议调大：默认 2×32k 对大文件易触发过早冲刷，推荐设为 2 128k，给内核留足攒包空间
- sendfile_max_chunk 推荐 512k：限制单次内核复制量，防止阻塞事件循环，也适配多数高清视频/安装包的起始段大小
- 避免全局启用：对 API、WebSocket、小图标等低延迟敏感资源开启，反而增加首字节时间（TTFB），得不偿失
实际效果因场景而异
不是所有“大文件”都受益于该组合。吞吐提升最明显的，是那些单体较大（>500KB）、连接复用率高、且传输链路带宽充足（如 CDN 边缘节点、内网文件分发）的场景。
- HTTP/2 + keepalive 下，Nginx 默认已做合理缓冲，手动开启 tcp_nopush 收益有限
- HTTPS 场景中，TLS 加密层本身会引入一定缓冲行为，与 tcp_nopush 存在交互影响，需实测验证
- 对象存储回源（如 MinIO/OSS）时，必须确保 upstream 返回 200 + Content-Length，且 proxy_buffering off，否则仍走 chunked 分块路径
