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

文｜紀松

網(wǎng)易云信資深音視頻服務端開發(fā)工程師

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

引言

市面上多數(shù)傳統(tǒng)的音視頻服務基于 TCP 協(xié)議做可靠數(shù)據(jù)的傳輸，但是因為 TCP 自身協(xié)議的特性，有著天生的一些缺陷，例如：

• 傳輸效率低

TCP 無私的傳輸特性，導致傳輸慢，效率較低，在弱網(wǎng)下更明顯。

• 建聯(lián)延遲大

三次握手的安全設計引起首次建聯(lián)耗時高，會引起首屏出現(xiàn)較晚。

• 抗弱網(wǎng)特性差

TCP 的可靠傳輸特性決定了，較小的丟包就會引起鏈路斷開。

• 隊頭阻塞嚴重

包文有序依次傳輸，小序列號包的丟失會引起后面包文阻塞，直到重傳成功。

這些缺陷導致傳統(tǒng)音視頻服務在弱網(wǎng)環(huán)境下，可靠數(shù)據(jù)鏈路先于媒體鏈路斷開，信令延遲到達，影響用戶體驗。如何提高可靠數(shù)據(jù)鏈路的可靠性和及時性是所有音視頻服務提供商需要解決的問題。隨著技術發(fā)展，當前熱門協(xié)議 QUIC 應運而生。

QUIC 概述以及優(yōu)勢

QUIC 全稱 Quick UDP Internet Connection，即快速 UDP 互聯(lián)網(wǎng)連接，是由 Google 于2013年提出，使用 UDP 進行多路并發(fā)傳輸?shù)膮f(xié)議。QUIC 使用 UDP 協(xié)議，在兩個端點間創(chuàng)建連接，且支持多路復用連接。在設計之初，QUIC 希望能夠提供等同于 SSL/TLS 層級的網(wǎng)絡安全保護，減少數(shù)據(jù)傳輸及創(chuàng)建連接時的延遲時間，雙向控制帶寬，以避免網(wǎng)絡擁塞。下面，我們一起來看看 QUIC 相對于 TCP 的優(yōu)勢。

• 簡化 TLS 的握手流程，降低首次建連 RTT

QUIC 協(xié)議做的最大優(yōu)化即簡化握手流程到 0/1RTT。眾所周知，HTTPS 的握手需要 3RTT 的耗時，然而 QUIC 建聯(lián)最多只消耗 1RTT。如下圖，說明了 TCP 的握手繁瑣流程，然而 QUIC 將該繁瑣流程降低到了 0-1 個 RTT。

• 采用多流策略，某個流的隊頭阻塞不會引起另外一個流的數(shù)據(jù)阻塞。

應用層的協(xié)議數(shù)據(jù)通過流交換信息，每個流內是有序序列的字節(jié)，而流之間沒有順序關系，流與流之間是相互隔離，相互獨立的。如果某個流出現(xiàn)丟包或者傳輸不可達，不會影響連接中其他流的數(shù)據(jù)。這樣設計可以避免 TCP 協(xié)議中的隊頭阻塞，我們需要做的是把不同優(yōu)先級的數(shù)據(jù)進行隔離即可。

• 改進擁塞控制算法

TCP 的擁塞控制是針對一條連接的，所有的傳輸受控于一個擁塞控制模塊。然而 QUIC 是可以做到對于每條流做流控。

• 支持動態(tài)連接遷移

連接遷移即當連接四元組中任何一個元素發(fā)生變化時，這條連接依然維持，能夠保持業(yè)務邏輯不中斷。QUIC 之所以能支持連接遷移，是因為 QUIC 不再用四元組標識連接，而是以一個 64 位的隨機數(shù)作為 ConnctionID 來標識，這樣就算 IP 或者端口發(fā)生變化，只要 ConnctionID 不變，這條連接依然維持著，上層業(yè)務邏輯不會感知到變化，就不會中斷，也就不需要重連。

• 實現(xiàn)前向糾錯，通過發(fā)送冗余包來減少重傳

QUIC 會對一些優(yōu)先級較高的包進行冗余發(fā)送，丟失的數(shù)據(jù)包可以通過冗余包計算，減少重傳次數(shù)以提高傳輸效率。

以上這些 QUIC 優(yōu)點在互聯(lián)網(wǎng)行業(yè)都有著很大的吸引力，網(wǎng)易云信也參考了這些優(yōu)點，在此基礎上設計了自己的加速代理架構。

網(wǎng)易云信可靠鏈路的加速架構

網(wǎng)易云信參考 QUIC 的優(yōu)勢，自研了 QUIC 加速代理服務，為端到邊緣服務器節(jié)點提供可靠數(shù)據(jù)傳輸?shù)拇矸?#xff0c;提高可靠數(shù)據(jù)的及時性。下圖為網(wǎng)易云信加速代理的架構圖。

