QUIC 技術創新讓視訊和圖片分發再提速

語言: CN / TW / HK

時間 2022-01-18 14:39:32 我是程式設計師

主題: CDN

隨著網際網路的快速發展，基礎網路環境也在發生變化，WEB網路協議也經歷了HTTP1.0、HTTP1.1、HTTP2.0以及即將迎來HTTP3.0; HTTP3.0將以QUIC協議替代TCP作為傳輸層，具備stream多路複用、握手0RTT、連線遷移以及使用者態擁塞演算法諸多優勢。CDN產品關注QUIC協議演進並實踐落地，從gQUIC協議到標準IETF QUIC協議已經部署在CDN邊緣節點，並在短視訊和圖片業務場景實踐有不錯的收益。

在1月12日的「阿里雲CDN產品釋出會-新一代傳輸協議QUIC讓CDN更快一步」之上，阿里雲技術專家淮葉分享了QUIC技術及其應用落地實踐。本文根據分享內容梳理，包括以下三個部分：

QUIC協議介紹，包括協議誕生歷史、基礎特性、相比TCP有哪些優勢，以及QUIC協議可以應用在哪些業務場景
CDN QUIC技術落地實踐，包括協議庫選擇，QUIC協議軟體實現以及QUIC落地技術架構，以及QUIC效能優化，QUIC產品如何接入使用
CDN QUIC技術落地場景，主要介紹阿里巴巴集團業務使用QUIC加速後的收益，以及背後的一些優化措施

QUIC協議介紹

當我們訪問視訊網站和APP應用時，經常會遇到各種各樣的效能問題，網頁載入慢、視訊卡頓、網路出錯，其中關鍵影響因素就是網路協議。

HTTP 協議作為網際網路web協議，經歷了幾次重要的升級：

HTTP1.0 -> HTTP1.1： 支援長連線，請求pipeline特性，通過減少了TCP三次握手，降低連線建立的開銷

HTTP -> HTTPS： 增加TLS層握手，傳輸內容加解密，因增加安全特性，故增加建連延遲

HTTP1.1 -> HTTP2： H2特性是請求資料流的多路複用與頭部壓縮，提高了單連線的併發能力

從HTTP1.0升級到HTTP2，其中傳輸層協議沒有變化都是基於TCP協議。TCP協議是可靠傳輸協議，需要三次握手狀態，還有隊頭阻塞問題，為了解決這些問題，基於UDP設計實現的一種可靠傳輸協議——QUIC協議應運而生。因此，HTTP協議再次升級。

HTTP2->HTTP3： HTTP3基於QUIC協議，因此具備QUIC協議的傳輸特性，解決TCP隊頭阻塞問題，具備TLS1.30-RTT、H2多路複用能力，還具備連線遷移能力。QUIC協議已於2021年5月正式標準化，編號為RFC9000。

QUIC 協議解決了哪些問題

1. 低連線延時

QUIC 基於 UDP，無需 TCP 連線，最好情況下，QUIC 可以做到 0RTT 開啟資料傳輸。而基於 TCP 的 HTTPS，即使在TLS1.3的early data下仍然需要 1RTT 開啟資料傳輸。然而對於常見的 TLS1.2 完全握手的情況，則需要 3RTT 開啟資料傳輸。

2. 無隊頭阻塞

雖然 HTTP2 實現了多路複用，但是傳輸層依然使用的是TCP，一旦出現某個報文丟包，將會影響多路複用下的所有請求流。然而QUIC 基於 UDP，在設計上就解決了隊頭阻塞問題。同時HTTP3使用 QPACK 編碼替換 HPACK 編碼，在一定程度上也減輕了 HTTP 請求頭的隊頭阻塞問題。

3. 使用者態擁塞控制

QUIC 的傳輸控制不再依賴核心的擁塞控制演算法，而是實現在應用層上。這意味著可以根據不同的業務場景，實現配置不同的擁塞控制演算法以及引數，甚至同一個業務的不同QUIC連線也可以使用不同的擁塞控制演算法。

4. 連線遷移

當實際使用者的網路發生變化時，從 WIFI 網路切換到 4G 網路時，使用者地址發生變化，基於 TCP 的 HTTP 協議無法保持連線的存活；而QUIC 基於連線 CID 作為連線標識, 仍然可以保證連線存活和資料正常收發。

QUIC協議與TCP協議對比

既然QUIC協議設計初衷是解決傳輸層協議問題，與其競對的就是TCP協議，那麼從傳輸協議特性分析兩種協議設計差異，可得出以下對比：

