其實關於這方面的知識，我閱讀的是《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模型的實驗代碼會在2017年10月前放到我的github倉庫中。

參考文獻

1. 《Unix網路編程捲1：套接字聯網API》（第3版）人民郵電出版社