陳璟遠(yuǎn)，朱民耀

(上海大學(xué) 通信與信息工程學(xué)院，上海 200444)

Aspera-fasp技術(shù)在視頻CDN系統(tǒng)中的應(yīng)用與研究

陳璟遠(yuǎn)，朱民耀

(上海大學(xué) 通信與信息工程學(xué)院，上海 200444)

研究、設(shè)計了一個基于HTTP Live Streaming視頻流媒體技術(shù)的視頻直播和點(diǎn)播的CDN系統(tǒng)，并在此基礎(chǔ)上對其進(jìn)行優(yōu)化。目前，傳統(tǒng)的CDN系統(tǒng)雖適用于目前國內(nèi)大部分的網(wǎng)絡(luò)環(huán)境，但在某些極端惡劣的環(huán)境條件下，比如無專線網(wǎng)絡(luò)情況下的跨國數(shù)據(jù)傳輸，還是無法滿足正常的業(yè)務(wù)需求。因此，該設(shè)計引入了Aspera-fasp傳輸技術(shù)，這是一項(xiàng)突破性的傳輸協(xié)議，能充分利用現(xiàn)有的WAN基礎(chǔ)設(shè)施和通用硬件，讓其為傳統(tǒng)的CDN系統(tǒng)提供全球數(shù)據(jù)的快速傳輸。

CDN系統(tǒng)；流媒體；全球數(shù)據(jù)傳輸；Aspera-fasp

近幾年來，隨著國務(wù)院發(fā)布了“寬帶中國”戰(zhàn)略及實(shí)施方案，互聯(lián)網(wǎng)技術(shù)得到了飛速的發(fā)展，其中視音頻業(yè)務(wù)在互聯(lián)網(wǎng)中的應(yīng)用呈爆炸式增長，而傳統(tǒng)電視媒體業(yè)務(wù)像有線電視、廣播電臺正在逐漸淡出人們的視野。CDN技術(shù)便是在這個背景下所衍生出來的，它作為一種提高網(wǎng)絡(luò)內(nèi)容，特別是視頻流媒體內(nèi)容的服務(wù)質(zhì)量、節(jié)省骨干網(wǎng)的服務(wù)帶寬的技術(shù)，在世界各地得到了廣泛的應(yīng)用。

CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)[1]。是通過在現(xiàn)有的 Internet 中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)“邊緣”，使用戶可以就近取得所需的內(nèi)容，解決 Internet 網(wǎng)絡(luò)擁塞狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度，從技術(shù)上全面解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點(diǎn)分布不均，造成的用戶訪問網(wǎng)站響應(yīng)速度慢的問題。

在互聯(lián)網(wǎng)視頻中，節(jié)目的存儲和網(wǎng)絡(luò)帶寬始終是一對矛盾，如果把所有的內(nèi)容都集中在一個地方存儲，這樣雖可降低存儲的成本，但帶寬的成本巨大；如果把所有的內(nèi)容都分布到邊緣，這樣帶寬成本降低，但存儲成本巨大。視頻CDN技術(shù)就是在兩者之間尋找一種平衡。

1 系統(tǒng)架構(gòu)及方案

CDN系統(tǒng)模型的拓?fù)浣Y(jié)構(gòu)采用的是自上而下的樹形結(jié)構(gòu)[2]，最頂層是源服務(wù)器(origin server)，往下為緩存服務(wù)器(cache server)，它可以分為很多級，而真正為用戶提供服務(wù)的緩存服務(wù)器稱為邊緣節(jié)點(diǎn)，邊緣節(jié)點(diǎn)在互聯(lián)網(wǎng)中是離用戶最近的。

在本文設(shè)計的系統(tǒng)總體結(jié)構(gòu)中，采用3層結(jié)構(gòu)，遵循核心集中，節(jié)點(diǎn)分散的異地部署原則，最頂層的源節(jié)點(diǎn)部署于中國上海；第2層區(qū)域?qū)臃謩e位于浙江、江蘇、湖南、福建、四川、遼寧等；第3層邊緣層分別位于臺州、鎮(zhèn)江、益陽、德陽、沈陽等，同時為了全球視頻業(yè)務(wù)的拓展，還加入了加拿大節(jié)點(diǎn)。

