今天聊聊零拷贝。
计算机处理的任务大体可以分为两类：CPU密集型与IO密集型。
当前流行的互联网应用更多的属于IO密集型，传统的IO标准接口都是基于数据拷贝的，这篇文章我们主要关注该怎样从数据拷贝的角度来优化IO性能，让你的程序在IO性能方面赶超P8。
操作系统本质上就是一个管家，
目的就是更加公平合理的给各个进程分配硬件资源
，在操作系统出现之前，程序员需要直面各类硬件，就像这样：
在这一时期程序员真可谓掌控全局，掌控全局带来的后果就是你需要掌控所有细节，这显然不利于生产力的释放。
操作系统应用而生。
计算机系统就变成这样了：
现在应用程序不需要和硬件直接交互了，仅从IO的角度上看，操作系统变成了一个类似路由器的角色，把应用程序递交过来的数据分发到具体的硬件上去，或者从硬件接收数据并分发给相应的进程。
数据传递是通过什么呢？就是我们常说的buffer，所谓buffer就是一块可用的内存空间，用来暂存数据。
操作系统这一中间商导致的问题就是：
你需要首先把东西交给操作系统，操作系统再转手交给硬件
，这就必然涉及到数据拷贝。
这就是为什么传统的IO操作必然需要进行数据拷贝的原因所在。关于操作系统系统完整的阐述请参见博主的《深入理解操作系统》。
然而数据拷贝是有性能损耗的，接下来我们用一个实例来让大家对该问题有一个更直观的认知。
浏览器打开一个网页需要很多数据，包括看到的图片、html文件、css文件、js文件等等，当浏览器请求这类文件时服务器端的工作其实是非常简单的：服务器只需要从磁盘中抓出该文件然后丢给网络发送出去。
代码基本上类似这样：
read(fileDesc, buf, len);
write(socket, buf, len);
这两段代码非常简单，第一行代码从文件中读取数据存放在buf中，然后将buf中的数据通过网络发送出去。
注意观察buf，服务器全程没有对buf中的数据进行任何修改，buf里的数据在用户态逛了一圈后挥一挥衣袖没有带走半点云彩就回到了内核态。
这两行看似简单的代码实际上在底层发生了什么呢？
答案是这样的：
在程序看来简单的两行代码在底层是比较复杂的，看到这张图你应该真心感激操作系统，操作系统就像一个无比称职的管家，替你把所有脏活累活都承担下来，好让你悠闲的在用户态指点江山。
这简单的两行代码涉及：
四次数据拷贝
以及
四次上下文切换：
-
read函数会涉及一次用户态到内核态的切换，操作系统会向磁盘发起一次IO请求，当数据准备好后通过DMA技术把数据拷贝到内核的buffer中，注意本次数据拷贝无需CPU参与。
-
此后操作系统开始把这块数据从内核拷贝到用户态的buffer中，此时read()函数返回，并从内核态切换回用户态，到这时read(fileDesc, buf, len);这行代码就返回了，buf中装好了新鲜出炉的数据。
-
接下来send函数再次导致用户态与内核态的切换，此时数据需要从用户态buf拷贝到网络协议子系统的buf中，具体点该buf属于在代码中使用的这个socket。
-
此后send函数返回，再次由内核态返回到用户态；此时在程序员看来数据已经成功发出去了，但实际上数据可能依然停留在内核中，此后第四次数据copy开始，利用DMA技术把数据从socket buf拷贝给网卡，然后真正的发送出去。
这就是看似简单的这两行代码在底层的完整过程。
你觉得这个过程有什么问题吗？
有的同学肯定已经注意到了，既然在用户态没有对数据进行任何修改，那为什么要这么麻烦的让数据在用户态来个一日游呢？直接在内核态从磁盘给到网卡不就可以了吗？
恭喜你，答对了！
这种优化思路就是所谓的零拷贝技术，Zero Copy。
总体上来看，优化数据拷贝会有以下三个方向：
-
用户态不需要真正的去访问数据，就像上面这个示例，用户态根本不需要知道buf里面装的是什么。在这种情况下无需把数据从内核态拷贝到用户态然后再把数据从用户态拷贝回内核态。
数据无需用户态感知，数据拷贝完全发生在内核态。
-
内核态不要真正的去访问数据，用户态程序可以绕过内核直接和硬件交互，这样就避免了内核的参与，从而减少数据拷贝的可能。
内核无需感知数据。
-
如果内核态和用户态不得不进行数据交互，则优化用户态与内核态数据的交互方式。
知道了解决问题的思路，我们来看下为了实现零拷贝，计算机系统中都有哪些巧妙的设计。
是的，就是mmap。
对于本文提到的网络服务器我们可以这样修改代码：
buf = mmap(file, len);
write(socket, buf, len);
你可能会想仅仅将read替换为mmap会有什么优化吗？
如果你真的理解了mmap就会知道，mmap仅仅将文件内容映射到了进程地址空间中，并没有真正的拷贝到进程地址空间，这节省了一次从内核态到用户态的数据拷贝。
同样的，当调用write时数据直接从内核buf拷贝给了socket buf，而不是像read/write方法中把用户态数据拷贝给socket buf。
我们可以看到，利用mmap我们节省了一次数据拷贝，上下文切换依然是四次。
