9、多用户连接架构：Mesh、SFU、MCU 全面对比
聊到多人实时通信，很多朋友第一反应就是「把两个人连起来的方式，扩展到 N 个人不就行了？」。嗯，真没这么简单。我在早期做视频会议项目时，就踩过这个坑——当时天真地用了全连接方案，结果 6 个人开会，客户端直接卡成幻灯片。
今天咱们就把三种主流架构掰开揉碎讲清楚：Mesh（网状）、SFU（选择性转发单元）、MCU（多点控制单元）。每种我都亲手搭过，坑也踩了不少，希望能帮你少走弯路。
9.1 为什么需要多用户架构？
WebRTC 本身是点对点的。两个人通话，直接建一个 PeerConnection 就行。但如果是 5 个人、10 个人呢？
你想想看，每个客户端都要跟其他所有人建立连接。5 个人就需要 10 条连接。10 个人就是 45 条。这个数字增长是 O(n²) 的——说白了，人数翻倍，连接数翻四倍。
更头疼的是上行带宽。每个客户端都要把自己的音视频流发送给其他所有人。如果你的上行只有 5Mbps，分给 9 个人，每人只能分到 500Kbps 左右。画质？别想了。
所以我们需要不同的架构来解决这个扩展性问题。三种主流方案各有取舍，没有银弹。
9.2 Mesh 架构：最简单的方案
Mesh 架构，也叫全连接架构。每个客户端跟其他所有客户端建立直接的 PeerConnection。
举个例子：4 个人开会，每个人需要建立 3 条连接，总共 6 条连接。每条连接都是独立的 P2P 通道。
- 不需要服务器转发媒体流
- 每个客户端上行 = 单路码率 × (N-1)
- 每个客户端下行 = 单路码率 × (N-1)
- 延迟最低（直连）
我在一个内部工具项目里用过 Mesh。当时团队只有 4 个人，需求就是简单语音通话。Mesh 完美胜任，部署也简单——一个信令服务器就够了，不需要额外的媒体服务器。
但如果你要支持 10 人以上，Mesh 基本就废了。为什么？
- 上行带宽爆炸：假设每路视频 1Mbps，10 个人，你得上行 9Mbps。普通家庭宽带的上行也就 10-20Mbps，再开个摄像头就满了。
- CPU 负担重：每个连接都要独立编码、加密。我测试过，6 路视频同时编码，笔记本风扇直接起飞。
- NAT 穿透困难：连接数越多，打洞失败的概率就越高。总有几个连不上的。
9.3 SFU 架构：当前最主流的选择
SFU（Selective Forwarding Unit），选择性转发单元。它不混流，只转发。每个客户端只跟 SFU 服务器建立一条连接，把自己的流推上去，然后 SFU 把其他所有人的流转发下来。
说白了，SFU 就是一个「智能路由器」。它知道谁在说话、谁在看谁，可以按需转发。
- 每个客户端上行 = 单路码率（只推一路给 SFU）
- 每个客户端下行 = 单路码率 × (N-1)（SFU 转发所有其他人的流）
- 服务器带宽 = 上行 × N + 下行 × N
- 支持 Simulcast（同时发送多分辨率流）
我个人习惯用 SFU 做中大型会议。比如 Zoom、Google Meet 底层用的就是 SFU 变种。为什么它这么流行？
- 上行压力小：你只需要推一路流给服务器，不管多少人开会，上行带宽固定。
- 灵活性强：SFU 可以决定转发哪些流。比如只转发当前说话人的视频，或者根据用户屏幕大小选择合适的分辨率。
- 支持 Simulcast：客户端同时发送 3 路不同分辨率的流（比如 720p、360p、180p），SFU 根据接收端需求转发合适的流。这个功能我在项目中用过，效果非常好——手机端收小流，PC 端收大流，带宽利用率极高。
但 SFU 也有缺点：
- 服务器带宽成本高：N 个人开会，服务器需要处理 N×(N-1) 路的转发。100 人会议，服务器要转发 9900 路流。带宽成本不低。
- 客户端解码压力大：每个客户端要解码 N-1 路视频。10 个人就是 9 路解码，手机可能扛不住。
- 延迟比 Mesh 略高：多了一跳（客户端 → SFU → 客户端），但通常可以接受（20-50ms）。
9.4 MCU 架构：老牌方案，但正在被淘汰
MCU（Multipoint Control Unit），多点控制单元。它把所有客户端的流收上来，在服务器端混成一路流，再分发给所有人。
你看到的「九宫格」画面，其实就是 MCU 在服务器端拼好的。每个客户端只需要解码一路流。
- 每个客户端上行 = 单路码率
- 每个客户端下行 = 单路码率（只收一路混流）
- 服务器带宽 = 上行 × N + 下行 × N（但流数少）
- 服务器需要做混流、转码，CPU 消耗极大
MCU 最大的优势是客户端压力最小。不管多少人开会，客户端只需要编解码一路流。这对移动端、低端设备非常友好。
但它的缺点也很致命：
- 服务器成本极高：混流需要大量的 CPU/GPU 资源。我见过一个支持 50 人的 MCU 服务器，用的是双路 Xeon + 独立显卡，成本轻松上万。
- 灵活性差：所有客户端看到的是同一个画面。你想单独看某个人？不行。你想调整布局？得服务器端改。
- 延迟较高：混流需要等待所有流到达，然后重新编码。延迟通常在 100-300ms。
- 扩展性差：单台 MCU 能支持的人数有限，集群方案又非常复杂。
9.5 三种架构的全面对比
下面这张表是我根据实际项目经验整理的，你可以直接拿去用：
| 维度 | Mesh | SFU | MCU |
|---|---|---|---|
| 客户端上行带宽 | 单路 × (N-1) | 单路 | 单路 |
| 客户端下行带宽 | 单路 × (N-1) | 单路 × (N-1) | 单路 |
| 服务器带宽 | 无（仅信令） | N × (N-1) 路 | N 路上行 + 1 路下行 |
| 服务器 CPU 消耗 | 极低 | 低（仅转发） | 极高（混流转码） |
| 客户端 CPU 消耗 | 高（N-1 路编解码） | 中（N-1 路解码） | 低（1 路解码） |
| 延迟 | 最低 | 低 | 中高 |
| 灵活性 | 高（可单独控制每路） | 高（可按需转发） | 低（统一画面） |
| 推荐人数 | 2-6 人 | 10-500 人 | 10-50 人 |
| 典型场景 | 小团队语音 | 视频会议、直播 | 传统视频会议 |
9.6 架构选择决策树
如果你现在要做一个多用户通信系统，不知道怎么选，可以参考这个思路：
- 人数 ≤ 4：直接用 Mesh。简单、免费、延迟最低。不需要服务器。
- 人数 5-10：看客户端设备。如果全是 PC，Mesh 还能扛；如果有手机，建议上 SFU。
- 人数 10-100：SFU 是唯一合理的选择。配合 Simulcast 和动态订阅，效果很好。
- 人数 > 100：SFU + 分层架构。比如用级联 SFU，或者结合 CDN 做大规模分发。
- 客户端全是低端设备：考虑 MCU，但要做好服务器成本预算。
9.7 架构对比图
下面这张 SVG 图展示了三种架构的核心区别，你可以直观地看到数据流向：
9.8 实际项目中的选择建议
最后，我想分享一些实际项目中的经验：
- 小团队内部工具：Mesh 就够了。比如 3-5 人的研发团队语音沟通，不需要服务器，部署成本为零。
- 在线教育：SFU 是首选。老师推一路高清流，学生端按需订阅。配合 Simulcast，手机端收小流，PC 端收大流，体验很好。
- 大型直播互动：SFU + CDN 混合架构。主播用 SFU 跟嘉宾互动，观众通过 CDN 拉流，这样能支持上万人。
- 传统视频会议：如果客户要求兼容老旧的 H.323/SIP 设备，MCU 可能是唯一选择。但新项目建议直接上 SFU。
好了，三种架构就讲到这里。记住一句话：没有最好的架构，只有最合适的架构。Mesh 简单但扩展性差，MCU 对客户端友好但服务器成本高，SFU 是当前最平衡的选择。根据你的实际场景和预算来选，别盲目跟风。