tcp_nopush与tcp_nodelay不是互斥开关，而是协同策略：前者需sendfile on配合，优化大文件合并发送；后者默认开启，保障小包低延迟即时发出；混合场景须按location路径精细化配置。
这两个参数不决定“快或慢”的绝对值，而是分别优化两类不同数据的发送节奏：一个管“怎么攒包发大文件”，一个管“怎么立刻发小响应”。配错组合反而会拖慢关键路径。
tcp_nopush：只对大文件有效，且必须配合 sendfile
它本质是启用 Linux 的 TCP_CORK 机制，目标是把 HTTP 响应头、ETag、Last-Modified 和文件主体尽可能塞进同一个 TCP 包发出，减少包数量和 ACK 往返。但前提是：
- 必须开启 sendfile on —— 否则 tcp_nopush on 形同虚设；
- 响应体必须来自磁盘文件（如 /static/logo.png、/js/app.js）—— proxy_pass、FastCGI、PHP-FPM 等动态路径完全不走这条内核零拷贝路径；
- HTTPS 下效果明显衰减：TLS 记录层强制分段 + 加密开销，让内核很难有效“攒包”。
典型收益场景：CDN 节点分发图片、JS、CSS、字体等静态资源，吞吐提升可达 20–30%，CPU 拷贝开销下降。
tcp_nodelay：长连接下的低延迟守门员，几乎默认就生效
它禁用 Nagle 算法，确保每个 write() 产生的数据（哪怕只有几个字节）立刻发出，不等待前序包 ACK 或凑满 MSS。这对首字节敏感的场景是刚性要求：
- HTTP/1.1 持久连接、WebSocket、SSE、API 返回 JSON、登录鉴权响应都依赖它；
- Nginx 1.15+ 默认就是 tcp_nodelay on，多数情况无需显式写；
- 但必须在 listen 指令中声明（如 listen 443 ssl http2 tcp_nodelay;），否则可能被 location 继承覆盖或未实际作用于套接字。
实测显示：开启后小包 P99 延迟可降低 50%+，QPS 提升 15–30%（以典型 JSON 接口为基准）。
二者不是互斥，而是按路径协同
它们解决不同问题，可以共存，且内核有优先级协调（tcp_nodelay 优先级更高）：
- 大文件传输时：tcp_nopush 主导合并发送，tcp_nodelay 在最后未填满的尾巴包上兜底，避免卡顿；
- 小包交互时：tcp_nopush 不生效（不走 sendfile），tcp_nodelay 全程起效；
- 混合站点（如 /static/ + /api/）必须按 location 拆分配置，不能全局统一开关。
错误做法是把 tcp_nopush on 放在 http 块顶层，结果 API 请求也继承了无效配置，还可能隐式干扰小包调度。
怎么验证是否真生效？
别只看配置文件：
- 用 ss -i | grep port=80 查看连接是否带 np（nopush）标记；
- 用 tcpdump 抓包，Wireshark 中观察小包间隔是否稳定在毫秒级、是否有大量单字节 [PSH] 包堆积；
- 用 curl -w "%{time_starttransfer}\n" 测首字节延迟，对比开关前后的波动变化。
不复杂但容易忽略。
