本文將從文件傳輸場(chǎng)景以及零拷貝技術(shù)深究 Linux I/O 的發(fā)展過(guò)程、優(yōu)化手段以及實(shí)際應(yīng)用。

前言

存儲(chǔ)器是計(jì)算機(jī)的核心部件之一，在完全理想的狀態(tài)下，存儲(chǔ)器應(yīng)該要同時(shí)具備以下三種特性：

• 速度足夠快：存儲(chǔ)器的存取速度應(yīng)當(dāng)快于 CPU 執(zhí)行一條指令，這樣 CPU 的效率才不會(huì)受限于存儲(chǔ)器；

• 容量足夠大：容量能夠存儲(chǔ)計(jì)算機(jī)所需的全部數(shù)據(jù)；

• 價(jià)格足夠便宜：價(jià)格低廉，所有類型的計(jì)算機(jī)都能配備。

但是現(xiàn)實(shí)往往是殘酷的，我們目前的計(jì)算機(jī)技術(shù)無(wú)法同時(shí)滿足上述的三個(gè)條件，于是現(xiàn)代計(jì)算機(jī)的存儲(chǔ)器設(shè)計(jì)采用了一種分層次的結(jié)構(gòu)：

從頂至底，現(xiàn)代計(jì)算機(jī)里的存儲(chǔ)器類型分別有：寄存器、高速緩存、主存和磁盤?，這些存儲(chǔ)器的速度逐級(jí)遞減而容量逐級(jí)遞增。

存取速度最快的是寄存器?，因?yàn)榧拇嫫鞯闹谱鞑牧虾?CPU 是相同的，所以速度和 CPU 一樣快，CPU 訪問(wèn)寄存器是沒(méi)有時(shí)延的，然而因?yàn)閮r(jià)格昂貴，因此容量也極小，一般 32 位的 CPU 配備的寄存器容量是 32??32 Bit，64 位的 CPU 則是 64??64 Bit，不管是 32 位還是 64 位，寄存器容量都小于 1 KB，且寄存器也必須通過(guò)軟件自行管理。

第二層是高速緩存?，也即我們平時(shí)了解的 CPU 高速緩存?L1、L2、L3?，一般 L1 是每個(gè) CPU 獨(dú)享，L3 是全部 CPU 共享，而 L2 則根據(jù)不同的架構(gòu)設(shè)計(jì)會(huì)被設(shè)計(jì)成獨(dú)享或者共享兩種模式之一，比如 Intel 的多核芯片采用的是共享 L2 模式而 AMD 的多核芯片則采用的是獨(dú)享 L2 模式。

第三層則是主存?，也即主內(nèi)存，通常稱作隨機(jī)訪問(wèn)存儲(chǔ)器（Random Access Memory, RAM）。是與 CPU 直接交換數(shù)據(jù)的內(nèi)部存儲(chǔ)器。它可以隨時(shí)讀寫（刷新時(shí)除外），而且速度很快，通常作為操作系統(tǒng)或其他正在運(yùn)行中的程序的臨時(shí)資料存儲(chǔ)介質(zhì)。

至于磁盤?則是圖中離用戶最遠(yuǎn)的一層了，讀寫速度相差內(nèi)存上百倍；另一方面自然針對(duì)磁盤操作的優(yōu)化也非常多，如零拷貝**、** direct I/O**、** 異步 I/O 等等，這些優(yōu)化的目的都是為了提高系統(tǒng)的吞吐量；另外操作系統(tǒng)內(nèi)核中也有磁盤高速緩存區(qū)、PageCache、TLB等，可以有效的減少磁盤的訪問(wèn)次數(shù)。

現(xiàn)實(shí)情況中，大部分系統(tǒng)在由小變大的過(guò)程中，最先出現(xiàn)瓶頸的就是I/O，尤其是在現(xiàn)代網(wǎng)絡(luò)應(yīng)用從 CPU 密集型轉(zhuǎn)向了 I/O 密集型的大背景下，I/O越發(fā)成為大多數(shù)應(yīng)用的性能瓶頸。

