一文完全弄懂零拷贝原理

这是我参与8月更文挑战的第12天，活动详情查看：8月更文挑战java

零拷贝

零拷贝（Zero-Copy）是一种 I/O 操做优化技术，能够快速高效地将数据从文件系统移动到网络接口，而不须要将其从内核空间复制到用户空间。其在 FTP 或者 HTTP 等协议中能够显著地提高性能。可是须要注意的是，并非全部的操做系统都支持这一特性，目前只有在使用 NIO 和 Epoll 传输时才可以使用该特性。markdown

须要注意，它不能用于实现了数据加密或者压缩的文件系统上，只有传输文件的原始内容。这类原始内容也包括加密了的文件内容。网络

传统I/O操做存在的性能问题

若是服务端要提供文件传输的功能，咱们能想到的最简单的方式是：将磁盘上的文件读取出来，而后经过网络协议发送给客户端。并发

传统 I/O 的工做方式是，数据读取和写入是从用户空间到内核空间来回复制，而内核空间的数据是经过操做系统层面的 I/O 接口从磁盘读取或写入。socket

代码一般以下，通常会须要两个系统调用：高并发

read(file, tmp_buf, len);
write(socket, tmp_buf, len);
复制代码

代码很简单，虽然就两行代码，可是这里面发生了很多的事情。post

首先，期间共发生了 4 次用户态与内核态的上下文切换，由于发生了两次系统调用，一次是 read() ，一次是 write()，每次系统调用都得先从用户态切换到内核态，等内核完成任务后，再从内核态切换回用户态。性能

上下文切换到成本并不小，一次切换须要耗时几十纳秒到几微秒，虽然时间看上去很短，可是在高并发的场景下，这类时间容易被累积和放大，从而影响系统的性能。优化

其次，还发生了 4 次数据拷贝，其中两次是 DMA 的拷贝，另外两次则是经过 CPU 拷贝的，下面说一下这个过程：加密

第一次拷贝，把磁盘上的数据拷贝到操做系统内核的缓冲区里，这个拷贝的过程是经过 DMA 搬运的。
第二次拷贝，把内核缓冲区的数据拷贝到用户的缓冲区里，因而咱们应用程序就可使用这部分数据了，这个拷贝到过程是由 CPU 完成的。
第三次拷贝，把刚才拷贝到用户的缓冲区里的数据，再拷贝到内核的 socket 的缓冲区里，这个过程依然仍是由 CPU 搬运的。
第四次拷贝，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程又是由 DMA 搬运的。

这种简单又传统的文件传输方式，存在冗余的上文切换和数据拷贝，在高并发系统里是很是糟糕的，多了不少没必要要的开销，会严重影响系统性能。

因此，要想提升文件传输的性能，就须要减小「用户态与内核态的上下文切换」和「内存拷贝」的次数。

零拷贝技术原理

零拷贝主要是用来解决操做系统在处理 I/O 操做时，频繁复制数据的问题。关于零拷贝主要技术有 mmap+write、sendfile和splice等几种方式。

虚拟内存

在了解零拷贝技术以前，先了解虚拟内存的概念。

全部现代操做系统都使用虚拟内存，使用虚拟地址取代物理地址，主要有如下几点好处：

多个虚拟内存能够指向同一个物理地址。
虚拟内存空间能够远远大于物理内存空间。

利用上述的第一条特性能够优化，能够把内核空间和用户空间的虚拟地址映射到同一个物理地址，这样在 I/O 操做时就不须要来回复制了。

以下图展现了虚拟内存的原理。

mmap/write 方式

使用mmap/write方式替换原来的传统I/O方式，就是利用了虚拟内存的特性。下图展现了mmap/write原理：

整个流程的核心区别就是，把数据读取到内核缓冲区后，应用程序进行写入操做时，直接把内核的Read Buffer的数据复制到Socket Buffer以便写入，此次内核之间的复制也是须要CPU的参与的。

上述流程就是少了一个 CPU COPY，提高了 I/O 的速度。不过发现上下文的切换仍是4次并无减小，这是由于仍是要应用程序发起write操做。

那能不能减小上下文切换呢?这就须要sendfile方式来进一步优化了。

sendfile 方式

从 Linux 2.1 版本开始，Linux 引入了 sendfile来简化操做。sendfile方式能够替换上面的mmap/write方式来进一步优化。

sendfile将如下操做：

mmap();
  write();
复制代码

替换为：

sendfile();
复制代码

这样就减小了上下文切换，由于少了一个应用程序发起write操做，直接发起sendfile操做。

下图展现了sendfile原理：

sendfile方式只有三次数据复制（其中只有一次 CPU COPY）以及2次上下文切换。

那能不能把 CPU COPY 减小到没有呢？这样须要带有 scatter/gather的sendfile方式了。

带有 scatter/gather 的 sendfile方式

Linux 2.4 内核进行了优化，提供了带有 scatter/gather 的 sendfile 操做，这个操做能够把最后一次 CPU COPY 去除。其原理就是在内核空间 Read BUffer 和 Socket Buffer 不作数据复制，而是将 Read Buffer 的内存地址、偏移量记录到相应的 Socket Buffer 中，这样就不须要复制。其本质和虚拟内存的解决方法思路一致，就是内存地址的记录。

下图展现了scatter/gather 的 sendfile 的原理：

scatter/gather 的 sendfile 只有两次数据复制（都是 DMA COPY）及 2 次上下文切换。CUP COPY 已经彻底没有。不过这一种收集复制功能是须要硬件及驱动程序支持的。

splice 方式

splice 调用和sendfile 很是类似，用户应用程序必须拥有两个已经打开的文件描述符，一个表示输入设备，一个表示输出设备。与sendfile不一样的是，splice容许任意两个文件互相链接，而并不仅是文件与socket进行数据传输。对于从一个文件描述符发送数据到socket这种特例来讲，一直都是使用sendfile系统调用，而splice一直以来就只是一种机制，它并不只限于sendfile的功能。也就是说 sendfile 是 splice 的一个子集。

在 Linux 2.6.17 版本引入了 splice，而在 Linux 2.6.23 版本中， sendfile 机制的实现已经没有了，可是其 API 及相应的功能还在，只不过 API 及相应的功能是利用了 splice 机制来实现的。

和 sendfile 不一样的是，splice 不须要硬件支持。

总结

不管是传统的 I/O 方式，仍是引入了零拷贝以后，2 次 DMA copy是都少不了的。由于两次 DMA 都是依赖硬件完成的。因此，所谓的零拷贝，都是为了减小 CPU copy 及减小了上下文的切换。

下图展现了各类零拷贝技术的对比图：

	CPU拷贝	DMA拷贝	系统调用	上下文切换
传统方法	2	2	read/write	4
内存映射	1	2	mmap/write	4
sendfile	1	2	sendfile	2
scatter/gather copy	0	2	sendfile	2
splice	0	2	splice	0

结尾

我是一个正在被打击还在努力前进的码农。若是文章对你有帮助，记得点赞、关注哟，谢谢！