WebTransport开播的应用实践之路

不管是本地软件推流还是 Web 推流，需要解决的技术问题都是一样的，如何稳定地把高质量的音视频流呈现给更多用户，只不过 Web 开播的话，需要一个限定，就是在现有的 Web 技术范围内。从技术角度来解读一下这里的几个关键词：

• 稳定性: 传输协议本身的稳定性是需要保障的，优先会选择使用可靠传输，防止网损带来的花屏、杂音等问题，更重要的是，在服务链路不可用的情况下能够迅速切换服务线路。因此在推流场景下需要提供多线路备份的能力。

• 高质量：在一些场景下，比如医疗医美营销的场景、带货的场景，要对商品细节做展示，这就要求技术方案在带宽允许的前提下，尽可能选用对画面细节损失更少的编码方案。

• 大规模用户：要分发给更多用户，那技术方案设计肯定会引入直播 CDN 服务，但是推流协议是不是能够被直播 CDN 支持，这就是一个考量的点，也是做私有协议无法满足的点。

首先我们简单来了解一下 WebTransport 这个传输协议基本的技术原理。WebTransport 是基于 HTTP3 的应用层传输协议，HTTP3 的底层又基于 quic 协议，quic 协议是基于 UDP 协议实现的一套传输协议，支持可靠与非可靠传输两种形式。

WebTransport 对于 Web 应用的意义并不止于一个更好的传输协议，它更多的还是带来了一个更加丰富的技术栈，能够根据实际场景，结合 WebCodecs、WebAssembly 和 WebNN 等能力实现更好的应用体验。相较于 WebRTC 相对中心化的技术栈，这种方式显然是更加灵活的，易于做出更多灵活的技术组合。

另一个明显的优势在于 WebTransport 可以发挥页面多线程的优势，使用 WebRTC 协议，大量的逻辑只能放在主线程执行，而使用 WebTransport 就可以将整个音视频的处理流程放在 WebWorker 中，降低对主线程的占用，提升页面流畅度。同时使用多线程能够提升应用的扩展性，在面对更多的音视频任务时可以用线程来进行抽象和隔离。

充分利用多线程机制降低主线程负担

利用多线程机制提升应用的可拓展性

首次连接比 TCP 快 1～2RTT

对有缓存的连接支持 0RTT

基于这些优势，火山引擎直播团队选择使用 WebTransport 优化直播推流。设计的方案是基于单向流的稳定传输，从传输格式上对标 RTMP，这样直播 CDN 的支持成本会相对较小，比较好复用目前的 RTMP 收流逻辑。由于这个技术栈较新也需要解决过程中的一些问题：虽然 W3C 定义了 AAC 的编码能力，但是 Chrome 没有提供 AAC 编码的实现，可以将 libFaaC 编译成 wasm 库来实现，另外浏览器没有针对 flv 容器的封装，需要额外支持该部分能力。那么相比于 WebRTC 推流，WebTransport 推流的实际应用效果如何呢？

WebRTC 是面向实时通信的传输协议，对网络延时的变化敏感。使用 WebRTC 协议推流时，它受到网络抖动的影响较大，当网络延时的抖动发生时，RTC 的带宽估计模块会认为当前网络处于拥塞状态，需要降低发送码率以避免拥塞，码率的降低对视频画质的影响是非常大的，直观感受就会出现局部的马赛克。当使用 WebTransport 基于 Quic 可靠传输时，其拥塞控制算法对网络抖动的敏感度相对较低，可以通过牺牲一定的延迟保证发送可靠性，因此不容易出现大幅降低发送带宽的行为，画质相对有保障。

WebTransport 基于已经定稿的 HTTP3 规范，易于被直播 CDN 集成支持，应用复杂度相较于 WebRTC 更低，同时省去了 RTC 推流建连过程中的信令环节，可以加快首帧推送的速度，方便部署到更多的直播 CDN首先在网络抖动的场景下，同样加入 100ms 延迟抖动，WebTransport 推流的画面会明显比 RTC 推流要清晰。在网络抢占的场景下，固定一个较低的带宽，使用 GCC 拥塞控制算法的数据流，面对使用 TCP 协议的数据传输，它能够分到的带宽资源是非常小的。

WebTransport 推流

WebRTC 推流

不同的推流协议之间各有优缺点，目前没有一个完美的解决方案，需要根据实际的场景来做选择，比如连麦场景一般需要用 WebRTC 转推，更适合低延迟互动的场景，WebTransport 方案则更适合高画质需求的场景。总的来说，WebTransport 推流的方案在解决“如何稳定地将高质量的音视频传递给大量的用户”的问题上，即实现了可靠的传输，连接稳定性有保障，并且在遭遇网损的场景，可以通过牺牲部分延迟保障音视频质量，给出了一份令人较为满意的答卷。如果想要体验 WebTransport 的开播效果，可进入火山引擎控制台进行在线 demo 体验。