[發(fā)明專利]智能內(nèi)容分發(fā)控制裝置及系統(tǒng)

無效

• 申請?zhí)枺?/td>: 201210230723.1
• 申請日: 2012-07-03
• 公開（公告）號: CN102769669A
• 公開（公告）日: 2012-11-07
• 發(fā)明（設(shè)計）人: 陳衡
• 申請（專利權(quán)）人: UT斯達(dá)康通訊有限公司
• 主分類號: H04L29/08
• 分類號: H04L29/08
• 代理公司: 杭州天勤知識產(chǎn)權(quán)代理有限公司 33224
• 代理人: 楊天嬌

技術(shù)領(lǐng)域

本發(fā)明涉及數(shù)據(jù)通信技術(shù)領(lǐng)域，尤其涉及智能內(nèi)容分發(fā)系統(tǒng)。

背景技術(shù)

內(nèi)容分發(fā)系統(tǒng)(Content?Delivery?Network)CDN是常運用在IPTV、IDTV、手機電視、互聯(lián)網(wǎng)電視、視頻網(wǎng)站加速、內(nèi)容下載加速和所有基于IP網(wǎng)絡(luò)的將各種內(nèi)容進(jìn)行注入、推送、用戶出發(fā)拉至靠近用戶邊緣以提升服務(wù)質(zhì)量體驗的一種技術(shù)。現(xiàn)有的內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）通過在現(xiàn)有的Internet中分布式部署服務(wù)節(jié)點，將內(nèi)容分發(fā)到最接近用戶的網(wǎng)絡(luò)“邊緣”，使用戶可以就近取得所需的內(nèi)容并獲取服務(wù)，能提高用戶訪問該內(nèi)容(網(wǎng)站或服務(wù)器)的響應(yīng)速度，減少抖動及丟包，獲得服務(wù)質(zhì)量保證。現(xiàn)有傳統(tǒng)CDN的整體結(jié)構(gòu)如圖1所示，內(nèi)容源將內(nèi)容注入CDN的中心節(jié)點，然后逐級經(jīng)過骨干節(jié)點和邊緣節(jié)點進(jìn)行分發(fā)，直至內(nèi)容交付，中間的傳輸協(xié)議都基本是單一固定的。CDN管理控制器與網(wǎng)絡(luò)中的CDN中心節(jié)點，CDN骨干節(jié)點，CDN邊緣節(jié)點相連，控制內(nèi)容的分發(fā)。同時CDN管理控制器與內(nèi)容源相連，對內(nèi)容的注入進(jìn)行控制。

但目前現(xiàn)有CDN在內(nèi)容傳輸(包括內(nèi)容注入、內(nèi)容分發(fā)和內(nèi)容交付)及控制管理（對內(nèi)容傳輸及服務(wù)的控制管理）兩個層面上存在著以下缺點：

現(xiàn)有CDN的內(nèi)容從內(nèi)容源注入CDN的技術(shù)模式單一，通常受限于內(nèi)容源本身的能力支持程度，僅能以固定傳輸協(xié)議和模式將內(nèi)容注入CDN中固定的中心節(jié)點；CDN的內(nèi)容分發(fā)節(jié)點間內(nèi)容傳輸一般分為系統(tǒng)主動推傳輸（Push）和用戶觸發(fā)拉（Pull）兩類。但無論Push還是Pull，其涉及到的節(jié)點間的內(nèi)容傳輸都采用各自的指定的單一傳輸協(xié)議和模式，一旦傳輸方式選定就難以因應(yīng)實際網(wǎng)絡(luò)環(huán)境和業(yè)務(wù)服務(wù)需求的不同進(jìn)行更改，這限制了分發(fā)傳輸?shù)牟l(fā)性能、穩(wěn)定度，健壯性和適應(yīng)能力；CDN在將內(nèi)容交付至最終用戶端時，其交付使用的傳輸模式取決于用戶端使用的協(xié)議和模式，而現(xiàn)有CDN受限于自身能提供的能力，能提供的交付傳輸協(xié)議和模式有限，因此支持的終端類型有限且難以擴充。

