一. 視頻直播的痛點：卡頓
卡頓是最影響直播體驗的因素之一，也是最難解決的問題之一。在流媒體的傳輸鏈路中，任何一個環節丟包都可能導致用戶觀看卡頓。
其中，主播端的推流卡頓最影響觀看體驗，會直接影響到所有觀看直播的最終用戶。主播推流卡頓在部分場景會特別顯著，比如戶外直播就非常考驗在網絡狀況複雜的情況下推流的穩定性。
減少卡頓一直是開發者重大的技術挑戰，那麼繼續看看我們又有什麼樣的對策呢？
Google 從 2014 年推出 QUIC 協議後一直在音視頻產品上實踐該協議。現在，經過一年多的探索和實踐，我們的直播雲產品已經擁抱 QUIC，最新推出的直播 QUIC 推流方案可以大幅度的降低直播的卡頓問題，可以在各種複雜網絡環境下給客戶提供優秀的直播體驗。（關於QUIC協議的詳細介紹請閱讀《技術掃盲：新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》）
二. QUIC 是什麼，爲什麼可以降低卡頓？
既然 QUIC 可以解決如此重要的直播體驗問題，那麼我們先從整體瞭解一下 QUIC 協議（關於QUIC協議的詳細介紹請閱讀《技術掃盲：新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》）。
2.1 QUIC 協議的定義
QUIC 全稱 Quick UDP Internet Connection, 是谷歌公司制定的一種基於 UDP 協議的低時延互聯網傳輸協議。
我們知道，TCP/IP 協議族是互聯網的基礎。其中傳輸層協議只有兩種： TCP 和 UDP 協議。與 TCP 協議相比，UDP 更爲輕量，但是錯誤校驗也要少得多。由於 UDP 是不可靠協議，不保證按序送達，所以其可靠性比不上 TCP 協議。
QUIC 傳輸層基於 UDP 協議但卻是一種可靠的傳輸協議，因爲它將很多可靠性的驗證策略從系統層轉移到應用層來做，這樣可以使用更適合現代流媒體傳輸的擁塞控制策略。
關於TCP和UDP的差異，以下文章可以給您一些答案：
2.2 QUIC 在網絡傳輸中所處的位置
從圖上可以看出，QUIC 傳輸層用 UDP 協議替代了 TCP。（另外，更深入的計算機網絡協議關係圖請見《計算機網絡通訊協議關係圖（中文珍藏版）[附件下載]》）
2.3 QUIC 在傳輸上爲什麼有優勢
從上面所有對 QUIC 的定義上來看，很明顯 QUIC 的對比對象是 TCP。所以下面所有的優勢的枚舉都是基於 QUIC 和 TCP 的比較。
【QUIC優勢1：更出色的擁塞控制】
雖然例如 HTTP/2 或者 SPDY 協議現在都支持將頁面的多個數據通過一個數據鏈接進行傳輸，該特性也確實能夠加快數據的傳輸速度。但是由於 TCP 協議在處理包時是有嚴格順序的，所以還是會遇到隊首阻塞的問題。
比如發生如下圖所示場景下的問題時，當其中一個數據沒有發送成功，TCP 連接需要等待這個包完成重傳之後才能繼續進行。因此，即使邏輯上一個 TCP 連接上並行的在進行多路數據傳輸，其他毫無關聯的數據也會因此阻塞：
QUIC 協議直接通過傳輸層使用 UDP 協議就可以避免該問題的發送。由於 UDP 協議沒有嚴格的順序要求，當一個數據包遇到問題需要重傳時只會影響該數據包對應的資源，其他獨立的資源不會受到影響而阻塞傳輸：
【QUIC優勢2：更加靈活】
TCP 協議棧通常由操作系統層面來實現，例如如 Linux、Windows、iOS、Android 操作系統。因此如果要修改 TCP 協議需要從操作系統層面去做很多事情，這是一項複雜的工程。相對來說 UDP 協議在操作系統層面實現更爲簡單，QUIC 基於 UDP 在應用層做了很多網絡擁塞控制層面的優化，幫助用戶減少複雜網絡下的卡頓率，提高流暢度，這是 TCP 無法做到的。
2.4 QUIC小結
從以上所有的介紹中可以看出，如果我們需要使用 QUIC 改善直播體驗，就是用它來代替直播中 TCP 協議所扮演的角色。大家都清楚目前直播所使用的協議都基本是 RTMP 協議,而 RTMP 協議的傳輸層是基於 TCP 協議。所以我們的 QUIC 推流方案就是把 RTMP 當中的傳輸層協議換成 QUIC，從而達到推流卡頓率下降的效果。
三. 使用 QUIC 後的效果
上面說了那麼多基於 QUIC 做媒體傳輸的理論優勢，那麼有沒有實際的實驗測試作爲理論的支撐呢？下面一起來看看測試數據吧。
測試的參數配置：
測試方式：
使用 ATC 模擬的弱網環境下，用 srs 播放器播放 5 mins，記錄流暢度和卡頓次數。
3.1 測試場景之弱網配置一
ATC配置：delay 100ms loss 1%
結果分別如圖所示：
3.2 測試場景之弱網配置二
ATC配置：delay 200ms loss 10%
測試結果如圖所示：
而在 TCP 這種網絡配置下，推不起來，或者推一會就會斷開。