零拷贝技术原理：mmap、sendfile、splice 在协议驱动中的应用

说到协议解析的性能优化，有个话题绕不开——数据拷贝。我早年做网关设备时，一台机器要处理几千条并发连接，CPU 占用率动不动就飙到 90%。后来一查，一半以上的开销都花在「把数据从内核搬进用户态，再搬回去」这件事上。说白了，传统 IO 路径里，数据被反复拷贝了好几次。

零拷贝技术就是来解决这个问题的。它不是真的「零」拷贝，而是减少内核态与用户态之间的冗余拷贝。今天咱们就聊三个最常用的手段：mmap、sendfile 和 splice。它们在协议驱动场景下，各有各的用武之地。

传统 IO 路径：数据到底被拷贝了几次？

先看一个典型场景：从磁盘读文件，然后通过 socket 发出去。传统做法是 read() + write()。你想想看，数据走了多少步？

1. 磁盘 → 内核缓冲区（DMA 拷贝）
2. 内核缓冲区 → 用户态缓冲区（CPU 拷贝）
3. 用户态缓冲区 → socket 内核缓冲区（CPU 拷贝）
4. socket 内核缓冲区 → 网卡（DMA 拷贝）

一共 4 次拷贝，其中 2 次是 CPU 参与的。更关键的是，上下文切换也折腾了 4 次（read 两次、write 两次）。

mmap：共享一片内存区域

mmap 的思路很简单：把内核缓冲区映射到用户进程的地址空间。这样用户态程序可以直接读写这块内存，省掉了一次 CPU 拷贝。

用 mmap 替代 read() 后，上面的流程变成：

1. 磁盘 → 内核缓冲区（DMA 拷贝）
2. 内核缓冲区 → socket 内核缓冲区（CPU 拷贝，但数据不用经过用户态）
3. socket 内核缓冲区 → 网卡（DMA 拷贝）

拷贝从 4 次降到 3 次，CPU 参与的拷贝从 2 次降到 1 次。

但 mmap 有个坑——页对齐和文件截断。我曾经在一个项目里用 mmap 处理日志文件，结果文件被另一个进程截断了，映射区域直接 SIGBUS。嗯，这里要注意：mmap 映射的文件不能被截断，否则进程会崩溃。解决方案是用信号处理或者提前锁住文件。

sendfile：从文件到 socket 的直通车

sendfile() 是 Linux 专门为「文件 → socket」场景设计的。它直接把数据从内核文件缓冲区送到 socket 缓冲区，用户态完全不用碰数据。

流程变成：

1. 磁盘 → 内核缓冲区（DMA 拷贝）
2. 内核缓冲区 → socket 内核缓冲区（CPU 拷贝，由 sendfile 内部完成）
3. socket 内核缓冲区 → 网卡（DMA 拷贝）

还是 3 次拷贝？别急，如果网卡支持 SG-DMA（Scatter-Gather DMA），还能再优化：

1. 磁盘 → 内核缓冲区（DMA 拷贝）
2. 内核缓冲区 → 网卡（SG-DMA 直接描述符传递，无需 CPU 拷贝）

这就真正做到了「零 CPU 拷贝」。我在做静态文件服务器时，用 sendfile 替换 read+write，CPU 占用率直接降了 40%。

splice：更通用的零拷贝管道

splice() 是 Linux 2.6.17 引入的，它比 sendfile 更通用。splice 可以在两个文件描述符之间移动数据，而且不需要经过用户态。它的核心依赖是「管道（pipe）」作为中间缓冲区。

举个例子，从 socket A 接收数据，直接转发到 socket B：

int pipefd[2];
pipe(pipefd);

// 从 socket A 读到管道
splice(sockA, NULL, pipefd[1], NULL, 4096, SPLICE_F_MOVE);

// 从管道写到 socket B
splice(pipefd[0], NULL, sockB, NULL, 4096, SPLICE_F_MOVE);

整个过程数据一直在内核态流转，用户态只负责控制逻辑。拷贝次数？只有 2 次 DMA 拷贝（收和发），CPU 完全不参与数据搬运。

我在做协议网关时用过 splice。当时需要把 TCP 连接的数据原封不动转发到后端，同时还要做简单的头部检查。用 splice 做数据通道，用 mmap 做头部解析区，两者配合，吞吐量比传统方式高了将近一倍。

三种技术的对比

技术	适用场景	CPU 拷贝次数	用户态参与	协议解析适用性
mmap	文件映射、部分解析+转发	1 次	需要（指针操作）	高（可解析头部）
sendfile	文件 → socket 透传	0~1 次	不需要	低（只能透传）
splice	socket ↔ socket、管道	0 次	不需要	中（可配合控制逻辑）

零拷贝在协议驱动中的典型架构

下面这张图展示了我在一个协议网关项目中用到的零拷贝数据流。核心思路是：控制面走 mmap 做解析，数据面走 splice 做转发。

避坑指南

零拷贝技术虽好，但用不对反而会出问题。我踩过几个坑，分享给你：

• mmap 的内存占用：映射大文件时，虚拟地址空间消耗很快。32 位系统上尤其明显。我建议只映射需要解析的头部区域，body 用 splice 透传。
• sendfile 的 offset 管理：多次调用 sendfile 时，要手动维护文件偏移量。我曾经忘了更新 offset，结果同一个数据块被发了两次。
• splice 的管道大小限制：管道缓冲区默认只有 64KB，大流量下容易阻塞。记得用 fcntl() 调大管道容量，或者用 SPLICE_F_NONBLOCK 配合事件循环。
• 协议解析的边界问题：零拷贝意味着数据不在用户态连续存放。解析 TCP 流时，一个完整的协议帧可能跨多个 mmap 页或 splice 块。你需要自己维护状态机，不能指望一次 read 拿到完整数据。