每个 WebRTC 会议产品最终都要回答同一个架构问题：媒体流如何送达所有人，同时又不耗尽客户端带宽或服务端容量？这个答案会在数年内决定成本、质量和运维复杂度。
本文介绍主要拓扑及其之间的实际权衡，不预设任何特定厂商。
传输基线
WebRTC 通过 UDP（并有 TCP 回退）传输加密媒体，使用 ICE 建立连通性、DTLS 交换密钥、SRTP 加密媒体。信令不在规范之内：由你自行设计。
有两个特性驱动拓扑选择：
- 对客户端而言，上行是昂贵的。 参会者的出网带宽通常就是瓶颈，在移动网络上尤其如此。
- 要规模化就离不开服务端。 点对点在两人场景很优雅，十二个人就不现实了。
Mesh
每个参会者与其他所有参会者直接连接。
- 每个客户端的上行：n−1 路流。
- 服务端媒体负载：无（仅信令）。
- 适用场景：一对一通话、极小规模群聊，或媒体绝不能经过服务端的场景。
Mesh 的质量下降很快。10 位参会者各发送 1 Mbit/s 时，每个客户端大约要上行 9 Mbit/s，同时接收相同的量。移动设备和非对称链路会吃不消，而且没有中心点来实施策略。
SFU（Selective Forwarding Unit，选择性转发单元）
每个客户端向服务端发布一路流（或若干 simulcast 层）；服务端将选定的流转发给订阅者。
- 每个客户端的上行：通常 1–3 层。
- 服务端出网：大致为 发布者 × 订阅者 × 层数，随房间规模增长。
- 适用场景：多数会议产品、互动有限的网络研讨会，以及选择性订阅很重要的大型房间。
SFU 不解码媒体，因此 CPU 成本可控，但它要终结 DTLS/SRTP，所以仍承担带宽和加解密开销。容量规划主要由出网流量决定，而不是编码。
simulcast 与 SVC
使用 simulcast 时，发布端发送多个分辨率，SFU 根据每个订阅者的网络状况转发相应层。SVC 通过分层编码实现类似的自适应。两者都能减少转码需求、改善拥塞下的表现，代价是发布端需要更多上行带宽。
SFU 级联
对于地理上分散或规模极大的房间，SFU 可以级联：一个 SFU 将发布的流转发给另一个 SFU，由后者在本地扇出。这能减少跨区域流量，但会增加时延跳数，并使路由和故障处理更复杂。级联是一种优化手段，而不是默认方案。
MCU（Multipoint Control Unit，多点控制单元）
服务端将音频和视频混合成合成流。
- 每个客户端的上行：一路。
- 服务端工作：解码、混流、编码——CPU 密集且对编解码敏感。
- 适用场景：超大规模直播、异构设备，或接收端带宽严格受限。
- 缺点：合成限制了灵活性（每个观看者看到相同布局）、增加时延，并且服务端成为昂贵的扩展瓶颈。
现代会议产品通常采用带选择性转发的 SFU，仅在录制或直播时做服务端合成，而不是对每位参会者都使用经典 MCU。
对比
| 特性 | Mesh | SFU | MCU |
|---|---|---|---|
| 客户端上行 | 随房间规模增长 | 一到三层 | 一路流 |
| 服务端 CPU | 极低 | 中等（加解密、转发） | 高（混流） |
| 服务端带宽 | 无 | 出网流量高 | 出网较低，CPU 更高 |
| 每位观看者的布局 | 原生 | 灵活 | 受合成限制 |
| 最佳房间规模 | 2–4 人 | 4 人至数百人 | 大型直播 |
| 运维复杂度 | 低 | 中 | 高 |
信令设计决策
拓扑只是设计的一半。信令影响可靠性和运维：
- 状态归属。 把权威的房间状态放在服务端，而不是客户端内存中。
- 基于令牌的鉴权。 签发短期入会令牌；在媒体层和信令层都校验权限。
- 幂等操作。 重连和重试一定会发生；设计入会与发布流程时应保证可以安全重复。
- 版本协商。 假定灰度发布期间客户端与服务端版本会不一致。
- 可观测性钩子。 为入会尝试、协商失败和媒体质量发出事件，以便在不复现会话的情况下排查问题。
NAT 穿透与中继
ICE 会寻找一条路径，但有些网络只允许中继连通。要为 TURN 做好准备：
- 将中继部署在靠近用户的位置，以限制额外时延。
- 单独预算中继带宽；经中继的媒体会被传输两次。
- 监控中继用量；用量突增往往意味着网络变更，而不是正常增长。
在私有化部署中，TURN 可能仅限内网使用，但跨站点和远程接入场景通常需要一个边缘中继。
录制与处理
录制是一条媒体处理流水线，而不是一个勾选项。可选方式包括客户端录制、服务端合成，以及在 SFU 上做流级抓取。每种方式对 CPU、存储、知情同意和留存都有不同影响。先确定策略，再确定实现。
如何选择拓扑
可以用这些问题来判断：
- 典型房间的最大规模是多少，可能出现的最大规模又是多少？
- 参会者主要处于可管理的网络，还是移动网络和公网？
- 观看者需要各自独立的布局，还是共用一路合成画面即可？
- 你愿意为跨区域流量支付多少成本？
- 是否需要录制，谁可以访问录制内容？
对多数私有化企业会议而言，基于 SFU 的设计配合 TURN 中继、simulcast 和清晰的容量模型，是务实的选择。Mesh 在边缘场景中仍有用武之地；MCU 仍适用于直播。
结语
架构选择本质上是约束的另一种表达。先确定房间规模、网络和合规边界，拓扑通常就会随之确定。飞雁音视频 RTC 是一个基于 SFU、可私有化部署的选项，无论你评估哪家厂商，这些问题都同样适用。
页面中标注 Coming soon 或 Roadmap 的能力尚未在当前版本提供；产品能力与上线状态以正式发布说明为准。