python併發之IO模型（二）

blocking IO （阻塞IO）

在linux中，默認狀況下全部的socket都是blocking，一個典型的讀操做流程大概是這樣：

當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來講，不少時候數據在一開始尚未到達（好比，尚未收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，而後kernel返回結果，用戶進程才解除block的狀態，從新運行起來。

因此，blocking IO的特色就是在IO執行的兩個階段都被block了。

 

non-blocking IO（非阻塞IO）

linux下，能夠經過設置socket使其變爲non-blocking。當對一個non-blocking socket執行讀操做時，流程是這個樣子：

從圖中能夠看出，當用戶進程發出read操做時，若是kernel中的數據尚未準備好，那麼它並不會block用戶進程，而是馬上返回一個error。從用戶進程角度講 ，它發起一個read操做後，並不須要等待，而是立刻就獲得了一個結果。用戶進程判斷結果是一個error時，它就知道數據尚未準備好，因而它能夠再次發送read操做。一旦kernel中的數據準備好了，而且又再次收到了用戶進程的system call，那麼它立刻就將數據拷貝到了用戶內存，而後返回。

因此，用戶進程實際上是須要不斷的主動詢問kernel數據好了沒有。

 

注意：

在網絡IO時候，非阻塞IO也會進行recvform系統調用，檢查數據是否準備好，與阻塞IO不同，」非阻塞將大的整片時間的阻塞分紅N多的小的阻塞, 因此進程不斷地有機會 ‘被’ CPU光顧」。即每次recvform系統調用之間，cpu的權限還在進程手中，這段時間是能夠作其餘事情的，

      也就是說非阻塞的recvform系統調用調用以後，進程並無被阻塞，內核立刻返回給進程，若是數據還沒準備好，此時會返回一個error。進程在返回以後，能夠乾點別的事情，而後再發起recvform系統調用。重複上面的過程，循環往復的進行recvform系統調用。這個過程一般被稱之爲輪詢。輪詢檢查內核數據，直到數據準備好，再拷貝數據到進程，進行數據處理。須要注意，拷貝數據整個過程，進程仍然是屬於阻塞的狀態。

 

IO multiplexing（IO多路複用）

 IO multiplexing這個詞可能有點陌生，可是若是我說select，epoll，大概就都能明白了。有些地方也稱這種IO方式爲event driven IO。咱們都知道，select/epoll的好處就在於單個process就能夠同時處理多個網絡鏈接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的全部socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖：

當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會「監視」全部select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操做，將數據從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實並無太大的不一樣，事實上，還更差一些。由於這裏須要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。可是，用select的優點在於它能夠同時處理多個connection。（多說一句。因此，若是處理的鏈接數不是很高的話，使用select/epoll的web server不必定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優點並非對於單個鏈接能處理得更快，而是在於能處理更多的鏈接。）
在IO multiplexing Model中，實際中，對於每個socket，通常都設置成爲non-blocking，可是，如上圖所示，整個用戶的process實際上是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。

 

注意1：select函數返回結果中若是有文件可讀了，那麼進程就能夠經過調用accept()或recv()來讓kernel將位於內核中準備到的數據copy到用戶區。

注意2: select的優點在於能夠處理多個鏈接，不適用於單個鏈接

 

Asynchronous I/O（異步IO）

linux下的asynchronous IO其實用得不多。先看一下它的流程：

用戶進程發起read操做以後，馬上就能夠開始去作其它的事。而另外一方面，從kernel的角度，當它受到一個asynchronous read以後，首先它會馬上返回，因此不會對用戶進程產生任何block。而後，kernel會等待數據準備完成，而後將數據拷貝到用戶內存，當這一切都完成以後，kernel會給用戶進程發送一個signal，告訴它read操做完成了。

      到目前爲止，已經將四個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 that I/O operationcompletes;
    An asynchronous I/O operation does not cause the requesting process to be blocked; 
      二者的區別就在於synchronous IO作」IO operation」的時候會將process阻塞。按照這個定義，以前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO。有人可能會說，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。

       注意：因爲我們接下來要講的select，poll，epoll都屬於IO多路複用，而IO多路複用又屬於同步的範疇，故，epoll只是一個僞異步而已。

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

通過上面的介紹，會發現non-blocking IO和asynchronous IO的區別仍是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，可是它仍然要求進程去主動的check，而且當數據準備完成之後，也須要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則徹底不一樣。它就像是用戶進程將整個IO操做交給了他人（kernel）完成，而後他人作完後發信號通知。在此期間，用戶進程不須要去檢查IO操做的狀態，也不須要主動的去拷貝數據。

五種IO模型比較：

select poll epoll IO多路複用介紹

首先列一下，sellect、poll、epoll三者的區別

select 
select最先於1983年出如今4.2BSD中，它經過一個select()系統調用來監視多個文件描述符的數組，當select()返回後，該數組中就緒的文件描述符便會被內核修改標誌位，使得進程能夠得到這些文件描述符從而進行後續的讀寫操做。 
select目前幾乎在全部的平臺上支持 　 
select的一個缺點在於單個進程可以監視的文件描述符的數量存在最大限制，在Linux上通常爲1024，不過能夠經過修改宏定義甚至從新編譯內核的方式提高這一限制。 　 
另外，select()所維護的存儲大量文件描述符的數據結構，隨着文件描述符數量的增大，其複製的開銷也線性增加。同時，因爲網絡響應時間的延遲使得大量TCP鏈接處於非活躍狀態，但調用select()會對全部socket進行一次線性掃描，因此這也浪費了必定的開銷。

poll 
它和select在本質上沒有多大差異，可是poll沒有最大文件描述符數量的限制。 
通常也不用它，至關於過渡階段

