一区二区三区日韩精品-日韩经典一区二区三区-五月激情综合丁香婷婷-欧美精品中文字幕专区

分享

【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二)...

 bxb_koala 2008-10-06

作者:CppExplore 網(wǎng)址:http://www./CppExplore/
本章主要列舉服務(wù)器程序的各種網(wǎng)絡(luò)模型,示例程序以及性能對比后面再寫。
一、分類依據(jù)。服務(wù)器的網(wǎng)絡(luò)模型分類主要依據(jù)以下幾點
(1)是否阻塞方式處理請求,是否多路復(fù)用,使用哪種多路復(fù)用函數(shù)
(2)是否多線程,多線程間如何組織
(3)是否多進(jìn)程,多進(jìn)程的切入點一般都是accept函數(shù)前
二、分類。首先根據(jù)是否多路復(fù)用分為三大類:
(1)阻塞式模型
(2)多路復(fù)用模型
(3)實時信號模型
三、詳細(xì)分類。
1、阻塞式模型根據(jù)是否多線程分四類:
(1)單線程處理。實現(xiàn)可以參見http://www./CppExplore/archive/2008/03/14/44509.html后面的示例代碼。
(2)一個請求一個線程。
主線程阻塞在accept處,新連接到來,實時生成線程處理新連接。受限于進(jìn)程的線程數(shù),以及實時創(chuàng)建線程的開銷,過多線程后上下文切換的開銷,該模型也就是有學(xué)習(xí)上價值。
(3)預(yù)派生一定數(shù)量線程,并且所有線程阻塞在accept處。
該模型與下面的(4)類似與線程的領(lǐng)導(dǎo)者/追隨者模型。
傳統(tǒng)的看法認(rèn)為多進(jìn)程(linux上線程仍然是進(jìn)程方式)同時阻塞在accept處,當(dāng)新連接到來時會有“驚群”現(xiàn)象發(fā)生,即所有都被激活,之后有一個獲取連接描述符返回,其它再次轉(zhuǎn)為睡眠。linux從2.2.9版本開始就不再存在這個問題,只會有一個被激活,其它平臺依舊可能有這個問題,甚至是不支持所有進(jìn)程直接在accept阻塞。
(4)預(yù)派生一定數(shù)量線程,并且所有線程阻塞在accept前的線程鎖處。
一次只有一個線程能阻塞在accept處。避免不支持所有線程直接阻塞在accept,并且避免驚群問題。特別是當(dāng)前l(fā)inux2.6的線程庫下,模型(3)沒有存在的價值了。另有文件鎖方式,不具有通用性,并且效率也不高,不再單獨列舉。
(5)主線程處理accept,預(yù)派生多個線程(線程池)處理連接。
類似與線程的半同步/半異步模型。
主線程的accept返回后,將clientfd放入預(yù)派生線程的線程消息隊列,線程池讀取線程消息隊列處理clientfd。主線程只處理accept,可以快速返回繼續(xù)調(diào)用accept,可以避免連接爆發(fā)情況的拒絕連接問題,另加大線程消息隊列的長度,可以有效減少線程消息隊列處的系統(tǒng)調(diào)用次數(shù)。
(6)預(yù)派生多線程阻塞在accept處,每個線程又有預(yù)派生線程專門處理連接。
3)和(4)/(5)的復(fù)合體。
經(jīng)測試,(5)中的accept線程處理能力非常強,遠(yuǎn)遠(yuǎn)大于業(yè)務(wù)線程,并發(fā)10000的連接數(shù)也毫無影響,因此該模型沒有實際意義。
總結(jié):就前五模型而言,性能最好的是模型(5)。模型(3)/(4)可以一定程度上改善模型(1)的處理性能,處理爆發(fā)繁忙的連接,仍然不理想。。阻塞式模型因為讀的阻塞性,容易受到攻擊,一個死連接(建立連接但是不發(fā)送數(shù)據(jù)的連接)就可以導(dǎo)致業(yè)務(wù)線程死掉。因此內(nèi)部服務(wù)器的交互可以采用這類模型,對外的服務(wù)不適合。優(yōu)先(5),然后是(4),然后是(1),其它不考慮。
2、多路復(fù)用模型根據(jù)多路復(fù)用點、是否多線程分類:
以下各個模型依據(jù)選用select/poll/epoll又都細(xì)分為3類。下面?zhèn)€別術(shù)語采用select中的,僅為說明。
(1)accept函數(shù)在多路復(fù)用函數(shù)之前,主線程在accept處阻塞,多個從線程在多路復(fù)用函數(shù)處阻塞。主線程和從線程通過管道通訊,主線程通過管道依次將連接的clientfd寫入對應(yīng)從線程管道,從線程把管道的讀端pipefd作為fd_set的第一個描述符,如pipefd可讀,則讀數(shù)據(jù),根據(jù)預(yù)定義格式分解出clientfd放入fd_set,如果clientfd可讀,則read之后處理業(yè)務(wù)。
此方法可以避免select的fd_set上限限制,具體機器上select可以支持多少個描述符,可以通過打印sizeof(fd_set)查看,我機器上是512字節(jié),則支持512×8=4096個。為了支持多余4096的連接數(shù),此模型下就可以創(chuàng)建多個從線程分別多路復(fù)用,主線程accept后平均放入(順序循環(huán))各個線程的管道中。創(chuàng)建5個從線程以其對應(yīng)管道,就可以支持2w的連接,足夠了。另一方面相對與單線程的select,單一連接可讀的時候,還可以減少循環(huán)掃描fd_set的次數(shù)。單線程下要掃描所有fd_set(如果再最后),該模型下,只需要掃描所在線程的fd_set就可。
(2)accept函數(shù)在多路復(fù)用函數(shù)之前,與(1)的差別在于,主線程不直接與從線程通過管道通訊,而是將獲取的fd放入另一緩存線程的線程消息隊列,緩存線程讀消息隊列,然后通過管道與從線程通訊。
目的在主線程中減少系統(tǒng)調(diào)用,加快accept的處理,避免連接爆發(fā)情況下的拒絕連接。
(3)多路復(fù)用函數(shù)在accept之前。多路復(fù)用函數(shù)返回,如果可讀的是serverfd,則accept,其它則read,后處理業(yè)務(wù),這是多路復(fù)用通用的模型,也是經(jīng)典的reactor模型。
4)連接在單獨線程中處理。
以上(1)(2)(3)都可以在檢測到cliendfd可讀的時候,把描述符寫入另一線程(也可以是線程池)的線程消息隊列,另一線程(或線程池)負(fù)責(zé)read,后處理業(yè)務(wù)。

