如何實現(xiàn)文件傳輸

你會如何實現(xiàn)文件傳輸？

服務器提供文件傳輸功能，需要將磁盤上的文件讀取出來，通過網(wǎng)絡協(xié)議發(fā)送到客戶端。如果需要你自己編碼實現(xiàn)這個文件傳輸功能，你會怎么實現(xiàn)呢？

通常，你會選擇最直接的方法：從網(wǎng)絡請求中找出文件在磁盤中的路徑后，如果這個文件比較大，假設有 320MB，可以在內(nèi)存中分配 32KB 的緩沖區(qū)，再把文件分成一萬份，每份只有 32KB，這樣，從文件的起始位置讀入 32KB 到緩沖區(qū)，再通過網(wǎng)絡 API 把這 32KB 發(fā)送到客戶端。接著重復一萬次，直到把完整的文件都發(fā)送完畢。如下圖所示：

不過這個方案性能并不好，主要有兩個原因。

首先，它至少經(jīng)歷了 4 萬次 用戶態(tài)與內(nèi)核態(tài)的上下文切換 。因為 每處理 32KB 的消息，就需要一次 read 調(diào)用和一次 write 調(diào)用 ，每次系統(tǒng)調(diào)用****都得先從用戶態(tài)切換到內(nèi)核態(tài)，等內(nèi)核完成任務后，再從內(nèi)核態(tài)切換回用戶態(tài) 。可見，每處理 32KB，就有 4 次上下文切換，重復 1 萬次后就有 4 萬次切換。

這個系統(tǒng)調(diào)用的內(nèi)容，我們可以結合下面補充的三種“ 上下文切換 ”來理解，上下文切換分別是進程，線程，中斷三種。### 補充：進程上下文切換

Linux 按照特權等級，把 進程的運行空間分為內(nèi)核空間和用戶空間 ，分別對應著下圖中， CPU 特權等級的 Ring 0 和 Ring 3 。內(nèi)核空間（Ring 0）具有最高權限，可以直接訪問所有資源，而用戶空間（Ring 3）只能訪問受限資源， 不能直接訪問內(nèi)存等硬件設備，必須通過系統(tǒng)調(diào)用陷入到內(nèi)核中 ，才能訪問這些特權資源。

換個角度看，也就是說，進程既可以在用戶空間運行，又可以在內(nèi)核空間中運行。 進程在用戶空間運行時，被稱為進程的用戶態(tài)，而陷入內(nèi)核空間的時候，被稱為進程的內(nèi)核態(tài) 。從用戶態(tài)到內(nèi)核態(tài)的轉變，需要通過系統(tǒng)調(diào)用來完成。比如，當我們查看文件內(nèi)容時，就需要多次系統(tǒng)調(diào)用來完成：首先調(diào)用 open() 打開文件，然后調(diào)用 read() 讀取文件內(nèi)容，并調(diào)用 write() 將內(nèi)容寫到標準輸出，最后再調(diào)用 close() 關閉文件。

那么系統(tǒng)調(diào)用的過程是如何發(fā)生 CPU 上下文的切換的呢？我們再了解兩個概念：1. CPU 寄存器 ，是 CPU 內(nèi)置的容量小、但速度極快的內(nèi)存 。

1. 程序計數(shù)器 ，則是用來 存儲 CPU 正在執(zhí)行的指令位置 、 或者即將執(zhí)行的下一條指令位置 。它們都是 CPU 在 運行任何任務前，必須的依賴環(huán)境 ，因此也被叫做 CPU 上下文 。

知道了什么是 CPU 上下文，我想你也很容易理解 CPU 上下文切換。 CPU 上下文切換 ，就是先把前一個任務的 CPU 上下文（也就是 CPU 寄存器和程序計數(shù)器）保存起來，然后加載新任務的上下文到這些寄存器和程序計數(shù)器，最后再跳轉到程序計數(shù)器所指的新位置，運行新任務。而這些 保存下來的上下文，會存儲在系統(tǒng)內(nèi)核中，并在任務重新調(diào)度執(zhí)行時再次加載進來。這樣就能保證任務原來的狀態(tài)不受影響，讓任務看起來還是連續(xù)運行 。

