金山視頻云推出QUIC+ ，暢快直播再升級

一、直播為什么需要QUIC?

眾所周知，決定直播觀看體驗的因素有很多，比如：卡頓、首屏?xí)r間、延時、清晰度等等。而卡頓被稱為直播體驗的頭號痛點，從“主播推流端”→“CDN”→“觀眾拉流端”，整個流媒體傳輸鏈路中，任何一個環(huán)節(jié)出現(xiàn)丟包都可能導(dǎo)致卡頓。尤其是主播推流端的推流流暢度更是決定了原流的質(zhì)量，如果主播推流時網(wǎng)絡(luò)丟包較高、延時較大，將會出現(xiàn)推流卡頓，那么所有觀眾在觀看這路流時都會出現(xiàn)卡頓。那么拉流端是否存在痛點呢?拉流端同樣存在痛點，因為在移動互聯(lián)網(wǎng)時代，大量觀眾是使用手機(jī)觀看直播視頻的，移動蜂窩網(wǎng)絡(luò)在不同地區(qū)、不同位置的覆蓋質(zhì)量是不同的，在信號覆蓋不好的地區(qū)就會出現(xiàn)弱網(wǎng)問題，弱網(wǎng)的顯著特點是丟包率和延時都很高，在這些弱網(wǎng)地區(qū)使用傳統(tǒng)的TCP拉流體驗是很差的。

而QUIC具有弱網(wǎng)環(huán)境下抗丟包、縮短首屏?xí)r間等優(yōu)勢，因此可以用QUIC來解決直播業(yè)務(wù)上存在的上述痛點。不了解QUIC的小伙伴別著急，我們下文將會為您詳細(xì)介紹QUIC的技術(shù)原理和優(yōu)勢。

二、金山視頻云直播QUIC+解決方案概要

為了解決直播業(yè)務(wù)上存在的痛點，金山視頻云直播推出了QUIC+解決方案，該方案不僅支持RTMPoverQUIC推流，同時還支持RTMPover QUIC/ HTTP-FLVover QUIC/ HLSover QUIC拉流功能，真正實現(xiàn)了端到端支持QUIC，此外金山云直播QUIC+解決方案采用了最新的BBR擁塞控制算法，在弱網(wǎng)環(huán)境下的表現(xiàn)更出色。

相比而言，有些友商的直播產(chǎn)品不支持QUIC，少數(shù)廠商僅支持overQUIC推流，不支持overQUIC拉流，無法做到端到端支持QUIC，并且需要使用他們的推流SDK，這會導(dǎo)致SDK對接繁瑣，并且頭部客戶因為有顧慮一般不愿意使用云廠商的SDK，而是選擇自己開發(fā)SDK;還有友商的直播QUIC方案中沒有集成BBR擁塞控制算法，在弱網(wǎng)環(huán)境下抗丟包的能力不如采用BBR算法的金山視頻云直播QUIC+解決方案，這一點我們可以從測試數(shù)據(jù)中得到證實，從友商公布的測試數(shù)據(jù)來看，overQUIC推流，當(dāng)丟包率20%時，流暢度只有30-40%;而金山視頻云直播QUIC+解決方案在丟包率達(dá)到30%時流暢度還有96.51%?？梢姡鹕揭曨l云直播QUIC+解決方案是率先真正完美支持直播推拉流overQUIC的云廠商。

我們下文將會為大家呈現(xiàn)金山視頻云QUIC+解決方案在直播業(yè)務(wù)上與傳統(tǒng)TCP方案的實際測試對比，大家能夠在下文的測試報告中看到金山視頻云QUIC+解決方案的優(yōu)勢：傳統(tǒng)的RTMP over TCP推流在5%丟包率時就已經(jīng)非?？耍?dāng)丟包率超過10%時，RTMP over TCP直接無法推拉流，而金山視頻云QUIC+解決方案采用RTMP over QUIC推流在30%丟包率時持續(xù)5分鐘的播放過程中只出現(xiàn)了7次卡頓，流暢度為96.51%，這樣的流暢度還是不影響觀看體驗的，大多數(shù)的觀眾還能接受。

