一、Linux網絡I/O模型簡介

Linux的內核將所有外部設備都看做一個文件來操作，對一個文件的讀寫操作會調用內核提供的系統命令，返回一個file descriptor（fd，文件描述符 ）。而對一個socket的讀寫也會有相應的描述符，稱為socketfd（socket描述符），描述符就是一個數字，它指向內核中的一個結構體（文件路徑，數據區等一些屬性）。

根據UNIX網絡編程對I/O模型的分類，UNIX提供了5種I/O模型，分別如下：

• 阻塞I/O模型
  最常用的I/O模型就是阻塞I/O模型，缺省情形下，所有文件操作都是阻塞的。我們以套接字接口為例來講解此模型。在進程空間中調用recvfrom，其系統調用直到數據包到達且被復制到應用進程的緩沖區中或者發生錯誤時才返回，在此期間一直會等待，進程在從調用recvfrom開始到它返回的整段時間內都是被阻塞的，因此被稱為阻塞I/O模型。

阻塞I/O模型

• 非阻塞I/O模型
  rcvfrom從應用層到內核的時候，如果該緩沖區沒有數據的話，就直接返回一個EWOULDBLOCK錯誤，一般都對非阻塞I/O模型進行輪詢檢查這個狀態，看內核是不是有數據到來。

非阻塞I/O模型

• I/O復用模型
  Linux提供select/poll（I/O復用模型會用到select或者poll函數，這兩個函數也會使進程阻塞，但是和阻塞I/O所不同的是，這兩個函數可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數進行檢測，直到有數據可讀或可寫時，才真正調用I/O操作函數），進程通過將一個或多個fd傳遞給select或poll系統調用，阻塞在select操作上，這樣select/poll可以幫我們偵測多fd是否處于就緒狀態。select/poll是順序掃描fd是否就緒，而且支持的fd數量有限，因此它的使用受到了一些制約。Linux還提供了一個epoll系統調用，epoll使用基于事件驅動方式代替順序掃描，因此性能更高。當有fd就緒時，立即回調函數rollback。

I/O復用模型

• 信號驅動I/O模型
  首先開啟套接口信號驅動I/O功能，并通過系統調用sigaction執行一個信號處理函數（此系統調用立即返回，進程繼續工作，它是非阻塞的）。當數據準備就緒時，就為該進程生成一個SIGIO信號，通過信號回調通知應用程序調用recvfrom來讀取數據，并通知主循環函數處理數據。

信號驅動I/O模型

• 異步I/O
  告知內核啟動某個操作，并讓內核在整個操作完成后（包括將數據從內核復制到用戶自己的緩沖區）通知我們。這種模型與信號驅動模型的主要區別是：信號驅動I/O由內核通知我們何時可以開始一個I/O操作；異步I/O模型由內核通知我們I/O操作何時已經完成。

異步I/O

二、I/O多路復用技術

在I/O編程過程中，當需要同時處理多個客戶端接入請求時，可以利用多線程或者I/O多路復用技術進行處理。I/O多路復用技術通過把多個I/O的阻塞復用到同一個select的阻塞上，從而使得系統在單線程的情況下可以同時處理多個客戶端請求。與傳統的多線程/多進程模型比，I/O多路復用的最大優勢是系統開銷小，系統不需要創建新的額外進程或者線程，也不需要維護這些進程和線程的運行，降底了系統的維護工作量，節省了系統資源，I/O多路復用的主要應用場景如下：

• 服務器需要同時處理多個處于監聽狀態或者多個連接狀態的套接字。
• 服務器需要同時處理多種網絡協議的套接字。

目前支持I/O多路復用的系統調用有 select，pselect，poll，epoll，在Linux網絡編程過程中，很長一段時間都使用select做輪詢和網絡事件通知，然而select的一些固有缺陷導致了它的應用受到了很大的限制，最終Linux不得不在新的內核版本中尋找select的替代方案，最終選擇了epoll。epoll與select的原理比較類似，為了克服select的缺點，epoll作了很多重大改進，現總結如下：

1. 支持一個進程打開的socket描述符（FD）不受限制（僅受限于操作系統的最大文件句柄數）。
   select最大的缺陷就是單個進程所打開的FD是有一定限制的，它由FD_SETSIZE設置，默認值是1024。對于那些需要支持上萬個TCP連接的大型服務器來說顯然太少了。可以選擇修改這個宏，然后重新編譯內核，不過這會帶來網絡效率的下降。我們也可以通過選擇多進程的方案（傳統的Apache方案）解決這個問題，不過雖然在Linux上創建進程的代價比較小，但仍舊是不可忽視的，另外，進程間的數據交換非常麻煩，對于Java由于沒有共享內存，需要通過Socket通信或者其他方式進行數據同步，這帶來了額外的性能損耗，增加了程序復雜度，所以也不是一種完美的解決方案。值得慶幸的是，epoll并沒有這個限制，它所支持的FD上限是操作系統的最大文件句柄數，這個數字遠遠大于1024。例如，在1GB內存的機器上大約是10萬個句柄左右，具體的值可以通過cat/proc/sys/fs/filemax察看，通常情況下這個值跟系統的內存關系比較大。

2. I/O效率不會隨著FD數目的增加而線性下降。
   傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，由于網絡延時或者鏈路空閑，任一時刻只有少部分的socket是“活躍”的，但是select/poll每次調用都會線性掃描全部集合，導致效率呈現線性下降。epoll不存在這個問題，它只會對“活躍”的socket進行操作-這是因為在內核實現中epoll是根據每個fd上面的callback函數實現的，那么，只有“活躍”的socket才會主動的去調用callback函數，其他idle狀態socket則不會。在這點上，epoll實現了一個偽AIO。針對epoll和select性能對比的benchmark測試表明：如果所有的socket都處于活躍態。例如一個高速LAN環境，epoll并不比select/poll效率高太多；相反，如果過多使用epoll_ctl，效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境，epoll的效率就遠在select/poll之上了。

3. 使用mmap加速內核與用戶空間的消息傳遞
   無論是select，poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存復制就顯得非常重要，epoll是通過內核和用戶空間mmap使用同一塊內存實現。

4. epoll的API更加簡單
   用來克服select/poll缺點的方法不只有epoll，epoll只是一種Linux的實現方案。在freeBSD下有kqueue，而dev/poll是最古老的Solaris的方案，使用難度依次遞增。但epoll更加簡單。