回到系統(tǒng)調(diào)用的問題上，CPU 寄存器里原來 用戶態(tài)的指令位置，需要先保存起來 。接著，為了執(zhí)行內(nèi)核態(tài)代碼，CPU 寄存器需要 更新為內(nèi)核態(tài)指令的新位置。最后才是跳轉到內(nèi)核態(tài)運行內(nèi)核任務。 而系統(tǒng)調(diào)用結束后，CPU 寄存器需要 恢復原來保存的用戶態(tài) ，然后再切換到用戶空間，繼續(xù)運行進程。所以，一次系統(tǒng)調(diào)用的過程，其實是發(fā)生了兩次 CPU 上下文切換。

不過，需要注意的是，系統(tǒng)調(diào)用過程中，并不會涉及到虛擬內(nèi)存等進程用戶態(tài)的資源，也不會切換進程。這跟我們通常所說的進程上下文切換是不一樣的：

1. 進程上下文切換，是指從一個進程切換到另一個進程運行。
2. 系統(tǒng)調(diào)用過程中一直是同一個進程在運行。

那么，進程上下文切換跟系統(tǒng)調(diào)用又有什么區(qū)別呢？首先，你需要知道， 進程是由內(nèi)核來管理和調(diào)度的，進程的切換只能發(fā)生在內(nèi)核態(tài) 。所以，進程的上下文不僅包括了虛擬內(nèi)存、棧、全局變量等用戶空間的資源，還包括了內(nèi)核堆棧、寄存器等內(nèi)核空間的狀態(tài)。因此，進程的上下文切換就比系統(tǒng)調(diào)用時多了一步：在保存當前進程的內(nèi)核狀態(tài)和 CPU 寄存器之前， 需要先把該進程的虛擬內(nèi)存、棧等保存下來；而加載了下一進程的內(nèi)核態(tài)后，還需要刷新進程的虛擬內(nèi)存和用戶棧 。

保存上下文和恢復上下文的過程并不是“免費”的，需要內(nèi)核在 CPU 上運行才能完成。

每次上下文切換都需要幾十納秒到數(shù)微秒的 CPU 時間。這個時間還是相當可觀的，特別是在進程上下文切換次數(shù)較多的情況下，很容易導致 CPU 將大量時間耗費在寄存器、內(nèi)核棧以及虛擬內(nèi)存等資源的保存和恢復上，進而大大縮短了真正運行進程的時間。Linux 通過 TLB（Translation Lookaside Buffer）來管理虛擬內(nèi)存到物理內(nèi)存的映射關系。當虛擬內(nèi)存更新后，TLB 也需要刷新，內(nèi)存的訪問也會隨之變慢。特別是在多處理器系統(tǒng)上，緩存是被多個處理器共享的，刷新緩存不僅會影響當前處理器的進程，還會影響共享緩存的其他處理器的進程。

TLB，這個東西的資料比較晦澀難懂，我大致搜了一下，非常多的專業(yè)術語，不太建議大家展開了，等到我們真的要用上的時候，再去了解也不晚，大致內(nèi)容我覺得如果要展開，那就展開我下面的這個部分就已經(jīng)足夠了。

TLB是一種高速緩存，內(nèi)存管理硬件使用它來改善虛擬地址到物理地址的轉換速度。當前所有的個人桌面，筆記本和服務器處理器都使用TLB來進行 虛擬地址到物理地址的映射 。使用TLB內(nèi)核可以快速的找到虛擬地址指向物理地址，而不需要請求RAM內(nèi)存獲取虛擬地址到物理地址的映射關系。

虛擬地址和物理地址的話，大致是這么理解的。每個進程都有自己獨立的4G內(nèi)存空間，各個進程的內(nèi)存空間具有類似的結構。一個新進程建立的時候，將會建立起自己的內(nèi)存空間，此進程的數(shù)據(jù)，代碼等從磁盤拷貝到自己的進程空間，哪些數(shù)據(jù)在哪里，都由進程控制表中的task_struct記錄，它會有一條鏈表，記錄中內(nèi)存空間的分配情況，哪些地址有數(shù)據(jù)，哪些地址無數(shù)據(jù)，哪些可讀，哪些可寫，都可以通過這個鏈表記錄。每個進程已經(jīng)分配的內(nèi)存空間，都與對應的磁盤空間映射

