框架篇:見識一下linux高效能網路IO+Reactor模型

cscw發表於2020-11-08

前言

網路I/O,可以理解為網路上的資料流。通常我們會基於socket與遠端建立一條TCP或者UDP通道,然後進行讀寫。單個socket時,使用一個執行緒即可高效處理;然而如果是10K個socket連線,或者更多,我們如何做到高效能處理?

  • 基本概念介紹
  • 網路I/O的讀寫過程
  • linux下的五種網路I/O模型
  • 多路複用I/O深入理解一波
  • Reactor模型
  • Proacotr模型

關注公眾號,一起交流 :潛行前行

基本概念介紹

  • 程式(執行緒)切換
    • 所有系統都有排程程式的能力,它可以掛起一個當前正在執行的程式,並恢復之前掛起的程式
  • 程式(執行緒)的阻塞
    • 執行中的程式,有時會等待其他事件的執行完成,比如等待鎖,請求I/O的讀寫;程式在等待過程會被系統自動執行阻塞,此時程式不佔用CPU
  • 檔案描述符
    • 在Linux,檔案描述符是一個用於表述指向檔案引用的抽象化概念,它是一個非負整數。當程式開啟一個現有檔案或者建立一個新檔案時,核心向程式返回一個檔案描述符
  • linux訊號處理
    • Linux程式執行中可以接受來自系統或者程式的訊號值,然後根據訊號值去執行相應捕捉函式;訊號相當於是硬體中斷的軟體模擬

在零拷貝機制篇章已介紹過 使用者空間和核心空間緩衝區,這裡就省略了

網路IO的讀寫過程

  • 當在使用者空間發起對socket套接字的讀操作時,會導致上下文切換,使用者程式阻塞(R1)等待網路資料流到來,從網路卡複製到核心;(R2)然後從核心緩衝區向使用者程式緩衝區複製。此時程式切換恢復,處理拿到的資料
  • 這裡我們給socket讀操作的第一階段起個別名R1,第二階段稱為R2
  • 當在使用者空間發起對socket的send操作時,導致上下文切換,使用者程式阻塞等待(1)資料從使用者程式緩衝區複製到核心緩衝區。資料copy完成,此時程式切換恢復

linux五種網路IO模型

阻塞式I/O (blocking IO)

ssize_t recvfrom(int sockfd,void *buf,size_t len,unsigned int flags, struct sockaddr *from,socket_t *fromlen);

  • 最基礎的I/O模型就是阻塞I/O模型,也是最簡單的模型。所有的操作都是順序執行的
  • 阻塞IO模型中,使用者空間的應用程式執行一個系統呼叫(recvform),會導致應用程式被阻塞,直到核心緩衝區的資料準備好,並且將資料從核心複製到使用者程式。最後程式才被系統喚醒處理資料
  • 在R1、R2連續兩個階段,整個程式都被阻塞

非阻塞式I/O (nonblocking IO)

  • 非阻塞IO也是一種同步IO。它是基於輪詢(polling)機制實現,在這種模型中,套接字是以非阻塞的形式開啟的。就是說I/O操作不會立即完成,但是I/O操作會返回一個錯誤程式碼(EWOULDBLOCK),提示操作未完成
  • 輪詢檢查核心資料,如果資料未準備好,則返回EWOULDBLOCK。程式再繼續發起recvfrom呼叫,當然你可以暫停去做其他事
  • 直到核心資料準備好,再拷貝資料到使用者空間,然後程式拿到非錯誤碼資料,接著進行資料處理。需要注意,拷貝資料整個過程,程式仍然是屬於阻塞的狀態
  • 程式在R2階段阻塞,雖然在R1階段沒有被阻塞,但是需要不斷輪詢

