ACM通信

实践

WebRTC:开放网络平台的实时通信

作者:Niklas Blum, Serge Lachapelle, Harald Alvestrand
ACM通信，2021年8月，第64卷第8期，50-54页
10.1145 / 3453182
评论

在疫情期间，世界前所未有地转向基于互联网的实时通信(RTC)。在过去的十年里，RTC产品的数量激增，很大程度上是因为更便宜的高速网络接入和更强大的设备，但也因为一个开放的、免版税的平台，叫做WebRTC。

事实上，在过去的一年里，在选择谷歌Chrome的统计数据的匿名人群中，通过WebRTC栈接收的视频分钟增加了100倍。在大多数互联网会议服务、社交网络、直播体验，甚至基于云的游戏产品中都可以找到WebRTC的身影。

WebRTC为浏览器和本地应用程序提供RTC功能。该平台的开源实现和教程可以在以下网站找到https://webrtc.org．它包括音频和视频编解码器，以及信号处理功能，如带宽估计，噪声抑制和回声消除。

这个广泛部署的通信平台支持所有主流浏览器(包括桌面和移动设备)上的音频/视频通话、会议和协作系统。这使得数十亿用户能够进行交互。WebRTC极大地扩展和促进了为初创公司和大型公司创建和部署实时交互式服务的能力，它可以在商业产品和开源项目中找到相似的地方。

WebRTC的想法起源于2009年底，也就是谷歌的Chrome浏览器推出一年多之后。Chrome团队寻找桌面和网络之间的功能差距。虽然正在进行的项目已经解决了大多数差异，但没有实时通信的解决方案。当时，只有Adobe的Flash和Netscape的NPAPI (Netscape Plugin API)提供RTC。Flash的产品质量有些低，需要服务器许可证。插件的安装对用户来说相当棘手，很少有开发人员有足够的资源来部署和更新在多个操作系统的三种不同浏览器上运行的插件。

大约在这个时候，谷歌确定了一家公司，全球IP解决方案(又名GIPS)，它拥有RTC所需的底层组件。GIPS组件得到了几个大客户的许可，并出现在谷歌、Skype、AOL、Yahoo!思科等公司。通过将这些音频和视频组件与JavaScript接口结合起来，谷歌相信它可以解决其Web服务中的大“洞”，并刺激RTC市场的创新。如果只需要几行JavaScript代码就可以将RTC添加到Web应用程序中，而且不需要许可、组件集成或对RTC的深入了解，那么谁知道会发生什么呢?

GIPS的总部设在瑞典和美国，在斯德哥尔摩和旧金山都有工程师。对谷歌来说幸运的是，它的音频和视频Hangouts产品已经在斯德哥尔摩开发，而GIPS工程师的加入进一步增强了斯德哥尔摩办公室作为谷歌RTC专家的实力。

当收购在2011年1月完成时，新成立的Chrome WebRTC团队专注于将代码集成到Chrome中，并开源所有关键组件webrtc.org．从一开始，我们的计划就是建立一个对网络开放的东西，使人人都能使用RTC。

回到顶部

体系结构和功能

WebRTC对等点可以是用户端点(Web浏览器、本机应用程序等)，也可以是充当两个或多个端点之间中介的服务器。虽然许多WebRTC服务依赖于客户机-服务器架构，但许多其他服务部署在点对点(P2P，又称无连接)架构中。

WebRTC既是一个API也是一个协议。WebRTC协议是两个WebRTC代理进行双向安全实时通信的一组规则。WebRTC API²³然后允许开发者使用WebRTC协议。

WebRTC API仅为JavaScript指定。在两个WebRTC对等体之间建立连接的协议是其他技术的集合，这些技术可以分为信令、连接管理、安全和媒体传输。这四个步骤通常是依次进行的。前面的步骤必须成功，才能开始后面的步骤。每个步骤实际上都由许多其他协议组成。

作为WebRTC标准的一部分，许多自21世纪初就存在的现有技术被结合和改编，以用于浏览器和移动应用程序。¹⁷

图1提供了WebRTC主要组件和技术的高级概述。

图1。WebRTC库配件。

Android和iOS api是特定于实现的，不是标准的一部分，但它们遵循与JavaScript api (webrtc.org开源实现¹⁸)．音频和视频捕获/渲染和网络集成针对不同的操作系统。