可是計算機明明沒有那么多內(nèi)存（n個進程的話就需要n*4G）內(nèi)存。還有建立一個進程，就要把磁盤上的程序文件拷貝到進程對應的內(nèi)存中去，對于一個程序對應的多個進程這種情況是根本不需要這樣操作的。

所以，每個進程的4G內(nèi)存空間只是 虛擬內(nèi)存空間 ，每次 訪問內(nèi)存空間的某個地址，都需要把地址翻譯為實際物理內(nèi)存地址 。 所有進程共享同一物理內(nèi)存 ，每個進程只把自己目前需要的虛擬內(nèi)存空間映射并存儲到物理內(nèi)存上。進程要知道哪些內(nèi)存地址上的數(shù)據(jù)在物理內(nèi)存上，哪些不在，還有在物理內(nèi)存上的哪里，需要用頁表來記錄。頁表的每一個表項分兩部分，第一部分記錄 此頁是否在物理內(nèi)存上 ，第二部分記錄 物理內(nèi)存頁的地址 （如果在的話）。當進程訪問某個虛擬地址，去看頁表，如果發(fā)現(xiàn)對應的數(shù)據(jù)不在物理內(nèi)存中，則缺頁異常。缺頁異常的處理過程，就是把進程需要的數(shù)據(jù)從磁盤上拷貝到物理內(nèi)存中。

知道了進程上下文切換潛在的性能問題后，我們再來看，究竟什么時候會切換進程上下文。顯然，只有在進程調(diào)度的時候，才需要切換上下文。Linux 為每個 CPU 都維護了一個就緒隊列，將活躍進程（即正在運行和正在等待 CPU 的進程）按照優(yōu)先級和等待 CPU 的時間排序，然后選擇最需要 CPU 的進程，也就是優(yōu)先級最高和等待 CPU 時間最長的進程來運行。

那么，進程在什么時候才會被調(diào)度到 CPU 上運行呢？最容易想到的一個時機，就是進程執(zhí)行完終止了，它之前使用的 CPU 會釋放出來，這個時候再從就緒隊列里，拿一個新的進程過來運行。其實還有很多其他場景，也會觸發(fā)進程調(diào)度，在這里我給你逐個梳理下。

其一，為了保證所有進程可以得到 公平調(diào)度 ，CPU 時間被劃分為一段段的時間片，這些 時間片再被輪流分配給各個進程 。這樣，當某個進程的時間片耗盡了，就會被系統(tǒng)掛起，切換到其它正在等待 CPU 的進程運行。
其二，進程在 系統(tǒng)資源不足 （比如內(nèi)存不足）時，要等到資源滿足后才可以運行，這個時候進程也會被掛起，并由系統(tǒng)調(diào)度其他進程運行。
其三，當進程通過 sleep 這樣的方法 將自己主動掛起時 ，自然也會重新調(diào)度。
其四，當有優(yōu)先級更高的進程運行時，為了保證高優(yōu)先級進程的運行，當前進程會被掛起，由高優(yōu)先級進程來運行。
最后一個，發(fā)生硬件中斷時，CPU 上的進程會被中斷掛起，轉而執(zhí)行內(nèi)核中的中斷服務程序。

線程上下文切換

線程與進程最大的區(qū)別在于， 線程是調(diào)度的基本單位，而進程則是資源擁有的基本單位 。說白了，所謂內(nèi)核中的任務調(diào)度，實際上的 調(diào)度對象是線程 ；而進程只是給線程 提供了虛擬內(nèi)存、全局變量等資源 。所以，對于線程和進程，我們可以這么理解：

1. 當進程只有一個線程時，可以認為進程就等于線程。
2. 當進程擁有多個線程時，這些線程會共享相同的虛擬內(nèi)存和全局變量等資源。這些資源在上下文切換時是不需要修改的。
3. 另外，線程也有自己的私有數(shù)據(jù)，比如棧和寄存器等，這些在上下文切換時也是需要保存的。

這么一來，線程的上下文切換其實就可以分為兩種情況：

第一種， 前后兩個線程屬于不同進程。此時，因為資源不共享，所以切換過程就跟進程上下文切換是一樣。

