1. 概念理解

     在進行網路程式設計時，我們常常見到同步(Sync)/非同步(Async)，阻塞(Block)/非阻塞(Unblock)四種呼叫方式：

同步/非同步主要針對C端: 
同步：所謂同步，就是在c端發出一個功能呼叫時，在沒有得到結果之前，該呼叫就不返回。也就是必須一件一件事做,等前一件做完了才能做下一件事。

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

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

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

阻塞/非阻塞主要針對S端:

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

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

快遞的例子：比如到你某個時候到A樓一層（假如是核心緩衝區）取快遞，但是你不知道快遞什麼時候過來，你又不能幹別的事，只能死等著。但你可以睡覺（程序處於休眠狀態），因為你知道快遞把貨送來時一定會給你打個電話（假定一定能叫醒你）。

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

     還是等快遞的例子：如果用忙輪詢的方法，每隔5分鐘到A樓一層(核心緩衝區）去看快遞來了沒有。如果沒來，立即返回。而快遞來了，就放在A樓一層，等你去取。

物件的阻塞模式和阻塞函式呼叫物件是否處於阻塞模式和函式是不是阻塞呼叫有很強的相關性，但是並不是一一對應的。阻塞物件上可以有非阻塞的呼叫方式，我們可以通過一定的

API去輪詢狀態，在適當的時候呼叫阻塞函式，就可以避免阻塞。而對於非阻塞物件，呼叫特殊的函式也可以進入阻塞呼叫。函式select就是這樣的一個例子。

1. 同步，就是我客戶端（c端呼叫者）呼叫一個功能，該功能沒有結束前，我（c端呼叫者）死等結果。
2. 非同步，就是我（c端呼叫者）呼叫一個功能，不需要知道該功能結果，該功能有結果後通知我（c端呼叫者）即回撥通知。

同步/非同步主要針對C端, 但是跟S端不是完全沒有關係，同步/非同步機制必須S端配合才能實現.同步/非同步是由c端自己控制,但是S端是否阻塞/非阻塞, C端完全不需要關心.

3. 阻塞，      就是呼叫我（s端被呼叫者，函式），我（s端被呼叫者，函式）沒有接收完資料或者沒有得到結果之前，我不會返回。
4. 非阻塞，  就是呼叫我（s端被呼叫者，函式），我（s端被呼叫者，函式）立即返回，通過select通知呼叫者

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

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

同步和非同步都只針對於本機SOCKET而言的。

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

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

node.js裡面的描述：

        執行緒在執行中如果遇到磁碟讀寫或網路通訊（統稱為I/O 操作），通常要耗費較長的時間，這時作業系統會剝奪這個執行緒的CPU 控制權，使其暫停執行，同時將資源讓給其他的工作執行緒，這種執行緒排程方式稱為 阻塞。當I/O 操作完畢時，作業系統將這個執行緒的阻塞狀態解除，恢復其對CPU的控制權，令其繼續執行。這種I/O 模式就是通常的同步式I/O（Synchronous I/O）或阻塞式I/O （Blocking I/O）。
         相應地，非同步式I/O （Asynchronous I/O）或非阻塞式I/O （Non-blocking I/O）則針對所有I/O 操作不採用阻塞的策略。當執行緒遇到I/O 操作時，不會以阻塞的方式等待I/O 操作的完成或資料的返回，而只是將I/O 請求傳送給作業系統，繼續執行下一條語句。當作業系統完成I/O 操作時，以事件的形式通知執行I/O 操作的執行緒，執行緒會在特定時候處理這個事件。為了處理非同步I/O，執行緒必須有事件迴圈，不斷地檢查有沒有未處理的事件，依次予以處理。阻塞模式下，一個執行緒只能處理一項任務，要想提高吞吐量必須通過多執行緒。而非阻塞模式下，一個執行緒永遠在執行計算操作，<span style="color:#ff0000;">這個執行緒所使用的CPU 核心利用率永遠是100%</span>，I/O 以事件的方式通知。<span style="color:#ff0000;">在阻塞模式下，多執行緒往往能提高系統吞吐量，因為一個執行緒阻塞時還有其他執行緒在工作，多執行緒可以讓CPU 資源不被阻塞中的執行緒浪費。</span>而在非阻塞模式下，執行緒不會被I/O 阻塞，永遠在利用CPU。多執行緒帶來的好處僅僅是在多核CPU 的情況下利用更多的核，而Node.js的單執行緒也能帶來同樣的好處。這就是為什麼Node.js 使用了單執行緒、非阻塞的事件程式設計模式。

2. 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()等介面開始的。使用這些介面可以很方便的構建伺服器 /客戶機的模型。

阻塞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連線總會等待至少到伺服器的一次往返時間。

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

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

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

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

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

      多執行緒/程序伺服器同時為多個客戶機提供應答服務。模型如下：

       

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

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

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

      但是，“執行緒池”和“連線池”技術也只是在一定程度上緩解了頻繁呼叫 IO 介面帶來的資源佔用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小。

      對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“執行緒池”或“連線池”或許可以緩解部分壓力，但是不能解決所有問題。

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

3. select、poll、epoll簡介

select原型說明:http://blog.csdn.net/hguisu/article/details/38638183#t5

epoll模型：http://blog.csdn.net/hguisu/article/details/38638183#t12

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

同步/非同步與阻塞/非阻塞經常看到是成對出現：

同步阻塞,非同步非阻塞,同步非阻塞

感謝您的支援，我會繼續努力的! 掃碼打賞，你說多少就多少