一 IO模型：
Stevens在文章中一共比較了五種IO Model：
* blocking IO#阻塞模型 * nonblocking IO#非阻塞 * IO multiplexing#多路復用 * signal driven IO#信號驅動 * asynchronous IO#異步 由signal driven IO（信號驅動IO）在實際中並不常用，所以主要介紹其余四種IO Model。
再說一下IO發生時涉及的對象和步驟。對於一個network IO (這里我們以read舉例)，它會涉及到兩個系統對象，一個是調用這個IO的process (or thread)，另一個就是系統內核(kernel)。當一個read操作發生時，該操作會經歷兩個階段：
#1）等待數據准備 (Waiting for the data to be ready)
#2）將數據從內核拷貝到進程中(Copying the data from the kernel to the process)
記住這兩點很重要，因為這些IO模型的區別就是在兩個階段上各有不同的情況。
#1、輸入操作：read、readv、recv、recvfrom、recvmsg共5個函數，如果會阻塞狀態，則會經理wait data和copy data兩個階段，如果設置為非阻塞則在wait 不到data時拋出異常
#2、輸出操作：write、writev、send、sendto、sendmsg共5個函數，在發送緩沖區滿了會阻塞在原地，如果設置為非阻塞，則會拋出異常
#3、接收外來鏈接：accept，與輸入操作類似
#4、發起外出鏈接：connect，與輸出操作類似
二 下面我們來首先講blocking IO：在這種情況下沒辦法實現並發，因為遇到IO就阻塞。直到IO阻塞結束才會繼續執行。
由上圖我們可以看出，對於blocking IO模型。在傳輸數據的過程中，首先向操作系統發請求，經過等待數據，和copy數據的過程。
recv:經過本地copy data和wait data。
而send：只有copy data。
其實copy的過程就是從應用程序到操作系統的過程。
所以，blocking IO的特點就是在IO執行的兩個階段（等待數據和拷貝數據兩個階段）都被block了。
實際上，除非特別指定，幾乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。這給網絡編程帶來了一個很大的問題，如在調用recv(1024)的同時，線程將被阻塞，在此期間，線程將無法執行任何運算或響應任何的網絡請求。
一個簡單的解決方案：
#在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。
該方案的問題是：
#開啟多進程或都線程的方式，在遇到要同時響應成百上千路的連接請求，則無論多線程還是多進程都會嚴重占據系統資源，降低系統對外界響應效率，
而且線程與進程本身也更容易進入假死狀態。
改進方案：
#很多程序員可能會考慮使用“線程池”或“連接池”。“線程池”旨在減少創建和銷毀線程的頻率，其維持一定合理數量的線程，並讓空閑的線程重新承擔新的執行任務。
“連接池”維持連接的緩存池，盡量重用已有的連接、減少創建和關閉連接的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，
如websphere、tomcat和各種數據庫等。
改進后方案其實也存在着問題：
#“線程池”和“連接池”技術也只是在一定程度上緩解了頻繁調用IO接口帶來的資源占用。而且，所謂“池”始終有其上限，當請求大大超過上限時，
“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小。
對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。總之，多線程模型可以方便高效的解決小規模的服務請求，但面對大規模的服務請求，多線程模型也會遇到瓶頸，可以用非阻塞接口來嘗試解決這個問題。
三 多路復用IO(IO multiplexing)
IO multiplexing這個詞可能有點陌生，但是如果我說select/epoll，大概就都能明白了。有些地方也稱這種IO方式為事件驅動IO(event driven IO)。我們都知道，select/epoll的好處就在於單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖：
當用戶進程調用了select，那么整個進程會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的數據准備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實並沒有太大的不同，事實上還更差一些。因為這里需要使用兩個系統調用(select和recvfrom)，而blocking IO只調用了一個系統調用(recvfrom)。但是，用select的優勢在於它可以同時處理多個connection。
強調：
1. 如果處理的連接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連接能處理得更快，而是在於能處理更多的連接。
2. 在多路復用模型中，對於每一個socket，一般都設置成為non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。
結論: select的優勢在於可以處理多個連接，不適用於單個連接
四 IO模型比較分析
到目前為止，已經將四個IO Model都介紹完了。現在回過頭來回答最初的那幾個問題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。
先回答最簡單的這個：blocking vs non-blocking。前面的介紹中其實已經很明確的說明了這兩者的區別。調用blocking IO會一直block住對應的進程直到操作完成，而non-blocking IO在kernel還准備數據的情況下會立刻返回。
再說明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。Stevens給出的定義（其實是POSIX的定義）是這樣子的：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operationcompletes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
兩者的區別就在於synchronous IO做”IO operation”的時候會將process阻塞。按照這個定義，四個IO模型可以分為兩大類，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO這一類，而 asynchronous I/O后一類 。
有人可能會說，non-blocking IO並沒有被block啊。這里有個非常“狡猾”的地方，定義中所指的”IO operation”是指真實的IO操作，就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候，如果kernel的數據沒有准備好，這時候不會block進程。但是，當kernel中數據准備好的時候，recvfrom會將數據從kernel拷貝到用戶內存中，這個時候進程是被block了，在這段時間內，進程是被block的。而asynchronous IO則不一樣，當進程發起IO 操作之后，就直接返回再也不理睬了，直到kernel發送一個信號，告訴進程說IO完成。在這整個過程中，進程完全沒有被block。
各個IO Model的比較如圖所示：
經過上面的介紹，會發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，並且當數據准備完成以后，也需要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人（kernel）完成，然后他人做完后發信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態，也不需要主動的去拷貝數據。