一、多路複用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拷貝到使用者程序。

強調：

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的優勢在於可以處理多個連線，不適用於單個連線。

select網路IO模型示例：

from socket import *
import select

server = socket(AF_INET, SOCK_STREAM)
server.bind(("192.168.2.209",9900))
server.listen(5)
server.setblocking(False)

rlist = [server,]   # 收，存一堆conn，和server
wlist = []          # 發，存一堆conn，一旦快取區沒滿，證明可以發了
wdata = {}
 
while True:
    rl,wl,xl = select.select(rlist,wlist,[],1)   # 後面的列表是出異常的列表,1是超時時間，每隔1s問一遍作業系統
    print("rl",rl)      # 收的套接字
    print("wl",wl)      # 發的套接字

    for sock in rl:
        if sock == server:
            conn,addr = sock.accept()
            rlist.append(conn)
        else:
            try:    # recv的時候，客戶端單方面的把連結斷開，會拋異常，在這裡捕獲下
                data = sock.recv(1024)
                if not data:    # 客戶端沒發資料，跳過
                    sock.close()
                    rlist.remove(sock)
                    continue
                wlist.append(sock)
                wdata[sock] = data.upper()
            except Exception:
                sock.close()
                rlist.remove(sock)

    for sock in wl:
        data = wdata[sock]
        sock.send(data)
        wlist.remove(sock)
        wdata.pop(sock)

server.close()

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

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

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

該模型的優點：

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

該模型的缺點：

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

# 其次，該模型將事件探測和事件響應夾雜在一起，一旦事件響應的執行體龐大，則對整個模型是災難性的。

二、非同步IO（Asynchronous I/O）

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

使用者程序發起 read操作之後，立刻就可以開始去做其它的事。

而另一方面，從 kernel的角度，當它受到一個 asynchronous read之後，首先它會立刻返回，所以不會對使用者程序產生任何 block。

然後，kernel會等待資料準備完成，然後將資料拷貝到使用者記憶體，當這一切都完成之後，kernel會給使用者程序傳送一個signal，告訴它read操作完成了。

三、IO模型比較分析

到目前為止，已經將四個 IO Model都介紹完了。現在回過頭來回答最初的那幾個問題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。

先回答最簡單的這個：blocking vs non-blocking。前面的介紹中其實已經很明確的說明了這兩者的區別。

呼叫 blocking IO會一直block住對應的程序直到操作完成，而non-blocking IO在kernel還準備資料的情況下會立刻返回。

再說明 synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。Stevens給出的定義（其實是POSIX的定義）是這樣子的：
A synchronous I/O operation causes the requesting process to be blocked until thatI/O operationcompletes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
兩者的區別就在於 synchronous IO做”IO operation”的時候會將 process阻塞。

按照這個定義，四個IO模型可以分為兩大類，之前所述的 blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO這一類，而asynchronous I/O後一類 。

有人可能會說，non-blocking IO並沒有被 block啊。這裡有個非常“狡猾”的地方，定義中所指的”IO operation”是指真實的IO操作，就是例子中的 recvfrom這個 system call。

non-blocking IO在執行recvfrom這個system call的時候，如果kernel的資料沒有準備好，這時候不會block程序。

但是，當 kernel中資料準備好的時候，recvfrom會將資料從 kernel拷貝到使用者記憶體中，這個時候程序是被 block了，在這段時間內，程序是被 block的。

而 asynchronous IO則不一樣，當程序發起 IO操作之後，就直接返回再也不理睬了，直到 kernel傳送一個訊號，告訴程序說 IO完成。在這整個過程中，程序完全沒有被 block。

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

經過上面的介紹，會發現 non-blocking IO和 asynchronous IO的區別還是很明顯的。

在 non-blocking IO中，雖然程序大部分時間都不會被 block，但是它仍然要求程序去主動的 check，並且當資料準備完成以後，也需要程序主動的再次呼叫 recvfrom來將資料拷貝到使用者記憶體。

而 asynchronous IO則完全不同。它就像是使用者程序將整個 IO操作交給了他人（kernel）完成，然後他人做完後發訊號通知。在此期間，使用者程序不需要去檢查 IO操作的狀態，也不需要主動的去拷貝資料。

四、selectors模組

1，瞭解 selectors，poll，epoll

IO複用：為了解釋這個名詞，首先來理解下複用這個概念，複用也就是共用的意思，這樣理解還是有些抽象，
為此，咱們來理解下複用在通訊領域的使用，在通訊領域中為了充分利用網路連線的物理介質，
往往在同一條網路鏈路上採用時分複用或頻分複用的技術使其在同一鏈路上傳輸多路訊號，到這裡我們就基本上理解了複用的含義，
即公用某個“介質”來儘可能多的做同一類(性質)的事，那IO複用的“介質”是什麼呢？為此我們首先來看看伺服器程式設計的模型，
客戶端發來的請求服務端會產生一個程序來對其進行服務，每當來一個客戶請求就產生一個程序來服務，然而程序不可能無限制的產生，
因此為了解決大量客戶端訪問的問題，引入了IO複用技術，即：一個程序可以同時對多個客戶請求進行服務。
也就是說IO複用的“介質”是程序(準確的說複用的是select和poll，因為程序也是靠呼叫select和poll來實現的)，
複用一個程序(select和poll)來對多個IO進行服務，雖然客戶端發來的IO是併發的但是IO所需的讀寫資料多數情況下是沒有準備好的，
因此就可以利用一個函式(select和poll)來監聽IO所需的這些資料的狀態，一旦IO有資料可以進行讀寫了，程序就來對這樣的IO進行服務。


