前言:
網路視訊直播存在已有很長一段時間，隨著移動上下行頻寬提升及資費的下調，
視訊直播被賦予了更多娛樂和社交的屬性，人們享受隨時隨地進行直播和觀看，
直播的開啟時間和延遲變成了影響產品功能發展重要指標。

注：本文是以原文為主體，加上我自己的一些總結和補充寫的

那麼，問題來了：
如何實現低延遲、秒開的直播？

先來看看視訊直播的5個關鍵的流程：
錄製->編碼->網路傳輸->解碼->播放，

每個環節對於直播的延遲都會產生不同程度的影響。
這裡重點分析移動裝置的情況。
受限於技術的成熟度、硬體環境等，我們針對移動場景簡單總結出直播延遲優化的4個點：
網路、協議、編解碼、移動終端，
並將分四大塊來一一解密UCloud直播雲實現低延遲、秒開的技術細節。

一、UCloud直播雲實現接入網路優化的技術細節：

1）全域性負載均衡-就近接入

實現就近接入的技術比較廣為人知，就是CDN即Content Delivery Network （內容分發網路）。
CDN包含兩大核心技術：
負載均衡和分發網路。

隨著10多年的演進，對負載均衡和分發的實現方式已多種多樣，
分發網路的構建策略通常是經過日積月累的總結出一套最合適的分發路由，
並且也不是一成不變，需時刻關注調整，動態運營。
這裡重點介紹下CDN的負載均衡技術。
負載均衡是如何實現讓使用者就近訪問的呢？
比較普遍的實現方式：通過使用者使用的DNS伺服器來判斷客戶端所在的網路位置，
從而返回對應的服務IP。
如下圖示例:

Fig-2
廣東電信使用者IP:1.1.1.1 需要看一個直播http://www.ucloud.cn/helloworld.flv ，
實現就近訪問的過程是：

S1. 使用者向配置的DNS伺服器1.1.1.0
(通常是運營商指定，也稱local DNS，後面簡稱Ldns)發起www.ucloud.cn 的查詢；
S2. Ldns 上沒有該域名的記錄，則往頂級即Root NS上發起查詢；
S3. Root NS返回告知Ldns該域名的權威解析記錄在UCloud NS上；
S4. Ldns 向UCloud NS發起查詢；
S5. UCloud NS 向UCloud GSLB服務發起查詢，GSLB發現 Ldns1.1.1.0是屬於廣東電信；

S6. 返回廣東電信的就近節節點IP1.1.1.2；
S7. 返回1.1.1.2給Ldns；
S8. 返回給使用者1.1.1.2，使用者到1.1.1.2上去獲取直播內容。

鏈路很長，
但是每個Ldns上都會對查詢過的域名做合理的快取，
下一個廣東電信的使用者再來查詢的時候就可以直接返回1.1.1.2。
架構並不複雜，關鍵點是如何知道Ldns是位於廣東電信，這就涉及一個IP地址庫。
有開源地址庫，也有商業地址庫，可以按需求採購即可，一般一年1萬左右。
例如，淘寶的IP地址庫
淘寶官方ip地址庫 http://ip.taobao.com/
介面說明
1. 請求介面（GET）：
http://ip.taobao.com/service/getIpInfo.php?ip=[ip地址字串]
2. 響應資訊：
（json格式的）國家、省（自治區或直轄市）、市（縣）、運營商
3. 返回資料格式：
{"code":0,"data":{"ip":"210.75.225.254","country":"\u4e2d\u56fd","area":"\u534e\u5317",
"region":"\u5317\u4eac\u5e02","city":"\u5317\u4eac\u5e02","county":"","isp":"\u7535\u4fe1",
"country_id":"86","area_id":"100000","region_id":"110000","city_id":"110000",
"county_id":"-1","isp_id":"100017"}}
其中code的值的含義為，0：成功，1：失敗。

這裡不難看出來，排程的準確度是完全依賴使用者配置的Ldns，
而這些Ldns大多數是省級別的，即GLSB只知道使用者是廣東電信，
但是常常分不出來是廣東廣州電信，還是廣東深圳電信。

HTTPDNS就是實現更精準的排程一種方式：

Fig-3
S1. 使用者1.1.1.1通過HTTP協議直接向UCloud NS請求直播域名www.ucloud.cn；
S2. UCloud NS發現使用者IP1.1.1.1屬於廣東深圳電信；
S3. 返回廣東深圳電信節點1.1.1.11給UCloud NS；
S4. 返回給使用者。

