现在有一种新型的 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 的标准构建自己的技术栈,则可以