自應用層組播的概念提出以來，已有很多各具特點的解決方案被提出。各個不同的應用層組播系統具有不同的設計目標及系統結構。如，e**(end-system multicast)
[1]和almi
[2]適合時延要求不高的小規模多對多通訊，而scattercast
[3]和overcasts
[4]則支援大規模的資料遞送系統。
在系統結構方面，根據建立應用層組播拓撲結構時採用的方案，將這些系統分為兩種：網優先(mesh first)和樹優先(tree first)，網優先的系統會首先為覆蓋節點建立乙個網狀的拓撲結構，然後按照某種路由協議來生成資料路由樹，如e**的narada協議，會先構建乙個網，然後通過修改後的dvmrp協議完成路由樹的生成；而樹優先的系統則是直接建立資料路由樹，almi、 overcast、 host multicastis
[5]均屬於這種系統。一般來說，網優先的系統穩定性更好，不會形成迴路，樹優先的系統則在效率上佔優勢。
在多源的應用層組播方案中，根據資料路由樹的使用和維持，可以分為shared tree和source-specific tree兩種。shared tree，就是所有的源使用同一棵樹；source-specific tree，就是每個源維持一棵樹，前者不能保證每個源都能獲得較好的傳輸延遲。
我們的思路是，建立乙個全分布的，支援多組、多源，低時延的，基於不定叉源指定樹(source-specific tree)的tree-first應用層組播協議平台。
基於以上的假設，我們將在組應用開始前建立n棵source-specific tree，n等於組的節點數，每個節點負責生成一棵以它為根的滿三叉樹。我們又知道，有的節點的上傳能力可能不到3個，有的節點則可能超過3個，而且這種能力可能是變動的。由此，這些樹必須根據網路的實際狀態進行調整，節點的分發孩子個數視其能力變動而定，分發能力的判斷，則通過孩子節點反饋rtcp資訊包來計算丟包率。也就是說，滿三叉樹在應用預執行或執行後成為動態調整的不定叉樹。
節點必須清楚自己屬於哪個組，然後加入到合適的組中。
rp(集中點)為節點提供加入服務。任乙個節點加入時，必須向rp報到，rp將新節點加入到組的節點列表中，然後將已加入的節點列表發給新節點，同時，向所有節點通告單個節點加入訊息。
2.3.1「距離」與「距離」計算
節點一旦成功加入，馬上與列表中的同組節點通訊，估算節點之間的「距離」。所謂的「距離」，指的是節點間的傳輸延遲和頻寬加權後的值，我們採取簡單做法，就是測試1k udp包來回所需的時間。我們採取如下演算法計算node
a和node
b節點間的「距離」：
time
as= current time of node
a node
a send 1k bytes to node
b by udp with time
asnode
b recvive packet from node
a time
br= time when node
b recvives the packet
time
bs= current time of node
b node
b send 1k bytes to a by udp with time
as, time
br and time
bs node
a recvive packet from node
b time
ar= time when node
a recvives the packet
distance
ab=time
ar- time
as- (time
bs -time
br)2.3.2樹生成
開始時，每個源生成一棵不超過4層(源，即根，為0層)的滿三叉資料路由樹，樹的生成依據這樣的原則，在樹中，離源較近的節點與源有更近的「距離」，而第2層的節點即與其第1層的父親節點有更近的「距離」 ，依此類推。
首先，根選擇3個最合適的節點作為它的第一層子節點，然後，根分別通知這3個子節點，去尋找它們合適的孩子節點，過程不斷重複，直到所有的節點都加入到樹中。樹的生成是由覆蓋網中的所有節點協同完成的，因此其生成演算法是分布的，演算法如下：
onreceivecreatetree (void *packet)
onreceiveinvitetobechildreq(void * packet)
onreceivetobechildreply(void * packet)
else
if( (孩子數==3 ) || (已入樹節點數+拒絕我的節點數==組節點數))
else
將孩子節點列表打包,傳送給根; }
}onreceiveselectchildrenorder(void * packet) }
樹生成的演算法是由分布在網路上的多個節點機共同執行的，為避免多個節點同時選擇乙個節點為其孩子，因此，我們採用了應答制。
前面講到，在生成樹時，並沒有過多考慮樹的上傳能力，只是基於經驗及網路的一般現狀，假設每節點有能力完成對3個節點的視音訊資料**。但，實際情況可能是，有的節點的分發能力超過3，有的節點則不足3。這樣，在應用預執行後，必須盡快對樹進行調整。
當父親節點認為其上傳能力不足時，希望移交孩子節點，父親節點會選擇頻寬較高的節點傳送移交請求。收到移交請求的節點檢查其自身上傳能力，回應接受請求或不接受請求，傳送移交請求的節點會一直嘗試，直到有節點同意移交，此外，上傳能力不足的節點可以啟用選幀，降低對頻寬的需求，這屬於應用層qos的任務，不在這裡詳述。
目前多數的alm協議，對底層網路變動的適應普遍採取整體變動的方法，這樣的代價相當大，如narada，節點狀態的變化將導致網mesh的重構，從而導致所有source-specific tree的重構，這個過程需要較長的收斂時間。我們採取區域性變化的對策以適應overlay network的變化。
圖1 節點轉移實現優化
有邊相連的節點，互相為鄰居。節點每3秒鐘向鄰居傳送「心跳」資訊。「心跳」資訊可以簡單到是乙個不斷增長的序列號。當節點在30秒鐘收不到鄰居的「心跳」資訊後，節點認為鄰居已經出現故障。
故障處理：
1). 為避免多個節點同時嘗試修補樹，我們規定，只允許上層節點對下層節點進行修補。如果根節點故障，樹的修補失去意義。
2). 後備選擇
從故障節點的最左邊的子孫節點逐級往上提公升，最左的節點不存在，則往右選擇。
3). 葉子節點故障將不修補。
4). 樹修補演算法
如圖2:
i發現其兒子節點j故障後,執行如下演算法:
1. 向組內所有節點通告j的故障
2. j是葉子節點嗎?
2.1 是，演算法結束
2.2 否，轉3
3. j有合適的孩子嗎？
3.1 有，轉4
3.2 沒有，演算法結束
4. 選擇合適的孩子，向其傳送接替j的通知
5. t:=j
圖2樹的修補
任何節點k收到l傳送給自己，要求自己接替節點j的通知，執行如下演算法：
1. k是否葉子
1.1 是，向l傳送j ßk、kß0的通知
1.2 否，選擇合適的兒子，向其傳送接替k的通知，t:=j,t
1:=l
任何節點k收到確認接替的通知，執行如下演算法：
1. 接替串的第乙個節點是自己嗎？
1.1 是，接替串 := tßk+接替串，向t
1傳送接替串
1.2 否，根據接替串替換樹，將新樹向所有節點傳送
協議對很多複雜問題做了簡化，這些簡化對協議的實現帶來很大的便利，但同時也使得協議的適應能力存在著一定的問題，我們將在樹的優化、修補上進行改造，以使得協議具有更廣闊的適應能力。
1 chu y, rao s, zhang h. a case for end system multicast. acm sigmetrics, 2000
3 chawathe y. scattercast: an architecture for internet broadcast distribution as an infrastructure service[ph.d.thesis].2000
4 jannot j.overcast: reliable multicasting with an overlay network.usenix osdi, 2000-10
本文引自：http://www.ahcit.com/lanmuyd.asp?id=2194
基於TCP IP UDP的應用層協議
本篇文章總結一下計算機網路層中的很多協議以及其所依賴的協議 功能協議 基於的協議 網域名稱轉換 dnsudp 檔案傳送 tftp udp網路管理 snmp udpip位址配置 dhcp udp動態路由演算法，尋找路由，距離向量演算法 ripudp 動態路由演算法，鏈路狀態演算法 ospf ipint...
基於tcp的應用層協議還原
基於tcp的應用層協議還原技術是網路安全每個領域都需要的一種基礎技術。首先，我們需要認識到tcp協議的兩個特徵 tcp是一種流協議。傳送者以位元組流的形式傳遞給接收者。tcp協議本身沒有固有的 報文 或 報文邊界 的概念。參考 tcp協議的特徵1意味著，在還原應用層協議之前，我們需要首先將乙個個的t...
應用層的HTTP協議
應用層協議定義了執行在不同端系統上的應用程式程序如何相互傳遞報文，特別是 1 交換的報文型別，例如請求報文和響應報文 2 各種報文型別的語法，例如報文中的各個欄位及這些欄位是如何描述的 3 欄位的語義，即這些欄位中包含的資訊的含義 4 乙個程序何時以及如何傳送報文，對報文進行響應的規則 web的應用...