Webrtc一对一的通信，通常采用的是端到端的方式，那如果多人通信的架构方案一般有这三种常见的方案

Mesh方案

即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。

当某个浏览器想要共享它的音视频流时，它会将共享的媒体流分别发送给其他 3 个浏览器，这样就实现了多人通信。这种结构的优势有如下：

• 不需要服务器中转数据，STUN/TUTN 只是负责 NAT 穿越，这样利用现有 WebRTC 通信模型就可以实现，而不需要开发媒体服务器。
• 充分利用了客户端的带宽资源。
• 节省了服务器资源，由于服务器带宽往往是专线，价格昂贵，这种方案可以很好地控制成本。

劣势：

• 共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，这样对上行带宽的占用很大。参与人越多，占用的带宽就越大。除此之外，对 CPU、Memory 等资源也是极大的考验。一般来说，客户端的机器资源、带宽资源往往是有限的，资源占用和参与人数是线性相关的。这样导致多人通信的规模非常有限，通过实践来看，这种方案在超过 4 个人时，就会有非常大的问题。
• 另一方面，在多人通信时，如果有部分人不能实现 NAT 穿越，但还想让这些人与其他人互通，就显得很麻烦，需要做出更多的可靠性设计。

MCU 方案(MultiPoint Control Unit)

MCU 主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。

MCU 技术在视频会议领域出现得非常早，目前技术也非常成熟，主要用在硬件视频会议领域。不过我们今天讨论的是软件 MCU，它与硬件 MCU 的模型是一致的，只不过一个是通过硬件实现的，另一个是通过软件实现的罢了。MCU 方案的模型是一个星形结构，如下图所示：

我们来假设一个条件，B1 与 B2 同时共享音视频流，它们首先将流推送给 MCU 服务器，MCU 服务器收到两路流后，分别将两路流进行解码，之后将解码后的两路流进行混流，然后再编码，编码后的流数据再分发给 B3 和 B4。

对于 B1 来说，因为它是其中的一个共享者，所以 MCU 给它推的是没有混合它的共享流的媒体流，在这个例子中就是直接推 B2 的流给它。同理，对于 B2 来说 MCU 给它发的是 B1 的共享流。但如果有更多的人共享音视频流，那情况就更加复杂。

MCU 主要的处理逻辑如下图所示：

1. 接收共享端发送的音视频流。
2. 将接收到的音视频流进行解码。
3. 对于视频流，要进行重新布局，混合处理。
4. 对于音频流，要进行混音、重采样处理。
5. 将混合后的音视频进行重新编码。
6. 发送给接收客户端。

优点

• 技术非常成熟，在硬件视频会议中应用非常广泛
• 作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。
• 将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验非常好。

缺点

• 重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大。
• 重新解码、编码、混流还会带来延迟。
• MCU服务器的压力较大，需要较高的配置。

SFU(Selective Forwarding Unit)

SFU 像是一个媒体流路由器，接收终端的音视频流，根据需要转发给其他终端。SFU 在音视频会议中应用非常广泛，尤其是 WebRTC 普及以后。支持 WebRTC 多方通信的媒体服务器基本都是 SFU 结构。SFU 的拓扑机构和功能模型如下图：

在上图中，B1、B2、B3、B4 分别代表 4 个浏览器，每一个浏览器都会共享一路流发给 SFU，SFU 会将每一路流转发给共享者之外的 3 个浏览器。