追求無止境，除了在直播場景下率先真正端到端完美支持直播推拉流overQUIC外，金山云CDN還支持直播多流擇優(yōu)方案，通過穩(wěn)定的性能、透明的數(shù)據(jù)服務(wù)體制，金山云成功保障國慶70周年慶典直播、建軍90周年閱兵、“十九大”、全國兩會、香港回歸20周年、G20峰會、金磚國家峰會、央視春晚、世界互聯(lián)網(wǎng)大會、世界杯、亞運(yùn)會等大型活動和體育賽事。作為云計算行業(yè)的領(lǐng)導(dǎo)者，金山云將致力于為用戶打造高品質(zhì)的直播體驗而保駕護(hù)航。選用視頻云，就選金山云!選用CDN，就選金山云!

三、QUIC介紹

1、QUIC簡介

QUIC(Quick UDP Internet Connection，發(fā)音'quick')是一種互聯(lián)網(wǎng)傳輸協(xié)議，最初由Google的Jim Roskind設(shè)計，并于2012年被應(yīng)用和部署，隨后在2013年隨著實驗的擴(kuò)大而開始對外公開，并于同年向IETF(Internet Engineering Task Force，國際互聯(lián)網(wǎng)工程任務(wù)組)遞交了協(xié)議草案。

互聯(lián)網(wǎng)人士都知道，TCP/IP協(xié)議簇是互聯(lián)網(wǎng)的基礎(chǔ)，任何數(shù)據(jù)在互聯(lián)網(wǎng)中傳輸都依賴它。TCP/IP四層模型中輸層協(xié)議只有兩種：TCP和UDP協(xié)議，其中TCP協(xié)議是面向連接的協(xié)議，是一種可靠的協(xié)議，TCP保證數(shù)據(jù)的正確性和數(shù)據(jù)包的順序;而UDP協(xié)議是非連接的協(xié)議，也就是說傳輸數(shù)據(jù)時不需要建立連接，是不可靠的協(xié)議，UDP不保證數(shù)據(jù)的正確性和數(shù)據(jù)包的順序。因為TCP和UDP各有優(yōu)缺點，TCP的優(yōu)點是可靠、穩(wěn)定，但是也有明顯的缺點：建連需要經(jīng)過3次握手，繁瑣、效率低、占用系統(tǒng)資源高。UDP的優(yōu)點是效率高、快、輕量占用系統(tǒng)資源少，但是缺點很明顯：不可靠、無序。

QUIC其實是在UDP協(xié)議之上提供一種可靠的、可建立面向連接的服務(wù)，它繼承了UDP的優(yōu)點，同時基于UDP之上加入了擁塞控制、多路復(fù)用、前向糾錯等特性，從而彌補(bǔ)了UDP的缺點，使得QUIC既提高了數(shù)據(jù)的傳輸效率，也變得可靠了。

如下圖所示，QUIC所處的網(wǎng)絡(luò)層次如下。從功能上看，HTTP-over-QUIC ≈ TCP + TLS + HTTP2，但是基于UDP之上實現(xiàn)的。

2、QUIC的優(yōu)勢

前面咱們聊到QUIC是基于UDP實現(xiàn)的，在UDP之上加入了一些新特性從而彌補(bǔ)了UDP的缺點，這些優(yōu)勢有哪些呢?

1）極短的建連時間

QUIC的建連時間中大部分為0 RTT，極少部分是1 RTT。分為以下兩種情況：

a) 若客戶端與服務(wù)器未建連，則第一次建連時需在客戶端生成證書和協(xié)議棧相關(guān)的配置并生成ConnectionID，這些數(shù)據(jù)會保存在服務(wù)端;

b)若客戶端與服務(wù)器已建連過，服務(wù)端已保存了客戶端的證書和ConnectionID等數(shù)據(jù)，服務(wù)端會直接進(jìn)行校驗，校驗通過后直接向客戶端發(fā)送數(shù)據(jù)，從而實現(xiàn)0RTT極短的建連時間。