第二種，前后兩個線程屬于同一個進程。此時，因為虛擬內(nèi)存是共享的，所以在切換時， 虛擬內(nèi)存這些資源就保持不動，只需要切換線程的私有數(shù)據(jù)、寄存器等不共享的數(shù)據(jù) 。到這里你應該也發(fā)現(xiàn)了，雖然同為上下文切換，但同進程內(nèi)的線程切換，要比多進程間的切換消耗更少的資源，而這，也正是多線程代替多進程的一個優(yōu)勢。

中斷上下文切換

一個場景也會切換 CPU 上下文，那就是中斷。為了快速響應硬件的事件，中斷處理會打斷進程的正常調(diào)度和執(zhí)行，轉而調(diào)用中斷處理程序，響應設備事件。而在打斷其他進程時，就需要將進程當前的狀態(tài)保存下來，這樣在中斷結束后，進程仍然可以從原來的狀態(tài)恢復運行。

跟進程上下文不同，中斷上下文切換并不涉及到進程的用戶態(tài)。所以，即便中斷過程打斷了一個正處在用戶態(tài)的進程，也不需要保存和恢復這個進程的虛擬內(nèi)存、全局變量等用戶態(tài)資源。中斷上下文，其實只包括內(nèi)核態(tài)中斷服務程序執(zhí)行所必需的狀態(tài)，包括 CPU 寄存器、內(nèi)核堆棧、硬件中斷參數(shù)等。對同一個 CPU 來說，中斷處理比進程擁有更高的優(yōu)先級，所以中斷上下文切換并不會與進程上下文切換同時發(fā)生。

同樣道理，由于中斷會打斷正常進程的調(diào)度和執(zhí)行，所以大部分中斷處理程序都短小精悍，以便盡可能快的執(zhí)行結束。另外，跟進程上下文切換一樣，中斷上下文切換也需要消耗 CPU，切換次數(shù)過多也會耗費大量的 CPU，嚴重降低系統(tǒng)的整體性能。

總結一下，CPU 上下文切換，是保證 Linux 系統(tǒng)正常工作的核心功能之一，一般情況下不需要我們特別關注。但過多的上下文切換，會把 CPU 時間消耗在寄存器、內(nèi)核棧以及虛擬內(nèi)存等數(shù)據(jù)的保存和恢復上，從而縮短進程真正運行的時間，導致系統(tǒng)的整體性能大幅下降。

回到零拷貝的事兒上

剛剛我們的場景，每處理 32KB，就有 4 次上下文切換，重復 1 萬次后就有 4 萬次切換。上下文切換的成本并不小，雖然一次切換僅消耗幾十納秒到幾微秒，但高并發(fā)服務就會放大這類時間的消耗。其次，這個方案做了 4 萬次內(nèi)存拷貝，對 320MB 文件拷貝的字節(jié)數(shù)也翻了 4 倍，到了 1280MB。很顯然，過多的內(nèi)存拷貝無謂地消耗了 CPU 資源，降低了系統(tǒng)的并發(fā)處理能力。所以要想提升傳輸文件的性能，需要從降低上下文切換的頻率和內(nèi)存拷貝次數(shù)兩個方向入手。

零拷貝如何提升文件傳輸性能？

再提一句，為什么讀取磁盤文件時，一定要做上下文切換呢？這是因為， 讀取磁盤或者操作網(wǎng)卡都由操作系統(tǒng)內(nèi)核完成 。 內(nèi)核負責管理系統(tǒng)上的所有進程 ，它的權限最高，工作環(huán)境與用戶進程完全不同。只要我們的代碼執(zhí)行 read 或者 write 這樣的系統(tǒng)調(diào)用，一定會發(fā)生 2 次上下文切換： 首先從用戶態(tài)切換到內(nèi)核態(tài)，當內(nèi)核執(zhí)行完任務后，再切換回用戶態(tài)交由進程代碼執(zhí)行 。因此，如果想減少上下文切換次數(shù)，就一定要減少系統(tǒng)調(diào)用的次數(shù)。解決方案就是把 read、write 兩次系統(tǒng)調(diào)用合并成一次，在內(nèi)核中完成磁盤與網(wǎng)卡的數(shù)據(jù)交換。

