網(wǎng)絡(luò)編程 socket阻塞與非阻塞,同步與異步永品、I/O模型

本文根據(jù)眾多互聯(lián)網(wǎng)博客內(nèi)容整理后形成做鹰,引用內(nèi)容的版權(quán)歸原始作者所有,僅限于學習研究使用鼎姐,不得用于任何商業(yè)用途钾麸。

概念理解
在進行網(wǎng)絡(luò)編程時,我們常常見到同步(Sync)/異步(Async)炕桨,阻塞(Block)/非阻塞(Unblock)四種調(diào)用方式:

同步/異步主要針對C端:

同步
所謂同步饭尝,就是在c端發(fā)出一個功能調(diào)用時,在沒有得到結(jié)果之前献宫,該調(diào)用就不返回钥平。也就是必須一件一件事做,等前一件做完了才能做下一件事。

例如普通B/S模式(同步):提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能干任何事

異步
異步的概念和同步相對姊途。當c端一個異步過程調(diào)用發(fā)出后涉瘾,調(diào)用者不能立刻得到結(jié)果。實際處理這個調(diào)用的部件在完成后捷兰,通過狀態(tài)立叛、通知和回調(diào)來通知調(diào)用者。

例如 ajax請求(異步): 請求通過事件觸發(fā)->服務器處理(這是瀏覽器仍然可以作其他事情)->處理完畢

阻塞/非阻塞主要針對S端:
阻塞
阻塞調(diào)用是指調(diào)用結(jié)果返回之前贡茅,當前線程會被掛起(線程進入非可執(zhí)行狀態(tài)秘蛇,在這個狀態(tài)下,cpu不會給線程分配時間片友扰,即線程暫停運行)彤叉。函數(shù)只有在得到結(jié)果之后才會返回。

有人也許會把阻塞調(diào)用和同步調(diào)用等同起來村怪,實際上他是不同的。對于同步調(diào)用來說浮庐,很多時候當前線程還是激活的甚负,只是從邏輯上當前函數(shù)沒有返回而已柬焕。 例如,我們在socket中調(diào)用recv函數(shù)梭域,如果緩沖區(qū)中沒有數(shù)據(jù)斑举,這個函數(shù)就會一直等待,直到有數(shù)據(jù)才返回病涨。而此時富玷,當前線程還會繼續(xù)處理各種各樣的消息。

快遞的例子:比如你某個時候到A樓一層(假如是內(nèi)核緩沖區(qū))取快遞既穆,但是你不知道快遞什么時候過來赎懦,你又不能干別的事,只能死等著幻工。但你可以睡覺(進程處于休眠狀態(tài))励两,因為你知道快遞把貨送來時一定會給你打個電話(假定一定能叫醒你)。

非阻塞
非阻塞和阻塞的概念相對應囊颅,指在不能立刻得到結(jié)果之前当悔,該函數(shù)不會阻塞當前線程,而會立刻返回踢代。

還是等快遞的例子:如果用輪詢的方法盲憎,每隔5分鐘到A樓一層(內(nèi)核緩沖區(qū))去看快遞來了沒有。如果沒來胳挎,立即返回饼疙。而快遞來了,就放在A樓一層串远,等你去取宏多。

對象的阻塞模式和阻塞函數(shù)調(diào)用
對象是否處于阻塞模式和函數(shù)是不是阻塞調(diào)用有很強的相關(guān)性,但是并不是一一對應的澡罚。阻塞對象上可以有非阻塞的調(diào)用方式伸但,我們可以通過一定的API去輪詢狀態(tài),在適當?shù)臅r候調(diào)用阻塞函數(shù)留搔,就可以避免阻塞更胖。而對于非阻塞對象,調(diào)用特殊的函數(shù)也可以進入阻塞調(diào)用隔显。函數(shù)select就是這樣的一個例子却妨。

  1. 同步,就是我客戶端(c端調(diào)用者)調(diào)用一個功能括眠,該功能沒有結(jié)束前彪标,我(c端調(diào)用者)死等結(jié)果。
  2. 異步掷豺,就是我(c端調(diào)用者)調(diào)用一個功能捞烟,不需要知道該功能結(jié)果薄声,該功能有結(jié)果后通知我(c端調(diào)用者)即回調(diào)通知。
    同步/異步主要針對C端, 但是跟S端不是完全沒有關(guān)系题画,同步/異步機制必須S端配合才能實現(xiàn).同步/異步是由c端自己控制,但是S端是否阻塞/非阻塞, C端完全不需要關(guān)心.
  3. 阻塞默辨, 就是調(diào)用我(s端被調(diào)用者,函數(shù))苍息,我(s端被調(diào)用者缩幸,函數(shù))沒有接收完數(shù)據(jù)或者沒有得到結(jié)果之前,我不會返回竞思。
  4. 非阻塞表谊, 就是調(diào)用我(s端被調(diào)用者,函數(shù))衙四,我(s端被調(diào)用者铃肯,函數(shù))立即返回,通過select通知調(diào)用者