HTTPDNS的好處顯而易見：
一可精準獲得使用者端的IP，有效避免使用者配錯Ldns（有時是網路中心配錯DNS）的情況，
可更精準定位使用者所在網路位置。
二可避免DNS解析劫持。

2）BGP中轉架構-最短傳輸路徑

BGP即Border Gateway Protocol （邊界閘道器協議），業內簡稱BGP。
為什麼BGP中轉架構對直播加速和分發如此重要？
不得不提國內複雜的網路狀況，較廣為人知的是“南電信北聯通”的寬頻使用者分佈。
那一個簡單的問題，電信主播發起了直播，聯通的使用者想看怎麼辦呢？
從結構上講，肯定是有有限個電信聯通兩個運營商的交匯點，相當於資訊橋樑。
這就會帶來兩個問題：
1、路程要繞遠，網路延遲高且不穩定；
2、高峰期擁堵，導致直播流卡頓。
BGP的技術原理往簡單的說就是允許同一IP在不同網路中廣播不同的路由資訊，
效果就是同一個IP，當電信使用者來訪問時走電信網內的路由，
聯通使用者來訪問時走的聯通的路由。
所以BGP技術對跨運營商的訪問帶來了巨大的便利，特別是直播場景。
不同於傳統的檔案快取場景，一個圖片哪怕第一次是跨了遙遠的距離從源站獲取後，
本地網路進行快取，後面的訪問都走本地網路。
直播加速是流式的，並且當要做到低延遲的時候，中間的快取要儘可能少。
BGP相當於給跨網的使用者就近搭建了一坐橋樑，不必繞遠路，延時和穩定性都大大提高了。

Fig-4
技術原理部分介紹完了，那麼它對直播延遲影響有多少改善呢？
首先這裡的就近，不一定是物理距離近，不考慮瞬時負載情況下，
更多是指測速延時最優的機房。
在國內一般而言相同的接入運營商（電信、聯通、移動）
並且地理位置最近的情況網路延遲最優，小於15ms。
跨省同運營商的網路延遲25~50ms，
跨運營商情況更復雜一些，在50~100ms。
總結起來，直播當中每個包的延時可以縮短100ms，
由於網路的疊加效果，反射到上層是秒級的延遲縮減。

【總結】
所以，網路部分的優化是兩點:
1. 使用自己的HTTPDNS，換句話說，就是要搭建自己的快速高併發的排程系統；
2. 使用BGP機房；

二、直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析

直播協議的選擇
國內常見公開的直播協議有幾個：RTMP、HLS、HDL（HTTP-FLV）、RTP，
我們來逐一介紹。
RTMP協議：
是Adobe的專利協議，現在大部分國外的CDN已不支援。
在國內流行度很高。原因有幾個方面：
1、開源軟體和開源庫的支援穩定完整。
如鬥魚主播常用的OBS軟體，開源的librtmp庫，服務端有nginx-rtmp外掛。
2、播放端安裝率高。
只要瀏覽器支援FlashPlayer就能非常簡易的播放RTMP的直播，
協議詳解可以Google瞭解。
相對其他協議而言，RTMP協議初次建立連線的時候握手過程過於複雜
（底層基於TCP，這裡說的是RTMP協議本身的互動），
視不同的網路狀況會帶來給首開帶來100ms以上的延遲。
基於RTMP的直播一般內容延遲在2~5秒。

Fig-5

HTTP-FLV協議：
即使用HTTP協議流式的傳輸媒體內容。
相對於RTMP，HTTP更簡單和廣為人知，而且不擔心被Adobe的專利綁架。
內容延遲同樣可以做到2~5秒，開啟速度更快，因為HTTP本身沒有複雜的狀態互動。
所以從延遲角度來看，HTTP-FLV要優於RTMP。

HLS 協議：
即Http Live Streaming，是由蘋果提出基於HTTP的流媒體傳輸協議。
HLS有一個非常大的優點：HTML5可以直接開啟播放；
這個意味著可以把一個直播連結通過微信等轉發分享，
不需要安裝任何獨立的APP，有瀏覽器即可，所以流行度很高。
社交直播APP，HLS可以說是剛需，下來我們分析下其原理。
基於HLS的直播流URL是一個m3u8的檔案，
裡面包含了最近若干個小視訊TS（一種視訊封裝格式，這裡就不擴充套件介紹）檔案，
如 http://www.ucloud.cn/helloworld.m3u8 是一個直播留連結，
其內容如下：

