WebTransport 开播的应用实践之路

Web 开播的业务挑战

不管是本地软件推流还是 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 体验。