(5)業(yè)務(wù)線程獨立,下面的網(wǎng)絡(luò)層讀取結(jié)束后通知業(yè)務(wù)線程。
以上(1)(2)(3)(4)中都可以將業(yè)務(wù)線程(可以是線程池)獨立,事先告之(1)、(2)、(3)、(4)中read所在線程(上面1、2、4都可以是線程池),需要讀取的字符串結(jié)束標(biāo)志或者需要讀取的字符串個數(shù),讀取結(jié)束,則將clientfd/buffer指針放入業(yè)務(wù)線程的線程消息隊列,業(yè)務(wù)線程讀取消息隊列處理業(yè)務(wù)。這也就是經(jīng)典的proactor模擬。
總結(jié):模型(1)是拓展select處理能力不錯選擇;模型(2)是模型(1)在爆發(fā)連接下的調(diào)整版本;模型(3)是經(jīng)典的reactor,epoll在該模型下性能就已經(jīng)很好,而select/poll仍然存在爆發(fā)連接的拒絕連接情況;模型(4)(5)則是方便業(yè)務(wù)處理,對模型(3)進(jìn)行多線程調(diào)整的版本。帶有復(fù)雜業(yè)務(wù)處理的情況下推薦模型(5)。根據(jù)測試顯示,使用epoll的時候,模型(1)(2)相對(3)沒有明顯的性能優(yōu)勢,(1)由于主線程兩次的系統(tǒng)調(diào)用,反而性能下降。
3、實時信號模型:
使用fcntl的F_SETSIG操作,把描述符可讀的信號由不可靠的SIGIO(SYSTEM V)或者SIGPOLL(BSD)換成可靠信號。即可成為替代多路復(fù)用的方式。優(yōu)于select/poll,特別是在大量死連接存在的情況下,但不及epoll。
四、多進(jìn)程的參與的方式
(1)fork模型。fork后所有進(jìn)程直接在accept阻塞。以上主線程在accept阻塞的都可以在accept前fork為多進(jìn)程。同樣面臨驚群問題。
(2)fork模型。fork后所有進(jìn)程阻塞在accept前的線程鎖處。同線程中一樣避免不支持所有進(jìn)程直接阻塞在accept或者驚群問題,所有進(jìn)程阻塞在共享內(nèi)存上實現(xiàn)的線程互斥鎖。
(3)業(yè)務(wù)和網(wǎng)絡(luò)層分離為不同進(jìn)程模型。這個模型可能是受unix簡單哲學(xué)的影響,一個進(jìn)程完成一件事情,復(fù)雜的事情通過多個進(jìn)程結(jié)合管道完成。我見過進(jìn)程方式的商業(yè)協(xié)議棧實現(xiàn)。自己暫時還沒有寫該模型的示例程序測試對比性能。
(4)均衡負(fù)載模型。起多個進(jìn)程綁定到不同的服務(wù)端口,前端部署lvs等均衡負(fù)載系統(tǒng),暴露一個網(wǎng)絡(luò)地址,后端映射到不同的進(jìn)程,實現(xiàn)可擴展的多進(jìn)程方案。
總結(jié):個人認(rèn)為(1)(2)沒什么意義。(3)暫不評價。(4)則是均衡負(fù)載方案,和以上所有方案不沖突。
以上模型的代碼示例以及性能對比后面給出。