假設列表裡面的包含5個TS檔案，每個TS檔案包含5秒的視訊內容，
那麼整體的延遲就是25秒。
當然可以縮短列表的長度和單個TS檔案的大小來降低延遲，
極致來說可以縮減列表長度為1，1秒內容的m3u8檔案，
但是極易受網路波動影響造成卡頓。
通過公網的驗證，目前按同城網路可以做到比較好的效果是5~7秒的延遲，
也是綜合流暢度和內容延遲的結果。
那麼HTML5是否可以有更低延遲直接開啟的直播流技術呢？我們在最後會探討這個問題。

RTP協議：
即Real-time Transport Protocol，用於Internet上針對多媒體資料流的一種傳輸層協議。
實際應用場景下經常需要RTCP（RTP Control Protocol）配合來使用，
可以簡單理解為RTCP傳輸互動控制的信令，RTP傳輸實際的媒體資料。
RTP在視訊監控、視訊會議、IP電話上有廣泛的應用，
因為視訊會議、IP電話的一個重要的使用體驗：內容實時性強。
對比與上述3種或實際是2種協議，
RTP和它們有一個重要的區別就是預設是使用UDP協議來傳輸資料，
而RTMP和HTTP是基於TCP協議傳輸。

為什麼UDP 能做到如此實時的效果呢？
關於TCP和UDP差別的分析文章一搜一大把，這裡不在贅述，簡單概括：
UDP：單個數據報，不用建立連線，簡單，不可靠，會丟包，會亂序；
TCP：流式，需要建立連線，複雜，可靠，有序。
實時音視訊流的場景不需要可靠保障，因此也不需要有重傳的機制，
實時的看到影象聲音，網路抖動時丟了一些內容，畫面模糊和花屏，完全不重要。
TCP為了重傳會造成延遲與不同步，如某一截內容因為重傳，導致1秒以後才到，
那麼整個對話就延遲了1秒，隨著網路抖動，延遲還會增加成2秒、3秒，
如果客戶端播放是不加以處理將嚴重影響直播的體驗。

總結一下：
在直播協議的選擇中，如果選擇是RTMP或HTTP-FLV則意味著有2~5秒的內容延遲，
但是就開啟延遲來看，HTTP-FLV 要優於RTMP。
HLS則有5~7秒的內容延遲。
選擇RTP進行直播則可以做到1秒內的直播延遲。
但就目前所瞭解，各大CDN廠商沒有支援基於RTP直播的，
所以目前國內主流還是RTMP或HTTP-FLV。

是否有除了HLS外更低延遲的方案？
HLS的優點點是顯而易見的：移動端無需安裝APP使用相容HTML5的瀏覽器開啟即可觀看，
所有主流的移動端瀏覽器基本都支援HTML5，在直播的傳播和體驗上有巨大的優勢。

而看起來唯一的缺點：
內容延遲高
（這裡也有很多HLS限制沒有提到，比如必須是H264 AAC編碼，也可認為是“缺點”之一）。
如果能得到解決，那將會是直播技術非常大的一個進步。
或者換個說法，有沒有更低延遲可直接用連結傳播的直播方案？
不侷限於HLS本身。
對於瀏覽器直接的視訊互動，Google一直在推WebRTC，目前已有不少成型的產品出現，
可以瀏覽器開啟即實時對話、直播。但來看看如下的瀏覽器覆蓋圖：

非常遺憾的說，在直至iOS 9.3上的Safari仍然不能支援WebRTC。
繼續我們的探索，那Websocket支援度如何呢？

除了老而不化的Opera Mini外，所有的瀏覽器都支援WebSocket。
這似乎是個好訊息。
如果採用HTML5 WebSocket來做直播，
那我們先來梳理一下HTML5 WebSocket直播需要解決的問題：
1、後端相容
2、傳輸
3、解碼播放
對於
#1似乎不是特別大問題，對於做過RTMP轉HLS、RTP來說是基本功。
#2對於瀏覽器來說使用HTTP來傳輸是比較好的選項。
對於#3 這裡推薦一個開源的JS解碼專案jsmpeg: https://github.com/phoboslab/jsmpeg，
裡面已有一個用於直播的stream-server.js的NodeJS伺服器。
從測試結果看，該專案的程式碼相對較薄，還沒達到工業級的成熟度，
需要大規模應用估計需要自填不少坑，有興趣的同學可以學習研究。

以上就是直播雲：直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析。
關於接入網路優化、內容快取與傳輸策略優化、終端優化，請參閱接下來發布的其他部分。

