1、前言
隨著互聯(lián)網(wǎng)的發(fā)展，面對海量用戶高并發(fā)業(yè)務，傳統(tǒng)的阻塞式的服務端架構模式已經(jīng)無能為力。本文（和下篇《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》）旨在為大家提供有用的高性能網(wǎng)絡編程的I/O模型概覽以及網(wǎng)絡服務進程模型的比較，以揭開設計和實現(xiàn)高性能網(wǎng)絡架構的神秘面紗。
限于篇幅原因，請將本文與《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》連起來讀，這樣會讓知識更連貫。
學習交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1935-1-1.html）
2、關于作者
陳彩華（caison）：主要從事服務端開發(fā)、需求分析、系統(tǒng)設計、優(yōu)化重構工作，主要開發(fā)語言是 Java，現(xiàn)任廣州貝聊服務端研發(fā)工程師。
關于廣州貝聊：
廣州市貝聊信息科技有限公司成立于2013年8月21日，是一家專注于搭建幼兒園家園共育平臺的信息科技公司。
公司產(chǎn)品“貝聊”是中國幼兒園家長工作平臺，致力于通過互聯(lián)網(wǎng)產(chǎn)品及定制化解決方案，幫助幼兒園解決展示、通知、溝通等家長工作中的痛點，促進家園關系和諧。貝聊是威創(chuàng)股份（A股幼教第一股）、清華啟迪、網(wǎng)易聯(lián)手投資的唯一品牌。
截止目前，“貝聊”已覆蓋全國31省份的5萬所幼兒園及機構，注冊用戶超過1000萬，用戶次月留存率高達74%，復合增長率為18.94%，領跑全行業(yè)。
3、C10K問題系列文章
本文是C10K問題系列文章中的第5篇，總目錄如下：
《高性能網(wǎng)絡編程(一)：單臺服務器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡編程(二)：上一個10年，著名的C10K并發(fā)連接問題》
《高性能網(wǎng)絡編程(三)：下一個10年，是時候考慮C10M并發(fā)問題了》
《高性能網(wǎng)絡編程(四)：從C10K到C10M高性能網(wǎng)絡應用的理論探索》
《高性能網(wǎng)絡編程(五)：一文讀懂高性能網(wǎng)絡編程中的I/O模型》（本文）
《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》
《高性能網(wǎng)絡編程經(jīng)典：《The C10K problem(英文)》[附件下載]》
4、互聯(lián)網(wǎng)服務端處理網(wǎng)絡請求的原理
首先看看一個典型互聯(lián)網(wǎng)服務端處理網(wǎng)絡請求的典型過程：
由上圖可以看到，主要處理步驟包括：
1）獲取請求數(shù)據(jù)，客戶端與服務器建立連接發(fā)出請求，服務器接受請求（1-3）；
2）構建響應，當服務器接收完請求，并在用戶空間處理客戶端的請求，直到構建響應完成（4）；
3）返回數(shù)據(jù)，服務器將已構建好的響應再通過內(nèi)核空間的網(wǎng)絡 I/O 發(fā)還給客戶端（5-7）。
設計服務端并發(fā)模型時，主要有如下兩個關鍵點：
1）服務器如何管理連接，獲取輸入數(shù)據(jù)；
2）服務器如何處理請求。
以上兩個關鍵點最終都與操作系統(tǒng)的 I/O 模型以及線程(進程)模型相關，這也是本文和下篇《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》將要介紹的內(nèi)容。下面先詳細介紹這I/O模型。
5、“I/O 模型”的基本認識
介紹操作系統(tǒng)的 I/O 模型之前，先了解一下幾個概念：
1）阻塞調(diào)用與非阻塞調(diào)用；
2）阻塞調(diào)用是指調(diào)用結果返回之前，當前線程會被掛起，調(diào)用線程只有在得到結果之后才會返回；
3）非阻塞調(diào)用指在不能立刻得到結果之前，該調(diào)用不會阻塞當前線程。
兩者的最大區(qū)別在于被調(diào)用方在收到請求到返回結果之前的這段時間內(nèi)，調(diào)用方是否一直在等待。
阻塞是指調(diào)用方一直在等待而且別的事情什么都不做；非阻塞是指調(diào)用方先去忙別的事情。
同步處理與異步處理：同步處理是指被調(diào)用方得到最終結果之后才返回給調(diào)用方；異步處理是指被調(diào)用方先返回應答，然后再計算調(diào)用結果，計算完最終結果后再通知并返回給調(diào)用方。
阻塞、非阻塞和同步、異步的區(qū)別（阻塞、非阻塞和同步、異步其實針對的對象是不一樣的）：
1）阻塞、非阻塞的討論對象是調(diào)用者；
2）同步、異步的討論對象是被調(diào)用者。
recvfrom 函數(shù)：
recvfrom 函數(shù)(經(jīng) Socket 接收數(shù)據(jù))，這里把它視為系統(tǒng)調(diào)用。
一個輸入操作通常包括兩個不同的階段：
1）等待數(shù)據(jù)準備好；
2）從內(nèi)核向進程復制數(shù)據(jù)。
對于一個套接字上的輸入操作，第一步通常涉及等待數(shù)據(jù)從網(wǎng)絡中到達。當所等待分組到達時，它被復制到內(nèi)核中的某個緩沖區(qū)。第二步就是把數(shù)據(jù)從內(nèi)核緩沖區(qū)復制到應用進程緩沖區(qū)。
實際應用程序在系統(tǒng)調(diào)用完成上面的 2 步操作時，調(diào)用方式的阻塞、非阻塞，操作系統(tǒng)在處理應用程序請求時，處理方式的同步、異步處理的不同，可以分為 5 種 I/O 模型（下面的章節(jié)將逐個展開介紹）。（參考《UNIX網(wǎng)絡編程卷1》）
6、I/O模型1：阻塞式 I/O 模型(blocking I/O）
在阻塞式 I/O 模型中，應用程序在從調(diào)用 recvfrom 開始到它返回有數(shù)據(jù)報準備好這段時間是阻塞的，recvfrom 返回成功后，應用進程開始處理數(shù)據(jù)報。
比喻：一個人在釣魚，當沒魚上鉤時，就坐在岸邊一直等。
優(yōu)點：程序簡單，在阻塞等待數(shù)據(jù)期間進程/線程掛起，基本不會占用 CPU 資源。
缺點：每個連接需要獨立的進程/線程單獨處理，當并發(fā)請求量大時為了維護程序，內(nèi)存、線程切換開銷較大，這種模型在實際生產(chǎn)中很少使用。
7、I/O模型2：非阻塞式 I/O 模型(non-blocking I/O）
在非阻塞式 I/O 模型中，應用程序把一個套接口設置為非阻塞，就是告訴內(nèi)核，當所請求的 I/O 操作無法完成時，不要將進程睡眠。
而是返回一個錯誤，應用程序基于 I/O 操作函數(shù)將不斷的輪詢數(shù)據(jù)是否已經(jīng)準備好，如果沒有準備好，繼續(xù)輪詢，直到數(shù)據(jù)準備好為止。
比喻：邊釣魚邊玩手機，隔會再看看有沒有魚上鉤，有的話就迅速拉桿。
優(yōu)點：不會阻塞在內(nèi)核的等待數(shù)據(jù)過程，每次發(fā)起的 I/O 請求可以立即返回，不用阻塞等待，實時性較好。
缺點：輪詢將會不斷地詢問內(nèi)核，這將占用大量的 CPU 時間，系統(tǒng)資源利用率較低，所以一般 Web 服務器不使用這種 I/O 模型。
8、I/O模型3：I/O 復用模型(I/O multiplexing）
在 I/O 復用模型中，會用到 Select 或 Poll 函數(shù)或 Epoll 函數(shù)(Linux 2.6 以后的內(nèi)核開始支持)，這兩個函數(shù)也會使進程阻塞，但是和阻塞 I/O 有所不同。
這兩個函數(shù)可以同時阻塞多個 I/O 操作，而且可以同時對多個讀操作，多個寫操作的 I/O 函數(shù)進行檢測，直到有數(shù)據(jù)可讀或可寫時，才真正調(diào)用 I/O 操作函數(shù)。
比喻：放了一堆魚竿，在岸邊一直守著這堆魚竿，沒魚上鉤就玩手機。
優(yōu)點：可以基于一個阻塞對象，同時在多個描述符上等待就緒，而不是使用多個線程(每個文件描述符一個線程)，這樣可以大大節(jié)省系統(tǒng)資源。
缺點：當連接數(shù)較少時效率相比多線程+阻塞 I/O 模型效率較低，可能延遲更大，因為單個連接處理需要 2 次系統(tǒng)調(diào)用，占用時間會有增加。
眾所周之，Nginx這樣的高性能互聯(lián)網(wǎng)反向代理服務器大獲成功的關鍵就是得益于Epoll。
9、I/O模型4：信號驅(qū)動式 I/O 模型（signal-driven I/O)
在信號驅(qū)動式 I/O 模型中，應用程序使用套接口進行信號驅(qū)動 I/O，并安裝一個信號處理函數(shù)，進程繼續(xù)運行并不阻塞。
當數(shù)據(jù)準備好時，進程會收到一個 SIGIO 信號，可以在信號處理函數(shù)中調(diào)用 I/O 操作函數(shù)處理數(shù)據(jù)。
比喻：魚竿上系了個鈴鐺，當鈴鐺響，就知道魚上鉤，然后可以專心玩手機。
優(yōu)點：線程并沒有在等待數(shù)據(jù)時被阻塞，可以提高資源的利用率。
缺點：信號 I/O 在大量 IO 操作時可能會因為信號隊列溢出導致沒法通知。
信號驅(qū)動 I/O 盡管對于處理 UDP 套接字來說有用，即這種信號通知意味著到達一個數(shù)據(jù)報，或者返回一個異步錯誤。
但是，對于 TCP 而言，信號驅(qū)動的 I/O 方式近乎無用，因為導致這種通知的條件為數(shù)眾多，每一個來進行判別會消耗很大資源，與前幾種方式相比優(yōu)勢盡失。
10、I/O模型5：異步 I/O 模型（即AIO，全稱asynchronous I/O）
由 POSIX 規(guī)范定義，應用程序告知內(nèi)核啟動某個操作，并讓內(nèi)核在整個操作（包括將數(shù)據(jù)從內(nèi)核拷貝到應用程序的緩沖區(qū)）完成后通知應用程序。
這種模型與信號驅(qū)動模型的主要區(qū)別在于：信號驅(qū)動 I/O 是由內(nèi)核通知應用程序何時啟動一個 I/O 操作，而異步 I/O 模型是由內(nèi)核通知應用程序 I/O 操作何時完成。
優(yōu)點：異步 I/O 能夠充分利用 DMA 特性，讓 I/O 操作與計算重疊。
缺點：要實現(xiàn)真正的異步 I/O，操作系統(tǒng)需要做大量的工作。目前 Windows 下通過 IOCP 實現(xiàn)了真正的異步 I/O。
而在 Linux 系統(tǒng)下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下實現(xiàn)高并發(fā)網(wǎng)絡編程時都是以 IO 復用模型模式為主。
關于AOI的介紹，請見：《Java新一代網(wǎng)絡編程模型AIO原理及Linux系統(tǒng)AIO介紹》。
11、5 種 I/O 模型總結
從上圖中我們可以看出，越往后，阻塞越少，理論上效率也是最優(yōu)。
這五種 I/O 模型中，前四種屬于同步 I/O，因為其中真正的 I/O 操作(recvfrom)將阻塞進程/線程，只有異步 I/O 模型才與 POSIX 定義的異步 I/O 相匹配。
（本文下篇《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》已發(fā)布，敬請閱讀！）
附錄：更多網(wǎng)絡編程精華文章
[1] 網(wǎng)絡編程基礎資料：
《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報協(xié)議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網(wǎng)絡通訊協(xié)議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《不為人知的網(wǎng)絡編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網(wǎng)絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》
《網(wǎng)絡編程懶人入門(一)：快速理解網(wǎng)絡通信協(xié)議（上篇）》
《網(wǎng)絡編程懶人入門(二)：快速理解網(wǎng)絡通信協(xié)議（下篇）》
《網(wǎng)絡編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》
《網(wǎng)絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網(wǎng)絡編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《技術掃盲：新一代基于UDP的低延時網(wǎng)絡傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術實踐分享》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結：請求速度、弱網(wǎng)適應、安全保障》
《聊聊iOS中網(wǎng)絡編程長連接的那些事》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡優(yōu)化方法總結》
《IPv6技術詳解：基本概念、應用現(xiàn)狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現(xiàn)狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》
《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》
《腦殘式網(wǎng)絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《以網(wǎng)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術挑戰(zhàn)》
>> 更多同類文章 ……
[2] NIO高性能異步網(wǎng)絡編程資料：
《Java新一代網(wǎng)絡編程模型AIO原理及Linux系統(tǒng)AIO介紹》
《有關“為何選擇Netty”的11個疑問及解答》
《開源NIO框架八卦——到底是先有MINA還是先有Netty?》
《選Netty還是Mina：深入研究與對比（一）》
《選Netty還是Mina：深入研究與對比（二）》
《NIO框架入門(一)：服務端基于Netty4的UDP雙向通信Demo演示》
《NIO框架入門(二)：服務端基于MINA2的UDP雙向通信Demo演示》
《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰(zhàn)》
《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺UDP雙向通信實戰(zhàn)》
《Netty 4.x學習（一）：ByteBuf詳解》
《Netty 4.x學習（二）：Channel和Pipeline詳解》
《Netty 4.x學習（三）：線程模型詳解》
《Apache Mina框架高級篇（一）：IoFilter詳解》
《Apache Mina框架高級篇（二）：IoHandler詳解》
《MINA2 線程原理總結（含簡單測試實例）》
《Apache MINA2.0 開發(fā)指南（中文版）[附件下載]》
《MINA、Netty的源代碼（在線閱讀版）已整理發(fā)布》
《解決MINA數(shù)據(jù)傳輸中TCP的粘包、缺包問題（有源碼）》
《解決Mina中多個同類型Filter實例共存的問題》
《實踐總結：Netty3.x升級Netty4.x遇到的那些坑（線程篇）》
《實踐總結：Netty3.x VS Netty4.x的線程模型》
《詳解Netty的安全性：原理介紹、代碼演示（上篇）》
《詳解Netty的安全性：原理介紹、代碼演示（下篇）》
《詳解Netty的優(yōu)雅退出機制和原理》
《NIO框架詳解：Netty的高性能之道》
《Twitter：如何使用Netty 4來減少JVM的GC開銷（譯文）》
《絕對干貨：基于Netty實現(xiàn)海量接入的推送服務技術要點》
《Netty干貨分享：京東京麥的生產(chǎn)級TCP網(wǎng)關技術實踐總結》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-1935-1-1.html）