WebRTC 服务器模型

1 对 1 通话

两端浏览器(clientA,clientB)可以直接音视频通话，而这种情况又可以分为两种情况：

• P2P(点对点通信) 成功 ClientA 与 ClientB 之间直接建立起数据通道

• P2P 失败 需要中转服务器参与在 ClientA 与 ClientB 之间进行数据转发

为什么存在这两种情况下呢？

因为一般情况下，因为 IPv4 地址紧张，大部分网络设备并没有公网 IP。一定数量的设备通过 NAT 协议，通过一定端口映射手段共享一个公网 IPv4 地址。所以 NAT 协议存在对于两个网络设备（没有独有公网 ip）的网络间建立直接数据通道造成了障碍。关于更多 NAT 协议及网络打洞可自行百度相关知识。

所以 webrtc 1 对 1 通话的模型即为下图：

如果 P2P 成功，则数据流通则是实线箭头，ClientA 与 ClientB 直接进行数据传输。

如果 P2P 失败，则是虚线通道，需要中转服务器(Turn Server)进行数据转发。

现在中转服务器并不仅仅具有中转功能，在 P2P 建立过程中也起到提供提供 client 公网 ip 及端口的功能。

详情可百度 ICE server 功能。

多对多通话

在上述模型下，进一步就会考虑如果在不是 1 对 1 的情况下又会是怎么样一个模型。

基于 1 对 1 模型，我们尝试再增加 1 方参与，很自然就可以得到下面的模型。

mesh 网络模型

多人通话跟单人通话唯一的不同就是每个客户端都需要跟其他两个端都分别建立 P2P 连接，我们把这种完全使用 P2P 方式的网络拓扑结称之为 Mesh 结构。

一般情况下多方通话的应用场景并不会采用这种场景，但这种模型可以用来做点对点音视频通信。也能承载少量用户使用。它与 1V1 场景而言只是增加一个 client。

优点：

整体来说逻辑简单，容易实现，而且如果 P2P 成功的情况下可以降低 turn 服务器的压力，这样也就节约了带宽等成本。

缺点：

如果再继续增加 client 数量，就可以看出这种网络结构的巨大缺陷。每增一个客户端就会增加单个客户端的一路上载和下载。而在现实网络情况中上行带宽是非常宝贵的。而且商用过程可能会存在对视频进行额外的处理如：录制存储回放、实时转码、智能分析、多路合流、转推直播等等。在这种模型下 这些功能都无法实现。而且 P2P 在网路情况不理想的情况下可能导致服务不稳定。

应用场景：

这种模型仅适用于接入方少且功能较为简单，服务端不需要对音视频进行处理的场景。感觉挺适合 iPcamera。

单个 client mesh 模型下网络压力：

上行网络下行网路（n-1）*码流（n-1）*码流

n：为客户端数。

SFU 网络模型

因为上诉 mesh 网络模型的缺点，在商用场景下，需要尽可能保证服务稳定及额外功能，自然而然就会对 turn 服务器所处的角色进行考虑，进而引入新的网络模型。

SFU 的全称是：Selective Forwarding Unit，是一种通过服务器来路由和转发 WebRTC 客户端音视频数据流的方法。这种模型完全摈弃了 P2P 模型，全是转发模式。

SFU 服务器最核心的特点是把自己 “伪装” 成了一个 WebRTC 的 Peer 客户端，WebRTC 的其他客户端其实并不知道自己通过 P2P 连接过去的是一台真实的客户端还是一台服务器，我们通常把这种连接称之为 P2S，即：Peer to Server。除了 “伪装” 成一个 WebRTC 的 Peer 客户端外，SFU 服务器还有一个最重要的能力就是具备 one-to-many 的能力，即可以将一个 Client 端的数据转发到其他多个 Client 端。

优点：

这种网络结构下，每个 Client 端上行带宽就仅一路了。再引入较多的 client 的情况下也不会对每个 client 的上行带宽造成压力，极大减少了多人视频通话场景下 Mesh 模型给客户端带来的上行带宽压力。因为每个 client 均会通过 SFU server，甚至可以做到接管 WebRTC 客户端的数据转发的申请和控制，可以控制任意一路数据上下行。

缺点：

摈弃了 P2P 模式，引入 SFU server，则 webrtc 客户端所有流量均会通过 SFU 进行转发，就带来大量的带宽成本及部分服务器压力。

应用场景：

用于参与方较多的多方会话的情况，但多方会话内容不会需要过多处理的情况。

