为什么要有 DMA 技术?

heaboy2025/9/16大约 20 分钟

9.1 什么是零拷⻉？

磁盘可以说是计算机系统最慢的硬件之一，读写速度相差内存 10 倍以上，所以针对优化磁盘的技

术非常的多，比如零拷⻉、直接 I/O 、异步 I/O 等等，这些优化的目的就是为了提高系统的吞吐

量，另外操作系统内核中的磁盘高速缓存区，可以有效的减少磁盘的访问次数。

这次，我们就以「文件传输」作为切入点，来分析 I/O 工作方式，以及如何优化传输文件的性

能。

为什么要有 DMA 技术?

在没有 DMA 技术前，I/O 的过程是这样的：

CPU 发出对应的指令给磁盘控制器，然后返回；

磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，

然后产生一个中断；

CPU 收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读

进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间 CPU 是无法执行

其他任务的。

为了方便你理解，我画了一副图：

可以看到，整个数据的传输过程，都要需要 CPU 亲自参与搬运数据的过程，而且这个过程，CPU

是不能做其他事情的。

简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都

用 CPU 来搬运的话，肯定忙不过来。

计算机科学家们发现了事情的严重性后，于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access ）技术。

什么是 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

搬运的。

read (file , tmp_buf , len );
write (socket , tmp_buf , len );

第二次拷⻉，把内核缓冲区的数据拷⻉到用⼾的缓冲区里，于是我们应用程序就可以使用这部

分数据了，这个拷⻉到过程是由 CPU 完成的。

第三次拷⻉，把刚才拷⻉到用⼾的缓冲区里的数据，再拷⻉到内核的 socket 的缓冲区里，这个

过程依然还是由 CPU 搬运的。

第四次拷⻉，把内核的 socket 缓冲区里的数据，拷⻉到网卡的缓冲区里，这个过程又是由

DMA 搬运的。

我们回过头看这个文件传输的过程，我们只是搬运一份数据，结果却搬运了 4 次，过多的数据拷

⻉无疑会消耗 CPU 资源，大大降低了系统性能。

这种简单又传统的文件传输方式，存在冗余的上文切换和数据拷⻉，在高并发系统里是非常糟糕

的，多了很多不必要的开销，会严重影响系统性能。

所以，要想提高文件传输的性能，就需要减少「用⼾态与内核态的上下文切换」和「内存拷⻉」

的次数。

如何优化文件传输的性能？

先来看看，如何减少「用⼾态与内核态的上下文切换」的次数呢？

读取磁盘数据的时候，之所以要发生上下文切换，这是因为用⼾空间没有权限操作磁盘或网卡，

内核的权限最高，这些操作设备的过程都需要交由操作系统内核来完成，所以一般要通过内核去

完成某些任务的时候，就需要使用操作系统提供的系统调用函数。

而一次系统调用必然会发生 2 次上下文切换：首先从用⼾态切换到内核态，当内核执行完任务

后，再切换回用⼾态交由进程代码执行。

所以，要想减少上下文切换到次数，就要减少系统调用的次数。

再来看看，如何减少「数据拷⻉」的次数？

在前面我们知道了，传统的文件传输方式会历经 4 次数据拷⻉，而且这里面，「从内核的读缓冲区

拷⻉到用⼾的缓冲区里，再从用⼾的缓冲区里拷⻉到 socket 的缓冲区里」，这个过程是没有必要

的。

因为文件传输的应用场景中，在用⼾空间我们并不会对数据「再加工」，所以数据实际上可以不用

搬运到用⼾空间，因此用⼾的缓冲区是没有必要存在的。

如何实现零拷⻉？

零拷⻉技术实现的方式通常有 2 种：

mmap + write

sendfile

下面就谈一谈，它们是如何减少「上下文切换」和「数据拷⻉」的次数。

mmap + write

在前面我们知道， 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_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的

⻓度，返回值是实际复制数据的⻓度。

首先，它可以替代前面的 read()  和 write()  这两个 系统调用，这样就可以减少一次系统调

用，也就减少了 2 次上下文切换的开销。

其次，该系统调用，可以直接把内核缓冲区里的数据拷⻉到 socket 缓冲区里，不再拷⻉到用⼾

态，这样就只有 2 次上下文切换，和 3 次数据拷⻉。如下图：

但是这还不是真正的零拷⻉技术，如果网卡支持 SG-DMA （The Scatter-Gather Direct Memory Access ）技术（和普通的 DMA 有所不同），我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷⻉到 socket 缓冲区的过程。

你可以在你的 Linux 系统通过下面这个命令，查看网卡是否支持 scatter-gather 特性：

$ ethtool -k eth0 | grep scatter-gather

scatter-gather: on

