不一樣音視頻傳輸協議的對比

1、直播

直播場景一般使用的有hls協議、http-flv漸進式傳輸、RTP協議、DASH協議、RTMP協議，固然還有一些公司本身研發的私有(通常是UDP)協議。此外還有一些較少爲人所知的HDS(adobe出品的與hls/dash匹配的碼率自適應協議HTTP Dynamic Streaming)、SSTR/MSS(微軟出品的碼率自適應協議Smooth Streaming Transport Protocol)

各個協議對比：

協議	傳輸層	客戶端支持	優點	劣勢
hls	HTTP短鏈接	ios/android端及H5原生支持，flash/PC端等須要自研播放器	支持普遍，HTTP請求支持簡單，網絡兼容性好，碼率自適應，服務端及CDN支持好	延時太長，10s以上，單分片文件較小不便存儲
http漸進式傳輸	HTTP長鏈接	flash支持，ios/android/PC端/H5須要自研	延遲相對較小，HTTP請求簡單，網絡兼容性好，服務端及CDN支持好	容易被劫持，多端兼容較爲麻煩
rtp	UDP	Android端支持，其餘各端都須要自研	延遲小	服務端邏輯複雜，協議及控制協議較難理解，開發週期長，客戶端支持很難
dash	HTTP短鏈接	H5原生支持，其餘端須要轉換格式	開放標準支持普遍，碼率自適應	服務端及商業CDN支持不夠，使用不普遍
rtmp	TCP長鏈接	flash支持，其餘須要自研	延遲較小	服務端壓力相對較大，協議較爲複雜，客戶端兼容播放麻煩
私有協議	UDP	徹底須要自研	延遲能夠作到很小，保密性較好，業務自行擴展性高	開發難度極其大，客戶端/協議定義/流服務端及CDN都須要自行開發支持，傳輸可靠性難以保證

多說一句：上面表格中傳輸層一列，並非指該種傳輸方式對應的傳輸層協議（實際上傳輸層應該就是咱們說的UDP/TCP），而是咱們工做場合便於理解，常提到的傳輸和鏈接方式（有的是介於傳輸層和應用層的）。好比HTTP短鏈接和HTTP長鏈接，其實HTTP嚴格來講是基於TCP的應用層協議，但TCP鏈接的通道能夠保持一段時間不關閉，這樣就實現了「所謂的」HTTP長鏈接。實際上對於HTTP而言，就是完成HTTP REQUEST和HTTP RESPONSE，但若是傳輸層的TCP鏈接未斷開，則能夠仍舊在這個通道中繼續request和response。

目前國內互聯網直播使用協議場景：

業務場景	使用協議狀況
web端直播	http-flv,rtmp,hls都有使用。通常若是結合P2P使用，會選擇flv和hls
移動端互動直播	較多使用http-flv，個別廠家使用私有協議
移動端大型直播	較多使用http-flv和hls
web端推流	主要使用rtmp，少數使用rtp
移動端推流	主要使用rtmp，少數使用rtp，個別廠家使用私有協議

我的比較看好dash的發展，標準老是須要統一的嘛，但感受要10年後了。。。

2、點播

點播的協議有hls,DASH,常見的基於http傳輸的mp4和flv,以及部分公司的私有協議。

寫到這裏我忽然以爲confused。網上一大坨都是直接拿mp4/flv和hls並列對比，你說怎麼能把mp四、flv和hls放一塊兒對比呢？感受不對呀！！確實咱們一般是基於http協議來傳輸mp4和flv，但說白了mp4和flv是一種封裝音視頻的標準（是一個盒子），應該對應hls協議裏面的ts/fMp四、DASH的mpd這些嘛，並且咱們也能夠用私有協議來傳輸mp4和flv呀。可是爲了便於理解，咱們沿用這種奇怪的對比方式。

各個協議對比：

協議	傳輸層	客戶端支持	優點	劣勢
mp4	通常http	普遍支持	各類設備及服務端、CDN都通用	文件頭過大且會累積
hls	http	H5/iOS/android原生支持，其餘須要自研	碼率自適應，直播切點播時能夠實時生成	拖拽可能不夠精準，對於超長點播可能分片較多
flv	通常http	flash支持，ios/android/PC端/H5須要自研	格式簡單	多端兼容略微麻煩
dash	http	H5原生支持，其餘須要轉換	碼率自適應，標準規範	服務端及CDN支持不夠，使用不普遍
私有協議	udp	同直播	與直播不一樣的是，更多的結合P2P使用，用於合理利用帶寬	同直播

目前國內一般使用搭配：

• 1).短視頻播放——用整段mp4的較多
• 2).與直播無關的長視頻播放——用分段的mp4/flv較多;也有少數廠家開始使用HLS/DASH，但因爲碼率自適應對客戶端的適配要求以及服務端轉碼要求不低，因此並無被真的普遍使用；有技術積累的廠家會用私有協議傳輸，疊加P2P
• 3).直播生成的回放——用hls較多。由於hls能夠在直播過程當中就轉碼切片生成ts，並且能夠實現直播實時觀看回放（*但這種狀況不適用於互動直播）。固然也能夠考慮使用分段的mp4/flv，可是這樣在直播結束時須要更新最後的文件頭，以及直播轉回放的URI查詢接口，會比較麻煩，也不適用於直播實時觀看回放的場景。

對於mp4和hls，有一種方法能夠結合兩者的優勢，具體見文章MP4大文件虛擬HLS分片技術，避免點播服務器的文件碎片