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函數返回成功指示。

     我們第一次接觸到的網絡編程都是從 listen()、send()、recv()等接口開始的。使用這些接口可以很方便的構建服務器 /客戶機的模型。

當調用recv()函數時，系統首先查是否有准備好的數據。如果數據沒有准備好，那么系統就處於等待狀態。當數據准備好后，將數據從系統緩沖區復制到用戶空間，然后該函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那么此時recv()函數就會處於等待狀態。

Sockets API調用分為以下四種:

    1．輸入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函數。以阻塞套接字為參數調用該函數接收數據。如果此時套接字緩沖區內沒有數據可讀，則調用線程在數據到來前一直睡眠。

    2．輸出操作： send()、sendto()、WSASend()和WSASendto()函數。以阻塞套接字為參數調用該函數發送數據。如果套接字緩沖區沒有可用空間，線程會一直睡眠，直到有空間。

    3．接受連接：accept()和WSAAcept()函數。以阻塞套接字為參數調用該函數，等待接受對方的連接請求。如果此時沒有連接請求，線程就會進入睡眠狀態。

補充一個listen函數的作用：
listen函數使用主動連接套接口變為被連接套接口，使得一個進程可以接受其它進程的請求，從而成為一個服務器進程。在TCP服務器編程中listen函數把進程變為一個服務器，並指定相應的套接字變為被動連接。

   4．外出連接：connect()和WSAConnect()函數。對於TCP連接，客戶端以阻塞套接字為參數，調用該函數向服務器發起連接。該函數在收到服務器的應答前，不會返回。這意味着TCP連接總會等待至少到服務器的一次往返時間。

阻塞模式給網絡編程帶來了一個很大的問題，如在調用 send()的同時，線程將被阻塞，在此期間，線程將無法執行任何運算或響應任何的網絡請求。這給多客戶機、多業務邏輯的網絡編程帶來了挑戰。這時，我們可能會選擇多線程的方式來解決這個問題。

應對多客戶機的網絡應用，最簡單的解決方式是在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。

 

具體使用多進程還是多線程，並沒有一個特定的模式。傳統意義上，進程的開銷要遠遠大於線程，所以，如果需要同時為較多的客戶機提供服務，則不推薦使用多進程；如果單個服務執行體需要消耗較多的 CPU 資源，譬如需要進行大規模或長時間的數據運算或文件訪問，則進程較為安全（線程則需要同步）。通常，使用 pthread_create () 創建新線程，fork() 創建新進程。

 

多線程/進程服務器同時為多個客戶機提供應答服務。模型如下：

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

上述多線程的服務器模型似乎完美的解決了為多個客戶機提供問答服務的要求，但其實並不盡然。如果要同時響應成百上千路的連接請求，則無論多線程還是多進程都會嚴重占據系統資源，降低系統對外界響應效率，而線程與進程本身也更容易進入假死狀態。

 

由此可能會考慮使用“線程池”或“連接池”。“線程池”旨在減少創建和銷毀線程的頻率，其維持一定合理數量的線程，並讓空閑的線程重新承擔新的執行任務。“連接池”維持連接的緩存池，盡量重用已有的連接、減少創建和關閉連接的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如apache，mysql數據庫等。

 

 但是，“線程池”和“連接池”技術也只是在一定程度上緩解了頻繁調用 IO 接口帶來的資源占用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小。對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。

補充一下連接池：
  采用CS方式的程序不可避免都要碰到socket連接的問題，很多時候，使用編程語言當中自帶的socket庫，使用起來多少有些不習慣，雖然系統自帶的庫在很多異常處理，穩定性上下了很多功夫，但是要去理解和使用那些庫，比如做socket連接池不免要走很多彎路。在這里我和大家討論下怎么樣創建和使用socket鏈接池。 
    一般socket鏈接有以下兩種方式：長（常）鏈接和短鏈接。 
    長鏈接：當數據發送完成后socket鏈接不斷開。一直保留到異常或者是程序退出為止，這種方式的好處是不用每次去發起連接斷開，在速度上可以比短連接要快一些，但是相對來說對服務器的資源壓力也要大些。長鏈接用的范圍很廣，比如游戲系統，qq等等，長（常）鏈接一般還需要定時向服務器ping數據，以保證socket鏈接暢通。當ping不通服務器時，需要重新開啟鏈接。 
    短鏈接：當一次數據發送完畢后，主動斷開鏈接，每次發送數據都要一次鏈接、斷開操作，這種方式的好處是：對服務器的資源占用相對來說比較小，但是由於每次都要重新鏈接，速度開銷上也比較大，這種方式對於那種不需要經常與服務器交互的情況下比較適用。 
    上面兩種方法在用戶量非常大的情況下都存在着很大的不足，因此，我們考慮可以用一種折衷的辦法，那就是使用socket的連接池。 
    程序一開始初始化創建若干數量的長鏈接。給他們設置一個標識位，這個標識位表示該鏈接是否空閑的狀態。當需要發送數據的時候，系統給它分配一個當前空閑的鏈接。同時，將得到的鏈接設置為“忙”，當數據發送完畢后，把鏈接標識位設置為“閑”，讓系統可以分配給下個用戶，這樣使得兩種方式的優點都充分的發揮出來了。

 

非阻塞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模型的比較：

 

 

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