CDN技術之--流媒體CDN系統的組成

流媒體業務是一種對實時性、連續性、時序性要求非常高的業務，無論從帶寬消耗上還是質量保障上來說，
對best-effort的IP網絡都是一個不小的沖擊

–高帶寬要求
–高QoS要求
–組播、廣播要求（目前IP網絡無法實現端到端的組播業務）

播放一個視頻分為以下四個步驟
–Access
–Demux（音視頻分離）
–Decode(解碼解壓縮)
–Output

RTP、RTCP、RTSP、RTMP的關系：
RTSP協議用來實現遠程播放控制，RTP用來提供時間信息和實現流同步，
RTCP協助RTP完成傳輸質量控制<=（播放控制），
=>（傳輸控制）RTMP和HTTP streaming則是將流同步、播放控制、質量控制集成起來的企業自有流媒體傳送協議
RTMP是adobe的傳輸協議。
RTMP的基本通信單元：消息塊（chunk）和消息（message）
RTMP協議架構在TCP層之上，但RTMP消息並不是直接封裝在TCP中，而是通過一個被稱為消息塊的封裝單元進行傳輸。
消息在網絡上發送之前往往需要分割成多個較小的部分，這樣較小的部分就是消息塊，屬於不同消息流的消息塊可以在網絡上交叉發送。
RTSP/RTP和HTTP streaming是目前應用最廣泛的流化協議，
目前電信運營商在IPTV（特殊通道的基於IP的流媒體播放）的流化上主要以RTSP/RTP技術為主，
而互聯網視頻網站（點播/直播）則多傾向於使用HTTP streaming的流化技術。
HTTP streaming前身是progressive download（漸進式下載：邊下載邊播放，直到下載完）。
HTTP streaming首先會將視頻數據（包括直播的視頻流和點播的視頻文件）在服務器上進行編碼，
然后將編碼后的數據進行更細粒度的分片，再把每個分片通過 HTTP協議傳輸到客戶端。
HTTP streaming的客戶端需要對視頻文件的每個分片都發出一個HTTP請求，
這樣，在視頻播放速度低於下載速度的情況下，
客戶端可以靈活控制HTTP請求的發出速度，從而保證用戶在中途退出時不會出現下載浪費。
另外，因為采用分片的特點，HTTP streaming還可以實現媒體播放過程中的碼率切換（碼率自適應），
結合網絡帶寬資源，為用戶提供更好的體驗。

HTTP streaming                            
支持點播、直播    
可對分片文件加密，保證數字版權    
因為分片傳輸，故支持碼率自適應    

Progressive download
僅支持點播
直接把媒體文件分割成多個小文件分片，無法保障版權所有
只支持固定碼率

HTTP streaming    
基於TCP，更高可靠性，也可以直接利用TCP的流控機制來適應帶寬的變化    
可將播放過的內容保存在客戶端    
使用80端口，能穿越防火牆    
采用標准的HTTP協議來傳輸，只需要標准的HTTP服務器支撐    

RTSP/RTP
基於UDP
不能保存在客戶端
使用特殊端口
需要特殊的流媒體服務器

HTTP streaming的幾個主流陣營：
–3GPP adaptive HTTP Streaming
–Microsoft IIS Smooth Streaming
-Adobe HTTP Dynamic Streaming (HDS)
–Apple HTTP Live Streaming (HLS)

HLS流化技術主要分三個部分：
服務器組件、分發組件和客戶端軟件

–服務器組件主要負責從原始的音視頻設備捕捉相應的音視頻流，並對這些輸入的媒體流進行編碼，
然后進行封裝和分片，最后交付給分發組件來進行傳送；

–分發組件主要負責接收客戶端發送的請求，然后將封裝的流媒體分片文件連同相關的索引文件一起發送給客戶端。
對於沒有采用CDN服務的源服務器，標准的 Web服務器就是一個分發組件，
而對於大型的視頻網站或者類似的大規模應用平台，分發組件還應包括支持RTMP協議的CDN；

–客戶端軟件負責確定應該請求的具體媒體流，下載相關資源，並在下載后通過拼接分片將流媒體重新展現給用戶
HLS音視頻流或流媒體文件在經過編碼、封裝和分片后，變成多個以.ts結尾的分片文件。
流分割器產生的索引文件是以.M3U8為后綴的，用戶可以直接通過Web訪問來獲取
分發組件負責將分片文件和索引文件通過HTTP的方式發送給客戶端，
無須對現有的Web服務器和Cache設備進行額外的擴展、配置和升級
客戶端組件根據URL來獲取這個視頻的索引文件。