下面这张图是从 SFU 服务器的角度展示的功能示意图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lVbzLWlM-1591512514956)(
相比 MCU，SFU 在结构上显得简单很多，只是接收流然后转发给其他人。然而，这个简单结构也给音视频传输带来了很多便利。比如，SFU 可以根据终端下行网络状况做一些流控，可以根据当前带宽情况、网络延时情况，选择性地丢弃一些媒体数据，保证通信的连续性。

目前许多 SFU 实现都支持 SVC 模式和 Simulcast 模式，用于适配 WiFi、4G 等不同网络状况，以及 Phone、Pad、PC 等不同终端设备。

优点

• 由于是数据包直接转发，不需要编码、解码，对 CPU 资源消耗很小
• 直接转发也极大地降低了延迟，提高了实时性。
• 带来了很大的灵活性，能够更好地适应不同的网络状况和终端类型。

缺点

• 由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步；相同的视频流，不同的参与人看到的画面也可能不一致。
• 参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。总之，整体在通用性、一致性方面比较差。
• 每个端需要建立一个连接用于上传自己的视频，同时还要有N-1个连接用于下载其它参与方的视频信息，消耗的带宽也是最大的(带宽比较烧钱)

通过上面的分析和比较，相信你已经有了一个大概的认知。如何选择架构方案还需要根据业务场景来判断，没有最好的是只有最适合的。

1.Simulcast 模式

所谓 Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流（一般为三路，如 1080P、720P、360P）。而 SFU 可以将接收到的三路流根据各终端的情况而选择其中某一路发送出去。例如，由于 PC 端网络特别好，给 PC 端发送 1080P 分辨率的视频；而移动网络较差，就给 Phone 发送 360P 分辨率的视频。

Simulcast 模式对移动端的终端类型非常有用，它可以灵活而又智能地适应不同的网络环境。下图就是 Simulcast 模式的示意图：

2. SVC 模式

SVC 是可伸缩的视频编码模式。与 Simulcast 模式的同时传多路流不同，SVC 模式是在视频编码时做“手脚”。

它在视频编码时将视频分成多层——核心层、中间层和扩展层。上层依赖于底层，而且越上层越清晰，越底层越模糊。在带宽不好的情况下，可以只传输底层，即核心层，在带宽充足的情况下，可以将三层全部传输过去。

同一路流，分成了多具层，核心层，护展层和边缘层，当带宽不足时，由上层逐渐丢弃！

如下图所示，PC1 共享的是一路视频流，编码使用 SVC 分为三层发送给 SFU。SFU 根据接收端的情况，发现 PC2 网络状况不错，于是将 0、1、2 三层都发给 PC2；发现 Phone 网络不好，则只将 0 层发给 Phone。这样就可以适应不同的网络环境和终端类型了。

总结

1. 由于各方面限制，Mesh 架构在真实的应用场景中几乎没有人使用，一般刚学习 WebRTC 的才会考虑使用这种架构来实现多方通信。（可以简单了解下）
2. MCU 架构是非常成熟的技术，在硬件视频会议中应用非常广泛。像很多做音视频会议的公司之前都会购买一套 MCU 设备，这样一套设备价格不菲，最低都要 50 万，但随着互联网的发展以及音视频技术越来越成熟，硬件 MCU 已经逐步被淘汰，当然现在也还有公司在使用软 MCU，比较有名的开源项目是 FreeSWITCH。
3. SFU 是最近几年流行的新架构，目前 WebRTC 多方通信媒体服务器都是 SFU 架构。从上面的介绍中你也可以了解到 SFU 这种架构非常灵活，性能也非常高，再配上视频的 Simulcast 模式或 SVC 模式，则使它更加如虎添翼，因此SFU模式已经渐渐成为主流了。
4. 目前的实际应用中，使用Simulcast比使用SVC多，webRTC对两种都支持

webRTC之Mesh/MCU/SFU通信架构区别(九)相关推荐

1. webrtc服务器架构Mesh/MCU/SFU

   互动直播之WebRTC服务开源技术选型 https://www.jianshu.com/p/73f2615dc3ef WebRTC 开发实践:为什么你需要 SFU 服务器 https://cloud. ...

2. 多人视频通讯常用架构Mesh/MCU/SFU

   问题:为什么要搞这么多架构? webrtc虽然是一项主要使用p2p的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很带宽和性能的问题,所以就有了下图 ...

3. WebRTC / Jitsi / 多人视频通讯常用架构 Mesh / MCU / SFU

   问题:为什么要搞这么多架构? WebRTC 虽然是一项主要使用 P2P 的实时通讯技术,本应该是无中心化节点的,但是在一些大型多人通讯场景,如果都使用端对端直连,端上会遇到很带宽和性能的问题,所以就有 ...

4. WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信架构

   WEBRTC三种类型(Mesh.MCU 和 SFU)的多方通信架构 WebRTC 本身提供的是 1 对 1 的通信模型,在 STUN/TURN 的辅助下,如果能实现 NAT 穿越,那么两个浏览器是可以 ...

5. 视频会议服务器SFU、MCU、Mesh三种类型的区别

   WebRTC 本身提供的是 1 对 1 的通信模型,在 STUN/TURN 的辅助下,如果能实现 NAT 穿越,那么两个浏览器是可以直接进行媒体数据交换的:如果不能实现 NAT 穿越,那么只能通过 T ...

6. （1）Kurento之WebRTC通信架构

     关于WebRTC网上有好多介绍,这里我就不详细的叙述了.重点放在WebRTC的项目实施过程,涉及后续开发,将会有详细介绍.   WebRTC是由谷歌提出的一套基于UDP协议的网页流媒体协议.有以下 ...

7. Tigo发布最先进的无线技术Mesh，作为TS4平台的新太阳能通信架构

   Mesh使得每个TS4单元都能充当太阳能电池阵上的信号中继站,并借助近日宣布推出的TAP扩大无线范围   加州洛斯加托斯--(美国商业资讯)--智能组件Flex MLPE平台领域的先锋企业Tigo®今 ...

8. WebRTC多人音视频聊天架构及实战

   三种模式 简单介绍一下基于 WebRTC 的多人通信的几种架构模式. 1.Mesh 架构 我们之前写过几个 1 v 1 的栗子,它们的连接模式如下: 这是典型的端到端对等连接,所以当我们要实现多人视频 ...

9. 网络音视频通信架构-商业模式

   视频会议服务端架构 架构 在视频会议场景中,主要有三种类型的服务器架构,Mesh,MCU和SFU,WebRTC主推的是无中心的P2P架构,会为每一个端建立一个PeerConnection对象,这就是M ...

最新文章

1. ROS探索总结（一）（二）（三）：ROS总体框架 ROS总体框架 ROS新手教程
2. CentOS 6.5 安装与配置LAMP
3. VTK：绘制截锥体用法实战
4. springMVC3学习(四)--訪问静态文件如js,jpg,css
5. 【pyqt5学习】——最新版：配置external tools(designer、pyuic、pqrcc)
6. rs232读取智能电表_三相电表怎么看度数 怎么计算总电量
7. Alibaba Sentinel 限流与熔断初探
8. 利用R、Octave、NumPy和SciPy求解线性方程组
9. c++运动学正反解 ros_ROS系统MoveIt玩转双臂机器人系列（六）–D-H逆运动学求解程序（C++）...
10. [转载] python hex转字符串_Python hexstring-list-str之间的转换方法
11. 每日算法系列【LeetCode 1031】两个非重叠子数组的最大和
12. 电脑芯片和服务器芯片,王思聪的服务器和我们的电脑有什么区别？
13. 【树上分块】【dfs序】2018沈阳网络赛 —— J题
14. Java 实现 贪吃蛇 小游戏【附源码】
15. MFC开发之显示网页
16. mac的python换字体_Mac OSX Yosemite系统字体修改
17. python爬微博话题_用Python写一个简单的微博爬虫
18. 大学生计算机系统推荐,上大学买电脑？最适合大学生学习用的Windows笔记本电脑推荐！...
19. varchar可以设置唯一吗_微信可以设置特效主题皮肤了，满屏幕的小爱心，你心动了吗？...
20. centos7是linux内核,在CentOS 7上用源代码编译最新的Linux内核

热门文章

1. 复制虚拟机/vmware中linux系统
2. 使用 Rust 构建分布式 Key-Value Store
3. git 远程代码被覆盖
4. UILabel「行距,首行缩进」
5. 来自天国的 kubernetes
6. Appnium学习日记一（下载安装Appnium）
7. Atitit.struts排除url 的设计and 原理 自定义filter 排除特定url
8. redis分布式客户端中间件
9. django新闻页面编写
10. 【机器学习】Weighted LSSVM原理与Python实现：LSSVM的稀疏化改进