本文将从文件传输场景以及零拷贝技术深究 Linux I/O 的发展过程、优化手段以及实际应用。

前言

存储器是计算机的核心部件之一，在完全理想的状态下，存储器应该要同时具备以下三种特性：

  • 速度足够快：存储器的存取速度应当快于 CPU 执行一条指令，这样 CPU 的效率才不会受限于存储器；

  • 容量足够大：容量能够存储计算机所需的全部数据；

  • 价格足够便宜：价格低廉，所有类型的计算机都能配备。

但是现实往往是残酷的，我们目前的计算机技术无法同时满足上述的三个条件，于是现代计算机的存储器设计采用了一种分层次的结构：

114b684c47eee731c6c57bef627650a7.jpeg

从顶至底，现代计算机里的存储器类型分别有：寄存器、高速缓存、主存和磁盘，这些存储器的速度逐级递减而容量逐级递增。

存取速度最快的是寄存器，因为寄存器的制作材料和 CPU 是相同的，所以速度和 CPU 一样快，CPU 访问寄存器是没有时延的，然而因为价格昂贵，因此容量也极小，一般 32 位的 CPU 配备的寄存器容量是 32✖️32 Bit，64 位的 CPU 则是 64✖️64 Bit，不管是 32 位还是 64 位，寄存器容量都小于 1 KB，且寄存器也必须通过软件自行管理。

第二层是高速缓存，也即我们平时了解的 CPU 高速缓存 L1、L2、L3，一般 L1 是每个 CPU 独享，L3 是全部 CPU 共享，而 L2 则根据不同的架构设计会被设计成独享或者共享两种模式之一，比如 Intel 的多核芯片采用的是共享 L2 模式而 AMD 的多核芯片则采用的是独享 L2 模式。

第三层则是主存，也即主内存，通常称作随机访问存储器（Random Access Memory, RAM）。是与 CPU 直接交换数据的内部存储器。它可以随时读写（刷新时除外），而且速度很快，通常作为操作系统或其他正在运行中的程序的临时资料存储介质。

零拷贝direct I/O异步 I/O磁盘高速缓存区PageCacheTLB
I/OI/OI/O

传统的 Linux 操作系统的标准 I/O 接口是基于数据拷贝操作的，即 I/O 操作会导致数据在操作系统内核地址空间的缓冲区和用户进程地址空间定义的缓冲区之间进行传输。设置缓冲区最大的好处是可以减少磁盘 I/O 的操作，如果所请求的数据已经存放在操作系统的高速缓冲存储器中，那么就不需要再进行实际的物理磁盘 I/O 操作；然而传统的 Linux I/O 在数据传输过程中的数据拷贝操作深度依赖 CPU，也就是说 I/O 过程需要 CPU 去执行数据拷贝的操作，因此导致了极大的系统开销，限制了操作系统有效进行数据传输操作的能力。

Linux I/O

需要了解的词

页缓存（Page Cache）32 KB

为什么要有 DMA

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

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

  • 磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断；

  • CPU 收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间 CPU 是被阻塞的状态，无法执行其他任务。

7addfbaaef33e8452448ad1ae60875b4.jpeg

整个数据的传输过程，都要需要 CPU 亲自参与拷贝数据，而且这时 CPU 是被阻塞的；简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来。

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

简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务。

具体流程如下图：

f6ab57055ca78bdfc8dbc7368f83476f.jpeg

  • 用户进程调用 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 控制器。

传统文件传输的缺陷

有了 DMA 后，我们的磁盘 I/O 就一劳永逸了吗？并不是的；拿我们比较熟悉的下载文件举例，服务端要提供此功能，比较直观的方式就是：将磁盘中的文件读出到内存，再通过网络协议发送给客户端。

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

代码通常如下，一般会需要两个系统调用：

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

代码很简单，虽然就两行代码，但是这里面发生了不少的事情：

30f9bf2491c2c3b98b0a8b11c6e3426b.jpeg

这其中有：

read()write()

所以，要想提高文件传输的性能，就需要减少用户态与内核态的上下文切换和内存拷贝的次数。

如何优化传统文件传输

减少「用户态与内核态的上下文切换」

读取磁盘数据的时候，之所以要发生上下文切换，这是因为用户空间没有权限操作磁盘或网卡，内核的权限最高，这些操作设备的过程都需要交由操作系统内核来完成，所以一般要通过内核去完成某些任务的时候，就需要使用操作系统提供的系统调用函数。

