DMA技术的出现
在没有 DMA 技术前，I/O 的过程是这样的：
- CPU 发出对应的指令给磁盘控制器，然后返回；
- 磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断；
- CPU收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间CPU 是无法执行其他任务的。
可以看到，整个数据的传输过程，都要需要 CPU 亲自参与搬运数据的过程，而且这个过程，CPU 是不能做其他事情的。
简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来。
于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access） 技术。
具体过程：
- 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态
- 操作系统收到请求后，进一步将 I/O 请求发送 DMA，然后让 CPU 执行其他任务； DMA 进一步将 I/O 请求发送给磁盘
- 磁盘收到DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向DMA发起中断信号，告知自己缓冲区已满； DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用CPU，CPU 可以执行其他任务；
- 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU； CPU 收到 DMA的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回
可以看到， 整个数据传输的过程，DMA帮CPU负担了很多工作，但是 CPU 在这个过程中也是必不可少的，因为传输什么数据，从哪里传输到哪里，都需要 CPU 来告诉 DMA 控制器。
早期 DMA 只存在在主板上，如今由于 I/O 设备越来越多，数据传输的需求也不尽相同，所以现在每个 I/O 设备里面都有自己的 DMA 控制器。
传统I/O存在的问题
如果服务端要提供文件传输的功能，我们能想到的最简单的方式是：将磁盘上的文件读取出来，然后通过网络协议发送给客户端。
传统 I/O 代码通常如下，一般会需要两个系统调用：
read(file, tmp_buf, len);
write(socket, tmp_buf, len);
代码很简单，虽然就两行代码，但是这里面发生了不少的事情。
首先，期间共发生了 4 次用户态与内核态的上下文切换，因为发生了两次系统调用，一次是 read() ，一次是 write()，每次系统调用都得先从用户态切换到内核态，等内核完成任务后，再从内核态切换回用户态。
上下文切换到成本并不小，一次切换需要耗时几十纳秒到几微秒，虽然时间看上去很短，但是在高并发的场景下，这类时间容易被累积和放大，从而影响系统的性能。
其次，还发生了 4 次数据拷贝，其中两次是 DMA 的拷贝，另外两次则是通过 CPU 拷贝的，下面说一下这个过程：
1.第一次拷贝，把磁盘上的数据拷贝到操作系统内核的缓冲区里，这个拷贝的过程是通过 DMA 搬运的。
2.第二次拷贝，把内核缓冲区的数据拷贝到用户的缓冲区里，于是我们应用程序就可以使用这部分数据了，这个拷贝到过程是由 CPU 完成的。
3.第三次拷贝，把刚才拷贝到用户的缓冲区里的数据，再拷贝到内核的 socket 的缓冲区里，这个过程依然还是由 CPU 搬运的。
4.第四次拷贝，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程又是由 DMA 搬运的。
这种简单又传统的文件传输方式，存在冗余的上文切换和数据拷贝，在高并发系统里是非常糟糕的，多了很多不必要的开销，会严重影响系统性能。
所以，要想提高文件传输的性能，就需要减少「用户态与内核态的上下文切换」和「内存拷贝」的次数。
虚拟内存
在了解零拷贝技术之前，先了解虚拟内存的概念。
所有现代操作系统都使用虚拟内存，使用虚拟地址取代物理地址，主要有以下几点好处：
- 多个虚拟内存可以指向同一个物理地址。
- 虚拟内存空间可以远远大于物理内存空间。
利用上述的第一条特性可以优化，可以把内核空间和用户空间的虚拟地址映射到同一个物理地址，这样在 I/O 操作时就不需要来回复制了。
如下图展示了虚拟内存的原理。
如何实现零拷贝
零拷贝主要是用来解决操作系统在处理 I/O 操作时，频繁复制数据的问题。关于零拷贝主要技术有 mmap+write、sendfile和splice等几种方式。
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();
这样就减少了2次上下文切换，因为只调用了一次系统函数。
下图展示了sendfile原理：
sendfile方式只有三次数据复制（其中只有一次 CPU COPY）以及2次上下文切换。
那能不能把 CPU COPY 减少到没有呢？这样需要带有 scatter/gather的sendfile方式了。
带有 scatter/gather 的 sendfile方式
Linux 2.4 内核对 sendfile 系统调用进行优化，但是需要硬件DMA控制器的配合。**提供了带有 scatter/gather 的 sendfile 操作，
这个操作可以把最后一次 CPU COPY 去除。级后的sendfile将内核空间缓冲区中对应的数据描述信息（文件描述符、地址偏移量等信息）记录到socket缓冲区中。
DMA控制器根据socket缓冲区中的地址和偏移量将数据从内核缓冲区拷贝到网卡中，从而省去了内核空间中仅剩1次CPU拷贝。
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 不需要硬件支持。
PageCache
前面说的「内核缓冲区」实际上是磁盘高速缓存（PageCache）。
我们可以用 PageCache 来缓存最近被访问的数据，当空间不足时淘汰最久未被访问的缓存。
PageCache 的优点主要是两个：
- 缓存最近被访问的数据；
- 预读功能；
但是，在传输大文件（GB 级别的文件）的时候，PageCache 会不起作用，那就白白浪费 DMA 多做的一次数据拷贝，造成性能的降低，即使使用了 PageCache 的零拷贝也会损失性能。
大文件建议采用异步和直接IO方式传输。
总结
无论是传统的 I/O 方式，还是引入了零拷贝之后，2 次 DMA copy是都少不了的。因为两次 DMA 都是依赖硬件完成的。所以，所谓的零拷贝，都是为了减少 CPU copy 及减少了上下文的切换。
下图展示了各种零拷贝技术的对比图：
