WebRTC 架构格局正在发生变化

2022年05月15日 阅读数:2
这篇文章主要向大家介绍WebRTC 架构格局正在发生变化,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

来源:WebRTC.Ventures
主讲人:Arin Sime(CEO of WebRTC.Ventures), Alberto Gonzalez(CTO of WebRTC.Ventures)
内容整理:彭峰
如今有一种新型的 WebRTC 应用程序架构正在发展,称为 WebRTC Unbundling,尽管它可能不适用于全部应用程序场景,但至少在开发新的实时视频开发项目时应该考虑一下它。在过去,三种不一样类型的 WebRTC 应用架构即符合标准的 WebRTC、开源媒体服务器和称为 CPaaS 的商业媒体服务器是基于 WebRTC 开发的选项,这三个仍然是有效的架构选择,WebRTC Unbundling 只是第四个选择,能够认为它是符合标准的 WebRTC选项的另外一种形式。web

目录后端

  • 介绍浏览器

  • 选项一:符合标准的 WebRTC安全

  • 选项二:开源媒体服务器服务器

  • 选项三:CPaaS微信

  • 提升 WebRTC 应用规模网络

    • MCU(Multipoint Control Unit)架构

    • SFU(Selective Forwarding Unit)app

    • MCU 和 SFU 的结合框架

  • 新一代架构选择——选项四: WebRTC Unbundling

  • 不一样选择的比较

  • 总结

介绍

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

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

WebRTC 创建链接示意图

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

首先,让咱们分别回顾一下以前的三种架构选择。首席技术官 Alberto Gonzalez 在 2021 年 TADSummit 上作的“如何架构你的 WebRTC 应用”会议演讲中也谈到了这一点。演讲视频:

选项一:符合标准的 WebRTC

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

固然若是直接在 WebRTC 的标准构建本身的技术栈,则能够拥有最强大灵活性,例如随意添加自定义功能和根据业务进行系统优化。伴随着这种强大的力量而来的是巨大的责任,业务开展者必须管理诸如 STUN/TURN 服务器、应用程序信令和浏览器/移动支持之类的事项,最重要的是,随着业务发展扩展应用程序也并不是易事。

自建系统的优缺点

对于当今的绝大多数应用程序,没有理由选择从零开始构建整个系统,最好在开源媒体服务器实现或 CPaaS 之上构建(见下文)。许多人开始以这种方式构建应用程序做为一种学习练习,而后将现有框架用于他们的生产应用程序。

特别的状况是,若是由于市场上没有任何东西适合你的精确要求,以往你只能构建本身的媒体服务系统或者修改和从新编译 libwebrtc 以得到独特的用例,但如今 WebRTC Unbundling 将更好地涵盖大多数这些用例。

选项二:开源媒体服务器

MediaSoup、Janus、Jitsi 和 Pion 库中的开源媒体服务器都是不错的选择,由于它们下降处理 WebRTC 的许多复杂性。它们一般具备内置的 STUN/TURN、信令和浏览器/移动支持的详细信息。基于选择性转发单元等媒体服务器设计,它们还极大地提升了标准 WebRTC 的扩展能力。

固然业务开展过程当中仍然须要处理服务器基础架构的全部方面的问题,以及对该基础架构的扩展。相比选项一来讲,技术负担有所减轻。

基于开源媒体服务器系统优缺点

选项三:CPaaS

对于许多客户而言,通讯平台即服务 (CPaaS) 是一种引人注目的架构选择,由于它是速度最快的解决方案。一般商业平台内置了应用程序视频部分所需的全部全局扩展,并与新的浏览器和移动版本保持同步。常见的 CPaaS 解决方案提供商包括 Agora、LiveSwitch、Twilio 和 Vonage。

CPaaS 的优缺点

惟一须要权衡是成本,解决方案提供商提供的服务的收费会提升你的运营成本,这些费用是基于使用量来计算的。尽管 CPaaS 仍然是入门的绝佳选择,可是,若是须要对业务进行更低级别的控制,CPaaS 并不能提供较低级别的控制;或者业务规模增加到必定程度后,服务费用的增加会成为巨大的问题。

提升 WebRTC 应用规模

正如前文提到的,构建本身的 WebRTC 库可能很复杂,以下图所示,尤为是当想要扩展到多个参与者时,除了复杂性,系统的性能也会大打折扣。

WebRTC 复杂性示意图

开源实现的媒体服务器或者 CPaaS 能够帮助简化这些可扩展性问题,但若是想要在 WebRTC 的标准下自建系统,能够有一些替代方案。

MCU(Multipoint Control Unit)

第一种是 MCU(Multipoint Control Unit)多点控制单元。以下图所示,多点控制单元中,中央服务器负责混合全部音频和视频,每一个参与者只须要下载一个音频和视频流,MCU 会为每一个用户控制视频流的组合。但其会带来额外的延迟,由于 MCU 须要大量的处理以及可靠的网络条件。

MCU 示意图

SFU(Selective Forwarding Unit)

第二种是 SFU(Selective Forwarding Unit)选择性转发单元,以下图所示,选择性转发单元对于每一个参与者仍然是惟一的流(容许在用户端更改布局),其拥有更多的选项,固然其实现也是更复杂的;它不须要进行大量的处理,但须要应对不一样的网络环境。

