CDN技术之--流媒体CDN系统的组成
流媒體業(yè)務(wù)是一種對(duì)實(shí)時(shí)性、連續(xù)性、時(shí)序性要求非常高的業(yè)務(wù),無論從帶寬消耗上還是質(zhì)量保障上來說,
對(duì)best-effort的IP網(wǎng)絡(luò)都是一個(gè)不小的沖擊
–高帶寬要求
–高QoS要求
–組播、廣播要求(目前IP網(wǎng)絡(luò)無法實(shí)現(xiàn)端到端的組播業(yè)務(wù))
播放一個(gè)視頻分為以下四個(gè)步驟
–Access
–Demux(音視頻分離)
–Decode(解碼解壓縮)
–Output
RTP、RTCP、RTSP、RTMP的關(guān)系:
RTSP協(xié)議用來實(shí)現(xiàn)遠(yuǎn)程播放控制,RTP用來提供時(shí)間信息和實(shí)現(xiàn)流同步,
RTCP協(xié)助RTP完成傳輸質(zhì)量控制<=(播放控制),
=>(傳輸控制)RTMP和HTTP streaming則是將流同步、播放控制、質(zhì)量控制集成起來的企業(yè)自有流媒體傳送協(xié)議
RTMP是adobe的傳輸協(xié)議。
RTMP的基本通信單元:消息塊(chunk)和消息(message)
RTMP協(xié)議架構(gòu)在TCP層之上,但RTMP消息并不是直接封裝在TCP中,而是通過一個(gè)被稱為消息塊的封裝單元進(jìn)行傳輸。
消息在網(wǎng)絡(luò)上發(fā)送之前往往需要分割成多個(gè)較小的部分,這樣較小的部分就是消息塊,屬于不同消息流的消息塊可以在網(wǎng)絡(luò)上交叉發(fā)送。
RTSP/RTP和HTTP streaming是目前應(yīng)用最廣泛的流化協(xié)議,
目前電信運(yùn)營商在IPTV(特殊通道的基于IP的流媒體播放)的流化上主要以RTSP/RTP技術(shù)為主,
而互聯(lián)網(wǎng)視頻網(wǎng)站(點(diǎn)播/直播)則多傾向于使用HTTP streaming的流化技術(shù)。
HTTP streaming前身是progressive download(漸進(jìn)式下載:邊下載邊播放,直到下載完)。
HTTP streaming首先會(huì)將視頻數(shù)據(jù)(包括直播的視頻流和點(diǎn)播的視頻文件)在服務(wù)器上進(jìn)行編碼,
然后將編碼后的數(shù)據(jù)進(jìn)行更細(xì)粒度的分片,再把每個(gè)分片通過 HTTP協(xié)議傳輸?shù)娇蛻舳恕?br />HTTP streaming的客戶端需要對(duì)視頻文件的每個(gè)分片都發(fā)出一個(gè)HTTP請求,
這樣,在視頻播放速度低于下載速度的情況下,
客戶端可以靈活控制HTTP請求的發(fā)出速度,從而保證用戶在中途退出時(shí)不會(huì)出現(xiàn)下載浪費(fèi)。
另外,因?yàn)椴捎梅制奶攸c(diǎn),HTTP streaming還可以實(shí)現(xiàn)媒體播放過程中的碼率切換(碼率自適應(yīng)),
結(jié)合網(wǎng)絡(luò)帶寬資源,為用戶提供更好的體驗(yàn)。
HTTP streaming?? ??????????????????????? ?
支持點(diǎn)播、直播?? ?
可對(duì)分片文件加密,保證數(shù)字版權(quán)?? ?
因?yàn)榉制瑐鬏?#xff0c;故支持碼率自適應(yīng)?? ?
Progressive download
僅支持點(diǎn)播
直接把媒體文件分割成多個(gè)小文件分片,無法保障版權(quán)所有
只支持固定碼率
HTTP streaming?? ?
基于TCP,更高可靠性,也可以直接利用TCP的流控機(jī)制來適應(yīng)帶寬的變化?? ?
可將播放過的內(nèi)容保存在客戶端?? ?
使用80端口,能穿越防火墻?? ?
采用標(biāo)準(zhǔn)的HTTP協(xié)議來傳輸,只需要標(biāo)準(zhǔn)的HTTP服務(wù)器支撐?? ?
RTSP/RTP
基于UDP
不能保存在客戶端
使用特殊端口
需要特殊的流媒體服務(wù)器
HTTP streaming的幾個(gè)主流陣營:
–3GPP adaptive HTTP Streaming
–Microsoft IIS Smooth Streaming
-Adobe HTTP Dynamic Streaming (HDS)
–Apple HTTP Live Streaming (HLS)
HLS流化技術(shù)主要分三個(gè)部分:
服務(wù)器組件、分發(fā)組件和客戶端軟件
–服務(wù)器組件主要負(fù)責(zé)從原始的音視頻設(shè)備捕捉相應(yīng)的音視頻流,并對(duì)這些輸入的媒體流進(jìn)行編碼,
然后進(jìn)行封裝和分片,最后交付給分發(fā)組件來進(jìn)行傳送;
–分發(fā)組件主要負(fù)責(zé)接收客戶端發(fā)送的請求,然后將封裝的流媒體分片文件連同相關(guān)的索引文件一起發(fā)送給客戶端。
對(duì)于沒有采用CDN服務(wù)的源服務(wù)器,標(biāo)準(zhǔn)的 Web服務(wù)器就是一個(gè)分發(fā)組件,
而對(duì)于大型的視頻網(wǎng)站或者類似的大規(guī)模應(yīng)用平臺(tái),分發(fā)組件還應(yīng)包括支持RTMP協(xié)議的CDN;
–客戶端軟件負(fù)責(zé)確定應(yīng)該請求的具體媒體流,下載相關(guān)資源,并在下載后通過拼接分片將流媒體重新展現(xiàn)給用戶
HLS音視頻流或流媒體文件在經(jīng)過編碼、封裝和分片后,變成多個(gè)以.ts結(jié)尾的分片文件。
流分割器產(chǎn)生的索引文件是以.M3U8為后綴的,用戶可以直接通過Web訪問來獲取
分發(fā)組件負(fù)責(zé)將分片文件和索引文件通過HTTP的方式發(fā)送給客戶端,
無須對(duì)現(xiàn)有的Web服務(wù)器和Cache設(shè)備進(jìn)行額外的擴(kuò)展、配置和升級(jí)
客戶端組件根據(jù)URL來獲取這個(gè)視頻的索引文件。
索引文件包含了可提供分片文件的具體位置、解密密鑰以及可用的替換流。
HDS,點(diǎn)播內(nèi)容是通過一個(gè)簡單的預(yù)編碼生成MP4片段以及Manifest清單文件;
直播的內(nèi)容準(zhǔn)備工作流程相對(duì)復(fù)雜一點(diǎn),
在播放的過程中生成MP4.(直播推薦用RTMP,使用FMS推流器)
MPEG-2 TS是指TS格式封裝的、MPEG-2編碼格式的媒體流。大多數(shù)IPTV系統(tǒng)使用這種內(nèi)容源。
H.264這一層完成原始文件的壓縮編碼,TS這一層負(fù)責(zé)音 視頻的復(fù)用以及同步,
RTP這一層負(fù)責(zé)流的順序傳輸,UDP這一層負(fù)責(zé)數(shù)據(jù)包的交付,IP層負(fù)責(zé)傳輸路由選擇
流媒體加速的回源要求:因?yàn)榱髅襟w文件傳送帶寬需求高,而且往往需要維持TCP長連接,
所以一旦CDN回源比例過高,源 站服務(wù)器I/O將不堪負(fù)荷。
CDN對(duì)內(nèi)容采取分發(fā)方式分為pull和push兩種。Pull是被動(dòng)下拉的方式,push是主動(dòng)推送的方式。
對(duì)于流媒體內(nèi)容,系統(tǒng)一般會(huì)選擇對(duì)熱點(diǎn)內(nèi)容采取push方式的預(yù)分發(fā),而普通的網(wǎng)頁內(nèi)容幾乎100%是pull方式的。
在流媒體CDN系統(tǒng)中,用戶訪問的調(diào)度會(huì)更多考慮內(nèi)容命中,主要是因?yàn)榱髅襟w內(nèi)容文件體積大,業(yè)務(wù)質(zhì)量要求高,
如果從其他節(jié)點(diǎn)拉內(nèi)容再向用戶提供服務(wù)會(huì)帶來額外的延遲,影響用戶體驗(yàn)。
為進(jìn)一步提高命中率,流媒體CDN系統(tǒng)普遍采用了對(duì)熱點(diǎn)內(nèi)容實(shí)施預(yù)先push的內(nèi)容分發(fā)策略
在流媒體服務(wù)系統(tǒng)中,主要關(guān)注的技術(shù)是對(duì)不同流媒體協(xié)議、不同編碼格式、不同播放器、不同業(yè)務(wù)質(zhì)量要求等的適應(yīng)。
流媒體CDN與Web CDN的對(duì)比(業(yè)務(wù)差異)
主要差異點(diǎn)
內(nèi)容類型
流媒體CDN:大文件、實(shí)時(shí)流、QoS要求高
Web CDN:小文件、固定大小、QoS要求低
用戶行為
流媒體CDN:拖曳、暫停等播放控制
Web CDN:下載后瀏覽
內(nèi)容管理
流媒體CDN:內(nèi)容冷熱度差異明顯(對(duì)命中率要求高),內(nèi)容生命周期長
Web CDN:內(nèi)容冷熱度差異不明顯,內(nèi)容生命周期短
回源要求
流媒體CDN:回源比例小
Web CDN:回源比例大
現(xiàn)在已經(jīng)投入商用的CDN系統(tǒng),基本都是同時(shí)提供Web CDN能力和流媒體CDN能力的,
而且這兩種能力的實(shí)現(xiàn)在系統(tǒng)內(nèi)部幾乎都是互相隔離的,從調(diào)度系統(tǒng)到節(jié)點(diǎn)設(shè)備都沒有交叉互用
流媒體CDN與Web CDN的設(shè)計(jì)差異(設(shè)計(jì)差異)
主要差異點(diǎn)?? ?
Cache ?
流媒體CDN:支持多種流化協(xié)議,硬件配置大存儲(chǔ)、高I/O
Web CDN:支持多協(xié)議(HTTP、FTP等)硬件配置小存儲(chǔ)、高性能CPU
負(fù)載均衡
流媒體CDN:DNS+HTTP重定向方式
Web CDN:DNS方式
內(nèi)容分發(fā)方式
流媒體CDN:熱片PUSH,冷片PULL
Web CDN:全PULL方式
組網(wǎng)
流媒體CDN:多級(jí)組網(wǎng),可能要求組播、單播混合組網(wǎng)
Web CDN:兩級(jí)組網(wǎng)
流媒體CDN的Cache設(shè)備與Web Cache無論在軟件實(shí)現(xiàn)還是硬件要求上差異都很大,我們很少看到這兩種業(yè)務(wù)共用同一臺(tái)設(shè)備
當(dāng)用戶請求的內(nèi)容在Cache上命中時(shí),Cache直接向用戶提供流服務(wù),此時(shí)Cache設(shè)備充當(dāng)流媒體服務(wù)器的角色; 當(dāng)用戶請求內(nèi)容未能在Cache上命中時(shí),Cache會(huì)從上一級(jí)Cache(二級(jí)緩存設(shè)備或中間緩存設(shè)備)或者源站服務(wù)器獲取內(nèi)容,再提供給用戶。
Cache在用戶與另一個(gè)流媒體服務(wù)器之間扮演代理的角色
分布式存儲(chǔ)技術(shù)因其大容量、低成本的特點(diǎn),目前也被業(yè)界關(guān)注和研究作為流媒體CDN系統(tǒng)的存儲(chǔ)解決方案之一。
常用的分布式存儲(chǔ)技術(shù)包括分布式文件系統(tǒng)和分布式數(shù)據(jù)庫,
由于采用了數(shù)據(jù)副本冗余(每份數(shù)據(jù)復(fù)制2~3份)、磁盤冗余(Raid1、Raid10、Raid5)等技術(shù),
通常可以提供良好的數(shù)據(jù)容錯(cuò)機(jī)制,當(dāng)單臺(tái)存儲(chǔ)設(shè)備斷電或者單個(gè)存儲(chǔ)磁盤失效時(shí),整個(gè)存儲(chǔ)系統(tǒng)仍能正常工作
負(fù)載均衡設(shè)備在進(jìn)行用戶訪問調(diào)度時(shí),會(huì)綜合考慮很多靜態(tài)的、動(dòng)態(tài)的參數(shù),包括IP就近性、連接保持、內(nèi)容命中、響應(yīng)速 度、連接數(shù)等。
但沒有哪個(gè)CDN會(huì)考慮所有參數(shù),而是會(huì)根據(jù)業(yè)務(wù)特點(diǎn)進(jìn)行一些取舍,否則均衡系統(tǒng)就太復(fù)雜了。
而流媒體CDN在進(jìn)行用戶訪問調(diào)度時(shí),會(huì)更多考慮內(nèi)容命中這一參數(shù)
有兩種GSLB實(shí)現(xiàn)方式,一種是基于DNS的,一種是基于應(yīng)用層重定向的
PUSH方式適合內(nèi)容訪問比較集中的情況,如熱點(diǎn)的影視流媒體內(nèi)容,PULL方式比較適合內(nèi)容訪問分散的情況
對(duì)使用CDN服務(wù)的SP來說,CDN的作用在于盡量就近為用戶提供服務(wù),
幫助SP解決長距離IP傳輸和跨域傳輸帶來的種 種業(yè)務(wù)質(zhì)量問題(通過空間換取時(shí)間)。
因此,為用戶提供服務(wù)的Cache設(shè)備一定部署在離用戶比較近的地方。另一方面,CDN的建設(shè)者從成本角度考慮,又 不能把所有內(nèi)容都存放在這些離用戶最近的節(jié)點(diǎn)中,這會(huì)消耗大量存儲(chǔ)成本,所以這些提供服務(wù)的Cache設(shè)備會(huì)根據(jù)需要從源站服務(wù)器或者其他Cache獲取 內(nèi)容。
這樣就形成了CDN網(wǎng)絡(luò)分層部署的概念。
從網(wǎng)絡(luò)分層上看,Web CDN通常是兩級(jí)架構(gòu)(也有三級(jí)架構(gòu)以減少回源),即中心-邊緣。而流媒體CDN通常有三級(jí)以上架構(gòu),即中心-區(qū)域-邊緣。
產(chǎn)生這種區(qū)別的原因在于流媒體 回源成本比較高,源站服務(wù)器響應(yīng)一次流媒體內(nèi)容回源請求,要比Web內(nèi)容回源消耗更多資源。
尤其對(duì)于流媒體直播業(yè)務(wù)來說,只要直播節(jié)目沒結(jié)束,服務(wù)器就需 要長時(shí)間持續(xù)吐流,如果沒有第二層節(jié)點(diǎn)作為中繼,那么中心節(jié)點(diǎn)的壓力將是不可想象的。
分層部署的方式,對(duì)點(diǎn)播業(yè)務(wù)而言的主要意義是節(jié)省存儲(chǔ)成本,對(duì)直播業(yè)務(wù)而言在于減少帶寬成本。
在點(diǎn)播業(yè)務(wù)中,邊緣Cache只需存儲(chǔ)用戶訪問量大的內(nèi)容或者內(nèi)容片斷,其余內(nèi)容存儲(chǔ)在區(qū)域Cache中。
在直播業(yè)務(wù)中,邊緣Cache從區(qū)域中心獲取直播流,而不需要直接向中心節(jié)點(diǎn)(源站)獲取,
從而節(jié)省了區(qū)域中心到中心節(jié)點(diǎn)這一段的大部分帶寬。
因?yàn)橹辈チ髟诟鱾€(gè)Cache中都不需要占用很大的存儲(chǔ)空間,只需少量緩存空間即可,
所以直播業(yè)務(wù)方面并不用注重考慮存儲(chǔ)成本
考慮到電信運(yùn)營商的IP拓?fù)浜土髁磕P?#xff0c;區(qū)域中心Cache通常部署在重點(diǎn)城市的城域網(wǎng)出口的位置,
以保障向各個(gè)邊緣 Cache的鏈路通暢。
邊緣Cache的位置選擇則以整個(gè)節(jié)點(diǎn)能夠提供的并發(fā)能力為主要依據(jù),依據(jù)業(yè)務(wù)并發(fā)數(shù)收斂比,
計(jì)算出單個(gè)Cache需要覆蓋的用戶 規(guī)模,從而選擇一個(gè)合適的部署位置。
當(dāng)然,邊緣Cache離用戶越近,服務(wù)質(zhì)量越好,但覆蓋的用戶數(shù)越少,部署成本越高。
內(nèi)容文件預(yù)處理
是指視頻內(nèi)容進(jìn)入CDN以后,進(jìn)入內(nèi)容分發(fā)流程之前,CDN系統(tǒng)對(duì)內(nèi)容進(jìn)行的一系列處理過程。這個(gè)預(yù)處理過程的目的有幾個(gè):
–為全網(wǎng)內(nèi)容管理提供依據(jù),比如對(duì)內(nèi)容進(jìn)行全網(wǎng)唯一標(biāo)識(shí),對(duì)內(nèi)容基礎(chǔ)信息進(jìn)行記錄等
–為提高CDN服務(wù)效率或降低系統(tǒng)成本提供手段,比如內(nèi)容切片
–為滿足業(yè)務(wù)要求提供能力,比如對(duì)同一內(nèi)容進(jìn)行多種碼率的轉(zhuǎn)換以滿足動(dòng)態(tài)帶寬自適應(yīng)或三屏互動(dòng)業(yè)務(wù)要求
視頻轉(zhuǎn)碼(video transcoding)
– 碼率轉(zhuǎn)換
–空間分辨率轉(zhuǎn)換
–時(shí)間分辨率轉(zhuǎn)換
– 編碼格式轉(zhuǎn)換。編碼格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他編碼格式轉(zhuǎn)換成H.264
文件切片
是指按照一定的規(guī)則把一個(gè)完整的文件切成大小一致的若干個(gè)小文件;
由于流媒體CDN需要提供的內(nèi)容體積越來越大,傳統(tǒng)整片存儲(chǔ)帶來的成本消耗超出了CDN服務(wù)商的承受范圍;
切片的另一個(gè)目的是,使邊緣Cache能夠支持自適應(yīng)碼率業(yè)務(wù)
防盜鏈機(jī)制和實(shí)現(xiàn)
–基于IP的黑白名單
–利用HTTP header的referer字段
–使用動(dòng)態(tài)密鑰(隨機(jī)生成的key通過算法生成新的url)
–在內(nèi)容中插入數(shù)據(jù)(對(duì)有版權(quán)內(nèi)容進(jìn)行加密(DRM),如Microsoft的playready,Google的Widevine)
–打包下載:在原文件的基礎(chǔ)上進(jìn)一步封裝,使得資源的hash值改變
備注:隨筆中內(nèi)容來源于網(wǎng)上資料整理,僅供參考。
轉(zhuǎn)載于:https://www.cnblogs.com/Alanf/p/8072161.html
總結(jié)
以上是生活随笔為你收集整理的CDN技术之--流媒体CDN系统的组成的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Beta阶段发布说明
- 下一篇: bzoj千题计划153:bzoj2431