理解完IO複用後，我們在來看下實現IO複用中的三個API(select、poll和epoll)的區別和聯絡

select，poll，epoll都是IO多路複用的機制，I/O多路複用就是通過一種機制，可以監視多個描述符，一旦某個描述符就緒（
一般是讀就緒或者寫就緒），能夠通知應用程式進行相應的讀寫操作。但select，poll，epoll本質上都是同步I/O，
因為他們都需要在讀寫事件就緒後自己負責進行讀寫，也就是說這個讀寫過程是阻塞的，而非同步I/O則無需自己負責進行讀寫，
非同步I/O的實現會負責把資料從核心拷貝到使用者空間。三者的原型如下所示：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);



 1.select的第一個引數nfds為fdset集合中最大描述符值加1，fdset是一個位數組，其大小限制為__FD_SETSIZE（1024），
 位陣列的每一位代表其對應的描述符是否需要被檢查。第二三四引數表示需要關注讀、寫、錯誤事件的檔案描述符位陣列，
 這些引數既是輸入引數也是輸出引數，可能會被核心修改用於標示哪些描述符上發生了關注的事件，
 所以每次呼叫select前都需要重新初始化fdset。timeout引數為超時時間，該結構會被核心修改，其值為超時剩餘的時間。

 select的呼叫步驟如下：

（1）使用copy_from_user從使用者空間拷貝fdset到核心空間

（2）註冊回撥函式__pollwait

（3）遍歷所有fd，呼叫其對應的poll方法（對於socket，這個poll方法是sock_poll，sock_poll根據情況會呼叫到tcp_poll,udp_poll
或者datagram_poll）

（4）以tcp_poll為例，其核心實現就是__pollwait，也就是上面註冊的回撥函式。

（5）__pollwait的主要工作就是把current（當前程序）掛到裝置的等待佇列中，不同的裝置有不同的等待佇列，對於tcp_poll 來說，
其等待佇列是sk->sk_sleep（注意把程序掛到等待佇列中並不代表程序已經睡眠了）。在裝置收到一條訊息（網路裝置）或填寫完檔案資料
（磁碟裝置）後，會喚醒裝置等待佇列上睡眠的程序，這時current便被喚醒了。

（6）poll方法返回時會返回一個描述讀寫操作是否就緒的mask掩碼，根據這個mask掩碼給fd_set賦值。

（7）如果遍歷完所有的fd，還沒有返回一個可讀寫的mask掩碼，則會呼叫schedule_timeout是呼叫select的程序（也就是 current）
進入睡眠。當裝置驅動發生自身資源可讀寫後，會喚醒其等待佇列上睡眠的程序。如果超過一定的超時時間（schedule_timeout 指定），
還是沒人喚醒，則呼叫select的程序會重新被喚醒獲得CPU，進而重新遍歷fd，判斷有沒有就緒的fd。

（8）把fd_set從核心空間拷貝到使用者空間。

總結下select的幾大缺點：

（1）每次呼叫select，都需要把fd集合從使用者態拷貝到核心態，這個開銷在fd很多時會很大

（2）同時每次呼叫select都需要在核心遍歷傳遞進來的所有fd，這個開銷在fd很多時也很大

（3）select支援的檔案描述符數量太小了，預設是1024



2．  poll與select不同，通過一個pollfd陣列向核心傳遞需要關注的事件，故沒有描述符個數的限制，pollfd中的events欄位和revents分別
用於標示關注的事件和發生的事件，故pollfd陣列只需要被初始化一次。

 poll的實現機制與select類似，其對應核心中的sys_poll，只不過poll向核心傳遞pollfd陣列，然後對pollfd中的每個描述符進行poll，
 相比處理fdset來說，poll效率更高。poll返回後，需要對pollfd中的每個元素檢查其revents值，來得指事件是否發生。



