tcp_nodelay对短连接API延迟几乎无优化效果，仅在keepalive长连接下改善小包合并延迟；应按需在location或upstream中启用，而非全局http块。
tcp_nodelay 在 Nginx 的 http 块中启用，**对 API 短连接延迟几乎没有优化效果**，反而可能在特定场景下引入微小开销。它真正起作用的是长连接（keepalive）下的小包合并问题。
为什么 tcp_nodelay 对短连接无效
Nginx 默认使用 TCP 的 Nagle 算法（延迟确认 + 小包合并），但该算法只在连接持续存在、有多个小数据块待发时才生效。而短连接（如典型 HTTP/1.1 无 keepalive 的 API 请求）通常：
- 一次请求+一次响应后立即关闭连接
- 响应体往往足够大（如 JSON 数据 > 1KB），直接触发 TCP 发送，不等待合并
- 内核在 close() 前会强制推送未发送数据，Nagle 不会阻塞最终响应
tcp_nodelay 真正适用的场景
它主要改善的是启用 keepalive 的长连接中连续多个小响应（例如 Server-Sent Events、WebSocket 子协议、或高频小 JSON 片段流）的延迟。此时：
- tcp_nodelay 关闭 Nagle，让每个 write() 调用立即发包，不等待 ACK 或更多数据
- 配合
keepalive_timeout和客户端复用连接，才能体现价值 - 在
http块设置会影响所有 server/location，但更推荐在具体 upstream 或 location 中按需开启
API 延迟更值得优化的方向
相比盲目开启 tcp_nodelay，以下配置对短连接 API 延迟影响更显著：
- 启用 keepalive 客户端连接复用：减少三次握手和 TLS 握手开销（尤其 HTTPS）
- 调小 send_timeout / client_header_timeout：避免慢客户端拖慢 worker 进程
- 使用 reuseport（Linux 3.9+）：提升多 worker 接收新连接的并发能力
- 关闭 access_log 或异步写日志：降低磁盘 I/O 对响应延迟的影响
如果仍要配置，正确写法是
tcp_nodelay 是 tcp_nopush 的互补项，常成对出现，适用于 location 或 upstream 块（非全局 http 块）：
location /api/stream {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# 长连接场景下启用
tcp_nodelay on;
tcp_nopush off; # 关闭零拷贝，换低延迟
} 
