摘要：接下來，本文將重點介紹在解決網絡傳輸路徑網絡擁塞丟包等問題過程中的質量優化實踐之路。因此我們進一步對傳輸內容的質量問題進行了相關優化，主要解決網絡擁塞和丟包恢復。

受疫情影響，在線教育迎來爆發式增長。智慧樹作為教育部推薦的線上教學平臺之一，為全國近2000所高校、30余萬老師、1000多萬大學生提供在線課程內容、在線教學平臺以及全流程教學服務。自2020年4月開始， UCloud URTC實時音視頻產品被智慧樹正式接入使用，為其提供從音視頻的采集、處理、編解碼、傳輸以及云端的轉碼混流等系統服務。

基于UCloud在全球部署的31個可用區、29條專線、500+加速節點，URTC可提供平均300ms的低延時穩定流暢的師生線上課程體驗，且支持百萬人級別的超高并發能力。

為充分保障智慧樹在線課堂的師生實時互動流暢體驗，URTC在底層網絡傳輸技術上做了大量的網絡優化工作，通過全球就近接入點接入、自研HTTPDNS調度算法、丟包重傳，實現了弱網高質量通信，即使在30%丟包下視頻仍然流暢、70%丟包下音頻仍可正常通信。

接下來，本文將重點介紹URTC在解決網絡傳輸路徑、網絡擁塞、丟包等問題過程中的質量優化實踐之路。

URTC 傳輸路徑優化

上圖是URTC 媒體服務集群簡單架構圖，URTC通過服務器全球化部署，實現用戶就近接入，下面著重介紹URTC在網絡傳輸路徑方面的優化實踐。

接入點選擇

傳統直播經常采用DNS進行接入點的分配，DNS一是解析比較慢，第二是面臨劫持的問題，并不能很好的進行接入。URTC采用Http-DNS進行接入點的選擇和分配，為了保障請求的效率和準確性，URTC會同時向幾個地址進行Http-DNS 地址請求，同時我們針對用戶的歷史接入數據對于大運營商聯通、電信、移動會通過歷史記錄比對的方式進行分配，加快接入數據，非大運營商則采用ping 速的方式進行動態探測，并通過延時丟包進行擬合算法判斷，判斷最優接入點。

傳輸的鏈路管理和分配

我們采用一個中心式的路由管理系統，所有的relay節點都是對等的，不同中心的relay 節點進行相互連接，組成一張圖，圖中各點的連接平分為路徑權重，轉發控制中心通過實時計算規劃最優路徑，在用戶請求時進行路徑分配，并對傳輸的路徑進行相應的監測，在故障時進行鏈路的切換。

數據中心之間傳輸

數據中心之間我們采用自研基于UDP的私有協議進行傳輸，降低數據中心之間的傳輸延時，并提高數據中心之間的傳輸吞吐量。

通過上面的三個優化方案，URTC有效解決了用戶就近接入、傳輸路徑分配、故障轉移等傳輸路徑的問題，但是在傳輸中我們還面臨傳輸數據內容的質量保障，尤其是用戶的“最后一公里”。因此我們進一步對傳輸內容的質量問題進行了相關優化，主要解決網絡擁塞和丟包恢復。

URTC 傳輸質量優化

一、網絡擁塞算法優化

目前有很多種解決網絡擁塞的算法，比如CUBIC、LEBAT、SCReAM、BBR、GCC、PCC等，這些算法大體可以分為3個方向：基于丟包、基于延時和基于機器學習。URTC采用了GCC 算法，并結合不同的使用場景進行了相應的優化：

• 直播轉推場景

直播轉推場景，URTC 主要完成用戶的上行推流任務，同時由于在轉推場景中，用戶對于延時（800ms -- 2s）不是很敏感，但是對于傳輸內容的質量有比較高的要求，因此URTC 在此場景中更偏向于質量保證，而對抖動的敏感度下降。于是我們將 URTC的GCC 算法退化成基于丟包的擁塞控制算法，目標是在用戶可接受的延時內盡量保證推流的質量。

• 連麥場景

連麥場景中強調實時的交互性，用戶對于延時（低于400ms）的敏感度比較高,因此算法需要對網絡的變化有更好的適應性，以保障更好的實時性。這里URTC的GCC 算法對抖動和延時的敏感度上升，我們便將其優化為基于延時的擁塞算法。

二、丟包恢復方案