于是，从 Linux 内核 2.4 版本开始起，对于支持网卡支持 SG-DMA 技术的情况下，

sendfile()  系统调用的过程发生了点变化 ，具体过程如下：

第一步，通过 DMA 将磁盘上的数据拷⻉到内核缓冲区里；

第二步，缓冲区描述符和数据⻓度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直

接将内核缓存中的数据拷⻉到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷

⻉到 socket 缓冲区中，这样就减少了一次数据拷⻉；

所以，这个过程之中，只进行了 2 次数据拷⻉，如下图：

这就是所谓的零拷⻉（Zero-copy ）技术，因为我们没有在内存层面去拷⻉数据，也就是说全程没

有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。。

零拷⻉技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷⻉次数，

只需要 2 次上下文切换和数据拷⻉次数，就可以完成文件的传输，而且 2 次的数据拷⻉过程，都

不需要通过 CPU ，2 次都是由 DMA 来搬运。

所以，总体来看，零拷⻉技术可以把文件传输的性能提高至少一倍以上。

使用零拷⻉技术的项目

事实上，Kafka 这个开源项目，就利用了「零拷⻉」技术，从而大幅提升了 I/O 的吞吐率，这也是

Kafka 在处理海量数据为什么这么快的原因之一。

如果你追溯 Kafka 文件传输的代码，你会发现，最终它调用了 Java NIO 库里的 transferTo 方

法：

@Overridepublic 
long  transferFrom (FileChannel  fileChannel , long  position , long  count ) throws  IOException 
return  fileChannel .transferTo (position , count , socketChannel );
}     
如果 Linux 系统支持 sendfile()  系统调用，那么 transferTo()  实际上最后就会使 用到
sendfile()  系统调用函数。

曾经有大佬专⻔写过程序测试过，在同样的硬件条件下，传统文件传输和零拷拷⻉文件传输的性

能差异，你可以看到下面这张测试数据图，使用了零拷⻉能够缩短 65% 的时间，大幅度提升了

机器传输数据的吞吐量。

另外，Nginx 也支持零拷⻉技术，一般默认是开启零拷⻉技术，这样有利于提高文件传输的效率，

是否开启零拷⻉技术的配置如下：

http {
...

sendfile on

...
}

sendfile 配置的具体意思:

设置为 on 表示，使用零拷⻉技术来传输文件：sendfile ，这样只需要 2 次上下文切换，和 2 次

数据拷⻉。

设置为 off 表示，使用传统的文件传输技术：read + write ，这时就需要 4 次上下文切换，和 4

次数据拷⻉。

当然，要使用 sendfile ，Linux 内核版本必须要 2.1 以上的版本。

http { ... sendfile on ... }

PageCache 有什么作用？

回顾前面说道文件传输过程，其中第一步都是先需要先把磁盘文件数据拷⻉「内核缓冲区」里，

这个「内核缓冲区」实际上是磁盘高速缓存（PageCache ）。

由于零拷⻉使用了 PageCache 技术，可以使得零拷⻉进一步提升了性能，我们接下来看看

PageCache 是如何做到这一点的。

读写磁盘相比读写内存的速度慢太多了，所以我们应该想办法把「读写磁盘」替换成「读写内

存」。于是，我们会通过 DMA 把磁盘里的数据搬运到内存里，这样就可以用读内存替换读磁盘。

但是，内存空间远比磁盘要小，内存注定只能拷⻉磁盘里的一小部分数据。

那问题来了，选择哪些磁盘数据拷⻉到内存呢？

我们都知道程序运行的时候，具有「局部性」，所以通常，刚被访问的数据在短时间内再次被访问

的概率很高，于是我们可以用 PageCache 来缓存最近被访问的数据，当空间不足时淘汰最久未被

访问的缓存。

所以，读磁盘数据的时候，优先在 PageCache 找，如果数据存在则可以直接返回；如果没有，则

从磁盘中读取，然后缓存 PageCache 中。

还有一点，读取磁盘数据的时候，需要找到数据所在的位置，但是对于机械磁盘来说，就是通过

磁头旋转到数据所在的扇区，再开始「顺序」读取数据，但是旋转磁头这个物理动作是非常耗时

的，为了降低它的影响，PageCache 使用了「预读功能」。

比如，假设 read 方法每次只会读 32 KB 的字节，虽然 read 刚开始只会读 0 〜 32 KB 的字节，

但内核会把其后面的 32 〜64 KB 也读取到 PageCache ，这样后面读取 32 〜64 KB 的成本就很低，

如果在 32 〜64 KB 淘汰出 PageCache 前，进程读取到它了，收益就非常大。

所以，PageCache 的优点主要是两个：

缓存最近被访问的数据；

预读功能；

这两个做法，将大大提高读写磁盘的性能。

