WebRTC Mesh 架构

最简单的WebRTC实例可以让你在两个浏览器之间建立一个实时的端对端连接,在其中交换个人视频、音频和数据。具体过程如图:

最简单的WebRTC形式

当然,大家都知道还需要信令和几个STUN/TURN服务器来完成上述操作。目前,我们先假设这些部分都已齐全。

办个派对

如果我们在上述连接中加入一个用户,两个用户,三个用户,会发生什么呢?这就是被定义为多方参与的一种情况。此种情况下的规则有所不同,甚至可以说大不相同。

涉及到如何处理WebRTC上的多方连接时,有三种策略可供选择——Mesh、SFU和MCU。Mesh是最简单,也可能是最常用的解决方案。今天我们要讨论的就是它。

Mesh

为了保证连接成功,使用RTCPeerConnection API的每一端都必须创建一个连接对象。这个连接对象需要添加所有相关的信息,如视频和音频流、STUN/TURN服务器地址,以及创建 Interactive Connectivity Establishment (ICE)候选者,或接收任何数据时所需的处理程序。

然后,API负责使用所有已传递的数据建立连接,这其中会有一个信令处理的过程。

最后,我们只需对添加到呼叫中的每一位重复这一过程。换句话说,我们会为每一位都创建另外的RTCPeerConnection对象。

因此,如果我们使用该策略,在上述图表中添加一端,过程看起来会是这样的:

可以看到,现在每一端都在通过向其他两端发送媒体流和数据,来维护另外的一个连接。同时,每一端也会从另两端那里接收媒体流和数据。

谁负责邀请大家来参加派对

那么,如果再增加几个对等端会是什么样子呢?

若用户数量持续增加,处理和带宽的消耗会过大。该问题在移动设备或低配电脑上会更为明显,因为他们的资源更有限。此外,宽带连接也是如此。因为宽带连接通常与合同挂钩,规定了每月的流量使用限制。

若总计有五个用户,每个浏览器都需要维持四个额外的连接,用于发送、接收流和数据,以及与其他对等端进行交流。

综上所述,我们可以说Mesh是实现多方交流的最简单的方法。因为它不需要对基础设施进行任何改变。所有的工作都可以在浏览器上完成。问题是,这种架构只适用于少量的用户。

替代方案

如果想在不产生任何问题的前提下支持更多的用户,我们需要找到另一种可替代策略,一种允许我们混合所有由Mesh创建的连接,或以某种方式路由它们,以避免客户端的高CPU和带宽消耗。比如说MCU (mixing connections) ,以及 SFU (routing connections) 等方法。

使用WebRTC搭建应用程序比大家想象中要难。该操作需要一个专家团队来完成。

文章地址:https://webrtc.ventures/2021/06/webrtc-mesh-architecture/

原文作者:Hector Zelaya