現(xiàn)有CDN的控制管理層功能采用服務(wù)集中式部署，例如常見的CDN內(nèi)容路由、負(fù)載調(diào)度功能模塊GSLB（Gobal?Server?Load?Balance），往往作為CDN的對終端用戶服務(wù)的統(tǒng)一入口。又如常見的CDN元數(shù)據(jù)管理服務(wù)，對接外部內(nèi)容源內(nèi)容管理信令的入口也是集中式部署。這使得傳統(tǒng)CDN雖然在內(nèi)容交付上采用了分布式部署分擔(dān)內(nèi)容流的負(fù)載壓力，而在信令流和控制流上卻容易成為壓力瓶頸或造成延時的性能損失，并存在鏈路和物理設(shè)備上的可靠性容災(zāi)風(fēng)險。

現(xiàn)有CDN的各節(jié)點，在內(nèi)容分發(fā)和內(nèi)容路由時，其結(jié)構(gòu)基本固定，分發(fā)路徑單一，中心節(jié)點、骨干節(jié)點和邊緣節(jié)點的關(guān)系難以改變。缺乏針對不同運營商不同運營需求的內(nèi)容加速方向靈活性。同時CDN的各節(jié)點各設(shè)備間耦合度高，增加、減少和調(diào)整節(jié)點部署困難。

現(xiàn)有的CDN都是專用CDN，或?qū)ｉT提供IPTV業(yè)務(wù)，或?qū)ｉT提供網(wǎng)頁加速業(yè)務(wù)，或?qū)ｉT提供下載緩存業(yè)務(wù)，內(nèi)容交付模式單一。

現(xiàn)有CDN技術(shù)，內(nèi)容注入點和內(nèi)容交付點位置比較固定，不滿足任意點注入、任意點輸出、內(nèi)容交換和UGC等日益迫切的靈活性內(nèi)容出入需求。

現(xiàn)有CDN其各節(jié)點往往需要采用相似的硬件設(shè)備、網(wǎng)絡(luò)和軟件，節(jié)點依靠約定固定的單一協(xié)議和信令進(jìn)行傳輸，傳輸和信令接口在節(jié)點與內(nèi)容源、節(jié)點與節(jié)點、節(jié)點與用戶端之間不統(tǒng)一，缺乏可互通性和可擴展性。

現(xiàn)有技術(shù)中也提出過以內(nèi)容分段切片存儲進(jìn)行傳輸或引入P2P技術(shù)的多源內(nèi)容交互方式來解決現(xiàn)有CDN分發(fā)不靈活的問題，但一方面切片傳輸或P2P傳輸技術(shù)對管理控制的要求更高，另一方面切片與P2P也僅是眾多傳輸模式中的其中一種，有很多特定場合（例如終端或節(jié)點無上行帶寬；網(wǎng)絡(luò)上封鎖了特定端口；網(wǎng)絡(luò)條件不允許上行流量；網(wǎng)絡(luò)中存在明顯的最優(yōu)單點路線；對端設(shè)備指定僅支持某些協(xié)議等）有其他更優(yōu)的選擇。

可見目前現(xiàn)有的各種CDN技術(shù)都無法很好的解決以上提出的各項問題。

發(fā)明內(nèi)容

本發(fā)明針對發(fā)明背景中提到的現(xiàn)有CDN存在的各項問題，提供一種能自動適配多協(xié)議傳輸模式的智能內(nèi)容分發(fā)系統(tǒng)，以使前述各問題得以解決。

本發(fā)明的核心思想是在智能內(nèi)容分發(fā)節(jié)點部署兩個邏輯功能模塊，分別是內(nèi)容管理模塊和內(nèi)容傳輸模塊，所述內(nèi)容管理模塊，負(fù)責(zé)對系統(tǒng)作整體的控制和管理，或更進(jìn)一步的說，其是通過對內(nèi)容傳輸模塊進(jìn)行控制和管理進(jìn)而達(dá)到對整個系統(tǒng)進(jìn)行控制、調(diào)度和管理。所述系統(tǒng)的內(nèi)容傳輸模塊，負(fù)責(zé)提供對內(nèi)容的傳輸和服務(wù)處理能力，其接受同一系統(tǒng)中的的內(nèi)容管理模塊信令管理。