Linux五種IO模型

Linux五種IO模型
Linux五種IO模型效能分析 

目錄(?)[-]

1. 概念理解
2. Linux下的五種IO模型
   1. 阻塞IO模型
   2. 非阻塞IO模型
   3. IO複用模型
   4. 訊號驅動IO
   5. 非同步IO模型
   6. 個IO模型的比較
   7. selectpollepoll簡介

1. 概念理解

 

在進行網路編程時，我們常常見到同步(Sync)/非同步(Async)，阻塞(Block)/非阻塞(Unblock)四種調用方式：
同步：
所謂同步，就是在發出一個功能調用時，在沒有得到結果之前，該調用就不返回。也就是必須一件一件事做,等前一件做完了才能做下一件事。

 

例如普通B/S模式（同步）：提交請求->等待伺服器處理->處理完畢返回這個期間用戶端瀏覽器不能幹任何事

非同步：
非同步概念和同步相對。當一個非同步程序呼叫發出後，調用者不能立刻得到結果。實際處理這個調用的組件在完成後，通過狀態、通知和回調來通知調用者。

例如 ajax請求（非同步）:請求通過事件觸發->伺服器處理（這是瀏覽器仍然可以作其他事情）->處理完畢

阻塞
阻塞調用是指調用結果返回之前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態下，cpu不會給線程分配時間片，即線程暫停運行）。函數只有在得到結果之後才會返回。

有人也許會把阻塞調用和同步調用等同起來，實際上他是不同的。對於同步調用來說，很多時候當前線程還是啟用的，只是從邏輯上當前函數沒有返回而已。例如，我們在socket中調用recv函數，如果緩衝區中沒有資料，這個函數就會一直等待，直到有資料才返回。而此時，當前線程還會繼續處理各種各樣的訊息。

非阻塞
非阻塞和阻塞的概念相對應，指在不能立刻得到結果之前，該函數不會阻塞當前線程，而會立刻返回。
對象的阻塞模式和阻塞函數調用
對象是否處於阻塞模式和函數是不是阻塞調用有很強的相關性，但是並不是一一對應的。阻塞對象上可以有非阻塞的調用方式，我們可以通過一定的API去輪詢狀態，在適當的時候調用阻塞函數，就可以避免阻塞。而對於非阻塞對象，調用特殊的函數也可以進入阻塞調用。函數select就是這樣的一個例子。

 

1. 同步，就是我調用一個功能，該功能沒有結束前，我死等結果。
2. 非同步，就是我調用一個功能，不需要知道該功能結果，該功能有結果後通知我（回調通知）
3. 阻塞， 就是調用我（函數），我（函數）沒有接收完資料或者沒有得到結果之前，我不會返回。
4. 非阻塞， 就是調用我（函數），我（函數）立即返回，通過select通知調用者

 

同步IO和非同步IO的區別就在於：資料拷貝的時候進程是否阻塞！

阻塞IO和非阻塞IO的區別就在於：應用程式的調用是否立即返回！

對於舉個簡單c/s 模式：

 

同步：提交請求->等待伺服器處理->處理完畢返回這個期間用戶端瀏覽器不能幹任何事
非同步：請求通過事件觸發->伺服器處理（這是瀏覽器仍然可以作其他事情）->處理完畢同步和非同步都只針對於本機SOCKET而言的。

同步和非同步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的對象也不相同。
阻塞和非阻塞是指當進程訪問的資料如果尚未就緒,進程是否需要等待,簡單說這相當於函數內部的實現區別,也就是未就緒時是直接返回還是等待就緒;

而同步和非同步是指訪問資料的機制,同步一般指主動請求並等待I/O操作完畢的方式,當資料就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段,同步的讀寫必須阻塞),非同步則指主動請求資料後便可以繼續處理其它任務,隨後等待I/O,操作完畢的通知,這可以使進程在資料讀寫時也不阻塞。(等待"通知")

1. 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。

阻塞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串連總會等待至少到伺服器的一次往返時間。

　　使用阻塞模式的通訊端，開發網路程式比較簡單，容易實現。當希望能夠立即發送和接收資料，且處理的通訊端數量比較少的情況下，使用阻塞模式來開發網路程式比較合適。

阻塞模式通訊端的不足表現為，在大量建立好的通訊端線程之間進行通訊時比較困難。當使用“生產者-消費者”模型開發網路程式時，為每個通訊端都分別分配一個讀線程、一個處理資料線程和一個用於同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量通訊端時，將無從下手，其擴充性很差

非阻塞IO模型

 

簡介：非阻塞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模型”，它有助於應用程式通過非同步方式，同時對一個或多個通訊端的通訊加以管理。

IO複用模型：

簡介：主要是select和epoll；對一個IO連接埠，兩次調用，兩次返回，比阻塞IO並沒有什麼優越性；關鍵是能實現同時對多個IO連接埠進行監聽；

I/O複用模型會用到select、poll、epoll函數，這幾個函數也會使進程阻塞，但是和阻塞I/O所不同的的，這兩個函數可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數進行檢測，直到有資料可讀或可寫時，才真正調用I/O操作函數。

訊號驅動IO

 

簡介：兩次調用，兩次返回；

首先我們允許套介面進行訊號驅動I/O,並安裝一個訊號處理函數，進程繼續運行並不阻塞。當資料準備好時，進程會收到一個SIGIO訊號，可以在訊號處理函數中調用I/O操作函數處理資料。

非同步IO模型

簡介：資料拷貝的時候進程無需阻塞。

當一個非同步程序呼叫發出後，調用者不能立刻得到結果。實際處理這個調用的組件在完成後，通過狀態、通知和回調來通知調用者的輸入輸出操作

同步IO引起進程阻塞，直至IO操作完成。
非同步IO不會引起進程阻塞。
IO複用是先通過select調用阻塞。

 

5個I/O模型的比較：

 

 

1. 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低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善

學習技術不只是為養家糊口，也為夜深人靜的時候能夠一個人靜靜享受這其中的樂趣。