傳統(tǒng)的 Linux 操作系統(tǒng)的標(biāo)準(zhǔn) I/O 接口是基于數(shù)據(jù)拷貝操作的，即 I/O 操作會(huì)導(dǎo)致數(shù)據(jù)在操作系統(tǒng)內(nèi)核地址空間的緩沖區(qū)和用戶進(jìn)程地址空間定義的緩沖區(qū)之間進(jìn)行傳輸。設(shè)置緩沖區(qū)最大的好處是可以減少磁盤 I/O 的操作?，如果所請(qǐng)求的數(shù)據(jù)已經(jīng)存放在操作系統(tǒng)的高速緩沖存儲(chǔ)器中，那么就不需要再進(jìn)行實(shí)際的物理磁盤 I/O 操作；然而傳統(tǒng)的 Linux I/O 在數(shù)據(jù)傳輸過(guò)程中的數(shù)據(jù)拷貝操作深度依賴 CPU?，也就是說(shuō) I/O 過(guò)程需要 CPU 去執(zhí)行數(shù)據(jù)拷貝的操作，因此導(dǎo)致了極大的系統(tǒng)開銷，限制了操作系統(tǒng)有效進(jìn)行數(shù)據(jù)傳輸操作的能力。

這篇文章就從文件傳輸場(chǎng)景以及零拷貝?技術(shù)深究 Linux I/O的發(fā)展過(guò)程、優(yōu)化手段以及實(shí)際應(yīng)用。

需要了解的詞

• DMA?DMA，全稱 Direct Memory Access，即直接存儲(chǔ)器訪問(wèn)，是為了避免 CPU 在磁盤操作時(shí)承擔(dān)過(guò)多的中斷負(fù)載而設(shè)計(jì)的；在磁盤操作中，CPU 可將總線控制權(quán)交給 DMA 控制器，由 DMA 輸出讀寫命令，直接控制 RAM 與 I/O 接口進(jìn)行 DMA 傳輸，無(wú)需 CPU 直接控制傳輸，也沒(méi)有中斷處理方式那樣保留現(xiàn)場(chǎng)和恢復(fù)現(xiàn)場(chǎng)過(guò)程，使得 CPU 的效率大大提高。

• MMU?Memory Management Unit—內(nèi)存管理單元，主要實(shí)現(xiàn)：

• 競(jìng)爭(zhēng)訪問(wèn)保護(hù)管理需求?：需要嚴(yán)格的訪問(wèn)保護(hù)，動(dòng)態(tài)管理哪些內(nèi)存頁(yè)/段或區(qū)，為哪些應(yīng)用程序所用。這屬于資源的競(jìng)爭(zhēng)訪問(wèn)管理需求；

• 高效的翻譯轉(zhuǎn)換管理需求?：需要實(shí)現(xiàn)快速高效的映射翻譯轉(zhuǎn)換，否則系統(tǒng)的運(yùn)行效率將會(huì)低下；

• 高效的虛實(shí)內(nèi)存交換需求?：需要在實(shí)際的虛擬內(nèi)存與物理內(nèi)存進(jìn)行內(nèi)存頁(yè)/段交換過(guò)程中快速高效。

• Page Cache?為了避免每次讀寫文件時(shí)，都需要對(duì)硬盤進(jìn)行讀寫操作，Linux 內(nèi)核使用 頁(yè)緩存（Page Cache） 機(jī)制來(lái)對(duì)文件中的數(shù)據(jù)進(jìn)行緩存。

此外，由于讀取磁盤數(shù)據(jù)的時(shí)候，需要找到數(shù)據(jù)所在的位置，但是對(duì)于機(jī)械磁盤來(lái)說(shuō)，就是通過(guò)磁頭旋轉(zhuǎn)到數(shù)據(jù)所在的扇區(qū)，再開始「順序」讀取數(shù)據(jù)，但是旋轉(zhuǎn)磁頭這個(gè)物理動(dòng)作是非常耗時(shí)的，為了降低它的影響，PageCache 使用了「預(yù)讀功能」?。比如，假設(shè) read 方法每次只會(huì)讀 32 KB 的字節(jié)，雖然 read 剛開始只會(huì)讀 0 ～ 32 KB 的字節(jié)，但內(nèi)核會(huì)把其后面的 32 ～ 64 KB 也讀取到 PageCache，這樣后面讀取 32 ～ 64 KB 的成本就很低，如果在 32 ～ 64 KB 淘汰出 PageCache 前，有進(jìn)程讀取到它了，收益就非常大。

