研究了快1個(gè)月的服務(wù)器架構(gòu)，把研究成果記錄一下。
參考的有：Apache? vlc? ACE? ftp
我主要需要其中的并發(fā)處理，內(nèi)存管理，TCP/UDP.QoS，速度限制等方面的內(nèi)容，所以著重說(shuō)這幾方面。
首先看一下Apache的基本框圖，左邊為APR。


然后是Apache在windows下的運(yùn)行流程

MPM的2種并發(fā)模式：

1、?? Windows NT/2000下采用的是完成端口，采用生產(chǎn)者消費(fèi)者模型。具體的原理為：N（N>=1）個(gè)接受者線程異步循環(huán)監(jiān)聽(tīng)網(wǎng)絡(luò)連接，N*64個(gè)工作者線程阻塞等待相應(yīng)的接受者線程投遞完成請(qǐng)求，如果有連接到來(lái)，接受者線程會(huì)投遞完成請(qǐng)求，工作者線程收到這個(gè)請(qǐng)求之后就建立新的鏈路來(lái)進(jìn)行數(shù)據(jù)收發(fā)。

Unix下MPM運(yùn)行流程

1) 主進(jìn)程循環(huán)

主循環(huán)主要是控制進(jìn)程池中空閑子進(jìn)程的數(shù)目，即循環(huán)監(jiān)控記分板，并根據(jù)記分板中子進(jìn)程的狀態(tài)作出反應(yīng)。

2) 客戶端請(qǐng)求/響應(yīng)循環(huán)

這個(gè)循環(huán)只適合于子進(jìn)程。在該循環(huán)中，子進(jìn)程等待自己變?yōu)閭陕?tīng)者，然后等待客戶端的連接，一旦獲取到連接則變?yōu)楣ぷ髡唛_(kāi)始處理請(qǐng)求，同時(shí)進(jìn)入Keep-alive循環(huán)中。

3) Keep-alive循環(huán)

Keep-alive循環(huán)主要是處理客戶端的請(qǐng)求，該循環(huán)僅僅適合子進(jìn)程。

4) 在退出之前進(jìn)行清理工作

?

結(jié)論：每個(gè)平臺(tái)有自己的特點(diǎn)，需要根據(jù)平臺(tái)特性來(lái)設(shè)計(jì)不同的并發(fā)處理機(jī)制，例如這里Unix平臺(tái)下使用進(jìn)程作為處理請(qǐng)求的最小單元，而windows使用線程作為處理請(qǐng)求的最小單元；windows下的完成端口可以提供較高的效率，而Unix下的epoll也具有較高的效率，并且2者不能跨平臺(tái)使用。

?

如果要設(shè)計(jì)一個(gè)UDP的并發(fā)處理機(jī)制，那么要注意以下幾點(diǎn)：

(1) TCP是每個(gè)客戶一個(gè)單獨(dú)的連接，socket表示一個(gè)已建立的連接；而最簡(jiǎn)單的UDP服務(wù)器只需要一個(gè)socket即可完成對(duì)所有客戶的操作，這里socket僅僅是單純的socket，真正的目的地址需要指定。給出一個(gè)比較通用的UDP服務(wù)器架構(gòu)，可以看出和TCP服務(wù)器設(shè)計(jì)的不同之處。

?

根據(jù)計(jì)算密集型和I/O密集型來(lái)合理控制接收者、緩存隊(duì)列和處理者的數(shù)量就可以相對(duì)適應(yīng)不用的平臺(tái)。由于需要的是I/O密集型服務(wù)器，所以一種合理的假設(shè)是N=CPU數(shù)量，Q=1，M=50。

??? 以上只是原理上的考慮，在真正實(shí)施上還是應(yīng)該結(jié)合不同的平臺(tái)利用不同的I/O模型來(lái)處理UDP的并發(fā)。下面是windows下最簡(jiǎn)單的IOCP的UDP模型

一、???????????? UDP的質(zhì)量保證和速度控制

有2種途徑，分別是借鑒TCP的實(shí)現(xiàn)機(jī)制和采用QoS機(jī)制

1借鑒TCP

借鑒TCP的滑動(dòng)窗口機(jī)制來(lái)控制速度以保證充分利用帶寬?????????????????????

TCP的特點(diǎn)之一是提供體積可變的滑動(dòng)窗口機(jī)制，支持端到端的流量控制。TCP的窗口以字節(jié)為單位進(jìn)行調(diào)整，以適應(yīng)接收方的處理能力。處理過(guò)程如下：???

（1）???????????????????? TCP連接階段，雙方協(xié)商窗口尺寸，同時(shí)接收方預(yù)留數(shù)據(jù)緩存區(qū)；

