一、直播為什么需要QUIC?
眾所周知，決定直播觀看體驗(yàn)的因素有很多，比如：卡頓、首屏?xí)r間、延時(shí)、清晰度等等。而卡頓被稱(chēng)為直播體驗(yàn)的頭號(hào)痛點(diǎn)，從“主播推流端”→“CDN”→“觀眾拉流端”，整個(gè)流媒體傳輸鏈路中，任何一個(gè)環(huán)節(jié)出現(xiàn)丟包都可能導(dǎo)致卡頓。尤其是主播推流端的推流流暢度更是決定了原流的質(zhì)量，如果主播推流時(shí)網(wǎng)絡(luò)丟包較高、延時(shí)較大，將會(huì)出現(xiàn)推流卡頓，那么所有觀眾在觀看這路流時(shí)都會(huì)出現(xiàn)卡頓。那么拉流端是否存在痛點(diǎn)呢?拉流端同樣存在痛點(diǎn)，因?yàn)樵谝苿?dòng)互聯(lián)網(wǎng)時(shí)代，大量觀眾是使用手機(jī)觀看直播視頻的，移動(dòng)蜂窩網(wǎng)絡(luò)在不同地區(qū)、不同位置的覆蓋質(zhì)量是不同的，在信號(hào)覆蓋不好的地區(qū)就會(huì)出現(xiàn)弱網(wǎng)問(wèn)題，弱網(wǎng)的顯著特點(diǎn)是丟包率和延時(shí)都很高，在這些弱網(wǎng)地區(qū)使用傳統(tǒng)的TCP拉流體驗(yàn)是很差的。
而QUIC具有弱網(wǎng)環(huán)境下抗丟包、縮短首屏?xí)r間等優(yōu)勢(shì)，因此可以用QUIC來(lái)解決直播業(yè)務(wù)上存在的上述痛點(diǎn)。不了解QUIC的小伙伴別著急，我們下文將會(huì)為您詳細(xì)介紹QUIC的技術(shù)原理和優(yōu)勢(shì)。
二、金山視頻云直播QUIC+解決方案概要
為了解決直播業(yè)務(wù)上存在的痛點(diǎn)，金山視頻云直播推出了QUIC+解決方案，該方案不僅支持RTMPoverQUIC推流，同時(shí)還支持RTMPover QUIC/ HTTP-FLVover QUIC/ HLSover QUIC拉流功能，真正實(shí)現(xiàn)了端到端支持QUIC，此外金山云直播QUIC+解決方案采用了最新的BBR擁塞控制算法，在弱網(wǎng)環(huán)境下的表現(xiàn)更出色。
相比而言，有些友商的直播產(chǎn)品不支持QUIC，少數(shù)廠商僅支持overQUIC推流，不支持overQUIC拉流，無(wú)法做到端到端支持QUIC，并且需要使用他們的推流SDK，這會(huì)導(dǎo)致SDK對(duì)接繁瑣，并且頭部客戶(hù)因?yàn)橛蓄檻]一般不愿意使用云廠商的SDK，而是選擇自己開(kāi)發(fā)SDK;還有友商的直播QUIC方案中沒(méi)有集成BBR擁塞控制算法，在弱網(wǎng)環(huán)境下抗丟包的能力不如采用BBR算法的金山視頻云直播QUIC+解決方案，這一點(diǎn)我們可以從測(cè)試數(shù)據(jù)中得到證實(shí)，從友商公布的測(cè)試數(shù)據(jù)來(lái)看，overQUIC推流，當(dāng)丟包率20%時(shí)，流暢度只有30-40%;而金山視頻云直播QUIC+解決方案在丟包率達(dá)到30%時(shí)流暢度還有96.51%?？梢?jiàn)，金山視頻云直播QUIC+解決方案是率先真正完美支持直播推拉流overQUIC的云廠商。
我們下文將會(huì)為大家呈現(xiàn)金山視頻云QUIC+解決方案在直播業(yè)務(wù)上與傳統(tǒng)TCP方案的實(shí)際測(cè)試對(duì)比，大家能夠在下文的測(cè)試報(bào)告中看到金山視頻云QUIC+解決方案的優(yōu)勢(shì)：傳統(tǒng)的RTMP over TCP推流在5%丟包率時(shí)就已經(jīng)非常卡了，當(dāng)丟包率超過(guò)10%時(shí)，RTMP over TCP直接無(wú)法推拉流，而金山視頻云QUIC+解決方案采用RTMP over QUIC推流在30%丟包率時(shí)持續(xù)5分鐘的播放過(guò)程中只出現(xiàn)了7次卡頓，流暢度為96.51%，這樣的流暢度還是不影響觀看體驗(yàn)的，大多數(shù)的觀眾還能接受。
追求無(wú)止境，除了在直播場(chǎng)景下率先真正端到端完美支持直播推拉流overQUIC外，金山云CDN還支持直播多流擇優(yōu)方案，通過(guò)穩(wěn)定的性能、透明的數(shù)據(jù)服務(wù)體制，金山云成功保障國(guó)慶70周年慶典直播、建軍90周年閱兵、“十九大”、全國(guó)兩會(huì)、香港回歸20周年、G20峰會(huì)、金磚國(guó)家峰會(huì)、央視春晚、世界互聯(lián)網(wǎng)大會(huì)、世界杯、亞運(yùn)會(huì)等大型活動(dòng)和體育賽事。作為云計(jì)算行業(yè)的領(lǐng)導(dǎo)者，金山云將致力于為用戶(hù)打造高品質(zhì)的直播體驗(yàn)而保駕護(hù)航。選用視頻云，就選金山云!選用CDN，就選金山云!
三、QUIC介紹
1、QUIC簡(jiǎn)介
QUIC(Quick UDP Internet Connection，發(fā)音'quick')是一種互聯(lián)網(wǎng)傳輸協(xié)議，最初由Google的Jim Roskind設(shè)計(jì)，并于2012年被應(yīng)用和部署，隨后在2013年隨著實(shí)驗(yàn)的擴(kuò)大而開(kāi)始對(duì)外公開(kāi)，并于同年向IETF(Internet Engineering Task Force，國(guó)際互聯(lián)網(wǎng)工程任務(wù)組)遞交了協(xié)議草案。
互聯(lián)網(wǎng)人士都知道，TCP/IP協(xié)議簇是互聯(lián)網(wǎng)的基礎(chǔ)，任何數(shù)據(jù)在互聯(lián)網(wǎng)中傳輸都依賴(lài)它。TCP/IP四層模型中輸層協(xié)議只有兩種：TCP和UDP協(xié)議，其中TCP協(xié)議是面向連接的協(xié)議，是一種可靠的協(xié)議，TCP保證數(shù)據(jù)的正確性和數(shù)據(jù)包的順序;而UDP協(xié)議是非連接的協(xié)議，也就是說(shuō)傳輸數(shù)據(jù)時(shí)不需要建立連接，是不可靠的協(xié)議，UDP不保證數(shù)據(jù)的正確性和數(shù)據(jù)包的順序。因?yàn)門(mén)CP和UDP各有優(yōu)缺點(diǎn)，TCP的優(yōu)點(diǎn)是可靠、穩(wěn)定，但是也有明顯的缺點(diǎn)：建連需要經(jīng)過(guò)3次握手，繁瑣、效率低、占用系統(tǒng)資源高。UDP的優(yōu)點(diǎn)是效率高、快、輕量占用系統(tǒng)資源少，但是缺點(diǎn)很明顯：不可靠、無(wú)序。
QUIC其實(shí)是在UDP協(xié)議之上提供一種可靠的、可建立面向連接的服務(wù)，它繼承了UDP的優(yōu)點(diǎn)，同時(shí)基于UDP之上加入了擁塞控制、多路復(fù)用、前向糾錯(cuò)等特性，從而彌補(bǔ)了UDP的缺點(diǎn)，使得QUIC既提高了數(shù)據(jù)的傳輸效率，也變得可靠了。
如下圖所示，QUIC所處的網(wǎng)絡(luò)層次如下。從功能上看，HTTP-over-QUIC ≈ TCP + TLS + HTTP2，但是基于UDP之上實(shí)現(xiàn)的。
2、QUIC的優(yōu)勢(shì)
前面咱們聊到QUIC是基于UDP實(shí)現(xiàn)的，在UDP之上加入了一些新特性從而彌補(bǔ)了UDP的缺點(diǎn)，這些優(yōu)勢(shì)有哪些呢?
1）極短的建連時(shí)間
QUIC的建連時(shí)間中大部分為0 RTT，極少部分是1 RTT。分為以下兩種情況：
a) 若客戶(hù)端與服務(wù)器未建連，則第一次建連時(shí)需在客戶(hù)端生成證書(shū)和協(xié)議棧相關(guān)的配置并生成ConnectionID，這些數(shù)據(jù)會(huì)保存在服務(wù)端;
b)若客戶(hù)端與服務(wù)器已建連過(guò)，服務(wù)端已保存了客戶(hù)端的證書(shū)和ConnectionID等數(shù)據(jù)，服務(wù)端會(huì)直接進(jìn)行校驗(yàn)，校驗(yàn)通過(guò)后直接向客戶(hù)端發(fā)送數(shù)據(jù)，從而實(shí)現(xiàn)0RTT極短的建連時(shí)間。
TCP的一個(gè)建連包含三次握手，而如果是HTTPS，則還需包含TLS層的一次握手，同時(shí)增加1RTT的時(shí)間;因此，就TCP+TLS而言，已完成建連的連接需要2RTT，而首次建連的則需3RTT。相比而言，QUIC0~1 RTT的建連時(shí)間就顯得極短了，因此直播業(yè)務(wù)支持QUIC推拉流后，能夠顯著縮短首屏?xí)r間，至少能將首屏?xí)r間降低一半。
2）改進(jìn)的擁塞控制
金山視頻云直播QUIC方案采用了BBR擁塞控制算法，其中BBR算法是先在QUIC中試驗(yàn)，由于效果很好，后來(lái)還被移植到TCP內(nèi)核中了。可見(jiàn)QUIC在弱網(wǎng)環(huán)境下的擁塞控制方面是很優(yōu)秀的，金山云直播QUIC方案在推流和拉流上都實(shí)現(xiàn)了BBR算法，并且經(jīng)過(guò)對(duì)BBR算法的適配和優(yōu)化，能保證在弱網(wǎng)環(huán)境下丟包30%時(shí)仍然能流暢推流和拉流。
3）避免隊(duì)頭阻塞的多路復(fù)用
HTTP1.1中，每條數(shù)據(jù)流基于一個(gè)TCP連接，每個(gè)TCP連接都單獨(dú)傳輸數(shù)據(jù)，但此TCP連接方案會(huì)明顯增加服務(wù)端與客戶(hù)端的并發(fā)負(fù)載，浪費(fèi)服務(wù)端和客戶(hù)端的資源;
HTTP/2中，對(duì)此問(wèn)題進(jìn)行了有效優(yōu)化也就是采用多路復(fù)用的傳輸策略，通過(guò)一條TCP連接傳輸多路數(shù)據(jù)，但此方案容易造成隊(duì)首阻塞問(wèn)題。隊(duì)首阻塞(Head-of-Line Blocking)是指因?yàn)殛?duì)首的數(shù)據(jù)流丟失而重傳造成其他隊(duì)首之后的多條數(shù)據(jù)流被阻塞的現(xiàn)象。
如下圖所示，以HTTP/2 over TCP數(shù)據(jù)流為例，若Stream 3丟失那么Stream 1與Stream 2都會(huì)被阻塞，直到丟失的Stream 3數(shù)據(jù)重傳完成之后Stream 1與Stream 2才能被繼續(xù)傳輸。
而在QUIC中，改善了HTTP/2中的隊(duì)首阻塞問(wèn)題，實(shí)現(xiàn)了避免隊(duì)首阻塞的多路復(fù)用，具體實(shí)現(xiàn)是把每個(gè)重傳過(guò)程安排在每條Stream中單獨(dú)完成，由于Stream本質(zhì)上是一個(gè)基于UDP的小數(shù)據(jù)包，所以這種方案并不會(huì)造成隊(duì)首阻塞問(wèn)題。如下圖所示，Stream 3 是隊(duì)首數(shù)據(jù)，當(dāng)Stream 3中出現(xiàn)丟包后，不影響Stream 2和Stream 1的數(shù)據(jù)傳輸，Stream 2可以獨(dú)立傳輸，不用等Stream 3丟失的數(shù)據(jù)重傳完成。
4）前向糾錯(cuò)
前向糾錯(cuò)算法(FEC，F(xiàn)orward Error Correction)是一種對(duì)抗網(wǎng)絡(luò)丟包的算法，具體實(shí)現(xiàn)是當(dāng)弱網(wǎng)環(huán)境下出現(xiàn)丟包時(shí)，可以通過(guò)未丟失的報(bào)文和FEC報(bào)文將丟包恢復(fù)出來(lái)，減少了不必要的重傳，從而實(shí)現(xiàn)在弱網(wǎng)環(huán)境下丟包率較高時(shí)不影響數(shù)據(jù)接收端的體驗(yàn)。金山視頻云直播QUIC+方案，在丟包30%時(shí)主播端仍然能流暢推流，觀眾端仍能流暢觀看，具體數(shù)據(jù)可繼續(xù)看下面的TCP與QUIC測(cè)試對(duì)比。
5）連接轉(zhuǎn)移
假設(shè)用戶(hù)在家中使用WiFi觀看直播視頻，這時(shí)突然有事需要出門(mén)，一邊刷著直播視頻一邊下電梯，當(dāng)用戶(hù)進(jìn)入電梯時(shí)手機(jī)連接的WiFi將會(huì)斷開(kāi)，手機(jī)網(wǎng)絡(luò)自動(dòng)切換到移動(dòng)蜂窩網(wǎng)絡(luò)，在網(wǎng)絡(luò)從WiFi到蜂窩網(wǎng)絡(luò)切換的瞬間，TCP連接會(huì)斷開(kāi)重連，這是因?yàn)門(mén)CP采用四元組(源IP、目標(biāo)IP、源端口、目標(biāo)端口)的方式來(lái)標(biāo)識(shí)一個(gè)連接;而QUIC是用數(shù)據(jù)包中一個(gè)64位的數(shù)值ConnectionID來(lái)標(biāo)識(shí)一個(gè)連接，無(wú)論WiFi與蜂窩網(wǎng)絡(luò)之間如何切換，只要發(fā)送給的服務(wù)端的ConnectionID沒(méi)變，服務(wù)端就會(huì)認(rèn)為是同一個(gè)連接，從而避免出現(xiàn)切換網(wǎng)絡(luò)需要重連的問(wèn)題。
QUIC優(yōu)勢(shì)總結(jié)：
以上這些優(yōu)點(diǎn)將幫助互聯(lián)網(wǎng)內(nèi)容服務(wù)商實(shí)現(xiàn)更快的連接建立、弱網(wǎng)環(huán)境抗丟包、切換網(wǎng)絡(luò)無(wú)需重新連接等特性，因此業(yè)內(nèi)越來(lái)越多的廠商開(kāi)始擁抱QUIC，發(fā)展前景一片光明。金山云作為云計(jì)算行業(yè)的領(lǐng)導(dǎo)者、金山云云直播產(chǎn)品作為行業(yè)內(nèi)的旗艦產(chǎn)品，現(xiàn)已率先推出金山視頻云直播QUIC+解決方案。
四、金山視頻云直播QUIC+解決方案效果測(cè)試
上文說(shuō)到了直播為什么需要QUIC，以及QUIC的優(yōu)勢(shì)，那么金山云直播over QUIC推拉流的效果相較于傳統(tǒng)的over TCP推拉流如何呢，我們通過(guò)長(zhǎng)期的線上驗(yàn)證，并通過(guò)頭部客戶(hù)使用后的反饋來(lái)看，效果非常好。我們將用數(shù)據(jù)說(shuō)話，告訴大家金山云直播支持QUIC推拉流后帶來(lái)哪些改善。
測(cè)試方法：
1)使用同一個(gè)媒資，推流分辨率、碼率、編碼格式都相同;
2)使用ATC工具模擬弱網(wǎng)環(huán)境，分別采用RTMP over TCP和RTMP overQUIC推拉流，用srs播放器持續(xù)播放5 mins，記錄流暢度和卡頓次數(shù)。
推流視頻
測(cè)試結(jié)果：
弱網(wǎng)環(huán)境1：delay 100ms loss 1%
1)RTMP over TCP測(cè)試截圖：
2)RTMP over QUIC測(cè)試截圖：
弱網(wǎng)環(huán)境2：delay 150ms loss 5%
1)RTMP over TCP測(cè)試截圖：
2)RTMP over QUIC測(cè)試截圖：
弱網(wǎng)環(huán)境3：delay 200ms loss 10%
在這種弱網(wǎng)環(huán)境下，RTMP over TCP推流非?？ǎシ牌骼?5秒后被斷開(kāi)連接;而RTMP over QUIC推流和播放都很流暢，在持續(xù)5分鐘的播放過(guò)程中0次卡頓，流暢度100%，效果非常好。
1)RTMP over TCP測(cè)試截圖：
2)RTMP over QUIC測(cè)試截圖：
弱網(wǎng)環(huán)境4：loss 20%
在這種弱網(wǎng)環(huán)境下，RTMP over TCP推流非?？o(wú)法正常推流，播放器拉流馬上就被斷開(kāi);而RTMP over QUIC推流和播放都很流暢，在持續(xù)5分鐘的播放過(guò)程中0次卡頓，流暢度100%，效果非常好。
RTMP over QUIC測(cè)試截圖：
弱網(wǎng)環(huán)境5：delay 500ms，loss 30%
在這種弱網(wǎng)環(huán)境下，RTMP over TCP直接無(wú)法推流，而RTMP over QUIC推流和播放仍然還是流暢的，在持續(xù)5分鐘的播放過(guò)程中只出現(xiàn)7次卡頓，流暢度96.51%，這樣的流暢度大多數(shù)觀眾還是能接受的。
RTMP over QUIC測(cè)試截圖：
