webrtc学习--了解webrtc服务器
推荐一个零声学院免费教程,个人觉得老师讲得不错,分享给大家:[Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,
webrtc 服务器架构
0 前言
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)连接,
- 优点:
- 实现简单,不需要服务器中转数据,只需要webrtc通信模型就可以实现。
- 可以p2p,充分的利用了终端的带宽资源
- 节省了服务器带宽资源(服务器一般是专线,这种方案不需要服务器转发,可以很大的节省带宽)
- 缺点:
- 与多人通信时,参与者越多,对终端带宽要求越高,需要将音视频流发送给各个终端。
- 与多人通信时,对终端配置要求也比较高,需要解多路流。
- 对终端间的网络要求较高,需要能进行nat穿透
2.2 MCU
- 优点:
- 技术成熟,在硬件视频会议应用广泛。
- 方便集成,服务器偏于接入不同的音视频数据,通过解码再编码。
- 所有的终端画面一致,都是通过服务器编码再转发的。
- 缺点:
- 服务器需要解码再编码混流,运算量很大,对服务器算力要求很高。
- 服务器重新解码再编码混流然后转发,这过程会造成延时。
- 由于算力瓶颈,所以MCU对接入的终端容量有限,不太适合接入太多终端同时进行会议。
2.3 SFU
- 优点:
- 音视频数据直接转发,不需要编码、解码,对服务器性能要求一般。
- 直接转发,不进行解码,编码和混流,有效的降低了延迟,提高了实时性。
- 由于可以直接对流处理,这样灵活性更高,对流的操作性更好。
- 缺点:
- 参会人同时观看多路视频,可能会出现不同步。
- 同一路视频流,不同的参会人可能观看不一致。
- 带宽消耗最大(每个终端需要上传自己的音视频流,同时,在同一房间内,需要下载其他的所有终端的视频流)
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笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU
更多推荐
所有评论(0)