摘 要: 針對近年來互聯(lián)網(wǎng)上迅速興起的多媒體通信應用，分析和指出了當前互聯(lián)網(wǎng)網(wǎng)絡層路由不適于傳輸多媒體數(shù)據(jù)的內(nèi)在缺陷,為改善多媒體通信質量，設計并實現(xiàn)了一個名為CORS的覆蓋層路由系統(tǒng)，通過構建和使用多條覆蓋層路徑來突破網(wǎng)絡層單路徑路由的局限性，并提供應用感知的傳輸層服務。利用在全球網(wǎng)絡實驗平臺——PlanetLab上的真實實驗驗證了CORS的有效性。
關鍵詞: 覆蓋層路由；多媒體通信；端到端性能
隨著互聯(lián)網(wǎng)的日益普及和網(wǎng)絡帶寬的迅速提高，當今的互聯(lián)網(wǎng)已經(jīng)不再局限于支持FTP、Web瀏覽和P2P文件共享等傳統(tǒng)的數(shù)據(jù)傳輸應用，各種基于音頻和視頻的多媒體應用也正在迅速興起。
交互多媒體通信是通信雙方利用語音和視頻等多媒體手段遠程地進行實時互動的通信形式，包括VoIP、視頻會議和遠程教學等具體應用。這類應用在近年來發(fā)展迅速，已被公認為下一代互聯(lián)網(wǎng)的核心業(yè)務之一。與傳統(tǒng)的數(shù)據(jù)傳輸應用一般只關注帶寬不同,交互多媒體通信的質量（用戶感受）對端到端延時、丟包和延時抖動等其他端到端性能指標也都非常敏感，并具有嚴格的要求。
然而，當前的互聯(lián)網(wǎng)卻仍然保留了它最初為傳統(tǒng)的數(shù)據(jù)傳輸應用而設計和優(yōu)化的體系結構。過去二十多年的實踐證明，試圖在網(wǎng)絡層實現(xiàn)服務質量（QoS）保證的方案，如IntServ和DiffServ等，因需要投入大量成本升級核心路由器等基礎設施，且要求相互競爭的ISP間深入合作，最終難以在實際中得到廣泛部署和實施。
覆蓋層路由不需要改變?nèi)魏尉W(wǎng)絡設備，而是利用從邊緣網(wǎng)絡接入的其他普通終端計算機在應用層轉發(fā)網(wǎng)包，使其經(jīng)由不同于網(wǎng)絡層路徑的覆蓋層路徑。RON[1]最早提出了利用覆蓋層路由改善端到端性能的研究項目和實際系統(tǒng)。RON在由普通終端計算機充當?shù)母采w網(wǎng)絡節(jié)點間運行一個類似于OSPF的協(xié)議，用來發(fā)掘和計算任意兩節(jié)點間的最佳路徑，它可能是網(wǎng)絡層路徑，也可能是經(jīng)由多個終端計算機的覆蓋層路徑。但是，由于需要主動測量和監(jiān)測大量“鏈路”狀態(tài)，RON的致命缺點是可擴展性差，只能支持幾十個覆蓋網(wǎng)絡節(jié)點。SOSR[2]提出并驗證了用一跳覆蓋層路徑（即只用一個覆蓋網(wǎng)絡節(jié)點作為中繼）繞開網(wǎng)絡層路徑局部故障的想法。盡管提高了可擴展性，但SOSR只考慮連通性，并采用隨機選擇中繼的算法，無法保證覆蓋層路徑的端到端性能滿足多媒體通信的要求。本文針對交互多媒體通信的數(shù)據(jù)傳輸特點設計和實現(xiàn)了一個新的覆蓋層路由系統(tǒng)——CORS。
1 CORS系統(tǒng)設計
CORS的目標是利用覆蓋層路由技術解決互聯(lián)網(wǎng)的網(wǎng)絡層路由所固有的不適于交互多媒體通信應用的下述幾方面缺陷：(1)網(wǎng)絡層僅提供“盡力而為”的服務，傳輸層TCP協(xié)議的重傳機制難以滿足多媒體通信對數(shù)據(jù)延時的要求； (2)網(wǎng)絡層使用同一條路徑傳輸流量,無法按照具體應用的需求特點區(qū)分網(wǎng)包的優(yōu)先級； (3)網(wǎng)絡層路由的連通性和可用性也有待進一步提高。
CORS的基本思想是構建和使用一條或多條一跳覆蓋層路徑來協(xié)助網(wǎng)絡層路徑改善數(shù)據(jù)傳輸?shù)亩说蕉诵阅?。與RON相比，CORS節(jié)省測量開銷，具有更好的可擴展性，可支持大規(guī)模覆蓋網(wǎng)絡；與SOSR相比，CORS采用啟發(fā)式預選和主動測量確認相結合的方式保證所選覆蓋層路徑能夠滿足傳輸多媒體數(shù)據(jù)的性能要求。而且，CORS還打破了網(wǎng)絡層路由、RON和SOSR僅使用單一路徑的局限，以實現(xiàn)更低的延時和丟包率，以及更高的可用帶寬。
1.1 系統(tǒng)架構
CORS的系統(tǒng)結構示意圖如圖1所示，考慮到覆蓋網(wǎng)絡中節(jié)點能力的異質性，CORS的軟件實現(xiàn)包括Proxy和API兩個組件。Proxy組件僅需要部署在計算能力強接入帶寬大的超級終端節(jié)點，而API組件則要部署在所有希望享用CORS覆蓋層路由服務的客戶端節(jié)點上。
1.2 Proxy組件
Proxy組件是一個與特定網(wǎng)絡端口綁定的持續(xù)運行的監(jiān)聽進程，它的主要功能包括：(1)維持大規(guī)模覆蓋網(wǎng)絡的連通性； (2)向本節(jié)點或其他僅安裝API組件的節(jié)點推薦適當?shù)闹欣^候選節(jié)點； (3)充當中繼節(jié)點在應用層轉發(fā)流經(jīng)的網(wǎng)包。這些功能通過3個模塊具體實現(xiàn)。
1.2.1 Neighbor-Maintainer（NM）模塊
NM模塊負責用Gossip的方式發(fā)現(xiàn)、探測和更新鄰居節(jié)點列表，從而形成并維持一個連通的覆蓋網(wǎng)絡。鄰居節(jié)點是指當前節(jié)點所知的且對其進行周期性探測的安裝了Proxy組件的其他節(jié)點；在覆蓋網(wǎng)絡拓撲當前節(jié)點與其鄰居節(jié)點間是單向直連的。除發(fā)送和應答探測消息外，當列表中的鄰居節(jié)點數(shù)目過少時，此模塊還要發(fā)出特定的請求消息，從其他節(jié)點的鄰居列表中獲取新的節(jié)點來進行填補。
此模塊算法的關鍵是以低開銷保持覆蓋網(wǎng)絡的連通性和優(yōu)秀中繼節(jié)點分布的均勻性，這使當前節(jié)點與任一目標節(jié)點通信時，附近局部網(wǎng)絡中優(yōu)秀中繼節(jié)點的密度與整個覆蓋網(wǎng)絡中的密度相當。
1.2.2 Relay-Advisor(RA)模塊
RA模塊接收本地或遠程節(jié)點API組件發(fā)來的請求消息，根據(jù)源和目標節(jié)點的IP地址等信息，從自身的鄰居列表中選取并推薦適當?shù)闹欣^候選節(jié)點。若自身鄰居列表中滿足條件的中繼候選節(jié)點數(shù)目過少，此模塊還會將請求消息轉發(fā)給部分鄰居節(jié)點，委托它們也推薦一定數(shù)量的中繼候選節(jié)點。
此模塊推薦的中繼候選節(jié)點直接決定了能否用低測量開銷就構建起端到端性能優(yōu)秀的覆蓋層路徑，對整個CORS系統(tǒng)的可擴展性和服務性能都至關重要。為此，此模塊采用了基于PoP層推斷路徑選取中繼候選節(jié)點的啟發(fā)式算法，并使用知識共享機制進行近鄰節(jié)點間協(xié)作。
因篇幅所限，啟發(fā)式算法的細節(jié)超出了本文討論范疇，知識共享機制的核心思想如下：當一對源和目標節(jié)點S和D進行通信，并通過測量發(fā)現(xiàn)優(yōu)秀中繼節(jié)點R時，就將該條“知識”共享，表示為(Sp,Dp,Rp,TS,RTT,…)，其中Sp、Dp和Rp分別表示節(jié)點S、D和R的IP地址前綴，TS表示該條知識的有效時間，而RTT及后續(xù)各項指明這條覆蓋層路徑的延時等各項端到端性能指標；當另一對源和目標節(jié)點S′和D′通信時，會首先查詢是否有前兩項分別為S′p和D′p的知識,如果S′和S、D′和D恰好都具有同樣的IP地址前綴,則無需測量就能優(yōu)先在IP地址前綴為Rp的鄰居節(jié)點中推薦中繼候選節(jié)點。存儲知識的方式既可用中心數(shù)據(jù)庫，也可用完全分布式可擴展性更高的DHT網(wǎng)絡，如OpenDHT[3]。
1.2.3 Packet-Forwarder（PF）模塊
PF模塊屬數(shù)據(jù)層面，負責在應用層轉發(fā)經(jīng)由中繼節(jié)點的網(wǎng)包，同時保證每個會話占用的轉發(fā)帶寬都不超過被許可的最大值。CORS采用了源路由的方式，即把每個網(wǎng)包要經(jīng)過的整條覆蓋層路徑的信息都置于網(wǎng)包的CORS頭部。因此，此模塊只需要根據(jù)頭部信息轉發(fā)網(wǎng)包，而不需像RON那樣傳播路由消息、計算最短路徑和維護路由狀態(tài)。
1.3 API組件
API組件包括兩個功能模塊和一組供應用軟件開發(fā)者調(diào)用的類似于Socket(UDP)的編程接口。
1.3.1 Relay-Selector（RS）模塊
RS模塊請求本地或遠程節(jié)點的Proxy組件推薦中繼候選節(jié)點，并測量這些候選節(jié)點構成的覆蓋層路徑性能，從中選出真正滿足要求的中繼節(jié)點，再根據(jù)上層應用傳輸多媒體數(shù)據(jù)的實際需求向中繼節(jié)點請求和協(xié)商該中繼能夠提供的轉發(fā)帶寬。
為避免啟動延遲過長，此模塊采用迭代的方式選擇中繼節(jié)點并建立覆蓋層路徑；考慮到中繼節(jié)點可能離線等意外因素影響，此模塊預備的覆蓋層路徑的總體性能之和一般會大于多媒體通信會話的實際需求，以便動態(tài)地監(jiān)視和調(diào)整這些覆蓋層路徑。
1.3.2 Multipath-Manager（MM）模塊
MM模塊屬于數(shù)據(jù)層面,它在發(fā)送端調(diào)度和協(xié)調(diào)多媒體數(shù)據(jù)在網(wǎng)絡層路徑和若干條覆蓋層路徑上的傳輸，既要滿足數(shù)據(jù)對延時和可靠性的要求，又要確保每條覆蓋層路徑承載的流量不超過中繼節(jié)點承諾提供的轉發(fā)帶寬。對經(jīng)由覆蓋層路徑的網(wǎng)包，此模塊還要用目標節(jié)點的IP地址、端口以及用于協(xié)助測量丟包率和延時抖動的信息等生成CORS頭部。
在接收端，此模塊執(zhí)行與發(fā)送端相逆的過程：接收來自網(wǎng)絡層和覆蓋層路徑的網(wǎng)包，然后根據(jù)CORS頭部的源節(jié)點IP地址和端口信息，將來自同一源節(jié)點的多媒體數(shù)據(jù)恢復成正常順序，再通知接收端的上層應用軟件進行讀取和播放。
2 工作過程
新節(jié)點首次加入CORS的覆蓋網(wǎng)絡時，它必須通過讀取配置文件或訪問某知名站點等“軟狀態(tài)”方式知道至少一個已處在CORS的覆蓋網(wǎng)絡中且具有Proxy組件的節(jié)點。當覆蓋網(wǎng)絡進入穩(wěn)定狀態(tài)后，一次基于CORS的交互多媒體通信過程如下：
(1) 用戶操作應用軟件期望與另一端的用戶進行多媒體通信，經(jīng)一系列信令交互后(如SIP)，開始建立用于傳輸多媒體數(shù)據(jù)的數(shù)據(jù)通道。
(2) 應用軟件會調(diào)用API組件提供的init()函數(shù)通知RS模塊構建覆蓋層路徑，同時MM模塊馬上開始用網(wǎng)絡層路徑傳輸來自于應用軟件的多媒體數(shù)據(jù)。
(3) RS模塊先查找本地歷史記錄，確認是否以前曾跟同一目標節(jié)點通信并保留了優(yōu)秀中繼節(jié)點信息。如記錄中的覆蓋層路徑不能滿足要求，則RS模塊就用RPC方式請求RA模塊推薦為中繼候選節(jié)點。
(4) RA模塊利用啟發(fā)式算法和知識共享機制推薦中繼候選節(jié)點集，RS模塊通過實際測量從中找到真正滿足要求的中繼節(jié)點，并與它們的PF模塊協(xié)商構建覆蓋層路徑。此過程是迭代式進行的，以盡量保持所有覆蓋層路徑的總體能滿足端到端性能要求。一條覆蓋層路徑的性能包括端到端延時、可用帶寬和傳輸可靠性三項指標。前兩項指標都易于理解，傳輸可靠性的定義為：
其中L表示丟包率，Tn表示當前時刻，Ts表示該中繼節(jié)點最新上線的時刻，τ表示該中繼節(jié)點歷史上平均連續(xù)在線的時間。傳輸可靠性與丟包率的區(qū)別在于考慮了中繼節(jié)點可能中途離線的因素。
(5)發(fā)送端應用軟件調(diào)用sendto()函數(shù)將多媒體數(shù)據(jù)傳遞給MM模塊，MM模塊將利用網(wǎng)絡層路徑和當前可用的覆蓋層路徑盡可能地滿足該數(shù)據(jù)對延時和傳輸可靠性的要求。為提高公平性和降低相關性，MM模塊用一個鏈表存儲所有可用的覆蓋層路徑，當要傳輸一段大小為S、可靠性要求為H且最大期望延時為t的多媒體數(shù)據(jù)時，MM模塊從頭搜索鏈表直到找到第一條覆蓋層路徑p能同時滿足：
其中Ω表示所用覆蓋層路徑的集合。若無法找到Ω滿足上述條件，MM模塊將再使用網(wǎng)絡層路徑冗余傳輸這段多媒體數(shù)據(jù)。
(6) 接收端的MM模塊將從網(wǎng)絡層和覆蓋層路徑到達的網(wǎng)包恢復成多媒體數(shù)據(jù)，通過recvfrom()函數(shù)傳遞給上層應用軟件，并最終播放給用戶。
(7) 當用戶結束此次會話時，應用軟件會調(diào)用close( )函數(shù)通知API組件，發(fā)送端的RS模塊將通知所有覆蓋層路徑的中繼節(jié)點釋放它們?yōu)榇舜螘挶Ａ舻霓D發(fā)帶寬等資源。
3 實驗和性能評價
為考察CORS改善多媒體通信質量的效果，將其原型系統(tǒng)部署在全球規(guī)模的網(wǎng)絡實驗平臺——PlanetLab[4]上進行了實驗：首先從30個PlanetLab節(jié)點中隨機選出若干對，然后分別使用CORS系統(tǒng)和默認的網(wǎng)絡層路徑在它們之間傳輸同一段視頻流數(shù)據(jù)，最后比較不同情況下的有效丟包率和接收端視頻的PSNR。PSNR是一種常用的評價視頻質量的客觀指標，其值越大說明視頻質量的損失越??；人眼一般能感受到PSNR值相差0.5 dB以上的視頻質量差別。視頻流數(shù)據(jù)由一個30 s的簡單背景下人物頭像的視頻片段按H.264編碼分別在384、768、1 024和2 048 kb/s 4種不同碼率下生成。
4種碼率情況下都各在400多對PlanetLab節(jié)點間進行了上述實驗。圖2和圖3分別比較了使用CORS系統(tǒng)和默認的網(wǎng)絡層路徑2種情況下得到的平均有效丟包率和接收端視頻的平均PSNR?？梢钥吹?，在所考察的各種情況下，CORS都能夠顯著降低有效丟包率(2 %左右)和有效提高視頻質量(1.37～2.16 dB)。證實了CORS能夠改善多媒體通信質量的有效性。
針對當前互聯(lián)網(wǎng)網(wǎng)絡層路由不適于傳輸多媒體數(shù)據(jù)的內(nèi)在缺陷，本文提出使用覆蓋層路由技術改善交換多媒體通信質量，并設計和實現(xiàn)了一個具備以下特點的覆蓋層路由系統(tǒng)CORS：(1)低開銷維持覆蓋網(wǎng)絡的連通性和均勻性，按需構建覆蓋層路徑，因而具有高可擴展性；(2)選擇中繼節(jié)點時將啟發(fā)式推薦和知識共享機制與主動測量相結合，既節(jié)省了測量開銷又提高了準確性；(3)向上層提供應用感知的多路徑傳輸機制，更好地滿足多媒體數(shù)據(jù)對延時、丟包和帶寬等端到端性能指標的特定要求。
在PlanetLab上的大規(guī)模實驗結果驗證CORS系統(tǒng)提高數(shù)據(jù)傳輸可靠性和改善多媒體通信質量的有效性。
參考文獻
[1] ANDERSEN D, BALAKRISHNAN H, KAASHOEK F, et al. Resilient overlay networks[J]. ACM SIGOPS Operating Systems Review, 2001,35(5):131-145.
[2] GUMMADI P, MADHYASHA V, GRIBBLE D, et al. Improving the reliability of internet paths with one-hop source routing[C]. In:Proc. of OSDI'04. San Francisco, USA: [s.n],2004:13-27.
[3] RHEA S, GODFREY B, BRAD K, et al. OpenDHT: a public DHT service and its uses[C]. In:Proc. of ACM SIGCOMM’05, Philadelphia, USA:[s.n], 2005.
[4] PlanetLab. http://www.planet-lab.org