TCP的一個建連包含三次握手，而如果是HTTPS，則還需包含TLS層的一次握手，同時增加1RTT的時間;因此，就TCP+TLS而言，已完成建連的連接需要2RTT，而首次建連的則需3RTT。相比而言，QUIC0~1 RTT的建連時間就顯得極短了，因此直播業(yè)務(wù)支持QUIC推拉流后，能夠顯著縮短首屏?xí)r間，至少能將首屏?xí)r間降低一半。

2）改進(jìn)的擁塞控制

金山視頻云直播QUIC方案采用了BBR擁塞控制算法，其中BBR算法是先在QUIC中試驗，由于效果很好，后來還被移植到TCP內(nèi)核中了。可見QUIC在弱網(wǎng)環(huán)境下的擁塞控制方面是很優(yōu)秀的，金山云直播QUIC方案在推流和拉流上都實現(xiàn)了BBR算法，并且經(jīng)過對BBR算法的適配和優(yōu)化，能保證在弱網(wǎng)環(huán)境下丟包30%時仍然能流暢推流和拉流。

3）避免隊頭阻塞的多路復(fù)用

HTTP1.1中，每條數(shù)據(jù)流基于一個TCP連接，每個TCP連接都單獨傳輸數(shù)據(jù)，但此TCP連接方案會明顯增加服務(wù)端與客戶端的并發(fā)負(fù)載，浪費(fèi)服務(wù)端和客戶端的資源;

HTTP/2中，對此問題進(jìn)行了有效優(yōu)化也就是采用多路復(fù)用的傳輸策略，通過一條TCP連接傳輸多路數(shù)據(jù)，但此方案容易造成隊首阻塞問題。隊首阻塞(Head-of-Line Blocking)是指因為隊首的數(shù)據(jù)流丟失而重傳造成其他隊首之后的多條數(shù)據(jù)流被阻塞的現(xiàn)象。

如下圖所示，以HTTP/2 over TCP數(shù)據(jù)流為例，若Stream 3丟失那么Stream 1與Stream 2都會被阻塞，直到丟失的Stream 3數(shù)據(jù)重傳完成之后Stream 1與Stream 2才能被繼續(xù)傳輸。

而在QUIC中，改善了HTTP/2中的隊首阻塞問題，實現(xiàn)了避免隊首阻塞的多路復(fù)用，具體實現(xiàn)是把每個重傳過程安排在每條Stream中單獨完成，由于Stream本質(zhì)上是一個基于UDP的小數(shù)據(jù)包，所以這種方案并不會造成隊首阻塞問題。如下圖所示，Stream 3 是隊首數(shù)據(jù)，當(dāng)Stream 3中出現(xiàn)丟包后，不影響Stream 2和Stream 1的數(shù)據(jù)傳輸，Stream 2可以獨立傳輸，不用等Stream 3丟失的數(shù)據(jù)重傳完成。

4）前向糾錯

前向糾錯算法(FEC，F(xiàn)orward Error Correction)是一種對抗網(wǎng)絡(luò)丟包的算法，具體實現(xiàn)是當(dāng)弱網(wǎng)環(huán)境下出現(xiàn)丟包時，可以通過未丟失的報文和FEC報文將丟包恢復(fù)出來，減少了不必要的重傳，從而實現(xiàn)在弱網(wǎng)環(huán)境下丟包率較高時不影響數(shù)據(jù)接收端的體驗。金山視頻云直播QUIC+方案，在丟包30%時主播端仍然能流暢推流，觀眾端仍能流暢觀看，具體數(shù)據(jù)可繼續(xù)看下面的TCP與QUIC測試對比。

5）連接轉(zhuǎn)移