多路複用I/O (IO multiplexing)

  • 一般後端服務都會存在大量的socket連線,如果一次能查詢多個套接字的讀寫狀態,若有任意一個準備好,那就去處理它,效率會高很多。這就是“I/O多路複用”,多路是指多個socket套接字,複用是指複用同一個程式
  • linux提供了select、poll、epoll等多路複用I/O的實現方式
  • select或poll、epoll是阻塞呼叫
  • 與阻塞IO不同,select不會等到socket資料全部到達再處理,而是有了一部分socket資料準備好就會恢復使用者程式來處理。怎麼知道有一部分資料在核心準備好了呢?答案:交給了系統系統處理吧
  • 程式在R1、R2階段也是阻塞;不過在R1階段有個技巧,在多程式、多執行緒程式設計的環境下,我們可以只分配一個程式(執行緒)去阻塞呼叫select,其他執行緒不就可以解放了嗎

訊號驅動式I/O (SIGIO)

  • 需要提供一個訊號捕捉函式,並和socket套接字關聯;發起sigaction呼叫之後程式就能解放去處理其他事
  • 當資料在核心準備好後,程式會收到一個SIGIO訊號,繼而中斷去執行訊號捕捉函式,呼叫recvfrom把資料從核心讀取到使用者空間,再處理資料
  • 可以看出使用者程式是不會阻塞在R1階段,但R2還是會阻塞等待

非同步IO (POSIX的aio_系列函式)

  • 相對同步IO,非同步IO在使用者程式發起非同步讀(aio_read)系統呼叫之後,無論核心緩衝區資料是否準備好,都不會阻塞當前程式;在aio_read系統呼叫返回後程式就可以處理其他邏輯
  • socket資料在核心就緒時,系統直接把資料從核心複製到使用者空間,然後再使用訊號通知使用者程式
  • R1、R2兩階段時程式都是非阻塞的

多路複用IO深入理解一波

select

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
  • 1)使用copy_from_user從使用者空間拷貝fd_set到核心空間
  • 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)進入睡眠
  • 8) 當裝置驅動發生自身資源可讀寫後,會喚醒其等待佇列上睡眠的程式。如果超過一定的超時時間(timeout指定),還是沒人喚醒,則呼叫select的程式會重新被喚醒獲得CPU,進而重新遍歷fd,判斷有沒有就緒的fd
  • 9)把fd_set從核心空間拷貝到使用者空間

select的缺點

  • 每次呼叫select,都需要把fd集合從使用者態拷貝到核心態,這個開銷在fd很多時會很大
  • 同時每次呼叫select都需要在核心遍歷傳遞進來的所有fd,這個開銷在fd很多時也很大
  • select支援的檔案描述符數量太小了,預設是1024

epoll

int epoll_create(int size);  
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);  
int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout); 
  • 呼叫epoll_create,會在核心cache裡建個紅黑樹用於儲存以後epoll_ctl傳來的socket,同時也會再建立一個rdllist雙向連結串列用於儲存準備就緒的事件。當epoll_wait呼叫時,僅檢視這個rdllist雙向連結串列資料即可
  • epoll_ctl在向epoll物件中新增、修改、刪除事件時,是在rbr紅黑樹中操作的,非常快
  • 新增到epoll中的事件會與裝置(如網路卡)建立回撥關係,裝置上相應事件的發生時會呼叫回撥方法,把事件加進rdllist雙向連結串列中;這個回撥方法在核心中叫做ep_poll_callback

epoll的兩種觸發模式

  • epoll有EPOLLLT和EPOLLET兩種觸發模式,LT是預設的模式,ET是“高速”模式(只支援no-block socket)
    • LT(水平觸發)模式下,只要這個檔案描述符還有資料可讀,每次epoll_wait都會觸發它的讀事件
    • ET(邊緣觸發)模式下,檢測到有I/O事件時,通過 epoll_wait 呼叫會得到有事件通知的檔案描述符,對於檔案描述符,如可讀,則必須將該檔案描述符一直讀到空(或者返回EWOULDBLOCK),否則下次的epoll_wait不會觸發該事件

