sendfile 是热更资源下发的关键配置，需与 tcp_nopush on、tcp_nodelay off 组合启用，并禁用 gzip、etag、add_header 等退化项，配合 sendfile_max_chunk 2m 和 open_file_cache 才能真正实现零拷贝、降延迟、控 CPU。
sendfile 是游戏客户端热更资源下发场景中提升吞吐、降低延迟和 CPU 压力的关键配置，但不能只写 sendfile on; 就完事。热更资源（如 .pak、.zip、.bin、version.json 等）通常体积大、并发高、对首字节延迟和传输稳定性敏感，稍有配置冲突就会退化为传统读写路径，导致服务器负载飙升、下载卡顿甚至超时失败。
以下配置要点聚焦真实可用性，兼顾性能、兼容性与可观测性：
必须统一启用的核心组合（写在 http{} 块顶层）
-
sendfile on;
启用内核级零拷贝，是所有优化的前提 -
tcp_nopush on;
让 Nginx 等待 sendfile 数据填满 TCP 包再发，避免大量小包（尤其对 1–50MB 的热更包效果显著） -
tcp_nodelay off;
注意：不是on。tcp_nopush和tcp_nodelay互斥；开启nopush时必须关闭nodelay，否则失效
必须规避的热更常见退化陷阱
- ❌
gzip on;或gunzip on;
热更资源本身已是压缩格式（如 LZ4.pak），运行时再 gzip 会强制进用户态，彻底绕过 sendfile - ❌
etag on;或expires动态计算头（如add_header ETag ...）
Nginx 需 stat 文件并生成哈希，触发用户态介入；热更建议用固定ETag "static"或直接禁用 - ❌
add_header Last-Modified "";或add_before_body类指令
任何响应体改写或头部动态注入都会破坏零拷贝路径 - ❌ 资源放在 NFS / CIFS / overlayfs（Docker 容器卷）上
这些文件系统不支持sendfile()系统调用，Nginx 会静默回退到read()+write()
推荐增强稳定性的配套设置
-
sendfile_max_chunk 2m;
防止单次 sendfile 占用事件循环过久；2MB 适配主流热更包分片粒度，避免阻塞其他请求 -
open_file_cache max=10000 inactive=30s;
缓存.pak、.json等高频访问文件的 inode 和 size，减少open()/stat()系统调用 -
aio threads;+directio 4m;（仅限大文件直出，非代理）
对 >64MB 的安装包，可搭配aio异步 I/O，但需确认内核支持且不与 sendfile 冲突；一般热更包不建议启用 -
client_max_body_size 0;（若含上传校验）
热更常附带版本校验上传，避免因 body 大小限制中断流程
如何验证热更下发真走零拷贝
-
strace -p $(pgrep nginx | head -1) -e trace=sendfile64,read,write -f 2>&1 | grep -E "(sendfile64|read|write)"
在模拟热更下载时运行，应持续看到sendfile64(...)调用，几乎无read(输出 -
watch -n 1 'grep -i "ctxt" /proc/stat'
对比开启前后上下文切换数（cswch/nvcswch），下降 30%+ 是有效信号 - 使用
curl -v http://your-cdn/version.json -o /dev/null 2>&1 | grep "time_appconnect\|time_starttransfer"
观察time_starttransfer（首字节延迟），优化后应稳定在 1–3ms（本地 SSD）或
热更服务本质是「静态资源的高可靠分发」，sendfile 不是锦上添花，而是承载能力的底盘。配错一个 gzip on，就可能让 1000 并发压垮一台 8 核机器。