1.1 硬件架構(gòu)

系統(tǒng)整體硬件結(jié)構(gòu)可分為3層結(jié)構(gòu)(如圖1所示)。第1層部署在接入電信、聯(lián)通、移動線路的核心機(jī)房，為源節(jié)點(diǎn)。第2層是部署在電信和聯(lián)通網(wǎng)絡(luò)骨干的中間節(jié)點(diǎn)，為區(qū)域中心。第3層是部署在各地的CDN前端節(jié)點(diǎn)，為邊緣節(jié)點(diǎn)，直接為用戶提供視頻的直播和點(diǎn)播服務(wù)。

圖1 系統(tǒng)硬件架構(gòu)圖

1.2 軟件架構(gòu)

系統(tǒng)整體軟件架構(gòu)可分為直播和點(diǎn)播兩部分(如圖2所示)，其中直播軟件架構(gòu)主要負(fù)責(zé)直播頻道的實(shí)時切片、實(shí)時加擾，M3U8實(shí)時更新，節(jié)目的存儲；點(diǎn)播軟件架構(gòu)主要負(fù)責(zé)點(diǎn)播內(nèi)容的管理和快速下發(fā)，實(shí)時MP4封裝轉(zhuǎn)TS封裝格式，M3U8代理。區(qū)域中心和邊緣節(jié)點(diǎn)都是基于nginx開發(fā)搭建的緩存服務(wù)器，主要實(shí)現(xiàn)了文件緩存、反向代理、防盜鏈、流量統(tǒng)計、HLS一次回源、預(yù)測回源等功能[3]。

圖2 系統(tǒng)軟件架構(gòu)圖

1)直播Origin

直播源的所有功能模塊主要分為4部分，基于C/S結(jié)構(gòu)的Live Manager和origin、drmServer和數(shù)據(jù)庫。Live Manager負(fù)責(zé)管理每個origin服務(wù)進(jìn)程和drmServer的狀態(tài)，并把記錄保存在數(shù)據(jù)庫中。

單個origin服務(wù)進(jìn)程的框架結(jié)構(gòu)，基于Tomcat開發(fā)，agent主要負(fù)責(zé)接收來自Live manager的指令來執(zhí)行相應(yīng)的定時任務(wù)，以完成對UDP組播流的切片和打包，其中Package模塊和harmonic模塊的輸出互為主備切換。最終通過nginx完成http server的M3U8和TS的Proxy。

2)點(diǎn)播源

點(diǎn)播源中的主進(jìn)程是基于nginx而開發(fā)的server服務(wù)，接收來自中央CMS的視頻下發(fā)命令和來自下層的客戶請求。其中主要包含MP4 to TS模塊和M3U8代理模塊[4]。前者完成在用戶請求時MP4到TS的動態(tài)封裝轉(zhuǎn)換；后者負(fù)責(zé)解決HLS的一次回源功能[5]，確保每個節(jié)目對SLB的請求次數(shù)為1次。

3)FDN下發(fā)

FDN(Fast Delivery Network)是中央CMS下發(fā)節(jié)目的唯一接口，負(fù)責(zé)點(diǎn)播源的推送，推送完成后通知相關(guān)各地CMS。接口主要包含：Copy，Del，Transcode，Pack，Unpack，Check，Notify，Idle，Complete。各節(jié)點(diǎn)的狀態(tài)有NEW，EXECUTE，READY，DONE，ERROR，SERVERABLE。當(dāng)某個根節(jié)點(diǎn)下的所有子節(jié)點(diǎn)都完成下發(fā)操作后，該節(jié)點(diǎn)該內(nèi)容可以被上線，對外提供服務(wù)。

4)SLB請求調(diào)度