epoll相比select的優點

  • 解決select三個缺點
    • 對於第一個缺點:epoll的解決方案在epoll_ctl函式中。每次註冊新的事件到epoll控制程式碼中時(在epoll_ctl中指定EPOLL_CTL_ADD),會把所有的fd拷貝進核心,而不是在epoll_wait的時候重複拷貝。epoll保證了每個fd在整個過程中只會拷貝一次(epoll_wait不需要複製)
    • 對於第二個缺點:epoll為每個fd指定一個回撥函式,當裝置就緒,喚醒等待佇列上的等待者時,就會呼叫這個回撥函式,而這個回撥函式會把就緒的fd加入一個就緒連結串列。epoll_wait的工作實際上就是在這個就緒連結串列中檢視有沒有就緒的fd(不需要遍歷)
    • 對於第三個缺點:epoll沒有這個限制,它所支援的FD上限是最大可以開啟檔案的數目,這個數字一般遠大於2048,舉個例子,在1GB記憶體的機器上大約是10萬左右,一般來說這個數目和系統記憶體關係很大
  • epoll的高效能
    • epoll使用了紅黑樹來儲存需要監聽的檔案描述符事件,epoll_ctl增刪改操作快速
    • epoll不需要遍歷就能獲取就緒fd,直接返回就緒連結串列即可
    • linux2.6 之後使用了mmap技術,資料不在需要從核心複製到使用者空間,零拷貝

關於epoll的IO模型是同步非同步的疑問

  • 概念定義
    • 同步I/O操作:導致請求程式阻塞,直到I/O操作完成
    • 非同步I/O操作:不導致請求程式阻塞,非同步只用處理I/O操作完成後的通知,並不主動讀寫資料,由系統核心完成資料的讀寫
    • 阻塞,非阻塞:程式/執行緒要訪問的資料是否就緒,程式/執行緒是否需要等待
  • 非同步IO的概念是要求無阻塞I/O呼叫。前面有介紹到I/O操作分兩階段:R1等待資料準備好。R2從核心到程式拷貝資料。雖然epoll在2.6核心之後採用mmap機制,使得其在R2階段不需要複製,但是它在R1還是阻塞的。因此歸類到同步IO

Reactor模型

Reactor的中心思想是將所有要處理的I/O事件註冊到一箇中心I/O多路複用器上,同時主執行緒/程式阻塞在多路複用器上;一旦有I/O事件到來或是準備就緒,多路複用器返回,並將事先註冊的相應I/O事件分發到對應的處理器中

相關概念介紹:

  • 事件:就是狀態;比如:讀就緒事件指的是我們可以從核心讀取資料的狀態
  • 事件分離器:一般會把事件的等待發生交給epoll、select;而事件的到來是隨機,非同步的,所以需要迴圈呼叫epoll,在框架裡對應封裝起來的模組就是事件分離器(簡單理解為對epoll封裝)
  • 事件處理器:事件發生後需要程式或執行緒去處理,這個處理者就是事件處理器,一般和事件分離器是不同的執行緒

Reactor的一般流程

  • 1)應用程式在事件分離器註冊讀寫就緒事件讀寫就緒事件處理器
  • 2)事件分離器等待讀寫就緒事件發生
  • 3)讀寫就緒事件發生,啟用事件分離器,分離器呼叫讀寫就緒事件處理器
  • 4)事件處理器先從核心把資料讀取到使用者空間,然後再處理資料

單執行緒 + Reactor

多執行緒 + Reactor

多執行緒 + 多個Reactor

Proactor模型的一般流程

  • 1)應用程式在事件分離器註冊讀完成事件讀完成事件處理器,並向系統發出非同步讀請求
  • 2)事件分離器等待讀事件的完成
  • 3)在分離器等待過程中,系統利用並行的核心執行緒執行實際的讀操作,並將資料複製程式緩衝區,最後通知事件分離器讀完成到來
  • 4)事件分離器監聽到讀完成事件,啟用讀完成事件的處理器
  • 5)讀完成事件處理器直接處理使用者程式緩衝區中的資料

Proactor和Reactor的區別

  • Proactor是基於非同步I/O的概念,而Reactor一般則是基於多路複用I/O的概念
  • Proactor不需要把資料從核心複製到使用者空間,這步由系統完成

歡迎指正文中錯誤

參考文章

相關文章