假設(shè)用戶在家中使用WiFi觀看直播視頻，這時突然有事需要出門，一邊刷著直播視頻一邊下電梯，當(dāng)用戶進(jìn)入電梯時手機(jī)連接的WiFi將會斷開，手機(jī)網(wǎng)絡(luò)自動切換到移動蜂窩網(wǎng)絡(luò)，在網(wǎng)絡(luò)從WiFi到蜂窩網(wǎng)絡(luò)切換的瞬間，TCP連接會斷開重連，這是因為TCP采用四元組(源IP、目標(biāo)IP、源端口、目標(biāo)端口)的方式來標(biāo)識一個連接;而QUIC是用數(shù)據(jù)包中一個64位的數(shù)值ConnectionID來標(biāo)識一個連接，無論WiFi與蜂窩網(wǎng)絡(luò)之間如何切換，只要發(fā)送給的服務(wù)端的ConnectionID沒變，服務(wù)端就會認(rèn)為是同一個連接，從而避免出現(xiàn)切換網(wǎng)絡(luò)需要重連的問題。

QUIC優(yōu)勢總結(jié)：

以上這些優(yōu)點將幫助互聯(lián)網(wǎng)內(nèi)容服務(wù)商實現(xiàn)更快的連接建立、弱網(wǎng)環(huán)境抗丟包、切換網(wǎng)絡(luò)無需重新連接等特性，因此業(yè)內(nèi)越來越多的廠商開始擁抱QUIC，發(fā)展前景一片光明。金山云作為云計算行業(yè)的領(lǐng)導(dǎo)者、金山云云直播產(chǎn)品作為行業(yè)內(nèi)的旗艦產(chǎn)品，現(xiàn)已率先推出金山視頻云直播QUIC+解決方案。

四、金山視頻云直播QUIC+解決方案效果測試

上文說到了直播為什么需要QUIC，以及QUIC的優(yōu)勢，那么金山云直播over QUIC推拉流的效果相較于傳統(tǒng)的over TCP推拉流如何呢，我們通過長期的線上驗證，并通過頭部客戶使用后的反饋來看，效果非常好。我們將用數(shù)據(jù)說話，告訴大家金山云直播支持QUIC推拉流后帶來哪些改善。

測試方法：

1)使用同一個媒資，推流分辨率、碼率、編碼格式都相同;

2)使用ATC工具模擬弱網(wǎng)環(huán)境，分別采用RTMP over TCP和RTMP overQUIC推拉流，用srs播放器持續(xù)播放5 mins，記錄流暢度和卡頓次數(shù)。

推流視頻

測試結(jié)果：

弱網(wǎng)環(huán)境1：delay 100ms loss 1%

1)RTMP over TCP測試截圖：

2)RTMP over QUIC測試截圖：

弱網(wǎng)環(huán)境2：delay 150ms loss 5%

1)RTMP over TCP測試截圖：

2)RTMP over QUIC測試截圖：

弱網(wǎng)環(huán)境3：delay 200ms loss 10%

在這種弱網(wǎng)環(huán)境下，RTMP over TCP推流非常卡，播放器拉流35秒后被斷開連接;而RTMP over QUIC推流和播放都很流暢，在持續(xù)5分鐘的播放過程中0次卡頓，流暢度100%，效果非常好。

1)RTMP over TCP測試截圖：

2)RTMP over QUIC測試截圖：

弱網(wǎng)環(huán)境4：loss 20%

在這種弱網(wǎng)環(huán)境下，RTMP over TCP推流非?？o法正常推流，播放器拉流馬上就被斷開;而RTMP over QUIC推流和播放都很流暢，在持續(xù)5分鐘的播放過程中0次卡頓，流暢度100%，效果非常好。

RTMP over QUIC測試截圖：

弱網(wǎng)環(huán)境5：delay 500ms，loss 30%

在這種弱網(wǎng)環(huán)境下，RTMP over TCP直接無法推流，而RTMP over QUIC推流和播放仍然還是流暢的，在持續(xù)5分鐘的播放過程中只出現(xiàn)7次卡頓，流暢度96.51%，這樣的流暢度大多數(shù)觀眾還是能接受的。

RTMP over QUIC測試截圖：

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。