導讀：網易云信作為音視頻服務提供商的領導者，一直致力于提供頂級的音視頻通話服務體驗，為用戶在各種惡劣環境下提供可靠的音視頻服務。

文｜紀松

網易云信資深音視頻服務端開發工程師

如何在極端弱網條件下仍然能給用戶提供可靠的音視頻服務，是網易云信關注的重中之重。本文將闡述網易云信為了提高可靠數據在弱網環境及時性所采用的架構技術方案。

引言

市面上多數傳統的音視頻服務基于 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 直播業務。在音視頻數據傳輸和網絡數據轉發方面有著豐富的經驗。

?延伸閱讀?

• 網易云信在融合通信場景下的探索和實踐之 SIPGateway 服務架構

• 技術實踐 | 聊聊網易云信的信令網絡庫實踐

總結

以上是生活随笔為你收集整理的技术实践 | 网易云信 QUIC 加速服务架构与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。