前言

你知道Netty為什么性能這么高嗎？你知道Redis為什么單線程如此之快嗎？這都和底層的網絡IO模型有關系，所以掌握網絡IO模型真的很重要，是一個基礎，對你更好的理解其他應用幫助非常大，今天我們就好好來聊聊Linux的5種網絡IO模型。

IO工作原理

我們的應用大多數情況都是部署在linux系統中，linux系統也是一種應用，它是基于計算機硬件的一種操作系統軟件。當我們接收一次網絡傳輸，計算機硬件的網卡會從網絡中將讀到的字節流寫到linux的buffer緩沖區內存中，然后用戶空間會調用linux對外暴露的接口，將linux內核空間buffer內存中的數據拷貝到用戶空間的buffer區。這一次網絡讀取就是磁盤IO，同理從磁盤中讀取，也是遵循一樣的機制。

IO的性能瓶頸主要是下面兩個階段：

• 準備階段，指數據從網絡網卡或本地存儲器讀取到內核的過程
• 復制階段，指將內核緩沖區中的數據拷貝至用戶態的進程緩沖區

所以，Linux系統中提供了五種IO模型來提高性能，它們分別為BIO、NIO、多路復用、信號驅動、AIO，從性能上來說，它們屬于依次遞進的關系，但越靠后的IO模型實現也越為復雜。

1. 阻塞IO模型BIO

當用戶應用線程調用linux操作系統的recvfrom?函數讀取數據的時候，如果內核的buffer?內存中沒有數據，那么用戶線程會阻塞等待，直到內核的buffer?內存中有數據了，才去將內核的buffer內存中的數據拷貝到用戶應用內存中。

打比方理解：

比如你給女神發一條短信, 說我來找你了, 然后就默默的一直等著女神下樓, 這個期間除了等待你不會做其他事情, 屬于備胎做法。也就是說線程會一直阻塞等待內核把數據準備好，然后將數據copy到用戶空間。

優點：

• 開發簡單，容易入門；
• 在阻塞等待期間，用戶線程掛起，在掛起期間不會占用CPU資源。

缺點：

• 在BIO這種模型中，為了支持并發請求，通常會采用多線程的方式，并發過高時會導致創建大量線程，造成頻繁的上下文切換，甚至系統崩潰

在Java常用的Tomcat服務器中，Tomcat7.x版本以下默認的IO類型也是BIO，但是Tomcat中對BIO模型稍微進行了優化，通過線程池做了限制，所以避免出現并發過高而系統崩潰的情況。

2. 非阻塞IO模型NIO

當用戶應用線程調用linux操作系統的recvfrom?函數讀取數據的時候，如果內核的buffer?內存中沒有數據，那么用戶線程會直接拿到結果（沒有數據）不會阻塞等待，于是又會發起一次recvfrom函數調用，直到內核的buffer內存中有數據了，才去將內核的buffer內存中的數據拷貝到用戶應用內存中。

在非阻塞IO模型中，用戶線程需要不斷地詢問內核數據是否就緒，也就說非阻塞IO不會交出CPU，而會一直占用CPU。

打比方理解：

比如你給女神發短信, 如果不回, 接著再發, 一直發到女神下樓, 這個期間你除了發短信等待不會做其他事情, 屬于專一做法。同理，用戶線程無需等待內核數據準備結果，直接返回，然后通過輪詢去問結果，如果結果為準備好，進程把數據copy到用戶空間。

優點：

• 每次發起IO調用，在內核等待數據的過程中可以立即返回，用戶線程不會阻塞。

缺點：

• 多個線程不斷輪詢內核是否有數據，會占用大量CPU時間。

NIO相對來說較為雞肋，因此目前大多數的NIO技術并非采用這種多線程的模型，而是基于單線程的多路復用模型實現的，Java中支持的NIO模型亦是如此。

3. 多路復用IO模型

前面提到NIO由于線程在不斷的輪詢查看數據是否準備就緒，造成CPU開銷較大。既然說是由于大量無效的輪詢造成CPU占用過高，那么等內核中的數據準備好了之后，再去詢問數據是否就緒是不是就可以了？答案是Yes。這就是我們多路復用IO模型的設計思想。

多路復用IO模型是基于文件描述符File Descriptor?實現的，文件描述符是打開現存文件或新建文件時，內核會返回一個文件描述符。讀寫文件也需要使用文件描述符來指定待讀寫的文件。文件包含音頻文件，常規文件，硬件設備等等，也包括網絡套接字（Socket）。

IO多路復用就是利用Linux的內核單線程去監聽多個文件描述符，并在某個文件描述符可讀、可寫的時候接收到通知，避免無效的等待，充分利用CPU資源。

關于監聽的策略，在linux中提供了3種模式，也就是3個函數，分別是 select、poll、epoll，如下圖所示。

