WebRTC服务器模型

1 1对1通话

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

1. P2P(点对点通信) 成功 ClientA 与ClientB 之间直接建立起数据通道
2. P2P 失败 需要中转服务器参与在ClientA 与ClientB 之间进行数据转发

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

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

如果P2P成功，则数据流通则是实线箭头，ClientA与ClientB直接进行数据传输。
如果P2P失败，则是虚线通道，需要中转服务器(Turn Server)进行数据转发。
现在中转服务器并不仅仅具有中转功能，在P2P建立过程中也起到提供提供client 公网ip及端口的功能。
详情可百度ICE server功能。

 

2 多对多通话

在上述模型下，进一步就会考虑如果在不是1对1的情况下又会是怎么样一个模型。
基于1对1模型，我们尝试再增加1方参与，很自然就可以得到下面的模型。

 

2.1 mesh网络模型

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

一般情况下多方通话的应用场景并不会采用这种场景，但这种模型可以用来做点对点音视频通信。也能承载少量用户使用。它与1V1场景而言只是增加一个client。
优点：
整体来说逻辑简单，容易实现，而且如果P2P成功的情况下可以降低turn服务器的压力，这样也就节约了带宽等成本。
缺点：
如果再继续增加client数量，就可以看出这种网络结构的巨大缺陷。每增一个客户端就会增加单个客户端的一路上载和下载。而在现实网络情况中上行带宽是非常宝贵的。而且商用过程可能会存在对视频进行额外的处理如：录制存储回放、实时转码、智能分析、多路合流、转推直播等等。在这种模型下 这些功能都无法实现。而且P2P在网路情况不理想的情况下可能导致服务不稳定。
应用场景：
这种模型仅适用于接入方少且功能较为简单，服务端不需要对音视频进行处理的场景。感觉挺适合iPcamera。

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

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

n：为客户端数。

 

2.2 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：为客户端数。

 

2.3 MCU网络模型

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

MCU(Multipoint Conferencing Unit)，它的特点是，由 MCU Server 将各路客户端上行的视频流合成为一路，再转发给其他客户端。这种模型相比于 SFU 降低了多人视频通话场景下客户端的下行带宽压力。
优点：
在SFU模型上，我们虽然上行带宽只剩下了一路，但实质上下行带宽仍是n路，这在Client数量增加的情况下带来压力。而MCU在服务端混流后则每个客户端的下行带宽也只剩下一路，降低了服务器及Client带宽压力。
缺点：
MCU模型的缺点也非常明显，音视频合流是非常消耗服务器资源的操作，对服务器造成较大的压力。而且服务器混流后，画面格式就被固定了下了，对界面处理就不够灵活了。

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

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

n：为客户端数。

 

3 常用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语言的开发人员来说，这个开源系统比较容易学习。但是由于这个开源系统出现的时间不长，系统稳定性还有待提高。