?

CDN與Cache的技術(shù)特點及融合思路

宋兵

（中國移動通信集團設(shè)計院有限公司安徽分公司，合肥 230041）

摘 要結(jié)合現(xiàn)階段需求，重點分析了CDN與Cache的技術(shù)特點、分散建設(shè)模式下存在問題，并提出了CDN與Cache的融合思路。

關(guān)鍵詞Cache; CDN; 調(diào)度

1　概述

視頻流早已成為互聯(lián)網(wǎng)最主要流量，隨著視頻業(yè)務(wù)高清化及OTT等業(yè)務(wù)的發(fā)展，運營商網(wǎng)絡(luò)壓力越來越大。通過網(wǎng)絡(luò)擴容或部署DPI進行封堵難以解決根本問題，而CDN與Cache可實現(xiàn)將內(nèi)容引入網(wǎng)內(nèi)，并推送至用戶邊緣，這在提高本網(wǎng)率、提升用戶體驗、節(jié)省傳輸帶寬、降低網(wǎng)間流量等方面均可發(fā)揮重要作用。

而當(dāng)各省獨自建設(shè)網(wǎng)絡(luò)時，會缺少對內(nèi)容、管理及調(diào)度上的協(xié)同，CDN與Cache的差異、能否融合以及融合型CDN的建設(shè)思路是本文重點探討的問題。

2　CDN與Cache的技術(shù)比較

2.1 CDN與Cache的技術(shù)特點

CDN可以實現(xiàn)將分散于互聯(lián)網(wǎng)各處的內(nèi)容匯聚于網(wǎng)內(nèi)，并推送至靠近用戶的邊緣節(jié)點，就近為用戶提供服務(wù)。Cache是通過分光或DNS重定向方式截取用戶的正?；ヂ?lián)網(wǎng)訪問需求，根據(jù)用戶的請求熱度對內(nèi)容進行緩存，再次發(fā)起請求時，將用戶的請求重定向至Cache系統(tǒng)，由Cache系統(tǒng)向用戶提供服務(wù)。兩者既有相似也有不同點，從業(yè)務(wù)流程的差異上可比較出兩者的技術(shù)特點。

2.1.1 CDN的業(yè)務(wù)流程

在未使用CDN時，用戶的域名解析請求通過本地DNS定向至源站授權(quán)DNS，授權(quán)DNS將資源的IP地址返回至用戶，用戶向此IP發(fā)起訪問請求。而當(dāng)使用CDN后，源站授權(quán)DNS并不是將資源的IP地址直接返回用戶，而是返回一條CNAME記錄至本地DNS(因與源站的簽約合作關(guān)系，所以源站會這么做)，然后本地DNS定向請求至CDN的流量調(diào)度系統(tǒng)，流量調(diào)度系統(tǒng)負責(zé)將網(wǎng)內(nèi)最優(yōu)的服務(wù)節(jié)點的IP地址返回給用戶。流程如圖1所示。

2.1.2 Cache的業(yè)務(wù)流程

以WebCache為例，解析用戶原始請求，發(fā)送重定向報文引導(dǎo)用戶訪問本地的緩存系統(tǒng)，若已緩存，直接下發(fā)至用戶。若未緩存，下載至緩存系統(tǒng)為用戶提供服務(wù)。 業(yè)務(wù)流程如圖2所示。

（1）用戶發(fā)起對某域名的DNS解析請求；

（2）本地DNS在轉(zhuǎn)發(fā)策略中將需要加速的域名列表指向WebCache的重定向子系統(tǒng)；

（3）重定向子系統(tǒng)將域名解析為緩存子系統(tǒng)IP地址，并返回至用戶；

（4）用戶向緩存子系統(tǒng)IP地址發(fā)起HTTP請求；

（5）緩存子系統(tǒng)根據(jù)請求的URL返回相應(yīng)內(nèi)容。

通過上述流程可看出，CDN方式與源站有關(guān)(源站授權(quán)DNS)，而Cache與源站無關(guān)；CDN適合對簽約內(nèi)容的主動注入，Cache主要實現(xiàn)對熱點資源的被動緩存。

2.2 CDN與Cache的比較分析

目前，兩者在運營商均有大規(guī)模的部署應(yīng)用。結(jié)合技術(shù)特點以及在網(wǎng)絡(luò)中的實際部署情況分析，二者在支持文件類型及分級部署的架構(gòu)上相似，但在業(yè)務(wù)支持、緩存方式、調(diào)度方式以及控制、回源和運營方面存在差異，如表1所示。

