1. 概念理解

     在進行網路程式設計時，我們常常見到同步(Sync)/非同步(Async)，阻塞(Block)/非阻塞(Unblock)四種呼叫方式：同步：所謂同步，就是在發出一個功能呼叫時，在沒有得到結果之前，該呼叫就不返回。也就是必須一件一件事做,等前一件做完了才能做下一件事。

例如普通B/S模式（同步）：提交請求->等待伺服器處理->處理完畢返回這個期間客戶端瀏覽器不能幹任何事

非同步：非同步的概念和同步相對。當一個非同步過程呼叫發出後，呼叫者不能立刻得到結果。實際處理這個呼叫的部件在完成後，通過狀態、通知和回撥來通知呼叫者。

例如 ajax請求（非同步）

: 請求通過事件觸發->伺服器處理（這是瀏覽器仍然可以作其他事情）->處理完畢

阻塞阻塞呼叫是指呼叫結果返回之前，當前執行緒會被掛起（執行緒進入非可執行狀態，在這個狀態下，cpu不會給執行緒分配時間片，即執行緒暫停執行）。函式只有在得到結果之後才會返回。

     有人也許會把阻塞呼叫和同步呼叫等同起來，實際上他是不同的。對於同步呼叫來說，很多時候當前執行緒還是啟用的，只是從邏輯上當前函式沒有返回而已。 例如，我們在socket中呼叫recv函式，如果緩衝區中沒有數據，這個函式就會一直等待，直到有資料才返回。而此時，當前執行緒還會繼續處理各種各樣的訊息。

非阻塞非阻塞和阻塞的概念相對應，指在不能立刻得到結果之前，該函式不會阻塞當前執行緒，而會立刻返回。

物件的阻塞模式和阻塞函式呼叫物件是否處於阻塞模式和函式是不是阻塞呼叫有很強的相關性，但是並不是一一對應的。阻塞物件上可以有非阻塞的呼叫方式，我們可以通過一定的API去輪詢狀態，在適當的時候呼叫阻塞函式，就可以避免阻塞。而對於非阻塞物件，呼叫特殊的函式也可以進入阻塞呼叫。函式select就是這樣的一個例子。

1. 同步，就是我呼叫一個功能，該功能沒有結束前，我死等結果。
2. 非同步，就是我呼叫一個功能，不需要知道該功能結果，該功能有結果後通知我（回撥通知）
3. 阻塞，      就是呼叫我（函式），我（函式）沒有接收完資料或者沒有得到結果之前，我不會返回。
4. 非阻塞，  就是呼叫我（函式）

，我（函式）立即返回，通過select通知呼叫者

同步IO和非同步IO的區別就在於：資料拷貝的時候程序是否阻塞！

阻塞IO和非阻塞IO的區別就在於：應用程式的呼叫是否立即返回！

對於舉個簡單c/s 模式：

同步：提交請求->等待伺服器處理->處理完畢返回這個期間客戶端瀏覽器不能幹任何事
非同步：請求通過事件觸發->伺服器處理（這是瀏覽器仍然可以作其他事情）->處理完畢 同步和非同步都只針對於本機SOCKET而言的。

同步和非同步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的物件也不相同。
阻塞和非阻塞是指當程序訪問的資料如果尚未就緒,程序是否需要等待,簡單說這相當於函式內部的實現區別,也就是未就緒時是直接返回還是等待就緒;

而同步和非同步是指訪問資料的機制,同步一般指主動請求並等待I/O操作完畢的方式,當資料就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段,同步的讀寫必須阻塞),非同步則指主動請求資料後便可以繼續處理其它任務,隨後等待I/O,操作完畢的通知,這可以使程序在資料讀寫時也不阻塞。(等待"通知")

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

阻塞I/O模型圖：在呼叫recv()/recvfrom（）函式時，發生在核心中等待資料和複製資料的過程。

    當呼叫recv()函式時，系統首先查是否有準備好的資料。如果資料沒有準備好，那麼系統就處於等待狀態。當資料準備好後，將資料從系統緩衝區複製到使用者空間，然後該函式返回。在套接應用程式中，當呼叫recv()函式時，未必使用者空間就已經存在資料，那麼此時recv()函式就會處於等待狀態。

     當使用socket()函式和WSASocket()函式建立套接字時，預設的套接字都是阻塞的。這意味著當呼叫Windows Sockets API不能立即完成時，執行緒處於等待狀態，直到操作完成。

    並不是所有Windows Sockets API以阻塞套接字為引數呼叫都會發生阻塞。例如，以阻塞模式的套接字為引數呼叫bind()、listen()函式時，函式會立即返回。將可能阻塞套接字的Windows Sockets API呼叫分為以下四種:

    1．輸入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函式。以阻塞套接字為引數呼叫該函式接收資料。如果此時套接字緩衝區內沒有資料可讀，則呼叫執行緒在資料到來前一直睡眠。

    2．輸出操作： send()、sendto()、WSASend()和WSASendto()函式。以阻塞套接字為引數呼叫該函式傳送資料。如果套接字緩衝區沒有可用空間，執行緒會一直睡眠，直到有空間。

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

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

　　使用阻塞模式的套接字，開發網路程式比較簡單，容易實現。當希望能夠立即傳送和接收資料，且處理的套接字數量比較少的情況下，使用阻塞模式來開發網路程式比較合適。

    阻塞模式套接字的不足表現為，在大量建立好的套接字執行緒之間進行通訊時比較困難。當使用“生產者-消費者”模型開發網路程式時，為每個套接字都分別分配一個讀執行緒、一個處理資料執行緒和一個用於同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量套接字時，將無從下手，其擴充套件性很差

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

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