tcp_nopush需配合sendfile on生效，用于静态文件传输时合并响应头与数据以减少小包；必须设tcp_nodelay off避免冲突，禁用gzip，按location精细化启用，并通过抓包验证是否合并发送。
tcp_nopush 是 Nginx 中用于优化 TCP 数据传输的一个关键参数，它本身不直接“减少发送次数”，而是配合 TCP_NODELAY 和系统 TCP 栈，**延迟合并小包、提升单次发送的数据量**，从而降低网络小包数量和协议开销。它的效果主要体现在静态文件（如 CSS、JS、图片）的传输阶段。
tcp_nopush 的作用原理
该指令控制 Nginx 是否在发送响应时启用 TCP 的 push flag（即是否强制立即推送数据）。当开启时（默认 on），Nginx 会等待缓冲区填满或遇到文件末尾再一次性发出数据包；关闭后，数据可能被拆成多个小包快速发出。这本质上是利用了 TCP 的 Nagle 算法协同机制（但注意：tcp_nopush ≠ Nagle，它是服务端侧的 write() 调度优化）。
典型生效场景：Nginx 使用 sendfile() 零拷贝发送大文件时，内核可将 HTTP header 和文件内容合并进一个 TCP 包；若未启用 tcp_nopush，header 和部分文件内容可能被分开发送。
如何正确启用 tcp_nopush
该指令只能在 http、server、location 块中配置，且仅对启用 sendfile 的响应生效。需确保配套设置合理：
- 必须开启
sendfile on;—— 否则 tcp_nopush 不起作用 - 推荐同时开启
tcp_nodelay off;（默认值），避免与 tcp_nopush 冲突；若设为 on，则会禁用 Nagle 算法，可能导致小包增多，抵消 tcp_nopush 效果 - 典型配置示例：
location /static/ {
sendfile on;
tcp_nopush on; # 推荐保持默认（on）
tcp_nodelay off; # 确保不干扰合并行为
}什么时候不该用或需谨慎
tcp_nopush 对实时性要求高的场景可能带来轻微延迟（毫秒级），例如：
- 长连接流式响应（如 Server-Sent Events、某些 WebSocket 回退逻辑）
- 小而频繁的 API 响应（如 JSON 接口返回几十字节），此时更倾向 tcp_nodelay on + tcp_nopush off
- 启用了 gzip 或其他输出过滤模块时，sendfile 会被禁用 → tcp_nopush 自动失效
验证是否生效
无法通过 Nginx 日志直接查看，需借助网络抓包分析：
- 用
tcpdump抓取客户端请求静态资源的响应流量 - 对比开启/关闭 tcp_nopush 时的 TCP 包数量和大小：开启后，HTTP header 更大概率与首个文件数据块合并发送
- 观察 Wireshark 中 TCP Stream 中的 “TCP segment len” 分布是否更集中、小包更少
