文章會從網絡卡接收資料的流程講起，串聯起 CPU 中斷、作業系統程序排程等知識;再一步步分析阻塞接收資料、Select 到 Epoll 的進化過程;最後探究 Epoll 的實現細節。

從網絡卡接收資料說起

下邊是一個典型的計算機結構圖，計算機由 CPU、儲存器(記憶體)與網路介面等部件組成，瞭解 Epoll 本質的第一步，要從硬體的角度看計算機怎樣接收網路資料。

計算機結構圖(圖片來源：Linux 核心完全註釋之微型計算機組成結構)

下圖展示了網絡卡接收資料的過程：

• 在 1 階段，網絡卡收到網線傳來的資料。
• 經過 2 階段的硬體電路的傳輸。
• 最終 3 階段將資料寫入到記憶體中的某個地址上。

這個過程涉及到 DMA 傳輸、IO 通路選擇等硬體有關的知識，但我們只需知道：網絡卡會把接收到的資料寫入記憶體。

網絡卡接收資料的過程

通過硬體傳輸，網絡卡接收的資料存放到記憶體中，作業系統就可以去讀取它們。

如何知道接收了資料?

瞭解 Epoll 本質的第二步，要從 CPU 的角度來看資料接收。理解這個問題，要先了解一個概念：中斷。

計算機執行程式時，會有優先順序的需求。比如，當計算機收到斷電訊號時，它應立即去儲存資料，儲存資料的程式具有較高的優先順序(電容可以儲存少許電量，供 CPU 執行很短的一小段時間)。

一般而言，由硬體產生的訊號需要 CPU 立馬做出迴應，不然資料可能就丟失了，所以它的優先順序很高。

CPU 理應中斷掉正在執行的程式，去做出響應;當 CPU 完成對硬體的響應後，再重新執行使用者程式。

中斷的過程如下圖，它和函式呼叫差不多，只不過函式呼叫是事先定好位置，而中斷的位置由“訊號”決定。

中斷程式呼叫

以鍵盤為例，當用戶按下鍵盤某個按鍵時，鍵盤會給 CPU 的中斷引腳發出一個高電平，CPU 能夠捕獲這個訊號，然後執行鍵盤中斷程式。

下圖展示了各種硬體通過中斷與 CPU 互動的過程：

CPU 中斷(圖片來源：net.pku.edu.cn)

現在可以回答“如何知道接收了資料?”這個問題了：當網絡卡把資料寫入到記憶體後，網絡卡向 CPU 發出一箇中斷訊號，作業系統便能得知有新資料到來，再通過網絡卡中斷程式去處理資料。

程序阻塞為什麼不佔用 CPU 資源?

瞭解 Epoll 本質的第三步，要從作業系統程序排程的角度來看資料接收。阻塞是程序排程的關鍵一環，指的是程序在等待某事件(如接收到網路資料)發生之前的等待狀態，Recv、Select 和 Epoll 都是阻塞方法。

下邊分析一下程序阻塞為什麼不佔用 CPU 資源?為簡單起見，我們從普通的 Recv 接收開始分析，先看看下面程式碼：

//建立socket 
int s = socket(AF_INET, SOCK_STREAM, 0);    
//繫結 
bind(s, ...) 
//監聽 
listen(s, ...) 
//接受客戶端連線 
int c = accept(s, ...) 
//接收客戶端資料 
recv(c, ...); 
//將資料打印出來 
printf(...) 

這是一段最基礎的網路程式設計程式碼，先新建 Socket 物件，依次呼叫 Bind、Listen 與 Accept，最後呼叫 Recv 接收資料。

Recv 是個阻塞方法，當程式執行到 Recv 時，它會一直等待，直到接收到資料才往下執行。那麼阻塞的原理是什麼?

工作佇列

作業系統為了支援多工，實現了程序排程的功能，會把程序分為“執行”和“等待”等幾種狀態。

執行狀態是程序獲得 CPU 使用權，正在執行程式碼的狀態;等待狀態是阻塞狀態，比如上述程式執行到 Recv 時，程式會從執行狀態變為等待狀態，接收到資料後又變回執行狀態。

作業系統會分時執行各個執行狀態的程序，由於速度很快，看上去就像是同時執行多個任務。

下圖的計算機中執行著 A、B 與 C 三個程序，其中程序 A 執行著上述基礎網路程式，一開始，這 3 個程序都被作業系統的工作佇列所引用，處於執行狀態，會分時執行。

