複製粘貼自5種網路IO模型（有圖，很清楚） - findumars - 博客園

同步（synchronous） IO和非同步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什麼，到底有什麼區別？這個問題其實不同的人給出的答案都可能不同，比如wiki，就認為asynchronous IO和non-blocking IO是一個東西。這其實是因為不同的人的知識背景不同，並且在討論這個問題的時候上下文(context)也不相同。所以，為了更好的回答這個問題，我先限定一下本文的上下文。

本文討論的背景是Linux環境下的network IO。本文最重要的參考文獻是Richard Stevens的「UNIX? Network Programming Volume 1, Third Edition: The Sockets Networking 」，6.2節「I/O Models 」，Stevens在這節中詳細說明瞭各種IO的特點和區別，如果英文夠好的話，推薦直接閱讀。Stevens的文風是有名的深入淺出，所以不用擔心看不懂。本文中的流程圖也是截取自參考文獻。

Stevens在文章中一共比較了五種IO Model：

* blocking IO

* nonblocking IO * IO multiplexing * signal driven IO * asynchronous IO 由signal driven 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、阻塞IO（blocking IO）

在linux中，默認情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：

圖1 阻塞IO

當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。

所以，blocking IO的特點就是在IO執行的兩個階段（等待數據和拷貝數據兩個階段）都被block了。

幾乎所有的程序員第一次接觸到的網路編程都是從listen()、send()、recv() 等介面開始的，這些介面都是阻塞型的。使用這些介面可以很方便的構建伺服器/客戶機的模型。下面是一個簡單地「一問一答」的伺服器。

圖2 簡單的一問一答的伺服器/客戶機模型

我們注意到，大部分的socket介面都是阻塞型的。所謂阻塞型介面是指系統調用（一般是IO介面）不返回調用結果並讓當前線程一直阻塞，只有當該系統調用獲得結果或者超時出錯時才返回。

實際上，除非特別指定，幾乎所有的IO介面 ( 包括socket介面 ) 都是阻塞型的。這給網路編程帶來了一個很大的問題，如在調用send()的同時，線程將被阻塞，在此期間，線程將無法執行任何運算或響應任何的網路請求。

一個簡單的改進方案是在伺服器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。具體使用多進程還是多線程，並沒有一個特定的模式。傳統意義上，進程的開銷要遠遠大於線程，所以如果需要同時為較多的客戶機提供服務，則不推薦使用多進程；如果單個服務執行體需要消耗較多的CPU資源，譬如需要進行大規模或長時間的數據運算或文件訪問，則進程較為安全。通常，使用pthread_create ()創建新線程，fork()創建新進程。

我們假設對上述的伺服器 / 客戶機模型，提出更高的要求，即讓伺服器同時為多個客戶機提供一問一答的服務。於是有了如下的模型。

圖3 多線程的伺服器模型

在上述的線程 / 時間圖例中，主線程持續等待客戶端的連接請求，如果有連接，則創建新線程，並在新線程中提供為前例同樣的問答服務。

很多初學者可能不明白為何一個socket可以accept多次。實際上socket的設計者可能特意為多客戶機的情況留下了伏筆，讓accept()能夠返回一個新的socket。下面是 accept 介面的原型： int accept(int s, struct sockaddr *addr, socklen_t *addrlen); 輸入參數s是從socket()，bind()和listen()中沿用下來的socket句柄值。執行完bind()和listen()後，操作系統已經開始在指定的埠處監聽所有的連接請求，如果有請求，則將該連接請求加入請求隊列。調用accept()介面正是從 socket s 的請求隊列抽取第一個連接信息，創建一個與s同類的新的socket返回句柄。新的socket句柄即是後續read()和recv()的輸入參數。如果請求隊列當前沒有請求，則accept() 將進入阻塞狀態直到有請求進入隊列。 上述多線程的伺服器模型似乎完美的解決了為多個客戶機提供問答服務的要求，但其實並不盡然。如果要同時響應成百上千路的連接請求，則無論多線程還是多進程都會嚴重佔據系統資源，降低系統對外界響應效率，而線程與進程本身也更容易進入假死狀態。 很多程序員可能會考慮使用「線程池」或「連接池」。「線程池」旨在減少創建和銷毀線程的頻率，其維持一定合理數量的線程，並讓空閑的線程重新承擔新的執行任務。「連接池」維持連接的緩存池，盡量重用已有的連接、減少創建和關閉連接的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如websphere、tomcat和各種資料庫等。但是，「線程池」和「連接池」技術也只是在一定程度上緩解了頻繁調用IO介面帶來的資源佔用。而且，所謂「池」始終有其上限，當請求大大超過上限時，「池」構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用「池」必須考慮其面臨的響應規模，並根據響應規模調整「池」的大小。 對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，「線程池」或「連接池」或許可以緩解部分壓力，但是不能解決所有問題。總之，多線程模型可以方便高效的解決小規模的服務請求，但面對大規模的服務請求，多線程模型也會遇到瓶頸，可以用非阻塞介面來嘗試解決這個問題。

