操作系統IO之零拷貝技術

磁盤可以說是計算機系統最慢的硬件之一，讀寫速度相差內存 10 倍以上，所以針對優化磁盤的技術非常的多，比如零拷貝、直接 I/O、異步 I/O 等等，這些優化的目的就是為了提高系統的吞吐量，另外操作系統內核中的磁盤高速緩存區，可以有效的減少磁盤的訪問次數。本文會分析 I/O 工作方式，以及如何優化傳輸文件的性能。參考博客如下：

內容提綱

本會從以下幾個方面介紹磁盤的IO技術：

1. DMA之前的IO方式
2. 直接內存訪問——DMA技術。
3. DMA文件傳輸存在的問題。
4. 如何提高文件傳輸的性能。
5. 零拷貝實現原理分析。
6. PageCache有什么用。
7. 大文件傳輸用什么方式實現。

DMA之前的IO

在沒有DMA技術之前，操作系統的從磁盤讀取數據的IO過程如下所示（以read()接口為例）：

read(file, tmp_buf, len);

1. 用戶程序需要讀取數據，調用read方法，把讀取數據的指令交給CPU執行，線程進入阻塞狀態。
2. CPU發出指令給磁盤控制器，告訴磁盤控制器需要讀取哪些數據，然后返回；
3. 磁盤控制器接收到指令后，把指定的數據放入磁盤內部的緩存區，然后用中斷的方式通知CPU；
4. CPU收到中斷信號之后，開始一個字節一個字節的把數據讀取到PageCache緩存區；
5. CPU再一個字節一個字節把數據從PageCache緩存區讀取到用戶緩存區；
6. 用戶程序從內存中讀取到數據，可以繼續執行后續邏輯。

可以看到，整個數據的傳輸過程，都要需要CPU親自參與搬運數據的過程，而且這個過程，CPU是不能做其他事情的。簡單的搬運幾個字符數據那沒問題，但是如果我們用千兆網卡或者硬盤傳輸大量數據的時候，都用CPU來搬運的話，肯定忙不過來。計算機科學家們發現了事情的嚴重性后，於是就發明了 DMA 技術，也就是直接內存訪問（Direct Memory Access） 技術。

直接內存訪問——DMA技術

什么是 DMA 技術？簡單理解就是，在進行 I/O 設備和內存的數據傳輸的時候，數據搬運的工作全部交給 DMA 控制器，而 CPU 不再參與任何與數據搬運相關的事情，這樣 CPU 就可以去處理別的事務。

那使用 DMA 控制器進行數據傳輸的過程究竟是什么樣的呢？下面我們來具體看看。

read(file, tmp_buf, len);

1. 用戶程序需要讀取數據，調用read方法，把讀取數據的指令交給CPU執行。
2. CPU發出指令給DMA，告訴DMA需要讀取磁盤的哪些數據，然后返回，線程進入阻塞狀態
3. DMA向磁盤控制器發出IO請求，告訴磁盤控制器需要讀取哪些數據，然后返回；
4. 磁盤控制器收到IO請求之后，把數據讀取到磁盤緩存區，當磁盤緩存讀取完成之后，中斷DMA；
5. DMA收到磁盤的中斷信號，將磁盤緩存區的數據讀取到PageCache緩存區，然后中斷CPU；
6. CPU響應DMA中斷信號，知道數據讀取完成，然后將PageCache緩存區中的數據讀取到用戶緩存中；
7. 用戶程序從內存中讀取到數據，可以繼續執行后續邏輯。

可以看到， 整個數據傳輸的過程，CPU不再參與磁盤數據搬運的工作，而是全程由DMA完成，但是CPU在這個過程中也是必不可少的，因為傳輸什么數據，從哪里傳輸到哪里，都需要CPU來告訴DMA控制器。

早期DMA只存在在主板上，如今由於I/O設備越來越多，數據傳輸的需求也不盡相同，所以每個I/O設備里面都有自己的DMA控制器。

DMA文件傳輸存在的問題

如果服務端要提供文件傳輸的功能，我們能想到的最簡單的方式是：將磁盤上的文件讀取出來，然后通過網絡協議發送給客戶端。

傳統 I/O 的工作方式是，數據讀取和寫入是從用戶空間到內核空間來回復制，而內核空間的數據是通過操作系統層面的 I/O 接口從磁盤讀取或寫入。

代碼通常如下，一般會需要以下兩個系統調用，代碼很簡單，雖然就兩行代碼，但是這里面發生了不少的事情。

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

1. 用戶程序需要讀取數據，調用read方法，把讀取數據的指令交給CPU執行，線程進入阻塞狀態。
2. CPU發出指令給磁盤DMA，告訴磁盤DMA需要讀取磁盤的哪些數據，然后返回；
3. 磁盤DMA向磁盤控制器發出IO請求，告訴磁盤控制器需要讀取哪些數據，然后返回；
4. 磁盤控制器收到IO請求之后，把數據讀取到磁盤緩存區，當磁盤緩存讀取完成之后，中斷DMA；
5. DMA收到磁盤的中斷信號，將磁盤緩存區的數據讀取到PageCache緩存區，然后中斷CPU；
6. CPU響應DMA中斷信號，知道數據讀取完成，然后將PageCache緩存區中的數據讀取到用戶緩存中；
7. 用戶程序從內存中讀取到數據，可以繼續執行后續寫網卡數據操作；
8. 用戶需要向網卡設備寫入數據，調用write方法，把寫數據指令交給CPU執行，線程進入阻塞；
9. CPU將用戶緩存區的數據寫入PageCache緩存區，然后通知網卡DMA寫數據；
10. 網卡DMA將數據從PageCache緩存區復制到網卡，交給網卡處理數據。
11. 網卡開始處理數據，網卡處理完成數據之后中斷網卡DMA；
12. 網卡DMA處理中斷，知道數據處理完成，向CPU發出中斷；
13. CPU響應DMA中斷信號，知道數據處理完成，喚醒用戶線程；
14. 用戶程序執行后續邏輯。

