tcp_nopush在FreeBSD和Linux下作用一致，但需与sendfile on、Content-Length、gzip off等条件协同才生效；它合并响应头与首块数据，减少RTT，提升大文件首屏速度。
tcp_nopush 在 FreeBSD 和 Linux 下作用一致，但生效前提和协同机制有关键差异。它不是独立起效的 TCP 参数，而是深度依赖 sendfile 的内核路径，必须与 I/O 模式、协议版本、响应头完整性配合才能发挥减少小包、提升首屏速度的效果。
tcp_nopush 的本质与触发条件
tcp_nopush 并非直接控制 TCP 包大小，而是让 Nginx 将 HTTP 响应头与响应体的**首个数据块**合并进同一个 TCP 报文发出。这避免了客户端收到状态行后还要等待第二个 RTT 才拿到实际内容，对大文件下载尤其明显。
但它只在以下全部满足时才真正生效：
- sendfile on 已启用（核心前提）
- 响应来自磁盘静态文件（如 mp4、zip）或 proxy_store 落盘路径
- 后端响应中包含明确的 Content-Length 头（Nginx 需预知长度才能规划零拷贝边界）
- gzip off（压缩必须走用户态，会强制绕过 sendfile 路径）
FreeBSD 与 Linux 的行为一致性
虽然 tcp_nopush 最早源于 FreeBSD，但现代 Linux（2.4+ 内核）已完整支持该 socket 选项，且语义完全相同。两者均要求：
- 底层 TCP 栈支持 TCP_NOPUSH（或 TCP_CORK 的等效行为）
- Nginx 编译时链接了系统原生 libc（默认满足）
- 未同时启用 tcp_nodelay on（否则会立即发送，抵消攒包效果）
无需为不同系统写两套配置。只要用标准 nginx.conf 写法，就能在两个平台获得一致行为：
tcp_nopush on;
tcp_nodelay off; # 显式关闭更稳妥，因 off 是默认值
与内核 TCP 参数的间接协同
tcp_nopush 不直接修改内核 net.ipv4.tcp_* 参数，但它会受以下内核设置影响：
- net.ipv4.tcp_slow_start_after_idle = 0：防止空闲连接重启慢启动，保障长连接下 tcp_nopush 攒包稳定性
- net.ipv4.tcp_sack = 1：启用选择性确认，提升丢包恢复效率，间接让 tcp_nopush 发出的大包更可靠
- net.core.wmem_default / wmem_max：足够大的发送缓冲区，确保单次 sendfile + tcp_nopush 能容纳 HTTP 头 + 数 KB 文件头
这些属于通用 TCP 调优项，建议在高吞吐场景统一配置，不区分 FreeBSD/Linux。
按场景精细化启用，而非全局打开
tcp_nopush 对小响应（如 HTML、JSON）收益极低，反而可能增加延迟。应严格限定在已知大静态资源路径：
location ~ \.(mp4|avi|iso|zip|tar\.gz|dmg)$ {sendfile on;
tcp_nopush on;
gzip off;
# 可选：限制单连接带宽防打爆
limit_rate 8m;
}
若用于代理后端大文件（如对象存储直传），需额外确保：
– proxy_buffering off
– proxy_cache off
– 后端返回 Content-Length
– 使用 HTTP/1.1（proxy_http_version 1.1）
