一般會如何實現(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 萬次切換。

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

內(nèi)存拷貝:

其次，這個方案做了 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)存拷貝。

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

它是操作系統(tǒng)提供的新函數(shù)，同時接收文件描述符和 TCP socket 作為輸入參數(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ū)；如果用戶緩沖區(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）上下文切換。

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

此外，零拷貝還使用了 PageCache 技術，通過它，零拷貝可以進一步提升性能，我們接下來看看 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)存呢？通常，剛被訪問的數(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，進而也不應使用零拷貝技術處理。

異步 IO + 直接 IO

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

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

異步 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 也有一定的缺點。除了緩存外，內(nèi)核（IO 調(diào)度算法）會試圖緩存盡量多的連續(xù) IO 在 PageCache 中，最后合并成一個更大的 IO 再發(fā)給磁盤，這樣可以減少磁盤的尋址操作；另外，內(nèi)核也會預讀后續(xù)的 IO 放在 PageCache 中，減少磁盤操作。直接 IO 繞過了 PageCache，所以無法享受這些性能提升。

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

鏈接：https://www.cnblogs.com/-wenli/p/13380616.html

審核編輯：劉清