一、直播為什么需要QUIC?

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

　　而QUIC具有弱網環境下抗丟包、縮短首屏時間等優勢，因此可以用QUIC來解決直播業務上存在的上述痛點。不了解QUIC的小伙伴別著急，我們下文將會為您詳細介紹QUIC的技術原理和優勢。

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

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

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

　　我們下文將會為大家呈現金山視頻云QUIC+解決方案在直播業務上與傳統TCP方案的實際測試對比，大家能夠在下文的測試報告中看到金山視頻云QUIC+解決方案的優勢：傳統的RTMP over TCP推流在5%丟包率時就已經非常卡了，當丟包率超過10%時，RTMP over TCP直接無法推拉流，而金山視頻云QUIC+解決方案采用RTMP over QUIC推流在30%丟包率時持續5分鐘的播放過程中只出現了7次卡頓，流暢度為96.51%，這樣的流暢度還是不影響觀看體驗的，大多數的觀眾還能接受。

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

　　三、QUIC介紹

　　1、QUIC簡介

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

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

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

　　如下圖所示，QUIC所處的網絡層次如下。從功能上看，HTTP-over-QUIC ≈ TCP + TLS + HTTP2，但是基于UDP之上實現的。

　　2、QUIC的優勢

　　前面咱們聊到QUIC是基于UDP實現的，在UDP之上加入了一些新特性從而彌補了UDP的缺點，這些優勢有哪些呢?

　　1）極短的建連時間

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

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

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

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

　　2）改進的擁塞控制

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

　　3）避免隊頭阻塞的多路復用

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

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

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

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

　　4）前向糾錯

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

　　5）連接轉移

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

　　QUIC優勢總結：

　　以上這些優點將幫助互聯網內容服務商實現更快的連接建立、弱網環境抗丟包、切換網絡無需重新連接等特性，因此業內越來越多的廠商開始擁抱QUIC，發展前景一片光明。金山云作為云計算行業的領導者、金山云云直播產品作為行業內的旗艦產品，現已率先推出金山視頻云直播QUIC+解決方案。

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

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

　　測試方法：

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

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

　　推流視頻

　　測試結果：

　　弱網環境1：delay 100ms loss 1%

　　1)RTMP over TCP測試截圖：

　　2)RTMP over QUIC測試截圖：

　　弱網環境2：delay 150ms loss 5%

　　1)RTMP over TCP測試截圖：

　　2)RTMP over QUIC測試截圖：

　　弱網環境3：delay 200ms loss 10%

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

　　1)RTMP over TCP測試截圖：

　　2)RTMP over QUIC測試截圖：

　　弱網環境4：loss 20%

　　在這種弱網環境下，RTMP over TCP推流非常卡無法正常推流，播放器拉流馬上就被斷開;而RTMP over QUIC推流和播放都很流暢，在持續5分鐘的播放過程中0次卡頓，流暢度100%，效果非常好。

　　RTMP over QUIC測試截圖：

　　弱網環境5：delay 500ms，loss 30%

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

　　RTMP over QUIC測試截圖：

特別提醒：本網內容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。