Web開播的業(yè)務(wù)挑戰(zhàn)

無論是本地軟件推流還是Web推流，都需要解決推流抖動、畫面高糊、音頻卡頓等問題。在現(xiàn)有的Web技術(shù)環(huán)境下，如何穩(wěn)定地把高質(zhì)量的音視頻流呈現(xiàn)給更多用戶，是我們技術(shù)團(tuán)隊(duì)攻克的重點(diǎn)。從技術(shù)角度來解讀一下這里的幾個關(guān)鍵詞：

• 穩(wěn)定性: 傳輸協(xié)議本身的穩(wěn)定性是需要保障的，優(yōu)先會選擇使用可靠傳輸，防止網(wǎng)損帶來的花屏、雜音等問題，更重要的是，在服務(wù)鏈路不可用的情況下能夠迅速切換服務(wù)線路。因此在推流場景下需要提供多線路備份的能力。
• 高質(zhì)量：在一些場景下，比如醫(yī)療醫(yī)美營銷的場景、帶貨的場景，要對商品細(xì)節(jié)做展示，這就要求技術(shù)方案在帶寬允許的前提下，盡可能選用對畫面細(xì)節(jié)損失更少的編碼方案
• 大規(guī)模用戶：要分發(fā)給更多用戶，那技術(shù)方案設(shè)計(jì)肯定會引入直播CDN服務(wù)，但是推流協(xié)議是不是能夠被直播CDN支持，這就是一個考量的點(diǎn)，也是做私有協(xié)議無法滿足的點(diǎn)。

WebTransport 的技術(shù)原理

首先我們簡單來了解一下WebTransport這個傳輸協(xié)議基本的技術(shù)原理。WebTransport是基于HTTP3的應(yīng)用層傳輸協(xié)議，HTTP3的底層又基于quic協(xié)議，quic協(xié)議是基于UDP協(xié)議實(shí)現(xiàn)的一套傳輸協(xié)議，支持可靠與非可靠傳輸兩種形式。

WebTransport 的技術(shù)優(yōu)勢

WebTransport對于Web應(yīng)用的意義并不止于一個更好的傳輸協(xié)議，它更多的還是帶來了一個更加豐富的技術(shù)棧，能夠根據(jù)實(shí)際場景，結(jié)合WebCodecs、WebAssembly和WebNN等能力實(shí)現(xiàn)更好的應(yīng)用體驗(yàn)。相較于WebRTC相對中心化的技術(shù)棧，這種方式顯然是更加靈活的，易于做出更多靈活的技術(shù)組合。

另一個明顯的優(yōu)勢在于WebTransport可以發(fā)揮頁面多線程的優(yōu)勢，使用WebRTC協(xié)議，大量的邏輯只能放在主線程執(zhí)行，而使用WebTransport就可以將整個音視頻的處理流程放在WebWorker中，降低對主線程的占用，提升頁面流暢度。同時使用多線程能夠提升應(yīng)用的擴(kuò)展性，在面對更多的音視頻任務(wù)時可以用線程來進(jìn)行抽象和隔離。

充分利用多線程機(jī)制降低主線程負(fù)擔(dān)

利用多線程機(jī)制提升應(yīng)用的可拓展性

從傳輸協(xié)議的特性上來說，它的建聯(lián)速度更快，首次建聯(lián)只需要1個RTT，相比之下，TCP則需要2~3個RTT。針對已經(jīng)建立過的連接，超時時間內(nèi)再次建聯(lián)可以實(shí)現(xiàn)0RTT。在網(wǎng)絡(luò)擁塞的情況下，減少RTT次數(shù)對速度的優(yōu)化是非常明顯的?？梢缘綆资甿s。最后一個特性是連接遷移，在直播過程中如果WIFI網(wǎng)絡(luò)不好。切到手機(jī)熱點(diǎn)也可以實(shí)現(xiàn)0RTT，相比之下，TCP、RTC都需要重新建立連接，恢復(fù)的速度會慢很多。

首次連接比TCP快1～2RTT 

對有緩存的連接支持0RTT

基于這些優(yōu)勢，火山引擎直播團(tuán)隊(duì)選擇使用WebTransport優(yōu)化直播推流。設(shè)計(jì)的方案是基于單向流的穩(wěn)定傳輸，從傳輸格式上對標(biāo)RTMP，這樣直播CDN的支持成本會相對較小，比較好復(fù)用目前的RTMP收流邏輯。由于這個技術(shù)棧較新也需要解決過程中的一些問題：雖然W3C定義了AAC的編碼能力，但是Chrome沒有提供AAC編碼的實(shí)現(xiàn)，可以將libFaaC編譯成wasm庫來實(shí)現(xiàn)，另外瀏覽器沒有針對flv容器的封裝，需要額外支持該部分能力。那么相比于WebRTC推流，WebTransport推流的實(shí)際應(yīng)用效果如何呢？

