webrtc学习--了解webrtc服务器

逝水流年丶轻染尘

已于 2022-08-12 17:48:12 修改

阅读量841

点赞数

分类专栏： C ++ 文章标签：服务器 webrtc 学习

于 2022-08-12 17:39:19 首次发布

本文链接：https://blog.csdn.net/qq_18286031/article/details/126308671

版权

12 篇文章 0 订阅

订阅专栏

webrtc 服务器架构

在这里插入图片描述
（图片来自网络）

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

Mesh

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

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

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

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

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

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

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

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

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

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

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

关注

专栏目录