3　建設(shè)模式分析

隨著寬帶用戶規(guī)模和網(wǎng)絡(luò)流量的快速增長，各省運營商陸續(xù)進行互聯(lián)網(wǎng)電視CDN、省內(nèi)Cache等相關(guān)平臺的建設(shè)，為本省互聯(lián)網(wǎng)用戶提供加速服務(wù)。在流量本網(wǎng)率的提升方面效果明顯，但也存在一些問題。

表1　CDN與Cache的比較

圖1　CDN的業(yè)務(wù)訪問流程

圖2　WebCache的業(yè)務(wù)訪問流程

3.1 重復(fù)的緩存和回源，增加建設(shè)成本

主要存在CDN與Cache間內(nèi)容的重復(fù)、不同省份間內(nèi)容的重復(fù)。重復(fù)內(nèi)容造成硬件平臺的重復(fù)投資，另外相同內(nèi)容多次回源形成了結(jié)算的增加。

3.2 豎井式發(fā)展，缺乏調(diào)度協(xié)同

省內(nèi)在進行內(nèi)容引入時，在調(diào)度機制上框定了本省的地址范圍，即使相鄰省份的訪問也是被內(nèi)容源站所調(diào)度，往往難以得到最優(yōu)的訪問路徑，即對于A省已引入的資源與B省難以有效共享。此外，多個省份往往與同一個內(nèi)容源站進行簽約合作，這也增加了經(jīng)濟和人力上的重復(fù)開銷。

3.3 規(guī)模效應(yīng)不明顯

因為缺少統(tǒng)一的內(nèi)容管理和調(diào)度機制，難以形成CDN與Cache間、不同省份間資源的協(xié)同，形成龐大的規(guī)模效應(yīng)。

因此，優(yōu)化建設(shè)模式、整合內(nèi)容資源、統(tǒng)一管理和調(diào)度，使內(nèi)容源自全網(wǎng)、服務(wù)于全網(wǎng)，建設(shè)一個融合型CDN已成為發(fā)展趨勢。

4　融合思路建議

4.1 關(guān)鍵問題分析

4.1.1 融合不是取代，兩者將長期共存

CDN面向自有業(yè)務(wù)及簽約互聯(lián)網(wǎng)內(nèi)容，根據(jù)業(yè)務(wù)需求以主動授權(quán)方式進行分發(fā)加速。Cache面向開放的互聯(lián)網(wǎng)內(nèi)容，是非簽約內(nèi)容。CDN主要負責(zé)大型的、服務(wù)流量靠前的內(nèi)容源站以簽約的方式引入。數(shù)百萬計的龐大規(guī)模使得CDN不可能更無必要去完成對所有網(wǎng)站的引入。因此，當(dāng)CDN覆蓋不到時、或新增內(nèi)容CDN來不及覆蓋時，由Cache完成其中的熱點資源的引入。兩者在引入內(nèi)容的范圍上互為補充，而如何實現(xiàn)Cache基于訪問熱度緩存的內(nèi)容與CDN方式下有計劃的引入的內(nèi)容的互斥、如何實現(xiàn)分省引入內(nèi)容的全網(wǎng)服務(wù)和最優(yōu)調(diào)度，便成為兩者存在融合點之所在。CDN建設(shè)初期，與Cache作為網(wǎng)內(nèi)兩種獨立的方式進行流量疏導(dǎo)，當(dāng)簽約內(nèi)容成為網(wǎng)內(nèi)主要流量成份時，Cache的需求將逐步降低，但也不會被替代，兩種將長期共存，共同提供服務(wù)。

4.1.2 管理與調(diào)度的統(tǒng)一，是融合的目標(biāo)

內(nèi)容引入方式、覆蓋范圍不同，CDN和Cache的服務(wù)器節(jié)點將會共存，只是容量上此消彼長而已。那么融合的概念主要體現(xiàn)于管理與調(diào)度等方面的統(tǒng)一。融合時，需要解決的問題主要包括：

（1）統(tǒng)一的調(diào)度、回源、呈現(xiàn)和監(jiān)控；

（2）既能支持全國范圍內(nèi)的運維，又可支持分省的運維；

（3）各省已建CDN和Cache可利舊，各省可自主平滑擴容平臺；

（4）各廠家可協(xié)同建設(shè)，支持統(tǒng)一的規(guī)范及演進思路；

