多人会议架构Mesh / SFU / MCU 对比一对一视频通话是 P2P 直连多人就麻烦了。每个人都和每个人连还是走服务器转发还是混流成一路这篇讲三种多人 WebRTC 架构Mesh、SFU、MCU对比它们的优缺点、适用场景以及主流的开源方案。大家好我是黒漂技术佬。一对一 WebRTC 很简单P2P 直连就行。但多人视频会议就复杂了——3 个人开会每个人要发几路、收几路带宽够不够CPU 扛不扛得住多人 WebRTC 有三种主流架构Mesh网状、SFU选择性转发、MCU多点控制单元。各有优缺点适合不同场景。这篇把三种架构讲清楚对比选型再介绍几个开源的 SFU/MCU 项目。一、为什么一对一的方案不适合多人一对一A ⇄ B每个人发 1 路收 1 路很轻松。三个人如果全互联A ⇄ B A ⇄ C B ⇄ C每个人要发 1 路其他人收收 2 路其他两个人的。N 个人全互联每个人发 1 路每个人收 N-1 路总连接数N × (N-1) / 2人多了之后上行带宽爆炸上行一般比下行小很多4 个人可能就扛不住了CPU 爆炸同时解码多路视频手机电脑都卡连接管理复杂N 平方的连接数状态管理复杂所以 3-4 个人 Mesh 还能凑合用人再多就不行了得上服务器。二、三种架构对比架构 1Mesh网状 P2P结构每个人和每个人都建立 P2P 连接A / \ B---C工作方式每个人把自己的视频发给其他所有人每个人接收其他所有人的视频没有中心服务器除了信令优点服务器成本低只需要信令服务器延迟最低P2P 直连实现简单纯 WebRTC 就能搞缺点上行带宽压力大每个人都要发 N-1 路解码压力大每个人要解 N-1 路视频人数一多就崩一般 3-4 人是极限不同人的网络差异大有人卡就影响体验适用场景3-4 人的小型会议对成本敏感的小项目用户网络都很好的场景架构 2SFUSelective Forwarding Unit选择性转发单元结构每个人只发一路给服务器服务器转发给其他人┌─────┐ │ SFU │ └──┬──┘ ┌──┼──┐ A B C工作方式每个人只上传 1 路视频到 SFU 服务器SFU 把这路转发给其他所有人每个人接收 N-1 路从服务器来的优点上行压力小每人只发 1 路最大优势延迟较低只转发不混流处理快扩展性好几十上百人都能支持可以 Simulcast上传多路不同质量服务器按需转发缺点下行还是 N-1 路客户端解码压力大需要服务器有带宽成本比 Mesh 复杂适用场景中小型会议5-50 人在线教育小班课大部分视频会议场景目前最主流的多人方案。架构 3MCUMultipoint Conferencing Unit多点控制单元结构服务器把多路视频合成一路再发给每个人┌─────┐ │ MCU │ └──┬──┘ ┌──┼──┐ A B C工作方式每个人发 1 路给 MCUMCU 把多路视频解码、混合、重新编码成一路每个人只收 1 路混合后的视频优点客户端压力最小只收 1 路老设备也能跑下行带宽小每人只收 1 路布局统一服务端控制画面布局方便录制直接录混合后的流就行缺点服务器 CPU 压力大要解码 N 路 编码 1 路很吃算力延迟高多了编解码的过程延迟增加成本高服务器贵带宽也不低灵活性差每个人看到的都一样不能单独看某个人的大画面适用场景大型直播式会议很多人看少数人讲客户端设备弱比如老手机、嵌入式设备需要统一录制、统一布局的场景三、三种架构对比总结维度MeshSFUMCU上行路数每人N-111下行路数每人N-1N-11服务器成本低只有信令中带宽为主高CPU带宽客户端压力高解N-1路中低只解1路延迟最低较低较高适合人数2-4人5-50人任意看服务器实现复杂度低中高录制难中易怎么选2-4 人小会议Mesh简单省成本大多数场景SFU平衡各方面目前主流大型直播/弱客户端MCU客户端压力小现在的趋势是 SFU 为主流配合 Simulcast/SVC灵活度高体验好。四、SFU 的进阶能力Simulcast联播上传方同时推多路不同分辨率/码率的视频SFU 根据接收方的情况转发合适的一路发送方 → 高清 → SFU → 网络好的人收高清 → 标清 → → 网络差的人收标清 → 流畅 → → 很差的收流畅每个人根据自己的网络和屏幕大小看合适的画质不浪费带宽。SVC可伸缩视频编码一路视频里包含多层基础层 增强层网络差只转发基础层低画质网络好转发基础层 增强层高画质比 Simulcast 更省上行带宽但编码复杂兼容性差一些。语音活动检测VAD谁说话就突出显示谁的画面动态调整布局。录制SFU 也可以录制把收到的各路都存下来或者混流后再存。五、主流开源 SFU/MCU 项目SFU 项目1. Mediasoup语言C 核心Node.js 接口特点性能好功能全Simulcast/SVC 都支持生态活跃很多公司在用适合生产环境高性能要求2. Janus语言C特点插件式架构功能丰富不仅是 SFU生态老牌社区大适合各种 WebRTC 场景灵活度高3. LiveKit语言Go特点现代化API 友好SDK 全生态发展快开箱即用适合快速开发不想折腾底层4. pion/ion-sfu语言Go特点纯 Go 实现轻量易二次开发生态Pion 生态适合Go 技术栈定制化需求5. SRS语言C特点国产直播WebRTC 都支持文档中文友好生态国内用户多适合直播转 WebRTC 等场景MCU 项目JitsiJava开源视频会议系统包含 MCU 能力Kurento支持媒体处理可以做 MCU现在纯 MCU 用得少了一般都是 SFU 服务端混流录制的混合方案。六、选型建议快速 Demo / 小团队2-4 人纯 Mesh不用额外服务器再多人直接上 LiveKit / Jitsi开箱即用生产环境中等规模Mediasoup性能好成熟稳定LiveKit开发快SDK 完善Go 技术栈ion-sfu / LiveKitGo 写的好维护好定制国内项目SRS中文文档社区活跃直播 WebRTC 一体化需要大量定制Mediasoup灵活C 核心性能好Janus插件架构扩展性强七、多人会议的其他挑战1. 带宽管理Simulcast不同人收不同质量动态调整网络差自动降码率大流小流说话的人大画面其他人小画面2. 音频处理回声消除多人回声更复杂降噪每个人的环境噪音自动增益不同人声音大小不一样3. 布局管理画廊模式等分主讲模式一个大的其他小的谁说话谁变大4. 录制与回放服务端录制录制格式MP4、HLS回放5. 跨平台Web、Android、iOS、桌面端各端 SDK 适配八、常见误区误区 1SFU 很便宜SFU 虽然 CPU 压力比 MCU 小但带宽成本不低——10 个人每人 1Mbps 上行服务器就要收 10Mbps再转发出去就是 90Mbps 下行。带宽成本要算清楚。误区 2人多了才用 SFU其实 4 个人以上 Mesh 就开始吃力了尤其是移动端上行带宽小。预计会超过 4 人的话直接上 SFU。误区 3MCU 已经淘汰了没有淘汰只是场景变少了。大型直播、弱终端、统一录制的场景还是需要 MCU。或者 SFU 单独的混流服务组合用。误区 4SFU 就是转发很简单没那么简单Simulcast、拥塞控制、丢包重传、带宽估计……要做好不容易。直接用成熟的开源方案别自己写。九、本篇小结多人 WebRTC 三种架构Mesh全互联、SFU转发、MCU混流Mesh2-4 人小场景省服务器成本客户端压力大SFU主流方案每人发 1 路服务器转发平衡各方面5-50 人适用MCU服务端混流客户端压力小但服务器成本高延迟大SFU 进阶Simulcast 多流联播、SVC 分层编码主流开源 SFUMediasoup、Janus、LiveKit、ion-sfu、SRS选型看人数、成本、技术栈大多数场景 SFU 是最佳选择别自己写 SFU用成熟开源方案坑很多下一篇是本系列最后一篇实战一对一视频通话完整实现把前面讲的内容串起来做一个能跑的视频通话 Demo。我是黒漂技术佬。