Epoll 是個很老的知識點，是后端工程師的經(jīng)典必修課。這種知識具備的特點就是研究的人多，所以研究的趨勢就會越來越深。當然分享的人也多，由于分享者水平參差不齊，也產(chǎn)生的大量錯誤理解。

[[386789]]

圖片來自 Pexels 

今天我再次分享 epoll，肯定不會列個表格，對比一下差異，那就太無聊了。

我將從線程阻塞的原理，中斷優(yōu)化，網(wǎng)卡處理數(shù)據(jù)過程出發(fā)，深入的介紹 epoll 背后的原理，最后還會 diss 一些流行的觀點。相信無論你是否已經(jīng)熟悉 epoll，本文都會對你有價值。

正文開始前，先問大家?guī)讉€問題：

①epoll 性能到底有多高。很多文章介紹 epoll 可以輕松處理幾十萬個連接。而傳統(tǒng) IO 只能處理幾百個連接，是不是說 epoll 的性能就是傳統(tǒng) IO 的千倍呢?

②很多文章把網(wǎng)絡(luò) IO 劃分為阻塞，非阻塞，同步，異步。并表示：非阻塞的性能比阻塞性能好，異步的性能比同步性能好。

如果說阻塞導(dǎo)致性能低，那傳統(tǒng) IO 為什么要阻塞呢?epoll 是否需要阻塞呢?Java 的 NIO 和 AIO 底層都是 epoll 實現(xiàn)的，這又怎么理解同步和異步的區(qū)別?

③都是 IO 多路復(fù)用。既生瑜何生亮，為什么會有 select，poll 和 epoll 呢?為什么 epoll 比 select 性能高?

PS：本文共包含三大部分：初識 epoll、epoll 背后的原理 、Diss 環(huán)節(jié)。本文的重點是介紹原理，建議讀者的關(guān)注點盡量放在：“為什么”。

Linux 下進程和線程的區(qū)別其實并不大，尤其是在討論原理和性能問題時，因此本文中“進程”和“線程”兩個詞是混用的。

初識 epoll

epoll 是 Linux 內(nèi)核的可擴展 I/O 事件通知機制，其最大的特點就是性能優(yōu)異。

下圖是 libevent(一個知名的異步事件處理軟件庫)對 select，poll，epoll ，kqueue 這幾個 I/O 多路復(fù)用技術(shù)做的性能測試。

 

很多文章在描述 epoll 性能時都引用了這個基準測試，但少有文章能夠清晰的解釋這個測試結(jié)果。

這是一個限制了 100 個活躍連接的基準測試，每個連接發(fā)生 1000 次讀寫操作為止?？v軸是請求的響應(yīng)時間，橫軸是持有的 socket 句柄數(shù)量。

隨著句柄數(shù)量的增加，epoll 和 kqueue 響應(yīng)時間幾乎無變化，而 poll 和 select 的響應(yīng)時間卻增長了非常多。

可以看出來，epoll 性能是很高的，并且隨著監(jiān)聽的文件描述符的增加，epoll 的優(yōu)勢更加明顯。

不過，這里限制的 100 個連接很重要。epoll 在應(yīng)對大量網(wǎng)絡(luò)連接時，只有活躍連接很少的情況下才能表現(xiàn)的性能優(yōu)異。

換句話說，epoll 在處理大量非活躍的連接時性能才會表現(xiàn)的優(yōu)異。如果15000個 socket 都是活躍的，epoll 和 select 其實差不了太多。

為什么 epoll 的高性能有這樣的局限性?問題好像越來越多了，看來我們需要更深入的研究了。

epoll 背后的原理

阻塞

①為什么阻塞

我們以網(wǎng)卡接收數(shù)據(jù)舉例，回顧一下之前我分享過的網(wǎng)卡接收數(shù)據(jù)的過程。

 

為了方便理解，我盡量簡化技術(shù)細節(jié)，可以把接收數(shù)據(jù)的過程分為四步：

• NIC(網(wǎng)卡)接收到數(shù)據(jù)，通過 DMA 方式寫入內(nèi)存(Ring Buffer 和 sk_buff)。
• NIC 發(fā)出中斷請求(IRQ)，告訴內(nèi)核有新的數(shù)據(jù)過來了。
• Linux 內(nèi)核響應(yīng)中斷，系統(tǒng)切換為內(nèi)核態(tài)，處理 Interrupt Handler，從RingBuffer 拿出一個 Packet， 并處理協(xié)議棧，填充 Socket 并交給用戶進程。
• 系統(tǒng)切換為用戶態(tài)，用戶進程處理數(shù)據(jù)內(nèi)容。