其次，我們應該考慮如何減少內(nèi)存拷貝次數(shù)。每周期中的 4 次內(nèi)存拷貝，其中與物理設備相關的 2 次拷貝是必不可少的，包括： 把磁盤內(nèi)容拷貝到內(nèi)存，以及把內(nèi)存拷貝到網(wǎng)卡 。但另外 2 次與用戶緩沖區(qū)相關的拷貝動作都不是必需的，因為在把磁盤文件發(fā)到網(wǎng)絡的場景中，用戶緩沖區(qū)沒有必須存在的理由。如果內(nèi)核在讀取文件后， 直接把 PageCache 中的內(nèi)容拷貝到 Socket 緩沖區(qū) ，待到網(wǎng)卡發(fā)送完畢后，再通知進程，這樣就只有 2 次上下文切換，和 3 次內(nèi)存拷貝。

如果網(wǎng)卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術，還可以再去除 Socket 緩沖區(qū)的拷貝，這樣一共只有 2 次內(nèi)存拷貝。在DMA傳輸數(shù)據(jù)的過程中，要求源物理地址和目標物理地址必須是連續(xù)的。可是連續(xù)的存儲器地址在物理上不一定是連續(xù)的，所以DMA傳輸要分成多次完成。如果在傳輸完一塊物理上連續(xù)的數(shù)據(jù)后引起一次中斷，然后再由主機進行下一塊物理上連續(xù)的數(shù)據(jù)傳輸。Scatter-gather DMA方式則不同，它使用一個鏈表描述物理上不連續(xù)的存儲空間，然后把鏈表首地址告訴DMA master。DMA master在傳輸完一塊物理連續(xù)的數(shù)據(jù)后，不用發(fā)起中斷，而是根據(jù)鏈表來傳輸下一塊物理上連續(xù)的數(shù)據(jù)，直到傳輸完畢后再發(fā)起一次中斷。

實際上，這就是零拷貝技術。它是操作系統(tǒng)提供的新函數(shù)，同時接收文件描述符和 TCP socket 作為輸入?yún)?shù)，這樣 執(zhí)行時就可以完全在內(nèi)核態(tài)完成內(nèi)存拷貝，既減少了內(nèi)存拷貝次數(shù)，也降低了上下文切換次數(shù) 。而且，零拷貝取消了用戶緩沖區(qū)后，不只降低了用戶內(nèi)存的消耗，還通過 最大化利用 socket 緩沖區(qū)中的內(nèi)存，間接地再一次減少了系統(tǒng)調(diào)用的次數(shù) ，從而帶來了大幅減少上下文切換次數(shù)的機會

你可以回憶下，沒用零拷貝時，為了傳輸 320MB 的文件，在用戶緩沖區(qū)分配了 32KB 的內(nèi)存，把文件分成 1 萬份傳送，然而，這 32KB 是怎么來的？為什么不是 32MB 或者 32 字節(jié)呢？這是因為，在沒有零拷貝的情況下，我們希望內(nèi)存的利用率最高。 如果用戶緩沖區(qū)過大，它就無法一次性把消息全拷貝給 socket 緩沖區(qū) （這里是socket的大小有所限制）；如果用戶緩沖區(qū)過小，則會導致過多的 read/write 系統(tǒng)調(diào)用 。

那用戶緩沖區(qū)為什么不與 socket 緩沖區(qū)大小一致呢？這是因為， socket 緩沖區(qū)的可用空間是動態(tài)變化的 ，它既用于 TCP 滑動窗口，也用于應用緩沖區(qū)，還受到整個系統(tǒng)內(nèi)存的影響。尤其在長肥網(wǎng)絡中，它的變化范圍特別大。

零拷貝使我們不必關心 socket 緩沖區(qū)的大小。比如，調(diào)用零拷貝發(fā)送方法時， 盡可以把發(fā)送字節(jié)數(shù)設為文件的所有未發(fā)送字節(jié)數(shù) ，例如 320MB，也許此時 socket 緩沖區(qū)大小為 1.4MB，那么一次性就會發(fā)送 1.4MB 到客戶端，而不是只有 32KB。這意味著對于 1.4MB 的 1 次零拷貝，僅帶來 2 次上下文切換，而不使用零拷貝且用戶緩沖區(qū)為 32KB 時，經(jīng)歷了 176 次（4 * 1.4MB/32KB）上下文切換。

