必须同时启用sendfile on、tcp_nopush on和tcp_nodelay off，且满足真实本地文件、明确Content-Length、禁用gzip等用户态干预模块，才能真正触发零拷贝；否则退化为read()+write()四次拷贝路径。
在多媒体大文件（如 MP4、MOV、WEBM 视频，或 ISO、ZIP 安装包）下载场景下，Nginx 的 sendfile 不是“一开就快”，而是需要与内核网络栈、硬件能力、响应结构三者对齐才能真正释放零拷贝优势。核心目标不是提升理论带宽，而是降低 CPU 占用、减少小包中断、稳定高吞吐。
必须满足的三个生效前提
即使配置了 sendfile on，以下任一缺失都会导致自动退化为 read()+write() 四次拷贝路径：
-
请求必须命中真实本地文件：使用
root或alias直出磁盘文件；proxy_pass、FastCGI、Lua 脚本等动态路径不触发 sendfile -
响应头必须含明确
Content-Length：Nginx 需预知文件大小才能调用sendfile()系统调用；流式响应、chunked 编码、后端未返回长度均会失效 -
location 块内显式启用：不能仅靠 http 块继承，必须在服务视频/下载的具体 location 中写明
sendfile on;
配套 TCP 层必须同步开启
tcp_nopush 不是可选项，而是 sendfile 的“搭档开关”。它让内核等待发送缓冲区填满再发包，避免 sendfile 推出的大块数据被拆成几十个 1–2KB 小包：
-
tcp_nopush on;—— 必须开启，启用 TCP_CORK 行为 -
tcp_nodelay off;—— 显式关闭 Nagle 算法，避免与 tcp_nopush 冲突（注意不是on） - 禁用
gzip on、etag on、sub_filter等任何需用户态介入的模块，否则 sendfile 自动禁用
超大文件（≥4GB）需叠加异步 I/O 优化
纯 sendfile 依赖 page cache，当文件远超可用内存时，频繁换页会拖慢性能。实测显示：
- 单个 8GB 视频仅用
sendfile on：吞吐约 85 MB/s，CPU sys 占用 35% - 叠加
aio on; directio 4m;：吞吐升至 112 MB/s，CPU sys 降至 12% - 注意：
directio会禁用 sendfile，但 Nginx 实际降级为sendfile(SF_NODISKIO)+ 异步预读，仍是零拷贝增强路径
系统级参数需匹配网卡能力
sendfile 推送的数据最终要进网卡 TX ring 队列。若内核发送缓冲区太小，或 TX ring 深度不足，数据会卡在中间：
- 查看网卡 TX ring 大小：
ethtool -g eth0（常见为 256–512） - 调整内核参数：
net.ipv4.tcp_wmem = 4096 262144 4194304（中间值 ≥ TX ring × 16KB） - 同步设置：
net.core.wmem_default = 262144，net.core.wmem_max = 4194304 - 验证是否对齐：
ss -i查看连接的snd_wnd是否 ≥ 256KB
