Linux 内核中的零拷贝 Sendfile：从 epoll 多路复用到物理路径优化
在 Linux 的高并发服务里，epoll 和 sendfile 经常一起出现，但它们解决的是两类不同的问题。
epoll 负责“谁可以继续干活”，它解决的是大量连接下的事件等待和就绪通知问题。sendfile 负责“数据怎么搬得更省”，它解决的是文件内容从磁盘路径到 socket 路径的传输效率问题。
把两者放在同一个服务里，常见的场景就是静态文件服务器、下载服务、视频分发和反向代理。epoll 让线程不必在大量连接之间反复轮询，sendfile 让文件发送少走一次用户态拷贝路径。前者提升并发调度效率，后者降低数据搬运成本，这就是它们组合起来的价值。
1. epoll 解决的是等待成本
在传统 select 或 poll 模型里，连接数一多，内核和用户态都要付出更高的扫描成本。epoll 的核心优势不在于“更快读取数据”，而在于把“哪些连接已经就绪”这件事变成事件驱动。
对一个 Web 服务来说，epoll 适合做三件事：
也就是说，epoll 决定的是“何时发送”，不是“如何发送”。真正的数据传输路径，还要交给发送接口来完成。
2. sendfile 解决的是拷贝成本
传统发送文件的路径通常是：
这个过程里，用户态缓冲区并没有参与业务计算，但却承担了一次额外拷贝。对大文件或高并发下载场景来说，这个成本很不划算。
sendfile() 的思路是直接让内核把文件页缓存中的数据送到 socket 路径上，避免用户态中转。它减少的是“用户态到内核态再回到内核态”的这段搬运链路，因此常被称为零拷贝。
更准确地说，sendfile 不是“完全没有拷贝”，而是“去掉了用户态参与的数据拷贝”。在现代 Linux 中，底层是否还能进一步利用页面引用、DMA、网卡卸载能力，还要看内核版本、文件系统和网卡能力，但它的工程收益是确定的：减少一次数据搬运，降低 CPU 消耗。
3. 为什么 epoll 要和 sendfile 结合
单独看 sendfile，它只是一个高效的发送手段；单独看 epoll，它只是一个高效的事件通知机制。两者结合后，才形成一个完整的高并发文件服务模型。
典型流程是这样的：
这个结构的关键不在“把 sendfile 塞进 epoll”，而在于 epoll 只负责唤醒，sendfile 负责高效传输。这样，线程不会在不可写的 socket 上空转，也不会为了文件发送额外把数据搬到用户空间。
4. 物理路径到底优化了什么
“物理路径优化”这个说法，放到 sendfile 上，最好理解成对数据流动路径的收缩。
传统路径里，CPU 不仅要参与系统调用切换，还要参与两次显式拷贝。sendfile 让内核更直接地把页缓存中的文件页组织到 socket 发送路径中，减少了中间缓冲区的往返。
从工程视角看，优化体现在四个方面：
这也是为什么静态资源分发、文件下载、CDN 边缘节点、Nginx 这类场景长期偏爱 sendfile。
5. 适合用 sendfile 的场景
sendfile 并不是所有 I/O 的万能答案，它最适合的是“文件内容直接发给网络”的场景。
比较典型的使用场景有：
如果业务需要在发送前做压缩、加密、脱敏、拼接、协议转换，那么数据往往还是要先进入用户态处理，这时 sendfile 的适用性就会下降。
6. 什么时候不该直接用
sendfile 的性能收益很明显，但它不是无条件优于 read/write。
以下情况要谨慎：
换句话说，sendfile 的前提是“内容可以原样发送”。一旦业务逻辑要求先加工数据，用户态缓冲区就仍然有存在价值。
7. 一个更接近真实服务的发送流程
下面这段伪代码展示了 epoll 和 sendfile 结合时的主流程。重点不是语法，而是状态管理：连接建立后进入事件循环，socket 可写时推进文件发送进度。
int epfd = epoll_create1(0);
int listen_fd = create_listen_socket();
struct epoll_event ev, events[MAX_EVENTS];
ev.events = EPOLLIN;
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);
while (1) {
int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
for (int i = 0; i < n; i++) {
int fd = events[i].data.fd;
if (fd == listen_fd) {
int conn_fd = accept(listen_fd, NULL, NULL);
set_nonblocking(conn_fd);
ev.events = EPOLLOUT | EPOLLET;
ev.data.fd = conn_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);
continue;
}
if (events[i].events & EPOLLOUT) {
off_t offset = session[fd].offset;
ssize_t sent = sendfile(fd, session[fd].file_fd, &offset,
session[fd].remain);
if (sent > 0) {
session[fd].offset = offset;
session[fd].remain -= sent;
}
if (session[fd].remain == 0) {
close(fd);
}
}
}
}
这段流程里有几个实际问题必须处理：
也就是说，sendfile 只是数据路径优化，完整的稳定性仍然依赖状态机。
8. 性能判断不要只看“零拷贝”三个字
很多文章会把 sendfile 直接等同于“性能一定更好”，这其实不严谨。实际性能要看数据规模、并发量、内核实现和业务处理复杂度。
可以从这几个维度判断：
如果答案大多是“是”，sendfile 的收益通常很明显。如果业务本身就是强计算、强加工，优化重点可能不在这里。
9. 总结
epoll 和 sendfile 不是同一层的问题，但它们经常组成同一条高性能链路。
epoll 解决的是高并发下的事件等待问题，让线程只在连接就绪时工作。sendfile 解决的是文件到网络的数据搬运问题，让内容尽量不经过用户态中转。两者叠加后，Linux 服务就能在“少等待、少拷贝、少切换”的方向上同时受益。
对于静态文件服务来说，这是一条非常成熟的优化路线。真正要做的不是把它当成口号，而是根据业务形态判断：你的服务是在搬数据，还是在加工数据。前者适合 sendfile，后者更需要用户态处理链路。