SLB(Service Load Balance)簡單地說就是為服務(wù)器集群分配“工作任務(wù)”，采用恰當(dāng)?shù)恼{(diào)度算法，對于保護(hù)處于后端的Web服務(wù)器來說，非常重要。

當(dāng)某個節(jié)點(diǎn)如果發(fā)生故障時，需要建立一個機(jī)制去保證服務(wù)仍然可用。這里比較常見的容災(zāi)方式，是切換到附近城市節(jié)點(diǎn)。假如系統(tǒng)的天津節(jié)點(diǎn)發(fā)生故障，那么就將網(wǎng)絡(luò)流量切換到附近的北京節(jié)點(diǎn)上?？紤]到負(fù)載均衡，可能需要同時將流量切換到附近的幾個地域節(jié)點(diǎn)。此外，核心節(jié)點(diǎn)自身也需要做到完備的容災(zāi)和備份措施。

過載保護(hù)，指的是一個節(jié)點(diǎn)已經(jīng)達(dá)到最大容量，無法繼續(xù)接受更多請求了，系統(tǒng)必須有一個保護(hù)的機(jī)制。一個服務(wù)已經(jīng)滿負(fù)載，還繼續(xù)接受新的請求，會影響當(dāng)前整個節(jié)點(diǎn)的服務(wù)質(zhì)量。

本系統(tǒng)的容災(zāi)及過載保護(hù)策略有以下3點(diǎn)：

(1)存活性：live=0(節(jié)點(diǎn)癱瘓)，則不提供服務(wù)。

(2)負(fù)載：load>40(節(jié)點(diǎn)CPU負(fù)載超過40%)，則不提供服務(wù)。

(3)流量：網(wǎng)絡(luò)流量超過節(jié)點(diǎn)上限，則調(diào)度權(quán)重下降。

節(jié)點(diǎn)權(quán)重的設(shè)置：首先根據(jù)IP庫確定用戶地區(qū)和運(yùn)營商，優(yōu)先選擇相同運(yùn)營商，默認(rèn)為1?？缡」?jié)點(diǎn)權(quán)重下降1/4，節(jié)點(diǎn)調(diào)度時使用加權(quán)隨機(jī)，備選集合鎖定于同一優(yōu)先級中高于最高權(quán)重1/10以上的節(jié)點(diǎn)；對于權(quán)重低于1×10-15的節(jié)點(diǎn)不選擇其提供服務(wù)。

5)預(yù)測回源

預(yù)測回源功能是為所有邊緣節(jié)點(diǎn)開發(fā)的一個功能模塊，目的是為了在邊緣節(jié)點(diǎn)為用戶提供服務(wù)的同時，預(yù)測用戶的行為，先行用戶一步進(jìn)行回源操作，循環(huán)往復(fù)。那么當(dāng)用戶真正的請求到來時，就避免了Cache未命中的情況發(fā)生，解決了用戶卡頓的現(xiàn)象。

6)統(tǒng)計和報表系統(tǒng)

統(tǒng)計系統(tǒng)通過日志收集服務(wù)器收集所有邊緣節(jié)點(diǎn)的SLB和nginx日志，在統(tǒng)計服務(wù)器上完成對日志的解析，生成CSV文件，將CSV上傳到infobright服務(wù)器入庫。報表系統(tǒng)使用Hadoop對數(shù)據(jù)庫數(shù)據(jù)進(jìn)行二次處理，生成每日的報表并二次入庫。

1.3 系統(tǒng)工作流程

直播系統(tǒng)由于需要考慮視頻直播的實(shí)時性，工作流程由直播Orgin發(fā)起(如圖3所示)，采用PUSH的工作模式，主動向下一層一層將視頻推向距離用戶最近的邊緣節(jié)點(diǎn)。點(diǎn)播系統(tǒng)則采用相對被動的PULL工作模式(如圖4所示)，工作流程由用戶的請求觸發(fā)，一層一層向上拉取視頻節(jié)目，最終回到CDN的源節(jié)點(diǎn)。

