1. 概念了解
在進行網絡程式設計時，我們常常見到同步(Sync)/異步(Async)，阻塞(Block)/非阻塞(Unblock)四種調用方式：
一、同步與異步
同步/異步, 它們是消息的通知機制
1. 概念解釋
A. 同步
所謂同步，就是在發出一個功能調用時，在沒有得到結果之前，該調用就不傳回。
按照這個定義，其實絕大多數函數都是同步調用（例如sin isdigit等）。
但是一般而言，我們在說同步、異步的時候，特指那些需要其他部件協作或者需要一定時間完成的任務。
最常見的例子就是 SendMessage。
該函數發送一個消息給某個視窗，在對方處理完消息之前，這個函數不傳回。
當對方處理完畢以後，該函數才把消息處理函數所傳回的值傳回給調用者。
B. 異步
異步的概念和同步相對。
當一個異步過程調用發出後，調用者不會立刻得到結果。
實際處理這個調用的部件是在調用發出後，
通過狀态、通知來通知調用者，或通過回調函數處理這個調用。
以 Socket為例，
當一個用戶端通過調用 Connect函數發出一個連接配接請求後，調用者線程不用等待結果，可立刻繼續向下運作。
當連接配接真正建立起來以後，socket底層會發送一個消息通知該對象。
C. 三種傳回結果途徑
執行部件和調用者可以通過三種途徑傳回結果：
a. 狀态、
b. 通知、
c. 回調函數。
可以使用哪一種依賴于執行部件的實作，除非執行部件提供多種選擇，否則不受調用者控制。
a. 如果執行部件用狀态來通知，
那麼調用者就需要每隔一定時間檢查一次，效率就很低
有些初學多線程程式設計的人，總喜歡用一個循環去檢查某個變量的值，這其實是一種很嚴重的錯誤。
b. 如果是使用通知的方式，
效率則很高，因為執行部件幾乎不需要做額外的操作。
c. 至于回調函數，
和通知沒太多差別。
2. 舉例說明
了解這兩個概念，可以用去銀行辦理業務(可以取錢，也可以存錢)來比喻:
當到銀行後,
1、可以去ATM機前排隊等候 -- (排隊等候)就是同步等待消息
2、可以去大廳拿号,等到排到我的号時，
櫃台的人會通知我輪到我去辦理業務. -- (等待别人通知)就是異步等待消息.
在異步消息通知機制中,
等待消息者(在這個例子中就是等待辦理業務的人)往往注冊一個回調機制,
在所等待的事件被觸發時由觸發機制(在這裡是櫃台的人)通過某種機制(在這裡是寫在小紙條上的号碼)
找到等待該事件的人.
在select/poll 等IO 多路複用機制中就是fd,
當消息被觸發時,觸發機制通過fd 找到處理該fd的處理函數.
3. 在實際的程式中,
同步消息通知機制：就好比簡單的read/write 操作,它們需要等待這兩個操作成功才能傳回;
同步, 是由處理消息者自己去等待消息是否被觸發;
異步消息通知機制：類似于select/poll 之類的多路複用IO 操作,
當所關注的消息被觸發時,由消息觸發機制通知觸發對消息的處理.
異步, 由觸發機制來通知處理消息者;
還是回到上面的例子，輪到你辦理業務，這個就是你關注的消息，而辦理什麼業務，就是對這個消息的處理,兩者是有差別的.
而在真實的IO 操作時：所關注的消息就是該fd是否可讀寫, 而對消息的處理是對這個fd 進行讀寫.
同步/異步僅僅關注的是消息通知的方式，它們對消息如何處理并不關心。好比說，銀行的人僅僅通知你輪到你辦理業務了，而辦理業務什麼業務(存錢還是取錢)他們是不知道的.
二、阻塞與非阻塞
阻塞/非阻塞, 它們是程式在等待消息(無所謂同步或者異步)時的狀态.
1. 概念解釋
A. 阻塞
阻塞調用是指調用結果傳回之前，目前線程會被挂起。函數隻有在得到結果之後才會傳回。
有人也許會把阻塞調用和同步調用等同起來，實際上他是不同的。
對于同步調用來說，很多時候目前線程還是激活的，隻是從邏輯上目前函數沒有傳回而已。
socket接收資料函數recv是一個阻塞調用的例子。
當socket工作在阻塞模式的時候， 如果沒有資料的情況下調用該函數，則目前線程就會被挂起，直到有資料為止。
B. 非阻塞
非阻塞和阻塞的概念相對應，指在不能立刻得到結果之前，該函數不會阻塞目前線程，而會立刻傳回。
C. 對象的阻塞模式和阻塞函數調用
對象是否處于阻塞模式和函數是不是阻塞調用有很強的相關性，但是并不是一一對應的。
阻塞對象上可以有非阻塞的調用方式，我們可以通過一定的API去輪詢狀态，
在适當的時候調用阻塞函數，就可以避免阻塞。
而對于非阻塞對象，調用特殊的函數也可以進入阻塞調用。函數select就是這樣的一個例子。
2. 舉例說明
繼續上面的那個例子,
不論是排隊等待，還是使用号碼等待通知,
如果在這個等待的過程中,
. 等待者除了等待消息之外不能做其它的事情,那麼該機制就是阻塞的,
表現在程式中,也就是該程式一直阻塞在該函數調用處不能繼續往下執行.
. 相反,有的人喜歡在銀行辦理這些業務的時候一邊打打電話發發短信一邊等待,這樣的狀态就是非阻塞的,
因為他(等待者)沒有阻塞在這個消息通知上,而是一邊做自己的事情一邊等待.
三、易混淆的點
很多人也會把異步和非阻塞混淆,
因為異步操作一般都不會在真正的IO 操作處被阻塞,
比如如果用select 函數,當select 傳回可讀時再去read 一般都不會被阻塞
就好比當你的号碼排到時一般都是在你之前已經沒有人了,是以你再去櫃台辦理業務就不會被阻塞.
可見,同步/異步與阻塞/非阻塞是兩組不同的概念,它們可以共存組合,
同步、異步和阻塞、非阻塞的區分要差別兩個概念：消息的觸發和消息的處理。
調用者主動擷取并等待消息的觸發，就是同步。調用者不等待，而是被通知是否可以處理消息，就是異步。同步和異步是主動和被動擷取消息觸發。
阻塞是指調用者等待消息的處理結果，非阻塞是指調用者不等待，而是被通知消息的處理結果。
比如阻塞的read/write 操作中，其實是把消息的通知和消息的處理結合在了一起,
在這裡所關注的消息就是fd 是否可讀/寫，而處理消息則是對fd 讀/寫.
當我們将這個fd 設定為非阻塞的時候，read/write 操作就不會在等待消息通知這裡阻塞， 如果fd 不可讀/寫則操作立即傳回。
四、同步/異步與阻塞/非阻塞的組合分析
_______阻塞____________________非阻塞_____
同步 | 同步阻塞 同步非阻塞
異步 | 異步阻塞 異步非阻塞
同步阻塞形式:
等待消息觸發，這個過程中什麼也不做。
效率是最低的，
拿上面的例子來說，就是你專心排隊，什麼别的事都不做。
實際程式中
就是未對fd 設定O_NONBLOCK 标志位的read/write 操作,
異步阻塞形式:
異步操作是可以被阻塞住的，隻不過它不是在處理消息時阻塞，而是在等待消息被觸發時被阻塞。
如果在銀行等待辦理業務的人采用的是異步的方式去等待消息被觸發,也就是領了一張小紙條,
假如在這段時間裡他不能離開銀行做其它的事情,那麼很顯然,這個人被阻塞在了這個等待的操作上面;
比如select 函數,
假如傳入的最後一個timeout 參數為NULL,那麼如果所關注的事件沒有一個被觸發,
程式就會一直阻塞在這個select 調用處.
同步非阻塞形式:
主動等待消息觸發，但是等待過程中可以做其它事情，邊做其它事情邊主動檢視消息是否被觸發。
實際上是效率低下的,
想象一下你一邊打着電話一邊還需要擡頭看到底隊伍排到你了沒有,
如果把打電話和觀察排隊的位置看成是程式的兩個操作的話,
這個程式需要在這兩種不同的行為之間來回的切換,效率可想而知是低下的;
很多人會寫阻塞的read/write 操作,
但是别忘了可以對fd 設定O_NONBLOCK 标志位,這樣就可以将同步操作變成非阻塞的了;
異步非阻塞形式:
不等待，去做其他事情，消息觸發時通知調用者。
效率更高,
因為打電話是你(等待者)的事情,而通知你則是櫃台(消息觸發機制)的事情,
程式沒有在兩種不同的操作中來回切換.
比如說，這個人突然發覺自己煙瘾犯了,需要出去抽根煙,
于是他告訴大堂經理說,排到我這個号碼的時候麻煩到外面通知我一下(注冊一個回調函數),
那麼他就沒有被阻塞在這個等待的操作上面,自然這個就是異步+非阻塞的方式了.
如果使用異步非阻塞的情況,
比如aio_*組的操作,當發起一個aio_read 操作時,函數會馬上傳回不會被阻塞,
當所關注的事件被觸發時會調用之前注冊的回調函數進行處理,
舉個簡單c/s 模式：
同步：送出請求->等待伺服器處理->處理完畢傳回這個期間用戶端浏覽器不能幹任何事
異步：請求通過事件觸發->伺服器處理（這是浏覽器仍然可以作其他事情）->處理完畢 同步和異步都隻針對于本機SOCKET而言的。
同步和異步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的對象也不相同。
阻塞和非阻塞是指當程序通路的資料如果尚未就緒,程序是否需要等待,簡單說這相當于函數内部的實作差別,也就是未就緒時是直接傳回還是等待就緒;
而同步和異步是指通路資料的機制。同步一般指主動請求并等待I/O操作完畢的方式,當資料就緒後在讀寫的時候必須阻塞(差別就緒與讀寫二個階段,同步的讀寫必須阻塞)；異步則指主動請求資料後便可以繼續處理其它任務,随後等待I/O,操作完畢的通知,這可以使程序在資料讀寫時也不阻塞。(等待"通知")
2. Linux下的五種I/O模型
1)阻塞I/O（blocking I/O）
2)非阻塞I/O （nonblocking I/O）
3) I/O複用(select 和poll) （I/O multiplexing）
4)信号驅動I/O （signal driven I/O (SIGIO)）
5)異步I/O （asynchronous I/O (the POSIX aio_functions)）
前四種都是同步，隻有最後一種才是異步IO。
再說一下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 Model的差別就是在兩個階段上各有不同的情況。
阻塞I/O模型：
簡介：程序會一直阻塞，直到資料拷貝完成
應用程式調用一個IO函數，導緻應用程式阻塞，等待資料準備好。 如果資料沒有準備好，一直等待….資料準備好了，從核心拷貝到使用者空間,IO函數傳回成功訓示。
我們 第一次接觸到的網絡程式設計都是從 listen()、send()、recv()等接口開始的。使用這些接口可以很友善的建構伺服器 /客戶機的模型。
阻塞I/O模型圖：在調用recv()/recvfrom（）函數時，發生在核心中等待資料和複制資料的過程。
當使用者程序調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備資料。對于network io來說，很多時候資料在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的資料到來。而在使用者程序這邊，整個程序會被阻塞。當kernel一直等到資料準備好了，使用者程序就會将資料從kernel中拷貝到使用者記憶體，然後kernel傳回結果，使用者程序才解除block的狀态，重新運作起來。
是以，blocking IO的特點就是在IO執行的兩個階段都被block了。
當使用socket()函數和WSASocket()函數建立套接字時，預設的套接字都是阻塞的。這意味着當調用Windows Sockets API不能立即完成時，線程處于等待狀态，直到操作完成。
并不是所有Windows Sockets API以阻塞套接字為參數調用都會發生阻塞。例如，以阻塞模式的套接字為參數調用bind()、listen()函數時，函數會立即傳回。将可能阻塞套接字的Windows Sockets API調用分為以下四種:
1．輸入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函數。以阻塞套接字為參數調用該函數接收資料。如果此時套接字緩沖區内沒有資料可讀，則調用線程在資料到來前一直睡眠。
2．輸出操作： send()、sendto()、WSASend()和WSASendto()函數。以阻塞套接字為參數調用該函數發送資料。如果套接字緩沖區沒有可用空間，線程會一直睡眠，直到有空間。
3．接受連接配接：accept()和WSAAcept()函數。以阻塞套接字為參數調用該函數，等待接受對方的連接配接請求。如果此時沒有連接配接請求，線程就會進入睡眠狀态。
4．外出連接配接：connect()和WSAConnect()函數。對于TCP連接配接，用戶端以阻塞套接字為參數，調用該函數向伺服器發起連接配接。該函數在收到伺服器的應答前，不會傳回。這意味着TCP連接配接總會等待至少到伺服器的一次往返時間。
使用阻塞模式的套接字，開發網絡程式比較簡單，容易實作。當希望能夠立即發送和接收資料，且處理的套接字數量比較少的情況下，使用阻塞模式來開發網絡程式比較合适。
阻塞模式套接字的不足表現為，在大量建立好的套接字線程之間進行通信時比較困難。當使用“生産者-消費者”模型開發網絡程式時，為每個套接字都分别配置設定一個讀線程、一個處理資料線程和一個用于同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量套接字時，将無從下手，其擴充性很差.
阻塞模式給網絡程式設計帶來了一個很大的問題，如在調用 send()的同時，線程将被阻塞，在此期間，線程将無法執行任何運算或響應任何的網絡請求。這給多客戶機、多業務邏輯的網絡程式設計帶來了挑戰。這時，我們可能會選擇多線程的方式來解決這個問題。
應對多客戶機的網絡應用，最簡單的解決方式是在伺服器端使用多線程（或多程序）。多線程（或多程序）的目的是讓每個連接配接都擁有獨立的線程（或程序），這樣任何一個連接配接的阻塞都不會影響其他的連接配接。
具體使用多程序還是多線程，并沒有一個特定的模式。傳統意義上，程序的開銷要遠遠大于線程，是以，如果需要同時為較多的客戶機提供服務，則不推薦使用多程序；如果單個服務執行體需要消耗較多的 CPU 資源，譬如需要進行大規模或長時間的資料運算或檔案通路，則程序較為安全。通常，使用 pthread_create () 建立新線程，fork() 建立新程序。
多線程/程序伺服器同時為多個客戶機提供應答服務。模型如下：
主線程持續等待用戶端的連接配接請求，如果有連接配接，則建立新線程，并在新線程中提供為前例同樣的問答服務。
上述多線程的伺服器模型似乎完美的解決了為多個客戶機提供問答服務的要求，但其實并不盡然。如果要同時響應成百上千路的連接配接請求，則無論多線程還是多程序都會嚴重占據系統資源，降低系統對外界響應效率，而線程與程序本身也更容易進入假死狀态。
由此可能會考慮使用“線程池”或“連接配接池”。“線程池”旨在減少建立和銷毀線程的頻率，其維持一定合理數量的線程，并讓空閑的線程重新承擔新的執行任務。“連接配接池”維持連接配接的緩存池，盡量重用已有的連接配接、減少建立和關閉連接配接的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如apache，mysql資料庫等。
但是，“線程池”和“連接配接池”技術也隻是在一定程度上緩解了頻繁調用 IO 接口帶來的資源占用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應并不比沒有池的時候效果好多少。是以使用“池”必須考慮其面臨的響應規模，并根據響應規模調整“池”的大小。
對應上例中的所面臨的可能同時出現的上千甚至上萬次的用戶端請求，“線程池”或“連接配接池”或許可以緩解部分壓力，但是不能解決所有問題。
非阻塞IO模型 ：
簡介：非阻塞IO通過程序反複調用IO函數（ 多次系統調用，并馬上傳回 ）； 在資料拷貝的過程中，程序是阻塞的 ；
我們把一個SOCKET接口設定為非阻塞就是告訴核心，當所請求的I/O操作無法完成時，不要将程序睡眠，而是傳回一個錯誤。這樣我們的I/O操作函數将不斷的測試資料是否已經準備好，如果沒有準備好，繼續測試，直到資料準備好為止。在這個不斷測試的過程中，會大量的占用CPU的時間。
把SOCKET設定為非阻塞模式，即通知系統核心：在調用Windows Sockets API時，不要讓線程睡眠，而應該讓函數立即傳回。在傳回時，該函數傳回一個錯誤代碼。圖所示，一個非阻塞模式套接字多次調用recv()函數的過程。前三次調用recv()函數時，核心資料還沒有準備好。是以，該函數立即傳回WSAEWOULDBLOCK錯誤代碼。第四次調用recv()函數時，資料已經準備好，被複制到應用程式的緩沖區中，recv()函數傳回成功訓示，應用程式開始處理資料。
從圖中可以看出，當使用者程序發出read操作時，如果kernel中的資料還沒有準備好，那麼它并不會block使用者程序，而是立刻傳回一個error。從使用者程序角度講 ，它發起一個read操作後，并不需要等待，而是馬上就得到了一個結果。使用者程序判斷結果是一個error時，它就知道資料還沒有準備好，于是它可以再次發送read操作。一旦kernel中的資料準備好了，并且又再次收到了使用者程序的system call，那麼使用者程序馬上就将資料拷貝到了使用者記憶體，然後傳回。
是以，使用者程序其實是需要不斷的主動詢問kernel資料好了沒有。
當使用socket()函數和WSASocket()函數建立套接字時，預設都是阻塞的。在建立套接字之後，通過調用ioctlsocket()函數，将該套接字設定為非阻塞模式。Linux下的函數是:fcntl().
套接字設定為非阻塞模式後，在調用Windows Sockets API函數時，調用函數會立即傳回。大多數情況下，這些函數調用都會調用“失敗”，并傳回WSAEWOULDBLOCK錯誤代碼。說明請求的操作在調用期間内沒有時間完成。通常，應用程式需要重複調用該函數，直到獲得成功傳回代碼。
需要說明的是并非所有的Windows Sockets API在非阻塞模式下調用，都會傳回WSAEWOULDBLOCK錯誤。例如，以非阻塞模式的套接字為參數調用bind()函數時，就不會傳回該錯誤代碼。當然，在調用WSAStartup()函數時更不會傳回該錯誤代碼，因為該函數是應用程式第一調用的函數，當然不會傳回這樣的錯誤代碼。
要将套接字設定為非阻塞模式，除了使用ioctlsocket()函數之外，還可以使用WSAAsyncselect()和WSAEventselect()函數。當調用該函數時，套接字會自動地設定為非阻塞方式。
由于使用非阻塞套接字在調用函數時，會經常傳回WSAEWOULDBLOCK錯誤。是以在任何時候，都應仔細檢查傳回代碼并作好對“失敗”的準備。應用程式連續不斷地調用這個函數，直到它傳回成功訓示為止。上面的程式清單中，在While循環體内不斷地調用recv()函數，以讀入1024個位元組的資料。這種做法很浪費系統資源。
要完成這樣的操作，有人使用MSG_PEEK标志調用recv()函數檢視緩沖區中是否有資料可讀。同樣，這種方法也不好。因為該做法對系統造成的開銷是很大的，并且應用程式至少要調用recv()函數兩次，才能實際地讀入資料。較好的做法是，使用套接字的“I/O模型”來判斷非阻塞套接字是否可讀可寫。
非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要編寫更多的代碼，以便在每個Windows Sockets API函數調用中，對收到的WSAEWOULDBLOCK錯誤進行處理。是以，非阻塞套接字便顯得有些難于使用。
但是，非阻塞套接字在控制建立的多個連接配接，在資料的收發量不均，時間不定時，明顯具有優勢。這種套接字在使用上存在一定難度，但隻要排除了這些困難，它在功能上還是非常強大的。通常情況下，可考慮使用套接字的“I/O模型”，它有助于應用程式通過異步方式，同時對一個或多個套接字的通信加以管理。
IO複用模型：
簡介：主要是select和epoll；對一個IO端口，兩次調用，兩次傳回，比阻塞IO并沒有什麼優越性；關鍵是能實作同時對多個IO端口進行監聽；
I/O複用模型會用到select、poll、epoll函數，這幾個函數也會使程序阻塞并且等待，但是和阻塞I/O所不同的的，這兩個函數可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數進行檢測，直到有資料可讀或可寫時，才真正調用I/O操作函數。多路複用的好處是，一個程序可以同時處理多個多個網絡連接配接的I/O。
當使用者程序調用了select，那麼整個程序會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的資料準備好了，select就會傳回。這個時候使用者程序再調用read操作，将資料從kernel拷貝到使用者程序。
這個圖和blocking IO的圖其實并沒有太大的不同，事實上，還更差一些。因為這裡需要使用兩個system call (select 和 recvfrom)，而blocking IO隻調用了一個system call (recvfrom)。但是，用select的優勢在于它可以同時處理多個connection。（多說一句。是以，如果處理的連接配接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢并不是對于單個連接配接能處理得更快，而是在于能處理更多的連接配接。）
在IO multiplexing Model中，實際中，對于每一個socket，一般都設定成為non-blocking，但是，如上圖所示，整個使用者的process其實是一直被block的。隻不過process是被select這個函數block，而不是被socket IO給block。是以是I/O多路複用是同步I/O。
信号驅動IO
簡介：兩次調用，兩次傳回；
首先我們允許套接口進行信号驅動I/O,并安裝一個信号處理函數，程序繼續運作并不阻塞。當資料準備好時，程序會收到一個SIGIO信号，可以在信号處理函數中調用I/O操作函數處理資料。
異步IO模型
簡介：資料拷貝的時候程序無需阻塞。
當一個異步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀态、通知和回調來通知調用者進行輸入輸出操作。
使用者程序發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它收到一個asynchronous read之後，首先它會立刻傳回，是以不會對使用者程序産生任何block。然後，kernel會等待資料準備完成，然後将資料拷貝到使用者記憶體，當這一切都完成之後，kernel會給使用者程序發送一個signal，告訴它read操作完成了。
到目前為止，已經将四個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阻塞。按照這個定義，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬于synchronous IO。有人可能會說，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。
5個I/O模型的比較：
經過上面的介紹，會發現non-blocking IO和asynchronous IO的差別還是很明顯的。在non-blocking IO中，雖然程序大部分時間都不會被block，但是它仍然要求程序去主動的check，并且當資料準備完成以後，也需要程序主動的再次調用recvfrom來将資料拷貝到使用者記憶體。而asynchronous IO則完全不同。它就像是使用者程序将整個IO操作交給了他人（kernel）完成，然後他人做完後發信号通知。在此期間，使用者程序不需要去檢查IO操作的狀态，也不需要主動的去拷貝資料。
3. select、poll、epoll簡介
epoll跟select都能提供多路I/O複用的解決方案。在現在的Linux核心裡有都能夠支援，其中epoll是Linux所特有，而select則應該是POSIX所規定，一般作業系統均有實作。
select：
select本質上是通過設定或者檢查存放fd标志位的資料結構來進行下一步處理。這樣所帶來的缺點是：
1、 單個程序可監視的fd數量被限制，即同時監聽的連接配接數有限制。
一般來說這個數目和系統記憶體關系很大，具體數目可以cat /proc/sys/fs/file-max察看。32位機預設是1024個。64位機預設是2048.并且也受核心限制。
2、 對socket進行掃描時是線性掃描，即采用輪詢的方法，效率較低：
當套接字比較多的時候，每次select()都要通過周遊FD_SETSIZE個Socket來完成排程,不管哪個Socket是活躍的,都周遊一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。
3、需要維護一個用來存放大量fd的資料結構，這樣會使得使用者空間和核心空間在傳遞該結構時複制開銷大。
poll：
poll本質上和select沒有差別，它将使用者傳入的數組拷貝到核心空間，然後查詢每個fd對應的裝置狀态，如果裝置就緒則在裝置等待隊列中加入一項并繼續周遊，如果周遊完所有fd後沒有發現就緒裝置，則挂起目前程序，直到裝置就緒或者主動逾時，被喚醒後它又要再次周遊fd。這個過程經曆了多次無謂的周遊。
它沒有最大連接配接數的限制，原因是它是基于連結清單來存儲的，但是同樣有一個缺點：
1、大量的fd的數組被整體複制于使用者态和核心位址空間之間，而不管這樣的複制是不是有意義。
2、poll還有一個特點是“水準觸發”，如果報告了fd後，沒有被處理，那麼下次poll時會再次報告該fd。
epoll:
epoll支援水準觸發和邊緣觸發，最大的特點在于邊緣觸發，它隻告訴程序哪些fd剛剛變為就需态，并且隻會通知一次。還有一個特點是，epoll使用“事件”的就緒通知方式，通過epoll_ctl注冊fd，一旦該fd就緒，核心就會采用類似callback的回調機制來激活該fd，epoll_wait便可以收到通知
epoll的優點：
1、沒有最大并發連接配接的限制，能打開的FD的上限遠大于1024（1G的記憶體上能監聽約10萬個端口）；
2、效率提升，不是輪詢的方式，不會随着FD數目的增加效率下降。隻有活躍可用的FD才會調用callback函數；
即Epoll最大的優點就在于它隻管你“活躍”的連接配接，而跟連接配接總數無關，是以在實際的網絡環境中，Epoll的效率就會遠遠高于select和poll。
3、 記憶體拷貝，利用mmap()檔案映射記憶體加速與核心空間的消息傳遞；即epoll使用mmap減少複制開銷。
select、poll、epoll 差別總結：
1、支援一個程序所能打開的最大連接配接數
| select | 單個程序所能打開的最大連接配接數有FD_SETSIZE宏定義，其大小是32個整數的大小（在32位的機器上，大小就是32*32，同理64位機器上FD_SETSIZE為32*64），當然我們可以對進行修改，然後重新編譯核心，但是性能可能會受到影響，這需要進一步的測試。 |
| poll | poll本質上和select沒有差別，但是它沒有最大連接配接數的限制，原因是它是基于連結清單來存儲的 |
| epoll | 雖然連接配接數有上限，但是很大，1G記憶體的機器上可以打開10萬左右的連接配接，2G記憶體的機器可以打開20萬左右的連接配接 |
2、FD劇增後帶來的IO效率問題
| select | 因為每次調用時都會對連接配接進行線性周遊，是以随着FD的增加會造成周遊速度慢的“線性下降性能問題”。 |
| poll | 同上 |
| epoll | 因為epoll核心中實作是根據每個fd上的callback函數來實作的，隻有活躍的socket才會主動調用callback，是以在活躍socket較少的情況下，使用epoll沒有前面兩者的線性下降的性能問題，但是所有socket都很活躍的情況下，可能會有性能問題。 |
3、 消息傳遞方式
| select | 核心需要将消息傳遞到使用者空間，都需要核心拷貝動作 |
| poll | 同上 |
| epoll | epoll通過核心和使用者空間共享一塊記憶體來實作的。 |
總結：
綜上，在選擇select，poll，epoll時要根據具體的使用場合以及這三種方式的自身特點。
1、表面上看epoll的性能最好，但是在連接配接數少并且連接配接都十分活躍的情況下，select和poll的性能可能比epoll好，畢竟epoll的通知機制需要很多函數回調。
2、select低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善
http://blog.csdn.net/hguisu/article/details/7453390
http://blog.csdn.net/historyasamirror/article/details/5778378