這次答應我，一舉拿下 I-O 多路複用！

最基本的 Socket 模型

服務端首先調用 socket() 函數，創建網絡協議爲 IPv4，以及傳輸協議爲 TCP 的 Socket ，接着調用 bind() 函數，給這個 Socket 綁定一個 IP 地址和端口，綁定這兩個的目的是什麼？

綁定完 IP 地址和端口後，就可以調用 listen() 函數進行監聽，此時對應 TCP 狀態圖中的 listen，如果我們要判定服務器中一個網絡程序有沒有啓動，可以通過 netstate 命令查看對應的端口號是否有被監聽。

服務端進入了監聽狀態後，通過調用 accept() 函數，來從內核獲取客戶端的連接，如果沒有客戶端連接，則會阻塞等待客戶端連接的到來。

那客戶端是怎麼發起連接的呢？客戶端在創建好 Socket 後，調用 connect() 函數發起連接，該函數的參數要指明服務端的 IP 地址和端口號，然後萬衆期待的 TCP 三次握手就開始了。

在  TCP 連接的過程中，服務器的內核實際上爲每個 Socket 維護了兩個隊列：

當 TCP 全連接隊列不爲空後，服務端的 accept() 函數，就會從內核中的 TCP 全連接隊列裏拿出一個已經完成連接的  Socket 返回應用程序，後續數據傳輸都用這個 Socket。

注意，監聽的 Socket 和真正用來傳數據的 Socket 是兩個：

連接建立後，客戶端和服務端就開始相互傳輸數據了，雙方都可以通過 read() 和 write() 函數來讀寫數據。

至此， TCP 協議的 Socket 程序的調用過程就結束了，整個過程如下圖：

看到這，不知道你有沒有覺得讀寫 Socket  的方式，好像讀寫文件一樣。

是的，基於 Linux 一切皆文件的理念，在內核中 Socket 也是以「文件」的形式存在的，也是有對應的文件描述符。

PS : 下面會說到內核裏的數據結構，不感興趣的可以跳過這一部分，不會對後續的內容有影響。

文件描述符的作用是什麼？每一個進程都有一個數據結構 task_struct，該結構體裏有一個指向「文件描述符數組」的成員指針。該數組裏列出這個進程打開的所有文件的文件描述符。數組的下標是文件描述符，是一個整數，而數組的內容是一個指針，指向內核中所有打開的文件的列表，也就是說內核可以通過文件描述符找到對應打開的文件。

然後每個文件都有一個 inode，Socket 文件的 inode 指向了內核中的 Socket 結構，在這個結構體裏有兩個隊列，分別是發送隊列和接收隊列，這個兩個隊列裏面保存的是一個個 struct sk_buff，用鏈表的組織形式串起來。

sk_buff 可以表示各個層的數據包，在應用層數據包叫 data，在 TCP 層我們稱爲 segment，在 IP 層我們叫 packet，在數據鏈路層稱爲 frame。

你可能會好奇，爲什麼全部數據包只用一個結構體來描述呢？協議棧採用的是分層結構，上層向下層傳遞數據時需要增加包頭，下層向上層數據時又需要去掉包頭，如果每一層都用一個結構體，那在層之間傳遞數據的時候，就要發生多次拷貝，這將大大降低 CPU 效率。

於是，爲了在層級之間傳遞數據時，不發生拷貝，只用 sk_buff 一個結構體來描述所有的網絡包，那它是如何做到的呢？是通過調整 sk_buff 中 data 的指針，比如：

你可以從下面這張圖看到，當發送報文時，data 指針的移動過程。

如何服務更多的用戶？

前面提到的 TCP Socket 調用流程是最簡單、最基本的，它基本只能一對一通信，因爲使用的是同步阻塞的方式，當服務端在還沒處理完一個客戶端的網絡 I/O 時，或者 讀寫操作發生阻塞時，其他客戶端是無法與服務端連接的。

可如果我們服務器只能服務一個客戶，那這樣就太浪費資源了，於是我們要改進這個網絡 I/O 模型，以支持更多的客戶端。

在改進網絡 I/O 模型前，我先來提一個問題，你知道服務器單機理論最大能連接多少個客戶端？

相信你知道 TCP 連接是由四元組唯一確認的，這個四元組就是：本機 IP, 本機端口, 對端 IP, 對端端口。

服務器作爲服務方，通常會在本地固定監聽一個端口，等待客戶端的連接。因此服務器的本地 IP 和端口是固定的，於是對於服務端 TCP 連接的四元組只有對端 IP 和端口是會變化的，所以最大 TCP 連接數 = 客戶端 IP 數 × 客戶端端口數。

對於 IPv4，客戶端的 IP 數最多爲 2 的 32 次方，客戶端的端口數最多爲 2 的 16 次方，也就是服務端單機最大 TCP 連接數約爲 2 的 48 次方。