圖3 直播系統(tǒng)工作流程圖

圖4 點(diǎn)播系統(tǒng)工作流程圖

2 Aspera-fasp技術(shù)

這是一項(xiàng)突破性傳輸協(xié)議，充分利用現(xiàn)有的WAN基礎(chǔ)設(shè)施和通用硬件，傳輸速度比FTP和HTTP快數(shù)百倍，具有端對端安全性、100%可靠性以及卓越的帶寬控制能力。

fasp是在用戶數(shù)據(jù)報協(xié)議(UDP)之上開發(fā)的應(yīng)用層協(xié)議，在單個數(shù)據(jù)流上實(shí)現(xiàn)了速度最大化。在理論上fasp沒有速率上限，可以完全利用任意速度網(wǎng)絡(luò)的帶寬。

在中國到加拿大的OC-3鏈接上，使用fasp傳輸時速率可以接近155 Mbit/s，在某些情況下可以比TCP快千倍，且其速率具有可預(yù)測性。所以fasp實(shí)現(xiàn)了在高速廣域網(wǎng)上傳輸海量數(shù)據(jù)(和文件大小無關(guān))的高速傳輸。

2.1 性能測試

上?！幽么螅褂胒asp，帶寬100 Mbit/s，平均傳輸速率92 Mbit/s，文件大小1 Gbyte，傳輸時間1分49秒，如圖5所示。

圖5 帶寬100 Mbit/s的fasp傳輸(截圖)

上?！幽么?，HTTP傳輸，帶寬100 Mbit/s，平均傳輸速率0.872 Mbit/s，文件大小1 Gbyte，預(yù)計傳輸時間1小時37分，如圖6所示。

圖6 帶寬100 Mbit/s的HTTP傳輸(截圖)

2.2 系統(tǒng)改進(jìn)

利用fasp在廣域網(wǎng)上數(shù)據(jù)傳輸?shù)淖吭侥芰Γ驹O(shè)計在第二部分實(shí)現(xiàn)的CDN系統(tǒng)基礎(chǔ)上稍作改進(jìn)，如圖7所示，在原有的CDN三層結(jié)構(gòu)的前兩層中增加一層網(wǎng)絡(luò)結(jié)構(gòu)，使用Aspera-fasp技術(shù)進(jìn)行傳輸。該設(shè)計針對跨國數(shù)據(jù)傳輸以及國內(nèi)跨省市，且受南北網(wǎng)絡(luò)運(yùn)營商限制的傳輸，提升效果非常明顯。

圖7 fasp系統(tǒng)改進(jìn)圖

2.3 軟件設(shè)計

1)軟件工作流程

圖8和圖9所示為使用Aspera-fasp服務(wù)節(jié)點(diǎn)的軟件工作流程和框架圖，由于每次請求的M3U8文件大小都較小，故不使用fasp傳輸；僅當(dāng)有視頻請求時，才使用fasp進(jìn)行傳輸。傳輸完成的視頻文件通過Prepost后處理進(jìn)程更新到Cache緩存中去。

圖8 多Job傳輸多文件流程圖

圖9 節(jié)點(diǎn)軟件框架圖

2)示例代碼

每一個的fasp傳輸任務(wù)都依靠一個fasp manager統(tǒng)一執(zhí)行和管理，它提供一套用于Aspera數(shù)據(jù)傳輸?shù)母呒壗涌?，在傳輸過程中提供狀態(tài)分析和進(jìn)度統(tǒng)計。

fasp manager主要接口有：GetInstance，Destroy，LaunchJob，ControlJob，CancelJob，AddSourcePath，AddCallback，GetJobIdList，GetJobStats等。程序如下：

int main( )

