流媒體業(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ù)浜土髁磕Ｐ?#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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。