sendfile指令本质是调用内核sendfile()系统调用，实现磁盘到网卡的内核直传，绕过用户态：传统read/write需4次拷贝和切换，启用后减至2次且全程在内核完成；必须配套tcp_nopush on、tcp_nodelay off，并满足静态文件、Content-Length存在、禁用gzip等条件才生效。
sendfile 指令不是简单地“打开一个开关”，而是让 Nginx 主动调用 Linux 内核的 sendfile() 系统调用，把静态文件从磁盘直接送入网络协议栈——全程不经过用户空间，这是性能跃升的关键。
sendfile 怎么绕过用户态？
传统 read/write 流程必须把数据搬进 Nginx 进程的内存里：磁盘 → 内核缓冲区 → 用户态缓冲区 → socket 缓冲区 → 网卡。这涉及 4 次数据拷贝和 4 次上下文切换，CPU 大量耗在搬运上。
启用 sendfile 后，路径缩短为：磁盘 → 内核缓冲区 → socket 缓冲区 → 网卡。数据始终留在内核空间，Nginx 进程只发一次系统调用，不持有数据内容。内核通过 do_splice_direct 或 DMA 引擎完成内部搬运，省掉两次 CPU 拷贝和两次上下文切换。
注意：“零拷贝”指的是零用户态拷贝，不是物理上完全不复制。是否触发 SG-DMA（跳过 socket 缓冲区）、是否复用 page cache，取决于文件大小、缓存状态、文件系统类型和内核版本。
为什么 sendfile 会悄悄失效？
只要响应过程需要用户态介入，内核就无法直通，Nginx 会自动回落到 read/write 模式。常见退化场景包括：
- 开启
gzip on：压缩必须在用户态完成，破坏零拷贝链路 - 使用
proxy_pass或fastcgi_pass：后端返回的是 socket 数据流，不是本地文件句柄 - 配置
sub_filter、add_before_body等内容改写指令：需读取、修改、重写响应体 - 客户端发起 Range 请求：Nginx 要切片、计算偏移、构造新响应头
- 文件位于 NFS/CIFS 等远程文件系统：部分实现不支持 sendfile 的底层接口
配套指令如何协同生效？
sendfile 单独开启没有实际意义，必须与 TCP 层机制配合才能发挥最大效能：
-
tcp_nopush on：依赖 sendfile 路径，让内核把响应头和文件数据合并进同一个 TCP 报文段，避免小包泛滥 -
tcp_nodelay off：若设为 on，会强制立即发包，直接抵消 tcp_nopush 的聚合效果 -
open_file_cache on：缓存文件句柄和元数据，减少高并发下 open/stat 等系统调用引发的用户态开销 -
gzip_static on+gzip off：用预压缩的 .gz 文件替代运行时压缩，仍走 sendfile 路径
怎么确认它真正在工作？
不能只看配置，要验证运行时行为：
- 用
strace -p $(pgrep nginx) -e trace=sendfile观察 worker 进程是否持续触发sendfile系统调用 - 对比开启前后 CPU 使用率（特别是 sys%）和静态文件 QPS/延迟变化
- 检查 access log 中大文件请求是否仍被记录为 200，同时无 gzip 相关 header 出现
