摘 要： 介紹了典型的P2P流媒體系統模型，并指出基于多播樹協議的服務模型與基于Gossip協議的服務模型的區別。分析了對P2P流媒體系統的節點的調度算法、數據存儲、資源發現、內容分發等關鍵技術，在此基礎上指出了P2P流媒體系統進一步的研究方向。
??? 關鍵詞： 對等網絡；流媒體系統；數據存儲；資源發現；內容分發
?
?? 以P2P(Peer-to-Peer)為代表的覆蓋網絡，以其獨特的結構特點，可變集中處理和存儲為分布處理和存儲，充分挖掘Internet邊緣的空閑資源，克服了傳統的客戶機/服務器(C/S)結構中服務器負載過高、網絡帶寬占用過大、服務器易形成單點失效等缺點，并改善了網絡層組播(IP組播)結構系統擴展性不好、內容分發網絡CDN(Content Delivery Network)部署成本高等缺點。基于這些優勢，研究人員將P2P技術引入流媒體系統中，形成了P2P流媒體技術。
P2P技術的快速發展為大規模流媒體應用提供了新的解決方案，許多實際運行的系統證明了將P2P技術應用于內容分發過程中的有效性，如提供文件共享服務功能的BitTorrent系統[1]、提供視頻直播服務功能的CoolStreaming[2]、PPLive[3]以及提供視頻點播服務功能的PPStream[4]等。本文對P2P流媒體系統模型及其關鍵技術進行了分析，并在此基礎上指出了P2P流媒體技術的進一步的研究方向。
1 P2P流媒體系統模型
P2P流媒體系統按其工作方式大致可分為二類：基于樹狀多播系統和基于Gossip協議的網狀多播系統。
基于樹狀多播的P2P流媒體系統將網絡中所有節點組織成1棵多播樹，如圖1所示。樹的根節點是媒體發布源，流媒體數據從多播樹的父節點向其子節點傳播直到葉節點。該方法可以最小化系統中多余的數據傳播，并保證每個數據塊能傳播到系統中每個節點，其缺點是：(1)多播樹極易分裂且維護的開銷巨大；(2)多播樹的父節點限制了其所在子樹的最大輸入帶寬，因此多播樹中帶寬瓶頸節點到處存在；(3)各個節點的負載不均衡，如葉節點只下載不上傳，是純粹的帶寬消費者。典型代表有ZIGZAG系統[5]等。
?
近年來，基于Gossip協議的P2P流媒體系統已成為P2P流媒體系統的主流，如圖2所示?；贕ossip協議的網狀服務模型并沒有依靠固定的拓撲結構把數據轉發給接收節點，而是依靠數據有效信息來驅動數據在節點間流動，因此該結構又稱為數據驅動化網絡。節點首先將消息發送給周圍的一組節點，周圍節點在接收到消息后根據需要對消息進行轉發，消息就可以通過節點之間以接力的方式進行傳遞。鄰居維護的靈活性與數據傳播的隨機性使得基于Gossip協議的P2P流媒體系統不會因節點失效而導致顯著的性能下降，從而良好地適應了高動態性的互聯網環境。因此，本文主要針對網狀結構系統模型來分析P2P流媒體系統的主要組成部分及關鍵實現技術。
?
為了更好地理解P2P流媒體系統的框架結構，下面給出基于Gossip協議的DONet服務模型系統的主要功能模塊。
(1)成員管理模塊：實現成員節點的管理。在成員管理模塊中維護一個mCache(membership Cache)，該表包含當前系統中部分活動節點信息。當新節點加入系統時，首先連接節目源服務器，服務器從它的mCache中隨機選擇1個代理節點，并把新節點的加入請求重定向給該代理節點。新節點從代理節點獲取1個成員列表作為備選節點集合，然后從該集合中選取部分節點作為自己的伙伴節點。
(2)伙伴關系管理模塊：建立和維護節點間的伙伴關系，并通過交換緩存映射圖BM(Buffer Map)獲取節點間的有效數據信息。整個視頻流被分成長度相同的數據段(segment)，節點緩存中的數據段有效性信息可通過BM來表示。節點定期地與其伙伴節點交換BM，調度算法根據伙伴節點中的BM來確定獲取哪個數據段。
(3)調度模塊：負責把數據實時地傳送到播放節點的緩存中，用以保證媒體播放的連續性。對于同構的靜態網絡，簡單的輪詢調度算法即可滿足數據的調度；但對于異構的動態網絡，則需要更加智能化的調度算法。調度應滿足2個約束條件[6]：①每個數據段需在播放時限之前到達，錯過時限的片段要盡可能少；②每個節點的帶寬情況不同。該問題是并行機調度的一個變種，為NP難題。因此，想要尋找一個適合具體網絡的調度算法，特別是適合動態網絡環境的調度算法，將是非常困難的。下面給出一種可以實時連續觀看流媒體內容的節點調度算法。
節點的調度算法
??? 輸入：deadline[i]??? 數據塊i的截止期限
????????? seg_size?????? 數據塊的大小
????????? set_partners?? 伙伴節點集合
????????? num_partners?? 節點的伙伴節點的數量
???? ? band[k]????? 伙伴節點k的帶寬
????????? bm[k]????????? 伙伴節點k的緩存映射
????????? fetch_set????? 需要取得的數據塊集合
??? 輸出：supplier[i]??? 在fetch_set中不可用數據塊i的提供者
??? (1)對于塊i∈fetch_set，執行
????①n←0；
????②對于j從1到num_partners，執行
??????? T[j，i]←deadline[i]-current_time；?? //傳送到第i個
//數據塊可用的時間
??????? n←n+bm[j，i]；?????????????????????? //數據塊i的潛在提供者數量
????③若n=1，則執行???????????????????????? //數據塊只有1個潛在提供者
?????? k←argr{bm[r，i]=1}；
???????? supplier[i]←k；
?? ?????? 對于fetch_set中的每個塊j(j>k)，執行
?? ????? t[k，j]←t[k，j]-seg_size/band[k]；
???? ? 否則，執行
???????????? dup_set[n]←dup_set[n]Y{i}；
???????? supplier[n]←null；
(2)對于n從2到num_partners，執行
???? 對于每個i∈fetch_set[n]，執行? //數據塊有n個
?????????????????????????????????????????????//潛在提供者
?????????????? k←argr{band[r]>brand[r′]|t[r，i]>set_size/
?????? band[r]|，t[r′，i]>seg_size/band[r′]，r，r′∈set_partners}；
??? 若k不為空，則
supplier[i]←k；
????? 對于fetch_set中的每個塊j(j>k)，執行
??????????????????????? t[k，j]←t[k，j]-seg_size/band[k]；
(3)返回supplier[i]。
在節點調度算法中，首先計算每個數據塊的潛在提供者的數量。因為當1個數據塊有很少的潛在提供者時，要滿足該數據塊的截止期限的限制將會很困難。因為節點調度算法從開始只有單個提供者的塊到具有2個提供者的數據塊再到具有多個提供者的數據塊的順序來確定每個數據塊的潛在提供者。在這些潛在提供者中，具有最高帶寬、足夠的可利用時間的提供者將會被選擇。算法被周期性地執行更新調度，調度完成后，同一個提供者的數據塊被表示成BM的形式傳送給相應的提供者，提供者通過一個實時的傳輸協議傳輸數據。
2 數據存儲
??? 媒體數據在系統中存儲決定了系統中數據的可用性。這不僅對P2P直播系統中節點間播放的同步性有影響，而且對視頻點播系統中交互性支持能力也有直接的影響。因此，好的數據存儲策略對整個系統的性能的提高是至關重要的。
2.1 數據分塊策略
??? 單個節點的存儲能力有限，這就要求對媒體數據進行分割，將其分散存儲于系統中的多個節點中。CoolStreaming首先把整個媒體文件分成大小相等的若干數據塊，以連續編號進行標識，并且將整個視頻流劃分為一系列的子流，每個子流中存儲一部分數據塊。假設某媒體文件被分成K個子流，則第K個子流上存儲的數據塊為nK+i，其中，n是非負整數，i是1~K的正整數。
參考文獻[3]指出，從資源調度和流媒體傳輸實時性角度考慮，媒體數據被劃分的數據塊數目越多越好，即數據塊體積越小越好；而從網絡開銷角度考慮，媒體數據被劃分的數據塊數目越少越好，即數據塊體積越大越好。因此，如何權衡這兩方面的關系是一個很有價值的研究課題。
2.2 數據緩存及更新策略
??? 緩存是指用戶觀看視頻時把當前媒體數據暫時保存在系統內存或者外存中，它是一種被動的存儲方式，存儲內容由當前觀看的視頻內容決定。在P2P直播系統中，用戶的觀看過程基本同步，上游節點中的緩存內容可以很好地滿足下游節點的要求。但在點播系統中，用戶請求數據具有異步性，如何對分布于多個節點的媒體數據進行緩存和更新則需要更加復雜的策略。
通常的緩存策略是對正在下載播放的數據按時間順序進行緩存，如果緩存空間已滿，則采用LRU(Least Recently Used Algorithms)或其他簡單的緩存替換算法進行替換。該方法沒有考慮緩存內容的流行度及其他節點的緩存情況，這樣容易造成節點保存了較多流行度不高且在系統中已有足夠副本的數據，而替換出了流行度高且緩存的副本數量不足的媒體數據。
參考文獻[7]指出，一個緩存替換算法既要考慮到媒體數據的流行程度，也應關注到該流媒體塊在其他節點中的緩存情況，其定義了流媒體塊的使用價值R=流媒體數據塊的流行度(F)/系統已緩存該流媒體塊的副本數量(CN)，并提出了相應的緩存替換算法。該替換算法的本質是替換出使用價值最小者，緩存使用價值最大者。 2.3 支持交互式的存儲方法
為了支持視頻點播系統中的VCR(Video Cassette Recorder)操作，應采取相應的存儲機制。數據預取機制可以為VCR操作備好所需內容，從而更加充分地利用節點的上行帶寬，有效地減少交互操作時延。
在VMesh中，媒體數據被分成數塊并以分布式的方式保存在多個節點中，這些節點通過結構化覆蓋網絡方式組織起來以支持VCR操作。該方法的性能取決于事先存儲數據的受歡迎程度，因此VMesh是采用基于流行度的段存儲方案。VMesh假設數據塊的流行度符合Zipf分布，把視頻文件劃分為N個數據塊，每個數據塊的播放
3 資源定位機制
資源定位的結果是得到一個資源擁有者的列表，然后請求節點從該列表中選出期望能夠提供良好服務的節點并與之直接連接。在P2P直播系統中，由于各節點的播放時間基本同步，節點間的數據傳輸關系相對穩定，因此，伙伴節點選擇比較容易，通常采用基于Gossip協議的方式進行。基于Gossip協議的內容發現與定位方法不需要維護節點間的邏輯拓撲，但當節點內容更新較快時，通告消息發送頻率低將導致內容定位準確性下降；而通告消息發送頻率高時可能產生較大的控制流量。因此，找到一種較好的資源定位方案是重要的研究內容。類似地，結構化覆蓋網絡方法，如DHT(Distributed Hash Table)機制，可以實現內容的快速查找，但系統動態性較強時結構難以維護。因此，盡管GridMedia系統[8]采用了無結構化網絡結構，但并沒有采用基于Gossip協議的節點發現策略，而是引入了1個集中點服務器RP(Rendezvous Point)來維護覆蓋網中所有節點的信息，它把合適的候選伙伴節點集合返回給需要資源定位的節點。
混合式P2P系統結構指的是在系統選擇一些節點充當系統局部的中心，中心節點的鄰居節點需要向中心節點報告其數據存儲狀態。中心節點相對穩定但并非一直不變，中心節點之間也需要進行一定的數據交換，從而使每個中心節點都可以獲得全局的數據狀態，盡管這個狀態可能不完全準確?；旌鲜较到y結構在完全分布式的系統中引入了一定的結構化，有利于媒體內容的快速檢索，同時又避免了維護固定網絡拓撲的過重負擔?，F有的很多系統為了滿足不同的信息檢索需要采用混合式內容發現策略，其代表為PPLive系統[3]。
4 內容分發
P2P網絡中的絕大多數節點都是對等的，在某些網絡中會設置少量超級節點負責管理局部網絡的事務。每個節點都可能對網絡中的某些內容有興趣，或者其所擁有的內容是其他節點感興趣的。內容分發算法的目標是建立起從源到目標接收點滿足播放質量的分發路徑，下面分別從數據源的數量和數據交換技術二方面對內容分發進行介紹。
4.1 單源和多源分發策略
由于網絡中資源的存放方式不同，分發策略可以分為單源的和多源的策略[9]。它們的數據傳輸方式分別如圖3、圖4所示。
單源分發策略常采用的網絡拓撲結構為樹型結構，基于應用層組播技術，由1個發送者向多個接收者發送數據，接收者有且僅有1個數據源。服務器和所有客戶節點組織成組播樹，組播樹的中間節點接收來自父節點組播的媒體數據，同時將數據以組播的方式傳送給其子節點。如圖3，P2、P6、P7、P8、P9、P10、P11請求同一媒體內容，服務器將其組織成1棵組播樹，P2直接從服務器獲取數據，同時又將數據傳送給它的2個子節點P6和P7。以此類推，P6又把數據傳送給自己的子節點P8和P9，同樣地，P7又把數據傳送給自己的子節點P10和P11。以組播的方式傳輸流媒體，避免了單播C/S服務模式下為每個接收者單獨發送信息的缺點，同時減輕了服務器的負載，節約了網絡資源。但其缺點是，實際部署困難，并且節點的要求較高，如至少能發送1個完整的流媒體流，即上行帶寬要足夠大。此種分發方式的典型代表系統有Promise、CoopNet、SplitStream等。
在實際的網絡環境中，各個節點之間在提供的帶寬、存儲空間以及CPU能力等方面存在著很大的差異。在當前的接入方式中，用戶的上行帶寬通常小于下行帶寬，為了滿足媒體數據播放的時間約束，通常采用如圖2所示的多源發送的數據傳輸方式，以保證提供服務的所有節點出口帶寬之和大于媒體流的編碼速率R。但該類型的數據傳輸方式所帶來的問題在于怎樣選擇合適的發送節點、怎樣協調多個發送節點之間的傳輸速率、如何分配各個發送節點的數據段等。
4.2 數據交換技術
根據媒體流傳輸的驅動端不同，內容分發方式又可以分為：接收端驅動，即“拉數據”；發送端驅動，即“推數據”。所謂“拉數據”，就是節點首先向另一個節點發出請求，另一節點再根據請求發送數據，這不需要節點之間任何層次性的關系，但是節點需要預先知道對方含有的數據；而所謂“推數據”，就是節點主動向另一個節點發送數據，這就需要節點之間有一種父與子的關系，父節點依據這種關系主動發送數據給子節點。
CoolStreaming早期版本中流媒體數據的傳輸是基于接收節點的主動請求，即“拉數據”流傳輸策略。其缺點是將導致每個數據塊傳輸都有一定的延遲，并且節點需要周期性地向鄰居節點發送BM信息和請求，使得網絡流量中控制信息的比重較高，系統的控制開銷增大。為了解決這些問題，Zhang等人設計了一個“推拉結合”的GridMedia[10]系統，將P2P流媒體系統中的數據塊分成二類：一類數據塊只在被請求獲取時才傳播，稱為“拉數據”；另一類數據塊一旦節點收到就立即傳播給鄰居，稱為“推數據”。GridMedia系統主要的設計目標是減少數據傳播時延，它間接地提高了播放連續度。但“推數據”的方法必然帶來相當大的通信開銷，而且也不能從本質上保證高播放連續度。
5 總結與展望
流媒體是今后互聯網上主要應用之一，但傳統的C/S服務模式存在可擴展性問題，使得流媒體技術無法實現大規模的應用。P2P作為一種新型的網絡模型，為流媒體的大規模應用提供了新的解決方案，基于P2P的流媒體服務系統已經引起了許多研究機構以及商業組織的重視。
本文主要對P2P流媒體系統中已有的資源存儲、資源發現、內容分發等關鍵技術進行了詳細的分析介紹，針對上述研究內容，目前P2P流媒體技術需要解決的主要問題有：
(1)如何將整個的視頻進行更加合理地分塊，怎樣根據用戶的行為特征進行數據的存儲，如何進行數據的更新以達到系統的負載均衡。
(2)在高度動態的網絡環境中，如何設計出高效的資源發現算法對P2P流媒體系統來說仍是十分重要的內容；在VOD系統中，如何設計出支持用戶頻繁的VCR操作的資源定位算法，是評價系統優劣的一個重要指標。
??? (3)隨著無線網絡和各種各樣手持設備的出現，無線流媒體的應用也變得越來越重要，尤其是3G解決了接入網的傳輸瓶頸。因此，在無線網絡環境下進行P2P流媒體的研究是一個重要的研究方向。
(4)僅僅依靠上述研究內容還不足以在現實的網絡環境中提供大規模的流媒體服務，還需要對目前的QoS保證機制、激勵機制、容錯機制、可靠性傳輸、安全機制和版權問題等作進一步深入研究。
參考文獻
[1] BHARAMBE A R， HERLEY C， PADMANABHAN V N. Analyzing and improving a bitTorrent network’s performance mMechanisms[C]. In： Proc. of? IEEE INFOCOM’06， 2006.
[2] XIE Su Su， LI Bo， KEUNG G Y， et al. Coolstreaming： design， theory， and practice[C]. In： Proc. of IEEE Transactions on Multimedia， 2007(9)：1661-1671.
[3] HUANG Yan， FU T Z J， CHIU D M， et al. Challenges， design and analysis of a large-scale P2P-VOD system[C]. In： Proc. of SIGCOMM’08， August， 2008.
[4] PPStream(PPS網絡電視).http：//www.ppstream.com， 2008-06.
[5] TRAN D A， HUA K A， Do T T. A peer-to-peer architecture for media streaming[J]. IEEE Journal on Selected Areas in Communications， 2004，22：1-14.
[6] ZHANG Xin Yan， LIU Jiang Chuan， LI Bo， et al. Coolstreaming/DONet： a data-driven overlay network for peer-to-peer live media streaming[C]. In： Proc. of IEEE Infocom，April， 2005.
[7] 楊傳棟，余鎮危，王行剛.混合P2P流媒體的緩存替換算法研究[J].計算機應用研究，2006(11)：71-73.
[8] LI Zhao， LUO Jian Guang， ZHANG Meng， et al. Gridmedia： a practical peer-to-peer based live video streaming system[C]. In： Proc. of IEEE 7th Workshop on Multimedia Signal Processing， 2005：287-290.
[9] 鄭常熠，王新，趙進，等.P2P視頻點播內容分發策略[J]. 軟件學報，2007，18(11)：2942-2954.
[10] 羅建光，張萌，趙黎，等.基于P2P網絡的大規模視頻直播系統[J].軟件學報，2007，18(2)：391-399.