同步IO和異步IO的區(qū)別就在于:數(shù)據(jù)訪問的時候進程是否阻塞传蹈!
阻塞IO和非阻塞IO的區(qū)別就在于:應用程序的調(diào)用是否立即返回押逼!

同步和異步都只針對于本機SOCKET而言的。

同步和異步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的對象也不相同惦界。
阻塞和非阻塞是指當server端的進程訪問的數(shù)據(jù)如果尚未就緒,進程是否需要等待,簡單說這相當于函數(shù)內(nèi)部的實現(xiàn)區(qū)別,也就是未就緒時是直接返回還是等待就緒;
而同步和異步是指client端訪問數(shù)據(jù)的機制,同步一般指主動請求并等待I/O操作完畢的方式,當數(shù)據(jù)就緒后在讀寫的時候必須阻塞(區(qū)別就緒與讀寫二個階段,同步的讀寫必須阻塞),異步則指主動請求數(shù)據(jù)后便可以繼續(xù)處理其它任務,隨后等待I/O,操作完畢的通知,這可以使進程在數(shù)據(jù)讀寫時也不阻塞挑格。(等待"通知")

Node.js里面的描述:

線程在執(zhí)行中如果遇到磁盤讀寫或網(wǎng)絡(luò)通信(統(tǒng)稱為I/O 操作),通常要耗費較長的時間沾歪,這時操作系統(tǒng)會剝奪這個線程的CPU 控制權(quán)漂彤,使其暫停執(zhí)行,同時將資源讓給其他的工作線程灾搏,這種線程調(diào)度方式稱為 阻塞挫望。當I/O 操作完畢時,操作系統(tǒng)將這個線程的阻塞狀態(tài)解除狂窑,恢復其對CPU的控制權(quán)媳板,令其繼續(xù)執(zhí)行。這種I/O 模式就是通常的同步式I/O(Synchronous I/O)或阻塞式I/O (Blocking I/O)泉哈。
相應地蛉幸,異步式I/O (Asynchronous I/O)或非阻塞式I/O (Non-blocking I/O)則針對所有I/O 操作不采用阻塞的策略。當線程遇到I/O 操作時丛晦,不會以阻塞的方式等待I/O 操作的完成或數(shù)據(jù)的返回奕纫,而只是將I/O 請求發(fā)送給操作系統(tǒng),繼續(xù)執(zhí)行下一條語句烫沙。當操作系統(tǒng)完成I/O 操作時匹层,以事件的形式通知執(zhí)行I/O 操作的線程,線程會在特定時候處理這個事件锌蓄。為了處理異步I/O又固,線程必須有事件循環(huán)仲器,不斷地檢查有沒有未處理的事件煤率,依次予以處理仰冠。阻塞模式下,一個線程只能處理一項任務蝶糯,要想提高吞吐量必須通過多線程洋只。而非阻塞模式下,一個線程永遠在執(zhí)行計算操作昼捍,這個線程所使用的CPU 核心利用率永遠是100%识虚,I/O 以事件的方式通知。在阻塞模式下妒茬,多線程往往能提高系統(tǒng)吞吐量担锤,因為一個線程阻塞時還有其他線程在工作,多線程可以讓CPU 資源不被阻塞中的線程浪費乍钻。</span>而在非阻塞模式下肛循,線程不會被I/O 阻塞,永遠在利用CPU银择。多線程帶來的好處僅僅是在多核CPU 的情況下利用更多的核多糠,而Node.js的單線程也能帶來同樣的好處。這就是為什么Node.js 使用了單線程浩考、非阻塞的事件編程模式夹孔。

