webrtc 服务器架构

0 前言

推荐一个零声学院免费教程，个人觉得老师讲得不错，
分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，
fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，
TCP/IP，协程，DPDK等技术内容，点击立即学习:

1 服务器架构

（图片来自网络）

由上图中，我们很清楚的知道在多方通信中，服务器架构有三种，mesh架构、mcu架构和sfu架构。

• Mesh

  多个终端两两进行连接，与其他所有的终端都能互联通信。

• MCU

  是由1个服务器和多个客户端组成的。各个终端将自己的音视频发送给服务器，服务器将同一个房间中的所有的终端进行混合编码，并将混合后的音视频流发送给各个终端。

• SFU

  和MCU一样，是由1个服务器和多个终端构成。不同的是，SFU服务器只对流进行转发，而不进行混合编码。

三种架构中，只有Mesh支持p2p， MCU和SFU只支持服务器转发。

2 Mesh 、MCU、SFU的优缺点

2.1 Mesh

有前面的图中，可以很清楚的知道，这种结构是各个终端之间两两互相连接的，同时都要与ICE服务器（STUN/TURN）连接，

• 优点：
  1. 实现简单，不需要服务器中转数据，只需要webrtc通信模型就可以实现。
  2. 可以p2p，充分的利用了终端的带宽资源
  3. 节省了服务器带宽资源（服务器一般是专线，这种方案不需要服务器转发，可以很大的节省带宽）
• 缺点：
  1. 与多人通信时，参与者越多，对终端带宽要求越高，需要将音视频流发送给各个终端。
  2. 与多人通信时，对终端配置要求也比较高，需要解多路流。
  3. 对终端间的网络要求较高，需要能进行nat穿透

2.2 MCU

• 优点：
  1. 技术成熟，在硬件视频会议应用广泛。
  2. 方便集成，服务器偏于接入不同的音视频数据，通过解码再编码。
  3. 所有的终端画面一致，都是通过服务器编码再转发的。
• 缺点：
  1. 服务器需要解码再编码混流，运算量很大，对服务器算力要求很高。
  2. 服务器重新解码再编码混流然后转发，这过程会造成延时。
  3. 由于算力瓶颈，所以MCU对接入的终端容量有限，不太适合接入太多终端同时进行会议。

2.3 SFU

• 优点：
  1. 音视频数据直接转发，不需要编码、解码，对服务器性能要求一般。
  2. 直接转发，不进行解码，编码和混流，有效的降低了延迟，提高了实时性。
  3. 由于可以直接对流处理，这样灵活性更高，对流的操作性更好。
• 缺点：
  1. 参会人同时观看多路视频，可能会出现不同步。
  2. 同一路视频流，不同的参会人可能观看不一致。
  3. 带宽消耗最大（每个终端需要上传自己的音视频流，同时，在同一房间内，需要下载其他的所有终端的视频流）

3 开源服务器

常见的开源 SFU 服务器有：Licode，Janus，Jitsi，mediasoup，Medooze 等等

下面的几个SFU服务器，记录下来，偏于学习

• mediasoup

https://github.com/versatica/mediasoup

https://github.com/yanhua133/mediasoup-sfu-cpp

• licode

https://github.com/lynckia/licode

https://github.com/harvestsure/licode-windows

4 学习和感受

webrtc服务器学习，相应的资料不是很多，有很多的资料都是不全的。需要自己搭建对应的环境，一步步的尝试。同时，这个过程中也能学习到不少的东西，这里面记录下学习和查找的相关资料，方便后续的学习。同时，也能提高自己。锻炼学习的能力。后期，准备深入的学习一下，更深入的了解webrtc。

5 参考博客

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

WebRTC：Mesh/MCU/SFU三种通信架构

Webrtc音视频会议之Mesh/MCU/SFU三种架构

WebRTC 开发实践：为什么你需要 SFU 服务器

WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信架构
webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU