前言
磁盘可以说是计算机系统最慢的硬件之一，读写速度相差内存10倍以上，所以针对优化磁盘的技术非常的多，比如零拷贝、直接I/O、异步I/O等等，这些优化的目的就是为了提高系统的吞吐量，另外操作系统内核中的磁盘高速缓存区，可以有效的减少磁盘的访问次数。
这次，我们就以「文件传输」作为切入点，来分析I/O工作方式，以及如何优化传输文件的性能。
为什么要有DMA技术?
在没有DMA技术前，I/O的过程是这样的：
为了方便你理解，我画了一副图：
可以看到，整个数据的传输过程，都要需要CPU亲自参与搬运数据的过程，而且这个过程，CPU是不能做其他事情的。
简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用CPU来搬运的话，肯定忙不过来。
计算机科学家们发现了事情的严重性后，于是就发明了DMA技术，也就是直接内存访问（DirectMemoryAccess）技术。
什么是DMA技术？简单理解就是，在进行I/O设备和内存的数据传输的时候，数据搬运的工作全部交给DMA控制器，而CPU不再参与任何与数据搬运相关的事情，这样CPU就可以去处理别的事务。
那使用DMA控制器进行数据传输的过程究竟是什么样的呢？下面我们来具体看看。
具体过程：
用户进程调用read方法，向操作系统发出I/O请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态；
操作系统收到请求后，进一步将I/O请求发送DMA，然后让CPU执行其他任务；
DMA进一步将I/O请求发送给磁盘；
磁盘收到DMA的I/O请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向DMA发起中断信号，告知自己缓冲区已满；
DMA收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用CPU，CPU可以执行其他任务；
当DMA读取了足够多的数据，就会发送中断信号给CPU；
CPU收到DMA的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回；
可以看到，整个数据传输的过程，CPU不再参与数据搬运的工作，而是全程由DMA完成，但是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拷贝的，下面说一下这个过程：
第一次拷贝，把磁盘上的数据拷贝到操作系统内核的缓冲区里，这个拷贝的过程是通过DMA搬运的。
第二次拷贝，把内核缓冲区的数据拷贝到用户的缓冲区里，于是我们应用程序就可以使用这部分数据了，这个拷贝到过程是由CPU完成的。
第三次拷贝，把刚才拷贝到用户的缓冲区里的数据，再拷贝到内核的socket的缓冲区里，这个过程依然还是由CPU搬运的。
第四次拷贝，把内核的socket缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程又是由DMA搬运的。
我们回过头看这个文件传输的过程，我们只是搬运一份数据，结果却搬运了4次，过多的数据拷贝无疑会消耗CPU资源，大大降低了系统性能。
这种简单又传统的文件传输方式，存在冗余的上文切换和数据拷贝，在高并发系统里是非常糟糕的，多了很多不必要的开销，会严重影响系统性能。
所以，要想提高文件传输的性能，就需要减少「用户态与内核态的上下文切换」和「内存拷贝」的次数。
如何优化文件传输的性能？
先来看看，如何减少「用户态与内核态的上下文切换」的次数呢？
读取磁盘数据的时候，之所以要发生上下文切换，这是因为用户空间没有权限操作磁盘或网卡，内核的权限最高，这些操作设备的过程都需要交由操作系统内核来完成，所以一般要通过内核去完成某些任务的时候，就需要使用操作系统提供的系统调用函数。
而一次系统调用必然会发生2次上下文切换：首先从用户态切换到内核态，当内核执行完任务后，再切换回用户态交由进程代码执行。
所以，要想减少上下文切换到次数，就要减少系统调用的次数。
再来看看，如何减少「数据拷贝」的次数？
在前面我们知道了，传统的文件传输方式会历经4次数据拷贝，而且这里面，「从内核的读缓冲区拷贝到用户的缓冲区里，再从用户的缓冲区里拷贝到socket的缓冲区里」，这个过程是没有必要的。
因为文件传输的应用场景中，在用户空间我们并不会对数据「再加工」，所以数据实际上可以不用搬运到用户空间，因此用户的缓冲区是没有必要存在的。
如何实现零拷贝？
零拷贝技术实现的方式通常有2种：
下面就谈一谈，它们是如何减少「上下文切换」和「数据拷贝」的次数。
mmapwrite
在前面我们知道，read系统调用的过程中会把内核缓冲区的数据拷贝到用户的缓冲区里，于是为了减少这一步开销，我们可以用mmap替换read系统调用函数。
buf=mmap(file,len);write(sockfd,buf,len);
mmap系统调用函数会直接把内核缓冲区里的数据「映射」到用户空间，这样，操作系统内核与用户空间就不需要再进行任何的数据拷贝操作。
具体过程如下：
应用进程调用了mmap后，DMA会把磁盘的数据拷贝到内核的缓冲区里。接着，应用进程跟操作系统内核「共享」这个缓冲区；
应用进程再调用write，操作系统直接将内核缓冲区的数据拷贝到socket缓冲区中，这一切都发生在内核态，由CPU来搬运数据；
最后，把内核的socket缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程是由DMA搬运的。
我们可以得知，通过使用mmap来代替read，可以减少一次数据拷贝的过程。
但这还不是最理想的零拷贝，因为仍然需要通过CPU把内核缓冲区的数据拷贝到socket缓冲区里，而且仍然需要4次上下文切换，因为系统调用还是2次。
sendfile
在Linux内核版本2.1中，提供了一个专门发送文件的系统调用函数sendfile，函数形式如下：
#include<sys/socket.h>ssize_tsendfile(intout_fd,intin_fd,off_t*offset,size_tcount);
它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。
首先，它可以替代前面的read和write这两个系统调用，这样就可以减少一次系统调用，也就减少了2次上下文切换的开销。
其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到socket缓冲区里，不再拷贝到用户态，这样就只有2次上下文切换，和3次数据拷贝。如下图：
但是这还不是真正的零拷贝技术，如果网卡支持SG-DMA（TheScatter-GatherDirectMemoryAccess）技术（和普通的DMA有所不同），我们可以进一步减少通过CPU把内核缓冲区里的数据拷贝到socket缓冲区的过程。
你可以在你的Linux系统通过下面这个命令，查看网卡是否支持scatter-gather特性：
$ethtool-keth0|grepscatter-gatherscatter-gather:on
于是，从Linux内核2.4版本开始起，对于支持网卡支持SG-DMA技术的情况下，sendfile系统调用的过程发生了点变化，具体过程如下：
所以，这个过程之中，只进行了2次数据拷贝，如下图：
这就是所谓的零拷贝（Zero-copy）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过CPU来搬运数据，所有的数据都是通过DMA来进行传输的。
零拷贝技术的文件传输方式相比传统文件传输的方式，减少了2次上下文切换和数据拷贝次数，只需要2次上下文切换和数据拷贝次数，就可以完成文件的传输，而且2次的数据拷贝过程，都不需要通过CPU，2次都是由DMA来搬运。
所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。
使用零拷贝技术的项目
事实上，Kafka这个开源项目，就利用了「零拷贝」技术，从而大幅提升了I/O的吞吐率，这也是Kafka在处理海量数据为什么这么快的原因之一。
如果你追溯Kafka文件传输的代码，你会发现，最终它调用了JavaNIO库里的transferTo方法：
@OverridepubliclongtransferFrom(FileChannelfileChannel,longposition,longcount)throwsIOException{returnfileChannel.transferTo(position,count,socketChannel);}如果Linux系统支持sendfile系统调用，那么transferTo实际上最后就会使用到sendfile系统调用函数。
曾经有大佬专门写过程序测试过，在同样的硬件条件下，传统文件传输和零拷拷贝文件传输的性能差异，你可以看到下面这张测试数据图，使用了零拷贝能够缩短65%的时间，大幅度提升了机器传输数据的吞吐量。
数据来源于：https://developer.ibm.com/articles/j-zerocopy/
另外，Nginx也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：
http{...sendfileon...}sendfile配置的具体意思:
当然，要使用sendfile，Linux内核版本必须要2.1以上的版本。
PageCache有什么作用？
回顾前面说道文件传输过程，其中第一步都是先需要先把磁盘文件数据拷贝「内核缓冲区」里，这个「内核缓冲区」实际上是磁盘高速缓存（PageCache）。
由于零拷贝使用了PageCache技术，可以使得零拷贝进一步提升了性能，我们接下来看看PageCache是如何做到这一点的。
读写磁盘相比读写内存的速度慢太多了，所以我们应该想办法把「读写磁盘」替换成「读写内存」。于是，我们会通过DMA把磁盘里的数据搬运到内存里，这样就可以用读内存替换读磁盘。
但是，内存空间远比磁盘要小，内存注定只能拷贝磁盘里的一小部分数据。
那问题来了，选择哪些磁盘数据拷贝到内存呢？
我们都知道程序运行的时候，具有「局部性」，所以通常，刚被访问的数据在短时间内再次被访问的概率很高，于是我们可以用PageCache来缓存最近被访问的数据，当空间不足时淘汰最久未被访问的缓存。
所以，读磁盘数据的时候，优先在PageCache找，如果数据存在则可以直接返回；如果没有，则从磁盘中读取，然后缓存PageCache中。
还有一点，读取磁盘数据的时候，需要找到数据所在的位置，但是对于机械磁盘来说，就是通过磁头旋转到数据所在的扇区，再开始「顺序」读取数据，但是旋转磁头这个物理动作是非常耗时的，为了降低它的影响，PageCache使用了「预读功能」。
比如，假设read方法每次只会读32KB的字节，虽然read刚开始只会读0～32KB的字节，但内核会把其后面的32～64KB也读取到PageCache，这样后面读取32～64KB的成本就很低，如果在32～64KB淘汰出PageCache前，进程读取到它了，收益就非常大。
所以，PageCache的优点主要是两个：
这两个做法，将大大提高读写磁盘的性能。
但是，在传输大文件（GB级别的文件）的时候，PageCache会不起作用，那就白白浪费DMA多做的一次数据拷贝，造成性能的降低，即使使用了PageCache的零拷贝也会损失性能。
这是因为如果你有很多GB级别文件需要传输，每当用户访问这些大文件的时候，内核就会把它们载入PageCache中，于是PageCache空间很快被这些大文件占满。
另外，由于文件太大，可能某些部分的文件数据被再次访问的概率比较低，这样就会带来2个问题：
所以，针对大文件的传输，不应该使用PageCache，也就是说不应该使用零拷贝技术，因为可能由于PageCache被大文件占据，而导致「热点」小文件无法利用到PageCache，这样在高并发的环境下，会带来严重的性能问题。
大文件传输用什么方式实现？
那针对大文件的传输，我们应该使用什么方式呢？
我们先来看看最初的例子，当调用read方法读取文件时，进程实际上会阻塞在read方法调用，因为要等待磁盘数据的返回，如下图：
具体过程：
当调用read方法时，会阻塞着，此时内核会向磁盘发起I/O请求，磁盘收到请求后，便会寻址，当磁盘数据准备好后，就会向内核发起I/O中断，告知内核磁盘数据已经准备好；
内核收到I/O中断后，就将数据从磁盘控制器缓冲区拷贝到PageCache里；
最后，内核再把PageCache中的数据拷贝到用户缓冲区，于是read调用就正常返回了。
对于阻塞的问题，可以用异步I/O来解决，它工作方式如下图：
它把读操作分为两部分：
而且，我们可以发现，异步I/O并没有涉及到PageCache，所以使用异步I/O就意味着要绕开PageCache。
绕开PageCache的I/O叫直接I/O，使用PageCache的I/O则叫缓存I/O。通常，对于磁盘，异步I/O只支持直接I/O。
前面也提到，大文件的传输不应该使用PageCache，因为可能由于PageCache被大文件占据，而导致「热点」小文件无法利用到PageCache。
于是，在高并发的场景下，针对大文件的传输的方式，应该使用「异步I/O直接I/O」来替代零拷贝技术。
直接I/O应用场景常见的两种：
另外，由于直接I/O绕过了PageCache，就无法享受内核的这两点的优化：
于是，传输大文件的时候，使用「异步I/O直接I/O」了，就可以无阻塞地读取文件了。
所以，传输文件的时候，我们要根据文件的大小来使用不同的方式：
传输大文件的时候，使用「异步I/O直接I/O」；
传输小文件的时候，则使用「零拷贝技术」；
在Nginx中，我们可以用如下配置，来根据文件的大小来使用不同的方式：
location/video/{sendfileon;aioon;directio1024m;}当文件大小大于directio值后，使用「异步I/O直接I/O」，否则使用「零拷贝技术」。
总结
早期I/O操作，内存与磁盘的数据传输的工作都是由CPU完成的，而此时CPU不能执行其他任务，会特别浪费CPU资源。
于是，为了解决这一问题，DMA技术就出现了，每个I/O设备都有自己的DMA控制器，通过这个DMA控制器，CPU只需要告诉DMA控制器，我们要传输什么数据，从哪里来，到哪里去，就可以放心离开了。后续的实际数据传输工作，都会由DMA控制器来完成，CPU不需要参与数据传输的工作。
传统IO的工作方式，从硬盘读取数据，然后再通过网卡向外发送，我们需要进行4上下文切换，和4次数据拷贝，其中2次数据拷贝发生在内存里的缓冲区和对应的硬件设备之间，这个是由DMA完成，另外2次则发生在内核态和用户态之间，这个数据搬移工作是由CPU完成的。
为了提高文件传输的性能，于是就出现了零拷贝技术，它通过一次系统调用（sendfile方法）合并了磁盘读取与网络发送两个操作，降低了上下文切换次数。另外，拷贝数据都是发生在内核中的，天然就降低了数据拷贝的次数。
Kafka和Nginx都有实现零拷贝技术，这将大大提高文件传输的性能。
零拷贝技术是基于PageCache的，PageCache会缓存最近访问的数据，提升了访问缓存数据的性能，同时，为了解决机械硬盘寻址慢的问题，它还协助I/O调度算法实现了IO合并与预读，这也是顺序读比随机读性能好的原因。这些优势，进一步提升了零拷贝的性能。
需要注意的是，零拷贝技术是不允许进程对文件内容作进一步的加工的，比如压缩数据再发送。
另外，当传输大文件时，不能使用零拷贝，因为可能由于PageCache被大文件占据，而导致「热点」小文件无法利用到PageCache，并且大文件的缓存命中率不高，这时就需要使用「异步IO直接IO」的方式。
在Nginx里，可以通过配置，设定一个文件大小阈值，针对大文件使用异步IO和直接IO，而对小文件使用零拷贝。