一般會如何實現文件傳輸？

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

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

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

上下文切換：

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

上下文切換的成本并不小，雖然一次切換僅消耗幾十納秒到幾微秒，但高并發服務會放大這類時間的消耗。

內存拷貝:

其次，這個方案做了 4 萬次內存拷貝，對 320MB 文件拷貝的字節數也翻了 4 倍，到了 1280MB。很顯然，過多的內存拷貝無謂地消耗了 CPU 資源，降低了系統的并發處理能力。

所以要想提升傳輸文件的性能，需要從降低上下文切換的頻率和內存拷貝次數兩個方向入手。

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

首先，我們來看如何降低上下文切換的頻率。

為什么讀取磁盤文件時，一定要做上下文切換呢？這是因為，讀取磁盤或者操作網卡都由操作系統內核完成。內核負責管理系統上的所有進程，它的權限最高，工作環境與用戶進程完全不同。只要我們的代碼執行 read 或者 write 這樣的系統調用，一定會發生 2 次上下文切換：首先從用戶態切換到內核態，當內核執行完任務后，再切換回用戶態交由進程代碼執行。

因此，如果想減少上下文切換次數，就一定要減少系統調用的次數。解決方案就是把 read、write 兩次系統調用合并成一次，在內核中完成磁盤與網卡的數據交換。

其次，我們應該考慮如何減少內存拷貝次數。

每周期中的 4 次內存拷貝，其中與物理設備相關的 2 次拷貝是必不可少的，包括：把磁盤內容拷貝到內存，以及把內存拷貝到網卡。但另外 2 次與用戶緩沖區相關的拷貝動作都不是必需的，因為在把磁盤文件發到網絡的場景中，用戶緩沖區沒有必須存在的理由。

如果內核在讀取文件后，直接把 PageCache 中的內容拷貝到 Socket 緩沖區，待到網卡發送完畢后，再通知進程，這樣就只有 2 次上下文切換，和 3 次內存拷貝。

如果網卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術，還可以再去除 Socket 緩沖區的拷貝，這樣一共只有 2 次內存拷貝。

實際上，這就是零拷貝技術。

它是操作系統提供的新函數，同時接收文件描述符和 TCP socket 作為輸入參數，這樣執行時就可以不需要用戶層緩存，完全在內核態完成內存拷貝，既減少了內存拷貝次數，也降低了上下文切換次數。

而且，零拷貝取消了用戶緩沖區后，不只降低了用戶內存的消耗，還通過最大化利用 socket 緩沖區中的內存，間接地再一次減少了系統調用的次數，從而帶來了大幅減少上下文切換次數的機會！

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

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

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

綜合上述各種優點，零拷貝可以把性能提升至少一倍以上！對文章開頭提到的 320MB 文件的傳輸，當 socket 緩沖區在 1.4MB 左右時，只需要 4 百多次上下文切換，以及 4 百多次內存拷貝，拷貝的數據量也僅有 640MB，這樣，不只請求時延會降低，處理每個請求消耗的 CPU 資源也會更少，從而支持更多的并發請求。

此外，零拷貝還使用了 PageCache 技術，通過它，零拷貝可以進一步提升性能，我們接下來看看 PageCache 是如何做到這一點的。

PageCache，磁盤高速緩存

回顧上文中的幾張圖，你會發現，讀取文件時，是先把磁盤文件拷貝到 PageCache 上，再拷貝到進程中。為什么這樣做呢？有兩個原因所致。

第一，由于磁盤比內存的速度慢許多，所以我們應該想辦法把讀寫磁盤替換成讀寫內存，比如把磁盤中的數據復制到內存中，就可以用讀內存替換讀磁盤。但是，內存空間遠比磁盤要小，內存中注定只能復制一小部分磁盤中的數據。

選擇哪些數據復制到內存呢？通常，剛被訪問的數據在短時間內再次被訪問的概率很高（這也叫“時間局部性”原理），用 PageCache 緩存最近訪問的數據，當空間不足時淘汰最久未被訪問的緩存（即 LRU 算法）。讀磁盤時優先到 PageCache 中找一找，如果數據存在便直接返回，這便大大提升了讀磁盤的性能。

第二，讀取磁盤數據時，需要先找到數據所在的位置，對于機械磁盤來說，就是旋轉磁頭到數據所在的扇區，再開始順序讀取數據。其中，旋轉磁頭耗時很長，為了降低它的影響，PageCache 使用了預讀功能。

也就是說，雖然 read 方法只讀取了 0-32KB 的字節，但內核會把其后的 32-64KB 也讀取到 PageCache，這后 32KB 讀取的成本很低。如果在 32-64KB 淘汰出 PageCache 前，進程讀取到它了，收益就非常大。這一講的傳輸文件場景中這是必然發生的。

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

具體是什么場景呢？就是在傳輸大文件的時候。比如，你有很多 GB 級的文件需要傳輸，每當用戶訪問這些大文件時，內核就會把它們載入到 PageCache 中，這些大文件很快會把有限的 PageCache 占滿。

然而，由于文件太大，文件中某一部分內容被再次訪問到的概率其實非常低。這帶來了 2 個問題：首先，由于 PageCache 長期被大文件占據，熱點小文件就無法充分使用 PageCache，它們讀起來變慢了；其次，PageCache 中的大文件沒有享受到緩存的好處，但卻耗費 CPU 多拷貝到 PageCache 一次。

所以，高并發場景下，為了防止 PageCache 被大文件占滿后不再對小文件產生作用，大文件不應使用 PageCache，進而也不應使用零拷貝技術處理。

異步 IO + 直接 IO

高并發場景處理大文件時，應當使用異步 IO 和直接 IO 來替換零拷貝技術。

仍然回到本講開頭的例子，當調用 read 方法讀取文件時，實際上 read 方法會在磁盤尋址過程中阻塞等待，導致進程無法并發地處理其他任務，如下圖所示：

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

從圖中可以看到，異步 IO 并沒有拷貝到 PageCache 中，這其實是異步 IO 實現上的缺陷。經過 PageCache 的 IO 我們稱為緩存 IO，它與虛擬內存系統耦合太緊，導致異步 IO 從誕生起到現在都不支持緩存 IO。

繞過 PageCache 的 IO 是個新物種，我們把它稱為直接 IO。對于磁盤，異步 IO 只支持直接 IO。

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

當然，直接 IO 也有一定的缺點。除了緩存外，內核（IO 調度算法）會試圖緩存盡量多的連續 IO 在 PageCache 中，最后合并成一個更大的 IO 再發給磁盤，這樣可以減少磁盤的尋址操作；另外，內核也會預讀后續的 IO 放在 PageCache 中，減少磁盤操作。直接 IO 繞過了 PageCache，所以無法享受這些性能提升。

有了直接 IO 后，異步 IO 就可以無阻塞地讀取文件了。現在，大文件由異步 IO 和直接 IO 處理，小文件則交由零拷貝處理，至于判斷文件大小的閾值可以靈活配置（參見 Nginx 的 directio 指令）。

?