導語：網易雲信作爲音視頻服務提供商的領導者，一直致力於提供頂級的音視頻通話服務體驗，爲用戶在各種惡劣環境下提供可靠的音視頻服務。如何在極端弱網條件下仍然能給用戶提供可靠的音視頻服務，是網易雲信關注的重中之重。本文將闡述網易雲信爲了提高可靠數據在弱網環境及時性所採用的架構技術方案。
引言
市面上多數傳統的音視頻服務基於 TCP 協議做可靠數據的傳輸，但是因爲 TCP 自身協議的特性，有着天生的一些缺陷，例如：
- 傳輸效率低
TCP 無私的傳輸特性，導致傳輸慢，效率較低，在弱網下更明顯。
- 建聯延遲大
三次握手的安全設計引起首次建聯耗時高，會引起首屏出現較晚。
- 抗弱網特性差
TCP 的可靠傳輸特性決定了，較小的丟包就會引起鏈路斷開。
- 隊頭阻塞嚴重
包文有序依次傳輸，小序列號包的丟失會引起後面包文阻塞，直到重傳成功。
這些缺陷導致傳統音視頻服務在弱網環境下，可靠數據鏈路先於媒體鏈路斷開，信令延遲到達，影響用戶體驗。如何提高可靠數據鏈路的可靠性和及時性是所有音視頻服務提供商需要解決的問題。隨着技術發展，當前熱門協議 QUIC 應運而生。
QUIC 概述以及優勢
QUIC 全稱 Quick UDP Internet Connection，即快速 UDP 互聯網連接，是由 Google 於2013年提出，使用 UDP 進行多路併發傳輸的協議。QUIC 使用 UDP 協議，在兩個端點間創建連接，且支持多路複用連接。在設計之初，QUIC 希望能夠提供等同於 SSL/TLS 層級的網絡安全保護，減少數據傳輸及創建連接時的延遲時間，雙向控制帶寬，以避免網絡擁塞。下面，我們一起來看看 QUIC 相對於 TCP 的優勢。
- **簡化 TLS 的握手流程，降低首次建連 RTT **
QUIC 協議做的最大優化即簡化握手流程到 0/1RTT。衆所周知，HTTPS 的握手需要 3RTT 的耗時，然而 QUIC 建聯最多隻消耗 1RTT。如下圖，說明了 TCP 的握手繁瑣流程，然而 QUIC 將該繁瑣流程降低到了 0-1 個 RTT。
- 採用多流策略，某個流的隊頭阻塞不會引起另外一個流的數據阻塞。
應用層的協議數據通過流交換信息，每個流內是有序序列的字節，而流之間沒有順序關係，流與流之間是相互隔離，相互獨立的。如果某個流出現丟包或者傳輸不可達，不會影響連接中其他流的數據。這樣設計可以避免 TCP 協議中的隊頭阻塞，我們需要做的是把不同優先級的數據進行隔離即可。
- 改進擁塞控制算法
TCP 的擁塞控制是針對一條連接的，所有的傳輸受控於一個擁塞控制模塊。然而 QUIC 是可以做到對於每條流做流控。
- 支持動態連接遷移
連接遷移即當連接四元組中任何一個元素髮生變化時，這條連接依然維持，能夠保持業務邏輯不中斷。QUIC 之所以能支持連接遷移，是因爲 QUIC 不再用四元組標識連接，而是以一個 64 位的隨機數作爲 ConnctionID 來標識，這樣就算 IP 或者端口發生變化，只要 ConnctionID 不變，這條連接依然維持着，上層業務邏輯不會感知到變化，就不會中斷，也就不需要重連。
- 實現前向糾錯，通過發送冗餘包來減少重傳
QUIC 會對一些優先級較高的包進行冗餘發送，丟失的數據包可以通過冗餘包計算，減少重傳次數以提高傳輸效率。
以上這些 QUIC 優點在互聯網行業都有着很大的吸引力，網易雲信也參考了這些優點，在此基礎上設計了自己的加速代理架構。
網易雲信可靠鏈路的加速架構
網易雲信參考 QUIC 的優勢，自研了 QUIC 加速代理服務，爲端到邊緣服務器節點提供可靠數據傳輸的代理服務，提高可靠數據的及時性。下圖爲網易雲信加速代理的架構圖。
如上圖，雲信採用 QUIC 協議和 TCP 協議並行的設計，客戶端同時支持 QUIC 鏈路和 TCP 鏈路建聯。正常情況下，客戶端會優先使用 QUIC 協議。客戶端通過連接到 QUIC 加速服務來連接到後端，在 QUIC 連接失敗的情況下，纔會選擇備用 TCP 鏈路建聯直接連接後端。網易雲信之所以保留原 TCP 協議接入，目的是用來做某些用戶場景下 UDP 不可用的補充，保證程序的高可用性。
網易雲信加速架構設計初衷
我們採用此架構設計的初衷是出於以下幾點考慮：
- 對最後一公里加速
距離用戶最後一公里爲最容易出現弱網故障的鏈路，在該鏈路上對用戶可靠數據進行加速，可以實現事半功倍的效果。
- UDP/TCP 的雙保險，提升高可用性
某些局域網防火牆中禁用了 UDP 協議，在該網絡環境下，UDP 報文不可達。該網絡環境下，基於 UDP 的 QUIC 協議包將會被全部丟棄。在該網絡環境下只能寄希望於 TCP 傳輸，所以雲信將 TCP 選取爲數據鏈路的備份。
- 加速服務與業務相互隔離，加速服務不關心業務數據
網易雲信加速服務，作爲一個透明的協議，只負責接受 QUIC 包文，解開包文透傳給後端。加速代理服務不關心 QUIC 承載的內容，所以擴展性較大，可以用來給很多需要加速業務做數據傳輸加速。
- 兼容原有架構
爲老客戶提供彈性升級策略是雲信產品升級策略之一，所以該架構的部署不能影響老用戶，老用戶可以保留原先的鏈路，新用戶則默認採用加速鏈路。
下面，我們來詳細看一下網易雲信加速服務器的架構設計。
數據加速服務器的架構設計
數據加速代理服務器分爲兩大模塊，QUIC 前代理模塊和後代理模塊。
QUIC 前代理模塊
QUIC 前代理模塊，啓動一個 UDP 監聽，監聽客戶端用戶 QUIC 報文，前代理模塊主要負責以下工作：
- 接收客戶端 QUIC 協議的 UDP 包文
- 對收到的包進行 QUIC 解包和冗餘度過濾
- 對於將要發送的包文進行 QUIC 協議打包
- 按照網絡情況計算帶寬和冗餘度，發送冗餘包
- 對收到的包文進行完整性校驗
QUIC 後代理模塊
QUIC 後代理模塊負責與後端建立 TCP 連接或者跟後端發起 http 請求，後代理模塊主要工作內容爲：
- 按照前端的請求，向後端發起連接請求
- 對前端代理的業務數據包進行打包，透傳給後端服務器
- 接受後端服務器的業務包，並且進行壓縮和正校驗在送給前端代理模塊，由前代理模塊進行 QUIC 協議轉發
前端代理與後端的服務器一般會進行就近部署或者同機部署，所以幾乎可以忽略代理到後端服務器的延遲。主要延遲產生爲端與前端代理之間的延遲，優化的重點轉爲增加端到前端代理的 QUIC 傳輸優化。
基於 QUIC 加速服務實現的音視頻服務優化
在 QUIC 加速服務的基礎上，網易雲信主要做了以下幾方面優化：
- 首屏打開速度優化
雲信客戶端與服務器實現耗費至 0-1RTT 來建連，相比 TCP+TLS+HTTP/2 的 3RTT 建連，具有很大的優勢。在成功連接之後，一旦客戶端緩存或持久化客戶端配置，就可以複用並結合本地生成的私鑰進行加密數據傳輸，不需要再次握手，從而實現 0RTT 建立連接。這樣給用戶首屏打開速度至少帶來了 2RTT 的延遲降低。特別在一些網絡差的偏遠地區，可以降低 100-300ms 的首屏延遲，提高了用戶體驗。
- 多 Streams 設計
QUIC 鏈路下創建多個 Streams，分別用於不同應用層協議數據的傳輸，各個 Stream 傳輸相互隔離，不會因爲優先級低的數據隊頭阻塞會影響另外優先級高的數據接受和發送。
- 信令優先級分級設計
優先級高的數據採用較高的冗餘度發送，優先級較低冗餘度也較低，從而保證優先級高的數據優先到達，並且優先層級低的數據不會阻塞優先級高的信令傳輸。
- 可選配置的傳輸數據壓縮
數據代理支持 zlib 壓縮，針對一些信令字符 Json 數據，zlib 壓縮對於字符壓縮，壓縮率可以達到 20%。通過壓縮，可以降低傳輸帶寬，緩解帶寬受限的擁塞。
- 引入 CRC 對傳技術數據進行校驗
QUIC 是流式數據，新增對於傳輸的每條數據進行 CRC 校驗，一旦校驗失敗，隨即斷開連接，保證數據傳輸的可靠性和準確性，以免影響業務。
- 根據網絡狀況，動態調整冗餘度
通過 nacked 包的情況，來評估全鏈路網絡情況，發生了 unnacked 則正向調整冗餘度，反之待穩定後降低冗餘度。最大限度節省帶寬佔用，節省用戶帶寬，避免隊列擁塞。
網易雲信加速服務的弱網性能表現
我們在進行數據加速之後與未加速的情況做了一系列的對比，特別做了在弱網環境下的對比。
首屏耗時和登錄耗時
上圖是雲信音視頻業務 QUIC 和 TCP 的首屏打開耗時和登錄流程耗時。可以看到首屏打開有20%的提升，登錄有將近30%的提升，效果較明顯。原因主要因爲 QUIC 實現了0-1次 RTT 的握手流程，特別對於一些偏遠省份，可以省下 100ms 的延遲，效果較爲明顯。
抗丟包能力
上圖是雲信信令數據在 QUIC 和 TCP 鏈路下能夠抗住的最大丟包率。QUIC 在上行丟包率達到70%的條件下仍然可以提供服務，下行邊界甚至可以抗住75%的丟包。TCP鏈路在45%的丟包情況下就會出現斷開重連。相對於 TCP 的信令鏈路 QUIC 鏈路有50%的提升。主要原因：
- 雲信實現了動態冗餘，會檢測到丟包之後增加冗餘度，這樣就用冗餘包彌補了高丟包，帶來了抗丟包性能。
- QUIC 改進的流量控制和擁塞控制算法讓QUIC在弱網絡下可能取得更大的傳輸優勢。
帶寬受限
我們還做了在帶寬受限的情況下，QUIC 對於帶寬的使用率，基本上 QUIC 對於帶寬的使用率都能達到90%以上，然而 TCP 就要差很多。
測試結論
在丟包方面，雲信得到了50%的抗丟包性能提升，在首屏打開速度上雲信也有20%的提升 ，並且在帶寬受限制的情況下，也能夠達到90%的帶寬使用率，是音視頻服務業內領先的水準。
展望&總結
網易雲信在可靠數據加速上可靠數據傳輸上已經得到很大的提升，但是仍然還有一些需要優化的地方：
- 一旦單向發生丟包，會引起服務器和端都增加雙向的冗餘度，帶來不必要的冗餘增加。後續會檢測到單向丟包，只針對丟包的鏈路進行冗餘度增加。
- 對於高 RTT 和高丟包場景，QUIC 擁塞控制算法需要持續優化。
網易雲信將持續在音視頻領域，在各種極端情況下爲用戶提供優質的服務。
作者簡介
紀松，網易雲信資深音視頻服務端開發工程師，負責雲信雲信直播業務和音視頻數據鏈路加速業務，曾負責併發 70 萬人的 TFboys 直播業務。在音視頻數據傳輸和網絡數據轉發方面有着豐富的經驗。