Linux下的五種I/O模型

1)阻塞I/O(blocking I/O)
2)非阻塞I/O (nonblocking I/O)
3)I/O復用(select 和poll) (I/O multiplexing)
4)信號驅(qū)動I/O (signal driven I/O (SIGIO))
5)異步I/O (asynchronous I/O (the POSIX aio_functions))

前四種都是同步,只有最后一種才是異步IO析孽。

阻塞I/O模型:
簡介:進程會一直阻塞搭伤,直到數(shù)據(jù)拷貝完成

應用程序調(diào)用一個IO函數(shù),導致應用程序阻塞袜瞬,等待數(shù)據(jù)準備好怜俐。 如果數(shù)據(jù)沒有準備好,一直等待….數(shù)據(jù)準備好了吞滞,從內(nèi)核拷貝到用戶空間,IO函數(shù)返回成功指示佑菩。

我們 第一次接觸到的網(wǎng)絡(luò)編程都是從 listen()、send()裁赠、recv()等接口開始的殿漠。使用這些接口可以很方便的構(gòu)建服務器 /客戶機的模型。

阻塞I/O模型圖:在調(diào)用recv()/recvfrom()函數(shù)時佩捞,發(fā)生在內(nèi)核中等待數(shù)據(jù)和復制數(shù)據(jù)的過程绞幌。

當調(diào)用recv()函數(shù)時,系統(tǒng)首先查是否有準備好的數(shù)據(jù)一忱。如果數(shù)據(jù)沒有準備好莲蜘,那么系統(tǒng)就處于等待狀態(tài)谭确。當數(shù)據(jù)準備好后,將數(shù)據(jù)從系統(tǒng)緩沖區(qū)復制到用戶空間票渠,然后該函數(shù)返回逐哈。在套接應用程序中,當調(diào)用recv()函數(shù)時问顷,未必用戶空間就已經(jīng)存在數(shù)據(jù)昂秃,那么此時recv()函數(shù)就會處于等待狀態(tài)。

當使用socket()函數(shù)和WSASocket()函數(shù)創(chuàng)建套接字時杜窄,默認的套接字都是阻塞的肠骆。這意味著當調(diào)用Windows Sockets API不能立即完成時,線程處于等待狀態(tài)塞耕,直到操作完成蚀腿。

并不是所有Windows Sockets API以阻塞套接字為參數(shù)調(diào)用都會發(fā)生阻塞。例如扫外,以阻塞模式的套接字為參數(shù)調(diào)用bind()莉钙、listen()函數(shù)時,函數(shù)會立即返回畏浆。將可能阻塞套接字的Windows Sockets API調(diào)用分為以下四種:

1.輸入操作: recv()胆胰、recvfrom()、WSARecv()和WSARecvfrom()函數(shù)刻获。以阻塞套接字為參數(shù)調(diào)用該函數(shù)接收數(shù)據(jù)蜀涨。如果此時套接字緩沖區(qū)內(nèi)沒有數(shù)據(jù)可讀,則調(diào)用線程在數(shù)據(jù)到來前一直睡眠蝎毡。
2.輸出操作: send()厚柳、sendto()、WSASend()和WSASendto()函數(shù)沐兵。以阻塞套接字為參數(shù)調(diào)用該函數(shù)發(fā)送數(shù)據(jù)别垮。如果套接字緩沖區(qū)沒有可用空間,線程會一直睡眠扎谎,直到有空間碳想。
3.接受連接:accept()和WSAAcept()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)毁靶,等待接受對方的連接請求胧奔。如果此時沒有連接請求,線程就會進入睡眠狀態(tài)预吆。
4.外出連接:connect()和WSAConnect()函數(shù)龙填。對于TCP連接,客戶端以阻塞套接字為參數(shù),調(diào)用該函數(shù)向服務器發(fā)起連接岩遗。該函數(shù)在收到服務器的應答前扇商,不會返回。這意味著TCP連接總會等待至少到服務器的一次往返時間宿礁。

使用阻塞模式的套接字案铺,開發(fā)網(wǎng)絡(luò)程序比較簡單,容易實現(xiàn)窘拯。當希望能夠立即發(fā)送和接收數(shù)據(jù)红且,且處理的套接字數(shù)量比較少的情況下,使用阻塞模式來開發(fā)網(wǎng)絡(luò)程序比較合適涤姊。