（5）能夠支持自有業(yè)務(wù)和互聯(lián)網(wǎng)業(yè)務(wù)的加速，支持能力的對外開放和運營。

能解決上述問題的系統(tǒng)可稱之為“融合CDN”。

4.1.3 解耦，是實現(xiàn)融合的關(guān)鍵點

對軟件的掌握和開放能力構(gòu)成了對CDN運營的基本要求，要實現(xiàn)對系統(tǒng)的自主掌控必須解耦(包括不同子系統(tǒng)間接口的解耦、軟硬件平臺的解耦)，需由運營商通過制定標(biāo)準(zhǔn)的接口規(guī)范、設(shè)備規(guī)范、技術(shù)要求來實現(xiàn)不同廠商平臺間的對接，承建廠商也應(yīng)在承諾開放接口、支持接口規(guī)范和相關(guān)能力的廠商中選擇。 解耦后的系統(tǒng)架構(gòu)會更清晰，升級、替換、利舊、維護更便捷，可以打破壟斷和縮短建設(shè)周期。

4.2 建設(shè)思路建議

建設(shè)融合型CDN網(wǎng)絡(luò)時，在實現(xiàn)內(nèi)容的管理與調(diào)度、業(yè)務(wù)的快速對接、良好的視頻體驗以及穩(wěn)定易維護等方面需具備解決方案，特別是對已建設(shè)的Cache和CDN需能平滑演進。

4.2.1 統(tǒng)一的內(nèi)容管理和調(diào)度

CDN的簽約內(nèi)容與Cache的熱點內(nèi)容在管理和調(diào)度上需達到協(xié)同，以實現(xiàn)內(nèi)容的精細化運營，建議建設(shè)內(nèi)容資源管理平臺，平臺同步接受來自于CDN、Cache(也包括IDC中直接引入的內(nèi)容)的內(nèi)容視圖，實現(xiàn)對引入的互聯(lián)網(wǎng)內(nèi)容的視圖呈現(xiàn)、統(tǒng)計分析以及智能調(diào)度等功能，并能保證存儲內(nèi)容的互斥。在調(diào)度機制方面，將CDN的簽約內(nèi)容在Cache上設(shè)置為黑名單，由CDN進行調(diào)度。對于非簽約的內(nèi)容由Cache提供服務(wù)，內(nèi)容資源管理平臺輔助參與調(diào)度。如圖3所示。

4.2.2 實現(xiàn)靈活快速的內(nèi)容引入

融合CDN需能支持多種對接模式，適應(yīng)不同的內(nèi)容與業(yè)務(wù)的快速接入。對于非簽約熱點網(wǎng)站，采用透明Cache技術(shù)(網(wǎng)站無需修改)，實現(xiàn)互聯(lián)網(wǎng)網(wǎng)站內(nèi)容的快速引入；對于簽約的政企網(wǎng)站，采用HTTP+URL或者回源接口，對不同網(wǎng)站的URL規(guī)則和參數(shù)進行適配；對于與運營商自營業(yè)務(wù)或互聯(lián)網(wǎng)電視牌照方的對接，采用HTTP+XML接口，通過接口定義完善的交互消息和過程，功能全面且能靈活擴展。

4.2.3 業(yè)務(wù)體驗的保障

融合CDN需能通過多種技術(shù)保障業(yè)務(wù)體驗，尤其是視頻業(yè)務(wù)體驗。在CDN核心節(jié)點內(nèi)容注入與處理上，通過4 k+H.265的組合，在帶寬可控的情況下提供清晰度更高的視頻質(zhì)量。在CDN的邊緣節(jié)點，通過流量整形，避免視頻碼率突發(fā)造成分組丟失，減少對網(wǎng)絡(luò)的需求。在用戶側(cè)，通過FCC、FEC、RET等技術(shù)，縮短頻道切換時間并在丟包產(chǎn)生時進行有效補償。此外，通過分片預(yù)取技術(shù)、TCP單/雙邊加速、快速碼率切換等技術(shù)的引入進一步提升用戶的體驗。

4.2.4 穩(wěn)定可靠，易維護

融合CDN平臺服務(wù)用戶多、網(wǎng)絡(luò)覆蓋廣，必須穩(wěn)定可靠方便維護。穩(wěn)定可靠性方面建議對內(nèi)容庫進行容災(zāi)備份，鏈路方面通過智能路由判斷鏈路健康度并選擇合適路由進行分發(fā)，此外節(jié)點內(nèi)采用服務(wù)器負載均衡技術(shù)避免單機負載過高、采用服務(wù)節(jié)點互助機制保障某節(jié)點故障時可由互助節(jié)點接管服務(wù)。維護方面通過部署探針進行業(yè)務(wù)撥測，監(jiān)控不同節(jié)點間流量情況以定位業(yè)務(wù)故障點。

