Web開播的業務挑戰

無論是本地軟件推流還是Web推流，都需要解決推流抖動、畫面高糊、音頻卡頓等問題。在現有的Web技術環境下，如何穩定地把高質量的音視頻流呈現給更多用戶，是我們技術團隊攻克的重點。從技術角度來解讀一下這裡的幾個關鍵詞：

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

WebTransport 的技術原理

首先我們簡單來了解一下WebTransport這個傳輸協議基本的技術原理。WebTransport是基於HTTP3的應用層傳輸協議，HTTP3的底層又基於quic協議，quic協議是基於UDP協議實現的一套傳輸協議，支持可靠與非可靠傳輸兩種形式。

WebTransport 的技術優勢

WebTransport對於Web應用的意義並不止於一個更好的傳輸協議，它更多的還是帶來了一個更加豐富的技術棧，能夠根據實際場景，結合WebCodecs、WebAssembly和WebNN等能力實現更好的應用體驗。相較於WebRTC相對中心化的技術棧，這種方式顯然是更加靈活的，易於做出更多靈活的技術組合。

另一個明顯的優勢在於WebTransport可以發揮頁面多線程的優勢，使用WebRTC協議，大量的邏輯只能放在主線程執行，而使用WebTransport就可以將整個音視頻的處理流程放在WebWorker中，降低對主線程的佔用，提升頁面流暢度。同時使用多線程能夠提升應用的擴展性，在面對更多的音視頻任務時可以用線程來進行抽象和隔離。

充分利用多線程機制降低主線程負擔

利用多線程機制提升應用的可拓展性

從傳輸協議的特性上來說，它的建聯速度更快，首次建聯只需要1個RTT，相比之下，TCP則需要2~3個RTT。針對已經建立過的連接，超時時間內再次建聯可以實現0RTT。在網絡擁塞的情況下，減少RTT次數對速度的優化是非常明顯的。可以到幾十ms。最後一個特性是連接遷移，在直播過程中如果WIFI網絡不好。切到手機熱點也可以實現0RTT，相比之下，TCP、RTC都需要重新建立連接，恢復的速度會慢很多。

首次連接比TCP快1～2RTT 

對有緩存的連接支持0RTT

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

WebTransport 推流與WebRTC 推流效果對比

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

網絡傳輸（畫質與穩定性）：

WebRTC是面向實時通信的傳輸協議，對網絡延時的變化敏感。使用WebRTC協議推流時，它受到網絡抖動的影響較大，當網絡延時的抖動發生時，RTC的帶寬估計模塊會認為當前網絡處於擁塞狀態，需要降低發送碼率以避免擁塞，碼率的降低對視頻畫質的影響是非常大的，直觀感受就會出現局部的馬賽克。當使用WebTransport基於Quic可靠傳輸時，其擁塞控制算法對網絡抖動的敏感度相對較低，可以通過犧牲一定的延遲保證發送可靠性，因此不容易出現大幅降低發送帶寬的行為，畫質相對有保障。

編碼優化（畫質）：

WebTransport在Web規範中提供了網絡傳輸的能力，並且可以與現有的Web端多媒體能力進行深度集成，例如WebCodecs、WebGPU等。給應用的優化提供了更多編碼格式、參數選擇方面的空間。

易於集成到直播CDN （大規模分發）：

WebTransport基於已經定稿的HTTP3規範，易於被直播CDN集成支持，應用複雜度相較於WebRTC更低，同時省去了RTC推流建連過程中的信令環節，可以加快首幀推送的速度，方便部署到更多的直播CDN

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

WebTransport推流+100ms延遲抖動

 WebRTC推流+100ms延遲抖動

另外，在固定3Mbps上行帶寬的網絡下，同時使用WebTransport和RTC推流，設定的目標碼率都是1.5M，過程中RTC推流的碼率會受到嚴重的影響，碼率大幅下降，不能保證畫質。WebTransport推流在不同網絡狀態下的流暢度表現，除了大量丟包的情況下，其餘的場景都能夠達到與RTC推流基本持平。

WebTransport推流

 WebRTC推流

總結與展望

不同的推流協議之間各有優缺點，目前沒有一個完美的解決方案，需要根據實際的場景來做選擇，比如連麥場景一般需要用WebRTC轉推，更適合低延遲互動的場景，WebTransport方案則更適合高畫質需求的場景。總的來說，WebTransport推流的方案在解決“如何穩定地將高質量的音視頻傳遞給大量的用戶”的問題上，即實現了可靠的傳輸，連接穩定性有保障，並且在遭遇網損的場景，可以通過犧牲部分延遲保障音視頻質量，給出了一份令人較為滿意的答卷。如果想要體驗WebTransport的開播效果，可進入火山引擎控制台進行在線demo體驗。