阻塞模式套接字的不足表現(xiàn)為,在大量建立好的套接字線程之間進行通信時比較困難嗤放。當使用“生產(chǎn)者-消費者”模型開發(fā)網(wǎng)絡(luò)程序時思喊,為每個套接字都分別分配一個讀線程、一個處理數(shù)據(jù)線程和一個用于同步的事件次酌,那么這樣無疑加大系統(tǒng)的開銷恨课。其最大的缺點是當希望同時處理大量套接字時,將無從下手岳服,其擴展性很差.

阻塞模式給網(wǎng)絡(luò)編程帶來了一個很大的問題剂公,如在調(diào)用 send()的同時,線程將被阻塞吊宋,在此期間纲辽,線程將無法執(zhí)行任何運算或響應任何的網(wǎng)絡(luò)請求。這給多客戶機璃搜、多業(yè)務邏輯的網(wǎng)絡(luò)編程帶來了挑戰(zhàn)拖吼。這時,我們可能會選擇多線程的方式來解決這個問題这吻。

應對多客戶機的網(wǎng)絡(luò)應用吊档,最簡單的解決方式是在服務器端使用多線程(或多進程)。多線程(或多進程)的目的是讓每個連接都擁有獨立的線程(或進程)唾糯,這樣任何一個連接的阻塞都不會影響其他的連接怠硼。

具體使用多進程還是多線程,并沒有一個特定的模式移怯。傳統(tǒng)意義上香璃,進程的開銷要遠遠大于線程,所以芋酌,如果需要同時為較多的客戶機提供服務增显,則不推薦使用多進程;如果單個服務執(zhí)行體需要消耗較多的 CPU 資源,譬如需要進行大規(guī)耐疲或長時間的數(shù)據(jù)運算或文件訪問糖权,則進程較為安全。通常炸站,使用 pthread_create () 創(chuàng)建新線程星澳,fork() 創(chuàng)建新進程。

多線程/進程服務器同時為多個客戶機提供應答服務旱易。模型如下:
圖片待補禁偎。。阀坏。如暖。。

主線程持續(xù)等待客戶端的連接請求忌堂,如果有連接盒至,則創(chuàng)建新線程,并在新線程中提供為前例同樣的問答服務士修。

上述多線程的服務器模型似乎完美的解決了為多個客戶機提供問答服務的要求枷遂,但其實并不盡然。如果要同時響應成百上千路的連接請求棋嘲,則無論多線程還是多進程都會嚴重占據(jù)系統(tǒng)資源酒唉,降低系統(tǒng)對外界響應效率,而線程與進程本身也更容易進入假死狀態(tài)沸移。

由此可能會考慮使用“線程池”或“連接池”痪伦。“線程池”旨在減少創(chuàng)建和銷毀線程的頻率阔籽,其維持一定合理數(shù)量的線程流妻,并讓空閑的線程重新承擔新的執(zhí)行任務“手疲“連接池”維持連接的緩存池绅这,盡量重用已有的連接、減少創(chuàng)建和關(guān)閉連接的頻率在辆。這兩種技術(shù)都可以很好的降低系統(tǒng)開銷证薇,都被廣泛應用很多大型系統(tǒng),如apache匆篓,MySQL數(shù)據(jù)庫等浑度。

但是,“線程池”和“連接池”技術(shù)也只是在一定程度上緩解了頻繁調(diào)用 IO 接口帶來的資源占用鸦概。而且箩张,所謂“池”始終有其上限,當請求大大超過上限時,“池”構(gòu)成的系統(tǒng)對外界的響應并不比沒有池的時候效果好多少先慷。所以使用“池”必須考慮其面臨的響應規(guī)模饮笛,并根據(jù)響應規(guī)模調(diào)整“池”的大小。

對應上例中的所面臨的可能同時出現(xiàn)的上千甚至上萬次的客戶端請求论熙,“線程池”或“連接池”或許可以緩解部分壓力福青,但是不能解決所有問題。

非阻塞IO模型

簡介:非阻塞IO通過進程反復調(diào)用IO函數(shù)(多次系統(tǒng)調(diào)用脓诡,并馬上返回)无午;在數(shù)據(jù)拷貝的過程中,進程是阻塞的祝谚;