单个 client SFU 模型下网络压力：

上行网络下行网路 1 路码流（n-1）*码流

n：为客户端数。

MCU 网络模型

如果需要对多方会话支持更大规模的，则可在 SFU 的简单路由转发进一步升级，得到 MCU 模型。

MCU(Multipoint Conferencing Unit)，它的特点是，由 MCU Server 将各路客户端上行的视频流合成为一路，再转发给其他客户端。这种模型相比于 SFU 降低了多人视频通话场景下客户端的下行带宽压力。

优点：

在 SFU 模型上，我们虽然上行带宽只剩下了一路，但实质上下行带宽仍是 n 路，这在 Client 数量增加的情况下带来压力。而 MCU 在服务端混流后则每个客户端的下行带宽也只剩下一路，降低了服务器及 Client 带宽压力。

缺点：

MCU 模型的缺点也非常明显，音视频合流是非常消耗服务器资源的操作，对服务器造成较大的压力。而且服务器混流后，画面格式就被固定了下了，对界面处理就不够灵活了。

单个 client MCU 模型下网络压力：

上行网络下行网路 1 路码流 1 路码流

n：为客户端数。

常用 webrtc 开源服务器

在 SFU 和 MCU 模型是，我们可以对 webrtc 的码流进行处理。比如录制存储回放、实时转码、智能分析、多路合流、转推直播等等。一些开源服务器实现了下列功能，如下图(均为 MCU SFU 架构)：

如果需要第一种 mesh 结构的 webrtc 则可以参考 Google 的 apprtc 方案和 simplewebrtc 方案。

表格中所列出的开源系统是目前市面上比较常见的，分别从服务器类型、编解码能力、文档的完整性和开发商来进行对比。大家都知道 WebRTC 的服务器模型有两种，分别是 SFU 和 MCU，SFU 实现的是简单转发的路由功能，而 MCU 可以提供更多扩展性的功能实现，而且 MCU 型的服务器往往包含 SFU，所以 MCU 的实现难度较大。其次，文档的完整性也是非常重要的，因为对于开发者来说，文档具有非常重要的指导作用。最后是开发商，这个主要涉及到项目的可持续性、升级支持以及版权问题，对于商业机构来说版权的问题需要谨慎考虑。

● 首先介绍的开源系统是 Kurento，这个开源系统是在表格所列出中最全能的一个开源系统。这个开源系统支持转码，同时还有滤镜的附加功能。但是在测试过程中，这个开源系统的稳定性不是很好。这个开源系统同时提供了一个云服务方案，主要是开发商为了推广云服务而开源的系统，所以性能的稳定性还有待提高。

● Janus 的出发点是网关，它的开发商是 Meetecho 公司，Slack 推出的视频通话方案就是基于这个开源系统的。但在测试过程中发现，这个开源系统在性能上有些问题， 而 Slack 也是对其进行了大量的优化。

● Jitsi 只是实现了 SFU 模型，不包含 MCU，由于功能单一，只是一个转化路由，所以这个系统是列表中是较为稳定的一个开源系统。如果只是需要实现简单的转发功能，这个开源系统是不错的选择。

● Licode 具有 SFU 和 MCU 功能，它的架构是插件式的，也就是说，如果你想在自己的源代码上附加某些功能，可以直接使用 Licode 对自己的系统进行补充，既能保留原有系统的特性，又能达到完善功能的目的。

● Intel 使用 Licode 实现了一个 Intel CS for WebRTC 的套件，它是免费的，有提供 Client 端和 Server 端的 SDK，但是这个系统不开源。我们在一些沙龙活动中会经常看到有关这个系统的介绍，基于这个系统配合使用 Intel 方案也是不错的选择。这个系统也是列表中唯一支持 RTMP 转协议的系统。

● 最后一个开源系统是 MediaSoup，这个系统只支持 SFU，底层的开发语言是 Node.js。对于熟悉 Node.js 语言的开发人员来说，这个开源系统比较容易学习。但是由于这个开源系统出现的时间不长，系统稳定性还有待提高。

技术交流群:【960994558】整理了一些个人觉得比较好的学习书籍、大厂面试题、和热门技术教学视频资料共享在里面，有需要的可以自行添加哦！~

以上有不足的地方欢迎指出讨论，觉得不错的朋友希望能得到您的转发支持，同时可以持续关注我，每天分享 Linux C/C++后台开发干货内容！(*＾-＾*)(*＾-＾*)(*＾-＾*)