Linux五種IO模型

1. 概念理解
在進行網絡編程時，我們常常見到同步(Sync)/異步(Async)，阻塞(Block)/非阻塞(Unblock)四種調用方式：
同步：所謂同步，就是在發出一個功能調用時，在沒有得到結果之前，該調用就不返回。也就是必須一件一件事做,等前一件做完了才能做下一件事。
例如普通B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回這個期間客戶端瀏覽器不能幹任何事
異步：異步的概念和同步相對。當一個異步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀態、通知和回調來通知調用者。
例如 ajax請求（異步）: 請求通過事件觸發->服務器處理（這是瀏覽器仍然可以作其他事情）->處理完畢
阻塞：阻塞調用是指調用結果返回之前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態下，cpu不會給線程分配時間片，即線程暫停運行）。函數只有在得到結果之後纔會返回。
有人也許會把阻塞調用和同步調用等同起來，實際上他是不同的。對於同步調用來說，很多時候當前線程還是激活的，只是從邏輯上當前函數沒有返回而已。例如，我們在socket中調用recv函數，如果緩衝區中沒有數據，這個函數就會一直等待，直到有數據才返回。而此時，當前線程還會繼續處理各種各樣的消息。
非阻塞：非阻塞和阻塞的概念相對應，指在不能立刻得到結果之前，該函數不會阻塞當前線程，而會立刻返回。
對象的阻塞模式和阻塞函數調用
對象是否處於阻塞模式和函數是不是阻塞調用有很強的相關性，但是並不是一一對應的。阻塞對象上可以有非阻塞的調用方式，我們可以通過一定的API去輪詢狀態，在適當的時候調用阻塞函數，就可以避免阻塞。而對於非阻塞對象，調用特殊的函數也可以進入阻塞調用。函數select就是這樣的一個例子。

同步，就是我調用一個功能，該功能沒有結束前，我死等結果。
異步，就是我調用一個功能，不需要知道該功能結果，該功能有結果後通知我（回調通知）
阻塞，就是調用我（函數），我（函數）沒有接收完數據或者沒有得到結果之前，我不會返回。
非阻塞，就是調用我（函數），我（函數）立即返回，通過select通知調用者
同步IO和異步IO的區別就在於：數據拷貝的時候進程是否阻塞！
阻塞IO和非阻塞IO的區別就在於：應用程序的調用是否立即返回！

對於舉個簡單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、epoll) （I/O multiplexing）
4)信號驅動I/O （signal driven I/O (SIGIO)）
5)異步I/O （asynchronous I/O (the POSIX aio_functions)）
前四種都是同步，只有最後一種纔是異步IO

(1)阻塞I/O模型：
簡介：進程會一直阻塞，直到數據拷貝完成
應用程序調用一個IO函數，導致應用程序阻塞，等待數據準備好。如果數據沒有準備好，一直等待….數據準備好了，從內核拷貝到用戶空間,IO函數返回成功指示。

阻塞I/O模型圖：在調用recv()/recvfrom（）函數時，發生在內核中等待數據和複製數據的過程

當調用recv()函數時，系統首先查是否有準備好的數據。如果數據沒有準備好，那麼系統就處於等待狀態。當數據準備好後，將數據從系統緩衝區複製到用戶空間，然後該函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那麼此時recv()函數就會處於等待狀態。

當使用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連接總會等待至少到服務器的一次往返時間。

使用阻塞模式的套接字，開發網絡程序比較簡單，容易實現。當希望能夠立即發送和接收數據，且處理的套接字數量比較少的情況下，使用阻塞模式來開發網絡程序比較合適。
阻塞模式套接字的不足表現爲，在大量建立好的套接字線程之間進行通信時比較困難。當使用“生產者-消費者”模型開發網絡程序時，爲每個套接字都分別分配一個讀線程、一個處理數據線程和一個用於同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量套接字時，將無從下手，其擴展性很差

(2)非阻塞I/O模型：
簡介：非阻塞IO通過進程反覆調用IO函數（多次系統調用，並馬上返回）；在數據拷貝的過程中，進程是阻塞的；

我們把一個SOCKET接口設置爲非阻塞就是告訴內核，當所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤。這樣我們的I/O操作函數將不斷的測試數據是否已經準備好，如果沒有準備好，繼續測試，直到數據準備好爲止。在這個不斷測試的過程中，會大量的佔用CPU的時間。
把SOCKET設置爲非阻塞模式，即通知系統內核：在調用Windows Sockets API時，不要讓線程睡眠，而應該讓函數立即返回。在返回時，該函數返回一個錯誤代碼。圖所示，一個非阻塞模式套接字多次調用recv()函數的過程。前三次調用recv()函數時，內核數據還沒有準備好。因此，該函數立即返回WSAEWOULDBLOCK錯誤代碼。第四次調用recv()函數時，數據已經準備好，被複制到應用程序的緩衝區中，recv()函數返回成功指示，應用程序開始處理數據。

當使用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模型”，它有助於應用程序通過異步方式，同時對一個或多個套接字的通信加以管理。

(3)IO複用模型：
簡介：主要是select和epoll；對一個IO端口，兩次調用，兩次返回，比阻塞IO並沒有什麼優越性；關鍵是能實現同時對多個IO端口進行監聽；
I/O複用模型會用到select、poll、epoll函數，這幾個函數也會使進程阻塞，但是和阻塞I/O所不同的的，這兩個函數可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數進行檢測，直到有數據可讀或可寫時，才真正調用I/O操作函數。