（2）???????????????????? 發(fā)送方根據(jù)協(xié)商的結(jié)果，發(fā)送符合窗口尺寸的數(shù)據(jù)字節(jié)流，并等待對(duì)方的確認(rèn)；

（3）???????????????????? 發(fā)送方根據(jù)確認(rèn)信息，改變窗口的尺寸，增加或者減少發(fā)送未得到確認(rèn)的字節(jié)流中的字節(jié)數(shù)。調(diào)整過(guò)程包括：如果出現(xiàn)發(fā)送擁塞，發(fā)送窗口縮小為原來(lái)的一半，同時(shí)將超時(shí)重傳的時(shí)間間隔擴(kuò)大一倍。

　TCP的窗口機(jī)制保證了流量控制。但是這種控制并不能比較精確的控制速度，而只是更具網(wǎng)絡(luò)情況來(lái)自行調(diào)整速度。如果要實(shí)現(xiàn)比較精確的限速，則可直接利用定時(shí)器函數(shù)，但是意義不大。

借鑒TCP的超時(shí)重傳機(jī)制

TCP接收端每次收到數(shù)據(jù)之后都會(huì)發(fā)送一個(gè)ACK給發(fā)送端，發(fā)送端根據(jù)這個(gè)ACK可以來(lái)動(dòng)態(tài)控制下次發(fā)送數(shù)據(jù)的時(shí)間間隔和發(fā)送數(shù)據(jù)大小。

如果發(fā)送端沒(méi)有得到ACK，則根據(jù)丟包比例動(dòng)態(tài)調(diào)節(jié)重傳間隔并根據(jù)重傳間隔來(lái)重傳數(shù)據(jù)。

參考以上TCP機(jī)制，一種最簡(jiǎn)單的可靠并且可控的UDP流程如下：

?

發(fā)送端收到的ACK越不全則下次發(fā)送的時(shí)間間隔越長(zhǎng)、數(shù)據(jù)包越少。

圖中用的是收到一個(gè)數(shù)據(jù)包組后返回確認(rèn)信息。真實(shí)環(huán)境下可以在一定時(shí)間和收到一定數(shù)量的包后返回確認(rèn)信息，當(dāng)發(fā)送端收到這個(gè)確認(rèn)消息之后就可以刪除發(fā)送緩存隊(duì)列了，并且改為在接收端一接收到不按順序的包序后立刻請(qǐng)求發(fā)送端重傳(發(fā)送協(xié)議中包含了下一次要發(fā)送的數(shù)據(jù)包序列號(hào))。

優(yōu)點(diǎn)：實(shí)現(xiàn)起來(lái)相對(duì)簡(jiǎn)單，并且可以很好的跨平臺(tái)

缺點(diǎn)：這種方法的可靠性是建立在重傳和限速的基礎(chǔ)之上，并沒(méi)有實(shí)現(xiàn)數(shù)據(jù)在主機(jī)和網(wǎng)絡(luò)設(shè)備上的優(yōu)先級(jí)處理，競(jìng)爭(zhēng)處理和優(yōu)先獲取帶寬。而這些正是QoS的優(yōu)點(diǎn)。

?

2 QoS

QoS就是針對(duì)各種不同需求，提供不同服務(wù)質(zhì)量的網(wǎng)絡(luò)服務(wù)功能。和模擬TCP方式的UDP比較起來(lái)，使用QoS相對(duì)就比較完善，不僅在錯(cuò)誤處理和速度控制上有規(guī)定，而且在其他很多地方也有優(yōu)化（例如優(yōu)先級(jí)策略、帶寬保持策略等等）

要使用QoS，首先必須有相應(yīng)的軟硬件支持。

注：硬件支持指數(shù)據(jù)傳輸要經(jīng)過(guò)的網(wǎng)絡(luò)設(shè)備（如路由器、交換機(jī)）和本地工作站（可為自己引入的網(wǎng)絡(luò)傳輸分派相應(yīng)的優(yōu)先級(jí)）的支持，網(wǎng)絡(luò)設(shè)備可以注意到并解析QoS信息（這些信息是保存在RSVP資源預(yù)約協(xié)議中），并根據(jù)這些信息來(lái)運(yùn)行分派調(diào)度策略。具體來(lái)說(shuō)就是為使“端到端”的QoS能正常運(yùn)作，兩個(gè)端點(diǎn)之間的網(wǎng)絡(luò)設(shè)備必須能對(duì)數(shù)據(jù)通信的優(yōu)先級(jí)加以區(qū)分。網(wǎng)絡(luò)設(shè)備對(duì)QoS分類的依據(jù)就是DSCP（different services code point ：區(qū)別服務(wù)編碼點(diǎn)）。而DSCP的數(shù)值是由COS或者TOS映射得到的。QOS通過(guò)DSCP就可以將非常的多的數(shù)據(jù)流，簡(jiǎn)單的規(guī)劃分類為幾個(gè)大的數(shù)據(jù)流。如果不用到QoS的分類，則DSCP等于0，表示一視同仁。

