并发服务器设计思路，参考apache学习UDP和QoS,研究成果
參考的有：Apache? vlc? ACE? ftp
我主要需要其中的并發處理，內存管理，TCP/UDP.QoS，速度限制等方面的內容，所以著重說這幾方面。
首先看一下Apache的基本框圖，左邊為APR。
然后是Apache在windows下的運行流程
MPM的2種并發模式：
1、?? Windows NT/2000下采用的是完成端口，采用生產者消費者模型。具體的原理為：N（N>=1）個接受者線程異步循環監聽網絡連接，N*64個工作者線程阻塞等待相應的接受者線程投遞完成請求，如果有連接到來，接受者線程會投遞完成請求，工作者線程收到這個請求之后就建立新的鏈路來進行數據收發。
Unix下MPM運行流程
1) 主進程循環
主循環主要是控制進程池中空閑子進程的數目，即循環監控記分板，并根據記分板中子進程的狀態作出反應。
2) 客戶端請求/響應循環
這個循環只適合于子進程。在該循環中，子進程等待自己變為偵聽者，然后等待客戶端的連接，一旦獲取到連接則變為工作者開始處理請求，同時進入Keep-alive循環中。
3) Keep-alive循環
Keep-alive循環主要是處理客戶端的請求，該循環僅僅適合子進程。
4) 在退出之前進行清理工作
?
結論：每個平臺有自己的特點，需要根據平臺特性來設計不同的并發處理機制，例如這里Unix平臺下使用進程作為處理請求的最小單元，而windows使用線程作為處理請求的最小單元；windows下的完成端口可以提供較高的效率，而Unix下的epoll也具有較高的效率，并且2者不能跨平臺使用。
?如果要設計一個UDP的并發處理機制，那么要注意以下幾點：
(1) TCP是每個客戶一個單獨的連接，socket表示一個已建立的連接；而最簡單的UDP服務器只需要一個socket即可完成對所有客戶的操作，這里socket僅僅是單純的socket，真正的目的地址需要指定。給出一個比較通用的UDP服務器架構，可以看出和TCP服務器設計的不同之處。
?
根據計算密集型和I/O密集型來合理控制接收者、緩存隊列和處理者的數量就可以相對適應不用的平臺。由于需要的是I/O密集型服務器，所以一種合理的假設是N=CPU數量，Q=1，M=50。
??? 以上只是原理上的考慮，在真正實施上還是應該結合不同的平臺利用不同的I/O模型來處理UDP的并發。下面是windows下最簡單的IOCP的UDP模型
一、???????????? UDP的質量保證和速度控制
有2種途徑，分別是借鑒TCP的實現機制和采用QoS機制
1借鑒TCP
借鑒TCP的滑動窗口機制來控制速度以保證充分利用帶寬?????????????????????
TCP的特點之一是提供體積可變的滑動窗口機制，支持端到端的流量控制。TCP的窗口以字節為單位進行調整，以適應接收方的處理能力。處理過程如下：???
（1）???????????????????? TCP連接階段，雙方協商窗口尺寸，同時接收方預留數據緩存區；
（2）???????????????????? 發送方根據協商的結果，發送符合窗口尺寸的數據字節流，并等待對方的確認；
（3）???????????????????? 發送方根據確認信息，改變窗口的尺寸，增加或者減少發送未得到確認的字節流中的字節數。調整過程包括：如果出現發送擁塞，發送窗口縮小為原來的一半，同時將超時重傳的時間間隔擴大一倍。
TCP的窗口機制保證了流量控制。但是這種控制并不能比較精確的控制速度，而只是更具網絡情況來自行調整速度。如果要實現比較精確的限速，則可直接利用定時器函數，但是意義不大。
借鑒TCP的超時重傳機制
TCP接收端每次收到數據之后都會發送一個ACK給發送端，發送端根據這個ACK可以來動態控制下次發送數據的時間間隔和發送數據大小。
如果發送端沒有得到ACK，則根據丟包比例動態調節重傳間隔并根據重傳間隔來重傳數據。
參考以上TCP機制，一種最簡單的可靠并且可控的UDP流程如下：
?
發送端收到的ACK越不全則下次發送的時間間隔越長、數據包越少。
圖中用的是收到一個數據包組后返回確認信息。真實環境下可以在一定時間和收到一定數量的包后返回確認信息，當發送端收到這個確認消息之后就可以刪除發送緩存隊列了，并且改為在接收端一接收到不按順序的包序后立刻請求發送端重傳(發送協議中包含了下一次要發送的數據包序列號)。
優點：實現起來相對簡單，并且可以很好的跨平臺
缺點：這種方法的可靠性是建立在重傳和限速的基礎之上，并沒有實現數據在主機和網絡設備上的優先級處理，競爭處理和優先獲取帶寬。而這些正是QoS的優點。
?
2 QoS
QoS就是針對各種不同需求，提供不同服務質量的網絡服務功能。和模擬TCP方式的UDP比較起來，使用QoS相對就比較完善，不僅在錯誤處理和速度控制上有規定，而且在其他很多地方也有優化（例如優先級策略、帶寬保持策略等等）
要使用QoS，首先必須有相應的軟硬件支持。
注：硬件支持指數據傳輸要經過的網絡設備（如路由器、交換機）和本地工作站（可為自己引入的網絡傳輸分派相應的優先級）的支持，網絡設備可以注意到并解析QoS信息（這些信息是保存在RSVP資源預約協議中），并根據這些信息來運行分派調度策略。具體來說就是為使“端到端”的QoS能正常運作，兩個端點之間的網絡設備必須能對數據通信的優先級加以區分。網絡設備對QoS分類的依據就是DSCP（different services code point ：區別服務編碼點）。而DSCP的數值是由COS或者TOS映射得到的。QOS通過DSCP就可以將非常的多的數據流，簡單的規劃分類為幾個大的數據流。如果不用到QoS的分類，則DSCP等于0，表示一視同仁。
第二層：交換機內部協議ISL
| ISL包頭（26字節，3位用于COS） | 被封裝的幀 | FCS（4字節） |
第三層：路由器 IPV4
| 版本/長度 | TOS(1字節) | 長度 | ID | 標記 | TTL | 協議 | 校驗 | IP-SA | IP-DA | 數據 |
其中TOS的高3位表示IP優先級
???? 軟件支持：首先需要操作系統支持QoS，例如windows中的GQOS組件。如果在廣域網下,就要使用RSVP協議,需要路由器支持。網卡要支持802.1p，這樣才可以識別OS分配的以太網幀中的優先級位。
QoS的作用體現在：
1．?分類：將數據分為不同的優先級，區別對待。
2．?流量調節：采用一定的策略來控制流量。
3．?擁塞管理：某些特權數據可以插隊，優先被轉發。
4．?擁塞避免：擁堵時優先丟棄不重要的數據保留重要數據，而不是按照隊列順序丟棄數據。
QoS編程
QoS實現可以分為2大類，一種是IntServ(在基于IP的呼叫兩端,先通過信令建立一條虛連接鏈路，然后呼叫雙方的報文都經此鏈路傳遞，從而達到保證傳輸質量的目的)，一種是DiffServ(它把流經路由器的數據包按照一定的優先級分類，然后按照優先級順序將數據包轉發至下一跳路由器)。2種方案都有缺陷，目前QoS技術還不成熟，對IntServ而言，當網絡規模大到一定程度時，維護鏈路狀態的工作將使核心網路由器不堪重負；如采用采用DiffServ，一旦網絡發生擁塞，報文無論優先級多高，一樣會被阻塞。
服務器端：可能為windows或linux。windows下有GQOS組件可供調用，該組件是基于RSVP(資源預留協議)，該協議通過預留數據鏈路上節點的帶寬來實現IntServ QoS。也可以和linux一樣直接修改定制網絡驅動層；linux下需要修改定制網絡驅動層程序來實現DiffServ QoS，即在網卡發送數據之前先通過一定的策略對數據包進行分類、管理、檢測擁堵和處理擁堵(和網絡設備類似，內部一般使用多緩沖隊列)。
中間層：只要在客戶端和服務器端遵照網絡層協議格式要求在制定規范中間件就可以自動識別和處理。這部分的編程一般由廠商完成。
客戶端：和服務器端收發機制基本相同。
?
?
轉載于:https://www.cnblogs.com/SuperXJ/archive/2009/09/27/1575204.html
總結
以上是生活随笔為你收集整理的并发服务器设计思路，参考apache学习UDP和QoS,研究成果的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件生存周期文档系列 之 6.用户操作手
- 下一篇： 3D 鼠标跟随脚本详解