① DPDK基礎知識之：零拷貝技術
很多應用程序在面臨客戶端請求時，可以等價為進行如下的系統調用：
在沒有任何優化技術使用的背景下，操作系統為此會進行4次數據拷貝，以及4次上下文切換，如下圖所示：
如果沒有優化，讀取磁碟數據，再通過網卡傳輸的場景性能比較差，在如今的應用服務中很容易就出現性能瓶頸：
4次 ：
4次上下文切換：
CPU全程負責內存內的數據拷貝還可以接受，因為效率還算可以接受，但是如果要全程負責內存與磁碟、網路的數據拷貝，這將難以接受。因為磁碟、網卡的速度遠小於內存，內存又遠遠小於CPU；4次、4次上下文切換，所以就有了IO的問題，那麼瓶頸也就出來了。
零拷貝主要的任務就是避免CPU將數據從一塊存儲拷貝到另外一塊存儲，主要就是利用各種零拷貝技術，避免讓CPU做大量的數據拷貝任務，減少不必要的拷貝，或者讓別的組件來做這一類簡單的數據傳輸任務，讓CPU解脫出來專注於別的任務。這樣就可以讓系統資源的利用更加有效。
零拷貝技術是一個思想，指的是指計算機執行操作時，CPU不需要先將數據從某處內存復制到另一個特定區域。
可見，零拷貝的特點是CPU不全程負責內存中的數據寫入其他組件，CPU僅僅起到管理的作用。但注意，零拷貝不是不進行拷貝，而是CPU不再全程負責數據拷貝時的搬運工作。如果數據本身不在內存中，那麼必須先通過某種方式拷貝到內存中（這個過程CPU可以不參與），因為數據只有在內存中，才能被轉移，才能被CPU直接讀取計算。
DMA技術很容易理解，本質上，DMA技術就是我們在主板上放一塊獨立的晶元。在進行內存和I/O設備的數據傳輸的時候，我們不再通過CPU來控制數據傳輸，而直接通過DMA控制器（DMAController，簡稱DMAC）。這塊晶元，我們可以認為它其實就是一個協處理器（Co-Processor）。
DMAC最有價值的地方體現在，當我們要傳輸的數據特別大、速度特別快，或者傳輸的數據特別小、速度特別慢的時候。
例如，我們用千兆網卡或者硬碟傳輸大量數據的時候，如果都用CPU來搬運的話，肯定忙不過來，所以可以選擇DMAC。而當數據傳輸很慢的時候，DMAC可以等數據到齊了，再發送信號，給到CPU去處理，而不是讓CPU在那裡忙等待。在DMAC控制數據傳輸的過程中，我們還是需要CPU的進行控制，但是具體數據的拷貝不再由CPU來完成。
原本，計算機所有組件之間的數據拷貝（流動）必須經過CPU，如下圖所示：
DMA代替CPU負責內存與磁碟以及內存與網卡之間的數據搬運，CPU作為DMA的控制者，如下圖所示：
但是DMA有其局限性，DMA僅僅能用於設備之間交換數據時進行數據拷貝，但是設備內部的數據拷貝還需要CPU進行，例如CPU需要負責內核空間數據與用戶空間數據之間的拷貝（內存內部的拷貝）。
UIO（UserspaceI/O）是運行在用戶空間的I/O技術。Linux系統中一般的驅動設備都是運行在內核空間，而在用戶空間用應用程序調用即可，而UIO則是將驅動的很少一部分運行在內核空間，而在用戶空間實現驅動的絕大多數功能。
一個設備驅動的主要任務有兩個：
如上圖所示，對於存取設備的內存，UIO核心實現了mmap()；對於處理設備產生的中斷，內核空間有一小部分代碼用處理中斷，用戶空間通過read()介面/dev/uioX來讀取中斷。
採用Linux提供UIO機制，可以旁路Kernel，將所有報文處理的工作在用戶空間完成。
如上圖，左邊是傳統的數據包獲取方式。
路徑為:
網卡->Kernel驅動->KernelTCP/IP協議棧->Socket介面->業務
右邊是DPDK的方式，基於UIO。
數據路徑為:
網卡->DPDK輪詢模式->DPDK基礎庫->業務
零拷貝技術的具體實現方式有很多，例如：
不同的零拷貝技術適用於不同的應用場景，下面依次進行sendfile、mmap、DirectI/O的分析。
sendfile：很多應用程序在面臨客戶端請求時，可以等價為進行如下的系統調用，sendfile一次代替read/write系統調用，通過使用DMA技術以及傳遞文件描述符，實現了零拷貝。
sendfile的應用場景是：用戶從磁碟讀取一些文件數據後不需要經過任何計算與處理就通過網路傳輸出去。此場景的典型應用是消息隊列。
在傳統I/O下，正如第一節所示，上述應用場景的一次數據傳輸需要四次CPU全程負責的拷貝與四次上下文切換。
sendfile主要使用到了兩個技術：a.利用DMA技術b.傳遞文件描述符代替數據拷貝
注意事項：只有網卡支持SG-DMA（TheScatter-GatherDirectMemoryAccess）技術才可以通過傳遞文件描述符的方式避免內核空間內的一次CPU拷貝。這意味著此優化取決於Linux系統物理網卡是否支持（Linux在內核2.4版本里引入了DMA的scatter/gather-分散/收集功能，只要確保Linux版本高於2.4即可）。
由於sendfile僅僅對應一次系統調用，而傳統文件操作則需要使用read以及write兩個系統調用。正因為如此，sendfile能夠將用戶態與內核態之間的上下文切換從4次減少到2次。
另一方面，我們需要注意sendfile系統調用的局限性。如果應用程序需要對從磁碟讀取的數據進行寫操作，例如解密或加密，那麼sendfile系統調用就完全沒法用。這是因為用戶線程根本就不能夠通過sendfile系統調用得到傳輸的數據。
mmap：以kafka為例，Kafka作為一個消息隊列，涉及到磁碟I/O主要有兩個操作：Kafka服務端接收Provider的消息並持久化的場景下使用mmap機制[6]，能夠基於順序磁碟I/O提供高效的持久化能力，使用的java類為java.nio.MappedByteBuffer。Kafka服務端向Consumer發送消息的場景下使用sendfile機制，這種機制主要有兩個好處：使用mmap對接收到的數據進行持久化，使用sendfile從持久化介質中讀取數據然後對外發送是一對常用的組合。但是注意，你無法利用sendfile來持久化數據，利用mmap實現CPU全程不參與數據搬運的數據拷貝。
DirectI/O即直接I/O。其名字中的」直接」二字用於區分使用pagecache機制的緩存I/O。這里的「直接」還有另一層語義：其它所有技術中，數據至少需要在內核空間存儲一份，但是在DirectI/O技術中，數據直接存儲在用戶空間中，繞過了內核。DirectI/O模式如下圖所示：此時用戶空間直接通過DMA的方式與磁碟以及網卡進行數據拷貝。
DirectI/O的讀寫非常有特點：
Write操作：由於其不使用pagecache，所以其進行寫文件，如果返回成功，數據就真的落盤了（不考慮磁碟自帶的緩存）；Read操作：由於其不使用pagecache，每次讀操作是真的從磁碟中讀取，不會從文件系統的緩存中讀取。事實上，即使DirectI/O還是可能需要使用操作系統的fsync系統調用。為什麼？這是因為雖然文件的數據本身沒有使用任何緩存，但是文件的元數據仍然需要緩存，包括VFS中的inodecache和dentrycache等。在部分操作系統中，在DirectI/O模式下進行write系統調用能夠確保文件數據落盤，但是文件元數據不一定落盤。如果在此類操作系統上，那麼還需要執行一次fsync系統調用確保文件元數據也落盤。否則，可能會導致文件異常、元數據確實等情況。MySQL的O_DIRECT與O_DIRECT_NO_FSYNC配置是一個具體案例。DirectI/O的優缺點：
優點：Linux中的直接I/O技術省略掉緩存I/O技術中操作系統內核緩沖區的使用，數據直接在應用程序地址空間和磁碟之間進行傳輸，從而使得自緩存應用程序可以省略掉復雜的系統級別的緩存結構，而執行程序自己定義的數據讀寫管理，從而降低系統級別的管理對應用程序訪問數據的影響。與其他零拷貝技術一樣，避免了內核空間到用戶空間的數據拷貝，如果要傳輸的數據量很大，使用直接I/O的方式進行數據傳輸，而不需要操作系統內核地址空間拷貝數據操作的參與，這將會大大提高性能。
缺點：由於設備之間的數據傳輸是通過DMA完成的，因此用戶空間的數據緩沖區內存頁必須進行pagepinning（頁鎖定），這是為了防止其物理頁框地址被交換到磁碟或者被移動到新的地址而導致DMA去拷貝數據的時候在指定的地址找不到內存頁從而引發缺頁錯誤，而頁鎖定的開銷並不比CPU拷貝小，所以為了避免頻繁的頁鎖定系統調用，應用程序必須分配和注冊一個持久的內存池，用於數據緩沖。如果訪問的數據不在應用程序緩存中，那麼每次數據都會直接從磁碟進行載入，這種直接載入會非常緩慢。在應用層引入直接I/O需要應用層自己管理，這帶來了額外的系統復雜性。
如何使用DirectI/O？用戶應用需要實現用戶空間內的緩存區，讀/寫操作應當盡量通過此緩存區提供。如果有性能上的考慮，那麼盡量避免頻繁地基於DirectI/O進行讀/寫操作。
總結：DMA技術回顧：DMA負責內存與其他組件之間的數據拷貝，CPU僅需負責管理，而無需負責全程的數據拷貝；sendfile：一次代替read/write系統調用，通過使用DMA技術以及傳遞文件描述符，實現了零拷貝。mmap：僅代替read系統調用，將內核空間地址映射為用戶空間地址，write操作直接作用於內核空間。通過DMA技術以及地址映射技術，用戶空間與內核空間無需數據拷貝，實現了零拷貝。DMA技術的推出使得內存與其他組件，例如磁碟、網卡進行數據拷貝時，CPU僅僅需要發出控制信號，而拷貝數據的過程則由DMA負責完成。Linux的零拷貝技術有多種實現策略，但根據策略可以分為如下幾種類型：減少甚至避免用戶空間和內核空間之間的數據拷貝：在一些場景下，用戶進程在數據傳輸過程中並不需要對數據進行訪問和處理，那麼數據在Linux的PageCache和用戶進程的緩沖區之間的傳輸就完全可以避免，讓數據拷貝完全在內核里進行，甚至可以通過更巧妙的方式避免在內核里的數據拷貝。這一類實現一般是是通過增加新的系統調用來完成的，比如Linux中的mmap()，sendfile()以及splice()等。繞過內核的直接I/O：允許在用戶態進程繞過內核直接和硬體進行數據傳輸，內核在傳輸過程中只負責一些管理和輔助的工作。這種方式其實和第一種有點類似，也是試圖避免用戶空間和內核空間之間的數據傳輸，只是第一種方式是把數據傳輸過程放在內核態完成，而這種方式則是直接繞過內核和硬體通信，效果類似但原理完全不同。內核緩沖區和用戶緩沖區之間的傳輸優化：這種方式側重於在用戶進程的緩沖區和操作系統頁緩存之間的CPU拷貝的優化。這種方法延續了以往那種傳統的通信方式，但更靈活。
② 一篇帶你徹底了解，零拷貝Zero-Copy技術(圖解)
零拷貝ZeroCopy技術是一種旨在優化數據傳輸效率的技術，它通過減少數據在操作系統內存和設備內存之間的拷貝操作來提高傳輸速度。以下是零拷貝技術的幾個關鍵點及實現方式：
減少不必要的拷貝：
mmap方式：
sendfile方式：
結合sendfile與DMA技術：
splice方式：
總結：零拷貝技術通過優化數據傳輸路徑和減少不必要的拷貝操作，顯著提高了數據傳輸效率。這種技術在處理大文件傳輸和網路通信等場景時表現尤為突出。
③ 零拷貝8張圖看懂零拷貝技巧
前言
磁碟可以說是計算機系統最慢的硬體之一，讀寫速度相差內存 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 搬運的。
第二次拷貝，把內核緩沖區的數據拷貝到用戶的緩沖區里，於是我們應用程序就可以使用這部分數據了，這個拷貝到過程是由 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 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-gatherscatter-gather: on於是，從 Linux 內核 2.4版本開始起，對於支持網卡支持 SG-DMA 技術的情況下， sendfile 系統調用的過程發生了點變化，具體過程如下：
第一步，通過 DMA 將磁碟上的數據拷貝到內核緩沖區里；
第二步，緩沖區描述符和數據長度傳到 socket 緩沖區，這樣網卡的 SG-DMA 控制器就可以直接將內核緩存中的數據拷貝到網卡的緩沖區里，此過程不需要將數據從操作系統內核緩沖區拷貝到 socket 緩沖區中，這樣就減少了一次數據拷貝；
所以，這個過程之中，只進行了 2 次數據拷貝，如下圖：
這就是所謂的零拷貝（Zero-）技術，因為我們沒有在內存層面去拷貝數據，也就是說全程沒有通過 CPU 來搬運數據，所有的數據都是通過 DMA 來進行傳輸的。
零拷貝技術的文件傳輸方式相比傳統文件傳輸的方式，減少了 2 次上下文切換和數據拷貝次數，只需要 2 次上下文切換和數據拷貝次數，就可以完成文件的傳輸，而且 2 次的數據拷貝過程，都不需要通過 CPU，2 次都是由 DMA 來搬運。
所以，總體來看，零拷貝技術可以把文件傳輸的性能提高至少一倍以上。
使用零拷貝技術的項目
事實上，Kafka 這個開源項目，就利用了「零拷貝」技術，從而大幅提升了 I/O 的吞吐率，這也是 Kafka 在處理海量數據為什麼這么快的原因之一。
如果你追溯 Kafka 文件傳輸的代碼，你會發現，最終它調用了 Java NIO 庫里的 transferTo方法：
@Overridepubliclong transferFrom(FileChannel fileChannel, long position, long count) throws IOException {return fileChannel.transferTo(position, count, socketChannel);}如果 Linux 系統支持 sendfile 系統調用，那麼 transferTo 實際上最後就會使用到 sendfile 系統調用函數。
曾經有大佬專門寫過程序測試過，在同樣的硬體條件下，傳統文件傳輸和零拷拷貝文件傳輸的性能差異，你可以看到下面這張測試數據圖，使用了零拷貝能夠縮短 65% 的時間，大幅度提升了機器傳輸數據的吞吐量。
數據來源於：https://developer.ibm.com/articles/j-zero/
另外，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，這樣在高並發的環境下，會帶來嚴重的性能問題。
大文件傳輸用什麼方式實現？
那針對大文件的傳輸，我們應該使用什麼方式呢？
我們先來看看最初的例子，當調用 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 控制器，我們要傳輸什麼數據，從哪裡來，到哪裡去，就可以放心離開了。後續的實際數據傳輸工作，都會由 DMA 控制器來完成，CPU 不需要參與數據傳輸的工作。
傳統 IO 的工作方式，從硬碟讀取數據，然後再通過網卡向外發送，我們需要進行 4 上下文切換，和 4 次數據拷貝，其中 2 次數據拷貝發生在內存里的緩沖區和對應的硬體設備之間，這個是由 DMA 完成，另外 2 次則發生在內核態和用戶態之間，這個數據搬移工作是由 CPU 完成的。
為了提高文件傳輸的性能，於是就出現了零拷貝技術，它通過一次系統調用（sendfile 方法）合並了磁碟讀取與網路發送兩個操作，降低了上下文切換次數。另外，拷貝數據都是發生在內核中的，天然就降低了數據拷貝的次數。
Kafka 和 Nginx 都有實現零拷貝技術，這將大大提高文件傳輸的性能。
零拷貝技術是基於 PageCache 的，PageCache 會緩存最近訪問的數據，提升了訪問緩存數據的性能，同時，為了解決機械硬碟定址慢的問題，它還協助 I/O 調度演算法實現了 IO 合並與預讀，這也是順序讀比隨機讀性能好的原因。這些優勢，進一步提升了零拷貝的性能。
需要注意的是，零拷貝技術是不允許進程對文件內容作進一步的加工的，比如壓縮數據再發送。
另外，當傳輸大文件時，不能使用零拷貝，因為可能由於 PageCache 被大文件占據，而導致「熱點」小文件無法利用到 PageCache，並且大文件的緩存命中率不高，這時就需要使用「非同步 IO 直接 IO 」的方式。
在 Nginx 里，可以通過配置，設定一個文件大小閾值，針對大文件使用非同步 IO 和直接 IO，而對小文件使用零拷貝。