這個理論值相當 “豐滿”，但是服務器肯定承載不了那麼大的連接數，主要會受兩個方面的限制：

那如果服務器的內存只有 2 GB，網卡是千兆的，能支持併發 1 萬請求嗎？

併發 1 萬請求，也就是經典的 C10K 問題 ，C 是 Client 單詞首字母縮寫，C10K 就是單機同時處理 1 萬個請求的問題。

從硬件資源角度看，對於 2GB 內存千兆網卡的服務器，如果每個請求處理佔用不到 200KB 的內存和 100Kbit 的網絡帶寬就可以滿足併發 1 萬個請求。

不過，要想真正實現 C10K 的服務器，要考慮的地方在於服務器的網絡 I/O 模型，效率低的模型，會加重系統開銷，從而會離 C10K 的目標越來越遠。

多進程模型

基於最原始的阻塞網絡 I/O， 如果服務器要支持多個客戶端，其中比較傳統的方式，就是使用多進程模型，也就是爲每個客戶端分配一個進程來處理請求。

服務器的主進程負責監聽客戶的連接，一旦與客戶端連接完成，accept() 函數就會返回一個「已連接 Socket」，這時就通過 fork() 函數創建一個子進程，實際上就把父進程所有相關的東西都複製一份，包括文件描述符、內存地址空間、程序計數器、執行的代碼等。

這兩個進程剛複製完的時候，幾乎一摸一樣。不過，會根據返回值來區分是父進程還是子進程，如果返回值是 0，則是子進程；如果返回值是其他的整數，就是父進程。

正因爲子進程會複製父進程的文件描述符，於是就可以直接使用「已連接 Socket 」和客戶端通信了，

可以發現，子進程不需要關心「監聽 Socket」，只需要關心「已連接 Socket」；父進程則相反，將客戶服務交給子進程來處理，因此父進程不需要關心「已連接 Socket」，只需要關心「監聽 Socket」。

下面這張圖描述了從連接請求到連接建立，父進程創建生子進程爲客戶服務。

另外，當「子進程」退出時，實際上內核裏還會保留該進程的一些信息，也是會佔用內存的，如果不做好 “回收” 工作，就會變成殭屍進程，隨着殭屍進程越多，會慢慢耗盡我們的系統資源。

因此，父進程要 “善後” 好自己的孩子，怎麼善後呢？那麼有兩種方式可以在子進程退出後回收資源，分別是調用 wait() 和 waitpid() 函數。

這種用多個進程來應付多個客戶端的方式，在應對 100 個客戶端還是可行的，但是當客戶端數量高達一萬時，肯定扛不住的，因爲每產生一個進程，必會佔據一定的系統資源，而且進程間上下文切換的 “包袱” 是很重的，性能會大打折扣。

進程的上下文切換不僅包含了虛擬內存、棧、全局變量等用戶空間的資源，還包括了內核堆棧、寄存器等內核空間的資源。

多線程模型

既然進程間上下文切換的 “包袱” 很重，那我們就搞個比較輕量級的模型來應對多用戶的請求 —— 多線程模型。

線程是運行在進程中的一個 “邏輯流”，單進程中可以運行多個線程，同進程裏的線程可以共享進程的部分資源的，比如文件描述符列表、進程空間、代碼、全局數據、堆、共享庫等，這些共享些資源在上下文切換時是不需要切換，而只需要切換線程的私有數據、寄存器等不共享的數據，因此同一個進程下的線程上下文切換的開銷要比進程小得多。

當服務器與客戶端 TCP 完成連接後，通過 pthread_create() 函數創建線程，然後將「已連接 Socket」的文件描述符傳遞給線程函數，接着在線程裏和客戶端進行通信，從而達到併發處理的目的。

如果每來一個連接就創建一個線程，線程運行完後，還得操作系統還得銷燬線程，雖說線程切換的上寫文開銷不大，但是如果頻繁創建和銷燬線程，系統開銷也是不小的。

那麼，我們可以使用線程池的方式來避免線程的頻繁創建和銷燬，所謂的線程池，就是提前創建若干個線程，這樣當由新連接建立時，將這個已連接的 Socket 放入到一個隊列裏，然後線程池裏的線程負責從隊列中取出已連接 Socket 進程處理。

需要注意的是，這個隊列是全局的，每個線程都會操作，爲了避免多線程競爭，線程在操作這個隊列前要加鎖。

上面基於進程或者線程模型的，其實還是有問題的。新到來一個 TCP 連接，就需要分配一個進程或者線程，那麼如果要達到 C10K，意味着要一臺機器維護 1 萬個連接，相當於要維護 1 萬個進程 / 線程，操作系統就算死扛也是扛不住的。