虛擬內(nèi)存?在計(jì)算機(jī)領(lǐng)域有一句如同摩西十誡般神圣的哲言："計(jì)算機(jī)科學(xué)領(lǐng)域的任何問(wèn)題都可以通過(guò)增加一個(gè)間接的中間層來(lái)解決?"，從內(nèi)存管理、網(wǎng)絡(luò)模型、并發(fā)調(diào)度甚至是硬件架構(gòu)，都能看到這句哲言在閃爍著光芒，而虛擬內(nèi)存則是這一哲言的完美實(shí)踐之一。虛擬內(nèi)存為每個(gè)進(jìn)程提供了一個(gè)一致的、私有且連續(xù)完整的內(nèi)存空間?；所有現(xiàn)代操作系統(tǒng)都使用虛擬內(nèi)存，使用虛擬地址取代物理地址，主要有以下幾點(diǎn)好處：利用上述的第一條特性可以優(yōu)化，可以把內(nèi)核空間和用戶空間的虛擬地址映射到同一個(gè)物理地址?，這樣在 I/O 操作時(shí)就不需要來(lái)回復(fù)制了。

• 多個(gè)虛擬內(nèi)存可以指向同一個(gè)物理地址；

• 虛擬內(nèi)存空間可以遠(yuǎn)遠(yuǎn)大于物理內(nèi)存空間；

• 應(yīng)用層面可管理連續(xù)的內(nèi)存空間，減少出錯(cuò)。

• NFS?文件系統(tǒng) 網(wǎng)絡(luò)文件系統(tǒng)是 FreeBSD 支持的文件系統(tǒng)中的一種，也被稱為 NFS；NFS 允許一個(gè)系統(tǒng)在網(wǎng)絡(luò)上與它人共享目錄和文件，通過(guò)使用 NFS，用戶和程序可以象訪問(wèn)本地文件 一樣訪問(wèn)遠(yuǎn)端系統(tǒng)上的文件。

• Copy-on-write?寫入時(shí)復(fù)制（Copy-on-write，COW）是一種計(jì)算機(jī)程序設(shè)計(jì)領(lǐng)域的優(yōu)化策略。其核心思想是，如果有多個(gè)調(diào)用者（callers）同時(shí)請(qǐng)求相同資源（如內(nèi)存或磁盤上的數(shù)據(jù)存儲(chǔ)），他們會(huì)共同獲取相同的指針指向相同的資源，直到某個(gè)調(diào)用者試圖修改資源的內(nèi)容時(shí)，系統(tǒng)才會(huì)真正復(fù)制一份專用副本（private copy）給該調(diào)用者，而其他調(diào)用者所見到的最初的資源仍然保持不變。這過(guò)程對(duì)其他的調(diào)用者都是透明的。此作法主要的優(yōu)點(diǎn)是如果調(diào)用者沒(méi)有修改該資源，就不會(huì)有副本（private copy）被創(chuàng)建?，因此多個(gè)調(diào)用者只是讀取操作時(shí)可以共享同一份資源。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ?

為什么要有 DMA

在沒(méi)有 DMA 技術(shù)前，I/O 的過(guò)程是這樣的：

• CPU 發(fā)出對(duì)應(yīng)的指令給磁盤控制器，然后返回；

• 磁盤控制器收到指令后，于是就開始準(zhǔn)備數(shù)據(jù)，會(huì)把數(shù)據(jù)放入到磁盤控制器的內(nèi)部緩沖區(qū)中，然后產(chǎn)生一個(gè)中斷?；

• CPU 收到中斷信號(hào)后，停下手頭的工作，接著把磁盤控制器的緩沖區(qū)的數(shù)據(jù)一次一個(gè)字節(jié)地讀進(jìn)自己的寄存器，然后再把寄存器里的數(shù)據(jù)寫入到內(nèi)存，而在數(shù)據(jù)傳輸?shù)钠陂g CPU 是被阻塞的狀態(tài)，無(wú)法執(zhí)行其他任務(wù)。

