hj118888.com162287l9999WebRTC常见架构

1. Mesh（P2P）

简介

Mesh 服务器架构其实就是标准 P2P 通讯模式的混用，每一个 P2P 连接有独立的传输策略控制，通讯质量有一定的保障。但是，这种架构对于客户端系统是一种浪费，一方面需要分配更多的端口，消耗更多的系统资源；另一方面，由于要向其它三个客户端发送本地音视频数据，增加了上行网络带宽的消耗，在同等带宽条件下，支持的多人通话路数就相对有限，视频质量(码率)也比较低。这种架构比较适合网络状况较好，人数较少，比如一对一的场景中。

缺点

a. 占用大量带宽。以上图为例，假设所有上下行媒体流占用带宽都是 1MB，那么，每个客户端需要提供 3MB 的上行带宽和 3MB 的下行带宽，每个客户端总体消耗的带宽是 6MB。如果复用 PeerConnection 通道的话，也需要建立六条链路。

b. 占用客户端资源。如上图所示，每个客户端在通讯过程中需要同时编码三路媒体流，分别发送给另外三个参会者，而不是共用一路编码媒体流。因此，会占用比较多的客户端资源。

优点

a. 对服务器资源占用最小。这一点也非常好理解，因为压根儿就没有用到流媒体服务器，只需要一个 ICE 穿透服务器就可以满足 P2P 打洞从而建立连接。

b. 成本最低。不像其他架构类型需要对流媒体服务器投入大量的资金和人力成本，节省了在服务器方面的绝大多数支出费用。

c. 去中心化。充分利用了客户端的算力，在边缘计算的大时代下，可能未来还会迎来新的机遇和挑战。

1. MCU（Multi-point Control Unit）

   简介

   MCU 将接收到的多路流进行转码和混合，并向每个终端输出单路流的做法，节省了终端用户的下行带宽，并且还能够对不同网络条件的用户，订制不同码率的输出视频流，让多人场景有更好的用户体验。典型的应用场景是多人音视频通话。这种架构比较适合客户端条件较差的场景，比如使用手机进行多人的视频通话，由服务端来抵消移动端的资源消耗。

缺点

a. 对服务器压力最大。MCU 服务架构需要系统提供一个中心化的 MCU 混流服务器，所有媒体流的解码、编码、转码、混合都在服务器端完成。如上图所示，四个客户端需要把自己的媒体流推流到 MCU 服务器，然后 MCU 服务器再对这四路媒体流进行解码、混流，最后把合并的媒体流发送给四个参会者。因此，MCU 架构的服务器压力非常大，也是三种服务架构中压力最大的。

b. 自定义布局复杂。一般情况下，MCU 服务器仅混流编码一路合并之后的媒体流，上图中的四个参会者接收到的混流媒体流是同一路，看到的视频画面也是一致的。如果某个参会者想改变视频画面的布局，比如放大某个人的视频画面，或者关闭某个人的视频画面，通常是无法满足的。但是，我们也可以定义单独的信令逻辑，请求 MCU 服务器单独编码一路媒体流发送给特定需求的参会者。但是，需要限制或者避免所有参会者都有类似的需求，否则 MCU 服务架构会退化成 SFU 服务架构。

c. 成本最高。如果资金允许的话，还是应该考虑引入高级的 GPU 加速服务器，用来提高流媒体服务器的混流能力。但是，成本也会相应提高。

优点

a. 带宽占用最小。还以上图为例，假设每路媒体流所占带宽大小为 1MB，每个客户端总体消耗的带宽是 2MB。如果复用 PeerConnection 通道的话，只需要建立四条链路。

b. 客户端解码压力小。因为每个参会的客户端都只需要解码一路媒体流，就可以代替分别解码每个参会者媒体流的情况，而另外两种服务架构都需要单独解码其他参会者的媒体流。

1. SFU（Selective Forwarding Unit）

   简介

   SFU 是解决服务器性能问题最有吸引力的方法，因为它不涉及视频解码和编码的计算费用，它以最低的开销来转发各路媒体流，典型的应用场景是1对多的直播服务。这种架构适用于大多数的情况，人数中等的场景，比如大班课，多人语音通话等。

缺点

a. 客户端解码压力大。这一点和 Mesh 服务架构相似，每个客户端需要解码 n-1 路媒体流。如上图所示，每个客户端需要编码一路媒体流同时解码三路媒体流。

b. 服务器成本也相对较高。其实，一般情况下，SFU 架构的服务器成本介于 Mesh 架构和 MCU 架构之间。但是，这也取决 SFU 服务架构的规模和复杂程度。