導語：網易雲信作為音視訊服務提供商的領導者，一直致力於提供頂級的音視訊通話服務體驗，為使用者在各種惡劣環境下提供可靠的音視訊服務。如何在極端弱網條件下仍然能給使用者提供可靠的音視訊服務，是網易雲信關注的重中之重。本文將闡述網易雲信為了提高可靠資料在弱網環境及時性所採用的架構技術方案。 ## 引言 市面上多數傳統的音視訊服務基於 TCP 協議做可靠資料的傳輸，但是因為 TCP 自身協議的特性，有著天生的一些缺陷，例如： 1. **傳輸效率低** TCP 無私的傳輸特性，導致傳輸慢，效率較低，在弱網下更明顯。 2. **建聯延遲大** 三次握手的安全設計引起首次建聯耗時高，會引起首屏出現較晚。 3. **抗弱網特性差** TCP 的可靠傳輸特性決定了，較小的丟包就會引起鏈路斷開。 4. **隊頭阻塞嚴重** 包文有序依次傳輸，小序列號包的丟失會引起後面包文阻塞，直到重傳成功。  這些缺陷導致傳統音視訊服務在弱網環境下，可靠資料鏈路先於媒體鏈路斷開，信令延遲到達，影響使用者體驗。**如何提高可靠資料鏈路的可靠性和及時性**是所有音視訊服務提供商需要解決的問題。隨著技術發展，當前熱門協議 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%的提升。主要原因： 1. 雲信實現了動態冗餘，會檢測到丟包之後增加冗餘度，這樣就用冗餘包彌補了高丟包，帶來了抗丟包效能。 1. QUIC 改進的流量控制和擁塞控制演算法讓QUIC在弱網路下可能取得更大的傳輸優勢。 ### 頻寬受限 我們還做了在頻寬受限的情況下，QUIC 對於頻寬的使用率，基本上 QUIC 對於頻寬的使用率都能達到90%以上，然而 TCP 就要差很多。  ### 測試結論 在丟包方面，雲信得到了50%的抗丟包效能提升，在首屏開啟速度上雲信也有20%的提升 ，並且在頻寬受限制的情況下，也能夠達到90%的頻寬使用率，是音視訊服務業內領先的水準。 ## 展望&總結 網易雲信在可靠資料加速上可靠資料傳輸上已經得到很大的提升，但是仍然還有一些需要優化的地方： - 一旦單向發生丟包，會引起伺服器和端都增加雙向的冗餘度，帶來不必要的冗餘增加。後續會檢測到單向丟包，只針對丟包的鏈路進行冗餘度增加。 - 對於高 RTT 和高丟包場景，QUIC 擁塞控制演算法需要持續優化。 網易雲信將持續在音視訊領域，在各種極端情況下為使用者提供優質的服務。 ### 作者簡介 紀鬆，網易雲信資深音視訊服務端開發工程師，負責雲信雲信直播業務和音視訊資料鏈路加速業務，曾負責併發 70 萬人的 TFboys 直播業務。在音視訊資料傳輸和網路資料轉發方面有著豐富的