一、IO模型介紹

　　Stevens在文章中一共比較了五種IO Model：
   　　 * blocking IO           阻塞IO
   　　 * nonblocking IO      非阻塞IO
  　　  * IO multiplexing      IO多路複用
   　　 * signal driven IO     訊號驅動IO
 　　   * asynchronous IO    非同步IO
    由signal driven IO（訊號驅動IO）在實際中並不常用，所以主要介紹其餘四種IO Model。

    再說一下IO發生時涉及的物件和步驟。對於一個network IO (這裡我們以read舉例)，它會涉及到兩個系統物件，一個是呼叫這個IO的process (or thread)，另一個就是系統核心(kernel)。當一個read操作發生時，該操作會經歷兩個階段：

#1）等待資料準備 (Waiting for the data to be ready)
#2）將資料從核心拷貝到程序中(Copying the data from the kernel to the process)

　　記住這兩點很重要，因為這些IO模型的區別就是在兩個階段上各有不同的情況。

二、阻塞IO(blocking IO)

　　在linux中，預設情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：

　　當用戶程序呼叫了recvfrom這個系統呼叫，kernel就開始了IO的第一個階段：準備資料。對於network io來說，很多時候資料在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的資料到來。

    而在使用者程序這邊，整個程序會被阻塞。當kernel一直等到資料準備好了，它就會將資料從kernel中拷貝到使用者記憶體，然後kernel返回結果，使用者程序才解除block的狀態，重新執行起來。
    所以，blocking IO的特點就是在IO執行的兩個階段（等待資料和拷貝資料兩個階段）都被block了。

    幾乎所有的程式設計師第一次接觸到的網路程式設計都是從listen()、send()、recv() 等介面開始的，使用這些介面可以很方便的構建伺服器/客戶機的模型。然而大部分的socket介面都是阻塞型的。如下圖

    ps：所謂阻塞型介面是指系統呼叫（一般是IO介面）不返回呼叫結果並讓當前執行緒一直阻塞，只有當該系統呼叫獲得結果或者超時出錯時才返回。

　實際上，除非特別指定，幾乎所有的IO介面 ( 包括socket介面 ) 都是阻塞型的。這給網路程式設計帶來了一個很大的問題，如在呼叫recv(1024)的同時，執行緒將被阻塞，在此期間，執行緒將無法執行任何運算或響應任何的網路請求。

    一個簡單的解決方案：

#在伺服器端使用多執行緒（或多程序）。多執行緒（或多程序）的目的是讓每個連線都擁有獨立的執行緒（或程序），這樣任何一個連線的阻塞都不會影響其他的連線。

    該方案的問題是：

#開啟多程序或都執行緒的方式，在遇到要同時響應成百上千路的連線請求，則無論多執行緒還是多程序都會嚴重佔據系統資源，降低系統對外界響應效率，而且執行緒與程序本身也更容易進入假死狀態。

   改進方案：

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

    改進後方案其實也存在著問題：

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

    對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“執行緒池”或“連線池”或許可以緩解部分壓力，但是不能解決所有問題。總之，多執行緒模型可以方便高效的解決小規模的服務請求，但面對大規模的服務請求，多執行緒模型也會遇到瓶頸，可以用非阻塞介面來嘗試解決這個問題。

三、非阻塞IO(non-blocking IO)

Linux下，可以通過設定socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：

　　從圖中可以看出，當用戶程序發出read操作時，如果kernel中的資料還沒有準備好，那麼它並不會block使用者程序，而是立刻返回一個error。從使用者程序角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。使用者程序判斷結果是一個error時，它就知道資料還沒有準備好，於是使用者就可以在本次到下次再發起read詢問的時間間隔內做其他事情，或者直接再次傳送read操作。一旦kernel中的資料準備好了，並且又再次收到了使用者程序的system call，那麼它馬上就將資料拷貝到了使用者記憶體（這一階段仍然是阻塞的），然後返回。

    也就是說非阻塞的recvform系統呼叫呼叫之後，程序並沒有被阻塞，核心馬上返回給程序，如果資料還沒準備好，此時會返回一個error。程序在返回之後，可以乾點別的事情，然後再發起recvform系統呼叫。重複上面的過程，迴圈往復的進行recvform系統呼叫。這個過程通常被稱之為輪詢。輪詢檢查核心資料，直到資料準備好，再拷貝資料到程序，進行資料處理。需要注意，拷貝資料整個過程，程序仍然是屬於阻塞的狀態。

    所以，在非阻塞式IO中，使用者程序其實是需要不斷的主動詢問kernel資料準備好了沒有。