PeerConnection API。RTCPeer-Connection API²¹是WebRTC规范的核心部分，涉及连接不同端点上的两个应用程序，使用点对点协议进行通信。对等点之间的通信可以是视频、音频或任意二进制数据(稍后我们将讨论支持DataChannel API的客户机)。

为了发现两个对等体如何连接，两个客户机都需要提供STUN(用于NAT的会话遍历实用程序)⁹或者一个TURN(使用NAT周围的中继遍历)服务器^3.配置。¹¹它们的作用是向每个客户机提供ICE(交互连接建立)候选，然后将其传输到远程对等端。这种ICE候选项的传输和其他配置信息(如媒体功能)的交换通常被称为信号。

音频/视频处理。WebRTC允许您发送和接收包含音频和/或视频内容的流。流可以在调用期间的任何时间添加和删除;它们可以是独立的，也可以捆绑在一起。RTC的一个常见协作用例是捕获计算机的桌面内容作为视频源，然后包括来自计算机的网络摄像头和麦克风的音频/视频。一般来说，WebRTC协议与编解码器无关。底层传输被设计成支持任何编解码器格式;然而，关于媒体编解码器的WebRTC用户代理功能已经受到了标准化的制约，并得到了很好的定义。

用于处理音频和视频的媒体功能提供了任何WebRTC实现的核心。对于音频通信和录音，Opus、G.711μ-law/A-law算法和DTMF(双音多频)被定义为强制编解码器。¹⁶IETF标准化委员会已经同意，WebRTC端点需要支持VP8视频编解码器和H.264约束基线来处理视频。¹³

WebRTC实现中的缓冲区管理包到达时间的可变性，也称为抖动，通过对等体之间的连接。缓冲、重传请求管理和隐藏丢失或超时数据包的逻辑是WebRTC信号处理工作的核心。在过去的10年里，这些算法不断被开发和改进。这项工作极大地有助于在Internet上通信时获得尽可能好的媒体质量，特别是当对等点连接到具有不同吞吐量和质量的网络时。

安全和媒体运输。WebRTC连接必须加密。这既是设计的核心部分，也是标准化的一部分。两个现有的协议，DTLS¹²(数据报传输层安全)和SRTP²(安全实时传输协议)已经被采用。

DTLS允许您协商一个会话，然后在两个对等体之间安全地交换数据。SRTP用于交换介质;它没有握手机制，并通过DTLS与外部密钥交换引导:

1. DTLS通过ICE提供的连接进行握手。在DTLS握手过程中，双方都提供证书。
2. SRTP会话是由DTLS生成的密钥创建的。
3. 成功完成这些步骤后，srtp加密的媒体就可以在WebRTC对等体之间交换了。

默认情况下，WebRTC对等体之间的媒体流基于UDP(用户数据报协议)，这意味着该协议必须处理不可靠的传输。为了达到尽可能高的质量，堆栈需要在延迟和质量之间做出权衡。一般来说，你愿意忍受的延迟越长，你所期望的视频质量就越高。对于实时语音通信，ITU-T(国际电信联盟电信标准化部门)定义了e模式，⁷该公司表示，当从口到耳的延迟超过250毫秒时，用户就会开始不满意。

拥塞控制是WebRTC在给定的延迟约束下找出可达到的质量的机制。实际上，拥塞控制是由带宽估计器根据比特率和视频分辨率或音频帧大小调整媒体编码参数来使用的。这降低了质量，但保证了当用户有较低或不断变化的可用带宽时，媒体保持流动。

在WebRTC的早期，即使在良好的条件下，建立连接和达到720像素(HD)分辨率的视频质量平均也需要40秒或更长时间。在与巴里理工大学的研究人员的合作下，通过设定积极的目标，时间被缩短到100毫秒。这次合作产生了新的拥塞控制器设计;⁴图2显示启动拥塞控制算法的结果。

图2。提升时间到1Mbps视频比特率。

数据通道。除了发送实时音频和视频数据，WebRTC还允许通过所谓的数据通道发送和接收任意数据。数据通道的用例范围从文件传输、游戏、物联网服务到P2P cdn(内容传递网络)。点对点数据API^20.允许创建数据通道。它扩展了RTCPeerConnection API。流控制传输协议¹⁵用作传输数据通道的底层协议。它包括信道复用、具有tcp类重传机制的可靠传输、拥塞避免和流量控制。

回到顶部

标准化