我們把一個SOCKET接口設(shè)置為非阻塞就是告訴內(nèi)核宪迟,當所請求的I/O操作無法完成時,不要將進程睡眠踊跟,而是返回一個錯誤踩验。這樣我們的I/O操作函數(shù)將不斷的測試數(shù)據(jù)是否已經(jīng)準備好,如果沒有準備好商玫,繼續(xù)測試,直到數(shù)據(jù)準備好為止牡借。在這個不斷測試的過程中拳昌,會大量的占用CPU的時間。

把SOCKET設(shè)置為非阻塞模式钠龙,即通知系統(tǒng)內(nèi)核:在調(diào)用Windows Sockets API時炬藤,不要讓線程睡眠,而應該讓函數(shù)立即返回碴里。在返回時沈矿,該函數(shù)返回一個錯誤代碼。圖所示咬腋,一個非阻塞模式套接字多次調(diào)用recv()函數(shù)的過程羹膳。前三次調(diào)用recv()函數(shù)時,內(nèi)核數(shù)據(jù)還沒有準備好根竿。因此陵像,該函數(shù)立即返回WSAEWOULDBLOCK錯誤代碼。第四次調(diào)用recv()函數(shù)時寇壳,數(shù)據(jù)已經(jīng)準備好醒颖,被復制到應用程序的緩沖區(qū)中,recv()函數(shù)返回成功指示壳炎,應用程序開始處理數(shù)據(jù)泞歉。


當使用socket()函數(shù)和WSASocket()函數(shù)創(chuàng)建套接字時,默認都是阻塞的。在創(chuàng)建套接字之后腰耙,通過調(diào)用ioctlsocket()函數(shù)榛丢,將該套接字設(shè)置為非阻塞模式。Linux下的函數(shù)是:fcntl().

套接字設(shè)置為非阻塞模式后沟优,在調(diào)用Windows Sockets API函數(shù)時涕滋,調(diào)用函數(shù)會立即返回。大多數(shù)情況下挠阁,這些函數(shù)調(diào)用都會調(diào)用“失敗”宾肺,并返回WSAEWOULDBLOCK錯誤代碼。說明請求的操作在調(diào)用期間內(nèi)沒有時間完成侵俗。通常锨用,應用程序需要重復調(diào)用該函數(shù),直到獲得成功返回代碼隘谣。

需要說明的是并非所有的Windows Sockets API在非阻塞模式下調(diào)用增拥,都會返回WSAEWOULDBLOCK錯誤。例如寻歧,以非阻塞模式的套接字為參數(shù)調(diào)用bind()函數(shù)時掌栅,就不會返回該錯誤代碼。當然码泛,在調(diào)用WSAStartup()函數(shù)時更不會返回該錯誤代碼猾封,因為該函數(shù)是應用程序第一調(diào)用的函數(shù),當然不會返回這樣的錯誤代碼噪珊。

要將套接字設(shè)置為非阻塞模式晌缘,除了使用ioctlsocket()函數(shù)之外,還可以使用WSAAsyncselect()和WSAEventselect()函數(shù)痢站。當調(diào)用該函數(shù)時磷箕,套接字會自動地設(shè)置為非阻塞方式。

由于使用非阻塞套接字在調(diào)用函數(shù)時阵难,會經(jīng)常返回WSAEWOULDBLOCK錯誤岳枷。所以在任何時候,都應仔細檢查返回代碼并作好對“失敗”的準備多望。應用程序連續(xù)不斷地調(diào)用這個函數(shù)嫩舟,直到它返回成功指示為止。上面的程序清單中怀偷,在While循環(huán)體內(nèi)不斷地調(diào)用recv()函數(shù)家厌,以讀入1024個字節(jié)的數(shù)據(jù)。這種做法很浪費系統(tǒng)資源椎工。

要完成這樣的操作饭于,有人使用MSG_PEEK標志調(diào)用recv()函數(shù)查看緩沖區(qū)中是否有數(shù)據(jù)可讀蜀踏。同樣,這種方法也不好掰吕。因為該做法對系統(tǒng)造成的開銷是很大的果覆,并且應用程序至少要調(diào)用recv()函數(shù)兩次,才能實際地讀入數(shù)據(jù)殖熟。較好的做法是局待,使用套接字的“I/O模型”來判斷非阻塞套接字是否可讀可寫。

