[轉]IO模型及select、poll、epoll和kqueue的區別

標籤：

（一）首先，介紹幾種常見的I/O模型及其區別，如下：

• blocking I/O

• nonblocking I/O

• I/O multiplexing (select and poll)

• signal driven I/O (SIGIO)

• asynchronous I/O (the POSIX aio_functions)—————非同步IO模型最大的特點是 完成後發回通知。

  阻塞與否，取決於實現IO交換的方式。

       非同步阻塞是基於select，select函數本身的實現方式是阻塞的，而採用select函數有個好處就是它可以同時監聽多個檔案控制代碼.

       非同步非阻塞直接在完成後通知，使用者進程只需要發起一個IO操作然後立即返回，等IO操作真正的完成以後，應用程式會得到IO操作完成的通知，此時使用者進程只需要對資料進行處理就好了，不需要進行實際的IO讀寫操作，因為真正的IO讀取或者寫入操作已經由核心完成了。

 

 

1 blocking I/O 

這個不用多解釋吧，阻塞通訊端。是它調用過程的圖示：

 

重點解釋下，下面例子都會講到。首先application調用 recvfrom()轉入kernel，注意kernel有2個過程，wait for data和copy data from kernel to user。直到最後copy complete後，recvfrom()才返回。此過程一直是阻塞的。

 

2 nonblocking I/O： 

與blocking I/O對立的，非阻塞通訊端，調用過程圖如下：

 

可以看見，如果直接操作它，那就是個輪詢。。直到核心緩衝區有資料。

 

3 I/O multiplexing (select and poll) 

最常見的I/O複用模型，select。

 

select先阻塞，有活動通訊端才返回。與blocking I/O相比，select會有兩次系統調用，但是select能處理多個通訊端。

 

4 signal driven I/O (SIGIO) 

只有UNIX系統支援，感興趣的課查閱相關資料

 

與I/O multiplexing (select and poll)相比，它的優勢是，免去了select的阻塞與輪詢，當有活躍通訊端時，由註冊的handler處理。

 

5 asynchronous I/O (the POSIX aio_functions) 

很少有*nix系統支援，windows的IOCP則是此模型

 

完全非同步I/O複用機制，因為縱觀上面其它四種模型，至少都會在由kernel copy data to appliction時阻塞。而該模型是當copy完成後才通知application，可見是純非同步。好像只有windows的完成連接埠是這個模型，效率也很出色。

6 下面是以上五種模型的比較

可以看出，越往後，阻塞越少，理論上效率也是最優。

=====================分割線==================================

5種模型的比較比較清晰了，剩下的就是把select,epoll,iocp,kqueue按號入座那就OK了。

select和iocp分別對應第3種與第5種模型，那麼epoll與kqueue呢？其實也於select屬於同一種模型，只是更進階一些，可以看作有了第4種模型的某些特性，如callback機制。

為什麼epoll,kqueue比select進階？ 

答案是，他們無輪詢。因為他們用callback取代了。想想看，當通訊端比較多的時候，每次select()都要通過遍曆FD_SETSIZE個Socket來完成調度,不管哪個Socket是活躍的,都遍曆一遍。這會浪費很多CPU時間。如果能給通訊端註冊某個回呼函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。

windows or *nix （IOCP or kqueue/epoll）？

 

誠然，Windows的IOCP非常出色，目前很少有支援asynchronous I/O的系統，但是由於其系統本身的局限性，大型伺服器還是在UNIX下。而且正如上面所述，kqueue/epoll 與 IOCP相比，就是多了一層從核心copy資料到應用程式層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue與epoll已經做得很優秀了。

提供一致的介面，IO Design Patterns

實際上，不管是哪種模型，都可以抽象一層出來，提供一致的介面，廣為人知的有ACE,Libevent（基於reactor模式）這些，他們都是跨平台的，而且他們自動選擇最優的I/O複用機制，使用者只需調用介面即可。說到這裡又得說說2個設計模式，Reactor and Proactor。見：Reactor模式--VS--Proactor模式。Libevent是Reactor模型，ACE提供Proactor模型。實際都是對各種I/O複用機制的封裝。

Java nio包是什麼I/O機制？

 現在可以確定，目前的java本質是select()模型，可以檢查/jre/bin/nio.dll得知。至於java伺服器為什麼效率還不錯。。我也不得而知，可能是設計得比較好吧。。-_-。

=====================分割線==================================

總結一些重點：

1. 只有IOCP是asynchronous I/O，其他機制或多或少都會有一點阻塞。
2. select低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善
3. epoll, kqueue、select是Reacor模式，IOCP是Proactor模式。
4. java nio包是select模型。。

（二）epoll 與select的區別 

1. 使用多進程或者多線程，但是這種方法會造成程式的複雜，而且對與進程與線程的建立維護也需要很多的開銷。（Apache伺服器是用的子進程的方式，優點可以隔離使用者）  （同步阻塞IO）

 

