其實關於這方面的知識，我閱讀的是《UNIX網絡編程:卷一》，書里是以UNIX為中心展開描述的，根據這部分知識，在網上參考了部分資料。以Linux為中心整理了這篇博客。
Linux的I/O模型
和Unix的I/O模型基本一致，Linux下一共有5種I/O模型[1]
- 阻塞式I/O模型；
- 非阻塞式I/O模型；
- I/O復用式模型；
- 信號驅動動式I/O模型
- 異步I/O模型
上面這個列表，算是絕大部分關於Linux I/O模型博客中都會貼出來的。
在上述５種I/O模型中，前4種，其實都可以划分為同步I/O方式，只有最有一種異步I/O模型才使用異步I/O方式。
為什么這么划分呢，就得仔細看看這5種I/O模型到底是什么。
行文須知
下文中對各個模型的描述，都是使用數據報(UDP)套接字作為例子進行說明的。
因為UDP相對與TCP來說比較簡單——要么整個數據報已經收到，要么還沒有——而對於TCP來說，套接字低水位標記等額外變量開始起作用,導致整個概念變得復雜。（加粗字體的內容在寫這篇博客時，並沒有搞清楚是什么，可能后續會陸續搞懂）
一、阻塞式I/O
通常我們使用的I/O都是阻塞式I/O，在編程時使用的大多數也是阻塞式I/O。在默認情況下，所有的套接字(socket)都是阻塞的。下圖解釋了阻塞式I/O模型的流程
上圖中，我們說從調用recvfrom開始到它返回的整段時間內是被阻塞的，recvfrom成功返回后，引用程序才開始處理數據報。
阻塞式I/O的優缺點
優點：
阻塞式I/O很容易上手，一般程序按照read-process的順序進行處理就好。通常來說我們編寫的第一個TCP的C/S程序就是阻塞式I/O模型的。並且該模型定位錯誤，在阻塞時整個進程將被掛起，基本不會占用CPU資源。
缺點:
該模型的缺點也十分明顯。作為服務器，需要處理同時多個的套接字，使用該模型對具有多個的客戶端並發的場景時就顯得力不從心。
當然也有補救方法，我們使用多線程技術來彌補這個缺陷。但是多線程在具有大量連接時，多線程技術帶來的資源消耗也不容小看：
如果我們現在有1000個連接時，就需要開啟1000個線程來處理這些連接，於是就會出現下面的情況
- 線程有內存開銷，假設每個線程需要512K的存放棧，那么1000個連接就需要月512M的內存。當並發量高的時候，這樣的內存開銷是無法接受的。
- 線程切換有CPU開銷，這個CPU開銷體現在上下文切換上，如果線程數越多，那么大多數CPU時間都用於上下文切換，這樣每個線程的時間槽會非常短，CPU真正處理數據的時間就會少了非常多。
二、非阻塞式I/O
有阻塞I/O，那么也會有非阻塞I/O，在上文說過默認情況下，所有的套接字都是阻塞的，那么通過設置套接字的NONBLOCK(一般在open(),socket()等調用中設置)標志或者設置recv、send等輸入輸出函數的MSG_DONTWAIT標志就可以實現非阻塞操作。
那我們來看看非阻塞I/O模型的運行流程吧
可以看到，前三次recvfrom時沒有數據可以返回，此時內核不阻塞進程，轉而立即返回一個EWOULDBLOCK錯誤。第四次調用recvfrom時已經有一個數據報准備好了，此時它將被復制到應用進程的緩沖區，於是recvfrom調用成功返回。
當一個應用進程像這樣對一個非阻塞描述符循環調用recvfrom時，我們稱之為輪詢(polling)
非阻塞式I/O的優缺點
優點：
這種I/O方式也有明顯的優勢，即不會阻塞在內核的等待數據過程，每次發起的I/O請求可以立即返回，不用阻塞等待。在數據量收發不均，等待時間隨機性極強的情況下比較常用。
缺點
輪詢這一個特征就已近暴露了這個I/O模型的缺點。輪詢將會不斷地詢問內核，這將占用大量的CPU時間，系統資源利用率較低。同時，該模型也不便於使用，需要編寫復雜的代碼。
三、I/O復用模型
上文中說到，在出現大量的鏈接時，使用多線程+阻塞I/O的編程模型會占用大量的內存。那么I/O復用技術在內存占用方面，就有着很好的控制。
當前的高性能反向代理服務器Nginx使用的就是I/O復用模型(epoll),它以高性能和低資源消耗著稱，在大規模並發上也有着很好的表現。
那么，我們就來看一看I/O復用模型的面目吧
那到底什么是I/O復用(I/O multiplexing)。根據我的理解，復用指的是復用線程，從阻塞式I/O來看，基本一個套接字就霸占了整個線程。例如當對一個套接字調用recvfrom調用時，整個線程將被阻塞掛起，直到數據報准備完畢。
多路復用就是復用一個線程的I/O模型，Linux中擁有幾個調用來實現I/O復用的系統調用——select,poll,epoll（Linux 2.6+）
線程將阻塞在上面的三個系統調用中的某一個之上，而不是阻塞在真正的I/O系統調用上。I/O復用允許對多個套接字進行監聽，當有某個套接字准備就緒(可讀/可寫/異常)時，系統調用將會返回。
然后我們可能將重新啟用一個線程並調用recvfrom來將特定套接字中的數據報從內核緩沖區復制到進程緩沖區。
I/O復用模型的優缺點
優點
I/O復用技術的優勢在於，只需要使用一個線程就可以管理多個socket，系統不需要建立新的進程或者線程，也不必維護這些線程和進程，所以它也是很大程度上減少了資源占用。
另外I/O復用技術還可以同時監聽不同協議的套接字
缺點
在只處理連接數較小的場合，使用select的服務器不一定比多線程+阻塞I/O模型效率高，可能延遲更大，因為單個連接處理需要2次系統調用，占用時間會有增加。
四、信號驅動式I/O模型
當然你可能會想到使用信號這一機制來避免I/O時線程陷入阻塞狀態。那么內核開發者怎么可能會想不到。那么我們來看看信號驅動式I/O模型的具體流程
從上圖可以看到，我們首先開啟套接字的信號驅動式I/O功能，並通過sigaction系統調用來安裝一個信號處理函數，我們進程不會被阻塞。
當數據報准備好讀取時，內核就為該進程產生一個SIGIO信號，此時我們可以在信號處理函數中調用recvfrom讀取數據報，並通知數據已經准備好，正在等待處理。
信號驅動式I/O模型的優缺點
優點
很明顯，我們的線程並沒有在等待數據時被阻塞，可以提高資源的利用率
缺點
其實在Unix中，信號是一個被過度設計的機制(這句話來自知乎大神,有待考究)
信號I/O在大量IO操作時可能會因為信號隊列溢出導致沒法通知——這個是一個非常嚴重的問題。
稍微歇息一下，還記得我們前面說過這4種I/O模型都可以划分為同步I/O方式，那我們來看看為什么。
了解了４種I/O模型的調用過程后，我們可以注意到，在數據從內核緩沖區復制到用戶緩沖區時，都需要進程顯示調用recvfrom，並且這個復制過程是阻塞的。
也就是說真正I/O過程(這里的I/O有點狹義，指的是內核緩沖區到用戶緩沖區)是同步阻塞的，不同的是各個I/O模型在數據報准備好之前的動作不一樣。
下面所說的異步I/O模型將會有所不同
五、異步I/O模型
異步I/O，是由POSIX規范定義的。這個規范定義了一些函數，這些函數的工作機制是：告知內核啟動某個操作，並讓內核在整個操作完成后再通知我們。(包括將數據從內核復制到我們進程的緩沖區)
照樣，先看模型的流程
全程沒有阻塞，真正做到了異步
異步的優點還用說明嗎？
but
異步I/O在Linux2.6才引入，而且到現在仍然未成熟。
雖然有知名的異步I/O庫 glibc，但是聽說glibc采用多線程模擬，但存在一些bug和設計上的不合理。wtf？多線程模擬，那還有殺卵用。
引入異步I/O可能會代碼難以理解的問題，這個站在軟件工程的角度也是需要細細衡量的。
總結
關於對Linux 的I/O模型的學習就寫到這里，每個模型都有自己使用的范圍
Talk is cheap, show me the code
實踐出真知。
關於I/O模型的實驗代碼會找個時間放到我的github倉庫中。
參考文獻
- 《Unix網絡編程卷1：套接字聯網API》（第3版）人民郵電出版社