網(wǎng)卡何時接收到數(shù)據(jù)是依賴發(fā)送方和傳輸路徑的，這個延遲通常都很高，是毫秒(ms)級別的。而應(yīng)用程序處理數(shù)據(jù)是納秒(ns)級別的。

也就是說整個過程中，內(nèi)核態(tài)等待數(shù)據(jù)，處理協(xié)議棧是個相對很慢的過程。這么長的時間里，用戶態(tài)的進程是無事可做的，因此用到了“阻塞(掛起)”。

②阻塞不占用 CPU

阻塞是進程調(diào)度的關(guān)鍵一環(huán)，指的是進程在等待某事件發(fā)生之前的等待狀態(tài)。

請看下表，在 Linux 中，進程狀態(tài)大致有 7 種(在 include/linux/sched.h 中有更多狀態(tài))：

 

從說明中其實就可以發(fā)現(xiàn)，“可運行狀態(tài)”會占用 CPU 資源，另外創(chuàng)建和銷毀進程也需要占用 CPU 資源(內(nèi)核)。重點是，當進程被"阻塞/掛起"時，是不會占用 CPU 資源的。

換個角度來講。為了支持多任務(wù)，Linux 實現(xiàn)了進程調(diào)度的功能(CPU 時間片的調(diào)度)。

而這個時間片的切換，只會在“可運行狀態(tài)”的進程間進行。因此“阻塞/掛起”的進程是不占用 CPU 資源的。

另外講個知識點，為了方便時間片的調(diào)度，所有“可運行狀態(tài)”狀態(tài)的進程，會組成一個隊列，就叫“工作隊列”。

③阻塞的恢復(fù)

內(nèi)核當然可以很容易的修改一個進程的狀態(tài)，問題是網(wǎng)絡(luò) IO 中，內(nèi)核該修改那個進程的狀態(tài)。

 

socket 結(jié)構(gòu)體，包含了兩個重要數(shù)據(jù)：進程 ID 和端口號。進程 ID 存放的就是執(zhí)行 connect，send，read 函數(shù)，被掛起的進程。

在 socket 創(chuàng)建之初，端口號就被確定了下來，操作系統(tǒng)會維護一個端口號到 socket 的數(shù)據(jù)結(jié)構(gòu)。

當網(wǎng)卡接收到數(shù)據(jù)時，數(shù)據(jù)中一定會帶著端口號，內(nèi)核就可以找到對應(yīng)的 socket，并從中取得“掛起”進程的 ID。

將進程的狀態(tài)修改為“可運行狀態(tài)”(加入到工作隊列)。此時內(nèi)核代碼執(zhí)行完畢，將控制權(quán)交還給用戶態(tài)。通過正常的“CPU 時間片的調(diào)度”，用戶進程得以處理數(shù)據(jù)。

④進程模型

上面介紹的整個過程，基本就是 BIO(阻塞 IO)的基本原理了。用戶進程都是獨立的處理自己的業(yè)務(wù)，這其實是一種符合進程模型的處理方式。

上下文切換的優(yōu)化

上面介紹的過程中，有兩個地方會造成頻繁的上下文切換，效率可能會很低：

• 如果頻繁的收到數(shù)據(jù)包，NIC 可能頻繁發(fā)出中斷請求(IRQ)。CPU 也許在用戶態(tài)，也許在內(nèi)核態(tài)，也許還在處理上一條數(shù)據(jù)的協(xié)議棧。但無論如何，CPU 都要盡快的響應(yīng)中斷。這么做實際上非常低效，造成了大量的上下文切換，也可能導(dǎo)致用戶進程長時間無法獲得數(shù)據(jù)。(即使是多核，每次協(xié)議棧都沒有處理完，自然無法交給用戶進程)
• 每個 Packet 對應(yīng)一個 socket，每個 socket 對應(yīng)一個用戶態(tài)的進程。這些用戶態(tài)進程轉(zhuǎn)為“可運行狀態(tài)”，必然要引起進程間的上下文切換。

①網(wǎng)卡驅(qū)動的 NAPI 機制

在 NIC 上，解決頻繁 IRQ 的技術(shù)叫做 New API(NAPI)。

原理其實特別簡單，把 Interrupt Handler 分為兩部分：

• 函數(shù)名為 napi_schedule，專門快速響應(yīng) IRQ，只記錄必要信息，并在合適的時機發(fā)出軟中斷 softirq。
• 函數(shù)名為 netrxaction，在另一個進程中執(zhí)行，專門響應(yīng) napi_schedule 發(fā)出的軟中斷，批量的處理 RingBuffer 中的數(shù)據(jù)。

 

所以使用了 NAPI 的驅(qū)動，接收數(shù)據(jù)過程可以簡化描述為：

