零拷贝⚓︎

摘要

本文从“文件如何在内核与用户态之间流动”这一条具体路径出发，说明所谓零拷贝究竟减少了哪些复制与上下文切换。重点不在术语本身，而在于 DMA、页缓存、mmap、sendfile 与 splice 分别改写了哪一段数据流。

问题背景⚓︎

很多 I/O 密集型程序的性能问题，并不是业务逻辑本身很重，而是数据在不同缓冲区之间被重复搬运。对于文件分发、下载、代理转发这类场景，正文内容往往几乎不需要修改，此时用户态缓冲区只是被当作中转站，引入了额外 CPU 成本。

如果把最传统的发送路径写成：

$\text{disk} \rightarrow \text{kernel page cache} \rightarrow \text{user buffer} \rightarrow \text{socket buffer} \rightarrow \text{NIC}$

那么问题就变得很明确：文件先进入页缓存，再被复制到用户缓冲区，随后又被复制回内核发送路径，最后才交给网卡。这条路径中真正让系统变慢的，往往不是磁盘读取本身，而是中间多出来的那两次用户态绕行。这里以 socket 发送为例，但同类问题也会出现在其他“内核对象到内核对象”的数据路径中。

传统发送路径为什么昂贵⚓︎

read + write 的优点是接口通用、语义直接，任何需要检查、解码、压缩、加密或改写正文的业务都可以自然使用它。但它的代价也同样清晰：线程既要发起两次系统调用，又要承担两次显式数据复制带来的 CPU 和缓存压力。

从用户态观察，这两段额外复制分别是：

$\text{kernel buffer} \rightarrow \text{user buffer}$

以及：

$\text{user buffer} \rightarrow \text{kernel socket path}$

当文件较大、并发连接较多或者发送吞吐较高时，这两段复制会持续占用内存带宽，并让 CPU 把时间消耗在搬运字节，而不是业务推进上。

DMA、页缓存与拷贝边界⚓︎

理解零拷贝之前，先要把设备搬运与 CPU 搬运区分开。DMA 的作用是让磁盘控制器或网卡直接在设备与内存之间传输数据，CPU 只负责建立控制路径、维护缓冲区和处理协议逻辑，而不亲自逐字节移动数据。

因此，很多“拷贝优化”的目标并不是消除一切数据移动，而是尽量让：

$\text{device} \leftrightarrow \text{memory}$

这类传输继续由 DMA 或内核内部路径完成，避免把数据额外抬到用户态再放回去。

页缓存是这条路径中的另一个关键角色。文件内容一旦进入页缓存，它已经处于内核可直接管理的数据页中。如果后续发送逻辑能够复用这些页，而不是重新复制出一份用户缓冲区副本，就能显著降低发送路径成本。这也是虚拟内存一文中“文件页”与“页缓存”概念在一般 I/O 路径里真正重要的原因。

`mmap` 改写了访问方式⚓︎

mmap 不是专门为网络发送设计的接口，它做的是把文件页映射到进程虚拟地址空间中，让程序可以像访问普通内存一样访问文件内容。这样一来，应用不必先调用 read 把文件内容复制到用户缓冲区，而是直接通过映射访问页缓存里的文件页。

对访问路径而言，它减少的是显式的：

$\text{kernel} \rightarrow \text{user copy}$

但这并不意味着发送到 socket 时就一定完全省掉后续成本。如果业务仍然需要逐段检查数据、组包或写入其他发送缓冲区，那么用户态依然会参与其中。mmap 更适合随机访问、局部读取和“把文件当内存看待”的场景，而不是自动成为所有发送链路的最佳解。

`sendfile` 改写了发送路径⚓︎

sendfile 更直接地面向“文件到 socket”这一问题。它的核心目标是让文件数据不再先到用户态再折返内核，而是尽量沿着页缓存到发送路径的通道前进：

$\text{file page cache} \rightarrow \text{socket path} \rightarrow \text{NIC}$

因此，相比 read + write，sendfile 主要减少了三类成本：

用户态缓冲区的中转。
由中转引入的两次显式复制中的主要部分。
两次系统调用拆分带来的部分控制开销。

这使它非常适合静态文件服务、对象存储下载、透明代理转发等“正文几乎不改动”的路径。只要业务不要求在用户态重写载荷内容，sendfile 往往都是一个非常直接而高收益的优化点。

`splice` 更像内核对象之间的接力⚓︎

splice 进一步泛化了“数据尽量停留在内核里流动”的思路。它通常借助 pipe 作为中介，把数据在两个内核对象之间转移，目标仍然是减少用户态介入。

与 sendfile 相比，splice 的适用对象更广，不局限于文件到 socket；但它的使用方式也更接近“搭建一条内核内部数据通路”，接口理解和工程维护都更复杂。因此它更适合明确知道自己在构建中继路径、并且业务确实不需要在用户态解释内容的场景。

零拷贝的真实含义⚓︎

工程语境里的“零拷贝”通常并不表示“物理上完全没有任何数据移动”。更准确的理解应当是三层目标：

尽量避免显式的用户态中转复制。
尽量减少 CPU 参与的数据搬运。
尽量复用内核已有的数据页、页缓存或缓冲区结构。

因此，所谓零拷贝本质上是在追求：

$\text{让数据路径尽可能停留在 kernel space 中}$

而不是宣称字节从未移动。只要业务必须解压、加密、过滤、重写正文，用户态迟早都要接触真实载荷，这时零拷贝收益就会下降，甚至不再成立。

工程边界⚓︎

判断是否值得使用零拷贝，不应只看接口名称，而应先回答两个问题。

第一，业务是否真的需要修改正文。如果答案是需要，那么 read + write 的通用路径往往更自然，因为数据最终还是必须进入用户态处理。

第二，瓶颈是否真的位于复制成本。如果系统瓶颈已经转移到磁盘、网络、TLS 加解密、压缩或应用层计算，那么单独减少一次复制未必带来决定性收益。

因此，零拷贝最适合的不是“所有高性能服务”，而是“数据内容高度可复用、用户态只负责调度而不负责重写”的那一类服务。

与系统设计的关系⚓︎

从系统设计视角看，零拷贝真正回答的是：当数据只需要被转发或发送，而不需要被改写时，用户态是否仍然值得充当中转站。

这也是为什么静态资源分发、下载服务、透明转发、缓存命中后的大对象回源路径，都会天然关注 sendfile、splice 或映射式访问。相反，如果命中后必须拼接模板、做内容改写或执行协议级编码，零拷贝就不再是核心问题。

如果继续追问页缓存、文件页与映射关系如何支撑这些优化，可结合虚拟内存阅读；如果继续追问这些路径如何被 I/O 模型调度和组织，可结合 I/O 模型阅读。