在马斯特里赫特IETF 78(2010年夏季)上，谷歌的新兴WebRTC团队与来自微软、苹果、Mozilla、Skype、爱立信和其他公司的工程师举行了一次非正式午餐，以评估他们对为Web构建这样一个RTC平台的兴趣。一个迅速组织的为期一天的研讨会¹⁴会议的目的是理解这样一个标准应该如何编写和定义。这导致了W3C(万维网联盟)和IETF的激烈活动，导致在2011年5月成立了两个工作组:IETF的RTCWeb⁵以及W3C的WebRTC，²⁷两者都需要整个行业的参与。

回到顶部

2020年WebRTC

WebRTC的采用已经走过了漫长的道路。大多数使用语音或视频的现代服务要么基于WebRTC协议，要么能够在服务最初部署的本地协议之外使用这些协议。例如，思科的Webex服务有一个WebRTC客户端，可以让人们直接从浏览器参加会议，而不需要下载额外的软件。更新的服务，例如whereby.com和Jitsi，从一开始就以WebRTC为基础。即使在不使用Web浏览器的情况下，主要的服务也会使用WebRTC进行视频传输。例如，WebRTC使Amazon Ring产品能够查看安全摄像头和门铃视频。越来越多的语音和/或视频流媒体的新物联网产品将其网络栈基于WebRTC协议。^3.

2020年与以往任何一年都不同。新冠肺炎疫情凸显了RTC的必要性，因为全球各地的人们都找到了新的方式来工作、教育，并通过视频聊天与亲人联系。WebRTC突然成为一种最重要的技术，允许Web浏览器进行语音、视频和实时数据调用。它允许互操作通信应用的生态系统蓬勃发展:自2020年3月初以来，Chrome通过WebRTC接收的视流增加了100倍，不包括隐身和默认选择不共享统计数据的用户(见图3)．

图3。2020年在WebRTC上的Chrome视频分钟。

如果没有开源社区的所有支持者，这些成功是不可能的。这一成功的一个重要因素是所有帮助实现这一生态系统的代码贡献者、测试人员、bug归档人员和企业合作伙伴。

回到顶部

前景

谷歌是AO-Media(开放媒体联盟)的创始成员，一直积极为RTC用例定义AV1视频比特流。随着AV1成为标准，视频编解码器正在集成到WebRTC中。Chrome 89版本提供了一个AV1软件编码器，为RTC提供AV1到web应用程序。与VP9相比，AV1在同等质量下又节省了30%-50%的比特率，并有望为视频通话服务提供另一个级别的带宽效率和质量。由于编解码器的复杂性，硬件支持将是非常重要的，以使它无处不在。AV1对于推动RTC服务进一步扩大规模以及未来实现更高质量的视频体验至关重要。

WebRTC超越了语音和视频通信。新兴游戏、低延迟视频流媒体、AR/VR(增强现实/虚拟现实)和混合现实服务同样受益于并要求低延迟媒体。例如，WebRTC使Stadia游戏服务能够为Web浏览器和电视带来基于云计算、低延迟、高质量的体验。

这些用例提高了延迟障碍，导致需要进一步优化传输协议。为满足这一需求，相应的标准化工作是WebTransport，^6，26专注于通过QUIC协议优化超低延迟的客户端-服务器媒体流。

随着新的WebRTC用例的出现，WebRTC标准化正在演变为所谓的WebRTC NV(下一个版本)。²⁵NV将不是一个全新的API，但将允许访问PeerConnections内部的低级媒体管道。媒体将可以使用流访问¹⁹和WebCodecs api。²²这个方向的第一步是已经实现的Insertable Streams API²⁴这为浏览器中完全的E2EE(端到端加密)多方会议提供了基础。⁸

WebRTC进入移动设备是通过将移动社交媒体、消息传递和视频通话应用程序的原生(即非web)集成开始的。随着5G网络的兴起，视频通话将变得更加大众化。

WebRTC的开放架构还允许使用机器学习和人工智能进行有趣的创新，以提高通话质量并隐藏噪声的影响¹⁰或网络中断。¹

一开始只是把音频和视频带到网络上，现在已经扩展到超出想象的更多的用例——从简单的视频通话到AR/VR体验，基于云的游戏，以及大规模可扩展的直播流媒体服务;从简单的点对点视频聊天到通过先进的机器学习模型提高质量的多用户对话。最重要的是，网络brtc正在从提供有用的经验发展为使数十亿人得以继续工作和教育，并在大流行期间保持重要的人际接触。摆在WebRTC面前的机遇和影响确实很吸引人。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc.

---

没有发现记录