整個(gè)數(shù)據(jù)的傳輸過(guò)程，都要需要 CPU 親自參與拷貝數(shù)據(jù)，而且這時(shí) CPU 是被阻塞的；簡(jiǎn)單的搬運(yùn)幾個(gè)字符數(shù)據(jù)那沒(méi)問(wèn)題，但是如果我們用千兆網(wǎng)卡或者硬盤傳輸大量數(shù)據(jù)的時(shí)候，都用 CPU 來(lái)搬運(yùn)的話，肯定忙不過(guò)來(lái)。

計(jì)算機(jī)科學(xué)家們發(fā)現(xiàn)了事情的嚴(yán)重性后，于是就發(fā)明了 DMA 技術(shù)，也就是直接內(nèi)存訪問(wèn)（Direct Memory Access）?技術(shù)。

簡(jiǎn)單理解就是，在進(jìn)行 I/O 設(shè)備和內(nèi)存的數(shù)據(jù)傳輸?shù)臅r(shí)候，數(shù)據(jù)搬運(yùn)的工作全部交給 DMA 控制器，而 CPU 不再參與任何與數(shù)據(jù)搬運(yùn)相關(guān)的事情，這樣 CPU 就可以去處理別的事務(wù)?。

具體流程如下圖：

• 用戶進(jìn)程調(diào)用 read 方法，向操作系統(tǒng)發(fā)出 I/O 請(qǐng)求，請(qǐng)求讀取數(shù)據(jù)到自己的內(nèi)存緩沖區(qū)中，進(jìn)程進(jìn)入阻塞狀態(tài)；

• 操作系統(tǒng)收到請(qǐng)求后，進(jìn)一步將 I/O 請(qǐng)求發(fā)送 DMA，釋放 CPU；

• DMA 進(jìn)一步將 I/O 請(qǐng)求發(fā)送給磁盤；

• 磁盤收到 DMA 的 I/O 請(qǐng)求，把數(shù)據(jù)從磁盤讀取到磁盤控制器的緩沖區(qū)中，當(dāng)磁盤控制器的緩沖區(qū)被讀滿后，向 DMA 發(fā)起中斷信號(hào)，告知自己緩沖區(qū)已滿；

• DMA 收到磁盤的信號(hào)，將磁盤控制器緩沖區(qū)中的數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)中，此時(shí)不占用 CPU，CPU 依然可以執(zhí)行其它事務(wù)?；

• 當(dāng) DMA 讀取了足夠多的數(shù)據(jù)，就會(huì)發(fā)送中斷信號(hào)給 CPU；

• CPU 收到 中斷信號(hào)，將數(shù)據(jù)從內(nèi)核拷貝到用戶空間，系統(tǒng)調(diào)用返回。

在有了 DMA 后，整個(gè)數(shù)據(jù)傳輸?shù)倪^(guò)程，CPU 不再參與與磁盤交互的數(shù)據(jù)搬運(yùn)工作，而是全程由 DMA 完成，但是 CPU 在這個(gè)過(guò)程中也是必不可少的，因?yàn)閭鬏斒裁磾?shù)據(jù)，從哪里傳輸?shù)侥睦铮夹枰?CPU 來(lái)告訴 DMA 控制器。

早期 DMA 只存在在主板上，如今由于 I/O 設(shè)備越來(lái)越多，數(shù)據(jù)傳輸?shù)男枨笠膊槐M相同，所以每個(gè) I/O 設(shè)備里面都有自己的 DMA 控制器。

傳統(tǒng)文件傳輸?shù)娜毕?/h1>

有了 DMA 后，我們的磁盤 I/O 就一勞永逸了嗎？并不是的；拿我們比較熟悉的下載文件舉例，服務(wù)端要提供此功能，比較直觀的方式就是：將磁盤中的文件讀出到內(nèi)存，再通過(guò)網(wǎng)絡(luò)協(xié)議發(fā)送給客戶端。

具體的 I/O 工作方式是，數(shù)據(jù)讀取和寫入是從用戶空間到內(nèi)核空間來(lái)回復(fù)制，而內(nèi)核空間的數(shù)據(jù)是通過(guò)操作系統(tǒng)層面的 I/O 接口從磁盤讀取或?qū)懭搿?/p>