posted on 2008-03-21 17:16 cppexplore 閱讀(2800) 評論(14)  編輯 收藏 引用

評論

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-21 19:17 sgsoft
現(xiàn)在的高性能服務(wù)器多采用異步IO,在Windows上,使用IOCP,在AIX上,使用AIO 系統(tǒng)對象,在Solaris,HP-UX上,都有不同實現(xiàn)。但大多使用了OS的異步事件隊列來防止連接阻塞。

是否缺異步通信服務(wù)器模型呢?Win和*inx不一樣的實現(xiàn)。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-21 22:05 cppexplore
@sgsoft
win上實現(xiàn)了socket上真正的AIO,*inx上基本上都沒有針對socket實現(xiàn)真正的AIO。本文主要針對linux平臺,其他平臺不很熟悉,并且沒機會接觸,也無法寫代碼進(jìn)行測試,因此AIO的模型就沒涉及。
另詳細(xì)分類2里的模型(5)模擬了AIO的實現(xiàn),也就是proactor的模擬。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-03-22 12:27 創(chuàng)
我一直采用的sever處理模型是,父進(jìn)程創(chuàng)建出監(jiān)聽socket,然后fork出子進(jìn)程,子進(jìn)程中在accept出阻塞,處理IO時采用多路復(fù)用模型(select之類的),個人感覺效率還是不錯的.

BTW:看來兄臺也是server程序員,有時間多多交流:)
  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 12:16 cppexplore
@創(chuàng)
你的模型是不是和細(xì)分類2中(1)的模型類似啊,直接使用線程不更好嘛。如果是用epoll的話,直接單線程在epoll處wait就好。

