首页当你打开一个视频会议应用，10个人的画面同时出现在屏幕上。你有没有想过，这些音视频数据是如何在网络中传递的？是每个人都直接把数据发给其他9个人？还是所有人都把数据发给服务器，再由服务器分发？如果是服务器分发，服务器是简单转发，还是会把10路画面混合成1路？
这些看似简单的问题，背后涉及实时音视频通信最核心的架构选择：P2P、SFU、MCU。不同的选择，意味着完全不同的成本结构、性能表现和用户体验。这篇文章会讲清楚这三种架构的本质区别，以及在什么场景下应该选择哪种方案。
一. 三种架构解决的是同一个问题
多人视频通话时，A、B、C三个人的音视频数据如何互相传递？这是个看起来简单但实际很复杂的问题。
最直观的想法是P2P（Peer-to-Peer）：每个人直接把自己的音视频发给其他所有人。A发给B和C，B发给A和C，C发给A和B。这在人数少的时候可以工作，但人数一多就出问题了。
于是出现了服务器转发的方案。服务器在中间做数据的接收和分发，客户端不需要跟所有其他客户端直连。但服务器具体怎么处理这些音视频数据，就分化出了两条路线：SFU和MCU。
SFU（Selective Forwarding Unit） 选择性转发。服务器收到音视频流后，不做处理，直接转发给需要的人。
MCU（Multipoint Control Unit） 多点控制。服务器收到所有人的音视频流后，混合成一路，再发给每个人。
这三种架构各有优劣，适合不同的场景。
二. P2P：最直接也最受限
P2P架构中，每个参与者都与其他所有参与者建立直接连接。A要把自己的音视频发给B和C，就需要建立两条上行连接；同时A要接收B和C的音视频，需要两条下行连接。
带宽消耗呈指数增长
P2P的最大问题是带宽消耗。假设每路视频流需要1Mbps带宽。3个人的会议，每个人需要发送2路（给另外2个人），接收2路（来自另外2个人），总共4Mbps带宽。但如果是10人会议，每个人需要发送9路，接收9路，总共18Mbps。到了20人，就是38Mbps。
家庭宽带的上行带宽通常远低于下行。很多100Mbps的宽带，上行只有10-20Mbps。10人会议需要的18Mbps上行已经接近极限，20人会议根本跑不动。
连接数的问题
建立和维护WebRTC连接是有开销的。每增加一个参与者，需要建立的连接数会线性增长。10人会议，每个人需要维护9条连接。这不仅消耗带宽，还消耗CPU和内存——每条连接都需要独立的编码器、解码器、加密解密、拥塞控制等。
低端设备很难同时维护这么多连接。手机的CPU和电池都承受不了。
P2P适合的场景
P2P并不是完全不能用，在小规模通话中它有独特的优势。
- 延迟最低。数据不经过服务器中转，直接点对点传输，延迟可以做到很低。
- 没有服务器成本。除了信令服务器帮助建立连接，音视频数据传输不占用服务器带宽和计算资源。
所以P2P适合2-4人的小规模通话，特别是延迟敏感的场景（比如1v1视频聊天、远程游戏联机）。人数一旦超过5人，P2P就开始力不从心了。
三. SFU：转发但不处理
SFU服务器的工作很简单：接收每个参与者的音视频流，然后转发给需要接收的其他参与者。服务器不对音视频数据做任何处理，不解码、不混流、不转码。
带宽从客户端转移到服务器
10人会议中，每个参与者只需要向SFU发送1路上行（自己的音视频），从SFU接收9路下行（其他9个人的音视频）。
客户端的上行带宽需求从P2P的9路降到了1路。这对家庭宽带来说是个巨大的改善——只需要1Mbps上行就能参加10人会议。
但这些带宽消耗转移到了服务器上。SFU需要接收10路上行（每个参与者1路），发送90路下行（每个参与者9路）。总带宽消耗是100Mbps。
服务器计算压力小
SFU的优势是服务器只做转发，不做编解码。
转发的计算量很小，主要是网络IO操作。一台普通服务器就能处理数百路流的转发。相比之下，MCU需要解码、混流、再编码，计算量大得多。
所以SFU可以支持大规模并发。几台SFU服务器就能支撑上千人同时在线的会议。
客户端压力还在
虽然上行带宽降下来了，但下行带宽没变。10人会议，每个参与者还是要接收9路视频，解码9路视频。
低端设备可能解码不过来。手机同时解码9路720p视频，CPU会飙到100%，电池掉电很快，还会发热降频。
这就是SFU的主要问题：把服务器的计算压力转移到了客户端。
Simulcast和SVC：SFU的增强技术
为了解决客户端解码压力大的问题，SFU通常会配合Simulcast（联播）或SVC（可伸缩视频编码）使用。Simulcast的原理是发送端同时编码多个分辨率的流。比如同时编码1080p、720p、360p三路。SFU根据接收端的网络状况和设备性能，选择合适的分辨率转发。
网络好的用户收1080p，网络一般的收720p，网络差的收360p。手机用户主动显示的画面收720p，缩略图收360p。
这样客户端的解码压力可以根据实际需要调整。不需要每个人都解码9路1080p。
SVC是在一路流中包含多个质量层级。接收端可以只解码基础层（低分辨率），也可以解码基础层+增强层（高分辨率）。
SVC的优势是只需要一路流，不像Simulcast需要发送多路。但SVC的编码效率稍差，而且并非所有编码器都支持SVC。目前主流的还是Simulcast。
四. MCU：混合后再分发
MCU的工作方式完全不同。服务器收到所有参与者的音视频流后，会解码、混合、重新编码成一路流，再发给每个参与者。
客户端压力最小
10人会议中，每个参与者只需要发送1路上行（自己的音视频），接收1路下行（MCU混合后的流）。
客户端的下行带宽需求降到最低——无论会议有10人还是100人，客户端只需要接收1路流。解码压力也降到最低——只需要解码1路视频。
这对低端设备非常友好。手机、平板、老旧电脑都能流畅参与大型会议。
服务器计算压力大
MCU需要做大量计算：
- 解码所有输入流。10人会议，MCU要解码10路视频。
- 音频混音。把10路音频混合成1路。
- 视频合成。把10路视频画面排版到一个画布上（类似拼图）。
- 重新编码。把混合后的画面编码成一路新的视频流。
这些操作都需要实时完成，延迟不能太高。编解码是CPU密集型任务，需要强大的服务器或GPU加速。
一台MCU服务器能处理的并发会议数量远少于SFU。通常一台服务器只能支持几十路到上百路流的处理，取决于视频分辨率和服务器配置。
带宽成本低
虽然服务器计算成本高，但MCU的带宽成本低。
10人会议，MCU接收10路上行，发送10路下行，总带宽20路。而SFU需要接收10路上行，发送90路下行，总带宽100路。
对于大规模会议，MCU的带宽成本优势明显。100人会议，MCU总带宽200路；SFU总带宽10000路。
灵活性差
MCU的一个显著问题是灵活性差。
所有人看到的画面都是服务器混合后的统一画面。A不能单独放大B的视频，也不能选择不看C的画面。所有人看到的布局、分辨率、帧率都一样。
如果有人网络差，MCU只能降低混合后流的码率。这意味着所有人的画质都会下降，即使其他人网络很好。
SFU没有这个问题。每个人可以根据自己的网络状况和需求，选择接收不同分辨率的流。
五. 三种架构的对比
| 维度 | P2P | SFU | MCU |
|---|---|---|---|
| 客户端上行带宽 | 高（N-1路） | 低（1路） | 低（1路） |
| 客户端下行带宽 | 高（N-1路） | 高（N-1路） | 低（1路） |
| 客户端计算压力 | 高 | 中高 | 低 |
| 服务器带宽成本 | 无 | 高 | 中 |
| 服务器计算成本 | 无 | 低 | 高 |
| 延迟 | 最低 | 低 | 中 |
| 扩展性 | 差（<5人） | 好 | 中 |
| 灵活性 | 高 | 高 | 低 |
实际选择架构时，需要考虑的因素包括：
- 参与人数。2-4人用P2P，5-50人用SFU，超大规模（数百人）可以考虑MCU或者MCU+SFU混合。
- 设备性能。如果用户设备普遍性能低（比如面向教育市场的低端平板），MCU更合适。如果用户设备性能好，SFU的体验更好。
- 网络环境。用户上行带宽普遍很差的地区（比如某些发展中国家的移动网络），P2P不可行，需要SFU或MCU。
- 成本考虑。SFU的带宽成本高但计算成本低，MCU相反。如果带宽便宜计算贵（比如在云服务商有专线优惠），选SFU；如果计算便宜带宽贵，选MCU。
- 业务需求。需要录制、需要统一画面、需要在会议中插入广告或水印，这些场景MCU更合适。需要灵活布局、需要个性化码率，选SFU。
六. 实际应用中的混合方案
真实的RTC系统很少只用一种架构，通常是根据场景动态选择或混合使用。
按人数动态切换
2-4人的小会议，优先尝试P2P直连。延迟低，没有服务器成本。
5-20人的中型会议，切换到SFU。客户端上行压力小，服务器转发开销可控。
超过20人的大型会议，可以考虑SFU+服务端混流的混合方案（类似MCU的优点，但更灵活）。
切换过程对用户透明。SDK会根据当前参与人数自动选择最优架构。
SFU+MCU混合
有些场景需要同时满足两种需求：部分用户需要灵活的SFU，部分用户需要简单的MCU。
比如一个100人的培训会议。主讲老师和几个助教需要看到所有人的画面，他们使用SFU模式，可以自由选择看谁的画面。普通学员只需要看到老师的画面，他们使用MCU模式，接收一路混合后的流。
这种混合架构可以平衡体验和成本。高价值用户（老师）获得高质量体验，普通用户（学员）降低服务器和带宽成本。
分层SFU
对于超大规模会议（数百人甚至上千人），单层SFU会遇到瓶颈。可以用分层架构。
第一层SFU接收所有参与者的上行流，第二层SFU从第一层拉流并转发给客户端。如果第二层还压力大，可以增加第三层。
分层架构可以水平扩展，理论上没有人数上限。但层数越多延迟越高，需要在扩展性和延迟之间权衡。
CDN+RTC混合
大规模直播场景中，主播和少数连麦观众使用RTC（低延迟），普通观众使用CDN（高延迟但成本低）。
主播通过RTC推流到服务器，服务器一方面通过SFU转发给连麦观众，另一方面转推到CDN分发给普通观众。
连麦观众的延迟在400ms以内，普通观众的延迟在3-5秒，但CDN的分发成本远低于RTC。这种混合方案平衡了互动性和成本。
七. 一些技术细节
SFU的带宽优化
SFU虽然只做转发，但也可以做一些优化来降低带宽消耗。
- 带宽探测和自适应。SFU监测客户端的下行带宽和丢包率，动态调整转发给该客户端的流的码率。客户端网络变差时，自动切换到低分辨率流。
- 按需转发。客户端可以告诉SFU哪些流是当前需要的。比如在多人会议中，只有正在显示的视频才需要高分辨率，缩略图可以用低分辨率甚至关闭。SFU根据客户端的订阅需求选择性转发。
- B帧过滤。视频编码中，B帧（双向预测帧）可以提升压缩率，但增加延迟和解码复杂度。SFU在转发时可以丢弃B帧，只转发I帧和P帧，降低客户端解码压力。
MCU的计算优化
MCU的计算瓶颈主要在视频编解码和混流上。
- 硬件加速。使用GPU或专用的视频编解码芯片（如NVIDIA的NVENC/NVDEC）可以大幅提升编解码性能。一块GPU可以同时处理几十路甚至上百路流。
- 智能混流。不是所有参与者的视频都需要一直混入画面。只混入正在发言的人，或者用户手动选择的几个人。其他人的视频可以只显示头像或者不显示。
- 分层混流。不同客户端接收不同分辨率的混流。移动端接收720p混流，桌面端接收1080p混流。这样可以减少重复编码的计算量。
P2P的网络穿透
P2P最大的技术挑战是NAT穿透。
现代网络中，大部分设备都在路由器或NAT后面，没有公网IP。两个都在NAT后面的设备要建立直连，需要通过ICE协议进行网络穿透。
ICE会尝试多种连接方式：
- 直连。如果双方都有公网IP，直接连接。
- STUN穿透。通过STUN服务器获取自己的公网地址和端口，尝试直连。
- TURN中继。如果前两种都失败（比如双方都在严格NAT后面），通过TURN服务器中继数据。
TURN中继虽然能保证连通性，但失去了P2P的低延迟优势，而且会消耗TURN服务器的带宽。
八. 如何选择架构
架构选择需要看具体场景。
- 社交App的1v1视频聊天，P2P是最直接的选择。两个人直连，延迟低，不需要服务器转发音视频数据，成本也最低。
- 团队视频会议通常是5-30人的规模，SFU是主流方案。客户端只需要1路上行，服务器只做转发不做编解码，扩展性好，可以同时支持大量会议房间。
- 在线教育场景有点特殊。学生用的设备往往性能不高——很多教育平板、老旧手机，同时解码多路视频会卡顿。这种情况下MCU或者SFU+服务端混流更合适，学生端只接收一路混合后的流，设备压力小。
- 大规模网络研讨会可能有几百人甚至上千人参与。这时候纯RTC成本太高，通常会用混合方案：主讲人和几个嘉宾通过SFU实时互动，普通观众通过CDN观看。互动性和成本找到了平衡点。
架构不是选了就不变的。业务在发展，用户规模在增长，使用场景可能也会变化。需要持续关注延迟、卡顿率、服务器成本、客户端CPU占用这些指标，发现问题及时调整。可能一开始用P2P够了，后来用户多了需要切到SFU；也可能一开始预算有限用MCU，后来发现用户对灵活性有要求，需要换成SFU。