QUIC為每個加密級別使用單獨的包號空間，除了0-RTT和1-RTT金鑰使用相同的包號空間，隔離的包號空間可以確保使用一種加密級別傳送包的ACK, 不會引起使用其他加密級別傳送的包的虛假重傳問題。
QUIC的包號嚴格按照包號空間遞增，直接編碼傳輸順序。報文號越高表示報文傳送時間越晚，報文號越低表示報文傳送時間越早。當一個包含應答幀的包被檢測到丟失時，QUIC會在一個新的包中包含必要的幀，並新增一個新的包號，從而消除了當收到應答時確認哪個包的不確定性。因此，可以進行更精確的進行RTT測量，可以輕鬆地檢測到虛假重傳。
Quicack幀包含類似於TCP選擇性應答(sack)的資訊。然而QUIC不允許資料包的確認被違背，這大大簡化了雙方的實現，並降低了傳送方的記憶體壓力。
與TCP的三個SACK範圍相反，QUIC支援許多ACK範圍。在高丟包環境中，這種方法可以加快恢復速度，減少虛假重傳。
TCPRTT測量使用傳送包和確認包時間戳計算，未考慮主機延遲問題，QUIC使用ACKDelay機制，使得路徑RTT測量更加準確。
QUIC使用PTO探測超時機制，代替TCP的RTO&TLP。
TCP使用一個包的最小擁塞視窗。如果丟失單個數據包意味著傳送方需要等待PTO來恢復，當接收方延遲確認時，傳送一個單一的ack-eliciting包也增加了引起額外延遲。因此，QUIC建議最小擁塞視窗為兩個包。雖然這增加了網路負載，但它被認為是安全的，因為在持續擁塞的情況下，傳送方仍然會以指數方式降低傳送速率。

QUIC協議可以加速哪些場景

動態請求(API和信令傳輸場景)：降低動態互動耗時
短視訊：提升首屏秒開率，降低卡頓率
圖片檔案下載：降低檔案下載總耗時
直播：降低播放卡頓率，提升推流穩定性

CDN QUIC技術落地實踐

關於協議庫如何選擇？

QUIC 協議棧的實現版本庫很多，但協議功能實現的全面性各有不同，通過QUIC協議互通性測試報告，可以瞭解各協議庫的QUIC特性支援程度。

CDN在QUIC協議上的實踐路線，是從gQUIC版本開始調研實現，然後跟進QUIC標準化進度，然後支援 IETFQUIC標準，並實現HTTP3接入服務。選擇gQUIC的原因是GOOGLE是QUIC協議的開創者，基於chromium實現的QUIC協議棧最早，功能最齊，實現上也最為標準，因此選擇了它。

關於IETFQUIC協議版本，NGINX官方已實現了一個基礎版本，生產環境使用仍然存在很多問題沒解決，擁塞控制演算法沒有實現；但從QUIC協議互通測試報告看，QUIC協議實現比較全面，並且效能也不錯，相信NGINX官方很快就會把QUIC分支合入主幹。同時，補全了其缺失功能，比如擁塞演算法。

gQUIC&IETFQUIC相容架構

我們選擇了兩套不同的QUIC協議棧實現版本，來分別支援gQUIC和IETFQUIC，其中gQUIC版本支援Q039,Q043,Q046，IETFQUIC支援h3-29quicv1。

gQUIC協議庫，自從2018年調研嵌入到CDN服務，我們從chromium裁剪出net網路庫部分，開發QUIC模組，以及自研擁塞演算法。隨著IETFQUIC協議草案逐漸成熟，2020年RFC草案基本定稿，CDN也開始IETFQUIC實現調研，我們基於NGINX官方QUIC版本進行深度開發，解決QUIC加密庫、擁塞演算法、資源運維等問題，達到CDN上線標準。現在CDN QUIC同時支援gQUIC和IETFQUIC兩種版本，客戶接入無需更換域名，更換排程域。（CDN實現已經做了協議分流）

CDN QUIC技術架構實現

技術架構實現分為兩個元件：QUIC-LB 和 QUIC-Server

QUIC-LB: 主要實現根據QUIC連線CID選擇後端QUIC-Server邏輯

QUIC-Server： 實現QUIC協議棧特性，並且根據連線CID選擇已建立會話的worker進行服務

在 CDN QUIC 技術落地實踐中，我們面臨一個難題是QUIC傳輸帶來的CPU資源損耗高於TCP協議棧的CPU消耗，QUIC 協議將 TCP協議棧的特性從核心移到了應用層，從目前開源 QUIC 實現版本來看，效能相比 TCP 還有差距。因為TCP長期使用以來，從協議棧到網絡卡經過了非常多的優化，相比之下，UDP的優化很少。除了核心和硬體外，QUIC 協議的效能也與其實現有關，不同的實現版本可能也會有很大的差距。