但是，在传输大文件（GB 级别的文件）的时候，PageCache 会不起作用，那就白白浪费 DMA 多

做的一次数据拷⻉，造成性能的降低，即使使用了 PageCache 的零拷⻉也会损失性能

这是因为如果你有很多 GB 级别文件需要传输，每当用⼾访问这些大文件的时候，内核就会把它们

载入 PageCache 中，于是 PageCache 空间很快被这些大文件占满。

另外，由于文件太大，可能某些部分的文件数据被再次访问的概率比较低，这样就会带来 2 个问

题：

PageCache 由于⻓时间被大文件占据，其他「热点」的小文件可能就无法充分使用到

PageCache ，于是这样磁盘读写的性能就会下降了；

PageCache 中的大文件数据，由于没有享受到缓存带来的好处，但却耗费 DMA 多拷⻉到

PageCache 一次；

所以，针对大文件的传输，不应该使用 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 应用场景常⻅的两种：

应用程序已经实现了磁盘数据的缓存，那么可以不需要 PageCache 再次缓存，减少额外的性能

损耗。在 MySQL 数据库中，可以通过参数设置开启直接 I/O ，默认是不开启；

传输大文件的时候，由于大文件难以命中 PageCache 缓存，而且会占满 PageCache 导致「热点」文件无法充分利用缓存，从而增大了性能开销，因此，这时应该使用直接 I/O 。

另外，由于直接 I/O 绕过了 PageCache ，就无法享受内核的这两点的优化：

内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中，最后「合并」成一个更大的

I/O 请求再发给磁盘，这样做是为了减少磁盘的寻址操作；

内核也会「预读」后续的 I/O 请求放在 PageCache 中，一样是为了减少对磁盘的操作；

于是，传输大文件的时候，使用「异步 I/O + 直接 I/O 」了，就可以无阻塞地读取文件了。

所以，传输文件的时候，我们要根据文件的大小来使用不同的方式：

传输大文件的时候，使用「异步 I/O + 直接 I/O 」；

传输小文件的时候，则使用「零拷⻉技术」；

在 nginx 中，我们可以用如下配置，来根据文件的大小来使用不同的方式：

location /video/ {
sendfile on;
aio on;
directio 1024m;
}

当文件大小大于 directio 值后，使用「异步 I/O + 直接 I/O 」，否则使用「零拷⻉技术」。

总结

早期 I/O 操作，内存与磁盘的数据传输的工作都是由 CPU 完成的，而此时 CPU 不能执行其他任

务，会特别浪费 CPU 资源。

于是，为了解决这一问题，DMA 技术就出现了，每个 I/O 设备都有自己的 DMA 控制器，通过这

个 DMA 控制器， CPU 只需要告诉 DMA 控制器，我们要传输什么数据，从哪里来，到哪里去，就

location /video/ { sendfile on; aio on; directio 1024m; }

9.2 I/O 多路复用：select/poll/epoll →

可以放心离开了。后续的实际数据传输工作，都会由 DMA 控制器来完成，CPU 不需要参与数据传

输的工作。

传统 IO 的工作方式，从硬盘读取数据，然后再通过网卡向外发送，我们需要进行 4 上下文切换，

和 4 次数据拷⻉，其中 2 次数据拷⻉发生在内存里的缓冲区和对应的硬件设备之间，这个是由

DMA 完成，另外 2 次则发生在内核态和用⼾态之间，这个数据搬移工作是由 CPU 完成的。

为了提高文件传输的性能，于是就出现了零拷⻉技术，它通过一次系统调用（ sendfile 方法）

合并了磁盘读取与网络发送两个操作，降低了上下文切换次数。另外，拷⻉数据都是发生在内核

中的，天然就降低了数据拷⻉的次数。

Kafka 和 Nginx 都有实现零拷⻉技术，这将大大提高文件传输的性能。

零拷⻉技术是基于 PageCache 的，PageCache 会缓存最近访问的数据，提升了访问缓存数据的性

能，同时，为了解决机械硬盘寻址慢的问题，它还协助 I/O 调度算法实现了 IO 合并与预读，这也

是顺序读比随机读性能好的原因。这些优势，进一步提升了零拷⻉的性能。

需要注意的是，零拷⻉技术是不允许进程对文件内容作进一步的加工的，比如压缩数据再发送。

另外，当传输大文件时，不能使用零拷⻉，因为可能由于 PageCache 被大文件占据，而导致「热点」小文件无法利用到 PageCache ，并且大文件的缓存命中率不高，这时就需要使用「异步 IO +

直接 IO 」的方式。

在 Nginx 里，可以通过配置，设定一个文件大小阈值，针对大文件使用异步 IO 和直接 IO ，而对

小文件使用零拷⻉。

为什么 要有 DMA 技术?

为什么要有 DMA 技术?