一、Mesh架构
WebRTC(Web Real-Time Communications)中的Mesh架构是一种将多个终端之间两两进行连接,形成网状结构的通信模式。以下是关于WebRTC的Mesh架构的详细解释:
- 基本概念:在Mesh架构中,每个参与者(或称为peer)都需要与其他所有参与者建立直接的媒体连接。例如,如果有A、B、C、D四个参与者,那么A需要分别与B、C、D建立连接,B也需要分别与A、C、D建立连接,以此类推。
- 带宽需求:在Mesh架构中,每个参与者都需要将自己的音视频流发送给其他所有参与者,同时也需要从其他参与者那里接收音视频流。因此,对于每个参与者来说,带宽需求会随着参与者数量的增加而线性增长。例如,如果每个音视频流占用1M带宽,那么每个参与者需要向其他三个参与者发送数据,总共需要3M上行带宽,同时从其他三个参与者接收数据,也需要3M下行带宽,即每个参与者总共需要6M上下行带宽。
- 优点:Mesh架构不需要服务器中转数据,充分利用了客户端的带宽资源,节省了服务器资源。此外,由于所有参与者都直接相连,因此网络延迟较低,实时性较好。
- 缺点:Mesh架构的缺点主要在于带宽消耗和客户端资源占用。由于每个参与者都需要与其他所有参与者建立连接,因此带宽消耗会随着参与者数量的增加而急剧增长。此外,为了建立和管理这些连接,客户端也需要消耗大量的系统资源。另外,由于要向其他所有参与者发送数据,因此在同等带宽条件下,支持的多人通话路数就相对有限,视频质量(码率)也比较低。
- 适用场景:Mesh架构比较适合网络状况较好、人数较少(如3-4人)的小型会议场景。在大型会议或网络状况较差的情况下,可能需要考虑其他架构(如MCU或SFU)来优化性能和带宽使用。
总的来说,WebRTC的Mesh架构是一种直接、简单的通信模式,适用于小型、实时性要求较高的场景。但在大型会议或网络状况较差的情况下,可能需要考虑其他更复杂的架构来优化性能和带宽使用。
二、设计
如果你已经能熟练掌握1V1通话(http://t.csdnimg.cn/P8n3x),那么设计Mesh构架的多人通话将十分简单。下面我将逐步分析多人通话的整个"握手"过程。
以A、B、C、D四人通话为例。
- A发起offer,A、B、C、D分别创建3个RTCPeerConnection实例,A分别与B、C、D协商,协商成功后A页面有1个localVideo与3个remoteVideo,实现多人通话。
- A发起offer后,B、C、D仅与A协商,B、C、D页面分别有1个localVideo与1个remoteVideo,仅仅实现了单人通话。
- A发起offer后,B发起offer,A与B已经通话跳过协商,B与C、D协商,此时B页面有1个localVideo与3个remoteVideo,实现多人通话。
- A发起offer后,B发起offer后,C、D分别有1个localVideo与2个remoteVideo,未实现与所有人通话。
- A发起offer后,B发起offer后,C(或D)发起offer,C跳过已经建立的A、B协商,仅仅与D协商,最终A、B、C、D都实现了对话房间的所有人通话。
以上过程4个用户供发起了3次(n-1)次offer,共协商了6次(n*(n-1)/2)。
三、实现
- 根据对话房间人数动态创建RTCPeerConnection实例与remoteVideo。
- 对端用户ID分别与RTCPeerConnection、remoteVideo建立映射。
- 信令服务器跳过已经建立通话的offer。
多人通话效果见下图:
需要源码与教学的请私信我(* ̄︶ ̄)