Webrtc 服务器网络模型
初次接触到Webrtc,都会了解到WebRTC实现了基于网页的语音对话或视频通话，目的是无插件实现web端的实时通信的能力。一般情况下会接触到下面的网络通话模型。
- mesh
- SFU
- MCU
文章目录
- 1 1对1通话
- 2 多对多通话
- 2.1 mesh网络模型
- 2.2 SFU网络模型
- 2.3 MCU网络模型
- 2.4 常用webrtc开源服务器
- 3 参考链接
1 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功能。
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带宽压力。
缺点：
SFU模型的缺点也非常明显，音视频合流是非常消耗服务器资源的操作，对服务器造成较大的压力。而且服务器混流后，画面格式就被固定了下了，对界面处理就不够灵活了。
单个client MCU模型下网络压力：
| 上行网络 | 下行网路 |
|---|---|
| 1路码流 | 1路码流 |
n：为客户端数。
2.4 常用webrtc开源服务器
在SFU和MCU模型是，我们可以对webrtc 的码流进行处理。比如录制存储回放、实时转码、智能分析、多路合流、转推直播等等。一些开源服务器实现了下列功能，如下图(均为MCU SFU架构)：
如果需要第一种mesh结构的webrtc 则可以参考Google 的apprtc方案和simplewebrtc方案。
3 参考链接
https://my.oschina.net/u/3747019/blog/1861856
https://kuaibao.qq.com/s/20190211G01J5P00?refer=cp_1026