【我的總結】
1. 以延時從低到高來看，協議上方案選擇為:
RTP/UDP: 可以做到秒內延時，目前國內的CDN都不支援，
但有些公司開發了私有協議實現了基於它們的直播，而且它們的延時都小於1秒，
甚至小於500ms, 像YY，映客直播採用的第三方技術等；
webRTC: 可以做到秒內延時，實際上它也是使用的RTP，
單列出來是因為它是Google開源出來的，目前社群也開始活躍，做的人也多了；
依據它出服務的公司國內有聲網，中國電信研究院等；
HTTP-FLV: 內容延遲可以做到2~5秒，開啟快；
RTMP: 內容延遲可以做2~5秒，當網路不好造成重傳時，延時會大量增加；
HTML5 WebSocket: 方案還不成熟，延時可能也會在2~5秒；
HLS: 有5~7秒的內容延遲

三、在傳輸直播流媒體過程中的內容快取與傳輸策略優化細節原理

基礎知識：I幀、B幀、P幀
I幀表示關鍵幀。
你可以理解為這一幀畫面的完整保留；解碼時只需要本幀資料就可以完成。
（因為包含完整畫面）
P幀表示這一幀跟之前的一個關鍵幀（或P幀）的差別。
解碼時需要用之前快取的畫面疊加上本幀定義的差別，生成最終畫面。
（也就是差別幀，P幀沒有完整畫面資料，只有與前一幀的畫面差別的資料）
B幀是雙向差別幀。
B幀記錄的是本幀與前後幀的差別（具體比較複雜，有4種情況）。
換言之，要解碼B幀，不僅要取得之前的快取畫面，還要解碼之後的畫面，
通過前後畫面的與本幀資料的疊加取得最終的畫面。
B幀壓縮率高，但是編解碼時會比較耗費CPU，而且在直播中可能會增加直播延時，
因此在移動端上一般不使用B幀。

Fig-6

關鍵幀快取策略
一個典型的視訊幀序列為IBBPBBPBBP……
對於直播而言，為了減少直播的延時，通常在編碼時不使用B幀。
P幀B幀對於I幀都有直接或者間接的依賴關係，
所以播放器要解碼一個視訊幀序列，並進行播放，必須首先解碼出I幀，
其後續的B幀和P幀才能進行解碼，

關於直播，所有的技術細節都在這裡了

一、UCloud直播雲實現接入網路優化的技術細節：

1）全域性負載均衡-就近接入

2）BGP中轉架構-最短傳輸路徑

二、直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析

三、在傳輸直播流媒體過程中的內容快取與傳輸策略優化細節原理

關於直播，所有的技術細節都在這裡了

關於直播的技術細節都在這裡

asa的nat配置，所有的情況都在這裏了

2019年一半已過，這些大前端技術你都GET了嗎？- 上篇

2019年一半已過，這些大前端技術你都GET了嗎？- 下篇

愛創課堂每日一題第五十七天-一個頁面從輸入 URL 到頁面加載顯示完成，這個過程中都發生了什麽？

使用Junit測試一個 spring靜態工廠實例化bean 的例子，所有代碼都沒有問題，但是出現java.lang.IllegalArgumentException異常

#一年一度的程式設計師節，看看IT公司都送了啥禮物？

周志華等提出RNN可解釋性方法，看看RNN內部都幹了些什麼

遊戲背景音樂的市場，看看你就都明白了

自從學會線上PDF轉PPT，PPT模板庫都滿了！

Java經典題丨猴子吃桃問題：猴子第一天摘下若干個桃子，當即吃了一半，還不癮，又多吃了一個第二天早上又將剩下的桃子吃掉一半，又多吃了一個，以後每天早上都吃了前一天剩下的一半零一個。

天一冷，程式設計師就都換上了格子衫

分享10個給Python小白看的實用案例，入門Python就在這裡了

做java的你，這些英文單詞都掌握了嗎？

劍指Offer演算法題JAVA版21-30題（全是個人寫的非官方，只供參考和自己複習，測試用例都通過了。）

無線網網速不給力，這些操作你都試了嗎？

貓大叫一聲，所有的老鼠都開始逃跑，主人被驚醒

Python爬取鬥魚的彈幕，看看奇葩網友都說了些什麽

Python爬取鬥魚的彈幕，看看奇葩網友都說了些什麼

關於直播，所有的技術細節都在這裡了

一、UCloud直播雲實現接入網路優化的技術細節：

1）全域性負載均衡-就近接入

2）BGP中轉架構-最短傳輸路徑

二、直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析

三、在傳輸直播流媒體過程中的內容快取與傳輸策略優化細節原理

相關推薦