綜合上述，對文章開頭提到的 320MB 文件的傳輸，當 socket 緩沖區(qū)在 1.4MB 左右時，只需要 4 百多次上下文切換，以及 4 百多次內(nèi)存拷貝，拷貝的數(shù)據(jù)量也僅有 640MB，這樣，不只請求時延會降低，處理每個請求消耗的 CPU 資源也會更少，從而支持更多的并發(fā)請求。

此外，零拷貝還使用了 PageCache 技術。### PageCache，磁盤高速緩存

回顧上文中，你會發(fā)現(xiàn)，讀取文件時，是先把磁盤文件拷貝到 PageCache 上，再拷貝到進程中。為什么這樣做呢？有兩個原因所致。

由于磁盤比內(nèi)存的速度慢許多，所以我們應該想辦法把 讀寫磁盤替換成讀寫內(nèi)存 ，比如把磁盤中的數(shù)據(jù)復制到內(nèi)存中，就可以用讀內(nèi)存替換讀磁盤。但是，內(nèi)存空間遠比磁盤要小，內(nèi)存中注定只能復制一小部分磁盤中的數(shù)據(jù)。通常，剛被訪問的數(shù)據(jù)在短時間內(nèi)再次被訪問的概率很高。用 PageCache 緩存最近訪問的數(shù)據(jù)，當空間不足時 淘汰最久未被訪問的緩存 （即 LRU 算法）。 讀磁盤時優(yōu)先到 PageCache 中找一找 ，如果數(shù)據(jù) 存在便直接返回 ，這便大大提升了讀磁盤的性能。

而且讀取磁盤數(shù)據(jù)時，需要先找到數(shù)據(jù)所在的位置，對于機械磁盤來說，就是旋轉磁頭到數(shù)據(jù)所在的扇區(qū)，再開始順序讀取數(shù)據(jù)。其中，旋轉磁頭耗時很長，為了降低它的影響，PageCache 使用了預讀功能。也就是說，雖然 read 方法只讀取了 0-32KB 的字節(jié)，但內(nèi)核會把其后的 32-64KB 也讀取到 PageCache，這后 32KB 讀取的成本很低。如果在 32-64KB 淘汰出 PageCache 前，進程讀取到它了，收益就非常大。這一講的傳輸文件場景中這是必然發(fā)生的。

綜上可以看到 PageCache 的優(yōu)點，它在 90% 以上場景下都會提升磁盤性能，但在某些情況下，PageCache 會不起作用，甚至由于多做了一次內(nèi)存拷貝，造成性能的降低。在這些場景中，使用了 PageCache 的零拷貝也會損失性能。

具體就是在傳輸大文件的時候。比如，你有很多 GB 級的文件需要傳輸，每當用戶訪問這些大文件時，內(nèi)核就會把它們載入到 PageCache 中，這些大文件很快會把有限的 PageCache 占滿。然而，由于文件太大， 文件中某一部分內(nèi)容被再次訪問到的概率其實非常低 。這帶來了 2 個問題：首先，由于 PageCache 長期被大文件占據(jù)， 熱點小文件就無法充分使用 PageCache，它們讀起來變慢了 ；其次， PageCache 中的大文件沒有享受到緩存的好處，但卻耗費 CPU 多拷貝到 PageCache 一次 。所以，高并發(fā)場景下，為了防止 PageCache 被大文件占滿后不再對小文件產(chǎn)生作用， 大文件不應使用 PageCache，進而也不應使用零拷貝技術處理。 用看電影來舉例的話，就是我只想看前10分鐘，就要把整部都下下來，這明顯是虧的。而高并發(fā)場景處理大文件時，應當使用異步 IO 和直接 IO 來替換零拷貝技術。

異步 IO + 直接 IO

回到開頭的例子，當調(diào)用 read 方法讀取文件時，實際上 read 方法會在磁盤尋址過程中阻塞等待，導致進程無法并發(fā)地處理其他任務，如下圖所示：也就是在拉數(shù)據(jù)的過程中，一整個流程下來進程都是阻塞的意思。