• NIC 接收到數(shù)據(jù)，通過 DMA 方式寫入內(nèi)存(Ring Buffer 和 sk_buff)。
• NIC 發(fā)出中斷請求(IRQ)，告訴內(nèi)核有新的數(shù)據(jù)過來了。
• driver 的 napi_schedule 函數(shù)響應(yīng) IRQ，并在合適的時機發(fā)出軟中斷(NET_RX_SOFTIRQ)。
• driver 的 net_rx_action 函數(shù)響應(yīng)軟中斷，從 Ring Buffer 中批量拉取收到的數(shù)據(jù)。并處理協(xié)議棧，填充 Socket 并交給用戶進程。
• 系統(tǒng)切換為用戶態(tài)，多個用戶進程切換為“可運行狀態(tài)”，按 CPU 時間片調(diào)度，處理數(shù)據(jù)內(nèi)容。

一句話概括就是：等著收到一批數(shù)據(jù)，再一次批量的處理數(shù)據(jù)。

②單線程的 IO 多路復(fù)用

內(nèi)核優(yōu)化“進程間上下文切換”的技術(shù)叫的“IO 多路復(fù)用”，思路和 NAPI 是很接近的。

每個 socket 不再阻塞讀寫它的進程，而是用一個專門的線程，批量的處理用戶態(tài)數(shù)據(jù)，這樣就減少了線程間的上下文切換。

 

作為 IO 多路復(fù)用的一個實現(xiàn)，select 的原理也很簡單。所有的 socket 統(tǒng)一保存執(zhí)行 select 函數(shù)的(監(jiān)視進程)進程 ID。

任何一個 socket 接收了數(shù)據(jù)，都會喚醒“監(jiān)視進程”。內(nèi)核只要告訴“監(jiān)視進程”，那些 socket 已經(jīng)就緒，監(jiān)視進程就可以批量處理了。

IO 多路復(fù)用的進化

①對比 epoll 與 select

select，poll 和 epoll 都是“IO 多路復(fù)用”，那為什么還會有性能差距呢?篇幅限制，這里我們只簡單對比 select 和 epoll 的基本原理差異。

對于內(nèi)核，同時處理的 socket 可能有很多，監(jiān)視進程也可能有多個。所以監(jiān)視進程每次“批量處理數(shù)據(jù)”，都需要告訴內(nèi)核它“關(guān)心的 socket”。

內(nèi)核在喚醒監(jiān)視進程時，就可以把“關(guān)心的 socket”中，就緒的 socket 傳給監(jiān)視進程。

換句話說，在執(zhí)行系統(tǒng)調(diào)用 select 或 epoll_create 時，入?yún)⑹?ldquo;關(guān)心的 socket”，出參是“就緒的 socket”。

而 select 與 epoll 的區(qū)別在于：

select (一次O(n)查找)：

• 每次傳給內(nèi)核一個用戶空間分配的 fd_set 用于表示“關(guān)心的 socket”。其結(jié)構(gòu)(相當于 bitset)限制了只能保存 1024 個 socket。
• 每次 socket 狀態(tài)變化，內(nèi)核利用 fd_set 查詢 O(1)，就能知道監(jiān)視進程是否關(guān)心這個 socket。
• 內(nèi)核是復(fù)用了 fd_set 作為出參，返還給監(jiān)視進程(所以每次 select 入?yún)⑿枰刂?。

然而監(jiān)視進程必須遍歷一遍 socket 數(shù)組 O(n)，才知道哪些 socket 就緒了。

epoll (全是O(1)查找)：

• 每次傳給內(nèi)核一個實例句柄。這個句柄是在內(nèi)核分配的紅黑樹 rbr+雙向鏈表 rdllist。只要句柄不變，內(nèi)核就能復(fù)用上次計算的結(jié)果。
• 每次 socket 狀態(tài)變化，內(nèi)核就可以快速從 rbr 查詢O(1)，監(jiān)視進程是否關(guān)心這個 socket。同時修改 rdllist，所以 rdllist 實際上是“就緒的 socket”的一個緩存。
• 內(nèi)核復(fù)制 rdllist 的一部分或者全部(LT 和 ET)，到專門的 epoll_event 作為出參。

所以監(jiān)視進程，可以直接一個個處理數(shù)據(jù)，無需再遍歷確認。

Select 示例代碼：

 

Epoll 示例代碼：

 

另外，epoll_create 底層實現(xiàn)，到底是不是紅黑樹，其實也不太重要(完全可以換成 hashtable)。

重要的是 efd 是個指針，其數(shù)據(jù)結(jié)構(gòu)完全可以對外透明的修改成任意其他數(shù)據(jù)結(jié)構(gòu)。

②API 發(fā)布的時間線

另外，我們再來看看網(wǎng)絡(luò) IO 中，各個 api 的發(fā)布時間線：

