tcp_nodelay与tcp_nopush是互补机制：前者禁用Nagle算法实现小包即时发送，提升响应及时性；后者配合sendfile合并大包发送，降低传输开销；二者共存可兼顾延迟与吞吐，Linux 2.5.9+内核支持协同生效。
tcp_nodelay 和 tcp_nopush 不是对立选项，而是互补机制——一个管“小包发得快”，一个管“大包发得省”，合理共存才能兼顾延迟与吞吐。
tcp_nodelay：专注响应及时性
它禁用 Nagle 算法，让应用层有数据就立即发出，不等待 ACK 或凑满 MSS。这对 HTTP 头、Keep-Alive 探针、WebSocket 帧、API 返回体等小而关键的数据特别重要。
- 默认就是 on，多数场景无需改动
- 只在 keepalive 连接开启时生效（依赖于 keepalive_timeout 配置）
- 适用于动态内容、反向代理、实时接口等低延迟敏感链路
- 配置位置在 listen 指令后，例如：listen 80 tcp_nodelay;
tcp_nopush：专注传输高效性
它启用 TCP_CORK 机制，配合 sendfile 使用，把文件内容和响应头“攒在一起”发送，减少小包数量和协议开销。但前提是必须开启 sendfile，否则该指令完全无效。
- 默认是 off，静态资源服务建议显式设为 on
- 典型组合是：sendfile on; tcp_nopush on;
- 只对内核零拷贝路径起作用，proxy_pass、FastCGI 等不走这条路，设了也无影响
- 适合图片、JS、CSS、视频片段等静态文件分发场景
二者如何协同工作
Linux 2.5.9+ 内核支持两者同时启用。Nginx 会按需调度：前几段大块文件由 tcp_nopush 合并发送；最后一个可能不满的包，由 tcp_nodelay 强制推送，避免卡住。
- 不是“要么攒包、要么立刻发”，而是“大段攒着发，末段不等直接发”
- HTTP/2 下内核调度更精细，这两个参数影响减弱，但仍建议保留标准配置
- 真实生效需验证：nginx -t 检语法，tcpdump 抓包看 PUSH 标志与小包间隔
常见误配与规避建议
容易踩坑的地方不在写法，而在上下文缺失：
- 写了 tcp_nopush on 但没开 sendfile → 配置静默失效
- 在 proxy_pass 的 location 里盲目加 tcp_nopush → 实际不参与传输路径
- 为降低延迟而关掉 tcp_nodelay，却未评估对首字节时间（TTFB）的影响
- 仅靠配置不验证，误以为优化已落地
