一. 視頻直播的痛點(diǎn)：卡頓

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

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

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

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

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

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

2.1 QUIC 協(xié)議的定義

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

?

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

?

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

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

2.4 QUIC小結(jié)

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

三. 使用 QUIC 后的效果

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

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

?

測(cè)試方式：?

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

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

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

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

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

ATC配置：delay 200ms loss 10%

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

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

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

總結(jié)

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

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