sendfile 专优静态文件零拷贝传输，tcp_nodelay 专保动态交互小包实时性；二者各司其职、互不冲突：sendfile 绕过用户态实现内核直送，仅对真实静态资源生效；tcp_nodelay 禁用 Nagle 算法确保 write 立即发包，仅在 keepalive 连接下作用于 API/WebSocket 等动态流量。
sendfile 和 tcp_nodelay 解决的是完全不同的问题，不是“二选一”，而是“各司其职”——前者优化静态文件传输路径，后者保障动态交互流量的低延迟响应。
sendfile：专为零拷贝大文件传输设计
它绕过用户态，让内核直接把磁盘文件数据送入 socket 缓冲区，省掉两次 CPU 拷贝和两次上下文切换。适用于 JS、CSS、图片、视频等静态资源，效果显著；但对 proxy_pass 转发的 API 响应完全不生效，因为那些内容需经 Nginx 读取、处理（如加 header、gzip）、再写入 socket，无法走零拷贝路径。
- 必须配合静态文件服务使用（如 root 或 alias 指向本地路径）
- 开启后，tcp_nopush 才能起作用，用于合并响应头与文件体成整包发送
- 与 tcp_nodelay 并不冲突：sendfile 场景下，Nginx 会自动忽略 tcp_nodelay 设置（因控制权交由内核），所以无需关掉 sendfile 来迁就 nodelay
tcp_nodelay：专为小包实时性而设
它禁用 Nagle 算法，确保每个 write() 调用的数据（哪怕只有几个字节）立即封装发出，避免 20–200ms 的攒包等待。这对 WebSocket、长连接 API、实时通知等场景至关重要——用户发一条消息，后端回一个 ACK 或状态更新，延迟必须可控。
- 仅在 keepalive 连接上生效，需配 keepalive_timeout（如 65s）
- 只对 HTTP/1.1 长连接或 upgrade 后的协议（如 ws://）起作用
- 在 location 块中按需启用更安全，例如：
location /api/v1/realtime { tcp_nodelay on; proxy_pass http://backend; proxy_http_version 1.1; }
实时交互 API 中怎么配才合理
API 流量不走 sendfile，所以不用考虑它是否干扰 nodelay；重点是让 TCP 层尽快发出去。
- 全局或 server 块中保持 keepalive_timeout 65; 和 keepalive_requests 1000;
- 在对应 API 的 location 块里显式写 tcp_nodelay on;
- 确保 proxy_http_version 1.1 和 Connection 头清理（proxy_set_header Connection "";），防止中间设备切断长连接
- 不必关闭 sendfile —— 它只影响静态资源，与 API 流量天然隔离
常见误区澄清
有人说“tcp_nodelay 和 tcp_nopush 互斥”，这是误解。它们作用阶段不同：nopush 是 sendfile 路径下的“打包策略”，nodelay 是所有 write 路径下的“发包时机控制”。二者可共存，只是生效条件不同——nopush 需要 sendfile，nodelay 需要 keepalive。
- 对 favicon.ico 这类极小响应，tcp_nodelay on 可降延迟 100–200ms，效果肉眼可见
- 对 >1MB 视频流，可关 tcp_nodelay（即设为 off），专注吞吐而非单包延迟
- 后端应用若本身有写缓冲或同步阻塞逻辑，光开 tcp_nodelay 无法解决端到端延迟