如上圖，云信采用 QUIC 協(xié)議和 TCP 協(xié)議并行的設計，客戶端同時支持 QUIC 鏈路和 TCP 鏈路建聯(lián)。正常情況下，客戶端會優(yōu)先使用 QUIC 協(xié)議。客戶端通過連接到 QUIC 加速服務來連接到后端，在 QUIC 連接失敗的情況下，才會選擇備用 TCP 鏈路建聯(lián)直接連接后端。網(wǎng)易云信之所以保留原 TCP 協(xié)議接入，目的是用來做某些用戶場景下 UDP 不可用的補充，保證程序的高可用性。

?網(wǎng)易云信加速架構設計初衷?

我們采用此架構設計的初衷是出于以下幾點考慮：

• 對最后一公里加速

距離用戶最后一公里為最容易出現(xiàn)弱網(wǎng)故障的鏈路，在該鏈路上對用戶可靠數(shù)據(jù)進行加速，可以實現(xiàn)事半功倍的效果。

• UDP/TCP 的雙保險，提升高可用性

某些局域網(wǎng)防火墻中禁用了 UDP 協(xié)議，在該網(wǎng)絡環(huán)境下，UDP 報文不可達。該網(wǎng)絡環(huán)境下，基于 UDP 的 QUIC 協(xié)議包將會被全部丟棄。在該網(wǎng)絡環(huán)境下只能寄希望于 TCP 傳輸，所以云信將 TCP 選取為數(shù)據(jù)鏈路的備份。

• 加速服務與業(yè)務相互隔離，加速服務不關心業(yè)務數(shù)據(jù)

網(wǎng)易云信加速服務，作為一個透明的協(xié)議，只負責接受 QUIC 包文，解開包文透傳給后端。加速代理服務不關心 QUIC 承載的內容，所以擴展性較大，可以用來給很多需要加速業(yè)務做數(shù)據(jù)傳輸加速。

• 兼容原有架構

為老客戶提供彈性升級策略是云信產品升級策略之一，所以該架構的部署不能影響老用戶，老用戶可以保留原先的鏈路，新用戶則默認采用加速鏈路。

下面，我們來詳細看一下網(wǎng)易云信加速服務器的架構設計。

數(shù)據(jù)加速服務器的架構設計

數(shù)據(jù)加速代理服務器分為兩大模塊，QUIC 前代理模塊和后代理模塊。

?QUIC 前代理模塊?

QUIC 前代理模塊，啟動一個 UDP 監(jiān)聽，監(jiān)聽客戶端用戶 QUIC 報文，前代理模塊主要負責以下工作：

• 接收客戶端 QUIC 協(xié)議的 UDP 包文

• 對收到的包進行 QUIC 解包和冗余度過濾

• 對于將要發(fā)送的包文進行 QUIC 協(xié)議打包

• 按照網(wǎng)絡情況計算帶寬和冗余度，發(fā)送冗余包

• 對收到的包文進行完整性校驗

?QUIC 后代理模塊?

QUIC 后代理模塊負責與后端建立 TCP 連接或者跟后端發(fā)起 http 請求，后代理模塊主要工作內容為：

• 按照前端的請求，向后端發(fā)起連接請求。

• 對前端代理的業(yè)務數(shù)據(jù)包進行打包，透傳給后端服務器。

• 接受后端服務器的業(yè)務包，并且進行壓縮和正校驗在送給前端代理模塊，由前代理模塊進行 QUIC 協(xié)議轉發(fā)。

前端代理與后端的服務器一般會進行就近部署或者同機部署，所以幾乎可以忽略代理到后端服務器的延遲。主要延遲產生為端與前端代理之間的延遲，優(yōu)化的重點轉為增加端到前端代理的 QUIC 傳輸優(yōu)化。

?基于 QUIC 加速服務實現(xiàn)的音視頻服務優(yōu)化?

在 QUIC 加速服務的基礎上，網(wǎng)易云信主要做了以下幾方面優(yōu)化：

• 首屏打開速度優(yōu)化

云信客戶端與服務器實現(xiàn)耗費至 0-1RTT 來建連，相比 TCP+TLS+HTTP/2 的 3RTT 建連，具有很大的優(yōu)勢。在成功連接之后，一旦客戶端緩存或持久化客戶端配置，就可以復用并結合本地生成的私鑰進行加密數(shù)據(jù)傳輸，不需要再次握手，從而實現(xiàn) 0RTT 建立連接。這樣給用戶首屏打開速度至少帶來了 2RTT 的延遲降低。特別在一些網(wǎng)絡差的偏遠地區(qū)，可以降低 100-300ms 的首屏延遲，提高了用戶體驗。

• 多 Streams 設計

QUIC 鏈路下創(chuàng)建多個 Streams，分別用于不同應用層協(xié)議數(shù)據(jù)的傳輸，各個 Stream 傳輸相互隔離，不會因為優(yōu)先級低的數(shù)據(jù)隊頭阻塞會影響另外優(yōu)先級高的數(shù)據(jù)接受和發(fā)送。

