[轉]談談select, iocp, epoll,kqueue及各種網路I/O複用機制

標籤：des   style   blog   http   io   ar   color   os   sp   

　　參考原文：再談select, iocp, epoll,kqueue及各種I/O複用機制

一、I/O模型概述

　　介紹幾種常見的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)

（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模型/poll模型，兩者原理和資料結構均類似。

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

（4）signal driven I/O (SIGIO) 
　　只有UNIX系統支援，感興趣的課查閱相關資料。

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

（5）asynchronous I/O (the POSIX aio_functions，真正意義上的非同步IO) 
　　很少有*nix系統支援，windows的IOCP則是此模型。

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

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

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

二、實際模型分析

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

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

2.1 為什麼epoll,kqueue比select進階？ 

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

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

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

2.3 提供一致的介面，IO Design Patterns

　　實際上，不管是哪種模型，都可以抽象一層出來，提供一致的介面，廣為人知的有ACE，Libevent這些，他們都是跨平台的，而且他們自動選擇最優的I/O複用機制，使用者只需調用介面即可。說到這裡又得說說2個設計模式，Reactor and Proactor。有一篇經典文章http://www.artima.com/articles/io_design_patterns.html值得閱讀，Libevent是Reactor模型，ACE提供Proactor模型。實際都是對各種I/O複用機制的封裝。

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

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

 

小結：

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

[轉]談談select, iocp, epoll,kqueue及各種網路I/O複用機制