基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)和方法
【專利摘要】本發(fā)明公開了一種基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)，包括CDN網(wǎng)絡結構和組內客戶端P2P網(wǎng)絡組結構，所述組內客戶端P2P網(wǎng)絡組結構從所述CDN網(wǎng)絡結構的邊緣緩存節(jié)點獲取緩存資源，所述組內客戶端P2P網(wǎng)絡包括支持WebRTC的客戶端和信令服務器，所述支持WebRTC的客戶端應用了瀏覽器緩存技術。本發(fā)明具有中心數(shù)據(jù)源數(shù)據(jù)多點緩存結構，提高了系統(tǒng)服務能力可靠性。
【專利說明】
基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)和方法
技術領域
[0001] 本發(fā)明設及網(wǎng)絡加速領域，特別設及一種基于WebRTC的流媒體多級緩存網(wǎng)絡加速 系統(tǒng)和方法。
【背景技術】
[0002] 將P2P^eer to Peer)技術引入到CDN系統(tǒng)內，各邊緣自治域內的內容服務器與用 戶的傳輸方式采用P2P方式。然而，P2P網(wǎng)絡拓撲可控性較差，數(shù)據(jù)的流通具有無序性，同時 各客戶節(jié)點又可在任意時刻加入和退出網(wǎng)絡，為系統(tǒng)的穩(wěn)定性帶來了不少挑戰(zhàn)。當其中某 些在P2P組內網(wǎng)絡的用戶突然退出P2P組群的時候，可能在P2P組內網(wǎng)絡流媒體資源會出現(xiàn) 斷層的情況，影響用戶的流媒體資源的下載過程。其中P2P網(wǎng)絡拓撲都是基于(VS架構而建 成的，然而到了流媒體傳輸更加頻繁的瀏覽器系統(tǒng)ΒΛ架構中，就顯得不是那么的常用了。

【發(fā)明內容】

[0003] 本發(fā)明的目的在于克服現(xiàn)有技術的缺點與不足，一種基于WebRTC的流媒體多級緩 存網(wǎng)絡加速系統(tǒng)和方法。
[0004] 本發(fā)明的目的通過如下技術方案實現(xiàn)：
[0005] 一種基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)，包括CDN網(wǎng)絡結構和組內客戶 端P2P網(wǎng)絡組結構，所述組內客戶端P2P網(wǎng)絡組結構從所述CDN網(wǎng)絡結構中緩存資源，所述組 內客戶端P2P網(wǎng)絡包括支持WebRTC的客戶端和信令服務器，所述支持WebRTC的客戶端應用 了瀏覽器緩存技術。
[0006] 所述支持WebRTC的客戶端與所述信令服務器之間通信并實現(xiàn)客戶端之間流媒體 緩存文件互傳都是使用WebRTC通信實現(xiàn)的。
[0007] 所述瀏覽器緩存技術使用的是HTTP協(xié)議定義的緩存機制，在HTTP 1.1中，使用了 (^iche-Control 策略。
[000引本發(fā)明的另一目的通過如下技術方案實現(xiàn)：
[0009] 一種基于WebRTC的流媒體多級緩存網(wǎng)絡加速方法，具體包括W下步驟：
[0010] S1、借助CDN網(wǎng)絡加速服務的優(yōu)勢，搭建一個屬于本發(fā)明的CDN流媒體網(wǎng)絡結構，并 把流媒體資源分發(fā)到資源服務器和邊緣節(jié)點緩存服務器中。
[0011] S2、由于本系統(tǒng)是在基于WebRTC的瀏覽器上運行的，根據(jù)WebRTC網(wǎng)頁實時通信的 特性，WebRTC技術支持客戶端的點對點連接;所W在客戶端連接的時候，引入信令服務器。 使得組內的客戶端可W實現(xiàn)彼此互相連接，在組內實現(xiàn)了客戶端P2P網(wǎng)絡結構。
[0012] S3、由于地理位置相近的多個客戶端很大可能訪問同一個邊緣節(jié)點緩存服務器， 能夠把邊緣節(jié)點緩存服務器和運些客戶端劃分為一個組。
[0013] S4、在共同訪問同一個邊緣節(jié)點緩存服務器的組內的客戶端中，運些客戶端不僅 能夠從邊緣緩存服務器獲取資源，也能夠從組內的其他客戶端獲取資源，W此形成流媒體 資源的第Ξ級緩存。
[0014]本發(fā)明與現(xiàn)有技術相比，具有如下優(yōu)點和有益效果：
[001引1、本發(fā)明大大減少了中屯、節(jié)點數(shù)據(jù)源和邊緣緩存節(jié)點數(shù)據(jù)源的壓力。傳統(tǒng)CDN每 個服務節(jié)點如果要獲得中屯、節(jié)點數(shù)據(jù)源數(shù)據(jù)，均需要直接訪問數(shù)據(jù)源服務器，造成數(shù)據(jù)源 壓力大，消耗帶寬多，造成中屯、到邊緣的數(shù)據(jù)鏈路得不到保障。而通過對CDN服務節(jié)點采用 P2P方式進行組織，節(jié)點之間可W通過P2P方式互相共享、緩存數(shù)據(jù)，大大降低了中屯、數(shù)據(jù)源 的壓力。
[0016] 2、本發(fā)明中屯、數(shù)據(jù)源數(shù)據(jù)多點備份，提高系統(tǒng)服務能力可靠性。不同服務節(jié)點之 間對中屯、數(shù)據(jù)多點備份，運一策略使得CDN系統(tǒng)整體冗余能力、服務的自我恢復能力得W提 高，進一步增強系統(tǒng)穩(wěn)定性。
[0017] 3、本發(fā)明增加可提供服務的節(jié)點數(shù)量，提升服務靈活性。通過P2P方式互相共享、 緩存數(shù)據(jù)，使得可W提供服務的節(jié)點數(shù)量大大增加，同時使得服務節(jié)點的服務更加靈活智 能。
[0018] 4、本發(fā)明增加了系統(tǒng)的可擴展性，提升服務效率。下層內容分發(fā)采用P2P技術實 現(xiàn)，使得系統(tǒng)的可擴展能力大大提高。整體系統(tǒng)具有良好的彈性，應對用戶訪問突發(fā)性、隨 意性的情況，保持良好的服務效率。
[0019] 5、本發(fā)明提高網(wǎng)絡的可管理性，避免流量無序。系統(tǒng)將P2P的范圍嚴格限制在某一 邊緣服務節(jié)點的服務區(qū)域內，避免了傳統(tǒng)P2P技術造成的過多的跨地區(qū)、跨ISP造成骨干網(wǎng) 擁塞、流量無序的問題。增強了網(wǎng)絡的可管理性和服務的可靠性。
【附圖說明】
[0020] 圖1為本發(fā)明所述的基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)結構圖；
[0021] 圖2為圖1所述系統(tǒng)所采用的JSEP的結構示意圖；
[0022] 圖3為圖1所述系統(tǒng)所采用的STUN的搭建位置示意圖；
[0023] 圖4為圖1所述系統(tǒng)所采用的信令服務器和STUN服務器速建立起的P2P網(wǎng)絡結構示 意圖；
[0024] 圖5為圖1所述系統(tǒng)所采用的瀏覽器緩存的執(zhí)行過程流程圖。
【具體實施方式】
[0025] 下面結合實施例及附圖對本發(fā)明作進一步詳細的描述，但本發(fā)明的實施方式不限 于此。
[0026] 本發(fā)明提供一種流媒體多級緩存技術的方法，該方法是：
[0027] 1、借助CDN網(wǎng)絡加速服務的優(yōu)勢，搭建一個屬于本發(fā)明的CDN流媒體網(wǎng)絡結構，并 把流媒體資源分發(fā)到資源服務器和邊緣節(jié)點緩存服務器中。
[00%] 2、由于本系統(tǒng)是在基于WebRTC的瀏覽器上運行的，根據(jù)WebRTC網(wǎng)頁實時通信的特 性，WebRTC技術支持客戶端的點對點連接。所W在客戶端連接的時候，引入信令服務器。使 得組內的客戶端可W實現(xiàn)彼此互相連接，在組內實現(xiàn)了客戶端P2P網(wǎng)絡結構。
[0029] 3、由于地理位置相近的多個客戶端很大可能訪問同一個邊緣節(jié)點緩存服務器，可 W把邊緣節(jié)點緩存服務器和運些客戶端劃分為一個組。
[0030] 4、在共同訪問同一個邊緣節(jié)點緩存服務器的組內的客戶端中，運些客戶端不僅可 w從邊緣緩存服務器獲取資源，也可w從組內的其他客戶端獲取資源，w此形成流媒體資 源的第Ξ級緩存。
[0031] 本發(fā)明提供一種流媒體多級緩存技術的系統(tǒng)，如圖1所示，該系統(tǒng)主要由CDN網(wǎng)絡 結構和組內客戶端P2P網(wǎng)絡組結構組成。
[0032] 其中虛框部分為新添加的服務器一一信令服務器。它的作用是客戶端通過訪問信 令服務器，發(fā)布并交換自己的連接信息，其他客戶端即可通過信令服務器與其建立連接，實 現(xiàn)客戶端之間的互聯(lián)從而建立一個P2P網(wǎng)絡。引入信令服務器之后，客戶端不僅可W從站點 服務器直接獲取資源，也可W從互聯(lián)的其他客戶端上獲取資源，在站點服務器帶寬受限，或 是處理能力下降的情況，依然可W正常的訪問網(wǎng)站服務。
[0033] 通過引入加速服務前后的對比，可知網(wǎng)絡加速服務由如下幾部分構成：
[0034] (1)支持WebRTC的客戶端
[0035] 運里的網(wǎng)絡加速服務是基于WebRTC構建，需要參與的客戶端支持WebRTC。使用 WebRTC的網(wǎng)絡通信部分，可W快速使各個客戶端構成P2P網(wǎng)絡。無論是PC端還是移動端， Firefox和化rome瀏覽器都提供了 WebRTC的大部分支持，所W大部分客戶端不需要任何安 裝就可W使用WebRTC。
[0036] (2)信令服務器
[0037] 使用WebRTC來構建客戶端的P2P網(wǎng)絡，客戶端就需要交換各自的信息才能連接在 一起，運時候就需要信令服務(Signaling)。信令是一個協(xié)調溝通的過程，為了讓客戶端之 間構成會話，客戶端需要交換W下信令信息:發(fā)起和關閉一個通話控制信息;錯誤信息;元 數(shù)據(jù)信息;確保通信安全的密鑰；網(wǎng)絡數(shù)據(jù)(如主機在外網(wǎng)的IP地址和端口）?？蛻舳说男帕?處理需要一種來回傳遞信息的方法，運種機制沒有被WebRTC定義，需要自己創(chuàng)建它。JSEP的 結構如圖2所示：
[0038] JSEP的結構避免了讓瀏覽器保存狀態(tài)信息，如果讓瀏覽器保存信令狀態(tài)，每次當 頁面重載時，信令就會消失。更好的解決方案是用服務器保存信令狀態(tài)，即使用信令服務 器。WebRTC的信令服務器不過多花費內存和進程，只需要轉發(fā)信息和保持很少的會話狀態(tài) 數(shù)據(jù)，所W甚至可W在當前服務器開啟一個進程來負責信令的處理。但是信令機制不僅可 W用來交換會話的元數(shù)據(jù)，也能用來傳送應用數(shù)據(jù)，本質上是一個信息服務，所W運里把它 作為一個單獨的服務器。
[0039] (3)STUN/TURN 服務器
[0040] 信令交互完成后，客戶端就會嘗試直接去連接其他客戶端。在簡單的網(wǎng)絡世界里， 每一個WebRTC客戶端都有一個唯一的地址，運樣可W直接通信，但是實際情況下，大多數(shù)設 備都在一個或多個NAT層后面，使用代理或是防火墻。為了克服真實世界的復雜網(wǎng)絡環(huán)境， 就需要使用STUN服務器來獲取外部網(wǎng)絡地址，或者使用TURN服務器，它在STUN服務器上加 入了中繼功能。STUN的搭建位置如圖3所示：
[0041] STUN服務架設在外網(wǎng)，獲取運行在NAT后面的客戶端的IP和端口，然后返回地址。 STUN的作用就是發(fā)現(xiàn)客戶端的外網(wǎng)IP和端口，之后的執(zhí)行步驟即信令服務的執(zhí)行過程。因 此，STUN服務器不需要存儲太多的內容也不需要做太多的工作，簡單的STUN服務器就可W 應付大量的請求。當單純的STUN無效之后，將會轉向使用TURNdTURN服務器的作用是中繼數(shù) 據(jù)，它負責在兩端間中轉音視頻、數(shù)據(jù)流等，但是不是發(fā)送數(shù)據(jù)。TURN具有公共地址，因此每 個客戶端都可W訪問到(無論是否使用了代理或是防火墻）dTURN任務簡單，但是數(shù)據(jù)中轉 會花費大量帶寬，所WTURN需要足夠強壯。
[0042] 普通使用時，可W使用Google提供的STUN服務器，但是如果作為一款實際應用的 產品，需要自己搭建STUN服務器降低使用第Ξ方服務的風險。
[0043] 由WebRTC客戶端，信令服務器和STUN服務器就可W快速建立起P2P網(wǎng)絡，達到網(wǎng)絡 加速的效果，完整的圖如圖4所示：
[0044] 2)本發(fā)明創(chuàng)造的技術關鍵點
[0045] 其中運個Ξ級緩存結構的Ξ個個關鍵點是，信令服務器、客戶端和瀏覽器緩存技 術。
[0046] (1)支持WebRTC的客戶端
[0047] 運里的網(wǎng)絡加速服務是基于WebRTC構建，需要參與的客戶端支持WebRTC。使用 WebRTC網(wǎng)頁實時通信技術，可W使得客戶端之間相互傳輸流媒體資源。無論是PC端還是移 動端，F(xiàn)irefox和化rome瀏覽器都提供了 WebRTC的大部分支持，所W大部分客戶端不需要任 何安裝就可W使用WebRTC。
[004引（2)信令服務器
[0049] 使用WebRTC來構建客戶端，客戶端之間要建立彼此的連接就需要交換各自的信息 才能形成P2P網(wǎng)絡組，運時候就需要信令服務(Signaling)。信令是一個協(xié)調溝通的過程，為 了讓客戶端之間構成會話，客戶端需要交換W下信令信息:發(fā)起和關閉一個通話控制信息； 錯誤信息;元數(shù)據(jù)信息；確保通信安全的密鑰；網(wǎng)絡數(shù)據(jù)(如主機在外網(wǎng)的IP地址和端口）。 客戶端的信令處理需要一種來回傳遞信息的方法，運種機制沒有被WebRTC定義，需要自己 創(chuàng)建它。
[0050] 在運些客戶端與信令服務器之間通信并實現(xiàn)客戶端之間流媒體緩存文件互傳都 是使用WebRTC通信實現(xiàn)的。WebRTC在應用層面提供了 Ξ個可供調用的API，分別是 Μ e d i a S t r e a m，用來訪問設備的攝像頭及話筒獲得視頻、音頻的同步流； RTCPeerConnection，用于構建點對點之間穩(wěn)定高效的流傳輸；RTCDataChannel，在點對點 之間建立一個低延時、高吞吐的信道，可用來傳輸任意類型數(shù)據(jù)。
[0051] (3)瀏覽器緩存技術
[0052] 在客戶端通信技術完善之后，客戶端緩存即瀏覽器緩存技術變得很重要。瀏覽器 都提供了緩存，緩存訪問過的站點的圖片、文本、腳本文件，甚至可W緩存頁面播放器點播 的視頻文件。瀏覽器的緩存機制使用的是HTTP協(xié)議定義的緩存機制。在HTTP 1.1中，使用了 化che-Control策略。原理是通過指明緩存資源的有效期，來控制瀏覽器是重新向服務器發(fā) 出請求獲取數(shù)據(jù)還是從瀏覽器緩存中讀取數(shù)據(jù)。Cache-Conctrol有多個設置選項，HTTP協(xié) 議頭中化che-Contro 1的可選值如表格所示：
[0化3] 表1
[0化4]
[0055] 字段Last-Modified/If-Modified-Since，Etag/If-None-Match也需要配合 化che-Control使用，關于運四個字段的說明，如表格所示：
[0056] 表2 Γ00571
[0059] 化ag是資源在服務端的唯一標識符，由服務器自動生成，可W更加精準的控制緩 存內容。如果同時使用Last-Modif ied和化ag，服務器會優(yōu)先驗證化ag，當化ag-致，才會對 比Last-Modified。
[0060] 瀏覽器緩存的執(zhí)行過程流程圖如圖5所示。在運些瀏覽器緩存流媒體文件之后，其 瀏覽器之間進行文件互傳使用的協(xié)議是化S化TTP Live Streaming)，HLS是由蘋果公司提 出的基于HTTP的流媒體傳輸協(xié)議。它的工作原理是把整個流拆分成一個個很小的文件，運 個文件是通過HTTP方式下載的，每次不是下載全部分片，而是下載一部分。當流播放時，客 戶端可W選擇從多個不同的源W不同的速率下載同樣的資源，流媒體會話可W適應不同的 數(shù)據(jù)速率。在流播放開始前，客戶端會先下載一個extended M3U playlist文件(m3u8索引 文件），文件包含元數(shù)據(jù)，用于尋找網(wǎng)絡中可用的媒體流。由于HLS只請求HTTP報文，所W很 容易使用CDN來傳輸分發(fā)流媒體，而且與實時傳輸協(xié)議不同，HLS可W穿過任何允許HTTP數(shù) 據(jù)通過的防火墻或是代理服務器。
[0061] 在運種CDN網(wǎng)絡結構下，通過增加邊緣緩存服務器和內部負責調度的DNS，合理地 讓用戶請求到總是距離最近的緩存服務器，運樣有效地減少了中屯、站的的訪問壓力。即使 某個節(jié)點遭遇訪問延遲或是被攻擊，也可W通過冗余節(jié)點，快速響應用戶的請求。由于CDN 的體系結構，它具有本地加速、遠程加速、帶寬優(yōu)化、服務端鏡像和抗攻擊的的特點。其中抗 攻擊的特點是因為CDN運個一個大的集群，廣泛分布且具有智能冗余機制，可W有效地預防 黑客入侵W及各種DDoS攻擊對服務訪問的影響，保證數(shù)據(jù)安全，提供更優(yōu)的服務質量。
[0062] 共享同一個邊緣節(jié)點服務器的組內客戶端P2P網(wǎng)絡組結構。在運個網(wǎng)絡結構中新 添加的服務器一一信令服務器。它的作用是客戶端通過訪問信令服務器，發(fā)布并交換自己 的連接信息，其他客戶端即可通過信令服務器與其建立連接，實現(xiàn)客戶端之間的互聯(lián)。而在 引入信令服務器之后，組內的客戶端可W實現(xiàn)彼此互相連接，在組內實現(xiàn)了 P2P網(wǎng)絡。組內 的客戶端不僅可W從邊緣緩存服務器獲取資源，也可W從組內的其他客戶端獲取資源，通 過利用組內客戶端P2P網(wǎng)絡加速技術與CDN網(wǎng)絡結構融合，形成客戶端流媒體資源的第Ξ級 緩存策略，客戶端就近和多層緩存節(jié)點訪問站點資源，實現(xiàn)流媒體網(wǎng)絡加速服務。在組內客 戶端的P2P網(wǎng)絡中，由于客戶端之間可W互傳資源，在多個客戶端上傳資源時，客戶端下載 幾乎可W達到自身帶寬的最大速度而不受服務器端帶寬的限制。而且在運個組內的P2P網(wǎng) 絡結構中，客戶端可通過訪問信令服務器W此獲得其它客戶端的連接信息，從而合理地選 擇最近的客戶端進行連接。運樣就能減少對邊緣節(jié)點服務器的訪問壓力。
[0063] WebRTC來構建客戶端的P2P網(wǎng)絡實現(xiàn)方式：
[0064] (1)支持WebRTC的客戶端
[0065] 運里的網(wǎng)絡加速服務是基于WebRTC構建，需要參與的客戶端支持WebRTC。使用 WebRTC網(wǎng)頁實時通信技術，可W使得客戶端之間相互傳輸流媒體資源。無論是PC端還是移 動端，F(xiàn)irefox和化rome瀏覽器都提供了 WebRTC的大部分支持，所W大部分客戶端不需要任 何安裝就可W使用WebRTC。
[0066] (2)信令服務器
[0067] 使用WebRTC來構建客戶端，客戶端之間要建立彼此的連接就需要交換各自的信息 才能形成P2P網(wǎng)絡組，運時候就需要信令服務(Signaling)。信令是一個協(xié)調溝通的過程，為 了讓客戶端之間構成會話，客戶端需要交換W下信令信息:發(fā)起和關閉一個通話控制信息； 錯誤信息;元數(shù)據(jù)信息；確保通信安全的密鑰；網(wǎng)絡數(shù)據(jù)(如主機在外網(wǎng)的IP地址和端口）。 客戶端的信令處理需要一種來回傳遞信息的方法，運種機制沒有被WebRTC定義，需要自己 創(chuàng)建它。JSEP的結構如圖2所示:JSEP的結構避免了讓瀏覽器保存狀態(tài)信息，如果讓瀏覽器 保存信令狀態(tài)，每次當頁面重載時，信令就會消失。更好的解決方案是用服務器保存信令狀 態(tài)，即使用信令服務器。WebRTC的信令服務器不過多花費內存和進程，只需要轉發(fā)信息和保 持很少的會話狀態(tài)數(shù)據(jù)，所W甚至可W在當前服務器開啟一個進程來負責信令的處理。但 是信令機制不僅可W用來交換會話的元數(shù)據(jù)，也能用來傳送應用數(shù)據(jù)，本質上是一個信息 服務，所W運里把它作為一個單獨的服務器。
[0068] 上述實施例為本發(fā)明較佳的實施方式，但本發(fā)明的實施方式并不受上述實施例的 限制，其他的任何未背離本發(fā)明的精神實質與原理下所作的改變、修飾、替代、組合、簡化， 均應為等效的置換方式，都包含在本發(fā)明的保護范圍之內。
【主權項】
1. 基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)，其特征在于包括⑶N網(wǎng)絡結構和組內 客戶端P2P網(wǎng)絡組結構，所述組內客戶端P2P網(wǎng)絡組結構從所述CDN網(wǎng)絡結構中緩存資源，所 述組內客戶端P2P網(wǎng)絡包括支持WebRTC的客戶端和信令服務器，所述支持WebRTC的客戶端 應用了瀏覽器緩存技術。2. 根據(jù)權利要求1所述的基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)，其特征在于所 述支持WebRTC的客戶端與所述信令服務器之間通信并實現(xiàn)客戶端之間流媒體緩存文件互 傳都是使用WebRTC通信實現(xiàn)的。3. 根據(jù)權利要求1所述的基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)，其特征在于所 述瀏覽器緩存技術使用的是HTTP協(xié)議定義的緩存機制，在HTTP 1.1中，使用了Cache-Control 策略。4. 基于權利要求1-3所述的基于WebRTC的流媒體多級緩存網(wǎng)絡加速系統(tǒng)的網(wǎng)絡加速方 法，其特征在于具體包括以下步驟： 51、 借助CDN網(wǎng)絡加速服務的優(yōu)勢，搭建一個屬于本發(fā)明的CDN流媒體網(wǎng)絡結構，并把流 媒體資源分發(fā)到資源服務器和邊緣節(jié)點緩存服務器中。 52、 由于本系統(tǒng)是在基于WebRTC的瀏覽器上運行的，根據(jù)WebRTC網(wǎng)頁實時通信的特性， WebRTC技術支持客戶端的點對點連接;所以在客戶端連接的時候，引入信令服務器。使得組 內的客戶端可以實現(xiàn)彼此互相連接，在組內實現(xiàn)了客戶端P2P網(wǎng)絡結構。 53、 由于地理位置相近的多個客戶端很大可能訪問同一個邊緣節(jié)點緩存服務器，能夠 把邊緣節(jié)點緩存服務器和這些客戶端劃分為一個組。 54、 在共同訪問同一個邊緣節(jié)點緩存服務器的組內的客戶端中，這些客戶端不僅能夠 從邊緣緩存服務器獲取資源，也能夠從組內的其他客戶端獲取資源，以此形成流媒體資源 的第三級緩存。
【文檔編號】H04L29/08GK105872044SQ201610190708
【公開日】2016年8月17日
【申請日】2016年3月30日
【發(fā)明人】徐楊, 朱黃華, 張國鵬, 李 東
【申請人】華南理工大學