2.一種較好的方式為I/O多路轉接（I/O multiplexing）（貌似也翻譯多工），先構造一張有關描述符的列表（epoll中為隊列），然後調用一個函數，直到這些描述符中的一個準備好時才返回，返回時告訴進程哪些I/O就緒。select和epoll這兩個機制都是多路I/O機制的解決方案，select為POSIX標準中的，而epoll為Linux所特有的。

 

區別（epoll相對select優點）主要有三：

1.select的控制代碼數目受限，在linux/posix_types.h標頭檔有這樣的聲明：#define __FD_SETSIZE    1024  表示select最多同時監聽1024個fd。而epoll沒有，它的限制是最大的開啟檔案控制代碼數目。

 

2.epoll的最大好處是不會隨著FD的數目增長而降低效率，在selec中採用輪詢處理，其中的資料結構類似一個數組的資料結構，而epoll是維護一個隊列，直接看隊列是不是空就可以了。epoll只會對"活躍"的socket進行操作---這是因為在核心實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有"活躍"的socket才會主動的去調用 callback函數（把這個控制代碼排入佇列），其他idle狀態控制代碼則不會，在這點上，epoll實現了一個"偽"AIO。但是如果絕大部分的I/O都是“活躍的”，每個I/O連接埠使用率很高的話，epoll效率不一定比select高（可能是要維護隊列複雜）。

 

3.使用mmap加速核心與使用者空間的訊息傳遞。無論是select,poll還是epoll都需要核心把FD訊息通知給使用者空間，如何避免不必要的記憶體拷貝就很重要，在這點上，epoll是通過核心於使用者空間mmap同一塊記憶體實現的。

 

關於epoll工作模式ET，LT    

 

epoll有兩種工作方式

ET：Edge Triggered，邊緣觸發。僅當狀態發生變化時才會通知，epoll_wait返回。換句話，就是對於一個事件，只通知一次。且只支援非阻塞的socket。

LT：Level Triggered，電平觸發（預設工作方式）。類似select/poll,只要還有沒有處理的事件就會一直通知，以LT方式調用epoll介面的時候，它就相當於一個速度比較快的poll.支援阻塞和不阻塞的socket。

 

三 Linux並髮網絡編程模型

 

    1  Apache 模型，簡稱 PPC （ Process Per Connection ，）:為每個串連分配一個進程。主機分配給每個串連的時間和空間上代價較大，並且隨著串連的增多，大量進程間切換開銷也增長了。很難應對大量的客戶並發串連。

    2  TPC 模型（ Thread Per Connection ）：每個串連一個線程。和PCC類似。

    3  select 模型：I/O多工技術。

       .1 每個串連對應一個描述。select模型受限於 FD_SETSIZE即進程最大開啟的描述符數linux2.6.35為1024,實際上linux每個進程所能開啟描數位個數僅受限於記憶體大小，然而在設計select的系統調用時，卻是參考FD_SETSIZE的值。可通過重新編譯核心更改此值，但不能根治此問題，對於百萬級的使用者串連請求  即便增加相應 進程數， 仍顯得杯水車薪呀。

      .2select每次都會掃描一個檔案描述符的集合，這個集合的大小是作為select第一個參數傳入的值。但是每個進程所能開啟檔案描述符若是增加了 ，掃描的效率也將減小。

      .3核心到使用者空間，採用記憶體複製傳遞檔案描述上發生的資訊。 

  4 poll 模型：I/O多工技術。poll模型將不會受限於FD_SETSIZE，因為核心所掃描的檔案 描述符集合的大小是由使用者指定的，即poll的第二個參數。但仍有掃描效率和記憶體拷貝問題。

 5 pselect模型：I/O多工技術。同select。

 6 epoll模型：

    .1)無檔案描述字大小限制僅與記憶體大小相關

   .2)epoll返回時已經明確的知道哪個socket fd發生了什麼事件，不用像select那樣再一個個比對。

  .3)核心到使用者空間採用共用記憶體方式，傳遞訊息。

四 ：FAQ  

1、單個epoll並不能解決所有問題，特別是你的每個操作都比較費時的時候，因為epoll是串列處理的。 所以你有還是必要建立線程池來發揮更大的效能。 

2、如果fd被註冊到兩個epoll中時，如果有時間發生則兩個epoll都會觸發事件。

3、如果註冊到epoll中的fd被關閉，則其會自動被清除出epoll監聽列表。
4、如果多個事件同時觸發epoll，則多個事件會被聯合在一起返回。
5、epoll_wait會一直監聽epollhup事件發生，所以其不需要添加到events中。
6、為了避免大資料量io時，et模式下只處理一個fd,其他fd被餓死的情況發生。linux建議可以在fd聯絡到的結構中增加ready位，然後epoll_wait觸發事件之後僅將其置位為ready模式，然後在下邊輪詢ready fd列表。

 

 

參考：

http://blog.csdn.net/ysu108/article/details/7570571

http://techbbs.zol.com.cn/1/8_2245.html

 

 

轉自：http://blog.csdn.net/wenbingoon/article/details/9004512

[轉]IO模型及select、poll、epoll和kqueue的區別