異步 IO（異步 IO 既可以處理網(wǎng)絡 IO，也可以處理磁盤 IO，這里我們只關注磁盤 IO）可以解決阻塞問題。它把讀操作分為兩部分，前半部分 向內(nèi)核發(fā)起讀請求，但不等待數(shù)據(jù)就位就立刻返回，此時進程可以并發(fā)地處理其他任務 。當 內(nèi)核將磁盤中的數(shù)據(jù)拷貝到進程緩沖區(qū)后，進程將接收到內(nèi)核的通知，再去處理數(shù)據(jù) ，這是異步 IO 的后半部分。如下圖所示：

從圖中可以看到，異步 IO 并沒有拷貝到 PageCache 中，這其實是異步 IO 實現(xiàn)上的缺陷。 經(jīng)過 PageCache 的 IO 我們稱為緩存 IO ，它與虛擬內(nèi)存系統(tǒng)耦合太緊，導致異步 IO 從誕生起到現(xiàn)在都不支持緩存 IO。繞過 PageCache 的 IO 是個新物種，我們把它稱為直接 IO。對于磁盤，異步 IO 只支持直接 IO。

直接 IO 的應用場景并不多，主要有兩種：第一，應用程序已經(jīng)實現(xiàn)了磁盤文件的緩存，不需要 PageCache 再次緩存，引發(fā)額外的性能消耗。比如 MySQL 等數(shù)據(jù)庫就使用直接 IO；第二，高并發(fā)下傳輸大文件，我們上文提到過，大文件難以命中 PageCache 緩存，又帶來額外的內(nèi)存拷貝，同時還擠占了小文件使用 PageCache 時需要的內(nèi)存，因此，這時應該使用直接 IO。

直接 IO 的缺點就是無法享受 PageCache 的好處，也就是內(nèi)核（IO 調(diào)度算法）會試圖緩存盡量多的連續(xù) IO 在 PageCache 中，最后合并成一個更大的 IO 再發(fā)給磁盤，這樣可以減少磁盤的尋址操作；另外，內(nèi)核也會預讀后續(xù)的 IO 放在 PageCache 中，減少磁盤操作。這些它都是做不到的### 小結

基于用戶緩沖區(qū)傳輸文件時，過多的內(nèi)存拷貝與上下文切換次數(shù)會降低性能。零拷貝技術在內(nèi)核中完成內(nèi)存拷貝，天然降低了內(nèi)存拷貝次數(shù)。它通過一次系統(tǒng)調(diào)用合并了磁盤讀取與網(wǎng)絡發(fā)送兩個操作，降低了上下文切換次數(shù)。尤其是，由于拷貝在內(nèi)核中完成，它可以最大化使用 socket 緩沖區(qū)的可用空間，從而提高了一次系統(tǒng)調(diào)用中處理的數(shù)據(jù)量，進一步降低了上下文切換次數(shù)。

零拷貝技術基于 PageCache，而 PageCache 緩存了最近訪問過的數(shù)據(jù)，提升了訪問緩存數(shù)據(jù)的性能，同時，為了解決機械磁盤尋址慢的問題，它還協(xié)助 IO 調(diào)度算法實現(xiàn)了 IO 合并與預讀（這也是順序讀比隨機讀性能好的原因），這進一步提升了零拷貝的性能。幾乎所有操作系統(tǒng)都支持零拷貝，如果應用場景就是把文件發(fā)送到網(wǎng)絡中，那么零拷貝確實是個好方法。

Tips：其實這里如果是使用SSD這類固態(tài)硬盤（不用旋轉磁頭），PageCache就沒有很大的影響，細節(jié)請參照我上一篇的那個SSD的文

不過，零拷貝有一個缺點，就是不允許進程對文件內(nèi)容作一些加工再發(fā)送，比如數(shù)據(jù)壓縮后再發(fā)送。另外，當 PageCache 引發(fā)負作用時，也不能使用零拷貝，此時可以用異步 IO+ 直接 IO 替換。我們 通常會設定一個文件大小閾值，針對大文件使用異步 IO 和直接 IO，而對小文件使用零拷貝 。