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