索引文件包含了可提供分片文件的具體位置、解密密鑰以及可用的替換流。
HDS，點播內容是通過一個簡單的預編碼生成MP4片段以及Manifest清單文件；
直播的內容准備工作流程相對復雜一點，
在播放的過程中生成MP4.（直播推薦用RTMP，使用FMS推流器）
MPEG-2 TS是指TS格式封裝的、MPEG-2編碼格式的媒體流。大多數IPTV系統使用這種內容源。
H.264這一層完成原始文件的壓縮編碼，TS這一層負責音 視頻的復用以及同步，
RTP這一層負責流的順序傳輸，UDP這一層負責數據包的交付，IP層負責傳輸路由選擇

流媒體加速的回源要求：因為流媒體文件傳送帶寬需求高，而且往往需要維持TCP長連接，
所以一旦CDN回源比例過高，源 站服務器I/O將不堪負荷。

CDN對內容采取分發方式分為pull和push兩種。Pull是被動下拉的方式，push是主動推送的方式。
對於流媒體內容，系統一般會選擇對熱點內容采取push方式的預分發，而普通的網頁內容幾乎100%是pull方式的。
在流媒體CDN系統中，用戶訪問的調度會更多考慮內容命中，主要是因為流媒體內容文件體積大，業務質量要求高，
如果從其他節點拉內容再向用戶提供服務會帶來額外的延遲，影響用戶體驗。
為進一步提高命中率，流媒體CDN系統普遍采用了對熱點內容實施預先push的內容分發策略
在流媒體服務系統中，主要關注的技術是對不同流媒體協議、不同編碼格式、不同播放器、不同業務質量要求等的適應。

流媒體CDN與Web CDN的對比（業務差異）
主要差異點

內容類型
流媒體CDN:大文件、實時流、QoS要求高
Web CDN:小文件、固定大小、QoS要求低

用戶行為
流媒體CDN:拖曳、暫停等播放控制
Web CDN:下載后瀏覽

內容管理
流媒體CDN:內容冷熱度差異明顯（對命中率要求高），內容生命周期長
Web CDN:內容冷熱度差異不明顯，內容生命周期短

回源要求
流媒體CDN:回源比例小
Web CDN:回源比例大

現在已經投入商用的CDN系統，基本都是同時提供Web CDN能力和流媒體CDN能力的，
而且這兩種能力的實現在系統內部幾乎都是互相隔離的，從調度系統到節點設備都沒有交叉互用


流媒體CDN與Web CDN的設計差異（設計差異）
主要差異點    
Cache  
流媒體CDN:支持多種流化協議，硬件配置大存儲、高I/O
Web CDN：支持多協議（HTTP、FTP等）硬件配置小存儲、高性能CPU

負載均衡
流媒體CDN:DNS+HTTP重定向方式
Web CDN:DNS方式

內容分發方式
流媒體CDN：熱片PUSH，冷片PULL
Web CDN：全PULL方式

組網
流媒體CDN：多級組網，可能要求組播、單播混合組網
Web CDN:兩級組網

流媒體CDN的Cache設備與Web Cache無論在軟件實現還是硬件要求上差異都很大，我們很少看到這兩種業務共用同一台設備
當用戶請求的內容在Cache上命中時，Cache直接向用戶提供流服務，此時Cache設備充當流媒體服務器的角色； 當用戶請求內容未能在Cache上命中時，Cache會從上一級Cache（二級緩存設備或中間緩存設備）或者源站服務器獲取內容，再提供給用戶。

Cache在用戶與另一個流媒體服務器之間扮演代理的角色
分布式存儲技術因其大容量、低成本的特點，目前也被業界關注和研究作為流媒體CDN系統的存儲解決方案之一。
常用的分布式存儲技術包括分布式文件系統和分布式數據庫，
由於采用了數據副本冗余（每份數據復制2~3份）、磁盤冗余（Raid1、Raid10、Raid5）等技術，
通常可以提供良好的數據容錯機制，當單台存儲設備斷電或者單個存儲磁盤失效時，整個存儲系統仍能正常工作
負載均衡設備在進行用戶訪問調度時，會綜合考慮很多靜態的、動態的參數，包括IP就近性、連接保持、內容命中、響應速 度、連接數等。
但沒有哪個CDN會考慮所有參數，而是會根據業務特點進行一些取舍，否則均衡系統就太復雜了。
而流媒體CDN在進行用戶訪問調度時，會更多考慮內容命中這一參數

