14、多人通话架构：Mesh、MCU、SFU三种架构对比、SFU架构的优势与选型
多人通话，说白了就是让三个以上的人同时说话、同时看见对方。这跟一对一通话完全是两码事。
一对一的时候，你只需要把视频流发给对方一个人。但三个人呢？每个人都要收到另外两个人的流。四个人？每个人要收三路流。人数一多，客户端和服务器都扛不住。
我最早做多人通话时，天真地以为把一对一复制几份就行了。结果呢？用户的手机直接变成暖手宝，CPU跑满，画面卡成幻灯片。嗯，从那以后我才认真研究起多人架构来。
三种主流架构：Mesh、MCU、SFU
目前业界就三种方案，没有第四种。我一个个说。
1. Mesh架构（全连接网格）
Mesh 是最简单的方案。每个客户端直接跟其他所有客户端建立 P2P 连接。
举个例子：4个人开会，每个人都要建立3个连接，发送1路流，接收3路流。
优点：
- 不需要服务器转发，成本低
- 延迟最小，因为是直连
- 实现简单，WebRTC原生支持
缺点：
- 上行带宽 = 单路码率 × (人数-1)
- 下行带宽 = 单路码率 × (人数-1)
- CPU解码压力随人数线性增长
- 一般只支持4-6人，再多就崩
2. MCU架构（多点控制单元）
MCU 是传统视频会议的老大哥。所有客户端把流发给服务器，服务器解码、混流、编码，再发回给每个客户端。
你想想看，服务器把4个人的画面拼成一个画面，编码成一路流，每个人只收这一路。客户端压力瞬间降下来了。
优点：
- 客户端只收1路流，带宽和CPU要求极低
- 适合大规模会议，几百人都行
- 画面布局统一，体验一致
缺点：
- 服务器压力巨大，需要解码+编码
- 延迟高，因为要等所有流到齐再混
- 服务器成本高，一台机器撑不了多少人
- 灵活性差，不能单独看某一个人的画面
3. SFU架构（选择性转发单元）
SFU 是目前 WebRTC 多人通话的主流方案。服务器不做解码编码，只做转发。客户端发1路流上来，服务器根据需求转发给其他人。
说白了，SFU 就是个聪明的路由器。它知道谁在看谁，只转发需要的流。
优点：
- 服务器压力小，只转发不解码
- 延迟低，转发比编码快得多
- 灵活性高，每个客户端可以选看谁的流
- 支持Simulcast和SVC，适应不同网络
缺点：
- 客户端压力比MCU大，要收多路流
- 带宽消耗比MCU高
- 实现复杂度中等
三种架构对比表
| 维度 | Mesh | MCU | SFU |
|---|---|---|---|
| 服务器负载 | 无 | 高（解码+编码） | 低（仅转发） |
| 客户端负载 | 高 | 低 | 中 |
| 延迟 | 最低 | 高 | 低 |
| 带宽消耗 | 高 | 低 | 中 |
| 扩展性 | 差（4-6人） | 好（百人级） | 好（百人级） |
| 灵活性 | 高 | 低 | 高 |
| 实现难度 | 低 | 高 | 中 |
| WebRTC适配 | 原生支持 | 需改造 | 原生支持 |
为什么SFU成了主流？
我个人习惯用SFU，原因很简单：它找到了一个平衡点。
Mesh 虽然简单，但客户端扛不住。MCU 虽然客户端舒服，但服务器成本太高。SFU 把压力分摊了——服务器只转发，客户端自己解码。
你想想看，现在的手机CPU越来越强，解码几路1080p完全没问题。但服务器的带宽和计算资源是有限的。SFU 正好利用了客户端的算力。
还有一个关键点：SFU 天然支持 WebRTC 的端到端加密。MCU 因为要解码，必须拿到明文，加密就废了。SFU 只转发加密后的数据包，端到端加密完美保留。
SFU选型：mediasoup、Janus、Jitsi
市面上SFU实现很多，我重点说三个最常用的。
1. mediasoup
我个人最喜欢 mediasoup。它是个纯粹的SFU，不做任何多余的事。
特点：
- C++核心，性能极高
- Node.js作为API层，开发友好
- 支持Simulcast和SVC
- 文档清晰，社区活跃
- 无状态设计，易于水平扩展
适合场景：需要高性能、低延迟的实时通信，比如直播连麦、在线教育。
2. Janus
Janus 是个通用型网关，不只是SFU。它支持很多插件，比如视频会议、录音、流媒体等。
特点：
- C语言实现，性能不错
- 插件架构，功能丰富
- 支持WebRTC和RTP/RTCP
- 文档一般，配置复杂
- 单进程模型，扩展性有限
适合场景：需要多种媒体处理功能的场景，比如录制、转码、网关。
3. Jitsi
Jitsi 是个完整的视频会议方案，不只是SFU。它包含了前端、后端、SFU、录播等全套组件。
特点：
- Java实现，JVB（Jitsi Videobridge）是核心SFU
- 开箱即用，部署简单
- 功能完整，有聊天、屏幕共享、录制等
- 性能中等，不如mediasoup
- 社区活跃，文档丰富
适合场景：需要快速搭建完整会议系统的团队，不想从零开发。
选型建议
| 需求 | 推荐方案 |
|---|---|
| 高性能、低延迟 | mediasoup |
| 功能丰富、快速上线 | Jitsi |
| 需要多种媒体处理 | Janus |
| 自研、深度定制 | mediasoup |
| 企业级、稳定优先 | Jitsi |
Simulcast与SVC技术
这两个技术是SFU的杀手锏。它们解决的是同一个问题：不同网络条件的用户，怎么都能流畅观看？
Simulcast（ simulcast 编码）
Simulcast 的意思是「同时广播」。发送端同时编码多路不同分辨率的视频流，比如一路720p、一路360p、一路180p。SFU根据接收端的网络情况，选择转发哪一路。
工作原理：
- 发送端编码3路流（高、中、低）
- SFU收到3路流，存着
- 接收端告诉SFU：我带宽够，给我720p
- 另一个接收端：我网络差，给我180p
- SFU分别转发对应的流
优点：
- 切换清晰度时无延迟，因为流一直在发
- 质量稳定，每路流都是独立编码
缺点：
- 发送端带宽消耗大（3路流 × 码率）
- CPU编码压力大
SVC（可伸缩视频编码）
SVC 跟 Simulcast 思路不同。它只编码1路流，但这路流包含多个层：基础层、增强层1、增强层2。基础层是低质量，加上增强层1变中质量，再加上增强层2变高质量。
工作原理：
- 发送端编码1路SVC流，包含3层
- SFU收到1路流，可以拆开
- 接收端网络好：转发全部3层
- 接收端网络差：只转发基础层
优点：
- 发送端带宽低（只有1路流）
- CPU编码压力小
- 切换更平滑，可以逐层增减
缺点：
- 编码效率低，同样质量下码率更高
- 浏览器支持有限（Chrome不支持SVC）
- 实现复杂
SVG架构对比图
总结
多人通话架构的选择，说白了就是权衡。Mesh 简单但撑不住人，MCU 稳定但成本高，SFU 是当前的最优解。
我个人建议：
- 如果你在做一个demo或者小工具，Mesh 就够了
- 如果你在做商业产品，直接上 SFU
- 选型时优先考虑 mediasoup，性能好、文档全
- Simulcast 是必选项，别省这个功能
嗯，多人通话这块内容不少，但核心就是这些。理解了架构差异，后面的开发就顺了。