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份）、磁盤冗餘（Raid一、Raid十、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.26四、MPEG-四、MPEG-二、VC-一、REAL、H.26三、WMV。一般是把其餘編碼格式轉換成H.264

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