tcp_nopush的作用是减少小包数量、提升单次TCP报文载荷效率，必须与sendfile on配合且tcp_nodelay off时才生效；它依赖内核零拷贝路径，对proxy_pass、chunked响应等非sendfile流量无效。
Linux 下 Nginx 使用 sendfile 时，tcp_nopush 的作用不是“加速发送”，而是**减少小包数量、提升单次 TCP 报文载荷效率**——它必须与 sendfile 配合生效，且仅在启用 tcp_nodelay off（即默认行为）时才起作用。
tcp_nopush 是什么，为什么需要它
tcp_nopush 是 Nginx 的一个 socket 选项开关（对应内核的 TCP_NOPUSH），开启后会延迟 TCP 报文发送，直到满足以下任一条件：
- 内核 TCP 发送缓冲区被填满（达到 MSS 倍数）
- 当前请求的全部文件数据已通过
sendfile()提交到内核协议栈 - 连接关闭或发生超时
它的设计初衷是避免 sendfile 场景下出现大量“未填满 MSS”的小 TCP 包（例如只带几个字节 HTTP 头 + 一小段文件数据），尤其在传输大静态文件（JS/CSS/图片）时效果明显。注意：该选项对非 sendfile 流量（如 proxy_pass、chunked 响应）无效。
如何正确启用并验证 tcp_nopush
Nginx 默认已开启 tcp_nopush on（自 0.8.12 起），但需确保相关上下文配置合理：
- 确保
sendfile on;已启用（通常放在http或server块） - 不要手动设置
tcp_nodelay on;—— 否则会强制禁用 Nagle 算法，使tcp_nopush失效 - 若使用
output_buffers或directio，需确认它们不干扰 sendfile 路径
验证是否生效：用 ss -i 查看连接状态，观察 ts（timestamp）和 nop 标志；或用 Wireshark 抓包对比开启/关闭前后 TCP segment size 分布，典型优化后平均包长会上升 20%–50%。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
常见误用与性能反模式
以下配置看似“更激进”，实则破坏 tcp_nopush 效果：
-
tcp_nodelay on;：直接绕过 Nagle 算法，tcp_nopush彻底失效 -
sendfile off;或aio on;+directio混用：触发用户态读写路径，无法走内核零拷贝，tcp_nopush不参与 - 在
location ~ \.php$等动态接口中盲目继承tcp_nopush：无意义，因响应由 FastCGI 生成，不走 sendfile
真实收益场景非常明确：高并发、大体积静态资源（≥64KB）、RTT 较低的局域网或 CDN 回源链路。
调优建议与补充配合项
单靠 tcp_nopush 收益有限，建议组合优化：
- 设置合适的
sendfile_max_chunk 512k;（Nginx 1.7.11+），防止单次sendfile锁住 worker 进程过久 - 启用
reset_timedout_connection on;，及时释放卡在半包状态的连接 - 内核层面调大
net.ipv4.tcp_wmem第三项（最大发送窗口），匹配千兆以上带宽 - 对 HTTPS 站点，确保
ssl_buffer_size 4k;或更高，避免 TLS 记录层切分破坏 TCP 包整合
实际压测中，开启 tcp_nopush 后，相同 QPS 下服务器发送的 TCP segment 数量可下降 30%–40%，对网卡中断、软中断（softirq）压力有可观缓解。
