WebRTC 的未来（关于新 API, WHIP 以及 web 2.5）

来源：FOSDEM 2022
主讲人：Tim Panton
内容整理：尹文沛【煤矿工厂】
链接：https://mp.weixin.qq.com/s/s5Yy7ay0Due3qakOVuXdtw

WebRTC 的定义

主讲人对 WebRTC 做了一个自己的定义：

在浏览器网页中实现或使用 W3C 的 WebRTC API；
在浏览器，服务器或者终端设备中使用或实现 IETF 的 RTCWeb 有线协议；
源自于 Google 的开源库 libwebrtc 的实现。

IETF

NICER

IETF 首先做的工作是开发了 NICER。NICER 是一种在一次对话中切换 4G 和 wifi 的一种方法，这给 WebRTC 增加了一个新功能。

NICER 在一次 WebRTC 会话中将持续检测 ICE 路径，然后检查所有工作路径的状况，如果另外一个路径比当前路径要好，则会切换到更好的路径，在整个 WebRTC 会话中会一直循环这个过程。

WISH

WISH 也是一个标准草案中的新 API。WISH 是一种上传直播视频到流分发站例如(Twitch 或者 Youtube)的一种方法。可以视为一种对 RTMP 的替代方法。

WISH 仅用到 WebRTC 的一些组件，所以协议不需要有额外的数据通道，它仅用于上传，不是双工的。不同于完整的 WebRTC，WISH 使用基于 HTTP 的信令标准。并且 WISH 在完全不基于 libwebrtc 的前提下，有多种语言的实现，包括 Janus, |pipe|, Millicast, Galene。

Sframe

Sframe 对基于服务器的窥探者加密。Sframe 对服务器数据进行了双重加密，其中一层是在 WebRTC 的加密基础上再进行加密，服务器也无法解码这一层新的加密。包的格式是 SRTP 但是 payload 数据是已经预先加过密的。同时在包中保留了充足的信息，这样可以使得 SFU 在传输过程中可以对包做出正确的决策。

RTCWeb

与 WebRTC 有关的 IETF 核心组是 RTCWeb，但是没啥动静，更新了一些镜像，但是没有实质性的改进。

W3C

Region Capture

你有时也许不想看到或者分享某个直播或者会议的整个画面，比如说演讲者设置的 ppt 注释，下一页的按钮等等。这个 API 能够让你只传输你想传输的部分画面，并允许会议 app 去截取这部分画面。

Capture Handle Action

当你想要展示某个 app，你就不得不在视频会议 app 和展示 app 的页面之间来回切换。这个 API 就能够允许视频会议 app 将下一步动作/指令发送给展示的 app。

Media Capture Transform

Media Capture Transform 能够让你在对视频流进行编码/加密/发送前，对其进行操作的 API。比方说，在视频会议中模糊你的背景，保护我们的隐私。

这个 API 就是将视频流转换成 worker, worker 能对视频流中的每一帧数据进行读取和修改。修改过后的视频流之后就可以照常传输。

Encoded Media Transform

Encoded Media Transform 能够在视频流被编码后，加密和发送前对其进行操作，这样利用 SFU 就能实现端到端的加密，即添加一层服务器无法解码的加密。这样被编码后的视频流经过处理后，发送到 worker，可以用会话参与者的 key 进行加密，而不需要与服务器分享 key。

可以应用在。用户不希望必须信任中继节点的安全性场景下，例如，在他们的云提供商中运行 SFU 的虚拟机。

该 API 可以与我们前面提到的 IETF 的 SFrame 搭配使用。

Transferable DataChannels

Transferable DataChannels 可以将较大的数据量从主线程中取出进行单独处理。这将允许一个 app 创建一个数据通道，然后给这些数据分配一个 javascript worker 对数据进行处理。这个 worker 就可以运行在浏览器的其他核上。

实际上，这就意味着你可以给一个 worker 创建一个单独的 datachannel，实际上就相当于另开一个网页处理大批量的数据。

Webcodecs

严格来说，这并不能算作是 WebRTC。

Webcodecs 就是使用 jacascript 来创建音视频的编码参数，当你想在视频被发送前压缩视频时就可以用到。

WebTransport

严格来说，这也不能算作是 WebRTC。