• 1983，socket 發(fā)布在 Unix(4.2 BSD)
• 1983，select 發(fā)布在 Unix(4.2 BSD)
• 1994，Linux 的 1.0，已經(jīng)支持 socket 和 select
• 1997，poll 發(fā)布在 Linux 2.1.23
• 2002，epoll 發(fā)布在 Linux 2.5.44

就可以得到兩個有意思的結(jié)論：

• socket 和 select 是同時發(fā)布的。這說明了，select 不是用來代替?zhèn)鹘y(tǒng) IO 的。這是兩種不同的用法(或模型)，適用于不同的場景。
• select、poll 和 epoll，這三個“IO 多路復(fù)用 API”是相繼發(fā)布的。這說明了，它們是 IO 多路復(fù)用的 3 個進化版本。

因為 API 設(shè)計缺陷，無法在不改變 API 的前提下優(yōu)化內(nèi)部邏輯。所以用 poll 替代 select，再用 epoll 替代 poll。

總結(jié)

我們花了三個章節(jié)，闡述 epoll 背后的原理，現(xiàn)在用三句話總結(jié)一下：

• 基于數(shù)據(jù)收發(fā)的基本原理，系統(tǒng)利用阻塞提高了 CPU 利用率。
• 為了優(yōu)化上線文切換，設(shè)計了“IO 多路復(fù)用”(和 NAPI)。
• 為了優(yōu)化“內(nèi)核與監(jiān)視進程的交互”，設(shè)計了三個版本的 API(select，poll，epoll)。

Diss 環(huán)節(jié)

講完“epoll 背后的原理”，已經(jīng)可以回答最初的幾個問題。這已經(jīng)是一個完整的文章，很多人勸我刪掉下面的 diss 環(huán)節(jié)。

我的觀點是：學(xué)習(xí)就是個研究+理解的過程。上面是研究，下面再講一下我的個人“理解”，歡迎指正。

關(guān)于 IO 模型的分類

關(guān)于阻塞，非阻塞，同步，異步的分類，這么分自然有其道理。但是在操作系統(tǒng)的角度來看“這樣分類，容易產(chǎn)生誤解，并不好”。

 

①阻塞和非阻塞

Linux 下所有的 IO 模型都是阻塞的，這是收發(fā)數(shù)據(jù)的基本原理導(dǎo)致的。阻塞用戶線程是一種高效的方式。

你當然可以寫一個程序，socket 設(shè)置成非阻塞模式，在不使用監(jiān)視器的情況下，依靠死循環(huán)完成一次 IO 操作。但是這樣做的效率實在是太低了，完全沒有實際意義。

換句話說，阻塞不是問題，運行才是問題，運行才會消耗 CPU。IO 多路復(fù)用不是減少了阻塞，是減少了運行。

上下文切換才是問題，IO 多路復(fù)用，通過減少運行的進程，有效的減少了上下文切換。

②同步和異步

Linux 下所有的 IO 模型都是同步的。BIO 是同步的，select 同步的，poll 同步的，epoll 還是同步的。

Java 提供的 AIO，也許可以稱作“異步”的。但是 JVM 是運行在用戶態(tài)的，Linux 沒有提供任何的異步支持。

因此 JVM 提供的異步支持，和你自己封裝成“異步”的框架是沒有本質(zhì)區(qū)別的(你完全可以使用 BIO 封裝成異步框架)。

所謂的“同步“和”異步”只是兩種事件分發(fā)器(event dispatcher)或者說是兩個設(shè)計模式(Reactor 和 Proactor)。

都是運行在用戶態(tài)的，兩個設(shè)計模式能有多少性能差異呢?

• Reactor 對應(yīng) Java 的 NIO，也就是 Channel，Buffer 和 Selector 構(gòu)成的核心的 API。
• Proactor對應(yīng) java 的 AIO，也就是 Async 組件和 Future 或 Callback 構(gòu)成的核心的 API。

③我的分類

我認為 IO 模型只分兩類：

• 更加符合程序員理解和使用的，進程模型。
• 更加符合操作系統(tǒng)處理邏輯的，IO 多路復(fù)用模型。

對于“IO 多路復(fù)用”的事件分發(fā)，又分為兩類：Reactor 和 Proactor。

關(guān)于 mmap

epoll 到底用沒用到 mmap?答案：沒有!

這是個以訛傳訛的謠言。其實很容易證明的，用 epoll 寫個 demo。strace 一下就清楚了。

作者：馮志明

簡介：2019 年至今負責(zé)搜索算法的相關(guān)工作，擅長處理復(fù)雜的業(yè)務(wù)系統(tǒng)，對底層技術(shù)有濃厚興趣。

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號Qunar技術(shù)沙龍(ID：QunarTL)