#服務端
from socket import *
import time
s=socket(AF_INET,SOCK_STREAM)
s.bind(('127.0.0.1',8080))
s.listen(5)
s.setblocking(False) #設定socket的介面為非阻塞
conn_l=[]
del_l=[]
while True:
    try:
        conn,addr=s.accept()
        conn_l.append(conn)
    except BlockingIOError:
        print(conn_l)
        for conn in conn_l:
            try:
                data=conn.recv(1024)
                if not data:
                    del_l.append(conn)
                    continue
                conn.send(data.upper())
            except BlockingIOError:
                pass
            except ConnectionResetError:
                del_l.append(conn)

        for conn in del_l:
            conn_l.remove(conn)
            conn.close()
        del_l=[]

#客戶端
from socket import *
c=socket(AF_INET,SOCK_STREAM)
c.connect(('127.0.0.1',8080))

while True:
    msg=input('>>: ')
    if not msg:continue
    c.send(msg.encode('utf-8'))
    data=c.recv(1024)
    print(data.decode('utf-8'))

但是非阻塞IO模型絕不被推薦。

    我們不能否則其優點：能夠在等待任務完成的時間裡幹其他活了（包括提交其他任務，也就是 “後臺” 可以有多個任務在“”同時“”執行）。

    但是也難掩其缺點：

#1. 迴圈呼叫recv()將大幅度推高CPU佔用率；這也是我們在程式碼中留一句time.sleep(2)的原因,否則在低配主機下極容易出現卡機情況
#2. 任務完成的響應延遲增大了，因為每過一段時間才去輪詢一次read操作，而任務可能在兩次輪詢之間的任意時間完成。這會導致整體資料吞吐量的降低。

    此外，在這個方案中recv()更多的是起到檢測“操作是否完成”的作用，實際作業系統提供了更為高效的檢測“操作是否完成“作用的介面，例如select()多路複用模式，可以一次檢測多個連線是否活躍。

四、多路複用IO(IO multiplexing)

IO multiplexing這個詞可能有點陌生，但是如果我說select/epoll，大概就都能明白了。有些地方也稱這種IO方式為事件驅動IO(event driven IO)。我們都知道，select/epoll的好處就在於單個process就可以同時處理多個網路連線的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有資料到達了，就通知使用者程序。它的流程如圖：

    當用戶程序呼叫了select，那麼整個程序會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的資料準備好了，select就會返回。這個時候使用者程序再呼叫read操作，將資料從kernel拷貝到使用者程序。
    這個圖和blocking IO的圖其實並沒有太大的不同，事實上還更差一些。因為這裡需要使用兩個系統呼叫(select和recvfrom)，而blocking IO只調用了一個系統呼叫(recvfrom)。但是，用select的優勢在於它可以同時處理多個connection。

    強調：

    1. 如果處理的連線數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server效能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連線能處理得更快，而是在於能處理更多的連線。

    2. 在多路複用模型中，對於每一個socket，一般都設定成為non-blocking，但是，如上圖所示，整個使用者的process其實是一直被block的。只不過process是被select這個函式block，而不是被socket IO給block。

    結論: select的優勢在於可以處理多個連線，不適用於單個連線 

#服務端
from socket import *
import select

s=socket(AF_INET,SOCK_STREAM)
s.setsockopt(SOL_SOCKET,SO_REUSEADDR,1)
s.bind(('127.0.0.1',8081))
s.listen(5)
s.setblocking(False) #設定socket的介面為非阻塞
read_l=[s,]
while True:
    r_l,w_l,x_l=select.select(read_l,[],[])
    print(r_l)
    for ready_obj in r_l:
        if ready_obj == s:
            conn,addr=ready_obj.accept() #此時的ready_obj等於s
            read_l.append(conn)
        else:
            try:
                data=ready_obj.recv(1024) #此時的ready_obj等於conn
                if not data:
                    ready_obj.close()
                    read_l.remove(ready_obj)
                    continue
                ready_obj.send(data.upper())
            except ConnectionResetError:
                ready_obj.close()
                read_l.remove(ready_obj)

#客戶端
from socket import *
c=socket(AF_INET,SOCK_STREAM)
c.connect(('127.0.0.1',8081))