SFU 示意图

MCU 和 SFU 的结合

在一些特别的场景下,例如,在一个典型的视频会议应用程序,部分参与者能够以 SFU 的方式参与会议,但为了提供更多的功能,参与者能够经过 MCU,使用网络 SIP 语音呼叫经过移动设备加入会议。在相似的情形下,同时使用这两种选择是一个很是有效的。

MCU 和 SFU 结合使用

新一代架构选择——选项四: WebRTC Unbundling

以下图所示,在 WebRTC Unbundling 架构中,能够组合各类 JavaScript API 来替换 WebRTC 应用程序中的媒体管道的一部分。其中包括WebAssembly、WebTransport 和 WebCodecs。

WebRTC Unbundling 示意图

使用这种架构模型,能够将 WebRTC 应用程序中完成的标准编码/解码替换为 WebCodecs 库,从而容许根据独特的应用程序需求对视频进行个性化的优化,以及操做单个视频帧。

若是想使用比 WebRTC 更轻的传输协议,还可使用 WebTransport 更改媒体管道的发送/接收部分。若是在用例不须要 NAT Traversal,那么实现自定义的基于 WebTransport 的应用程序是很是有意义的,所以 WebRTC 的 STUN/TURN 开销是没必要要的。WebAssembly 能够更快地将全部这些部分链接在一块儿,并与围绕视频自己的机器学习组件或者其余东西集成。但目前这些 API 还不是在全部浏览器中均可用。

你能够在下面这个视频中专门观看 WebRTC 的这部份内容。Tsahi 讨论了构成下一版 WebRTC 的新技术,以及它们如何在媒体管道中单独使用:

不一样选择的比较

一般而言,应用开发者主要关心如下四个问题:

  • 前期费用:构建这个应用程序须要多少钱?通常而言,CPaaS 或开源媒体服务器下降了构建 WebRTC 视频应用程序的复杂性,所以构建应用程序所需的时间比在 WebRTC 标准下自建系统要少。因为软件开发人员的成本很高,所以 CPaaS或开源媒体服务器可下降构建应用程序前期成本并减小开发时间。
  • 持续成本:在生产环境中运行这个应用程序须要多少钱?这指系统上每一个单独的视频通话的交易成本。因为 CPaaS 按分钟收费或根据所需的带宽量收费,所以它比使用开源媒体服务器构建本身的基础架构或按标准编码更昂贵。当用户数量较少时,这可能没什么大不了的。可是,若是业务规模扩展到数百万用户和视频通话,那么 CPaaS 的成本可能会变得太高。
  • 技术难度:这与前期成本密切相关,专业的开发人员会须要较高的成本;随着业务的不断开展,维护应用程序也会逐渐成为一个问题,规模增加的技术难度巨大。
  • 包括的功能:选择不一样的架构,最后得到的功能上限是不一样的,CPaaS 拥有大部分能够直接使用功能,例如 CPaaS 可能已经提供了用于背景替换或为视频添加字幕的选项,而对于自建系统,则必须本身构建该功能,固然,自建系统能够实现更多个性化功能。
前三种选项的优缺点对比

对 Unbundled WebRTC 而言,构建应用程序的前期成本仍然高于其余选项,相似于直接针对 WebRTC 标准构建。若是想在媒体管道中操做单个视频帧,你须要对视频编码有很好的理解,额外的专业知识和时间/成本是为何这不是更多应用程序的最佳选择。

与开源媒体服务器相似,选择 Unbundled WebRTC 将在此场景中控制本身的服务器基础架构,无需向 CPaaS 支付任何交易费用,所以 Unbundled WebRTC 应用程序能够提供相对较低的大规模持续成本。

Unbundled WebRTC 的技术难度要低一些,由于与尝试修改 libwebrtc 自己的内部结构相比,WebCodecs API 让你更容易访问视频帧。固然开发人员仍然须要对媒体处理管道和视频编解码器等内容有深刻的了解。

Unbundled WebRTC 的最大区别在于它为你提供的强大功能。一方面,如前文提到,CPaaS 为你提供了包含的最高功能,由于其商业 API 中内置了更多功能。例如 CPaaS 能够提供录制功能。可是,若是不喜欢 CPaaS 实现记录的方式,会发生什么?开发者对此无能为力,而 Unbundled WebRTC 的优点在于用户能够根据须要修改媒体处理管道的各个方面,从而得到巨大的潜力来构建想要的功能,但这仍然是一项艰苦的工做。

Unbundled WebRTC 的特色

总结

在基于 WebRTC 的应用开发中,架构选择须要权衡多种因素,如须要的功能、拥有的预算、开发人员技术水平等,大多数状况下, CPaaS 或开源媒体服务器选项仍然是最好的选项,由于它们提供了较低的前期成本以及内置功能和可扩展性方面的优点。可是,若是开发者已经有了一个明确目标,清楚知道它的应用使用者的需求,而且肯定经过现有的媒体服务器(开源或 CPaaS)没法实现这些需求,那么选择自建系统或者使用 Unbundled WebRTC 是值得的,由于能够为用户提供更多的自定义功能,从而从激烈的市场竞争中获胜。




▲扫描图中 二维码或点击阅读原文
了解音视频技术大会更多信息


本文分享自微信公众号 - LiveVideoStack(livevideostack)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。