以前去你blog上逛過,呵呵,多多交流!  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 15:24 ecopgm
在下是新手,想問幾個問題:
1. 上面的模型,都是將accept獨立處理,這樣可以接受爆發(fā)連接,然后讀寫和邏輯處理都是交給下級線程池。那這樣的模型跟主線程里accept并讀寫,然后下級線程池處理邏輯,在性能上區(qū)別有多大呢?
2. accept即使接受了所有爆發(fā)連接,但是生產(chǎn)者快,消費者慢,加上隊列的流控,這樣還是沒什么用啊,連接還是會被丟掉
3. 消息隊列和管道,這兩種通信方式,在性能上有什么差異?管道更好嗎,比消息隊列更少的同步操作?  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-03-24 19:32 CppExplore
@ecopgm
1、上面的模型并不是都將accept獨立處理啊?各種情況都有的。“下級線程池處理邏輯”這個就多說了,這個和accept/讀寫是否在同一線程不沖突,不同線程的時候也可以把邏輯獨立出來。各種模型性能上的數(shù)據(jù)對比后面的文章會給出具體的數(shù)據(jù)。概括說下,不單獨處理accept,除epoll方式外,爆發(fā)連接都會出現(xiàn)拒絕連接情況,比如ab(apache帶的工具)并發(fā)1w的時候。當(dāng)然并非所有的服務(wù)器能是要處理這種爆發(fā)的斷連接。在不拒絕連接的情況下,比如并發(fā)1000,性能還是差不多的。
2、連接被拒絕是在三路握手階段,accept接受的所有連接,連接就不會被丟掉了啊,生產(chǎn)者的確是非???,消費者很慢,但不影響client把數(shù)據(jù)發(fā)送到這邊的接受緩沖區(qū)。服務(wù)器沒有發(fā)送reset的必要,client也不會發(fā)fin分節(jié),連接自然不會被丟掉。
3、消息隊列自然比管道快,這里的消息隊列不是ipc的消息隊列,全部實現(xiàn)在用戶態(tài),可以看下上一篇《線程二》有消息隊列的實現(xiàn),比涉及系統(tǒng)調(diào)用的管道快,管道怎么也是屬于進(jìn)程間通訊的方式。但是消息隊列不能象管道一樣把文件描述符放到fd_set里,供select監(jiān)控。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 22:11 ecopgm
@CppExplore
我先前理解錯了,能不能接受爆發(fā)連接,是取決于accept的速度。我對并發(fā)的概念沒想清楚,呵呵,謝謝。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-03-24 22:34 CppExplore
@ecopgm
這么晚還沒睡覺啊。
這里說的爆發(fā)的連接,也可以說是單點并發(fā)。你想的并發(fā)是不是同時在線的連接啊?一般都是追求的同時在線連接數(shù)。爆發(fā)連接的場景畢竟也不多。尤其是對音頻視頻等多媒體的應(yīng)用服務(wù)器,限于網(wǎng)絡(luò)帶寬,也不可能有爆發(fā)的連接出現(xiàn),有的話直接拒絕連接就可以接受,呵呵。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 22:41 ecopgm
對的,我想成請求數(shù)了,覺得如果1萬個連接到了,每個發(fā)個消息過來,邏輯層處理不了這么多,而隊列又裝不下,那這個請求就丟失了,請求不是連接,呵呵  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-25 10:11 游客
好文章,贊一個??!  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-04-30 20:05 true
下面這個假想的模型在上面有體現(xiàn),但不太好歸類,描述如下:
1.主線程一直accept
2.有一個線程在監(jiān)聽epoll事件
3.accept后將連接加入2中的epoll監(jiān)聽(在epoll中add 這個fd時是線程安全的嗎?)
4.epoll檢測到某fd可讀時,交給業(yè)務(wù)邏輯線程t1處理(這時需要在epoll中del這個fd嗎),在t1中根據(jù)請求的類型給fd發(fā)送了一些數(shù)據(jù),然后再加入到epoll中?。即2中的epoll只監(jiān)聽可讀  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-05-01 07:53 CppExplore
@true
:)
這個就是文中2(1)的模型,主線程accept,將新的clientfd通過管道傳遞給epoll線程,管道的讀端也在epoll的監(jiān)控之下。不使用管道的話,sockpair也可以,不過它也是基于管道實現(xiàn)。
管道的連接是不可回避的,因為epoll線程在epoll_wait處等待,要實時的告訴epoll監(jiān)控某fd,一定要epoll_wait返回,執(zhí)行加入操作,再繼續(xù)epoll_wait。
后面的業(yè)務(wù)線程處理也就是2(4)和2(5)模型。
2(3)是單線程的模型,就epoll而言,單線程的性能最好,也就是epoll+單線程=高性能。業(yè)務(wù)線程當(dāng)然是根據(jù)需要后接線程,測試的數(shù)據(jù)一直沒時間發(fā)出來,過幾天發(fā)下。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-06-19 12:12 Jeff
想問一下,不可以用UDP來接收請求數(shù)據(jù)嗎,為什么非要用TCP,UDP不可靠?  回復(fù)  更多評論
  

# re: 【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-06-19 13:26 CppExplore
@Jeff
udp也可以啊,模型簡單,在一個端口上復(fù)用就可以了,沒什么可寫的。  回復(fù)  更多評論

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多

    草草夜色精品国产噜噜竹菊| 亚洲精品有码中文字幕在线观看| 亚洲中文字幕乱码亚洲| 人妻偷人精品一区二区三区不卡| 国产福利一区二区久久| 亚洲中文字幕乱码亚洲| 狠狠做五月深爱婷婷综合| 欧美二区视频在线观看| 日本熟妇五十一区二区三区 | 91亚洲精品亚洲国产| 日本男人女人干逼视频| 亚洲熟女一区二区三四区| 欧美精品在线观看国产| 久久永久免费一区二区| 一区二区三区18禁看| 久久国内午夜福利直播| 在线观看视频成人午夜| 日本在线高清精品人妻| 开心久久综合激情五月天| 久久精品一区二区少妇| 欧美同性视频免费观看| 欧美日韩少妇精品专区性色| 免费精品一区二区三区| 国产爆操白丝美女在线观看| 黄色国产精品一区二区三区| 经典欧美熟女激情综合网| 日韩欧美第一页在线观看| 久久本道综合色狠狠五月 | 精品一区二区三区三级视频| 尤物天堂av一区二区| 日本视频在线观看不卡| 日本加勒比在线观看不卡| 少妇一区二区三区精品| 又大又紧又硬又湿又爽又猛| 青青操日老女人的穴穴| 日韩毛片视频免费观看| 国产精品色热综合在线| 麻豆一区二区三区精品视频| 国产不卡在线免费观看视频| 熟女少妇一区二区三区蜜桃| 国产传媒一区二区三区|