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

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

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

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

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

URTC 傳輸路徑優(yōu)化

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

接入點選擇

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

傳輸?shù)逆溌饭芾砗头峙?/strong>

我們采用一個中心式的路由管理系統(tǒng)，所有的relay節(jié)點都是對等的，不同中心的relay 節(jié)點進行相互連接，組成一張圖，圖中各點的連接平分為路徑權重，轉發(fā)控制中心通過實時計算規(guī)劃最優(yōu)路徑，在用戶請求時進行路徑分配，并對傳輸?shù)穆窂竭M行相應的監(jiān)測，在故障時進行鏈路的切換。

數(shù)據(jù)中心之間傳輸

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

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

URTC 傳輸質量優(yōu)化

一、網(wǎng)絡擁塞算法優(yōu)化

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

• 直播轉推場景

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

• 連麥場景

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

二、丟包恢復方案

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

傳統(tǒng)抗丟包算法

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

• NACK

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

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

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

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

4.假設多人場景NACK 會大量吃掉用戶的帶寬，從而造成網(wǎng)絡傳輸?shù)牟▌印?/p>

• FEC

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

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

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

• ACK

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

URTC技術優(yōu)化

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

• 上行推流端

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

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

• 服務端

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

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

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

• 下行拉流端

URTC采用抖動緩沖策略去抖動，并采用智能播放策略，獲取區(qū)采用狀態(tài)機策略，分為填充、播放、慢放、等待、快放等，根據(jù)不同的狀態(tài)機，對數(shù)據(jù)進行不同的處理邏輯，以此保證數(shù)據(jù)播放平穩(wěn)和延時，同時NACK 變?yōu)楹蚏TT相關的策略，根據(jù)投遞的成功率進行投遞間隔的改變，防止NACK 投遞引起的重傳風暴和帶寬浪費。

總結

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