3．直到Linux2.6才出現了由核心直接支援的實現方法，那就是epoll，被公認為Linux2.6下效能最好的多路I/O就緒通知方法。
epoll可以同時支援水平觸發和邊緣觸發（Edge Triggered，只告訴程序哪些檔案描述符剛剛變為就緒狀態，它只說一遍，如果我們沒有采取行動，
那麼它將不會再次告知，這種方式稱為邊緣觸發），理論上邊緣觸發的效能要更高一些，但是程式碼實現相當複雜。
epoll同樣只告知那些就緒的檔案描述符，而且當我們呼叫epoll_wait()獲得就緒檔案描述符時，返回的不是實際的描述符，
而是一個代表就緒描述符數量的值，你只需要去epoll指定的一個數組中依次取得相應數量的檔案描述符即可，這裡也使用了記憶體對映（mmap）技術，
這樣便徹底省掉了這些檔案描述符在系統呼叫時複製的開銷。另一個本質的改進在於epoll採用基於事件的就緒通知方式。在select/poll中，
程序只有在呼叫一定的方法後，核心才對所有監視的檔案描述符進行掃描，而epoll事先通過epoll_ctl()來註冊一個檔案描述符，
一旦基於某個檔案描述符就緒時，核心會採用類似callback的回撥機制，迅速啟用這個檔案描述符，當程序呼叫epoll_wait()時便得到通知。


epoll既然是對select和poll的改進，就應該能避免上述的三個缺點。那epoll都是怎麼解決的呢？在此之前，我們先看一下epoll 和select和
poll的呼叫介面上的不同，select和poll都只提供了一個函式——select或者poll函式。而epoll提供了三個函 數，
epoll_create,epoll_ctl和epoll_wait，epoll_create是建立一個epoll控制代碼；epoll_ctl是注 冊要監聽的事件型別；
epoll_wait則是等待事件的產生。

　　對於第一個缺點，epoll的解決方案在epoll_ctl函式中。每次註冊新的事件到epoll控制代碼中時（在epoll_ctl中指定 EPOLL_CTL_ADD），
會把所有的fd拷貝進核心，而不是在epoll_wait的時候重複拷貝。epoll保證了每個fd在整個過程中只會拷貝 一次。

　　對於第二個缺點，epoll的解決方案不像select或poll一樣每次都把current輪流加入fd對應的裝置等待佇列中，而只在 epoll_ctl時把
current掛一遍（這一遍必不可少）併為每個fd指定一個回撥函式，當裝置就緒，喚醒等待佇列上的等待者時，就會呼叫這個回撥 函式，
而這個回撥函式會把就緒的fd加入一個就緒連結串列）。epoll_wait的工作實際上就是在這個就緒連結串列中檢視有沒有就緒的fd
（利用 schedule_timeout()實現睡一會，判斷一會的效果，和select實現中的第7步是類似的）。

　　對於第三個缺點，epoll沒有這個限制，它所支援的FD上限是最大可以開啟檔案的數目，這個數字一般遠大於2048,舉個例子, 
在1GB記憶體的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統記憶體關係很大。

總結：

（1）select，poll實現需要自己不斷輪詢所有fd集合，直到裝置就緒，期間可能要睡眠和喚醒多次交替。而epoll其實也需要呼叫 epoll_wait
不斷輪詢就緒連結串列，期間也可能多次睡眠和喚醒交替，但是它是裝置就緒時，呼叫回撥函式，把就緒fd放入就緒連結串列中，並喚醒在 epoll_wait中
進入睡眠的程序。雖然都要睡眠和交替，但是select和poll在“醒著”的時候要遍歷整個fd集合，而epoll在“醒著”的 時候只要判斷一下就緒連結串列
是否為空就行了，這節省了大量的CPU時間，這就是回撥機制帶來的效能提升。

（2）select，poll每次呼叫都要把fd集合從使用者態往核心態拷貝一次，並且要把current往裝置等待佇列中掛一次，而epoll只要 一次拷貝，
而且把current往等待佇列上掛也只掛一次（在epoll_wait的開始，注意這裡的等待佇列並不是裝置等待佇列，只是一個epoll內
部定義的等待佇列），這也能節省不少的開銷。

2，selectors模組

這三種 IO多路複用模型在不同的平臺有著不同的支援，而 epoll在windows下就不支援，好在我們有 selectors模組，幫我們預設選擇當前平臺下最合適的。

#服務端
from socket import *
import selectors

sel=selectors.DefaultSelector()
def accept(server_fileobj,mask):
    conn,addr=server_fileobj.accept()
    sel.register(conn,selectors.EVENT_READ,read)

def read(conn,mask):
    try:
        data=conn.recv(1024)
        if not data:
            print('closing',conn)
            sel.unregister(conn)
            conn.close()
            return
        conn.send(data.upper()+b'_SB')
    except Exception:
        print('closing', conn)
        sel.unregister(conn)
        conn.close()



server_fileobj=socket(AF_INET,SOCK_STREAM)
server_fileobj.setsockopt(SOL_SOCKET,SO_REUSEADDR,1)
server_fileobj.bind(('127.0.0.1',8088))
server_fileobj.listen(5)
server_fileobj.setblocking(False) #設定socket的介面為非阻塞
sel.register(server_fileobj,selectors.EVENT_READ,accept) #相當於網select的讀列表裡append了一個檔案控制代碼server_fileobj,並且綁定了一個回撥函式accept

while True:
    events=sel.select() #檢測所有的fileobj，是否有完成wait data的
    for sel_obj,mask in events:
        callback=sel_obj.data #callback=accpet
        callback(sel_obj.fileobj,mask) #accpet(server_fileobj,1)

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

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