I/O 多路複用

既然爲每個請求分配一個進程 / 線程的方式不合適，那有沒有可能只使用一個進程來維護多個 Socket 呢？答案是有的，那就是 I/O 多路複用技術。

一個進程雖然任一時刻只能處理一個請求，但是處理每個請求的事件時，耗時控制在 1 毫秒以內，這樣 1 秒內就可以處理上千個請求，把時間拉長來看，多個請求複用了一個進程，這就是多路複用，這種思想很類似一個 CPU 併發多個進程，所以也叫做時分多路複用。

我們熟悉的 select/poll/epoll 內核提供給用戶態的多路複用系統調用，進程可以通過一個系統調用函數從內核中獲取多個事件。

select/poll/epoll 是如何獲取網絡事件的呢？在獲取事件時，先把所有連接（文件描述符）傳給內核，再由內核返回產生了事件的連接，然後在用戶態中再處理這些連接對應的請求即可。

select/poll/epoll 這是三個多路複用接口，都能實現 C10K 嗎？接下來，我們分別說說它們。

select/poll

select 實現多路複用的方式是，將已連接的 Socket 都放到一個文件描述符集合，然後調用 select 函數將文件描述符集合拷貝到內核裏，讓內核來檢查是否有網絡事件產生，檢查的方式很粗暴，就是通過遍歷文件描述符集合的方式，當檢查到有事件產生後，將此 Socket 標記爲可讀或可寫， 接着再把整個文件描述符集合拷貝回用戶態裏，然後用戶態還需要再通過遍歷的方法找到可讀或可寫的 Socket，然後再對其處理。

所以，對於 select 這種方式，需要進行 2 次「遍歷」文件描述符集合，一次是在內核態裏，一個次是在用戶態裏 ，而且還會發生 2 次「拷貝」文件描述符集合，先從用戶空間傳入內核空間，由內核修改後，再傳出到用戶空間中。

select 使用固定長度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的個數是有限制的，在 Linux 系統中，由內核中的 FD_SETSIZE 限制， 默認最大值爲 1024，只能監聽 0~1023 的文件描述符。

poll 不再用 BitsMap 來存儲所關注的文件描述符，取而代之用動態數組，以鏈表形式來組織，突破了 select 的文件描述符個數限制，當然還會受到系統文件描述符限制。

但是 poll 和 select 並沒有太大的本質區別，都是使用「線性結構」存儲進程關注的 Socket 集合，因此都需要遍歷文件描述符集合來找到可讀或可寫的 Socket，時間複雜度爲 O(n)，而且也需要在用戶態與內核態之間拷貝文件描述符集合，這種方式隨着併發數上來，性能的損耗會呈指數級增長。

epoll

epoll 通過兩個方面，很好解決了 select/poll 的問題。

第一點，epoll 在內核裏使用紅黑樹來跟蹤進程所有待檢測的文件描述字，把需要監控的 socket 通過 epoll_ctl() 函數加入內核中的紅黑樹裏，紅黑樹是個高效的數據結構，增刪查一般時間複雜度是 O(logn)，通過對這棵黑紅樹進行操作，這樣就不需要像 select/poll 每次操作時都傳入整個 socket 集合，只需要傳入一個待檢測的 socket，減少了內核和用戶空間大量的數據拷貝和內存分配。

第二點， epoll 使用事件驅動的機制，內核裏維護了一個鏈表來記錄就緒事件，當某個 socket 有事件發生時，通過回調函數內核會將其加入到這個就緒事件列表中，當用戶調用 epoll_wait() 函數時，只會返回有事件發生的文件描述符的個數，不需要像 select/poll 那樣輪詢掃描整個 socket 集合，大大提高了檢測的效率。

從下圖你可以看到 epoll 相關的接口作用：

epoll 的方式即使監聽的 Socket 數量越多的時候，效率不會大幅度降低，能夠同時監聽的 Socket 的數目也非常的多了，上限就爲系統定義的進程打開的最大文件描述符個數。因而，epoll 被稱爲解決 C10K 問題的利器。

插個題外話，網上文章不少說，epoll_wait 返回時，對於就緒的事件，epoll 使用的是共享內存的方式，即用戶態和內核態都指向了就緒鏈表，所以就避免了內存拷貝消耗。

這是錯的！看過 epoll 內核源碼的都知道，壓根就沒有使用共享內存這個玩意。你可以從下面這份代碼看到， epoll_wait 實現的內核代碼中調用了 __put_user 函數，這個函數就是將數據從內核拷貝到用戶空間。

好了，這個題外話就說到這了，我們繼續！

epoll 支持兩種事件觸發模式，分別是邊緣觸發（edge-triggered，ET）和水平觸發（level-triggered，LT）。

這兩個術語還挺抽象的，其實它們的區別還是很好理解的。

