sendfile能显著提升物理效率，因其仅需2次DMA拷贝、0次CPU拷贝和2次上下文切换，避免用户空间搬运，依赖真实磁盘文件、socket目标、支持page cache的文件系统及内核≥2.4。
直接用 `sendfile()` 能显著提升文件传输的物理效率，核心在于减少数据在内存中的搬运路径和 CPU 干预次数，让数据从磁盘页缓存“直送”网卡 DMA 缓冲区，不经过用户空间——这不是调优技巧，而是绕过低效环节的系统级设计。
sendfile 为什么能提升物理效率
物理效率提升的关键不是“更快的时钟”，而是更少的数据移动和更低的硬件资源争用：
- 传统 read+write：需 4 次数据拷贝（2 次 DMA + 2 次 CPU）+ 4 次上下文切换，CPU 频繁参与字节搬运，总线与缓存带宽被冗余占用
- sendfile（内核 ≥ 2.4）：仅 2 次 DMA 拷贝（磁盘 → 页缓存 → 网卡），0 次 CPU 拷贝，上下文切换压至 2 次；DMA gather copy 可进一步合并分散页，减少内存寻址开销
- 实测表现：在千兆网卡、SSD 存储、1KB–64KB 小文件场景下，单位请求 CPU 时间下降 35%–48%，softirq 压力明显缓解，网络吞吐更稳定
必须满足的物理层前提条件
零拷贝不是开关，它依赖底层硬件与内核协同。不满足以下任一条件，`sendfile()` 会静默退化为普通拷贝或直接失败：
- 源文件描述符（
in_fd）必须指向真实磁盘文件（S_ISREG(st.st_mode)为真），不支持 pipe、socket、/proc 或 NFS/FUSE 挂载点（部分旧 NFS 客户端不透传 sendfile 语义） - 目标描述符（
out_fd）必须是已连接的 socket（TCP/UDP 均可，但 UDP 单包不能超IP_MAXPACKET，否则截断） - 文件系统需支持 page cache 与 mmap 语义（ext4/xfs/btrfs 均满足；某些 overlayfs 或加密文件系统可能受限）
- 内核版本 ≥ 2.4（推荐 ≥ 4.12，以启用
copy_file_range回退与更健壮的 offset 处理）
小文件场景下的真实提效策略
海量小文件（如静态资源、切片、图标）才是 sendfile 最具性价比的战场——但需规避常见反模式：
- 避免对
- 启用
TCP_CORK：连续发送多个小文件时，防止 Nagle 算法拆出大量 40–60 字节小包，降低网络层处理压力与丢包率 - 偏移量传指针（
&offset）：多线程共享同一in_fd时，可避免lseek竞态导致错位读取；单线程也可传nullptr省去更新开销 - 不加
O_DIRECT：小文件随机访问频繁，绕过页缓存反而破坏预读与缓存局部性，实测吞吐下降 20%+
验证是否真走零拷贝路径
别信文档，用工具看内核实际行为：
- 运行
strace -e trace=sendfile,read,write,writev -p [pid]：若只看到sendfile调用且返回值接近文件大小，说明生效；若夹杂大量read+write，说明已退化 - 监控
/proc/[pid]/stat中的min_flt（次缺页）与maj_flt（主缺页）：零拷贝下maj_flt显著升高（磁盘加载页），但min_flt不异常飙升（无用户缓冲区映射） - 用
perf record -e syscalls:sys_enter_sendfile,syscalls:sys_exit_sendfile统计调用频次与延迟分布