4.2.5 節(jié)點下沉，實現(xiàn)存儲換帶寬，流量本地化

CDN建設(shè)中應(yīng)根據(jù)承載業(yè)務(wù)和流量規(guī)模逐步向用戶邊緣下沉，初期在省網(wǎng)部署邊緣CDN節(jié)點，隨著業(yè)務(wù)和流量的規(guī)模發(fā)展邊緣節(jié)點下沉至地市節(jié)點，當(dāng)LTE流量爆炸式增長時，可考慮將CDN服務(wù)節(jié)點與無線網(wǎng)絡(luò)（PCC）配合，為重點客戶提供服務(wù)保障。服務(wù)節(jié)點的下沉分為服務(wù)于有線用戶和無線用戶兩種方式，如圖4所示。

4.2.6 對現(xiàn)網(wǎng)平臺的融合建議

建議省網(wǎng)OTT CDN、Cache通過軟件升級支持與全網(wǎng)CDN的互聯(lián)互通，各省CDN與Cache作為服務(wù)節(jié)點為各省用戶提供加速服務(wù)，定時上傳用戶訪問日志并可支持全局報表的展示；在調(diào)度、回源層面通過智能DNS系統(tǒng)進行全局調(diào)度和回源控制；在運營與管理層面，通過數(shù)據(jù)分析平臺進行報表展現(xiàn)，運營系統(tǒng)實現(xiàn)支持B2B操作。

融合時，建議分階段實施，先完成縱向互聯(lián)、再進行橫向協(xié)同、最后實現(xiàn)內(nèi)容的融合：

（1）第一階段，實現(xiàn)省級節(jié)點與全網(wǎng)節(jié)點的縱向互聯(lián)，Cache與CDN各自實現(xiàn)全網(wǎng)的統(tǒng)一回源。

圖3　內(nèi)容的統(tǒng)一管理和調(diào)度組網(wǎng)示意圖

（2）第二階段，實現(xiàn)系統(tǒng)間的橫向協(xié)同，完成內(nèi)容的統(tǒng)一管理，CDN分發(fā)內(nèi)容Cache不再緩存，完成CDN全網(wǎng)統(tǒng)一的調(diào)度能力，并實現(xiàn)報表和管理的統(tǒng)一。

（3）第三階段，打開一級Cache與CDN內(nèi)容中心的接口，將Cache內(nèi)容注入CDN。省公司層面實現(xiàn)省內(nèi)Cache的內(nèi)容注入CDN省內(nèi)服務(wù)節(jié)點。使得更多的Cache中緩存的內(nèi)容能夠被CDN所調(diào)度，提供更好的全網(wǎng)服務(wù)。

5　結(jié)束語

對運營商而言，CDN身兼多重價值?？梢詫崿F(xiàn)以提升網(wǎng)內(nèi)用戶互聯(lián)網(wǎng)感知為目標(biāo)，滿足管道業(yè)務(wù)發(fā)展需要；以提升運營商自營業(yè)務(wù)體驗為目標(biāo)，滿足自營業(yè)務(wù)發(fā)展需要。除此之外，CDN還可以成為拓展IDC營收能力的重要增值業(yè)務(wù)，為客戶提供分發(fā)加速服務(wù)。再往后，隨著技術(shù)的成熟，CDN可結(jié)合SDN技術(shù)進行更精確有效的用戶訪問調(diào)度和流量管理，實現(xiàn)其承載路徑的優(yōu)化，進一步提升內(nèi)容分發(fā)的質(zhì)量?？傊?，現(xiàn)階段做好Cache與CDN的融合非常重要。

圖4　CDN服務(wù)節(jié)點下沉思路

Technical features and integration ideas of CDN and Cache

SONG Bing

(China Mobile Group Design Institute Co., Ltd. Anhui Branch, Hefei 230041, China)

AbstractCombined with the present stage based on demand, this paper focuses on the analysis of technical characteristics, CDN and Cache dispersion construction mode existing problems, and puts forward the integration of CDN and Cache.

KeywordsCache; CDN; scheduling

收稿日期：2014-08-20

文章編號1008-5599（2015）01-0073-05

文獻標(biāo)識碼A

中圖分類號TN915