非阻塞模式套接字與阻塞模式套接字相比菱属,不容易使用钳榨。使用非阻塞模式套接字,需要編寫更多的代碼纽门,以便在每個Windows Sockets API函數(shù)調(diào)用中薛耻,對收到的WSAEWOULDBLOCK錯誤進行處理。因此赏陵,非阻塞套接字便顯得有些難于使用饼齿。

但是,非阻塞套接字在控制建立的多個連接蝙搔,在數(shù)據(jù)的收發(fā)量不均缕溉,時間不定時,明顯具有優(yōu)勢吃型。這種套接字在使用上存在一定難度倒淫,但只要排除了這些困難,它在功能上還是非常強大的败玉。通常情況下,可考慮使用套接字的“I/O模型”镜硕,它有助于應用程序通過異步方式运翼,同時對一個或多個套接字的通信加以管理。

IO復用模型:

簡介:主要是select和epoll兴枯;對一個IO端口血淌,兩次調(diào)用,兩次返回财剖,比阻塞IO并沒有什么優(yōu)越性悠夯;關(guān)鍵是能實現(xiàn)同時對多個IO端口進行監(jiān)聽;

I/O復用模型會用到select躺坟、poll沦补、epoll函數(shù),這幾個函數(shù)也會使進程阻塞咪橙,但是和阻塞I/O所不同的的夕膀,這兩個函數(shù)可以同時阻塞多個I/O操作虚倒。而且可以同時對多個讀操作,多個寫操作的I/O函數(shù)進行檢測产舞,直到有數(shù)據(jù)可讀或可寫時魂奥,才真正調(diào)用I/O操作函數(shù)。


信號驅(qū)動IO

簡介:兩次調(diào)用易猫,兩次返回耻煤;

首先我們允許套接口進行信號驅(qū)動I/O,并安裝一個信號處理函數(shù),進程繼續(xù)運行并不阻塞准颓。當數(shù)據(jù)準備好時哈蝇,進程會收到一個SIGIO信號,可以在信號處理函數(shù)中調(diào)用I/O操作函數(shù)處理數(shù)據(jù)瞬场。


異步IO模型

簡介:數(shù)據(jù)拷貝的時候進程無需阻塞买鸽。

當一個異步過程調(diào)用發(fā)出后,調(diào)用者不能立刻得到結(jié)果贯被。實際處理這個調(diào)用的部件在完成后眼五,通過狀態(tài)、通知和回調(diào)來通知調(diào)用者的輸入輸出操作

圖片待補...............................

同步IO引起進程阻塞彤灶,直至IO操作完成看幼。
異步IO不會引起進程阻塞。
IO復用是先通過select調(diào)用阻塞幌陕。

5個I/O模型的比較:

  1. select诵姜、poll、epoll簡介

select原型說明

epoll模型

epoll跟select都能提供多路I/O復用的解決方案搏熄。在現(xiàn)在的Linux內(nèi)核里有都能夠支持棚唆,其中epoll是Linux所特有,而select則應該是POSIX所規(guī)定心例,一般操作系統(tǒng)均有實現(xiàn)

select:

select本質(zhì)上是通過設(shè)置或者檢查存放fd標志位的數(shù)據(jù)結(jié)構(gòu)來進行下一步處理宵凌。這樣所帶來的缺點是:

1、 單個進程可監(jiān)視的fd數(shù)量被限制止后,即能監(jiān)聽端口的大小有限瞎惫。
一般來說這個數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大,具體數(shù)目可以cat /proc/sys/fs/file-max察看译株。32位機默認是1024個瓜喇。64位機默認是2048.
2、 對socket進行掃描時是線性掃描歉糜,即采用輪詢的方法乘寒,效率較低:
當套接字比較多的時候,每次select()都要通過遍歷FD_SETSIZE個Socket來完成調(diào)度,不管哪個Socket是活躍的,都遍歷一遍现恼。這會浪費很多CPU時間肃续。如果能給套接字注冊某個回調(diào)函數(shù)黍檩,當他們活躍時,自動完成相關(guān)操作始锚,那就避免了輪詢刽酱,這正是epoll與kqueue做的常熙。
3夸赫、需要維護一個用來存放大量fd的數(shù)據(jù)結(jié)構(gòu),這樣會使得用戶空間和內(nèi)核空間在傳遞該結(jié)構(gòu)時復制開銷大

