WebRTC 架构格局正在发生变化

本文探讨了WebRTC的应用架构变化,重点介绍了新兴的WebRTC Unbundling技术,作为符合标准WebRTC的另一种形式。文章分析了自建系统、开源媒体服务器和CPaaS三种传统架构的优缺点,并详细阐述了提高WebRTC应用规模的方法,如MCU和SFU。最后,文章比较了不同架构选择,并指出Unbundling虽然技术难度较大,但能提供更高的定制化功能。
摘要由CSDN通过智能技术生成

现在有一种新型的 WebRTC 应用程序架构正在发展,称为 WebRTC Unbundling,尽管它可能不适用于所有应用程序场景,但至少在开发新的实时视频开发项目时应该考虑一下它。在过去,三种不同类型的 WebRTC 应用架构即符合标准的 WebRTC、开源媒体服务器和称为 CPaaS 的商业媒体服务器是基于 WebRTC 开发的选项,这三个仍然是有效的架构选择,WebRTC Unbundling 只是第四个选择,可以认为它是符合标准的 WebRTC选项的另一种形式。

介绍

对于使用 WebRTC 的实时视频应用来说,没有适用于任何场景的通用应用架构,实际中基于用例以及在后端服务的商业,可以选择的架构有许多,并且差异较大。

当第一次了解 WebRTC 时,经常会看到一个如下的图表,在这里有两个对等点在浏览器中彼此连接,他们必须通过某种连接信令服务器必须在他们之间进行某种消息交换,以帮助建立它们之间的连接。但是一旦建立了该连接,所有繁重的流量例如视频、音频、数据通道这些都是在对等架构中在这两个浏览器之间直接交换的,你的信令服务器并没有真正承载大量流量。因为不处理传输数据本身,这种点对点 WebRTC 的想法有一些很大的优势,这是一种最简单的模型,也是我们在 WebRTC 中讨论最多的模型,即不会在服务器上增加太多的负载,视频音频流量和数据流量不会通过这些服务器,因此这也意味着可以更加安全地确保没有第三方获取到通信数据。所有数据在传输过程中都可以被加密,在现代浏览器中只需要使用 JavaScript 调用底层加密 API 即可实现。

WebRTC 建立连接示意图

但在实际部署中,问题并不简单,首先需要 STUN 和 TURN 服务器,以便帮助建立点对点连接;然后还需要信令服务器使得在没有成功建立连接之前进行一些必要信息的交换;此外在浏览器中需要处理不同的视频编解码器;又或者在群聊场景下,参与者不止有两个,将几个参与者的系统扩展到大型群里的复杂性是极高的;最后不同设备、软件之间存在不兼容性以及除了聊天之外的功能例如录制视频等会使得系统与最初的点对点连接系统之间产生天壤之别。在如此复杂的场景下,可以通过三种不同的方式来构建 WebRTC 应用程序,第一种是符合标准的前提下自己构建整个系统,第二种是借助开源代码的基础上实现,第三种是使用 CPaaS - CommunicationsPlatform as a Service,由服务提供商来提供技术支持。

选项一:符合标准的 WebRTC

这是构建 WebRTC 应用程序的原始方式,从一开始,WebRTC 就被描述为一种使用普通 JavaScript 访问摄像头和麦克风并建立对等视频、音频和数据通道的简单方法。它旨在将电信通信带给开发人员大众,这样他们就可以在浏览器中构建东西,而无需了解 VOIP 或电话,然而,它总是比宣传的要复杂一些,需要一定的技术支撑。

当然如果直接在 WebRTC 的标准构建自己的技术栈,则可以

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值