2、非阻塞IO（non-blocking IO）

Linux下，可以通過設置socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：

圖4 非阻塞IO

從圖中可以看出，當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那麼它並不會block用戶進程，而是立刻返回一個error。從用戶進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麼它馬上就將數據拷貝到了用戶內存，然後返回。

所以，在非阻塞式IO中，用戶進程其實是需要不斷的主動詢問kernel數據準備好了沒有。

非阻塞的介面相比於阻塞型介面的顯著差異在於，在被調用之後立即返回。使用如下的函數可以將某句柄fd設為非阻塞狀態。

fcntl( fd, F_SETFL, O_NONBLOCK ); 下面將給出只用一個線程，但能夠同時從多個連接中檢測數據是否送達，並且接受數據的模型。

圖5 使用非阻塞的接收數據模型

在非阻塞狀態下，recv() 介面在被調用後立即返回，返回值代表了不同的含義。如在本例中，

* recv() 返回值大於 0，表示接受數據完畢，返回值即是接受到的位元組數； * recv() 返回 0，表示連接已經正常斷開； * recv() 返回 -1，且 errno 等於 EAGAIN，表示 recv 操作還沒執行完成； * recv() 返回 -1，且 errno 不等於 EAGAIN，表示 recv 操作遇到系統錯誤 errno。 可以看到伺服器線程可以通過循環調用recv()介面，可以在單個線程內實現對所有連接的數據接收工作。但是上述模型絕不被推薦。因為，循環調用recv()將大幅度推高CPU 佔用率；此外，在這個方案中recv()更多的是起到檢測「操作是否完成」的作用，實際操作系統提供了更為高效的檢測「操作是否完成「作用的介面，例如select()多路復用模式，可以一次檢測多個連接是否活躍。 3、多路復用IO（IO multiplexing） IO multiplexing這個詞可能有點陌生，但是如果我說select/epoll，大概就都能明白了。有些地方也稱這種IO方式為事件驅動IO(event driven IO)。我們都知道，select/epoll的好處就在於單個process就可以同時處理多個網路連接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖：

圖6 多路復用IO

當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會「監視」所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。

這個圖和blocking IO的圖其實並沒有太大的不同，事實上還更差一些。因為這裡需要使用兩個系統調用(select和recvfrom)，而blocking IO只調用了一個系統調用(recvfrom)。但是，用select的優勢在於它可以同時處理多個connection。（多說一句：所以，如果處理的連接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連接能處理得更快，而是在於能處理更多的連接。） 在多路復用模型中，對於每一個socket，一般都設置成為non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。因此select()與非阻塞IO類似。

大部分Unix/Linux都支持select函數，該函數用於探測多個文件句柄的狀態變化。下面給出select介面的原型：

FD_ZERO(int fd, fd_set* fds) FD_SET(int fd, fd_set* fds)

FD_ISSET(int fd, fd_set* fds)

FD_CLR(int fd, fd_set* fds) int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) 這裡，fd_set 類型可以簡單的理解為按 bit 位標記句柄的隊列，例如要在某 fd_set 中標記一個值為16的句柄，則該fd_set的第16個bit位被標記為1。具體的置位、驗證可使用 FD_SET、FD_ISSET等宏實現。在select()函數中，readfds、writefds和exceptfds同時作為輸入參數和輸出參數。如果輸入的readfds標記了16號句柄，則select()將檢測16號句柄是否可讀。在select()返回後，可以通過檢查readfds有否標記16號句柄，來判斷該「可讀」事件是否發生。另外，用戶可以設置timeout時間。 下面將重新模擬上例中從多個客戶端接收數據的模型。

圖7 使用select()的接收數據模型

述模型只是描述了使用select()介面同時從多個客戶端接收數據的過程；由於select()介面可以同時對多個句柄進行讀狀態、寫狀態和錯誤狀態的探測，所以可以很容易構建為多個客戶端提供獨立問答服務的伺服器系統。如下圖。

圖8 使用select()介面的基於事件驅動的伺服器模型

這裡需要指出的是，客戶端的一個 connect() 操作，將在伺服器端激發一個「可讀事件」，所以 select() 也能探測來自客戶端的 connect() 行為。

上述模型中，最關鍵的地方是如何動態維護select()的三個參數readfds、writefds和exceptfds。作為輸入參數，readfds應該標記所有的需要探測的「可讀事件」的句柄，其中永遠包括那個探測 connect() 的那個「母」句柄；同時，writefds 和 exceptfds 應該標記所有需要探測的「可寫事件」和「錯誤事件」的句柄 ( 使用 FD_SET() 標記 )。 作為輸出參數，readfds、writefds和exceptfds中的保存了 select() 捕捉到的所有事件的句柄值。程序員需要檢查的所有的標記位 ( 使用FD_ISSET()檢查 )，以確定到底哪些句柄發生了事件。 上述模型主要模擬的是「一問一答」的服務流程，所以如果select()發現某句柄捕捉到了「可讀事件」，伺服器程序應及時做recv()操作，並根據接收到的數據準備好待發送數據，並將對應的句柄值加入writefds，準備下一次的「可寫事件」的select()探測。同樣，如果select()發現某句柄捕捉到「可寫事件」，則程序應及時做send()操作，並準備好下一次的「可讀事件」探測準備。下圖描述的是上述模型中的一個執行週期。