有兩種GSLB實現方式，一種是基於DNS的，一種是基於應用層重定向的
PUSH方式適合內容訪問比較集中的情況，如熱點的影視流媒體內容，PULL方式比較適合內容訪問分散的情況
對使用CDN服務的SP來說，CDN的作用在於盡量就近為用戶提供服務，
幫助SP解決長距離IP傳輸和跨域傳輸帶來的種 種業務質量問題（通過空間換取時間）。
因此，為用戶提供服務的Cache設備一定部署在離用戶比較近的地方。另一方面，CDN的建設者從成本角度考慮，又 不能把所有內容都存放在這些離用戶最近的節點中，這會消耗大量存儲成本，所以這些提供服務的Cache設備會根據需要從源站服務器或者其他Cache獲取 內容。

這樣就形成了CDN網絡分層部署的概念。
從網絡分層上看，Web CDN通常是兩級架構（也有三級架構以減少回源），即中心-邊緣。而流媒體CDN通常有三級以上架構，即中心-區域-邊緣。
產生這種區別的原因在於流媒體 回源成本比較高，源站服務器響應一次流媒體內容回源請求，要比Web內容回源消耗更多資源。
尤其對於流媒體直播業務來說，只要直播節目沒結束，服務器就需 要長時間持續吐流，如果沒有第二層節點作為中繼，那么中心節點的壓力將是不可想象的。

分層部署的方式，對點播業務而言的主要意義是節省存儲成本，對直播業務而言在於減少帶寬成本。
在點播業務中，邊緣Cache只需存儲用戶訪問量大的內容或者內容片斷，其余內容存儲在區域Cache中。
在直播業務中，邊緣Cache從區域中心獲取直播流，而不需要直接向中心節點（源站）獲取，
從而節省了區域中心到中心節點這一段的大部分帶寬。
因為直播流在各個Cache中都不需要占用很大的存儲空間，只需少量緩存空間即可，
所以直播業務方面並不用注重考慮存儲成本
考慮到電信運營商的IP拓撲和流量模型，區域中心Cache通常部署在重點城市的城域網出口的位置，
以保障向各個邊緣 Cache的鏈路通暢。
邊緣Cache的位置選擇則以整個節點能夠提供的並發能力為主要依據，依據業務並發數收斂比，
計算出單個Cache需要覆蓋的用戶 規模，從而選擇一個合適的部署位置。
當然，邊緣Cache離用戶越近，服務質量越好，但覆蓋的用戶數越少，部署成本越高。

內容文件預處理
是指視頻內容進入CDN以后，進入內容分發流程之前，CDN系統對內容進行的一系列處理過程。這個預處理過程的目的有幾個：
–為全網內容管理提供依據，比如對內容進行全網唯一標識，對內容基礎信息進行記錄等
–為提高CDN服務效率或降低系統成本提供手段，比如內容切片
–為滿足業務要求提供能力，比如對同一內容進行多種碼率的轉換以滿足動態帶寬自適應或三屏互動業務要求
視頻轉碼(video transcoding)
– 碼率轉換
–空間分辨率轉換
–時間分辨率轉換
– 編碼格式轉換。編碼格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他編碼格式轉換成H.264

文件切片
是指按照一定的規則把一個完整的文件切成大小一致的若干個小文件；
由於流媒體CDN需要提供的內容體積越來越大，傳統整片存儲帶來的成本消耗超出了CDN服務商的承受范圍；
切片的另一個目的是，使邊緣Cache能夠支持自適應碼率業務
防盜鏈機制和實現
–基於IP的黑白名單
–利用HTTP header的referer字段
–使用動態密鑰（隨機生成的key通過算法生成新的url）
–在內容中插入數據（對有版權內容進行加密（DRM），如Microsoft的playready，Google的Widevine）
–打包下載：在原文件的基礎上進一步封裝，使得資源的hash值改變
備注：隨筆中內容來源於網上資料整理,僅供參考。