大家应该都听过 WebRTC，WebRTC 的前身是 GIPS, 在 2011 年 Google 收购了 GIPS 并开源出来命名为 WebRTC， 10 年之后就是 2025 年 WebRTC1.0 正式定稿。但 WebRTC 本身仍存在很多问题，比如浏览器之间的适配问题，QoS 可定制的空间比较小，以及硬件编码器的适配问题。腾讯云音视频在 WebRTC 上面做了很多的优化，比如端和后台之间互相作用的带宽评估算法，在有些场景，我们采用发送端来进行带宽评估，而在屏幕共享的场景，我们则使用后台来进行带宽评估。我们还做了大量的各平台各版本之间的明控适配以及动态的 pacing 支持，客户可以配置追求低延时还是追求低卡顿。
在 Web 端中不得不提的一套新的 API 组合：WebTransport + WebCodecs+ WebAssembly。
我们先介绍一下 WebTransport，WebTransport 是 WebRTC 体系下的一套浏览器 API，提供低延迟 client 和 server 之间双向通信的能力。WebTransport 提供基于 QUIC 和 HTTP3 实现的 API, 自动获得 QUIC 和 HTTP3 本身的特性，比如应用层的拥塞，避免队头阻塞。双向通信的能力，多个传输通道复用一个连接的能力，能够很好的替代 WebSocket。同时它提供了发送 / 接受不可靠 UDP 的能力，这个是浏览器一直欠缺的能力。
第二个 Webcodecs 是在浏览器中提供高效的音视频编解码的 API。在目前的 WebAPI 中， 已经有了 MediaRecorder 和 MSE 两套编解码相关的 API, 但它们都有很多限制。比如 MediaRecorder 允许将含有视频和音频的 mediatrack 进行编码，但对于一些关键参数无法进行控制，比如对编码的精确控制，对关键帧的精确编码控制。同时它在输出数据前会有一段缓冲，这对于低延时的场景以及需要使用自有容器格式的场景也不合适。MSE 也可以实时解码媒体数据，但对于音视频的输入输出有比较大的限制。WebCodecs 提供的高效音视频编解码 API 能扩展更多的场景。
最后是 WebAseembly。WebRTC 作为浏览器的一个标准，在浏览器中我们无法控制 WebRTC 的内部工作机制。对于有能力处理好音视频前后处理的团队来说，加上 WebTransport 的提供的传输能力以及 Webcodecs 编解码能力完全可以在 Web 端通过 WebAseembly 来定制自己的 RTC 协议栈，这个想象力的空间特别大，我们也在做这方面的探索。
