22.彻底理解零拷贝

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

所谓CPU密集型就好比程序员，天天坐在办公室里闷头写代码不怎么需要与外界交互(CPU计算)；而IO密集型更像是销售，几乎不怎么呆在办公室里，需要不断与外界沟通交流(输入输出)。

对于程序员来说哪类更容易应对呢？显然是CPU密集型，原因也很简单，CPU密集型任务通常大部分时间都在用户态(呆在办公室里），很少涉及底层，像操作系统以及硬件等，因此程序的运行行为更容易被程序掌控。

而与CPU密集型相对于的，IO密集型任务花在用户态的时间相对更少，这类任务更多的需要操作系统的协助（与其它人交互），也就是花在内核态的时间更多，由于IO密集型任务涉及两部分软件：用户态的应用程序与内核态的操作系统，因此程序的运行行为对程序员来说控制力有限。

注意，用户态受程序员控制，内核态受操作系统控制，关于用户态内核态的更详尽讲解参见博主的深入理解操作系统一书，关注公众号码农的荒岛求生并操作系统即可。

然而不巧的是，当前流行的互联网技术其实也就是网络应用，更多的属于IO密集型，涉及：软件部分的操作系统与数据库，以及硬件部分的磁盘与网络，这些软硬件显然是在内核态，用户态部分只是冰山一角。当遇到IO后，多线程的魔法就消失了，因为相对于CPU速度来说，瓶颈往往出现在IO设备上，这时候任凭你有再多核再多线程都没有用了。

传统的IO标准接口都是基于数据拷贝的，这篇文章我们主要关注该怎样从数据拷贝的角度来优化IO操作。

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

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

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

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

操作系统应用而生。

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

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

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

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

这就是为什么传统的IO操作必然需要进行数据拷贝的原因所在。

有的同学可能不以为意，不就是数据拷贝吗？应该很快吧！

要知道数据拷贝不只涉及CPU一个模块，还包括内存、总线，在CPU看来，内存是一个非常低速的设备，让CPU去完成数据拷贝这样的任务就是在浪费人才，幸好现代计算机系统中普遍采用DMA技术，这类技术可以在没有CPU的参与下实现软件和硬件之间的数据拷贝，从而减轻CPU负担，然而用户态和内核态这类软件和软件之间的数据拷贝则无此机制，在这种情况下数据拷贝依然需要CPU的参与。

现状就是这样的，接下来我们用一个实例来让大家对该问题有一个更直观的认知。

网络服务器

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

代码基本上类似这样：

read(fileDesc, buf, len);
write(socket, buf, len);

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

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

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

答案是这样的：

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

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

1. read函数会涉及一次用户态到内核态的切换，操作系统会向磁盘发起一次IO请求，当数据准备好后通过DMA技术把数据拷贝到内核的buffer中，注意本次数据拷贝无需CPU参与。
2. 此后操作系统开始把这块数据从内核拷贝到用户态的buffer中，此时read()函数返回，并从内核态切换回用户态，到这时read(fileDesc, buf, len);这行代码就返回了，buf中装好了新鲜出炉的数据。
3. 记下来send函数再次导致用户态与内核态的切换，此时数据需要从用户态buf拷贝到网络协议子系统的buf中，具体点该buf属于在代码中使用的这个socket。
4. 4. 此后send函数返回，再次由内核态返回到用户态；此时在程序员看来数据已经成功发出去了，但实际数据依然停留在内核中，此后第四次数据copy开始，利用DMA技术把数据从socket buf拷贝给网卡，然后真正的发送出去。

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

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

发现问题

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

恭喜你，答对了！

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

总体上来看，数据拷贝会有以下三种情况：

1.用户态不需要真正的去访问数据，就像上面这个示例，用户态根本不需要知道buf里面装的是什么。在这种情况下无需把数据从内核态拷贝到用户态然后再把数据从用户态拷贝会内核态。 数据无需用户态感知，数据拷贝完全发生在内核态。

2.内核态不要真正的去访问数据，用户态程序可以绕过内核直接和硬件交互，这样就避免了内核的参与，从而减少数据拷贝的可能。

内核无需感知数据。

3.如果内核态和用户态不得不进行数据交互，则优化用户态与内核态数据的交互方式，有的同学可 能会问，除了数据拷贝难道还有其它交互方式吗？答案是肯定的，接下来你会看到。

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

mmap

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

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

buf = mmap(file, len);
write(socket, buf, len);

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

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

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

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

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

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

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

sendfile

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

#include <sys/sendfile.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, 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。

Splice

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

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

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

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

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

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

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

接下来我们在看一种可以绕过内核直接在用户态操作硬件的方法。

总结

本文介绍了很多零拷贝的优化技巧，但是注意，一定要注意，如果你的程序对性能要没有到那种极度苛刻哪怕慢1ns都不行的时候，忘掉本文讲解的这些所谓优化技巧，老老实实用read/write，相比这些所谓的技巧，内存拷贝没有那么糟糕。

本文仅仅告诉你为了追求高性能系统中都有哪些乱七八糟的设计。

我是小风哥，希望这篇文章对大家理解IO有所帮助。