電腦看直播卡的原理，從網路通信的原理解答一下?

02-01

首先解釋一下直播原理。

△ 圖片來源於又拍雲（http://www.upyun.com）

直播從主播端編碼發出，到達邊緣節點，經過內容分發網路（CDN），到達觀眾段節點拉取CDN中的緩存視頻流進行播放。

關於網路卡頓主要從以下幾個點去解釋：
1. 網路延時
當直播從主播端採集到觀眾端播放中間出現的網路卡頓延時現象。在不考慮主播段視頻編碼與觀眾段視頻解碼時間的情況下。

估算一下網路延時，光在真空中的速度約為300000km/s，在光纖中的傳輸速度為200000km/s。
在節點較少、網路情況較好的情況下，網路延時低，加上一定的緩存，可以控制延時在1s~2s左右。但是節點多、網路差的情況下，網路延時會對應增大，經驗來說延時可以達到15s以上。
2. 網路抖動
網路抖動，是指數據包的到達順序、間隔和發出時不一致。比如說，發送100個數據包，每個包間隔1s發出。結果第27個包在傳輸過程中遇到網路擁塞，造成包27不是緊跟著26到達的，而是延遲到87後面才達。在直播中，這種抖動的效果實際上跟丟包是一樣的。因為你不能依照接收順序把內容播放出來，否則會造成失真。
網路抖動，會造成播放延時對應增大。如果網路中抖動較大，會造成播放卡頓等現象。

如上圖所示，主播端t3和t5發出的包，分別在t3和t5到達，但是中間延時增大，即發生了網路抖動。這樣造成觀眾端觀看視頻的延時會不斷增大。
3. 網路丟包
CDN直播中用到的RTMP、HLS、HTTP FLV等協議都是在TCP的基礎之上。TCP一個很重要的特性是可靠性，即不會發生數據丟失的問題。為了保證可靠性，TCP在傳輸過程中有3次握手，首先客戶端會向服務端發送連接請求，服務端同意後，客戶端會確認這次連接。這就是3次握手。接著，客戶端就開始發送數據，每次發送一批數據，得到服務端的「收到」確認後，繼續發送下一批。TCP為了保證傳到，會有自動重傳機制。如果傳輸中發生了丟包，沒有收到對端發出的「收到」信號，那麼就會自動重傳丟失的包，一直到超時。
由於互聯網的網路狀況是變化的，以及主播端的網路狀況是無法控制的。所以當網路中丟包率開始升高時，重傳會導致延時會不斷增大，甚至導致不斷嘗試重連等情況，這樣不能有效的緩存，嚴重情況下會導致觀眾端視頻無法觀看。

一場直播的視頻流數據從主播端發出，直到被觀眾端接收，中間需要經歷很多環節：

由上述數據流向圖可以很容易的知道，卡頓成因一般有以下幾種：

1. 主播到邊緣節點的網路狀況不佳（調度問題，鏈路問題，網路波動問題等）。這種卡頓情況的影響面較大，因為主播的音視頻數據無法正常流出，所以該主播的所有觀眾都無法倖免，頻繁卡頓。

2. 觀眾到邊緣節點的網路狀況不佳（調度問題，鏈路問題，網路波動問題等）。這種卡頓影響較小，基本上只有特定觀眾的觀看體驗受影響。

3. 主播端的推流邊緣節點伺服器異常。這種情況一般極少發生，會影響到正在連接該節點的所有主播。

4. 觀眾端的拉流邊緣節點伺服器異常。這種情況一般也極少發生，會影響到正在連接該節點的所有觀眾。

5. 內容分發網路異常。極少發生，影響範圍不定。

6. 主播或觀眾的設備性能問題。影響具體的某一場直播。

由於卡頓的成因眾多，所以最好是能建立一套監控體系實時監控直播過程的每一個環節。

這裡簡單介紹下網易雲視頻服務在卡頓這塊的監控體系的搭建。

視頻雲實時監控的解決方案主要涉及數據採集，評價演算法，實時計算，監控預警等多個方面。

1. 數據的採集：視頻雲從項目初期就建立起了比較完善的數據採集體系，主要包括：

SDK端實時收集推拉流的多項指標數據，定時上報至統計服務集群?
在邊緣節點上部署數據採集應用，實時採集各路視頻流的詳細數據，實時上報?
通過在全國各地進行網路測速的方式，實時收集不同地區不同運營商的用戶到各個邊緣節點的網路暢通情況，上報服務端統一處理。

2. 評價演算法：通過離線大數據的方式對線上海量數據進行特徵計算，總結出了一套比較成熟的卡頓評價演算法，可以有效評估直播各個環節的質量，並以卡頓率為主要評價指標。

3. 實時計算：為了能及時處理匯總而來的海量數據，視頻雲搭建了一套實時計算集群，利用評價演算法對各環節產生的數據進行統計，實時的評估各環節在時間，地域，運營商，邊緣節點等不同維度下的卡頓率，輸出評估結果。確保每一份數據都能在幾秒內被準確的計算評估，供監控使用。

4. 監控預警：對實時計算集群產生的各環節各維度下的卡頓數據進行監控，及時的將異常情況推送給相關的負責人，即時處理。

下圖為卡頓實時監控方案的總體結構概覽：

方案上線後，已經產出了不少監控信息，舉一個例子來說明卡頓實時監控的運作情況：

某日收到的一條告警信息，顯示某一場直播在過去幾分鐘內質量不佳，主播端和觀眾端的卡頓率都在持續爬升。收到監控告警信息後，查看該直播的主播推流數據，發現該時間段內的音視頻的推流碼率都發生了較大的波動：

同時發現SDK的qos機制已經自動啟動，開始調整設定參數以保障弱網下的直播流暢：

說明該主播到邊緣節點間的網路的確發生了波動，並且已經影響到了部分用戶的觀看體驗。進一步排查後確認是該主播的個人網路發生波動，與地域及cdn邊緣節點無關。

利用這一套實時監控體系，視頻雲能夠有效的監控線上各個環節的運作情況，對可能存在異常的節點進行及時處理，最大程度上保障用戶的使用體驗。

電信數據機房：主要還是伺服器節點分布（這個最好參照通信行業數據工程師建議，各省各地路由路徑）、局內中繼租用量（也就是伺服器帶寬），其他的我認為是次要因素吧。

影響網路直播卡的因素很多，先看直播用了哪個技術實現。一般分為組播和單播。根據兩個方式分別定位每個環節的網路情況。總體來說可看網路通道質量如何，視頻源的發布節點有無問題，協議實現有無問題等。即先看網路質量，再分析協議問題。一兩句話說不清。。。