WebTransport 是一种与服务器低延迟通信的方法，并且支持不可靠和乱序的通信。使用的是 QUIC 协议，这是一种新兴的 HTTP/3 协议，使用的是 UDP 网页套接字，这意味着它使用与 HTTP/3 相同的服务器防火墙和端口。

将上面讲到的 API 组合到一起，未来的视频会议服务可能会是这样的（如图 1 所示）。

WebRTC 的未来（关于新 API, WHIP 以及 web 2.5） — 图 1 未来的视频会议服务

No WebRTC?

主讲人认为可能日后构建一个视频会议的连接并不需要一个完整的 WebRTC，而是用到 WebRTC 中的一些 API 就可以完成，因为 WebRTC 建立的流程中有很多复杂且琐碎的步骤，比如说：

NAT/P2P(ICE)
E2E(DTLS)
SRTP

这些过程在未来的视频服务中都可以被省略，取而代之的是 WebTransport+WebCodecs，过程更简洁，且理论上更容易实现。但是实现这样的过渡可能会需要点时间。

关于浏览器

如图 2 所示，在各个平台上的各大浏览器，可以说基本上是相同的，WebRTC 在不同浏览器中的实现只有细微的差别。

原生开发环境

WebRTC 的原生 app 如图 3 所示，选择一个适合自己的进行开发即可，或者在一个封装好的 Webview 中使用 WebRTC。

服务器选择

如果你确实需要一个服务器，那么我们推荐你使用以下所述的服务器服务。为了安全起见，最好使用 CPAAS 的服务供应商。

市场

一些其他因素对流媒体服务的影响：

越来越多的法规对中心数据的保护；
终端设备的容量越来越大（智能手机/浏览器）；
在终端设备中嵌入人工智能功能的成本非常低，一台 iphone 的花费当然比 Nvidia 的一张显卡便宜）；
对低延迟的需求（游戏，智能驾驶，无人机，视频会议等等）；
终端设备可用带宽上涨，5G 可以做到下行 200Mbit/s，上行 29Mbit/s。

那我们必须得充分利用终端设备增长的各种容量（带宽，人工智能性能等）。

NAT

谈谈 WebRTC 中的 NAT, 它使得连接两台终端设备变得困难，除非这两台设备在同一局域网下。

有没有一种安全且可以广泛部署的方式，可以让两个边缘设备通过多个NAT层连接？

WebRTC at the edge

WebRTC 已经具有：

P2P NAT traversal
E2E security
Bandwidth estimation

我们现在已经有一些轻量的 WebRTC 栈供设备使用，终端设备也有了比以往更大的带宽和容量，那我们可以做些什么？

New Example Apps on the Edge

如图 4 所示，给书友会议提供舒适空间，且支持大笑/啧啧声/咕噜声且无画面闪烁，没有服务器开销，仅仅利用自己的带宽资源。

一个安全的婴儿监护应用

由一个 WebRTC 硬件设施实现，实时的音视频数据，可以以 P2P 模式实现，以 E2E 方式加密。

Modern Webcam

可以实现多个观看者的同步。

直播 1080p H264 的视频；
分发到 20+ 的浏览器用户；
从一个物联网摄像机中获取源视频；
使用 vDSL；
没有云过程；
不需要中心许可证，是端到端安全的。

远程控制

这个案例使用了 |pipe| 的轻量栈，对 Arm 友好；
远程用户可以观看和控制至多 6 台设备；
共享音频空间；
在树莓派上运行；
基本无需任何安装，因为 Web 接口加载了 WebRTC 的数据通道。

Remote web server

远端的 web 服务器实现，其域名为 dev.pi.pe，该页面的代理是通过

WebRTC 数据通道
服务器 worker
Iframe

实现的。对没有授权的用户和访客都不可见。

Web2.5

Web 3.0 是一个开源的，不可靠的以及无许可的网络，在未来它可以使用户和服务器通过一个底层的端到端的网络直接交互数据，而不需要任何第三方介入。

但是上述案例并没有完全符合 Web3.0 的要求，我们在第一次建立连接时需要可靠连接，也许我们可以将其称作 Web 2.5。

Web2.5 是生态友好的

它仅运行在你的手机上，不需要验证工作，不需要在服务器中部署，这样就不需要大型冷却工作，不消耗国家电能，而且在大部分浏览器上已经可行。