而一次系统调用必然会发生 2 次上下文切换：首先从用户态切换到内核态，当内核执行完任务后，再切换回用户态交由进程代码执行。

减少「数据拷贝」次数

前面提到，传统的文件传输方式会历经 4 次数据拷贝；但很明显的可以看到：从内核的读缓冲区拷贝到用户的缓冲区和从用户的缓冲区里拷贝到 socket 的缓冲区」这两步是没有必要的。

因为在下载文件，或者说广义的文件传输场景中，我们并不需要在用户空间对数据进行再加工，所以数据并不需要回到用户空间中。

零拷贝

那么零拷贝技术就应运而生了，它就是为了解决我们在上面提到的场景——跨过与用户态交互的过程，直接将数据从文件系统移动到网络接口而产生的技术。

零拷贝实现原理

零拷贝技术实现的方式通常有 3 种：

  • mmap + write

  • sendfile

  • splice

mmap + write

read()mmap()read()
buf = mmap(file, len)
write(sockfd, buf, len)
mmap
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
mmap()

835e9f56f7ed0e888e3fb6abf6f5e9af.jpeg

具体过程如下：

mmap()write()
mmap()read()

但这还不是最理想的零拷贝，因为仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，且仍然需要 4 次上下文切换，因为系统调用还是 2 次。

sendfile

sendfile()
#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

read()write()

其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。如下图：

717642bda3aba7959d8150b8d54ed5c3.jpeg

带有 scatter/gather 的 sendfile 方式

scatter/gatherCPU COPY

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

$ ethtool -k eth0 | grep scatter-gather
scatter-gather: on
2.4sendfile()

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

  • 第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；

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

be9acee31a2a68bdf59654fcae3179b8.jpeg

splice 方式

splicesendfilesendfilesplicesocketsocketsendfilesplicesendfilesendfilesplice
splice()Linuxpipe buffersplice()
splice()
pipe()pipe()splice()DMAsplice()splice()socketDMAsocketsplice()

23814472c2497bba95a412099c3d4616.jpeg

splicesendfilesplice
sendfilesplice

零拷贝的实际应用

Kafka

事实上，Kafka 这个开源项目，就利用了「零拷贝」技术，从而大幅提升了 I/O 的吞吐率，这也是 Kafka 在处理海量数据为什么这么快的原因之一。

transferTo
@Overridepublic
long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
    return fileChannel.transferTo(position, count, socketChannel);
}
sendfile()transferTo()sendfile()

Nginx

Nginx 也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：

http {
...
    sendfile on
...
}

大文件传输场景

零拷贝还是最优选吗

在大文件传输的场景下，零拷贝技术并不是最优选择；因为在零拷贝的任何一种实现中，都会有「DMA 将数据从磁盘拷贝到内核缓存区——Page Cache」这一步，但是，在传输大文件（GB 级别的文件）的时候，PageCache 会不起作用，那就白白浪费 DMA 多做的一次数据拷贝，造成性能的降低，即使使用了 PageCache 的零拷贝也会损失性能。

这是因为在大文件传输场景下，每当用户访问这些大文件的时候，内核就会把它们载入 PageCache 中，PageCache 空间很快被这些大文件占满；且由于文件太大，可能某些部分的文件数据被再次访问的概率比较低，这样就会带来 2 个问题：

  • PageCache 由于长时间被大文件占据，其他「热点」的小文件可能就无法充分使用到 PageCache，于是这样磁盘读写的性能就会下降了；

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

direct I/O

那么大文件传输场景下我们该选择什么方案呢？让我们先来回顾一下我们在文章开头介绍 DMA 时最早提到过的同步 I/O：

972bf968d21e2702e0fb5b47bf9ae1fc.jpeg

I/O

6e0537c0173ff89ecf4b0522ddd2d280.jpeg

它把读操作分为两部分：

  • 前半部分，内核向磁盘发起读请求，但是可以不等待数据就位就返回，于是进程此时可以处理其他任务；

  • 后半部分，当内核将磁盘中的数据拷贝到进程缓冲区后，进程将接收到内核的通知，再去处理数据；

而且，我们可以发现，异步 I/O 并没有涉及到 PageCache；使用异步 I/O 就意味着要绕开 PageCache，因为填充 PageCache 的过程在内核中必须阻塞。