代碼通常如下，一般會(huì)需要兩個(gè)系統(tǒng)調(diào)用：

代碼很簡(jiǎn)單，雖然就兩行代碼，但是這里面發(fā)生了不少的事情：

這其中有：

• 4 次用戶態(tài)與內(nèi)核態(tài)的上下文切換?兩次系統(tǒng)調(diào)用 read() 和 write()中，每次系統(tǒng)調(diào)用都得先從用戶態(tài)切換到內(nèi)核態(tài)?，等內(nèi)核完成任務(wù)后，再?gòu)膬?nèi)核態(tài)切換回用戶態(tài)；上下文切換?的成本并不小，一次切換需要耗時(shí)幾十納秒到幾微秒，在高并發(fā)場(chǎng)景下很容易成為性能瓶頸（參考線程切換和協(xié)程切換的成本差別?）。

• 4 次數(shù)據(jù)拷貝?兩次由 DMA 完成拷貝，另外兩次則是由 CPU 完成拷貝；我們只是搬運(yùn)一份數(shù)據(jù)，結(jié)果卻搬運(yùn)了 4 次，過(guò)多的數(shù)據(jù)拷貝無(wú)疑會(huì)消耗 額外的資源，大大降低了系統(tǒng)性能。

所以，要想提高文件傳輸?shù)男阅埽托枰獪p少用戶態(tài)與內(nèi)核態(tài)的上下文切換?和內(nèi)存拷貝?的次數(shù)。

如何優(yōu)化傳統(tǒng)文件傳輸

減少「用戶態(tài)與內(nèi)核態(tài)的上下文切換」

讀取磁盤數(shù)據(jù)的時(shí)候，之所以要發(fā)生上下文切換，這是因?yàn)橛脩艨臻g沒(méi)有權(quán)限操作磁盤或網(wǎng)卡，內(nèi)核的權(quán)限最高，這些操作設(shè)備的過(guò)程都需要交由操作系統(tǒng)內(nèi)核來(lái)完成，所以一般要通過(guò)內(nèi)核去完成某些任務(wù)的時(shí)候，就需要使用操作系統(tǒng)提供的系統(tǒng)調(diào)用函數(shù)。

而一次系統(tǒng)調(diào)用必然會(huì)發(fā)生 2 次上下文切換：首先從用戶態(tài)切換到內(nèi)核態(tài)，當(dāng)內(nèi)核執(zhí)行完任務(wù)后，再切換回用戶態(tài)交由進(jìn)程代碼執(zhí)行。

減少「數(shù)據(jù)拷貝」次數(shù)

前面提到，傳統(tǒng)的文件傳輸方式會(huì)歷經(jīng) 4 次數(shù)據(jù)拷貝；但很明顯的可以看到：從內(nèi)核的讀緩沖區(qū)拷貝到用戶的緩沖區(qū)?和從用戶的緩沖區(qū)里拷貝到 socket 的緩沖區(qū)?」這兩步是沒(méi)有必要的。

因?yàn)樵谙螺d文件，或者說(shuō)廣義的文件傳輸場(chǎng)景中，我們并不需要在用戶空間對(duì)數(shù)據(jù)進(jìn)行再加工?，所以數(shù)據(jù)并不需要回到用戶空間中。

零拷貝

那么零拷貝?技術(shù)就應(yīng)運(yùn)而生了，它就是為了解決我們?cè)谏厦嫣岬降膱?chǎng)景——跨過(guò)與用戶態(tài)交互的過(guò)程，直接將數(shù)據(jù)從文件系統(tǒng)移動(dòng)到網(wǎng)絡(luò)接口而產(chǎn)生的技術(shù)。

零拷貝實(shí)現(xiàn)原理

零拷貝技術(shù)實(shí)現(xiàn)的方式通常有 3 種：

• mmap + write

• sendfile

• splice

mmap + write

在前面我們知道，read() 系統(tǒng)調(diào)用的過(guò)程中會(huì)把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到用戶的緩沖區(qū)里，于是為了省去這一步，我們可以用 mmap() 替換 read() 系統(tǒng)調(diào)用函數(shù)，偽代碼如下：

