WebRTC 入门:一分钟理解会议系统的三种架构(Mesh/SFU/MCU)

在 WebRTC 中,两点之间的 P2P 通话是基础,但当参会人数增加到 3 人、4 人甚至更多时,单纯的点对点连接就会面临挑战。本文将带你深入浅出地了解 WebRTC 会议的三种主流架构:MeshSFUMCU


1. Mesh 架构:完全互联的网状结构

这是最直观、也是最基础的架构形式。

核心原理

假设有 A、B、C、D 四个人需要参会。在 WebRTC 仅支持 P2P 的前提下,为了让所有人都能互通,每个客户端都必须和其余所有人建立连接。

  • A 的视角:A 必须分别和 B、C、D 建立关联,形成 A-B、A-C、A-D 三条通路。只有这样,A 才能把视频传给他们,并接收他们的视频。
  • B 的视角:同理,B 也要和 A、C、D 建立关联。

代码层面

从 WebRTC 的核心载体 PeerConnection 来看:

  • 一对关联关系 = 一个 PeerConnection 对象
  • 例如 A-B 这一关系,在代码中实际就是创建了一个 PeerConnection 对象,该对象内部维护着 A 和 B 之间的 SDP 信令媒体信息
  • 如果是 4 人会议,A 的浏览器里就需要维护 3 个 PeerConnection 对象。

优缺点

  • 优点:服务器成本低(因为不需要服务器转发媒体流,只负责信令),逻辑简单。
  • 缺点 :客户端带宽压力极大 。一个 N 人会议需要建立 N × (N − 1) / 2 条 P2P 连接 , 每个客户端需要维护 N − 1 条 RTCPeerConnection,连接数量呈平方级增长。

2. SFU 架构:高效的"中心转发"

SFU(Selective Forwarding Unit,选择性转发单元)是目前主流的会议架构。它引入了一个服务器作为中转站,客户端只发一路流给服务器,服务器负责把这路流"复制"并转发给其他参会者。而这个服务器则被称为 SFU 服务器

核心原理

为了理解 SFU,我们可以拿发快递做比喻:

  • Mesh 架构:就像是你(A)要给 B、C、D 三个人送礼物,你需要亲自开车跑三趟,分别把礼物送到他们每个人手里。
  • SFU 架构 :就像是一个快递集散中心
    • 你(A)只需要把礼物打包发给集散中心(SFU 服务器)。
    • 集散中心收到后,负责把你的礼物分别派送给 B、C、D。
    • 同理,B、C、D 也只需要把他们的礼物发给集散中心,由集散中心统一转发给你。

代码层面

在 SFU 架构中,代码逻辑发生了质的变化:

  • 1 个 PeerConnection:无论会议室里有多少人,每个客户端只需要维护 1 个 PeerConnection 对象。

    虽然每个客户端只需要维护 1 个 RTCPeerConnection ,但这个连接中会承载 多路 MediaStreamTrack 。因此客户端的下行带宽和解码压力,仍然随参会人数线性增长(N−1)

  • 对端永远是 SFU:这个 PeerConnection 的连接对象永远是 SFU 服务器,而不是其他客户端。

架构优势

  1. 客户端连接数低:每个客户端只需要 1 个 PeerConnection
  2. 上行带宽压力小 :无论会议中有多少人,客户端始终只上传 1 路音视频流
  3. 延迟低:SFU 只做媒体转发,不解码、不混流,延迟接近 P2P
  4. 扩展性好:支持几十人规模的会议,是当前主流视频会议系统的核心架构

缺点

  1. 下行带宽仍然随人数增长 :客户端需要接收 N−1 路媒体流,下行带宽和解码压力线性增加。
  2. 服务器带宽成本高:虽然不吃 CPU,但对服务器出口带宽要求很高。

3. MCU 架构:全能的"媒体大脑"

MCU(Multipoint Control Unit,多点控制单元)它大体上和 SFU 类似,但它不仅仅是转发,还会对流进行混合(Mixing)、转码和处理。服务器把所有人的画面拼合成一张图,编码成一路视频流发给客户端。

适用场景

MCU 专为媒体场景复杂的情况设计,例如:

  • 多种不同设备接入:接入会议的不只是手机电脑,还有监控摄像头(RTSP流)、硬件终端。
  • 直播与转播:需要将会议画面推流给成千上万的观众。
  • 云端录制:需要对会议进行高质量存档。

MCU 服务器内部做的事

所有参会的流首先进入 MCU 服务器,在这里,它们会经历深度的处理:

  1. 媒体转码 :这是 MCU 的核心能力。
    • 比如监控摄像头的视频是 H.265 格式,浏览器不支持,MCU 可以将其实时转码为 H.264。
    • 将 RTMP、RTSP 等协议转换为 WebRTC 标准的 RTC 流,或者将 RTP 转为 FLV 供直播使用。
  2. 云端录制:服务器可以直接过滤并录制经过的流。
  3. 服务端 AI 检测
    • 在大型直播中,内容安全至关重要。MCU 可以在服务端接入 AI 鉴别中心,实时检测直播内容。
    • 一旦发现非法内容,AI 可以直接切断直播,确保安全。
  4. 其他能力:媒体流混合(将多个人画面合成一个画面)、音频提取、视频抽帧存档等。

总结

在 WebRTC 多人实时通信中,架构选择的本质 ,是如何在 客户端压力、服务器成本、延迟和功能复杂度 之间做取舍。

维度 Mesh SFU MCU
PeerConnection N−1 1 1
客户端上行 N−1 路 1 路 1 路
客户端下行 N−1 路 N−1 路 1 路
服务器压力 极低 中(带宽) 极高(计算)
延迟 最低 较高
扩展性 极差 很好
典型应用 1v1 视频会议 直播 / 融合
相关推荐
粟悟饭&龟波功14 小时前
【软考系统架构设计师】九、架构演化与维护
前端·后端·架构·系统架构·软件工程
天远云服14 小时前
Fintech硬核架构:解析天远贷前风险报告接口在Go微服务中的解析策略
微服务·架构·golang
小坏讲微服务14 小时前
微服务是个啥?SpringCloud又是弄啥嘞?
spring cloud·微服务·架构
AI指北14 小时前
每周AI看 | OpenAI押注音频AI、江南布衣引入网易云商客服Agent,推动客户服务从“降本”迈向“增收”、DeepSeek提出大模型训练新架构
人工智能·ai·架构·agent
西格电力科技14 小时前
光伏四可装置硬件平台架构详解:计算单元、通信接口与可靠性设计
运维·人工智能·分布式·架构·系统架构·能源
CoderIsArt14 小时前
iSCSI架构中客户端与服务端
服务器·网络·架构
小股虫14 小时前
心脏手术指南:如何安全地为运行中的系统更换“数据库引擎”?
数据库·安全·架构·方法论
哈里谢顿1 天前
一致性哈希介绍
架构
softshow10261 天前
Ubuntu22.04(ROS2 humble)小车仿真环境搭建
架构