direct I/Obuffer I/O
direct I/O
direct I/O
direct I/O

  • 内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中，最后「合并」成一个更大的 I/O 请求再发给磁盘，这样做是为了减少磁盘的寻址操作；

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

实际应用中也有类似的配置，在 nginx 中，我们可以用如下配置，来根据文件的大小来使用不同的方式传输：

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

使用 direct I/O 需要注意的点

Linus(Linus Torvalds)

"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances." —Linus

Linus
man page

总结一下其中需要注意的点如下：

地址对齐限制

O_DIRECT会带来强制的地址对齐限制，这个对齐的大小也跟文件系统/存储介质相关，并且当前没有不依赖文件系统自身的接口提供指定文件/文件系统是否有这些限制的信息

blockdev --getss
blockdev --getpbsz

带来这个限制的原因也很简单，内存对齐这件小事通常是内核来处理的，而O_DIRECT绕过了内核空间，那么内核处理的所有事情都需要用户自己来处理，这里贴一篇详细解释。

O_DIRECT 平台不兼容
LinuxWindowsmacOS
不要并发地运行 fork 和 O_DIRECT I/O
O_DIRECT I/ObuffermmapO_DIRECT I/Ofork

以下情况这个限制不存在：

buffershmatmmapbuffermadvisebuffer
避免对同一文件混合使用 O_DIRECT 和普通 I/O
O_DIRECTI/OI/OI/O
direct I/Ommap。
NFS 协议下的 O_DIRECT
NFSO_DIRECTNFS
NFSO_DIRECT I/OPage CacheI/Ocache
I/OO_DIRECTI/OI/OI/O
LinuxNFS

在 Golang 中使用 direct I/O

direct io 必须要满足 3 种对齐规则：io 偏移扇区对齐，长度扇区对齐，内存 buffer 地址扇区对齐；前两个还比较好满足，但是分配的内存地址仅凭原生的手段是无法直接达成的。

posix_memalignGolang
Golang
buffer := make([]byte, 4096)
bufferdata

方法也很简单，就是先分配一个比预期要大的内存块，然后在这个内存块里找对齐位置 ；这是一个任何语言皆通用的方法，在 Go 里也是可用的。

比如，我现在需要一个 4096 大小的内存块，要求地址按照 512 对齐，可以这样做：

  • 先分配 4096 + 512 大小的内存块，假设得到的内存块首地址是 p1；

  • 然后在 [ p1, p1+512 ] 这个地址范围找，一定能找到 512 对齐的地址 p2；

  • 返回 p2 ，用户能正常使用 [ p2, p2 + 4096 ] 这个范围的内存块而不越界。

以上就是基本原理了，具体实现如下：

// 从 block 首地址往后找到符合 AlignSize 对齐的地址并返回
// 这里很巧妙的使用了位运算，性能upup
func alignment(block []byte, AlignSize int) int {
   return int(uintptr(unsafe.Pointer(&block[0])) & uintptr(AlignSize-1))
}

// 分配 BlockSize 大小的内存块
// 地址按 AlignSize 对齐
func AlignedBlock(BlockSize int) []byte {
   // 分配一个大小比实际需要的稍大
   block := make([]byte, BlockSize+AlignSize)
   // 计算到下一个地址对齐点的偏移量
   a := alignment(block, AlignSize)
   offset := 0
   if a != 0 {
      offset = AlignSize - a
   }
   // 偏移指定位置，生成一个新的 block，这个 block 就满足地址对齐了
   block = block[offset : offset+BlockSize]
   if BlockSize != 0 {
      // 最后做一次地址对齐校验
      a = alignment(block, AlignSize)
      if a != 0 {
         log.Fatal("Failed to align block")
      }
   }
   return block
}

所以，通过以上 AlignedBlock 函数分配出来的内存一定是 512 地址对齐的，唯一的一点点缺点就是在分配较小内存块时对齐的额外开销显得比较大。

开源实现
Golang direct I/O

使用也很简单：

// 创建句柄
fp, err := directio.OpenFile(file, os.O_RDONLY, 0666)
// 创建地址按照 4k 对齐的内存块
buffer := directio.AlignedBlock(directio.BlockSize)
// 把文件数据读到内存块中
_, err := io.ReadFull(fp, buffer)

内核缓冲区和用户缓冲区之间的传输优化

zero-copyCPUsendfile()splice()
mmap