再說到丟包問題，丟包產生原因包括傳輸通道誤碼、無線網絡通信不穩定、信號衰減干擾、網絡擁塞、數據包沒有按時到達、系統抖動等。這里有幾點必須強調下，由于RTC的目標是極低延時，因此我們在定義丟包的含義時，要考慮延時到達和抖動過大這兩種情況。這兩種情況下，采樣值過大的樣本在RTC中也應該定義為丟包，有了明確的丟包定義之后，才能對癥下藥解決丟包問題。

傳統抗丟包算法

傳統的的對抗丟包算法主要包含NACK(丟包重傳請求)、FEC(前向糾錯)、ACK(應答確認)。

• NACK

NACK是對沒有收到的數據進行主動的傳輸請求，這樣可以做到比較精確的丟包重傳請求，但是NACK也會帶來一些問題：

1.太密集的NACK 請求容易形成大量的重傳風暴，重傳的成功率偏低，浪費帶寬；

2.即便重傳不密集，但是當丟包率過大時，丟包重傳請求以及傳輸反饋投遞到源端的成功率也在降低，即反饋包也在面臨丟包的問題；

3.NACK必定帶來額外的延時，最理想的情況下引入一個RTT 的延時；

4.假設多人場景NACK 會大量吃掉用戶的帶寬，從而造成網絡傳輸的波動。

• FEC

FEC 本質是通過冗余數據，比如最簡單的冗余算法應該是數據倍數發送，一般可以設置3倍，來提高數據的正確完整到達，FEC算法有很多:異或計算、RS-FEC、噴泉碼等等。FEC 好處是可以通過冗余數據減少端到端的時延，但是同時也帶來額外的問題：

1.FEC 會帶來額外的冗余帶寬消耗，控制不好將會帶入更嚴重的擁塞和丟包問題；

2.在多人場景中FEC包的過度轉發也會引起觀看用戶的過度帶寬消耗。

• ACK

ACK是通過對已經發送的數據進行相關的確認，發送端根據確認的序號，判斷是否進行數據的重發或者新數據的發送，ACK目前是一種應用比較普遍的算法，但是為了提高網絡效率，ACK 通常會采用合并確認或者延時確認的方案，這會引入額外的延時。

URTC技術優化

綜合上述傳統抗丟包算法的優缺點，URTC在丟包恢復算法上采用了NACK+FEC+ARQ的算法方案，但是在具體的實現上還做了很多技術優化。主要包括：

• 上行推流端

通過3種算法的動態智能聯動，URTC可動態調整重傳和冗余數據比例，當低丟包低RTT時，通過NACK 進行數據的的恢復；當高丟包低RTT時，且長時間沒有收到反饋包，遠端會自動進行動態的調整，調整冗余數據、重傳數據和實際媒體數據的比例，進而得出新的目標碼率；當高RTT 低丟包以及高RTT高丟包時，NACK 將被關閉，只進行FEC 的使用，當然FEC比例增加的同時，遠端數據也會進行相應的降低。

同時針對音頻敏感場景，URTC會保證音頻的首先傳輸，在出現競爭時視頻質量逐漸降低直至掛起，以保證音頻質量。

• 服務端

在服務端,URTC針對每個用戶做了一個緩沖窗口。傳統的媒體服務器一般采用純轉發的方式，由客戶端進行相應的丟包和擁塞控制，這樣帶來的問題是在網絡抖動時，服務端不能感知網絡的變化，進而更早的發現擁塞。因此URTC 在服務端設計了一個網絡擁塞模塊，主要作用是感知網絡狀態，對抗網絡抖動，減輕網絡抖動引起的瞬間丟包和重傳風暴。

針對網絡不好的終端用戶，URTC采用先通知遠端降低碼率，碼率達到下限，在緩存窗口進行數據的丟棄，以保證接收端的低延時。同時針對不同網絡情況用戶，服務端也根據當前網絡狀態進行冗余數據的下發。

目前緩存窗口采取單一存儲，每個只記錄自己當前讀取的位置，以減輕內存壓力。

• 下行拉流端

URTC采用抖動緩沖策略去抖動，并采用智能播放策略，獲取區采用狀態機策略，分為填充、播放、慢放、等待、快放等，根據不同的狀態機，對數據進行不同的處理邏輯，以此保證數據播放平穩和延時，同時NACK 變為和RTT相關的策略，根據投遞的成功率進行投遞間隔的改變，防止NACK 投遞引起的重傳風暴和帶寬浪費。

總結

通過本文介紹的一些質量工程優化和算法工程優化，URTC將音頻抗丟包能力從20%提高到70%，視頻上行抗丟包從20% 提高到30%。未來，URTC還將不斷優化提升實時音視頻服務的穩定、低延時、流暢性，致力于為更多企業和開發者提供高質量、高可靠的SDK服務。