Nginx中http块tcp_nopush配合sendfile的性能实战-Nginx-PHP中文网

tcp_nopush 与 sendfile 协同优化静态文件传输：前者在 sendfile 启用时攒包发送以减少小包，后者通过零拷贝降低 CPU 和内存开销；二者必须同时开启才生效，否则 tcp_nopush 被忽略。

nginx中http块tcp_nopush配合sendfile的性能实战

在 Nginx 中，tcp_nopush 和 sendfile 是两个常被一起启用、协同优化静态文件传输性能的关键指令。它们的作用不是孤立的，而是通过减少系统调用和网络包数量，让内核更高效地把文件内容推送到客户端。

tcp_nopush 的作用与触发条件

tcp_nopush（仅适用于 FreeBSD 和 Linux）控制是否启用 TCP 的 TCP_NOPUSH（FreeBSD）或 TCP_CORK（Linux）选项。开启后，Nginx 会尽量把多个小响应头或响应体“攒”成一个完整的 TCP 包再发出，避免小包泛滥（即 Nagle 算法的补充机制）。

但它只在满足以下条件时才真正生效：

必须配合 sendfile on 使用（否则无意义）
响应体由内核直接从文件描述符发送（即走零拷贝路径）
响应头已写入，且后续要发的数据能填满或接近 MSS（最大分段大小）

简单说：tcp_nopush on 不是“强制延迟发送”，而是“等一等，凑够了再发”，前提是底层走的是 sendfile。

sendfile 如何改变数据流路径

sendfile 开启后，Nginx 不再把文件内容从内核页缓存读到用户空间缓冲区，再 write 到 socket；而是直接由内核完成“文件 → socket”的搬运，省去两次内存拷贝和一次用户态上下文切换。

典型效果：

CPU 使用率下降（尤其大文件、高并发场景）
内存带宽压力减小（避免用户空间 buffer 占用）
为 tcp_nopush 提供了“可攒包”的前提（因为数据不经过用户态，内核能统一调度）

注意：若启用了 gzip on 或任何需要用户态处理的过滤模块（如 sub_filter），sendfile 会自动失效，tcp_nopush 也退化为无效配置。

推荐配置与典型陷阱

标准高性能静态服务配置应类似：

http {
    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     off;  # 与 tcp_nopush 协同：禁用 Nagle 对小交互的影响，但大文件传输中通常保持 off
    keepalive_timeout  65;
}

常见误配情况：

sendfile on 但 tcp_nopush off：失去包合并机会，小文件可能产生大量 40–60 字节的 TCP 包
tcp_nopush on 但 sendfile off：该指令被忽略（Nginx 日志中会出现 warning：“tcp_nopush is ignored”）
在启用了 etag、expires 等头部操作的同时，未确认是否触发了 sendfile 禁用（实际不影响，这些只是 header 操作）
反向代理场景下错误开启 sendfile：后端响应非本地文件，sendfile 不生效，此时 tcp_nopush 也无效

如何验证是否生效

可通过以下方式交叉验证：

用 strace -e trace=sendfile,write,sendto 跑 Nginx worker，观察是否调用 sendfile() 系统调用
用 ss -i 查看连接的 TCP 队列状态，高负载下若 cwnd 稳定上升且重传率低，说明包合并有效
抓包分析（如 Wireshark）：对同一静态资源多次请求，观察 TCP payload size 是否趋近于 MSS（如 1448 字节），而非零散小包
Nginx error log 中没有 “tcp_nopush is ignored” 类警告

真实压测中，在千兆内网环境，开启组合后，1MB 文件的平均响应时间可降低 8%～12%，QPS 提升约 15%（取决于磁盘 I/O 和 CPU 负载均衡程度）。