大家好，我是小风哥，今天和大家简单聊聊零拷贝。

计算机处理的任务大体可以分为两类：CPU密集型与IO密集型。

当前流行的互联网应用更多的属于IO密集型，传统的IO标准接口都是基于数据拷贝的，这篇文章我们主要关注该怎样从数据拷贝的角度来优化IO性能。

为什么IO接口要基于数据拷贝？

为了让广大码农们更好的沉迷于自己的一亩三分地，防止ta们分心去关心计算机中的硬件资源分配问题，操作系统诞生了。

操作系统本质上就是一个管家，目的就是更加公平合理的给各个进程分配硬件资源，在操作系统出现之前，程序员需要直面各类硬件，就像这样：

在这一时期程序员真可谓掌控全局，掌控全局带来的后果就是你需要掌控所有细节，这显然不利于生产力的释放。

操作系统应用而生。

计算机系统就变成这样了：

现在应用程序不需要和硬件直接交互了，仅从IO的角度上看，操作系统变成了一个类似路由器的角色，把应用程序递交过来的数据分发到具体的硬件上去，或者从硬件接收数据并分发给相应的进程。

数据传递是通过什么呢？就是我们常说的buffer，所谓buffer就是一块可用的内存空间，用来暂存数据。

操作系统这一中间商导致的问题就是：你需要首先把东西交给操作系统，操作系统再转手交给硬件，这就必然涉及到数据拷贝。

这就是为什么传统的IO操作必然需要进行数据拷贝的原因所在。关于操作系统系统完整的阐述请参见博主的《深入理解操作系统》。

然而数据拷贝是有性能损耗的，接下来我们用一个实例来让大家对该问题有一个更直观的认知。

网络服务器

浏览器打开一个网页需要很多数据，包括看到的图片、html文件、css文件、js文件等等，当浏览器请求这类文件时服务器端的工作其实是非常简单的：服务器只需要从磁盘中抓出该文件然后丢给网络发送出去。

代码基本上类似这样：

fileDesc buf lensocket buf len

这两段代码非常简单，第一行代码从文件中读取数据存放在buf中，然后将buf中的数据通过网络发送出去。

注意观察buf，服务器全程没有对buf中的数据进行任何修改，buf里的数据在用户态逛了一圈后挥一挥衣袖没有带走半点云彩就回到了内核态。

这两行看似简单的代码实际上在底层发生了什么呢？

答案是这样的：

在程序看来简单的两行代码在底层是比较复杂的，看到这张图你应该真心感激操作系统，操作系统就像一个无比称职的管家，替你把所有脏活累活都承担下来，好让你悠闲的在用户态指点江山。

这简单的两行代码涉及：四次数据拷贝以及四次上下文切换：

这就是看似简单的这两行代码在底层的完整过程。

你觉得这个过程有什么问题吗？

发现问题

有的同学肯定已经注意到了，既然在用户态没有对数据进行任何修改，那为什么要这么麻烦的让数据在用户态来个一日游呢？直接在内核态从磁盘给到网卡不就可以了吗？

恭喜你，答对了！

这种优化思路就是所谓的零拷贝技术，Zero Copy。

总体上来看，优化数据拷贝会有以下三个方向：

知道了解决问题的思路，我们来看下为了实现零拷贝，计算机系统中都有哪些巧妙的设计。

是的，就是mmap，在《mmap可以让程序员实现哪些骚操作》一文中我们对其进行了详细讲解，你能想到mmap还可以实现零拷贝吗？

对于本文提到的网络服务器我们可以这样修改代码：

buf  mmap lensocket buf len

你可能会想仅仅将read替换为mmap会有什么优化吗？

如果你真的理解了mmap就会知道，mmap仅仅将文件内容映射到了进程地址空间中，并没有真正的拷贝到进程地址空间，这节省了一次从内核态到用户态的数据拷贝。

同样的，当调用write时数据直接从内核buf拷贝给了socket buf，而不是像read/write方法中把用户态数据拷贝给socket buf。

我们可以看到，利用mmap我们节省了一次数据拷贝，上下文切换依然是四次。