两种优化用户空间和内核空间数据传输的技术：

Copy-on-WriteBuffer Sharing

写时拷贝 (Copy-on-Write)

mmapCOW (Copy on Write)
COWMMUMMUMMUMMU
COWLinuxfork / cloneforkread-only

ff48eea712369f9f73a89eaadc63e3cb.jpeg

局限性
COWCOWCPU

此外，在实际应用的过程中，为了避免频繁的内存映射，可以重复使用同一段内存缓冲区，因此，你不需要在只用过一次共享缓冲区之后就解除掉内存页的映射关系，而是重复循环使用，从而提升性能。

read-onywrite-only
COW 的实际应用
Redis 的持久化机制
Redis
RedisbgsavebgrewriteaofRedisCOWfork()
语言层面的应用
C++ 98std::string
std::string x("Hello");
std::string y = x;  // x、y 共享相同的 buffer
y += ", World!";    // 写时复制，此时 y 使用一个新的 buffer
                    // x 依然使用旧的 buffer
Golangstring, sliceappendcopyappend

缓冲区共享 (Buffer Sharing)

Linux I/OI/Oread()write()
I/OLinuxI/OMMUTLBI/OTLBI/O
Fast Buffersfbuffbufsfbufsbuffer poolfbufs

共享缓冲区技术的实现需要依赖于用户进程、操作系统内核、以及 I/O 子系统 (设备驱动程序，文件系统等)之间协同工作。比如，设计得不好的用户进程容易就会修改已经发送出去的 fbuf 从而污染数据，更要命的是这种问题很难 debug。虽然这个技术的设计方案非常精彩，但是它的门槛和限制却不比前面介绍的其他技术少：首先会对操作系统 API 造成变动，需要使用新的一些 API 调用，其次还需要设备驱动程序配合改动，还有由于是内存共享，内核需要很小心谨慎地实现对这部分共享的内存进行数据保护和同步的机制，而这种并发的同步机制是非常容易出 bug 的从而又增加了内核的代码复杂度，等等。因此这一类的技术还远远没有到发展成熟和广泛应用的阶段，目前大多数的实现都还处于实验阶段。

总结

I/ODMACPUI/O
Zero-copyCPU

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

总体来看，零拷贝技术至少可以把文件传输的性能提高一倍以上，以下是各方案详细的成本对比：


CPU 拷贝DMA 拷贝系统调用上下文切换硬件依赖支持任意类型输入/输出描述符
传统方法22read/write4否是
内存映射12mmap/write4否是
sendfile12sendfile2否否
sendfile(scatter/gather copy)02sendfile2是否
splice02splice2否是
PageCachePageCacheI/OI/O
PageCachePageCacheI/Odirect I/Odirect I/OLinus

而在更广泛的场景下，我们还需要注意到内核缓冲区和用户缓冲区之间的传输优化，这种方式侧重于在用户进程的缓冲区和操作系统的页缓存之间的 CPU 拷贝的优化，延续了以往那种传统的通信方式，但更灵活。

I/O

2394312868c0679cb3b205cf9d9f04c5.png

欢迎加入极客星球圈子，分享多年工作经验和基础技术深度理解，内核，软硬结合，高性能编程，性能优化，后台开发核心技术，扩展视野，直播分享，面试问题，项目训练和指导，问题答疑，可以帮助想进各类大厂（芯片，自动驾驶，嵌入式，互联网等）制定学习路线和学习帮助， 可以分享各种不同公司宝贵的职场工作经验, 项目经验，普升经验，希望少走弯路，做得更好。

7a567ee8e3b02729291d615705f3d201.png

详细点击查看-> 极客星球。

c1be2e86b239939dff0c996506951591.jpeg


226d68e9fc4c2657c9708d17c0935f08.jpeg


fcaa8b4a3042f576e7ba50a9eb2b7713.jpeg

19bdb43ead62f3d44c7da0c11beecd02.jpeg


889aef30f42a561e97ba83158640fb1a.jpeg


看完一键三连在看，转发，点赞

是对文章最大的赞赏，极客重生感谢你7622931703da400e0f765d74f2edf1cd.png

推荐阅读

50aedb22bd3aa9b77802ffb5d97546d5.jpeg


87ea4828e999d910977e3ff3390e6b85.jpeg

51dca7fbfeabcd4629962e33f6495ad5.jpeg

感谢一键三连在看，转发，点赞