sendfile 与 epoll 协同优化 Nginx I/O：sendfile 实现零拷贝减少上下文切换和内存拷贝，epoll 驱动其在 socket 可写时异步执行，二者结合显著降低 CPU 占用、提升吞吐、稳定延迟。
sendfile 与多路复用模型（尤其是 epoll）在 Nginx 中不是孤立工作的，而是协同优化 I/O 路径的关键组合：前者减少数据拷贝，后者高效调度就绪事件，共同支撑高并发静态文件服务。
sendfile 避免内核-用户空间切换
传统文件传输需经历：磁盘 → 内核缓冲区 → 用户空间 → 内核 socket 缓冲区 → 网卡。这个过程涉及四次上下文切换和两次内存拷贝，开销大。
sendfile 启用后，路径简化为：磁盘 → 内核缓冲区 → socket 缓冲区 → 网卡。全程在内核空间完成，零拷贝（zero-copy），不经过用户态，显著降低 CPU 和内存带宽消耗。
- 需在 nginx.conf 中显式开启：
sendfile on; - 建议搭配：
tcp_nopush on;（合并小包，适配 sendfile 的整块发送） - 对大文件（如图片、视频、JS/CSS）效果最明显；小文件收益有限，甚至可能因系统调用开销略增延迟
epoll 高效驱动 sendfile 执行时机
sendfile 本身是同步系统调用，但它不阻塞整个进程——这依赖于 epoll 的事件通知机制：
- Nginx 将每个客户端 socket 注册到 epoll 实例中，监听可写（EPOLLOUT）或可读（EPOLLIN）事件
- 当 socket 发送缓冲区有空闲空间（即“可写”就绪），epoll 立即通知 Nginx，此时才真正触发 sendfile 系统调用
- 避免了传统阻塞模式下“调用 sendfile → 等待网卡发完 → 才能处理下一个请求”的串行瓶颈
- 一个 worker 进程即可并发处理成千上万个连接，每个连接只在真正需要时才执行 sendfile
两者结合的真实负载表现
在静态资源压测场景中（如百万并发请求 1MB 图片），该组合带来三重优势：
- CPU 利用率下降 30%~50%：省去用户态内存操作与频繁上下文切换
- 吞吐量提升 2~3 倍：epoll 快速唤醒 + sendfile 批量推送，单位时间发出更多响应
- 延迟更平稳：无阻塞等待，避免某一大文件传输拖慢其他连接的响应队列
注意：该优势在启用 keepalive、合理配置 worker_connections 和 epoll 作为 events 模块的前提下才能充分释放。