mmap的函數(shù)原型如下：

mmap() 系統(tǒng)調(diào)用函數(shù)會(huì)在調(diào)用進(jìn)程的虛擬地址空間中創(chuàng)建一個(gè)新映射，直接把內(nèi)核緩沖區(qū)里的數(shù)據(jù)「映射?」到用戶空間，這樣，操作系統(tǒng)內(nèi)核與用戶空間就不需要再進(jìn)行任何的數(shù)據(jù)拷貝操作。

具體過(guò)程如下：

• 應(yīng)用進(jìn)程調(diào)用了 mmap() 后，DMA 會(huì)把磁盤的數(shù)據(jù)拷貝到內(nèi)核的緩沖區(qū)里，應(yīng)用進(jìn)程跟操作系統(tǒng)內(nèi)核「共享」這個(gè)緩沖區(qū)；

• 應(yīng)用進(jìn)程再調(diào)用 write()，操作系統(tǒng)直接將內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到 socket 緩沖區(qū)中，這一切都發(fā)生在內(nèi)核態(tài)，由 CPU 來(lái)搬運(yùn)數(shù)據(jù)；

• 最后，把內(nèi)核的 socket 緩沖區(qū)里的數(shù)據(jù)，拷貝到網(wǎng)卡的緩沖區(qū)里，這個(gè)過(guò)程是由 DMA 搬運(yùn)的。

我們可以看到，通過(guò)使用 mmap() 來(lái)代替 read()， 可以減少一次數(shù)據(jù)拷貝的過(guò)程。

但這還不是最理想的零拷貝，因?yàn)槿匀恍枰ㄟ^(guò) CPU 把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到 socket 緩沖區(qū)里，且仍然需要 4 次上下文切換，因?yàn)橄到y(tǒng)調(diào)用還是 2 次。

sendfile

在 Linux 內(nèi)核版本 2.1 中，提供了一個(gè)專門發(fā)送文件的系統(tǒng)調(diào)用函數(shù) sendfile()如下：

它的前兩個(gè)參數(shù)分別是目的端和源端的文件描述符，后面兩個(gè)參數(shù)是源端的偏移量和復(fù)制數(shù)據(jù)的長(zhǎng)度，返回值是實(shí)際復(fù)制數(shù)據(jù)的長(zhǎng)度。

首先，它可以替代前面的 read() 和 write() 這兩個(gè)系統(tǒng)調(diào)用，這樣就可以減少一次系統(tǒng)調(diào)用，也就減少了 2 次上下文切換的開銷。

其次，該系統(tǒng)調(diào)用，可以直接把內(nèi)核緩沖區(qū)里的數(shù)據(jù)拷貝到 socket 緩沖區(qū)里，不再拷貝到用戶態(tài)，這樣就只有 2 次上下文切換，和 3 次數(shù)據(jù)拷貝。如下圖：

帶有 scatter/gather 的 sendfile 方式

Linux 2.4 內(nèi)核進(jìn)行了優(yōu)化，提供了帶有 scatter/gather 的 sendfile 操作，這個(gè)操作可以把最后一次 CPU COPY 去除。其原理就是在內(nèi)核空間 Read BUffer 和 Socket Buffer 不做數(shù)據(jù)復(fù)制，而是將 Read Buffer 的內(nèi)存地址、偏移量記錄到相應(yīng)的 Socket Buffer 中，這樣就不需要復(fù)制。其本質(zhì)和虛擬內(nèi)存的解決方法思路一致，就是內(nèi)存地址的記錄。

你可以在你的 Linux 系統(tǒng)通過(guò)下面這個(gè)命令，查看網(wǎng)卡是否支持 scatter-gather 特性：

于是，從 Linux 內(nèi)核 2.4 版本開始起，對(duì)于支持網(wǎng)卡支持 SG-DMA 技術(shù)的情況下， sendfile() 系統(tǒng)調(diào)用的過(guò)程發(fā)生了點(diǎn)變化，具體過(guò)程如下：

• 第一步，通過(guò) DMA 將磁盤上的數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)里；