epoll 
直到Linux2.6纔出現了由內核直接支持的實現方法，那就是epoll。被公認爲Linux2.6下性能最好的多路I/O就緒通知方法。windows不支持 
沒有最大文件描述符數量的限制。 
好比100個鏈接，有兩個活躍了，epoll會告訴用戶這兩個兩個活躍了，直接取就ok了，而select是循環一遍。 
（瞭解）epoll能夠同時支持水平觸發和邊緣觸發（Edge Triggered，只告訴進程哪些文件描述符剛剛變爲就緒狀態，它只說一遍，若是咱們沒有采起行動，那麼它將不會再次告知，這種方式稱爲邊緣觸發），理論上邊緣觸發的性能要更高一些，可是代碼實現至關複雜。 
另外一個本質的改進在於epoll採用基於事件的就緒通知方式。在select/poll中，進程只有在調用必定的方法後，內核纔對全部監視的文件描述符進行掃描，而epoll事先經過epoll_ctl()來註冊一個文件描述符，一旦基於某個文件描述符就緒時，內核會採用相似callback的回調機制，迅速激活這個文件描述符，當進程調用epoll_wait()時便獲得通知。 
因此市面上上見到的所謂的異步IO，好比nginx、Tornado、等，咱們叫它異步IO，其實是IO多路複用。

 

IO多路複用的觸發方式

水平觸發和邊緣觸發

在linux的IO多路複用中有水平觸發,邊緣觸發兩種模式,這兩種模式的區別以下:

水平觸發:若是文件描述符已經就緒能夠非阻塞的執行IO操做了,此時會觸發通知.容許在任意時刻重複檢測IO的狀態,

沒有必要每次描述符就緒後儘量多的執行IO.select,poll就屬於水平觸發.

 

邊緣觸發:若是文件描述符自上次狀態改變後有新的IO活動到來,此時會觸發通知.在收到一個IO事件通知後要儘量多的執行IO操做,由於若是在一次通知中沒有執行完IO那麼就須要等到下一次新的IO活動到來才能獲取到就緒的描述符.信號驅動式IO就屬於邊緣觸發.

epoll既能夠採用水平觸發,也能夠採用邊緣觸發.

你們可能還不能徹底瞭解這兩種模式的區別,咱們能夠舉例說明:一個管道收到了1kb的數據,epoll會當即返回,此時讀了512字節數據,而後再次調用epoll.這時若是是水平觸發的,epoll會當即返回,由於有數據準備好了.若是是邊緣觸發的不會當即返回,由於此時雖然有數據可讀可是已經觸發了一次通知,在此次通知到如今尚未新的數據到來,直到有新的數據到來epoll纔會返回,此時老的數據和新的數據均可以讀取到(固然是須要此次你儘量的多讀取).

 

下面咱們還從電子的角度來解釋一下:

水平觸發:也就是隻有高電平(1)或低電平(0)時才觸發通知,只要在這兩種狀態就能獲得通知.上面提到的只要有數據可讀(描述符就緒)那麼水平觸發的epoll就當即返回.

邊緣觸發:只有電平發生變化(高電平到低電平,或者低電平到高電平)的時候才觸發通知.上面提到即便有數據可讀,可是沒有新的IO活動到來,epoll也不會當即返回.

 

簡單實例(IO multiplexing):

在非阻塞實例中，輪詢的主語是進程，而「後臺」 可能有多個任務在同時進行，人們就想到了循環查詢多個任務的完成狀態，只要有任何一個任務完成，就去處理它。不過，這個監聽的重任經過調用select等函數交給了內核去作。IO多路複用有兩個特別的系統調用select、poll、epoll函數。select調用是內核級別的，select輪詢相對非阻塞的輪詢的區別在於—前者能夠等待多個socket，能實現同時對多個IO端口進行監聽，當其中任何一個socket的數據準好了，就能返回進行可讀，而後進程再進行recvfrom系統調用，將數據由內核拷貝到用戶進程，固然這個過程是阻塞的。

import socket
import select
sk=socket.socket()
sk.bind(("127.0.0.1",9904))
sk.listen(5)

while True:
   r,w,e=select.select([sk,],[],[],5)
   for i in r:
       # conn,add=i.accept()
       #print(conn)
       print("hello")
   print('>>>>>>')
   
#*************************client.py
import socket
sk=socket.socket()
sk.connect(("127.0.0.1",9904))
while 1:
   inp=input(">>").strip()
   sk.send(inp.encode("utf8"))
   data=sk.recv(1024)
   print(data.decode("utf8"))

 

爲何不調用accept，會反覆print？

select屬於水平觸發

server端併發聊天

#***********************server.py
import socket
import select
sk=socket.socket()
sk.bind(("127.0.0.1",8801))
sk.listen(5)
inputs=[sk,]
while True:
   r,w,e=select.select(inputs,[],[],5)
   print(len(r))
   for obj in r:
       if obj==sk:
           conn,add=obj.accept()
           print(conn)
           inputs.append(conn)
       else:
           data_byte=obj.recv(1024)
           print(str(data_byte,'utf8'))
           inp=input('回答%s號客戶>>>'%inputs.index(obj))
           obj.sendall(bytes(inp,'utf8'))

   print('>>',r)
#***********************client.py
import socket
sk=socket.socket()
sk.connect(('127.0.0.1',8801))

while True:
   inp=input(">>>>")
   sk.sendall(bytes(inp,"utf8"))
   data=sk.recv(1024)
   print(str(data,'utf8'))

 

---

 

掃描圖中二維碼,領取python全套視頻資料