poll:
poll本質(zhì)上和select沒有區(qū)別禾进,它將用戶傳入的數(shù)組拷貝到內(nèi)核空間姐呐,然后查詢每個fd對應的設(shè)備狀態(tài)殿怜,如果設(shè)備就緒則在設(shè)備等待隊列中加入一項并繼續(xù)遍歷,如果遍歷完所有fd后沒有發(fā)現(xiàn)就緒設(shè)備曙砂,則掛起當前進程头谜,直到設(shè)備就緒或者主動超時,被喚醒后它又要再次遍歷fd鸠澈。這個過程經(jīng)歷了多次無謂的遍歷柱告。

它沒有最大連接數(shù)的限制,原因是它是基于鏈表來存儲的笑陈,但是同樣有一個缺點:

1际度、大量的fd的數(shù)組被整體復制于用戶態(tài)和內(nèi)核地址空間之間,而不管這樣的復制是不是有意義涵妥。
2乖菱、poll還有一個特點是“水平觸發(fā)”,如果報告了fd后蓬网,沒有被處理窒所,那么下次poll時會再次報告該fd。

epoll:

epoll支持水平觸發(fā)和邊緣觸發(fā)帆锋,最大的特點在于邊緣觸發(fā)墩新,它只告訴進程哪些fd剛剛變?yōu)榫托钁B(tài),并且只會通知一次窟坐。還有一個特點是,epoll使用“事件”的就緒通知方式绵疲,通過epoll_ctl注冊fd哲鸳,一旦該fd就緒,內(nèi)核就會采用類似callback的回調(diào)機制來激活該fd盔憨,epoll_wait便可以收到通知

epoll的優(yōu)點:

1徙菠、沒有最大并發(fā)連接的限制,能打開的FD的上限遠大于1024(1G的內(nèi)存上能監(jiān)聽約10萬個端口)郁岩;
2婿奔、效率提升缺狠,不是輪詢的方式萍摊,不會隨著FD數(shù)目的增加效率下降挤茄。只有活躍可用的FD才會調(diào)用callback函數(shù); 即Epoll最大的優(yōu)點就在于它只管你“活躍”的連接冰木,而跟連接總數(shù)無關(guān)穷劈,因此在實際的網(wǎng)絡(luò)環(huán)境中,Epoll的效率就會遠遠高于select和poll踊沸。
3歇终、 內(nèi)存拷貝,利用mmap()文件映射內(nèi)存加速與內(nèi)核空間的消息傳遞逼龟;即epoll使用mmap減少復制開銷评凝。

select、poll腺律、epoll 區(qū)別總結(jié):

1奕短、支持一個進程所能打開的最大連接數(shù)

項目 說明
select 單個進程所能打開的最大連接數(shù)有FD_SETSIZE宏定義,其大小是32個整數(shù)的大屑苍(在32位的機器上篡诽,大小就是3232,同理64位機器上FD_SETSIZE為3264)榴捡,當然我們可以對進行修改杈女,然后重新編譯內(nèi)核,但是性能可能會受到影響吊圾,這需要進一步的測試达椰。
poll poll本質(zhì)上和select沒有區(qū)別,但是它沒有最大連接數(shù)的限制项乒,原因是它是基于鏈表來存儲的
epoll 雖然連接數(shù)有上限啰劲,但是很大,1G內(nèi)存的機器上可以打開10萬左右的連接檀何,2G內(nèi)存的機器可以打開20萬左右的連接

2蝇裤、FD劇增后帶來的IO效率問題

項目 說明
select 因為每次調(diào)用時都會對連接進行線性遍歷,所以隨著FD的增加會造成遍歷速度慢的“線性下降性能問題”频鉴。
poll 同上
epoll 因為epoll內(nèi)核中實現(xiàn)是根據(jù)每個fd上的callback函數(shù)來實現(xiàn)的栓辜,只有活躍的socket才會主動調(diào)用callback,所以在活躍socket較少的情況下垛孔,使用epoll沒有前面兩者的線性下降的性能問題藕甩,但是所有socket都很活躍的情況下,可能會有性能問題周荐。