工作佇列中有 A、B 和 C 三個程序

等待佇列

當程序 A 執行到建立 Socket 的語句時，作業系統會建立一個由檔案系統管理的 Socket 物件(如下圖)。

建立 Socket

這個 Socket 物件包含了傳送緩衝區、接收緩衝區與等待佇列等成員。等待佇列是個非常重要的結構，它指向所有需要等待該 Socket 事件的程序。

當程式執行到 Recv 時，作業系統會將程序 A 從工作佇列移動到該 Socket 的等待佇列中(如下圖)。

Socket 的等待佇列

由於工作佇列只剩下了程序 B 和 C，依據程序排程，CPU 會輪流執行這兩個程序的程式，不會執行程序 A 的程式。所以程序 A 被阻塞，不會往下執行程式碼，也不會佔用 CPU 資源。

注：作業系統新增等待佇列只是添加了對這個“等待中”程序的引用，以便在接收到資料時獲取程序物件、將其喚醒，而非直接將程序管理納入自己之下。上圖為了方便說明，直接將程序掛到等待佇列之下。

喚醒程序

當 Socket 接收到資料後，作業系統將該 Socket 等待佇列上的程序重新放回到工作佇列，該程序變成執行狀態，繼續執行程式碼。

同時由於 Socket 的接收緩衝區已經有了資料，Recv 可以返回接收到的資料。

核心接收網路資料全過程

這一步，貫穿網絡卡、中斷與程序排程的知識，敘述阻塞 Recv 下，核心接收資料的全過程。

核心接收資料全過程

如上圖所示，程序在 Recv 阻塞期間：

• 計算機收到了對端傳送的資料(步驟 ①)
• 資料經由網絡卡傳送到記憶體(步驟 ②)
• 然後網絡卡通過中斷訊號通知 CPU 有資料到達，CPU 執行中斷程式(步驟 ③)

此處的中斷程式主要有兩項功能，先將網路資料寫入到對應 Socket 的接收緩衝區裡面(步驟 ④)，再喚醒程序 A(步驟 ⑤)，重新將程序 A 放入工作佇列中。

喚醒程序的過程如下圖所示：

喚醒程序

以上是核心接收資料全過程，這裡我們可能會思考兩個問題：

• 作業系統如何知道網路資料對應於哪個 Socket?
• 如何同時監視多個 Socket 的資料?

第一個問題：因為一個 Socket 對應著一個埠號，而網路資料包中包含了 IP 和埠的資訊，核心可以通過埠號找到對應的 Socket。

當然，為了提高處理速度，作業系統會維護埠號到 Socket 的索引結構，以快速讀取。

第二個問題是多路複用的重中之重，也正是本文後半部分的重點。

同時監視多個 Socket 的簡單方法

服務端需要管理多個客戶端連線，而 Recv 只能監視單個 Socket，這種矛盾下，人們開始尋找監視多個 Socket 的方法。Epoll 的要義就是高效地監視多個 Socket。

從歷史發展角度看，必然先出現一種不太高效的方法，人們再加以改進，正如 Select 之於 Epoll。先理解不太高效的 Select，才能夠更好地理解 Epoll 的本質。

假如能夠預先傳入一個 Socket 列表，如果列表中的 Socket 都沒有資料，掛起程序，直到有一個 Socket 收到資料，喚醒程序。這種方法很直接，也是 Select 的設計思想。

為方便理解，我們先複習 Select 的用法。在下邊的程式碼中，先準備一個數組 FDS，讓 FDS 存放著所有需要監視的 Socket。

然後呼叫 Select，如果 FDS 中的所有 Socket 都沒有資料，Select 會阻塞，直到有一個 Socket 接收到資料，Select 返回，喚醒程序。

使用者可以遍歷 FDS，通過 FD_ISSET 判斷具體哪個 Socket 收到資料，然後做出處理。

int s = socket(AF_INET, SOCK_STREAM, 0);   
bind(s, ...) 
listen(s, ...) 
 
int fds[] =  存放需要監聽的socket 
 
while(1){ 
    int n = select(..., fds, ...) 
    for(int i=0; i < fds.count; i++){ 
        if(FD_ISSET(fds[i], ...)){ 
            //fds[i]的資料處理 
        } 
    } 
} 

Select 的流程