while True:
    msg=input('>>: ')
    if not msg:continue
    c.send(msg.encode('utf-8'))
    data=c.recv(1024)
    print(data.decode('utf-8'))

select監聽fd變化的過程分析：

#使用者程序建立socket物件，拷貝監聽的fd到核心空間，每一個fd會對應一張系統檔案表，核心空間的fd響應到資料後，就會發送訊號給使用者程序資料已到；

#使用者程序再發送系統呼叫，比如（accept）將核心空間的資料copy到使用者空間，同時作為接受資料端核心空間的資料清除，這樣重新監聽時fd再有新的資料又可以響應到了（傳送端因為基於TCP協議所以需要收到應答後才會清除）。 

    該模型的優點：

#相比其他模型，使用select() 的事件驅動模型只用單執行緒（程序）執行，佔用資源少，不消耗太多 CPU，同時能夠為多客戶端提供服務。如果試圖建立一個簡單的事件驅動的伺服器程式，這個模型有一定的參考價值。 

    該模型的缺點：

#首先select()介面並不是實現“事件驅動”的最好選擇。因為當需要探測的控制代碼值較大時，select()介面本身需要消耗大量時間去輪詢各個控制代碼。
#很多作業系統提供了更為高效的介面，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。
#如果需要實現更高效的伺服器程式，類似epoll這樣的介面更被推薦。遺憾的是不同的作業系統特供的epoll介面有很大差異，
#所以使用類似於epoll的介面實現具有較好跨平臺能力的伺服器會比較困難。
#其次，該模型將事件探測和事件響應夾雜在一起，一旦事件響應的執行體龐大，則對整個模型是災難性的。

 　　select做得事情和第二階段的阻塞沒有關係，就是從核心態將資料拷貝到使用者態的阻塞，始終幫你做得監聽的工作，幫你節省了一些第一階段阻塞的時間。

 　　IO多路複用的機制：

　　　　select機制： Windows、Linux

　　　　poll機制    ： Linux    #和lselect監聽機制一樣，但是對監聽列表裡面的數量沒有限制，select預設限制是1024個，但是他們兩個都是作業系統輪詢每一個被監聽的檔案描述符（如果數量很大，其實效率不太好），看是否有可讀操作。

　　　　epoll機制  ： Linux    #它的監聽機制和上面兩個不同，他給每一個監聽的物件綁定了一個回撥函式，你這個物件有訊息，那麼觸發回撥函式給使用者，使用者就進行系統呼叫來拷貝資料，並不是輪詢監聽所有的被監聽物件，這樣的效率高很多。

五、非同步IO(Asynchronous I/O)

Linux下的asynchronous IO其實用得不多，從核心2.6版本才開始引入。先看一下它的流程：

    使用者程序發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對使用者程序產生任何block。然後，kernel作業系統會等待資料（阻塞）準備完成，然後將資料拷貝到使用者記憶體，當這一切都完成之後，kernel會給使用者程序傳送一個signal，告訴它read操作完成了。

　　貌似非同步IO這個模型很牛~~但是你發現沒有，這不是我們自己程式碼控制的，都是作業系統完成的，而python在copy資料這個階段沒有提供操縱作業系統的介面，所以用python沒法實現這套非同步IO機制，其他幾個IO模型都沒有解決第二階段的阻塞（使用者態和核心態之間copy資料），但是C語言是可以實現的，因為大家都知道C語言是最接近底層的，雖然我們用python實現不了，但是python仍然有非同步的模組和框架（tornado、twstied，高併發需求的時候用），這些模組和框架很多都是用底層的C語言實現的，它幫我們實現了非同步，你只要使用就可以了，但是你要知道這個非同步是不是很好呀，不需要你自己等待了，作業系統幫你做了所有的事情，你就直接收資料就行了，就像你有一張銀行卡，銀行定期給你打錢一樣。

六、IO模型比較分析

 各個IO Model的比較如圖所示：

　　經過上面的介紹，會發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然程序大部分時間都不會被block，但是它仍然要求程序去主動的check，並且當資料準備完成以後，也需要程序主動的再次呼叫recvfrom來將資料拷貝到使用者記憶體。而asynchronous IO則完全不同。它就像是使用者程序將整個IO操作交給了他人（kernel）完成，然後他人做完後發訊號通知。在此期間，使用者程序不需要去檢查IO操作的狀態，也不需要主動的去拷貝資料。