3狭莱、 消息傳遞方式

項目 說明
select 內(nèi)核需要將消息傳遞到用戶空間僵娃,都需要內(nèi)核拷貝動作
poll 同上
epoll epoll通過內(nèi)核和用戶空間共享一塊內(nèi)存來實現(xiàn)的。

總結(jié):

綜上腋妙,在選擇select默怨,poll,epoll時要根據(jù)具體的使用場合以及這三種方式的自身特點辉阶。

1先壕、表面上看epoll的性能最好,但是在連接數(shù)少并且連接都十分活躍的情況下谆甜,select和poll的性能可能比epoll好垃僚,畢竟epoll的通知機制需要很多函數(shù)回調(diào)。
2规辱、select低效是因為每次它都需要輪詢谆棺。但低效也是相對的,視情況而定罕袋,也可通過良好的設(shè)計改善

同步/異步與阻塞/非阻塞經(jīng)掣氖纾看到是成對出現(xiàn):
同步阻塞,異步非阻塞,同步非阻塞

參考資料
socket阻塞與非阻塞,同步與異步浴讯、I/O模型 - huangguisu](http://blog.csdn.net/hguisu/article/details/7453390)

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末朵夏,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子榆纽,更是在濱河造成了極大的恐慌仰猖,老刑警劉巖,帶你破解...
    沈念sama閱讀 219,427評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件奈籽,死亡現(xiàn)場離奇詭異饥侵,居然都是意外死亡,警方通過查閱死者的電腦和手機衣屏,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,551評論 3 395
  • 文/潘曉璐 我一進店門躏升,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人狼忱,你說我怎么就攤上這事膨疏。” “怎么了钻弄?”我有些...
    開封第一講書人閱讀 165,747評論 0 356
  • 文/不壞的土叔 我叫張陵成肘,是天一觀的道長。 經(jīng)常有香客問我斧蜕,道長,這世上最難降的妖魔是什么砚偶? 我笑而不...
    開封第一講書人閱讀 58,939評論 1 295
  • 正文 為了忘掉前任批销,我火速辦了婚禮洒闸,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘均芽。我一直安慰自己丘逸,他們只是感情好,可當我...
    茶點故事閱讀 67,955評論 6 392
  • 文/花漫 我一把揭開白布掀宋。 她就那樣靜靜地躺著深纲,像睡著了一般。 火紅的嫁衣襯著肌膚如雪劲妙。 梳的紋絲不亂的頭發(fā)上湃鹊,一...
    開封第一講書人閱讀 51,737評論 1 305
  • 那天,我揣著相機與錄音镣奋,去河邊找鬼币呵。 笑死,一個胖子當著我的面吹牛侨颈,可吹牛的內(nèi)容都是我干的余赢。 我是一名探鬼主播,決...
    沈念sama閱讀 40,448評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼哈垢,長吁一口氣:“原來是場噩夢啊……” “哼妻柒!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起耘分,我...
    開封第一講書人閱讀 39,352評論 0 276
  • 序言:老撾萬榮一對情侶失蹤举塔,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后陶贼,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體啤贩,經(jīng)...
    沈念sama閱讀 45,834評論 1 317
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,992評論 3 338
  • 正文 我和宋清朗相戀三年拜秧,在試婚紗的時候發(fā)現(xiàn)自己被綠了痹屹。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,133評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡枉氮,死狀恐怖志衍,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情聊替,我是刑警寧澤楼肪,帶...
    沈念sama閱讀 35,815評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站惹悄,受9級特大地震影響春叫,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,477評論 3 331
  • 文/蒙蒙 一暂殖、第九天 我趴在偏房一處隱蔽的房頂上張望价匠。 院中可真熱鬧,春花似錦呛每、人聲如沸踩窖。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,022評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽洋腮。三九已至,卻和暖如春手形,著一層夾襖步出監(jiān)牢的瞬間啥供,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,147評論 1 272
  • 我被黑心中介騙來泰國打工叁幢, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留滤灯,地道東北人。 一個月前我還...
    沈念sama閱讀 48,398評論 3 373
  • 正文 我出身青樓曼玩,卻偏偏與公主長得像鳞骤,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子黍判,可洞房花燭夜當晚...
    茶點故事閱讀 45,077評論 2 355

推薦閱讀更多精彩內(nèi)容