這個過程比較復雜，其中主要存在以下問題：

• 發生了4次用戶態與內核態的上下文切換，因為發生了兩次系統調用，一次是read() ，一次是write()，每次系統調用都得先從用戶態切換到內核態，等內核完成任務后，再從內核態切換回用戶態。上下文切換到成本並不小，一次切換需要耗時幾十納秒到幾微秒，雖然時間看上去很短，但是在高並發的場景下，這類時間容易被累積和放大，從而影響系統的性能。
• 發生了4次數據拷貝，其中兩次是 DMA 的拷貝，另外兩次則是通過 CPU 拷貝的，下面說一下這個過程：第一次拷貝，把磁盤上的數據拷貝到操作系統內核的緩沖區里，這個拷貝的過程是通過 DMA 搬運的。第二次拷貝，把內核緩沖區的數據拷貝到用戶的緩沖區里，於是我們應用程序就可以使用這部分數據了，這個拷貝到過程是由 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() 系統調用函數會直接把內核緩沖區里的數據「映射」到用戶空間，這樣，操作系統內核與用戶空間就不需要再進行任何的數據拷貝操作。

具體過程如下：

1. 應用進程調用了mmap()后，DMA會把磁盤的數據拷貝到內核的緩沖區里。接着，應用進程跟操作系統內核「共享」這個緩沖區；
2. 應用進程再調用write()，操作系統直接將內核緩沖區的數據拷貝到socket緩沖區中，這一切都發生在內核態，由CPU來搬運數據；
3. 最后，把內核的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() 系統調用的過程發生了點變化，具體過程如下：

1. 通過 DMA 將磁盤上的數據拷貝到內核緩沖區里；
2. 緩沖區描述符和數據長度傳到 socket 緩沖區，這樣網卡的 SG-DMA 控制器就可以直接將內核緩存中的數據拷貝到網卡的緩沖區里，此過程不需要將數據從操作系統內核緩沖區拷貝到 socket 緩沖區中，這樣就減少了一次數據拷貝；

所以，這個過程之中，只進行了 2 次數據拷貝，如下圖：

這就是所謂的零拷貝（Zero-copy）技術，因為我們沒有在內存層面去拷貝數據，也就是說全程沒有通過 CPU 來搬運數據，所有的數據都是通過 DMA 來進行傳輸的。。

零拷貝技術的文件傳輸方式相比傳統文件傳輸的方式，減少了 2 次上下文切換和數據拷貝次數，只需要 2 次上下文切換和數據拷貝次數，就可以完成文件的傳輸，而且 2 次的數據拷貝過程，都不需要通過 CPU，2 次都是由 DMA 來搬運。

所以，總體來看，零拷貝技術可以把文件傳輸的性能提高至少一倍以上。

使用零拷貝技術的項目

事實上，Kafka這個開源項目，就利用了「零拷貝」技術，從而大幅提升了I/O的吞吐率，這也是Kafka在處理海量數據為什么這么快的原因之一。

如果你追溯Kafka文件傳輸的代碼，你會發現，最終它調用了Java NIO庫里的transferTo方法：

@Override
public 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 以上的版本。

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，這樣在高並發的環境下，會帶來嚴重的性能問題。

大文件傳輸用什么方式實現

繞開 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 控制器，我們要傳輸什么數據，從哪里來，到哪里去，就可以放心離開了。后續的實際數據傳輸工作，都會由 DMA 控制器來完成，CPU 不需要參與數據傳輸的工作。

傳統 IO 的工作方式，從硬盤讀取數據，然后再通過網卡向外發送，我們需要進行 4 上下文切換，和 4 次數據拷貝，其中 2 次數據拷貝發生在內存里的緩沖區和對應的硬件設備之間，這個是由 DMA 完成，另外 2 次則發生在內核態和用戶態之間，這個數據搬移工作是由 CPU 完成的。

為了提高文件傳輸的性能，於是就出現了零拷貝技術，它通過一次系統調用（sendfile 方法）合並了磁盤讀取與網絡發送兩個操作，降低了上下文切換次數。另外，拷貝數據都是發生在內核中的，天然就降低了數據拷貝的次數。

Kafka 和 Nginx 都有實現零拷貝技術，這將大大提高文件傳輸的性能。

零拷貝技術是基於 PageCache 的，PageCache 會緩存最近訪問的數據，提升了訪問緩存數據的性能，同時，為了解決機械硬盤尋址慢的問題，它還協助 I/O 調度算法實現了 IO 合並與預讀，這也是順序讀比隨機讀性能好的原因。這些優勢，進一步提升了零拷貝的性能。

需要注意的是，零拷貝技術是不允許進程對文件內容作進一步的加工的，比如壓縮數據再發送。

另外，當傳輸大文件時，不能使用零拷貝，因為可能由於 PageCache 被大文件占據，而導致「熱點」小文件無法利用到 PageCache，並且大文件的緩存命中率不高，這時就需要使用「異步 IO + 直接 IO 」的方式。

在 Nginx 里，可以通過配置，設定一個文件大小閾值，針對大文件使用異步 IO 和直接 IO，而對小文件使用零拷貝。

歡迎關注御狐神的微信公眾號

參考文檔

原來 8 張圖，就可以搞懂「零拷貝」了
linux dma拷貝數據到用戶態,圖解：零拷貝Zero-Copy技術大揭秘
內核態與用戶態、系統調用與庫函數、文件IO與標准IO、緩沖區等概念介紹

本文最先發布至微信公眾號，版權所有，禁止轉載！