14、零拷贝技术：传统I/O路径分析、mmap内存映射、sendfile系统调用、splice与tee、零拷贝在Kafka/nginx中的应用

零拷贝，这个词听起来就很诱人，对吧？

说白了，就是让数据在传输过程中，尽量减少甚至避免CPU的参与。我刚开始接触网络编程时，总觉得数据从磁盘到网卡，不就是读一下写一下嘛，能有多大事？直到我亲手压测了一个文件服务器，发现CPU全耗在拷贝上了，才意识到问题的严重性。

传统I/O路径分析：数据到底经历了什么？

我们先看看传统方式下，一个文件从磁盘读到内存，再通过socket发出去，中间发生了什么。

// 传统I/O：读取文件并发送
char buf[4096];
read(fd, buf, 4096);   // 磁盘 → 内核缓冲区 → 用户缓冲区
write(sockfd, buf, 4096); // 用户缓冲区 → 内核缓冲区 → 网卡

这段代码看起来简单，但背后有四次数据拷贝，四次上下文切换。

• 第一次拷贝：磁盘DMA直接把数据读到内核缓冲区。这一步不耗CPU，是硬件干的。
• 第二次拷贝：CPU把数据从内核缓冲区搬到用户缓冲区。这一步，CPU被占用了。
• 第三次拷贝：CPU再把数据从用户缓冲区搬到socket内核缓冲区。CPU又忙活了。
• 第四次拷贝：DMA从socket缓冲区把数据搬到网卡。这一步不耗CPU。

你看，真正有用的数据搬运只有两次（磁盘→内核→网卡），但CPU硬生生多干了两次没必要的活。我在项目中遇到过，一个简单的静态文件服务器，QPS刚过万CPU就飙到90%，一查全是拷贝开销。

mmap内存映射：让文件直接出现在进程地址空间

mmap的思路很直接——既然问题出在用户态和内核态之间的拷贝，那我干脆不拷贝了，直接把内核缓冲区映射到用户空间。

// mmap方式
void *addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, 0);
// 现在可以直接操作addr，就像操作普通内存一样
write(sockfd, addr, length);

这样做的好处是：少了一次CPU拷贝。数据从磁盘到内核缓冲区后，用户态程序可以直接访问，不需要再搬一次。

但注意，mmap不是银弹。我个人的经验是，小文件用mmap收益不大，甚至可能更慢，因为mmap本身有页对齐、缺页中断等开销。大文件（比如几百MB以上）才值得用。

sendfile系统调用：真正意义上的零拷贝

sendfile才是零拷贝的经典实现。它直接把数据从一个文件描述符传到另一个，全程不需要经过用户空间。

// sendfile方式
off_t offset = 0;
sendfile(sockfd, filefd, &offset, count);

这里发生了什么？

• 数据从磁盘DMA到内核缓冲区。
• 内核直接把数据描述符（不是数据本身）传给socket缓冲区。
• DMA从内核缓冲区把数据搬到网卡。

整个过程只有两次拷贝，而且CPU只参与了描述符的传递，不参与数据搬运。你想想看，这效率能不高吗？

我记得在优化一个图片服务器时，把read+write改成sendfile，CPU使用率直接降了40%，吞吐量翻了一倍。嗯，这种成就感是写业务代码体会不到的。

splice与tee：更灵活的零拷贝

sendfile虽然好，但局限性也明显。splice和tee是Linux提供的更通用的零拷贝接口。

// splice：在两个文件描述符之间移动数据
int pipefd[2];
pipe(pipefd);
splice(filefd, NULL, pipefd[1], NULL, count, SPLICE_F_MOVE);
splice(pipefd[0], NULL, sockfd, NULL, count, SPLICE_F_MOVE);

splice的核心思想是：通过管道作为中转，避免用户空间拷贝。它比sendfile灵活的地方在于，可以连接任意两个文件描述符，不限于文件到socket。

tee就更特殊了，它可以把管道中的数据复制到另一个管道，但数据本身不消耗。说白了，就是复制描述符，不复制数据。

我在做代理服务器时用过splice，效果不错。但说实话，splice的API有点反人类，需要自己管理管道，而且SPLICE_F_MOVE这个标志在很多内核版本上并不真正移动数据，只是拷贝。嗯，这里要注意。

零拷贝在Kafka/Nginx中的应用

理论说完了，我们看看工业界是怎么用的。

Nginx：sendfile是标配

Nginx的配置里有一个sendfile on;，打开后静态文件传输就走sendfile。我见过很多新手配Nginx，不知道这个选项，结果性能差了一大截。

Nginx还用了directio来配合大文件传输，避免内核缓冲区占用太多内存。说白了，就是小文件用sendfile，大文件用direct I/O，各取所长。

Kafka：零拷贝是核心设计

Kafka的吞吐量为什么那么高？零拷贝功不可没。Kafka在消费消息时，数据从磁盘读到页缓存，然后直接通过sendfile发给消费者，不经过用户空间。

我记得Kafka的官方文档里提到，零拷贝让Kafka在普通硬件上就能达到每秒百万条消息的吞吐量。这不是吹的，我亲自搭过集群验证过。

但Kafka也不是无脑用零拷贝。它有一个transferable的概念，只有消息体足够大时才走零拷贝路径，小消息还是走传统路径。为什么？因为零拷贝的上下文切换和系统调用开销，对小消息来说不划算。

知识体系总览

下面这张图总结了零拷贝技术的核心脉络，我建议你保存下来，面试前看一眼就够了。

总结一下

零拷贝的核心思想就一句话：减少数据在用户空间和内核空间之间的搬运次数。传统I/O有4次拷贝，mmap减少到3次，sendfile减少到2次。

但别以为零拷贝就是性能银弹。我见过有人在小文件上用mmap，结果性能还不如read+write。也见过有人想在加密场景下用sendfile，发现根本行不通。

选型的时候，问自己三个问题：

• 数据需要修改吗？需要 → 别用零拷贝。
• 文件大小多少？小于64KB → 传统I/O可能更快。
• 是静态文件传输吗？是 → sendfile是你的好朋友。

嗯，零拷贝就聊到这。下一章我们聊聊IO多路复用，那又是另一个精彩的话题。

---

公众号:蓝海资料掘金营，微信deep3321