• 信令優(yōu)先級分級設計

優(yōu)先級高的數(shù)據(jù)采用較高的冗余度發(fā)送，優(yōu)先級較低冗余度也較低，從而保證優(yōu)先級高的數(shù)據(jù)優(yōu)先到達，并且優(yōu)先層級低的數(shù)據(jù)不會阻塞優(yōu)先級高的信令傳輸。

• 可選配置的傳輸數(shù)據(jù)壓縮

數(shù)據(jù)代理支持 zlib 壓縮，針對一些信令字符 Json 數(shù)據(jù)，zlib 壓縮對于字符壓縮，壓縮率可以達到 20%。通過壓縮，可以降低傳輸帶寬，緩解帶寬受限的擁塞。

• 引入 CRC 對傳技術數(shù)據(jù)進行校驗

QUIC 是流式數(shù)據(jù)，新增對于傳輸?shù)拿織l數(shù)據(jù)進行 CRC 校驗，一旦校驗失敗，隨即斷開連接，保證數(shù)據(jù)傳輸?shù)目煽啃院蜏蚀_性，以免影響業(yè)務。

• 根據(jù)網(wǎng)絡狀況，動態(tài)調整冗余度

通過 nacked 包的情況，來評估全鏈路網(wǎng)絡情況，發(fā)生了 unnacked 則正向調整冗余度，反之待穩(wěn)定后降低冗余度。最大限度節(jié)省帶寬占用，節(jié)省用戶帶寬，避免隊列擁塞。

網(wǎng)易云信加速服務的弱網(wǎng)性能表現(xiàn)

我們在進行數(shù)據(jù)加速之后與未加速的情況做了一系列的對比，特別做了在弱網(wǎng)環(huán)境下的對比。

?首屏耗時和登錄耗時?

上圖是云信音視頻業(yè)務 QUIC 和 TCP 的首屏打開耗時和登錄流程耗時。可以看到首屏打開有20%的提升，登錄有將近30%的提升，效果較明顯。原因主要因為 QUIC 實現(xiàn)了0-1次 RTT 的握手流程，特別對于一些偏遠省份，可以省下 100ms 的延遲，效果較為明顯。

?抗丟包能力?

上圖是云信信令數(shù)據(jù)在 QUIC 和 TCP 鏈路下能夠抗住的最大丟包率。QUIC 在上行丟包率達到70%的條件下仍然可以提供服務，下行邊界甚至可以抗住75%的丟包。TCP鏈路在45%的丟包情況下就會出現(xiàn)斷開重連。相對于 TCP 的信令鏈路 QUIC 鏈路有50%的提升。主要原因：

• 云信實現(xiàn)了動態(tài)冗余，會檢測到丟包之后增加冗余度，這樣就用冗余包彌補了高丟包，帶來了抗丟包性能。

• QUIC 改進的流量控制和擁塞控制算法讓QUIC在弱網(wǎng)絡下可能取得更大的傳輸優(yōu)勢。

?帶寬受限?

我們還做了在帶寬受限的情況下，QUIC 對于帶寬的使用率，基本上 QUIC 對于帶寬的使用率都能達到90%以上，然而 TCP 就要差很多。

?測試結論?

在丟包方面，云信得到了50%的抗丟包性能提升，在首屏打開速度上云信也有20%的提升 ，并且在帶寬受限制的情況下，也能夠達到90%的帶寬使用率，是音視頻服務業(yè)內領先的水準。

展望&總結

網(wǎng)易云信在可靠數(shù)據(jù)加速上可靠數(shù)據(jù)傳輸上已經得到很大的提升，但是仍然還有一些需要優(yōu)化的地方：

• 一旦單向發(fā)生丟包，會引起服務器和端都增加雙向的冗余度，帶來不必要的冗余增加。后續(xù)會檢測到單向丟包，只針對丟包的鏈路進行冗余度增加。

• 對于高 RTT 和高丟包場景，QUIC 擁塞控制算法需要持續(xù)優(yōu)化。

網(wǎng)易云信將持續(xù)在音視頻領域，在各種極端情況下為用戶提供優(yōu)質的服務。

?作者介紹?

紀松，網(wǎng)易云信資深音視頻服務端開發(fā)工程師，負責云信云信直播業(yè)務和音視頻數(shù)據(jù)鏈路加速業(yè)務，曾負責并發(fā) 70 萬人的 TFboys 直播業(yè)務。在音視頻數(shù)據(jù)傳輸和網(wǎng)絡數(shù)據(jù)轉發(fā)方面有著豐富的經驗。

?延伸閱讀?

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

• 技術實踐 | 聊聊網(wǎng)易云信的信令網(wǎng)絡庫實踐

總結

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

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