圖9 多路復用模型的一個執行週期

這種模型的特徵在於每一個執行週期都會探測一次或一組事件，一個特定的事件會觸發某個特定的響應。我們可以將這種模型歸類為「事件驅動模型」。

相比其他模型，使用select() 的事件驅動模型只用單線程（進程）執行，佔用資源少，不消耗太多 CPU，同時能夠為多客戶端提供服務。如果試圖建立一個簡單的事件驅動的伺服器程序，這個模型有一定的參考價值。 但這個模型依舊有著很多問題。首先select()介面並不是實現「事件驅動」的最好選擇。因為當需要探測的句柄值較大時，select()介面本身需要消耗大量時間去輪詢各個句柄。很多操作系統提供了更為高效的介面，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。如果需要實現更高效的伺服器程序，類似epoll這樣的介面更被推薦。遺憾的是不同的操作系統特供的epoll介面有很大差異，所以使用類似於epoll的介面實現具有較好跨平臺能力的伺服器會比較困難。 其次，該模型將事件探測和事件響應夾雜在一起，一旦事件響應的執行體龐大，則對整個模型是災難性的。如下例，龐大的執行體1的將直接導致響應事件2的執行體遲遲得不到執行，並在很大程度上降低了事件探測的及時性。

圖10 龐大的執行體對使用select()的事件驅動模型的影響

幸運的是，有很多高效的事件驅動庫可以屏蔽上述的困難，常見的事件驅動庫有libevent庫，還有作為libevent替代者的libev庫。這些庫會根據操作系統的特點選擇最合適的事件探測介面，並且加入了信號(signal) 等技術以支持非同步響應，這使得這些庫成為構建事件驅動模型的不二選擇。下章將介紹如何使用libev庫替換select或epoll介面，實現高效穩定的伺服器模型。

實際上，Linux內核從2.6開始，也引入了支持非同步響應的IO操作，如aio_read, aio_write，這就是非同步IO。

4、非同步IO（Asynchronous I/O）

Linux下的asynchronous IO其實用得不多，從內核2.6版本才開始引入。先看一下它的流程：

圖11 非同步IO

用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。

用非同步IO實現的伺服器這裡就不舉例了，以後有時間另開文章來講述。非同步IO是真正非阻塞的，它不會對請求進程產生任何的阻塞，因此對高並發的網路伺服器實現至關重要。

到目前為止，已經將四個IO模型都介紹完了。現在回過頭來回答最初的那幾個問題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。先回答最簡單的這個：blocking與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 operation completes; * 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這個系統調用。non-blocking IO在執行recvfrom這個系統調用的時候，如果kernel的數據沒有準備好，這時候不會block進程。但是當kernel中數據準備好的時候，recvfrom會將數據從kernel拷貝到用戶內存中，這個時候進程是被block了，在這段時間內進程是被block的。而asynchronous IO則不一樣，當進程發起IO操作之後，就直接返回再也不理睬了，直到kernel發送一個信號，告訴進程說IO完成。在這整個過程中，進程完全沒有被block。

還有一種不常用的signal driven IO，即信號驅動IO。總的來說，UNP中總結的IO模型有5種之多：阻塞IO，非阻塞IO，IO復用，信號驅動IO，非同步IO。前四種都屬於同步IO。阻塞IO不必說了。非阻塞IO ，IO請求時加上O_NONBLOCK一類的標誌位，立刻返回，IO沒有就緒會返回錯誤，需要請求進程主動輪詢不斷發IO請求直到返回正確。IO復用同非阻塞IO本質一樣，不過利用了新的select系統調用，由內核來負責本來是請求進程該做的輪詢操作。看似比非阻塞IO還多了一個系統調用開銷，不過因為可以支持多路IO，纔算提高了效率。信號驅動IO，調用sigaltion系統調用，當內核中IO數據就緒時以SIGIO信號通知請求進程，請求進程再把數據從內核讀入到用戶空間，這一步是阻塞的。

非同步IO，如定義所說，不會因為IO操作阻塞，IO操作全部完成才通知請求進程。 各個IO Model的比較如圖所示：

圖12 各種IO模型的比較

經過上面的介紹，會發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，並且當數據準備完成以後，也需要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人（kernel）完成，然後他人做完後發信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態，也不需要主動的去拷貝數據。

http://blog.csdn.net/xiexievv/article/details/44976215

推薦閱讀：

相關文章