這次，我們以最簡單的方式 Socket 網絡模型，一步一步地過渡到 I/O 多路復用。

但我不會具體說到每個系統調用的參數，這方面書上肯定比我說得詳細。

最基本的 Socket 模型

要想客戶端和伺服器能在網絡中通信，那必須得使用 Socket 編程，它是進程間通信里比較特別的方式，特別之處在於它是可以跨主機間通信。

Socket 的中文名叫作插口，乍一看還挺迷惑的。事實上，雙方要進行網絡通信前，各自得創建一個 Socket，這相當於客戶端和伺服器都開了一個「口子」，雙方讀取和發送數據的時候，都通過這個「口子」。這樣一看，是不是覺得很像弄了一根網線，一頭插在客戶端，一頭插在服務端，然後進行通信。

創建 Socket 的時候，可以指定網絡層使用的是 IPv4 還是 IPv6，傳輸層使用的是 TCP 還是 UDP。

UDP 的 Socket 編程相對簡單些，這裡我們只介紹基於 TCP 的 Socket 編程。

伺服器的程序要先跑起來，然後等待客戶端的連接和數據，我們先來看看服務端的 Socket 編程過程是怎樣的。

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

綁定埠的目的：當內核收到 TCP 報文，通過 TCP 頭裡面的埠號，來找到我們的應用程式，然後把數據傳遞給我們。
綁定 IP 地址的目的：一台機器是可以有多個網卡的，每個網卡都有對應的 IP 地址，當綁定一個網卡時，內核在收到該網卡上的包，才會發給我們；

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

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

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

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

一個是還沒完全建立連接的隊列，稱為 TCP 半連接隊列，這個隊列都是沒有完成三次握手的連接，此時服務端處於syn_rcvd 的狀態；
一個是一件建立連接的隊列，稱為 TCP 全連接隊列，這個隊列都是完成了三次握手的連接，此時服務端處於 established狀態；

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

注意，監聽的 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 的指針，比如：

當接收報文時，從網卡驅動開始，通過協議棧層層往上傳送數據報，通過增加 skb->data 的值，來逐步剝離協議首部。
當要發送報文時，創建 sk_buff 結構體，數據緩存區的頭部預留足夠的空間，用來填充各層首部，在經過各下層協議時，通過減少 skb->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 次方。

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

文件描述符，Socket 實際上是一個文件，也就會對應一個文件描述符。在 Linux 下，單個進程打開的文件描述符數是有限制的，沒有經過修改的值一般都是 1024，不過我們可以通過 ulimit 增大文件描述符的數目；
系統內存，每個 TCP 連接在內核中都有對應的數據結構，代表著每個連接都是會占用一定內存的；

那如果伺服器的內存只有 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）。

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

使用邊緣觸發模式時，當被監控的 Socket 描述符上有可讀事件發生時，伺服器端只會從 epoll_wait 中甦醒一次，即使進程沒有調用 read 函數從內核讀取數據，也依然只甦醒一次，因此我們程序要保證一次性將內核緩衝區的數據讀取完；
使用水平觸發模式時，當被監控的 Socket 上有可讀事件發生時，伺服器端不斷地從 epoll_wait 中甦醒，直到內核緩衝區數據被 read 函數讀完才結束，目的是告訴我們有數據需要讀取；

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

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

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

如果使用邊緣觸發模式，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 在內核里使用「紅黑樹」來關注進程所有待檢測的 Socket，紅黑樹是個高效的數據結構，增刪查一般時間複雜度是 O(logn)，通過對這棵黑紅樹的管理，不需要像 select/poll 在每次操作時都傳入整個 Socket 集合，減少了內核和用戶空間大量的數據拷貝和內存分配。
epoll 使用事件驅動的機制，內核里維護了一個「鍊表」來記錄就緒事件，只將有事件發生的 Socket 集合傳遞給應用程式，不需要像 select/poll 那樣輪詢掃描整個集合（包含有和無事件的 Socket ），大大提高了檢測的效率。

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