{

Aspera：：FaspManager：：JobOrder *job_defn；

Aspera：：FaspManager：：Location *src；

Aspera：：FaspManager：：Location *dst；

Aspera：：FaspManager：：XferParams *xfer_params；

Aspera：：FaspManager：：Manager *manager；

/* Setup the transfer parameters */

xfer_params = new Aspera：：FaspManager：：XferParams( )；

xfer_params->encryption = Aspera：：FaspManager：：ENCRYPT_AES128；

xfer_params->target_rate = TARGET_RATE； /* Transfers never exceed this rate */

xfer_params->min_rate = MIN_RATE；

xfer_params->policy = Aspera：：FaspManager：：POLICY_FAIR；

xfer_params->create_dirs = CREATE_DIRS；

xfer_params->cookie = "my sample cookie"；

xfer_params->resume_check = Aspera：：FaspManager：：RESUME_NONE；

xfer_params->persist = true；

xfer_params->tcp_port = 9999；

/* Setup the job order */

job_defn = new Aspera：：FaspManager：：JobOrder( )；

job_defn->src_location = src；

job_defn->dst_location = dst；

job_defn->xfer_params = xfer_params；

const char* job_id；

/* Setup a callback function */

Aspera：：FaspManager：：CallbackFunctor *callback；

MyCallbackClass *callbackobj = new MyCallbackClass()；

callback = new Aspera：：FaspManager：：CallbackFunctor( callbackobj， &MyCallbackClass：：ReceiveCallback )；

manager = Aspera：：FaspManager：：Manager：：GetInstance()；

manager->SetDebugLevel(1)；

manager->AddGlobalCallback(callback)； // This callback fires for all events for all jobs/sessions

/* Launch the job */

job_id = manager->LaunchJob ( job_defn， callback )； // A callback specified here will only fire for this job

/* Wait for session to start */

while(!callbackobj->isSessionReady())

callbackobj->sleep(1000)；

/* Queue files to be downloaded */

manager->AddSourcePath(job_id， "playtrace.log.2013-01-21"， "playtrace.log.2013-01-21")；

manager->AddSourcePath(job_id， "playtrace.log.2013-01-22"， "playtrace.log.2013-01-22")；

/* Let it run until one file transferred or an error occurs (the session doesn't stop until we tell it to) */

while(callbackobj->getFileTransferCount() != 2)

callbackobj->sleep(1000)；

/* Stop session */

manager->StopPersistentJob(job_id)；

/* Wait for session to stop */

while(callbackobj->isSessionReady())

callbackobj->sleep(1000)；

/* Cleanup and close mgr */

manager->Destroy()；

return 0；

}

3)異常處理機(jī)制

當(dāng)國家級骨干網(wǎng)傳輸發(fā)生故障時，在本系統(tǒng)的網(wǎng)絡(luò)流量監(jiān)控上表現(xiàn)為兩種情況，分別是流量的銳減(通信無法進(jìn)行)和劇增(丟包和重傳)。針對這兩種情況，本軟件有特殊的異常處理機(jī)制，為每個Job都分配一個定時器，將未完成的任務(wù)記錄到一個隊列中，在網(wǎng)絡(luò)環(huán)境恢復(fù)之后進(jìn)行重傳，隊列的淘汰閾值為1天。

2.4 系統(tǒng)性能對比

如表1所示，當(dāng)不使用Aspera-fasp，僅使用普通HTTP進(jìn)行傳輸時，總帶寬為300 Mbit/s時，一片時長為10 s的視頻文件，平均傳輸時間約為10 s，且經(jīng)常出現(xiàn)連接超時及中斷現(xiàn)象。在這種情況下，客戶端無法進(jìn)行流暢的解碼和播放，視頻流媒體會出現(xiàn)嚴(yán)重的卡頓現(xiàn)象，用戶體驗(yàn)極差。而當(dāng)使用Aspera-fasp進(jìn)行傳輸后，如表2和表3所示，在總帶寬分別限制在300 Mbit/s和150 Mbit/s時，一片時長為10 s的視頻文件平均傳輸時間為0.8 s和1.4 s。

表1 HTTP(300 Mbit/s)傳輸情況

文件大小/byte17957761750468128516872051996776110600180686818341281817584傳輸時間/s9937174951437620538125617077216348191829899