WebTransport 推流 與 WebRTC 推流效果對比

為什么 WebTransport 能夠比 WebRTC 推流獲得更好的效果：

網(wǎng)絡(luò)傳輸（畫質(zhì)與穩(wěn)定性）：

WebRTC是面向?qū)崟r通信的傳輸協(xié)議，對網(wǎng)絡(luò)延時的變化敏感。使用WebRTC協(xié)議推流時，它受到網(wǎng)絡(luò)抖動的影響較大，當(dāng)網(wǎng)絡(luò)延時的抖動發(fā)生時，RTC的帶寬估計(jì)模塊會認(rèn)為當(dāng)前網(wǎng)絡(luò)處于擁塞狀態(tài)，需要降低發(fā)送碼率以避免擁塞，碼率的降低對視頻畫質(zhì)的影響是非常大的，直觀感受就會出現(xiàn)局部的馬賽克。當(dāng)使用WebTransport基于Quic可靠傳輸時，其擁塞控制算法對網(wǎng)絡(luò)抖動的敏感度相對較低，可以通過犧牲一定的延遲保證發(fā)送可靠性，因此不容易出現(xiàn)大幅降低發(fā)送帶寬的行為，畫質(zhì)相對有保障。

編碼優(yōu)化（畫質(zhì)）：

WebTransport在Web規(guī)范中提供了網(wǎng)絡(luò)傳輸?shù)哪芰?，并且可以與現(xiàn)有的Web端多媒體能力進(jìn)行深度集成，例如WebCodecs、WebGPU等。給應(yīng)用的優(yōu)化提供了更多編碼格式、參數(shù)選擇方面的空間。

易于集成到直播 CDN （大規(guī)模分發(fā)）：

WebTransport基于已經(jīng)定稿的HTTP3規(guī)范，易于被直播CDN集成支持，應(yīng)用復(fù)雜度相較于WebRTC更低，同時省去了RTC推流建連過程中的信令環(huán)節(jié)，可以加快首幀推送的速度，方便部署到更多的直播CDN

首先在網(wǎng)絡(luò)抖動的場景下，同樣加入100ms延遲抖動，WebTransport推流的畫面會明顯比RTC推流要清晰。在網(wǎng)絡(luò)搶占的場景下，固定一個較低的帶寬，使用GCC擁塞控制算法的數(shù)據(jù)流，面對使用TCP協(xié)議的數(shù)據(jù)傳輸，它能夠分到的帶寬資源是非常小的。

WebTransport推流+100ms延遲抖動

 WebRTC推流+100ms延遲抖動

另外，在固定3Mbps上行帶寬的網(wǎng)絡(luò)下，同時使用WebTransport和RTC推流，設(shè)定的目標(biāo)碼率都是1.5M，過程中RTC推流的碼率會受到嚴(yán)重的影響，碼率大幅下降，不能保證畫質(zhì)。WebTransport推流在不同網(wǎng)絡(luò)狀態(tài)下的流暢度表現(xiàn)，除了大量丟包的情況下，其余的場景都能夠達(dá)到與RTC推流基本持平。

WebTransport推流

 WebRTC推流

總結(jié)與展望

不同的推流協(xié)議之間各有優(yōu)缺點(diǎn)，目前沒有一個完美的解決方案，需要根據(jù)實(shí)際的場景來做選擇，比如連麥場景一般需要用WebRTC轉(zhuǎn)推，更適合低延遲互動的場景，WebTransport方案則更適合高畫質(zhì)需求的場景?？偟膩碚f，WebTransport推流的方案在解決“如何穩(wěn)定地將高質(zhì)量的音視頻傳遞給大量的用戶”的問題上，即實(shí)現(xiàn)了可靠的傳輸，連接穩(wěn)定性有保障，并且在遭遇網(wǎng)損的場景，可以通過犧牲部分延遲保障音視頻質(zhì)量，給出了一份令人較為滿意的答卷。如果想要體驗(yàn)WebTransport的開播效果，可進(jìn)入火山引擎控制臺進(jìn)行在線demo體驗(yàn)。