目錄
- 一、基本概念介紹
- 二、網(wǎng)絡(luò)IO的讀寫過程
- 三、Linux五種網(wǎng)絡(luò)IO模型
- 3.1、阻塞式I/O (blocking IO)
- 3.2、非阻塞式I/O (nonblocking IO)
- 3.3、多路復(fù)用I/O (IO multiplexing)
- 3.4、信號驅(qū)動式I/O (SIGIO)
- 3.5、異步IO (POSIX的aio_系列函數(shù))
- 四、多路復(fù)用IO深入理解一波
- 4.1、select
- 4.2、epoll
- 4.3、epoll相比select的優(yōu)點
- 4.4、關(guān)于epoll的IO模型是同步異步的疑問
- 五、Reactor模型
- 5.1、相關(guān)概念介紹
- 5.2、Reactor的一般流程
- 5.3、單線程 + Reactor
- 5.4、多線程 + Reactor
- 5.5、多線程 + 多個Reactor
- 六、Proactor模型的一般流程
- 6.1、Proactor和Reactor的區(qū)別
一、基本概念介紹
- 進程(線程)切換:所有系統(tǒng)都有調(diào)度進程的能力,它可以掛起一個當前正在運行的進程,并恢復(fù)之前掛起的進程
- 進程(線程)的阻塞:運行中的進程,有時會等待其他事件的執(zhí)行完成,比如等待鎖,請求I/O的讀寫;進程在等待過程會被系統(tǒng)自動執(zhí)行阻塞,此時進程不占用CPU
- 文件描述符:在Linux,文件描述符是一個用于表述指向文件引用的抽象化概念,它是一個非負整數(shù)。當程序打開一個現(xiàn)有文件或者創(chuàng)建一個新文件時,內(nèi)核向進程返回一個文件描述符
- linux信號處理:Linux進程運行中可以接受來自系統(tǒng)或者進程的信號值,然后根據(jù)信號值去運行相應(yīng)捕捉函數(shù);信號相當于是硬件中斷的軟件模擬
在零拷貝機制篇章已介紹過 用戶空間和內(nèi)核空間和緩沖區(qū),這里就省略了
二、網(wǎng)絡(luò)IO的讀寫過程
- 當在用戶空間發(fā)起對socket套接字的讀操作時,會導(dǎo)致上下文切換,用戶進程阻塞(R1)等待網(wǎng)絡(luò)數(shù)據(jù)流到來,從網(wǎng)卡復(fù)制到內(nèi)核;(R2)然后從內(nèi)核緩沖區(qū)向用戶進程緩沖區(qū)復(fù)制。此時進程切換恢復(fù),處理拿到的數(shù)據(jù)
- 這里我們給socket讀操作的第一階段起個別名R1,第二階段稱為R2
- 當在用戶空間發(fā)起對socket的send操作時,導(dǎo)致上下文切換,用戶進程阻塞等待(1)數(shù)據(jù)從用戶進程緩沖區(qū)復(fù)制到內(nèi)核緩沖區(qū)。數(shù)據(jù)copy完成,此時進程切換恢復(fù)
三、Linux五種網(wǎng)絡(luò)IO模型
3.1、阻塞式I/O (blocking IO)
ssize_t recvfrom(int sockfd,void *buf,size_t len,unsigned int flags, struct sockaddr *from,socket_t *fromlen);
- 最基礎(chǔ)的I/O模型就是阻塞I/O模型,也是最簡單的模型。所有的操作都是順序執(zhí)行的
- 阻塞IO模型中,用戶空間的應(yīng)用程序執(zhí)行一個系統(tǒng)調(diào)用(recvform),會導(dǎo)致應(yīng)用程序被阻塞,直到內(nèi)核緩沖區(qū)的數(shù)據(jù)準備好,并且將數(shù)據(jù)從內(nèi)核復(fù)制到用戶進程。最后進程才被系統(tǒng)喚醒處理數(shù)據(jù)
- 在R1、R2連續(xù)兩個階段,整個進程都被阻塞
3.2、非阻塞式I/O (nonblocking IO)
- 非阻塞IO也是一種同步IO。它是基于輪詢(polling)機制實現(xiàn),在這種模型中,套接字是以非阻塞的形式打開的。就是說I/O操作不會立即完成,但是I/O操作會返回一個錯誤代碼(EWOULDBLOCK),提示操作未完成
- 輪詢檢查內(nèi)核數(shù)據(jù),如果數(shù)據(jù)未準備好,則返回EWOULDBLOCK。進程再繼續(xù)發(fā)起recvfrom調(diào)用,當然你可以暫停去做其他事
- 直到內(nèi)核數(shù)據(jù)準備好,再拷貝數(shù)據(jù)到用戶空間,然后進程拿到非錯誤碼數(shù)據(jù),接著進行數(shù)據(jù)處理。需要注意,拷貝數(shù)據(jù)整個過程,進程仍然是屬于阻塞的狀態(tài)
- 進程在R2階段阻塞,雖然在R1階段沒有被阻塞,但是需要不斷輪詢
3.3、多路復(fù)用I/O (IO multiplexing)
- 一般后端服務(wù)都會存在大量的socket連接,如果一次能查詢多個套接字的讀寫狀態(tài),若有任意一個準備好,那就去處理它,效率會高很多。這就是“I/O多路復(fù)用”,多路是指多個socket套接字,復(fù)用是指復(fù)用同一個進程
- linux提供了select、poll、epoll等多路復(fù)用I/O的實現(xiàn)方式
- select或poll、epoll是阻塞調(diào)用
- 與阻塞IO不同,select不會等到socket數(shù)據(jù)全部到達再處理,而是有了一部分socket數(shù)據(jù)準備好就會恢復(fù)用戶進程來處理。怎么知道有一部分數(shù)據(jù)在內(nèi)核準備好了呢?答案:交給了系統(tǒng)系統(tǒng)處理吧
- 進程在R1、R2階段也是阻塞;不過在R1階段有個技巧,在多進程、多線程編程的環(huán)境下,我們可以只分配一個進程(線程)去阻塞調(diào)用select,其他線程不就可以解放了嗎
3.4、信號驅(qū)動式I/O (SIGIO)
- 需要提供一個信號捕捉函數(shù),并和socket套接字關(guān)聯(lián);發(fā)起sigaction調(diào)用之后進程就能解放去處理其他事
- 當數(shù)據(jù)在內(nèi)核準備好后,進程會收到一個SIGIO信號,繼而中斷去運行信號捕捉函數(shù),調(diào)用recvfrom把數(shù)據(jù)從內(nèi)核讀取到用戶空間,再處理數(shù)據(jù)
- 可以看出用戶進程是不會阻塞在R1階段,但R2還是會阻塞等待
3.5、異步IO (POSIX的aio_系列函數(shù))
- 相對同步IO,異步IO在用戶進程發(fā)起異步讀(aio_read)系統(tǒng)調(diào)用之后,無論內(nèi)核緩沖區(qū)數(shù)據(jù)是否準備好,都不會阻塞當前進程;在aio_read系統(tǒng)調(diào)用返回后進程就可以處理其他邏輯
- socket數(shù)據(jù)在內(nèi)核就緒時,系統(tǒng)直接把數(shù)據(jù)從內(nèi)核復(fù)制到用戶空間,然后再使用信號通知用戶進程
- R1、R2兩階段時進程都是非阻塞的
四、多路復(fù)用IO深入理解一波
4.1、select
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
1)使用copy_from_user從用戶空間拷貝fd_set到內(nèi)核空間
2)注冊回調(diào)函數(shù)__pollwait
3)遍歷所有fd,調(diào)用其對應(yīng)的poll方法(對于socket,這個poll方法是sock_poll,sock_poll根據(jù)情況會調(diào)用到tcp_poll,udp_poll或者datagram_poll)
4)以tcp_poll為例,其核心實現(xiàn)就是__pollwait,也就是上面注冊的回調(diào)函數(shù)
5)__pollwait的主要工作就是把current(當前進程)掛到設(shè)備的等待隊列中,不同的設(shè)備有不同的等待隊列,對于tcp_poll來說,其等待隊列是sk->sk_sleep(注意把進程掛到等待隊列中并不代表進程已經(jīng)睡眠了)。在設(shè)備收到一條消息(網(wǎng)絡(luò)設(shè)備)或填寫完文件數(shù)據(jù)(磁盤設(shè)備)后,會喚醒設(shè)備等待隊列上睡眠的進程,這時current便被喚醒了
6)poll方法返回時會返回一個描述讀寫操作是否就緒的mask掩碼,根據(jù)這個mask掩碼給fd_set賦值
7)如果遍歷完所有的fd,還沒有返回一個可讀寫的mask掩碼,則會調(diào)用schedule_timeout是調(diào)用select的進程(也就是current)進入睡眠
8) 當設(shè)備驅(qū)動發(fā)生自身資源可讀寫后,會喚醒其等待隊列上睡眠的進程。如果超過一定的超時時間(timeout指定),還是沒人喚醒,則調(diào)用select的進程會重新被喚醒獲得CPU,進而重新遍歷fd,判斷有沒有就緒的fd
9)把fd_set從內(nèi)核空間拷貝到用戶空間
select的缺點:
- 每次調(diào)用select,都需要把fd集合從用戶態(tài)拷貝到內(nèi)核態(tài),這個開銷在fd很多時會很大
- 同時每次調(diào)用select都需要在內(nèi)核遍歷傳遞進來的所有fd,這個開銷在fd很多時也很大
- select支持的文件描述符數(shù)量太小了,默認是1024
4.2、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);
- 調(diào)用epoll_create,會在內(nèi)核cache里建個紅黑樹用于存儲以后epoll_ctl傳來的socket,同時也會再建立一個rdllist雙向鏈表用于存儲準備就緒的事件。當epoll_wait調(diào)用時,僅查看這個rdllist雙向鏈表數(shù)據(jù)即可
- epoll_ctl在向epoll對象中添加、修改、刪除事件時,是在rbr紅黑樹中操作的,非???/li>
- 添加到epoll中的事件會與設(shè)備(如網(wǎng)卡)建立回調(diào)關(guān)系,設(shè)備上相應(yīng)事件的發(fā)生時會調(diào)用回調(diào)方法,把事件加進rdllist雙向鏈表中;這個回調(diào)方法在內(nèi)核中叫做ep_poll_callback
epoll的兩種觸發(fā)模式:
epoll有EPOLLLT和EPOLLET兩種觸發(fā)模式,LT是默認的模式,ET是“高速”模式(只支持no-block socket)
- LT(水平觸發(fā))模式下,只要這個文件描述符還有數(shù)據(jù)可讀,每次epoll_wait都會觸發(fā)它的讀事件
- ET(邊緣觸發(fā))模式下,檢測到有I/O事件時,通過 epoll_wait 調(diào)用會得到有事件通知的文件描述符,對于文件描述符,如可讀,則必須將該文件描述符一直讀到空(或者返回EWOULDBLOCK),否則下次的epoll_wait不會觸發(fā)該事件
4.3、epoll相比select的優(yōu)點
解決select三個缺點:
- 對于第一個缺點:epoll的解決方案在epoll_ctl函數(shù)中。每次注冊新的事件到epoll句柄中時(在epoll_ctl中指定EPOLL_CTL_ADD),會把所有的fd拷貝進內(nèi)核,而不是在epoll_wait的時候重復(fù)拷貝。epoll保證了每個fd在整個過程中只會拷貝一次(epoll_wait不需要復(fù)制)
- 對于第二個缺點:epoll為每個fd指定一個回調(diào)函數(shù),當設(shè)備就緒,喚醒等待隊列上的等待者時,就會調(diào)用這個回調(diào)函數(shù),而這個回調(diào)函數(shù)會把就緒的fd加入一個就緒鏈表。epoll_wait的工作實際上就是在這個就緒鏈表中查看有沒有就緒的fd(不需要遍歷)
- 對于第三個缺點:epoll沒有這個限制,它所支持的FD上限是最大可以打開文件的數(shù)目,這個數(shù)字一般遠大于2048,舉個例子,在1GB內(nèi)存的機器上大約是10萬左右,一般來說這個數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大
epoll的高性能:
- epoll使用了紅黑樹來保存需要監(jiān)聽的文件描述符事件,epoll_ctl增刪改操作快速
- epoll不需要遍歷就能獲取就緒fd,直接返回就緒鏈表即可
- linux2.6 之后使用了mmap技術(shù),數(shù)據(jù)不在需要從內(nèi)核復(fù)制到用戶空間,零拷貝
4.4、關(guān)于epoll的IO模型是同步異步的疑問
概念定義:
- 同步I/O操作:導(dǎo)致請求進程阻塞,直到I/O操作完成
- 異步I/O操作:不導(dǎo)致請求進程阻塞,異步只用處理I/O操作完成后的通知,并不主動讀寫數(shù)據(jù),由系統(tǒng)內(nèi)核完成數(shù)據(jù)的讀寫
- 阻塞,非阻塞:進程/線程要訪問的數(shù)據(jù)是否就緒,進程/線程是否需要等待
異步IO的概念是要求無阻塞I/O調(diào)用。前面有介紹到I/O操作分兩階段:R1等待數(shù)據(jù)準備好。R2從內(nèi)核到進程拷貝數(shù)據(jù)。雖然epoll在2.6內(nèi)核之后采用mmap機制,使得其在R2階段不需要復(fù)制,但是它在R1還是阻塞的。因此歸類到同步IO
五、Reactor模型
Reactor的中心思想是將所有要處理的I/O事件注冊到一個中心I/O多路復(fù)用器上,同時主線程/進程阻塞在多路復(fù)用器上;一旦有I/O事件到來或是準備就緒,多路復(fù)用器返回,并將事先注冊的相應(yīng)I/O事件分發(fā)到對應(yīng)的處理器中
5.1、相關(guān)概念介紹
- 事件:就是狀態(tài);比如:讀就緒事件指的是我們可以從內(nèi)核讀取數(shù)據(jù)的狀態(tài)
- 事件分離器:一般會把事件的等待發(fā)生交給epoll、select;而事件的到來是隨機,異步的,所以需要循環(huán)調(diào)用epoll,在框架里對應(yīng)封裝起來的模塊就是事件分離器(簡單理解為對epoll封裝)
- 事件處理器:事件發(fā)生后需要進程或線程去處理,這個處理者就是事件處理器,一般和事件分離器是不同的線程
5.2、Reactor的一般流程
1)應(yīng)用程序在事件分離器注冊讀寫就緒事件和讀寫就緒事件處理器
2)事件分離器等待讀寫就緒事件發(fā)生
3)讀寫就緒事件發(fā)生,激活事件分離器,分離器調(diào)用讀寫就緒事件處理器
4)事件處理器先從內(nèi)核把數(shù)據(jù)讀取到用戶空間,然后再處理數(shù)據(jù)
5.3、單線程 + Reactor
5.4、多線程 + Reactor
5.5、多線程 + 多個Reactor
六、Proactor模型的一般流程
1)應(yīng)用程序在事件分離器注冊讀完成事件和讀完成事件處理器,并向系統(tǒng)發(fā)出異步讀請求
2)事件分離器等待讀事件的完成
3)在分離器等待過程中,系統(tǒng)利用并行的內(nèi)核線程執(zhí)行實際的讀操作,并將數(shù)據(jù)復(fù)制進程緩沖區(qū),最后通知事件分離器讀完成到來
4)事件分離器監(jiān)聽到讀完成事件,激活讀完成事件的處理器
5)讀完成事件處理器直接處理用戶進程緩沖區(qū)中的數(shù)據(jù)
6.1、Proactor和Reactor的區(qū)別
- Proactor是基于異步I/O的概念,而Reactor一般則是基于多路復(fù)用I/O的概念
- Proactor不需要把數(shù)據(jù)從內(nèi)核復(fù)制到用戶空間,這步由系統(tǒng)完成
以上就是解析Linux高性能網(wǎng)絡(luò)IO和Reactor模型的詳細內(nèi)容,更多關(guān)于Linux高性能網(wǎng)絡(luò)IO和Reactor模型的資料請關(guān)注腳本之家其它相關(guān)文章!