Select 的實現思路很直接，假如程式同時監視如下圖的 Sock1、Sock2 和 Sock3 三個 Socket，那麼在呼叫 Select 之後，作業系統把程序 A 分別加入這三個 Socket 的等待佇列中。

作業系統把程序 A 分別加入這三個 Socket 的等待佇列中

當任何一個 Socket 收到資料後，中斷程式將喚起程序。下圖展示了 Sock2 接收到了資料的處理流程：

Sock2 接收到了資料，中斷程式喚起程序 A

注：Recv 和 Select 的中斷回撥可以設定成不同的內容。

所謂喚起程序，就是將程序從所有的等待佇列中移除，加入到工作佇列裡面，如下圖所示：

將程序 A 從所有等待佇列中移除，再加入到工作佇列裡面

經由這些步驟，當程序 A 被喚醒後，它知道至少有一個 Socket 接收了資料。程式只需遍歷一遍 Socket 列表，就可以得到就緒的 Socket。

這種簡單方式行之有效，在幾乎所有作業系統都有對應的實現。但是簡單的方法往往有缺點，主要是：

• 每次呼叫 Select 都需要將程序加入到所有監視 Socket 的等待佇列，每次喚醒都需要從每個佇列中移除。這裡涉及了兩次遍歷，而且每次都要將整個 FDS 列表傳遞給核心，有一定的開銷。

正是因為遍歷操作開銷大，出於效率的考量，才會規定 Select 的最大監視數量，預設只能監視 1024 個 Socket。

• 程序被喚醒後，程式並不知道哪些 Socket 收到資料，還需要遍歷一次。

那麼，有沒有減少遍歷的方法?有沒有儲存就緒 Socket 的方法?這兩個問題便是 Epoll 技術要解決的。

補充說明：本節只解釋了 Select 的一種情形。當程式呼叫 Select 時，核心會先遍歷一遍 Socket，如果有一個以上的 Socket 接收緩衝區有資料，那麼 Select 直接返回，不會阻塞。

這也是為什麼 Select 的返回值有可能大於 1 的原因之一。如果沒有 Socket 有資料，程序才會阻塞。

Epoll 的設計思路

Epoll 是在 Select 出現 N 多年後才被髮明的，是 Select 和 Poll(Poll 和 Select 基本一樣，有少量改進)的增強版本。Epoll 通過以下一些措施來改進效率：

措施一：功能分離

Select 低效的原因之一是將“維護等待佇列”和“阻塞程序”兩個步驟合二為一。

相比 Select，Epoll 拆分了功能

如上圖所示，每次呼叫 Select 都需要這兩步操作，然而大多數應用場景中，需要監視的 Socket 相對固定，並不需要每次都修改。

Epoll 將這兩個操作分開，先用 epoll_ctl 維護等待佇列，再呼叫 epoll_wait 阻塞程序。顯而易見地，效率就能得到提升。

為方便理解後續的內容，我們先了解一下 Epoll 的用法。如下的程式碼中，先用 epoll_create 建立一個 Epoll 物件 Epfd，再通過 epoll_ctl 將需要監視的 Socket 新增到 Epfd 中，最後呼叫 epoll_wait 等待資料：

int s = socket(AF_INET, SOCK_STREAM, 0);    
bind(s, ...) 
listen(s, ...) 
 
int epfd = epoll_create(...); 
epoll_ctl(epfd, ...); //將所有需要監聽的socket新增到epfd中 
 
while(1){ 
    int n = epoll_wait(...) 
    for(接收到資料的socket){ 
        //處理 
    } 
} 

功能分離，使得 Epoll 有了優化的可能。

措施二：就緒列表

Select 低效的另一個原因在於程式不知道哪些 Socket 收到資料，只能一個個遍歷。如果核心維護一個“就緒列表”，引用收到資料的 Socket，就能避免遍歷。

就緒列表示意圖

如上圖所示，計算機共有三個 Socket，收到資料的 Sock2 和 Sock3 被就緒列表 Rdlist 所引用。

當程序被喚醒後，只要獲取 Rdlist 的內容，就能夠知道哪些 Socket 收到資料。

Epoll 的原理與工作流程

本節會以示例和圖表來講解 Epoll 的原理和工作流程。

建立 Epoll 物件

如下圖所示，當某個程序呼叫 epoll_create 方法時，核心會建立一個 eventpoll 物件(也就是程式中 Epfd 所代表的物件)。