舉個例子，你的快遞被放到了一個快遞箱裏，如果快遞箱只會通過短信通知你一次，即使你一直沒有去取，它也不會再發送第二條短信提醒你，這個方式就是邊緣觸發；如果快遞箱發現你的快遞沒有被取出，它就會不停地發短信通知你，直到你取出了快遞，它才消停，這個就是水平觸發的方式。

這就是兩者的區別，水平觸發的意思是隻要滿足事件的條件，比如內核中有數據需要讀，就一直不斷地把這個事件傳遞給用戶；而邊緣觸發的意思是隻有第一次滿足條件的時候才觸發，之後就不會再傳遞同樣的事件了。

如果使用水平觸發模式，當內核通知文件描述符可讀寫時，接下來還可以繼續去檢測它的狀態，看它是否依然可讀或可寫。所以在收到通知後，沒必要一次執行儘可能多的讀寫操作。

如果使用邊緣觸發模式，I/O 事件發生時只會通知一次，而且我們不知道到底能讀寫多少數據，所以在收到通知後應儘可能地讀寫數據，以免錯失讀寫的機會。因此，我們會循環從文件描述符讀寫數據，那麼如果文件描述符是阻塞的，沒有數據可讀寫時，進程會阻塞在讀寫函數那裏，程序就沒辦法繼續往下執行。所以，邊緣觸發模式一般和非阻塞 I/O 搭配使用，程序會一直執行 I/O 操作，直到系統調用（如 read 和 write）返回錯誤，錯誤類型爲 EAGAIN 或 EWOULDBLOCK。

一般來說，邊緣觸發的效率比水平觸發的效率要高，因爲邊緣觸發可以減少 epoll_wait 的系統調用次數，系統調用也是有一定的開銷的的，畢竟也存在上下文的切換。

select/poll 只有水平觸發模式，epoll 默認的觸發模式是水平觸發，但是可以根據應用場景設置爲邊緣觸發模式。

另外，使用 I/O 多路複用時，最好搭配非阻塞 I/O 一起使用，Linux 手冊關於 select 的內容中有如下說明：

Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.

我谷歌翻譯的結果：

在 Linux 下，select() 可能會將一個 socket 文件描述符報告爲 "準備讀取"，而後續的讀取塊卻沒有。例如，當數據已經到達，但經檢查後發現有錯誤的校驗和而被丟棄時，就會發生這種情況。也有可能在其他情況下，文件描述符被錯誤地報告爲就緒。因此，在不應該阻塞的 socket 上使用 O_NONBLOCK 可能更安全。

簡單點理解，就是多路複用 API 返回的事件並不一定可讀寫的，如果使用阻塞 I/O， 那麼在調用 read/write 時則會發生程序阻塞，因此最好搭配非阻塞 I/O，以便應對極少數的特殊情況。

總結

最基礎的 TCP 的 Socket 編程，它是阻塞 I/O 模型，基本上只能一對一通信，那爲了服務更多的客戶端，我們需要改進網絡 I/O 模型。

比較傳統的方式是使用多進程 / 線程模型，每來一個客戶端連接，就分配一個進程 / 線程，然後後續的讀寫都在對應的進程 / 線程，這種方式處理 100 個客戶端沒問題，但是當客戶端增大到 10000  個時，10000 個進程 / 線程的調度、上下文切換以及它們佔用的內存，都會成爲瓶頸。

爲了解決上面這個問題，就出現了 I/O 的多路複用，可以只在一個進程裏處理多個文件的  I/O，Linux 下有三種提供 I/O 多路複用的 API，分別是：select、poll、epoll。

select 和 poll 並沒有本質區別，它們內部都是使用「線性結構」來存儲進程關注的 Socket 集合。

在使用的時候，首先需要把關注的 Socket 集合通過 select/poll 系統調用從用戶態拷貝到內核態，然後由內核檢測事件，當有網絡事件產生時，內核需要遍歷進程關注 Socket 集合，找到對應的 Socket，並設置其狀態爲可讀 / 可寫，然後把整個 Socket 集合從內核態拷貝到用戶態，用戶態還要繼續遍歷整個 Socket 集合找到可讀 / 可寫的 Socket，然後對其處理。

很明顯發現，select 和 poll 的缺陷在於，當客戶端越多，也就是 Socket 集合越大，Socket 集合的遍歷和拷貝會帶來很大的開銷，因此也很難應對 C10K。

epoll 是解決 C10K 問題的利器，通過兩個方面解決了 select/poll 的問題。

而且，epoll 支持邊緣觸發和水平觸發的方式，而 select/poll 只支持水平觸發，一般而言，邊緣觸發的方式會比水平觸發的效率高。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qVUXY7t515xmXIL8gQ1nBQ

猜你喜歡