導讀：網易雲信作為音視訊服務提供商的領導者，一直致力於提供頂級的音視訊通話服務體驗，為使用者在各種惡劣環境下提供可靠的音視訊服務。如何在極端弱網條件下仍然能給使用者提供可靠的音視訊服務，是網易雲信關注的重中之重。本文將闡述網易雲信對於 QUIC 協議的應用優化實踐。
引言
QUIC 協議從傳輸層面相較 TCP 的幾點優勢
- 0-RTT 建連
QUIC 協議基於 UDP，本身無需握手，並且其使用 Diffie-Hellman 或者 ECC 演算法，只在 1-RTT 就完成對等祕鑰的協商。QUIC 協議的 0-RTT 建連使用 TLS1.3，通過 early_data 完成加密資料透傳。
- 多路複用/無對頭阻塞
相比於 HTTP/2 的多路複用，QUIC 不會受到隊頭阻塞的影響，各個流更獨立，多路複用的效果也更好。
- 連線遷移
與 TCP 用四元組標識一個唯一連線不同，QUIC 使用一個 64 位的 ConnectionID 來標識連線，基於這個特點，QUIC 的使用連線遷移機制，在四元組發生變化時（比如客戶端從 WIFI 切換到蜂窩行動網路），嘗試“保留”先前的連線，從而維持資料傳輸不中斷。
- 可定製的擁塞控制
QUIC 協議沒有定義擁塞控制演算法的使用，這部分實現在應用層，方便開發者自行優化迭代。
QUIC 協議從協議層面相較 TCP 的幾點差別
- Separate Packet Number Spaces
QUIC 協議定義了 4 種不同的加密級別，各種加密級別使用不同包序列號空間。
- Monotonically Increasing Packet Numbers
相同包序列號空間中的包序列號單調遞增，避免了重傳歧義。QUIC 協議的包序列號空間只標識傳輸順序，資料包內容的順序則用 STREAM 幀當中的偏移（offset）來標識。
- Clearer Loss Epoch
當一個 QUIC 包被申明為丟失，QUIC 開啟一段丟失檢測的週期，在此之後傳送的任何一個 QUIC 包被確認則重新整理檢測週期的時間。與 TCP 不同，TCP 會一直等待序列號空間中的空白被填滿儘管有可能在傳輸過程中相同資料包發生了多次丟失。這樣做的意義在於：QUIC 可以更精確地在每個往返時間（RTT）內去更新擁塞視窗的大小。
- No Reneging
不能食言。一旦一個包被對端確認，則改包不能再被申明為丟失。這樣的設定大大簡化了雙端傳輸協議的設計，也減小了傳送端的記憶體壓力。
- More ACK Ranges
相比 TCP 的 SACK 只能確認三個段（範圍），QUIC 協議的 ACK 幀支援更多的段（範圍）確認。在高丟包場景下，加快了重傳恢復的速度，避免零散的範圍確認導致的傳輸中斷。
- Explicit Correction For Delayed Acknowledgements
QUIC 協議將計算從接收包到傳送該包 ACK 之間的延遲時間，並顯式寫入 ACK 幀中。這樣的設定旨在更加精準地計算網路的往返時間。
- Probe Timeout Replaces RTO and TLP
QUIC 協議使用 PTO（probe timeout）探測超時機制，包含了對端的期望最大確認延時，而不是一個固定的最小超時。與 TCP 的 RTO 超時不同的是，QUIC 協議在 PTO 過期時不會去嘗試摺疊擁塞視窗，因為尾部資料的丟失並不能表示網路發生了持續的擁塞。傳送方可以不受限制地傳送更多的資料包在其還有剩餘的擁塞視窗的條件下，即便此時已經發生了 PTO 超時。相對於 TCP 的 RTO 機制，PTO 機制更加激進。
- The Minimum Congestion Window is Two Packets
TCP 使用一個資料包作為最小擁塞視窗，如果這個資料包丟失了，意味著需要等待 RTO 來進行重傳，這很可能遠遠大於一個往返時間（RTT），QUIC 協議建議使用兩個資料包作為最小擁塞視窗，雖然這樣做會增加流量，但是被認為是安全的。
QUIC 協議在網易雲信的應用
在網易雲信音視訊服務的架構中，信令用於 SDP 的互動、會話房間的建立與管理、使用者資訊的上傳與下發等，其傳輸的穩定性和及時性至關重要。傳統的 WEBRTC 建議使用 WebSocket 作為信令傳輸協議，受限於 TCP 協議的缺陷，其在建連時間、傳輸效率和弱網抗性方面的效果不盡人意。而這些問題直接影響到音視訊服務的基線指標，比如首幀時間、鏈路的穩定性以及弱網抗性等。
雲信 QUIC 加速服務設計：
網易雲信使用 QUIC 協議替代 WebSocket 協議進行信令的傳輸，並在應用和協議層面做了若干優化實踐：
- 多路複用：根據不同信令的特性，給請求分類分級。對於 Request/Reponse 型別的訊息，其可靠性和實時性的要求最高，使用高優先順序的 STREAM 進行傳輸。對於用於鏈路保活的心跳訊息，則使用較低優先順序的 STREAM 進行傳輸。
- 不可靠的傳輸擴充：有一類 Notify 訊息型別，不需要接收端進行回覆，往往用於廣播各端使用者的網路狀態或者其他資訊。其對於實時性的要求很高，但是對可靠性沒有很高的要求。對於這種信令，我們可以使用 QUIC 協議的不可靠傳輸特性進行傳輸。
這種特殊的傳輸使用一種 DATAGRAM 幀，傳輸這種特殊的幀，需要在 Initial 包中的 CH 模組的 QUIC 傳輸參數列中進行申明(name=max_datagram_frame_size, value=0x20)，用以通告對端對於 DATAGRAM 幀的支援。max_datagram_frame_size 傳輸引數是一個整數值（表示為可變長度整數），表示端點願意接收的 DATAGRAM 幀的最大大小（包括幀型別、長度和有效負載），以位元組為單位。
DATAGRAM 幀用於以不可靠的方式傳輸應用程式資料。幀中的 Type 欄位採用 0b0011000X 的形式（或值 0x30 和 0x31），最低有效位是 LEN 位（0x01），表示是否存在 Length 欄位：如果該位設定為 0，則 Length 欄位不存在，Datagram Data 欄位擴充套件到資料包的結尾；如果該位設定為 1，則存在長度欄位。DATAGRAM 幀的結構如下：
儘管 DATAGRAM 幀在檢測到丟失時不會進行重傳，但也是需要被 ack 的。
- 報文壓縮：雲信在傳輸層引入了 Deflate 演算法對 STREAM 幀進行壓縮，旨在降低信令傳輸的頻寬佔用。
- 動態的冗餘策略：因為信令非流式資料，FEC 並不能適用於斷續資料的傳輸，以 RTT 和丟包率等指標動態地增加冗餘保護對提升傳輸的弱網抗性也有相當積極的作用。
雲信 QUIC 的弱網表現
首屏耗時和登入耗時
上圖是雲信音視訊業務信令建連使用 TCP 和 QUIC 的對比。在首幀耗時的指標上，QUIC 有 20% 的提升。在登入耗時的指標上，QUIC 有接近 30% 的提升。主要的原因是 QUIC 的建連對比 TCP+TLS 有 2~3 個 RTT 的優化，在高 RTT 的場景下握手時間縮短尤為明顯。在直播場景下，雲信 QUIC 做了私有化的 0RTT 握手的優化，建連更加快速。
抗丟包性
上圖是雲信信令資料在 QUIC 和 TCP 鏈路下能夠抗住的最大丟包率。QUIC 在上行丟包率達到 70% 的條件下仍然可以提供服務，下行邊界甚至可以抗住 75% 的丟包。TCP 鏈路在 45% 的丟包情況下就會出現斷開重連。相對於 TCP 的信令鏈路 QUIC 鏈路有 50% 的提升。
主要原因：
- 雲信實現了動態冗餘，會檢測到丟包之後增加冗餘度，這樣就用冗餘包彌補了高丟包，帶來了抗丟包效能。
- QUIC 改進的流量控制和擁塞控制演算法讓 QUIC 在弱網路下可能取得更大的傳輸優勢。
帶限
我們還做了在頻寬受限的情況下，QUIC 對於頻寬的使用率，基本上 QUIC 對於頻寬的使用率都能達到 90% 以上，然而 TCP 就要差很多。
展望&總結
網易雲信在可靠資料加速上可靠資料傳輸上已經得到很大的提升，但是仍然還有一些需要優化的地方：一旦單向發生丟包，會引起伺服器和端都增加雙向的冗餘度，帶來不必要的冗餘增加。後續會檢測到單向丟包，只針對丟包的鏈路進行冗餘度增加。對於高 RTT 和高丟包場景，QUIC 擁塞控制演算法需要持續優化。網易雲信將持續在音視訊領域，在各種極端情況下為使用者提供優質的服務。