尽管mmap可以节省数据拷贝，但维护文件与地址空间的映射关系也是有代价的，除非CPU拷贝数据的时间超过维系映射关系的代价，否则基于mmap的程序性能可能不及传统的read/write。

此外，如果映射的文件被其它进程截断，在Linux系统下你的进程将立即接收到SIGBUS信号，因此这种异常情况也需要正确处理。

除了mmap之外，还有其它办法也可以实现零拷贝。

你没有看错，在Linux系统下为了解决数据拷贝问题专门设计了这一系统调用：

ssize_t sendfile out_fd  in_fd off_t  size_t count

Windows下也有一个作用类似的API：TransmitFile。

这一系统调用的目的是在两个文件描述之间拷贝数据，但值得注意的是，数据拷贝的过程完全是在内核态完成，因此在网络服务器的这个例子中我们将把那两行代码简化为一行，也就是调用这里的sendfile。

使用sendfile将节省两次数据拷贝，因为数据无需传输到用户态：

调用sendfile后，首先DMA机制会把数据从磁盘拷贝到内核buf中，接下来把数据从内核buf拷贝到相应的socket buf中，最后利用DMA机制将数据从socket buf拷贝到网卡中。

我们可以看到，同使用传统的read/write相比少了一次数据拷贝，而且内核态和用户态的切换只有两次。

有的同学可能已经看出了，这好像不是零拷贝吧，在内核中这不是还有一次从内核态buf到socket buf的数据拷贝吗？这次拷贝看上去也是没有必要的。

的确如此，为解决这一问题，单纯的软件机制已经不够用了，我们需要硬件来帮一点忙，这就是DMA Gather Copy。

sendfile 与DMA Gather Copy

传统的DMA机制必须从一段连续的空间中传输数据，就像这样：

很显然，你需要在源头上把所有需要的数据都拷贝到一段连续的空间中：

现在肯定有同学会问，为什么不直接让DMA可以从多个源头收集数据呢？

这就是所谓的DMA Gather Copy。

有了这一特性，无需再将内核文件buf中的数据拷贝到socket buf，而是网卡利用DMA Gather Copy机制将消息头以及需要传输的数据等直接组装在一起发送出去。

在这一机制的加持下，CPU甚至完全不需要接触到需要传输的数据，而且程序利用sendfile编写的代码也无需任何改动，这进一步提升了程序性能。

当前流行的消息中间件kafka就基于sendfile来高效传输文件。

其实你应该已经看出来了，高效IO的秘诀其实很简单：尽量少让CPU参与进来。

实际上sendfile的使用场景是比较受限的，大前提是用户态无需看到操作的数据，并且只能从文件描述符往socket中传输数据，而且DMA Gather Copy也需要硬件支持，那么有没有一种不依赖硬件特性同时又能在任意两个文件描述符之间以零拷贝方式高效传递数据的方法呢？

答案是肯定的！这就要说到Linux下的另一个系统调用了：splice。

这里还要再次强调一下不管是sendfile还是这里的splice系统调用，使用的大前提都是无需在用户态看到要传递的数据。

让我们再来看一下传统的read/write方法。

在这一方法下必须将数据从内核态拷贝的用户态，然后在从用户态拷贝回内核态，既然用户态无需对该数据有任何操作，那么为什么不让数据传输直接在内核态中进行呢？

现在目标有了，实现方法呢？

答案是借助Linux世界中用于进程间通信的管道，pipe。

还是以网络服务器为例，DMA把数据从磁盘拷贝到文件buf，然后将数据写入管道，当在再次调用splice后将数据从管道读入socket buf中，然后通过DMA发送出去，值得注意的是向管道写数据以及从管道读数据并没有真正的拷贝数据，而仅仅传递的是该数据相关的必要信息。

你会看到，splice和sendfile是很像的，实际上后来sendfile系统调用经过改造后就是基于splice实现的，既然有splice那么为什么还要保留sendfile呢？答案很简单，如果直接去掉sendfile，那么之前依赖该系统调用的所有程序将无法正常运行。