一文讀懂高性能網絡編程中的I/O模型
前言
隨著互聯網的發展，面對海量用戶高并發業務，傳統的阻塞式的服務端架構模式已經無能為力。為大家提供有用的高性能網絡編程的I/O模型概覽以及網絡服務進程模型的比較，以揭開設計和實現高性能網絡架構的神秘面紗。
互聯網服務端處理網絡請求的原理
首先看看一個典型互聯網服務端處理網絡請求的典型過程：
由上圖可以看到，主要處理步驟包括：
1）獲取請求數據，客戶端與服務器建立連接發出請求，服務器接受請求（1-3）；
2）構建響應，當服務器接收完請求，并在用戶空間處理客戶端的請求，直到構建響應完成（4）；
3）返回數據，服務器將已構建好的響應再通過內核空間的網絡 I/O 發還給客戶端（5-7）。
設計服務端并發模型時，主要有如下兩個關鍵點：
1）服務器如何管理連接，獲取輸入數據；
2）服務器如何處理請求。
以上兩個關鍵點最終都與操作系統的 I/O 模型以及線程(進程)模型相關，這也是本文和下篇《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》將要介紹的內容。下面先詳細介紹這I/O模型。
“I/O 模型”的基本認識
介紹操作系統的 I/O 模型之前，先了解一下幾個概念：
1）阻塞調用與非阻塞調用；
2）阻塞調用是指調用結果返回之前，當前線程會被掛起，調用線程只有在得到結果之后才會返回；
3）非阻塞調用指在不能立刻得到結果之前，該調用不會阻塞當前線程。
兩者的***區別在于被調用方在收到請求到返回結果之前的這段時間內，調用方是否一直在等待。
阻塞是指調用方一直在等待而且別的事情什么都不做；非阻塞是指調用方先去忙別的事情。
同步處理與異步處理：同步處理是指被調用方得到最終結果之后才返回給調用方；異步處理是指被調用方先返回應答，然后再計算調用結果，計算完最終結果后再通知并返回給調用方。
阻塞、非阻塞和同步、異步的區別（阻塞、非阻塞和同步、異步其實針對的對象是不一樣的）：
1）阻塞、非阻塞的討論對象是調用者；
2）同步、異步的討論對象是被調用者。
recvfrom 函數：
recvfrom 函數(經 Socket 接收數據)，這里把它視為系統調用。
一個輸入操作通常包括兩個不同的階段：
1）等待數據準備好；
2）從內核向進程復制數據。
對于一個套接字上的輸入操作，***步通常涉及等待數據從網絡中到達。當所等待分組到達時，它被復制到內核中的某個緩沖區。第二步就是把數據從內核緩沖區復制到應用進程緩沖區。
實際應用程序在系統調用完成上面的 2 步操作時，調用方式的阻塞、非阻塞，操作系統在處理應用程序請求時，處理方式的同步、異步處理的不同，可以分為 5 種 I/O 模型（下面的章節將逐個展開介紹）。（參考《UNIX網絡編程卷1》）
I/O模型1：阻塞式 I/O 模型(blocking I/O）
在阻塞式 I/O 模型中，應用程序在從調用 recvfrom 開始到它返回有數據報準備好這段時間是阻塞的，recvfrom 返回成功后，應用進程開始處理數據報。
比喻：一個人在釣魚，當沒魚上鉤時，就坐在岸邊一直等。
優點：程序簡單，在阻塞等待數據期間進程/線程掛起，基本不會占用 CPU 資源。
缺點：每個連接需要獨立的進程/線程單獨處理，當并發請求量大時為了維護程序，內存、線程切換開銷較大，這種模型在實際生產中很少使用。
I/O模型2：非阻塞式 I/O 模型(non-blocking I/O）
在非阻塞式 I/O 模型中，應用程序把一個套接口設置為非阻塞，就是告訴內核，當所請求的 I/O 操作無法完成時，不要將進程睡眠。
而是返回一個錯誤，應用程序基于 I/O 操作函數將不斷的輪詢數據是否已經準備好，如果沒有準備好，繼續輪詢，直到數據準備好為止。
比喻：邊釣魚邊玩手機，隔會再看看有沒有魚上鉤，有的話就迅速拉桿。
優點：不會阻塞在內核的等待數據過程，每次發起的 I/O 請求可以立即返回，不用阻塞等待，實時性較好。
缺點：輪詢將會不斷地詢問內核，這將占用大量的 CPU 時間，系統資源利用率較低，所以一般 Web 服務器不使用這種 I/O 模型。
I/O模型3：I/O 復用模型(I/O multiplexing）
在 I/O 復用模型中，會用到 Select 或 Poll 函數或 Epoll 函數(Linux 2.6 以后的內核開始支持)，這兩個函數也會使進程阻塞，但是和阻塞 I/O 有所不同。
這兩個函數可以同時阻塞多個 I/O 操作，而且可以同時對多個讀操作，多個寫操作的 I/O 函數進行檢測，直到有數據可讀或可寫時，才真正調用 I/O 操作函數。
比喻：放了一堆魚竿，在岸邊一直守著這堆魚竿，沒魚上鉤就玩手機。
優點：可以基于一個阻塞對象，同時在多個描述符上等待就緒，而不是使用多個線程(每個文件描述符一個線程)，這樣可以大大節省系統資源。
缺點：當連接數較少時效率相比多線程+阻塞 I/O 模型效率較低，可能延遲更大，因為單個連接處理需要 2 次系統調用，占用時間會有增加。
眾所周之，Nginx這樣的高性能互聯網反向代理服務器大獲成功的關鍵就是得益于Epoll。
I/O模型4：信號驅動式 I/O 模型（signal-driven I/O)
在信號驅動式 I/O 模型中，應用程序使用套接口進行信號驅動 I/O，并安裝一個信號處理函數，進程繼續運行并不阻塞。
當數據準備好時，進程會收到一個 SIGIO 信號，可以在信號處理函數中調用 I/O 操作函數處理數據。
比喻：魚竿上系了個鈴鐺，當鈴鐺響，就知道魚上鉤，然后可以專心玩手機。
優點：線程并沒有在等待數據時被阻塞，可以提高資源的利用率。
缺點：信號 I/O 在大量 IO 操作時可能會因為信號隊列溢出導致沒法通知。
信號驅動 I/O 盡管對于處理 UDP 套接字來說有用，即這種信號通知意味著到達一個數據報，或者返回一個異步錯誤。
但是，對于 TCP 而言，信號驅動的 I/O 方式近乎無用，因為導致這種通知的條件為數眾多，每一個來進行判別會消耗很大資源，與前幾種方式相比優勢盡失。
I/O模型5：異步 I/O 模型（即AIO，全稱asynchronous I/O）
由 POSIX 規范定義，應用程序告知內核啟動某個操作，并讓內核在整個操作（包括將數據從內核拷貝到應用程序的緩沖區）完成后通知應用程序。
這種模型與信號驅動模型的主要區別在于：信號驅動 I/O 是由內核通知應用程序何時啟動一個 I/O 操作，而異步 I/O 模型是由內核通知應用程序 I/O 操作何時完成。
優點：異步 I/O 能夠充分利用 DMA 特性，讓 I/O 操作與計算重疊。
缺點：要實現真正的異步 I/O，操作系統需要做大量的工作。目前 Windows 下通過 IOCP 實現了真正的異步 I/O。
而在 Linux 系統下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下實現高并發網絡編程時都是以 IO 復用模型模式為主。
關于AOI的介紹，請見：《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》。
I/O 模型總結
從上圖中我們可以看出，越往后，阻塞越少，理論上效率也是***。
這五種 I/O 模型中，前四種屬于同步 I/O，因為其中真正的 I/O 操作(recvfrom)將阻塞進程/線程，只有異步 I/O 模型才與 POSIX 定義的異步 I/O 相匹配。