核心建立 eventpoll 物件

eventpoll 物件也是檔案系統中的一員，和 Socket 一樣，它也會有等待佇列。

建立一個代表該 Epoll 的 eventpoll 物件是必須的，因為核心要維護“就緒列表”等資料，“就緒列表”可以作為 eventpoll 的成員。

維護監視列表

建立 Epoll 物件後，可以用 epoll_ctl 新增或刪除所要監聽的 Socket。以新增 Socket 為例。

新增所要監聽的 Socket

如上圖，如果通過 epoll_ctl 新增 Sock1、Sock2 和 Sock3 的監視，核心會將 eventpoll 新增到這三個 Socket 的等待佇列中。

當 Socket 收到資料後，中斷程式會操作 eventpoll 物件，而不是直接操作程序。

接收資料

當 Socket 收到資料後，中斷程式會給 eventpoll 的“就緒列表”新增 Socket 引用。

給就緒列表新增引用

如上圖展示的是 Sock2 和 Sock3 收到資料後，中斷程式讓 Rdlist 引用這兩個 Socket。

eventpoll 物件相當於 Socket 和程序之間的中介，Socket 的資料接收並不直接影響程序，而是通過改變 eventpoll 的就緒列表來改變程序狀態。

當程式執行到 epoll_wait 時，如果 Rdlist 已經引用了 Socket，那麼 epoll_wait 直接返回，如果 Rdlist 為空，阻塞程序。

阻塞和喚醒程序

假設計算機中正在執行程序 A 和程序 B，在某時刻程序 A 執行到了 epoll_wait 語句。

epoll_wait 阻塞程序

如上圖所示，核心會將程序 A 放入 eventpoll 的等待佇列中，阻塞程序。

當 Socket 接收到資料，中斷程式一方面修改 Rdlist，另一方面喚醒 eventpoll 等待佇列中的程序，程序 A 再次進入執行狀態(如下

圖)。Epoll 喚醒程序

也因為 Rdlist 的存在，程序 A 可以知道哪些 Socket 發生了變化。

Epoll 的實現細節

至此，相信讀者對 Epoll 的本質已經有一定的瞭解。但我們還需要知道 eventpoll 的資料結構是什麼樣子?

此外，就緒佇列應該使用什麼資料結構?eventpoll 應使用什麼資料結構來管理通過 epoll_ctl 新增或刪除的 Socket?

Epoll 原理示意圖，圖片來源：《深入理解 Nginx：模組開發與架構解析(第二版)》，陶輝

如上圖所示，eventpoll 包含了 Lock、MTX、WQ(等待佇列)與 Rdlist 等成員，其中 Rdlist 和 RBR 是我們所關心的。

就緒列表的資料結構

就緒列表引用著就緒的 Socket，所以它應能夠快速的插入資料。程式可能隨時呼叫 epoll_ctl 新增監視 Socket，也可能隨時刪除。

當刪除時，若該 Socket 已經存放在就緒列表中，它也應該被移除。所以就緒列表應是一種能夠快速插入和刪除的資料結構。

雙向連結串列就是這樣一種資料結構，Epoll 使用雙向連結串列來實現就緒佇列(對應上圖的 Rdlist)。

索引結構

既然 Epoll 將“維護監視佇列”和“程序阻塞”分離，也意味著需要有個資料結構來儲存監視的 Socket，至少要方便地新增和移除，還要便於搜尋，以避免重複新增。

紅黑樹是一種自平衡二叉查詢樹，搜尋、插入和刪除時間複雜度都是 O(log(N))，效率較好，Epoll 使用了紅黑樹作為索引結構(對應上圖的 RBR)。

注：因為作業系統要兼顧多種功能，以及有更多需要儲存的資料，Rdlist 並非直接引用 Socket，而是通過 Epitem 間接引用，紅黑樹的節點也是 Epitem 物件。

同樣，檔案系統也並非直接引用著 Socket。為方便理解，本文中省略了一些間接結構。

總結

Epoll 在 Select 和 Poll 的基礎上引入了 eventpoll 作為中間層，使用了先進的資料結構，是一種高效的多路複用技術。

這裡也以表格形式簡單對比一下 Select、Poll 與 Epoll，結束此文。希望讀者能有所收穫。

轉自：(6條訊息) Epoll原理解析_~~ LINUX ~~-CSDN部落格_epoll