表2 Aspera-fasp(300 Mbit/s)傳輸情況

文件大小/byte12577552015583179334317531351067098944921159126720693272128358傳輸時間/s07829100460957191130207479070793085041024116177

表3 Aspera-fasp(150 Mbit/s)傳輸情況

文件大小/byte17967512019720177228619990399783861678312186367917407271891854傳輸時間/s146178155199143012154776103716148900153209149318173169

由圖10可見系統(tǒng)整體性能提升近10倍左右，提升效果十分顯著。無論對視頻直播還是視頻點(diǎn)播，該傳輸質(zhì)量完全可以保證流暢無卡頓的播放，完全滿足全球視頻直播和點(diǎn)播CDN系統(tǒng)的業(yè)務(wù)需求。

圖10 加拿大節(jié)點(diǎn)使用fasp前后性能對比

3 結(jié)論

基于視頻的內(nèi)容分發(fā)技術(shù)是目前在互聯(lián)網(wǎng)上播放視頻的最核心的關(guān)鍵技術(shù)。筆者根據(jù)當(dāng)前國內(nèi)網(wǎng)絡(luò)狀況，為了滿足全球視頻直播和點(diǎn)播的需求，在基礎(chǔ)CDN架構(gòu)的第一、二層之間用軟件實(shí)現(xiàn)了一層基于Aspera-fasp的傳輸層，優(yōu)化了其在廣域網(wǎng)數(shù)據(jù)傳輸上的瓶頸。本文最后給出了Aspera-fasp技術(shù)詳細(xì)的測試報告、前后性能對比。經(jīng)過改善后的CDN系統(tǒng)針對跨國傳輸時的性能提高近10倍，總體帶寬利用率高達(dá)98%，完全滿足了全球視頻直播和點(diǎn)播的CDN系統(tǒng)的業(yè)務(wù)需求。

[1] 梁潔，陳戈. 內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)關(guān)鍵技術(shù)、架構(gòu)與應(yīng)用[M].北京：人民郵電出版社， 2013.

[2] 雷葆華，孫穎.CDN技術(shù)詳解[M].北京：電子工業(yè)出版社， 2012.

[3] 陶輝.深入理解Nginx：模塊開發(fā)與架構(gòu)解析[M].北京：機(jī)械工業(yè)出版社， 2013.

[4] PANTOS R. HTTP live streaming protocol the IETF Internet-draft of the HTTP live streaming specification[EB/OL].[2015-04-12].http：//tools.ietf.org/html/draft-pantos-http-live-streaming.

[5] Apple Inc. HTTP live streaming overview[EB/OL].[2015-04-12].http：//developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html.

Application and Research of Aspera-fasp Technology in Video CDN System

CHEN Jingyuan，ZHU Minyao

(School of Communication & Information Engineering，Shanghai University，Shanghai 200444)

A CDN system for live streaming or video on demand based on the technology of HTTP Live Streaming is designed and implemented， furthermore， it improves and optimizes this system. Although traditional CDN system is suitable for most domestic network environment， but in some extreme environmental conditions， such as cross-border data transmission without dedicated network， or cannot meet the business needs. Therefore， this paper introduces the Aspera-fasp transport technology which is a breakthrough transfer protocol that leverages existing WAN infrastructure and commodity hardware to move the world’s data at maximum speed for the traditional CDN system.

CDN system； streaming media； world’s data transfer； Aspera-fasp

TN948

A

10.16280/j.videoe.2015.20.014

2015-05-22

【本文獻(xiàn)信息】陳璟遠(yuǎn)，朱民耀.Aspera-fasp技術(shù)在視頻CDN系統(tǒng)中的應(yīng)用與研究[J].電視技術(shù),2015，39(18).

陳璟遠(yuǎn)(1989— )，碩士生，主研視頻流媒體技術(shù)；

朱民耀(1965— )，高級工程師，碩士生導(dǎo)師，主研視音頻信號處理。

責(zé)任編輯：時 雯