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

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

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

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

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

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

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

接入點(diǎn)選擇

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

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

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

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

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

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

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

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

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

• 直播轉(zhuǎn)推場景

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

• 連麥場景

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

二、丟包恢復(fù)方案

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

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

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

• NACK

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

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

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

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

4.假設(shè)多人場景NACK 會(huì)大量吃掉用戶的帶寬，從而造成網(wǎng)絡(luò)傳輸?shù)牟▌?dòng)。

• FEC

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

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

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

• ACK

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

URTC技術(shù)優(yōu)化

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

• 上行推流端

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

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

• 服務(wù)端

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

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

目前緩存窗口采取單一存儲(chǔ)，每個(gè)只記錄自己當(dāng)前讀取的位置，以減輕內(nèi)存壓力。

• 下行拉流端

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

總結(jié)

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