• 第二步，緩沖區(qū)描述符和數(shù)據(jù)長(zhǎng)度傳到 socket 緩沖區(qū)，這樣網(wǎng)卡的 SG-DMA 控制器就可以直接將內(nèi)核緩存中的數(shù)據(jù)拷貝到網(wǎng)卡的緩沖區(qū)里，此過(guò)程不需要將數(shù)據(jù)從操作系統(tǒng)內(nèi)核緩沖區(qū)拷貝到 socket 緩沖區(qū)中，這樣就減少了一次數(shù)據(jù)拷貝；

所以，這個(gè)過(guò)程之中，只進(jìn)行了 2 次數(shù)據(jù)拷貝，如下圖：

splice 方式

splice 調(diào)用和sendfile 非常相似，用戶應(yīng)用程序必須擁有兩個(gè)已經(jīng)打開的文件描述符，一個(gè)表示輸入設(shè)備，一個(gè)表示輸出設(shè)備。與sendfile不同的是，splice允許任意兩個(gè)文件互相連接，而并不只是文件與socket進(jìn)行數(shù)據(jù)傳輸。對(duì)于從一個(gè)文件描述符發(fā)送數(shù)據(jù)到socket這種特例來(lái)說(shuō)，一直都是使用sendfile系統(tǒng)調(diào)用，而splice一直以來(lái)就只是一種機(jī)制，它并不僅限于sendfile的功能。也就是說(shuō) sendfile 是 splice 的一個(gè)子集。

splice() 是基于 Linux 的管道緩沖區(qū) (pipe buffer) 機(jī)制實(shí)現(xiàn)的，所以splice()的兩個(gè)入?yún)⑽募枋龇蟊仨氂幸粋€(gè)是管道設(shè)備。

使用 splice() 完成一次磁盤文件到網(wǎng)卡的讀寫過(guò)程如下：

• 用戶進(jìn)程調(diào)用 pipe()，從用戶態(tài)陷入內(nèi)核態(tài)；創(chuàng)建匿名單向管道，pipe() 返回，上下文從內(nèi)核態(tài)切換回用戶態(tài)；

• 用戶進(jìn)程調(diào)用 splice()，從用戶態(tài)陷入內(nèi)核態(tài)；

• DMA 控制器將數(shù)據(jù)從硬盤拷貝到內(nèi)核緩沖區(qū)，從管道的寫入端"拷貝"進(jìn)管道，splice()返回，上下文從內(nèi)核態(tài)回到用戶態(tài)；

• 用戶進(jìn)程再次調(diào)用 splice()，從用戶態(tài)陷入內(nèi)核態(tài)；

• 內(nèi)核把數(shù)據(jù)從管道的讀取端拷貝到socket緩沖區(qū)，DMA 控制器將數(shù)據(jù)從socket緩沖區(qū)拷貝到網(wǎng)卡；

• splice() 返回，上下文從內(nèi)核態(tài)切換回用戶態(tài)。

在 Linux 2.6.17 版本引入了 splice，而在 Linux 2.6.23 版本中， sendfile 機(jī)制的實(shí)現(xiàn)已經(jīng)沒(méi)有了，但是其 API 及相應(yīng)的功能還在，只不過(guò) API 及相應(yīng)的功能是利用了 splice 機(jī)制來(lái)實(shí)現(xiàn)的。

和 sendfile 不同的是，splice 不需要硬件支持。

零拷貝的實(shí)際應(yīng)用

Kafka

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

如果你追溯 Kafka 文件傳輸?shù)拇a，你會(huì)發(fā)現(xiàn)，最終它調(diào)用了 Java NIO 庫(kù)里的 transferTo 方法：

如果 Linux 系統(tǒng)支持 sendfile() 系統(tǒng)調(diào)用，那么 transferTo() 實(shí)際上最后就會(huì)使用到 sendfile() 系統(tǒng)調(diào)用函數(shù)。

Nginx

Nginx 也支持零拷貝技術(shù)，一般默認(rèn)是開啟零拷貝技術(shù)，這樣有利于提高文件傳輸?shù)男?，是否開啟零拷貝技術(shù)的配置如下：

由于文章篇幅過(guò)長(zhǎng)，下文繼續(xù)講解！

原文作者：騰訊技術(shù)工程