Nginx开启sendfile后，核心是通过内核零拷贝（磁盘→内核缓冲区→socket）替代传统四次搬运，省去用户态拷贝与上下文切换，降低CPU和内存开销；需同时满足location显式启用、真实磁盘文件、含Content-Length三前提，并配合tcp_nopush on、gzip off等配置方可生效。
开启 sendfile 后，Nginx 对大文件下载的优化核心在于绕过用户态、减少拷贝与上下文切换，让数据在内核空间直接从磁盘送入网络协议栈——这不提升带宽，但显著缩短首段响应时间、降低 CPU 负载、提高单连接吞吐效率。
零拷贝机制大幅降低开销
传统读写模式下，一个文件要经四次数据搬运：磁盘 → 内核缓冲区 → 用户态内存 → socket 发送缓冲区 → 网卡。启用 sendfile 后，仅需两次：磁盘 → 内核缓冲区 → socket 缓冲区（由 DMA 直接完成），省去一次内存拷贝和一次用户态/内核态上下文切换。
- CPU 占用下降明显，尤其在并发下载量高时，worker 进程不再频繁陷入 read()/write() 系统调用
- 内存带宽压力减小，避免为每个请求分配用户态缓冲区（如 64KB）
- 对 10MB 以上文件，系统调用次数可减少 50% 以上
必须满足的三个运行时前提
配置写了 sendfile on 并不等于生效。Nginx 在每次响应时动态判断是否走零拷贝路径，缺一不可：
- 当前 location 显式启用 sendfile on（不能只靠 http 块继承）
- 请求命中真实磁盘文件（root/alias 指向本地路径，且后缀匹配，如 .mp4、.zip；proxy_pass 或 FastCGI 不触发）
- 响应头中含明确的 Content-Length（Nginx 需预知大小才能调用 sendfile()；若后端流式返回或用 chunked 编码，则自动退回到 read/write 模式）
tcp_nopush 必须协同启用才起作用
tcp_nopush 不是独立优化项，它依赖 sendfile 提供的“整块连续数据”才能合并 TCP 报文。单独开启无效，且易被其他参数干扰：
- gzip off：压缩必须在用户态做，开启 gzip 会强制禁用 sendfile
- tcp_nodelay off：Linux 下 tcp_nopush 实际启用 TCP_CORK，而 tcp_nodelay 强制立即发包，二者冲突
- 代理场景需加 proxy_buffering off，并确保 upstream 返回 Content-Length
按文件类型精细化启用更安全高效
全局开启容易误伤 API、WebSocket、HLS 的 m3u8 等低延迟交互场景。推荐只在明确的大静态资源 location 中启用：
- 匹配常见后缀：
location ~ \.(mp4|webm|avi|zip|iso|tar\.gz|dmg)$ - 内部显式声明：
sendfile on; tcp_nopush on; tcp_nodelay off; gzip off; - 可叠加缓存策略：
expires 7d; add_header Cache-Control "public, immutable";
验证是否真正生效的关键方法
不能只看配置是否存在，需结合运行时行为确认：
- 用
strace -e trace=sendfile -p $(pgrep nginx)观察 worker 是否调用 sendfile 系统调用 - 用 Wireshark 抓包：开启后，HTTP 状态行、响应头与文件前几 KB 数据应出现在同一个 TCP 包中
- 对比未开启时的 packet count：大文件下载初期小包数量应明显减少（尤其在高延迟链路上）
