Apache启用sendfile可跳过用户空间，让内核直接将磁盘文件页送入socket发送队列，避免传统read/write路径中的两次上下文切换和两次CPU拷贝；但仅当无模块修改响应、文件在本地文件系统、客户端支持长连接等条件满足时才真正生效。
Apache 启用 sendfile 可跳过用户空间，让内核直接把磁盘文件页送入 socket 发送队列，避免传统 read/write 路径中的两次上下文切换和两次 CPU 拷贝。但它的生效高度依赖运行时条件，不是配了就一定用得上。
sendfile 为什么能减少切换损耗
传统静态文件响应流程是：read() → 用户缓冲区 → write() → socket 缓冲区。这触发两次系统调用，每次调用都伴随用户态→内核态→用户态的切换，加上两次 CPU 数据拷贝（内核页缓存→用户空间、用户空间→socket 内核缓冲区），开销明显。
启用 sendfile 后，Apache 直接调用内核 sendfile64() 系统调用，数据在内核内部从文件页缓存“搬运”到 TCP 发送队列，全程不经过用户空间。一次系统调用、零次 CPU 拷贝、仅两次上下文切换（发起和返回），显著降低 CPU 占用和延迟。
确保 sendfile 实际生效的关键条件
Apache 很谨慎，只要检测到以下任一情形，就会自动退回到 read/write 模式：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 响应被任何模块修改：比如 mod_deflate 开启压缩、mod_headers 修改了 Last-Modified 或 ETag、mod_php 或 mod_proxy 参与了内容生成
- 文件不在本地文件系统：NFS、CIFS、FUSE 类挂载点通常不支持 sendfile 接口，内核返回 ESPIPE 错误
- 客户端使用 HTTP/1.0 且未声明 Connection: keep-alive，连接无法复用 page cache，Apache 主动禁用
- 启用了 EnableMMAP off（尤其在 event MPM 下），影响底层文件映射能力
- 文件大小超过 SendfileMaxSize 限制（默认无上限，但旧版 Apache 可能设为 2GB）
验证 sendfile 是否真正在工作
不能只看配置里有没有 EnableSendfile on（它默认通常是开启的）。必须观测运行时行为：
- 用 strace -p $(pgrep apache2 | head -1) -e trace=sendfile64 抓一个纯静态资源（如 .jpg、.css）请求，看到 sendfile64() 被调用，才算成功
- 如果只看到大量 read() 和 write()，说明已被降级 —— 此时要检查是否有模块介入、文件路径是否跨文件系统、或响应头是否被篡改
- 也可临时关闭可疑模块（如 mod_deflate、mod_headers），再测试对比 strace 输出
配置与常见误区
mod_sendfile 不是独立模块，它是 Apache core 的一部分，2.0+ 版本均内置，无需 LoadModule。只需确认主配置中有：
EnableSendfile on注意：某些容器镜像或精简发行版（如 Alpine 上的 httpd）可能默认关掉它，需显式开启。另外，sendfile 与 mmap 是两种不同零拷贝路径，Apache 在满足条件时优先选 sendfile；若 sendfile 失败（如文件不可 mmap），才可能 fallback 到 mmap + write 组合，但该路径仍比纯 read/write 好。