• select?時間復雜度O(n)，它僅僅知道了，有I/O事件發生了，卻并不知道是哪幾個流（可能有一個，多個，甚至全部），我們只能無差別輪詢所有流，找出能讀出數據，或者寫入數據的流，對他們進行操作。所以select具有O(n)的無差別輪詢復雜度，同時處理的流越多，無差別輪詢時間就越長，而且最多支持的連接數量是1024個。
• poll?（翻譯：輪詢）時間復雜度O(n)，poll本質上和select沒有區別，它將用戶傳入的數組拷貝到內核空間，然后查詢每個fd對應的設備狀態， 但是它沒有最大連接數的限制，原因是它是基于鏈表來存儲的。
• epoll?時間復雜度O(1)，epoll可以理解為event poll，不同于忙輪詢和無差別輪詢，epoll會把哪個流發生了怎樣的I/O事件通知我們。所以我們說epoll實際上是事件驅動（每個事件關聯上fd）的，此時我們對這些流的操作都是有意義的。（復雜度降低到了O(1)）。

打個比方理解：

IO多路復用相當于找一個宿管大媽來幫你監視下樓的女生, 這個期間你可以些其他的事情. 例如可以順便看看其他妹子,玩玩王者榮耀, 上個廁所等等。IO復用又包括 select、poll、epoll 模式。那么它們的區別是什么?

• select?大媽 每一個女生下樓, select大媽都不知道這個是不是你的女神, 她需要一個一個詢問, 并且select大媽能力還有限, 最多一次幫你監視1024個妹子。
• poll大媽不限制盯著女生的數量, 只要是經過宿舍樓門口的女生, 都會幫你去問是不是你女神。
• epoll大媽不限制盯著女生的數量, 并且也不需要一個一個去問. 那么如何做呢? epoll大媽會為每個進宿舍樓的女生臉上貼上一個大字條,上面寫上女生自己的名字, 只要女生下樓了, epoll大媽就知道這個是不是你女神了, 然后大媽再通知你。

通知你之后，你需要到女生宿舍門口，把女神帶回自己宿色。

優點：

• 系統不必創建維護大量線程，只使用一個線程，一個選擇器即可同事處理成千上萬個連接，大大減少系統開銷。

缺點：

• 本質上，它還是同步的，數據準備好后，拷貝階段依然是阻塞的。

如果處理的連接數不是很高的話，使用select/epoll的web server?不一定比使用mutil-threading + blocking IO的web server?性能更好，可能延遲還更大。select/epoll 的優勢并不是對于單個連接能處理得更好，而是在于性能更多的連接，比如Redis、Netty都是采用這種IO模型。

4. 信號驅動IO模型

當用戶應用線程調用linux操作系統的sigaction函數，直接返回，然后該線程去做其他事情了，當有數據來了的時候，內核空間會去遞交信號給用戶空間，此時用戶空間會調用recvfrom函數去將數據從內核空間緩沖區拷貝到用戶空間緩沖區，并處理數據。

打比方理解：

你給女神發短信，她下樓了主動通知你，你這時候在宿舍門口等著把她待會自己宿舍。同比，進程無需等待內核數據準備結果，直接返回，事件信號通知進程結果，進程把數據copy到用戶空間。

優點：

• 從一定意義上實現了異步，也就是數據的準備階段是異步非阻塞執行的

缺點：

• 當調用的線程過多，對應的信號量會增多，SIGIO函數處理不及時，會導致保存信號的隊列溢出
• 內核空間與用戶空間頻繁的進行信號量的交互，性能很差。

現實中這種模式用的不多，就不展開闡述了。縱觀上述的所有IO模型：BIO、NIO、多路復用、信號驅動，本質上從內核緩沖區拷貝數據到程序緩沖區的過程都是阻塞的，如果想要做到真正意義上的異步非阻塞IO，那么就牽扯到了異步IO模型。

5. 異步IO模型AIO

異步非阻塞模型，該模型是真正意義上的異步非阻塞式IO，數據準備與復制階段都是異步非阻塞的。

在該模型中，首先用戶進程中會創建一個Sigio?信號處理程序，然后會系統調用sigaction?信號處理函數，緊接著內核會直接讓用戶進程中的線程返回，用戶進程可在這期間干別的工作，當內核中的數據準備好之后，內核會生成一個Sigio?信號，通知對應的用戶進程數據已準備就緒，然后由用戶進程在觸發一個recvfrom的系統調用，從內核中將數據拷貝出來進行處理。

打比方理解：

你給女神發短信，女神準備好了并且主動來到你宿舍通知你，你開門。 同比，應用進程把IO請求傳給內核后，完全由內核去操作文件拷貝到用戶空間。內核完成相關操作后，會發信號告訴應用進程本次IO已經完成。

優點：

• 真正實現了異步非阻塞，吞吐量高

缺點：

• 對內核有要求，比如Linux系統中，異步IO在2.6才引入

總結

本文講解了Linux系統中5中IO模型，其中前面4種都屬于同步IO，因為數據拷貝階段都是處于阻塞狀態，只有異步IO模型才真正實現了異步非阻塞。

? ?