一. 視頻直播的痛點：卡頓

? ? ? 卡頓是最影響直播體驗的因素之一，也是最難解決的問題之一。在流媒體的傳輸鏈路中，任何一個環(huán)節(jié)丟包都可能導(dǎo)致用戶觀看卡頓。

? ? ? 其中，主播端的推流卡頓最影響觀看體驗，會直接影響到所有觀看直播的最終用戶。主播推流卡頓在部分場景會特別顯著，比如戶外直播就非常考驗在網(wǎng)絡(luò)狀況復(fù)雜的情況下推流的穩(wěn)定性。

? ? ? 減少卡頓一直是開發(fā)者重大的技術(shù)挑戰(zhàn)，那么繼續(xù)看看我們又有什么樣的對策呢？

? ? ? Google 從 2014 年推出 QUIC 協(xié)議后一直在音視頻產(chǎn)品上實踐該協(xié)議?，F(xiàn)在，經(jīng)過一年多的探索和實踐，我們的直播云產(chǎn)品已經(jīng)擁抱 QUIC，最新推出的直播 QUIC 推流方案可以大幅度的降低直播的卡頓問題，可以在各種復(fù)雜網(wǎng)絡(luò)環(huán)境下給客戶提供優(yōu)秀的直播體驗。（關(guān)于QUIC協(xié)議的詳細(xì)介紹請閱讀《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》）

二. QUIC 是什么，為什么可以降低卡頓？

? ? ? 既然 QUIC 可以解決如此重要的直播體驗問題，那么我們先從整體了解一下 QUIC 協(xié)議（關(guān)于QUIC協(xié)議的詳細(xì)介紹請閱讀《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》）。

2.1 QUIC 協(xié)議的定義

? ? ? QUIC 全稱 Quick UDP Internet Connection, 是谷歌公司制定的一種基于 UDP 協(xié)議的低時延互聯(lián)網(wǎng)傳輸協(xié)議。

? ? ? ?我們知道，TCP/IP 協(xié)議族是互聯(lián)網(wǎng)的基礎(chǔ)。其中傳輸層協(xié)議只有兩種： TCP 和 UDP 協(xié)議。與 TCP 協(xié)議相比，UDP 更為輕量，但是錯誤校驗也要少得多。由于 UDP 是不可靠協(xié)議，不保證按序送達，所以其可靠性比不上 TCP 協(xié)議。

? ? ? QUIC 傳輸層基于 UDP 協(xié)議但卻是一種可靠的傳輸協(xié)議，因為它將很多可靠性的驗證策略從系統(tǒng)層轉(zhuǎn)移到應(yīng)用層來做，這樣可以使用更適合現(xiàn)代流媒體傳輸?shù)膿砣刂撇呗浴?/p>

關(guān)于TCP和UDP的差異，以下文章可以給您一些答案：

《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》

《簡述傳輸層協(xié)議TCP和UDP的區(qū)別》

《為什么QQ用的是UDP協(xié)議而不是TCP協(xié)議？》

《移動端即時通訊協(xié)議選擇：UDP還是TCP？》

2.2 QUIC 在網(wǎng)絡(luò)傳輸中所處的位置

?

? ? ? 從圖上可以看出，QUIC 傳輸層用 UDP 協(xié)議替代了 TCP。（另外，更深入的計算機網(wǎng)絡(luò)協(xié)議關(guān)系圖請見《計算機網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）[附件下載]》）

2.3 QUIC 在傳輸上為什么有優(yōu)勢

? ? ? 從上面所有對 QUIC 的定義上來看，很明顯 QUIC 的對比對象是 TCP。所以下面所有的優(yōu)勢的枚舉都是基于 QUIC 和 TCP 的比較。

【QUIC優(yōu)勢1：更出色的擁塞控制】

? ? ? 雖然例如 HTTP/2 或者 SPDY 協(xié)議現(xiàn)在都支持將頁面的多個數(shù)據(jù)通過一個數(shù)據(jù)鏈接進行傳輸，該特性也確實能夠加快數(shù)據(jù)的傳輸速度。但是由于 TCP 協(xié)議在處理包時是有嚴(yán)格順序的，所以還是會遇到隊首阻塞的問題。

? ? ? 比如發(fā)生如下圖所示場景下的問題時，當(dāng)其中一個數(shù)據(jù)沒有發(fā)送成功，TCP 連接需要等待這個包完成重傳之后才能繼續(xù)進行。因此，即使邏輯上一個 TCP 連接上并行的在進行多路數(shù)據(jù)傳輸，其他毫無關(guān)聯(lián)的數(shù)據(jù)也會因此阻塞：

?

? ? ? QUIC 協(xié)議直接通過傳輸層使用 UDP 協(xié)議就可以避免該問題的發(fā)送。由于 UDP 協(xié)議沒有嚴(yán)格的順序要求，當(dāng)一個數(shù)據(jù)包遇到問題需要重傳時只會影響該數(shù)據(jù)包對應(yīng)的資源，其他獨立的資源不會受到影響而阻塞傳輸：

?

【QUIC優(yōu)勢2：更加靈活】

? ? ? TCP 協(xié)議棧通常由操作系統(tǒng)層面來實現(xiàn)，例如如 Linux、Windows、iOS、Android 操作系統(tǒng)。因此如果要修改 TCP 協(xié)議需要從操作系統(tǒng)層面去做很多事情，這是一項復(fù)雜的工程。相對來說 UDP 協(xié)議在操作系統(tǒng)層面實現(xiàn)更為簡單，QUIC 基于 UDP 在應(yīng)用層做了很多網(wǎng)絡(luò)擁塞控制層面的優(yōu)化，幫助用戶減少復(fù)雜網(wǎng)絡(luò)下的卡頓率，提高流暢度，這是 TCP 無法做到的。

2.4 QUIC小結(jié)

? ? ? 從以上所有的介紹中可以看出，如果我們需要使用 QUIC 改善直播體驗，就是用它來代替直播中 TCP 協(xié)議所扮演的角色。大家都清楚目前直播所使用的協(xié)議都基本是 RTMP 協(xié)議,而 RTMP 協(xié)議的傳輸層是基于 TCP 協(xié)議。所以我們的 QUIC 推流方案就是把 RTMP 當(dāng)中的傳輸層協(xié)議換成 QUIC，從而達到推流卡頓率下降的效果。

三. 使用 QUIC 后的效果

? ? ? 上面說了那么多基于 QUIC 做媒體傳輸?shù)睦碚搩?yōu)勢，那么有沒有實際的實驗測試作為理論的支撐呢？下面一起來看看測試數(shù)據(jù)吧。

測試的參數(shù)配置：

?

測試方式：?

使用 ATC 模擬的弱網(wǎng)環(huán)境下，用 srs 播放器播放 5 mins，記錄流暢度和卡頓次數(shù)。

3.1 測試場景之弱網(wǎng)配置一

ATC配置：delay 100ms??loss 1%

結(jié)果分別如圖所示：

3.2 測試場景之弱網(wǎng)配置二

ATC配置：delay 200ms loss 10%

測試結(jié)果如圖所示：

而在 TCP 這種網(wǎng)絡(luò)配置下，推不起來，或者推一會就會斷開。

超強干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的使用QUIC协议实现实时视频直播0卡顿的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。