第二層：交換機(jī)內(nèi)部協(xié)議ISL

ISL包頭（26字節(jié)，3位用于COS）

被封裝的幀

FCS（4字節(jié)）

第三層：路由器 IPV4

版本/長(zhǎng)度

TOS(1字節(jié))

長(zhǎng)度

ID

標(biāo)記

TTL

協(xié)議

校驗(yàn)

IP-SA

IP-DA

數(shù)據(jù)

其中TOS的高3位表示IP優(yōu)先級(jí)

???? 軟件支持：首先需要操作系統(tǒng)支持QoS，例如windows中的GQOS組件。如果在廣域網(wǎng)下,就要使用RSVP協(xié)議,需要路由器支持。網(wǎng)卡要支持802.1p，這樣才可以識(shí)別OS分配的以太網(wǎng)幀中的優(yōu)先級(jí)位。

QoS的作用體現(xiàn)在：

1．?分類：將數(shù)據(jù)分為不同的優(yōu)先級(jí)，區(qū)別對(duì)待。

2．?流量調(diào)節(jié)：采用一定的策略來(lái)控制流量。

3．?擁塞管理：某些特權(quán)數(shù)據(jù)可以插隊(duì)，優(yōu)先被轉(zhuǎn)發(fā)。

4．?擁塞避免：擁堵時(shí)優(yōu)先丟棄不重要的數(shù)據(jù)保留重要數(shù)據(jù)，而不是按照隊(duì)列順序丟棄數(shù)據(jù)。

QoS編程

QoS實(shí)現(xiàn)可以分為2大類，一種是IntServ(在基于IP的呼叫兩端,先通過(guò)信令建立一條虛連接鏈路，然后呼叫雙方的報(bào)文都經(jīng)此鏈路傳遞，從而達(dá)到保證傳輸質(zhì)量的目的)，一種是DiffServ(它把流經(jīng)路由器的數(shù)據(jù)包按照一定的優(yōu)先級(jí)分類，然后按照優(yōu)先級(jí)順序?qū)?shù)據(jù)包轉(zhuǎn)發(fā)至下一跳路由器)。2種方案都有缺陷，目前QoS技術(shù)還不成熟，對(duì)IntServ而言，當(dāng)網(wǎng)絡(luò)規(guī)模大到一定程度時(shí)，維護(hù)鏈路狀態(tài)的工作將使核心網(wǎng)路由器不堪重負(fù)；如采用采用DiffServ，一旦網(wǎng)絡(luò)發(fā)生擁塞，報(bào)文無(wú)論優(yōu)先級(jí)多高，一樣會(huì)被阻塞。

服務(wù)器端：可能為windows或linux。windows下有GQOS組件可供調(diào)用，該組件是基于RSVP(資源預(yù)留協(xié)議)，該協(xié)議通過(guò)預(yù)留數(shù)據(jù)鏈路上節(jié)點(diǎn)的帶寬來(lái)實(shí)現(xiàn)IntServ QoS。也可以和linux一樣直接修改定制網(wǎng)絡(luò)驅(qū)動(dòng)層；linux下需要修改定制網(wǎng)絡(luò)驅(qū)動(dòng)層程序來(lái)實(shí)現(xiàn)DiffServ QoS，即在網(wǎng)卡發(fā)送數(shù)據(jù)之前先通過(guò)一定的策略對(duì)數(shù)據(jù)包進(jìn)行分類、管理、檢測(cè)擁堵和處理?yè)矶?和網(wǎng)絡(luò)設(shè)備類似，內(nèi)部一般使用多緩沖隊(duì)列)。

中間層：只要在客戶端和服務(wù)器端遵照網(wǎng)絡(luò)層協(xié)議格式要求在制定規(guī)范中間件就可以自動(dòng)識(shí)別和處理。這部分的編程一般由廠商完成。

客戶端：和服務(wù)器端收發(fā)機(jī)制基本相同。

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/SuperXJ/archive/2009/09/27/1575204.html

總結(jié)

以上是生活随笔為你收集整理的并发服务器设计思路，参考apache学习UDP和QoS,研究成果的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。