PDFWebRTC - 用于开放 Web 平台的实时通信
曾经只是一种将音频和视频带到网络的方式，现在已经扩展到我们无法想象的更多用例。
Niklas Blum、Serge Lachapelle 和 Harald Alvestrand，谷歌
在这个疫情时期，世界比以往任何时候都更依赖于基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量呈爆炸式增长，这在很大程度上归功于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税平台。
事实上，在过去一年中，通过选择加入 Google Chrome 统计信息的匿名用户群体，通过 WebRTC 堆栈接收的视频分钟数增加了 100 倍。在大多数互联网会议服务、社交网络、直播体验，甚至基于云的游戏产品中，都可以找到 WebRTC 的身影。
WebRTC 为浏览器和原生应用程序提供 RTC 功能。该平台的开源实现和教程可以在 https://webrtc.org 上找到。它包括音频和视频编解码器，以及信号处理功能，如带宽估计、噪声抑制和回声消除。
这个广泛部署的通信平台为所有主要浏览器（包括桌面和移动设备）上的音频/视频通话、会议和协作系统提供支持。这使得数十亿用户能够进行互动。WebRTC 大大扩展并促进了初创公司和大型企业创建和部署实时交互式服务的能力，并且可以在商业产品和开源项目中找到它的身影。
WebRTC 的起源
WebRTC 的想法起源于 2009 年末，即谷歌 Chrome 浏览器发布一年多之后。Chrome 团队寻找桌面和 Web 之间的功能差距。虽然大多数差异已经通过正在进行的项目得到解决，但实时通信仍然没有解决方案。当时，只有 Adobe 的 Flash 和 Netscape 的 NPAPI（Netscape 插件 API）提供了 RTC。Flash 的产品质量有些低，并且需要服务器许可证。对于用户来说，安装插件非常棘手，而且很少有开发人员有资源来处理部署和更新可以在跨多个操作系统的三种不同浏览器上运行的插件。
大约在这个时候，谷歌发现了一家公司 Global IP Solutions（又名 GIPS），该公司拥有 RTC 所需的底层组件。GIPS 组件已获得多家大型客户的许可，并出现在谷歌、Skype、AOL、Yahoo!、思科和其他公司的产品中。通过将这些音频和视频组件与 JavaScript 接口相结合，谷歌相信它可以解决其 Web 产品中的巨大“漏洞”，并刺激 RTC 市场的创新。如果只需要几行 JavaScript 代码就可以将 RTC 添加到 Web 应用程序中——并且无需许可、组件集成或对 RTC 的深入了解——谁知道会发生什么呢？
GIPS 总部位于瑞典和美国，在斯德哥尔摩和旧金山都设有工程师。对谷歌来说幸运的是，其音频和视频环聊产品已经在斯德哥尔摩进行开发，而 GIPS 工程师的加入进一步加强了斯德哥尔摩办公室作为谷歌内部 RTC 专家的实力。
当收购于 2011 年 1 月完成时，新成立的 Chrome WebRTC 团队专注于将代码集成到 Chrome 中，并在 webrtc.org 上开源所有关键组件。从一开始，计划就是构建一个对 Web 开放的东西，使每个人都可以使用 RTC。
架构和功能
WebRTC 对等端可以是用户端点（Web 浏览器、原生应用程序等）或充当两个或多个端点之间中介的服务器。虽然许多 WebRTC 服务依赖于客户端-服务器架构，但许多其他服务以对等 (P2P，又名无连接) 架构部署。
WebRTC 既是一个 API，也是一个协议。WebRTC 协议是一组规则，用于两个 WebRTC 代理协商双向安全实时通信。然后，WebRTC API23 允许开发人员使用 WebRTC 协议。
WebRTC API 仅针对 JavaScript 进行了规范。在两个 WebRTC 对等端之间建立连接的协议是其他技术的集合，可以分为信令、连接管理、安全和媒体传输。这四个步骤通常按顺序发生。只有前一步成功，后续步骤才能开始。每个步骤实际上都由许多其他协议组成。
作为 WebRTC 标准的一部分，自 2000 年代初期以来就存在的许多现有技术被组合和调整，以用于浏览器和移动应用程序。17
图 1 提供了 WebRTC 中主要组件和技术的高级概述。
Android 和 iOS API 是特定于实现的，而不是标准的一部分，但它们遵循与 JavaScript API 相同的原则（webrtc.org 开源实现18）。音频和视频捕获/渲染以及网络集成特定于不同的操作系统。
PeerConnection API
RTCPeerConnection API21 是 WebRTC 规范的核心部分，用于处理连接不同端点上的两个应用程序，以使用对等协议进行通信。对等端之间的通信可以是视频、音频或任意二进制数据（有关支持 DataChannel API 的客户端，请参见本文稍后部分）。
为了发现两个对等端如何连接，两个客户端都需要提供 STUN（NAT 会话遍历实用程序）9 或 TURN（NAT 周围中继遍历）服务器3 配置。11 它们的作用是为每个客户端提供 ICE（交互式连接建立）候选者，然后将其传输到远程对等端。ICE 候选者的传输以及其他配置信息（例如媒体功能）的交换通常称为信令。
音频/视频处理
WebRTC 允许您发送和接收包含音频和/或视频内容的流。流可以在通话期间随时添加和删除；它们可以是独立的，也可以捆绑在一起。RTC 的一个常见协作用例是捕获计算机的桌面内容作为视频源，然后包括来自计算机的网络摄像头和麦克风的音频/视频。通常，WebRTC 协议与编解码器无关。底层传输旨在支持任何编解码器格式；但是，WebRTC 用户代理在媒体编解码器方面的能力已经过标准化，并且定义明确。
用于处理音频和视频的媒体功能为任何 WebRTC 实现提供了核心。对于音频通信和录音，Opus、G.711μ-law/A-law 算法和 DTMF（双音多频）已被定义为强制性编解码器。16 IETF 标准化委员会已达成一致，WebRTC 端点需要支持 VP8 视频编解码器和 H.264 Constrained Baseline 以进行视频处理。13
WebRTC 实现中的缓冲区管理数据包到达时间的可变性，也称为抖动，这是通过对等端之间的连接实现的。缓冲的逻辑、重传请求的管理以及隐藏已丢失或超时的数据包是 WebRTC 信号处理工作的核心。这些算法不断发展，并在过去 10 年中取得了重大改进。这项工作极大地促进了在通过互联网进行通信时获得最佳媒体质量，尤其是在对等端连接到具有不同吞吐量级别和质量的网络时。
安全和媒体传输
WebRTC 连接必须加密。这既是设计的核心部分，也是标准化的一部分。已为此采用了两个现有协议，DTLS12（数据报传输层安全性）和 SRTP2（安全实时传输协议）。
DTLS 允许您协商会话，然后在两个对等端之间安全地交换数据。SRTP 专为交换媒体而设计；它没有握手机制，并且使用通过 DTLS 交换的外部密钥进行引导
1. DTLS 通过 ICE 提供的连接执行握手。在 DTLS 握手期间，双方都提供证书。
2. SRTP 会话是从 DTLS 生成的密钥创建的。
3. 完成这些步骤后，可以在 WebRTC 对等端之间交换 SRTP 加密的媒体。
WebRTC 对等端之间的媒体流默认基于 UDP（用户数据报协议），这意味着该协议必须处理不可靠的交付。为了实现尽可能高的质量，堆栈需要在延迟和质量之间做出权衡。一般来说，您愿意容忍的延迟越多，您可以期望的视频质量就越高。对于实时语音通信，ITU-T（国际电信联盟-电信标准化部门）定义了 E 模型7，该模型指出，当口到耳的延迟大于 250 毫秒时，用户开始感到不满意。
拥塞控制是 WebRTC 根据延迟约束确定可实现的质量的机制。实际上，拥塞控制由带宽估计器使用，该估计器调整比特率和视频分辨率或音频帧大小的媒体编码参数。这降低了质量，但确保了在用户可用带宽较低或变化时媒体保持流动。
在 WebRTC 的早期，即使在良好的条件下，也平均需要 40 秒或更长时间才能建立连接并达到 720 像素（高清）分辨率的视频质量。通过设定积极的目标，由于与巴里理工大学的研究人员合作，时间被缩短到 100 毫秒。这种合作促成了一种新的拥塞控制器设计4；图 2 显示了启动拥塞控制算法的结果。
数据通道
除了发送实时音频和视频数据外，WebRTC 还允许通过所谓的数据通道发送和接收任意数据。数据通道的用例范围从文件传输、游戏和 IoT（物联网）服务到 P2P CDN（内容分发网络）。对等数据 API20 允许创建数据通道。它扩展了 RTCPeerConnection API。SCTP（流控制传输协议）15 用作传输数据通道的底层协议。它包括通道多路复用、具有类似 TCP 的重传机制的可靠交付、拥塞避免和流量控制。
标准化
在马斯特里赫特举行的 IETF 78（2010 年夏季）会议上，谷歌新生的 WebRTC 团队与来自微软、苹果、Mozilla、Skype、爱立信和其他公司的工程师共进非正式午餐，以评估构建这样一个用于 Web 的 RTC 平台的兴趣。随后迅速组织了一个为期一天的工作坊14，目的是了解应该如何编写和定义这样的标准。这导致了 W3C（万维网联盟）和 IETF 的密集活动，最终于 2011 年 5 月成立了两个工作组：IETF 的 RTCWeb5 和 W3C 的 WebRTC27，这两个工作组都有来自整个行业的参与。
2020 年的 WebRTC
WebRTC 的采用已经取得了长足的进步。大多数使用语音或视频的现代服务要么基于 WebRTC 协议，要么除了服务最初部署的本机协议外，还能够使用它们。例如，思科的 Webex 服务有一个 WebRTC 客户端，允许人们直接从浏览器参与会议，而无需下载其他软件。较新的服务（如 whereby.com 和 Jitsi）从一开始就基于 WebRTC。即使不涉及 Web 浏览器，主要服务也使用 WebRTC 进行视频传输。例如，WebRTC 使 Amazon Ring 产品能够查看安全摄像头和门铃录像。越来越多的流式传输语音和/或视频的新型 IoT 产品正在将其网络堆栈基于 WebRTC 协议。3
2020 年是与以往任何一年都不同的一年。新冠疫情凸显了对 RTC 的需求，全球各地的人们都在寻找新的方式通过视频聊天进行工作、教育和与亲人联系。WebRTC 突然成为最重要的技术集合之一，使 Web 浏览器能够进行语音、视频和实时数据呼叫。它促成了一个可互操作的通信应用程序生态系统的蓬勃发展：自 2020 年 3 月初以来，Chrome 通过 WebRTC 接收的视频流增加了 100 倍，不包括隐身模式和默认选择不共享统计信息的用户（见图 3）。
如果没有所有支持开源社区的支持者，这些成功是不可能实现的。这项成功的一个重要因素是所有代码贡献者、测试人员、错误提交者和企业合作伙伴，他们帮助使这个生态系统成为现实。
展望
谷歌是 AOMedia（开放媒体联盟）的创始成员，并且一直积极参与为 RTC 用例定义 AV1 视频码流。随着 AV1 成为标准，该视频编解码器正在集成到 WebRTC 中。Chrome 89 版本正在发布 AV1 软件编码器，为 RTC 提供 AV1 到 Web 应用程序。与 VP9 相比，AV1 在相同质量下可节省 30% 到 50% 的比特率，并且有望为视频通话服务提供更高水平的带宽效率和质量。由于编解码器的复杂性，硬件支持对于使其普遍可用非常重要。AV1 对于促进 RTC 服务进一步扩展以及在未来实现更高质量的视频体验至关重要。
WebRTC 超越了语音和视频通信。新兴的游戏、低延迟视频流、AR/VR（增强现实/虚拟现实）和混合现实服务同样受益于并需要低延迟媒体。例如，WebRTC 使 Stadia 游戏服务能够为 Web 浏览器和电视带来基于云的、低延迟、高质量的体验。
这些用例推动了延迟障碍，导致需要进一步的传输协议优化。涵盖此需求的相应标准化工作是 WebTransport6,26，重点是通过 QUIC 协议优化超低延迟客户端-服务器媒体流。
随着 WebRTC 新用例的出现，WebRTC 标准化正在演变为所谓的 WebRTC NV（下一版本）。25 NV 不会是一个全新的 API，但将允许访问 PeerConnections 内部的较低级别媒体管道。媒体将使用 Streams19 和 WebCodecs API22 进行访问。朝着这个方向迈出的第一步是已经实现的 Insertable Streams API24，它为浏览器中的完整 E2EE（端到端加密）多方会议提供了基础。8
WebRTC 通过原生（即非 Web）集成到移动社交媒体、消息传递和视频通话应用程序中，开始了其在移动设备中的普及。随着新兴的 5G 网络，视频通话将变得更加普及。
WebRTC 的开放架构还允许使用机器学习和人工智能进行有趣的创新，以提高通话质量并隐藏噪声10 或网络中断1 的影响。
最初只是一种将音频和视频带到网络的方式，现在已经扩展到超出想象的更多用例——从简单的视频通话到 AR/VR 体验、基于云的游戏和大规模可扩展的直播服务；以及从简单的点对点视频聊天到通过高级机器学习模型增强质量的多用户对话。最重要的是，WebRTC 正在从实现有用的体验发展到在疫情期间成为让数十亿人继续工作和教育，并保持重要的人际交往的关键。WebRTC 未来的机遇和影响确实令人着迷。
参考文献
1. Barrera, P., Stimberg, F. 2020. 使用 WaveNetEQ 提高 Duo 中的音频质量。Google AI 博客（4 月 1 日）； https://ai.googleblog.com/2020/04/improving-audio-quality-in-duo-with.html。
2. Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman, K. 2004. 安全实时传输协议 (SRTP), IETF RFC 3711; https://tools.ietf.org/html/rfc3711。
3. Gross, G. 2020. WebRTC 技术被证明在疫情期间至关重要。IETF 对 Adam Roach 的采访（12 月 8 日）； https://www.ietf.org/blog/webrtc-pandemic/。
4. Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., Mascolo, S.; H. Alvestrand, ed. 2015. 用于实时通信的 Google 拥塞控制算法； https://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-03。
5. IETF。Web 浏览器中的实时通信 (RTCWeb) 工作组； https://datatracker.ietf.org/wg/rtcweb/documents/。
6. IETF。2021. WebTransport (webtrans)； https://datatracker.ietf.org/wg/webtrans/about/。
7. 国际电信联盟-T。2015. G.107: E 模型：用于传输规划的计算模型； https://www.itu.int/rec/T-REC-G.107-201506-I/en。
8. Ivov, E. 2020. 这才是端到端加密应该有的样子！(4 月 12 日。Jitsi 博客； https://jitsi.org/blog/e2ee/。
9. Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., Matthews, P. 2020. NAT 会话遍历实用程序 (STUN)。IETF RFC 8489; https://tools.ietf.org/html/rfc8489。
10. Protalinski, E. 2020. Google Meet 降噪功能现已推出——以下是其工作原理。VentureBeat（6 月 8 日）； https://venturebeat.com/2020/06/08/google-meet-noise-cancellation-ai-cloud-denoiser-g-suite/。
11. Reddy, T., Johnston, A., Matthews, P., Rosenberg, J. 2020. NAT 周围中继遍历 (TURN)：NAT 会话遍历实用程序 (STUN) 的中继扩展，IETF RFC 8656; https://tools.ietf.org/html/rfc8656。
12. Rescorla, E., N. Modadugu, N. 2012. 数据报传输层安全性，版本 1.2。IETF RFC 6347; https://tools.ietf.org/html/rfc6347。
13. Roach, A. B. 2016. WebRTC 视频处理和编解码器要求。IETF RFC 7742; https://tools.ietf.org/html/rfc7742。
14. RTC-Web 工作坊。2010； http://rtc-web.alvestrand.com/。
15. Stewart, R., Ed. 2007. 流控制传输协议。IETF RFC 4960; https://tools.ietf.org/html/rfc4960。
16. Valin, J. M., Bran, C. 2016. WebRTC 音频编解码器和处理要求。IETF RFC 7874; https://tools.ietf.org/html/rfc7874。
17. WebRTC for the Curious. 2020. 什么是 WebRTC？（9 月 19 日）； https://webrtcforthecurious.com/docs/01-what-why-and-how/。
18. WebRTC.org 实现。Google Git； https://webrtc.googlesource.com/src/。
19. W3C。2016. Streams API（11 月 29 日）； https://www.w3.org/TR/streams-api/。
20. W3C。2020. 对等数据 API（12 月 15 日）； https://www.w3.org/TR/webrtc/#peer-to-peer-data-api。
21. W3C。2020. RTCPeerConnection 接口（12 月 15 日）； https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface。
22. W3C。2020. WebCodecs（12 月 8 日）； https://wicg.github.io/web-codecs/。
23. W3C。2020. WebRTC 1.0：浏览器之间的实时通信。W3C 拟议建议（12 月 15 日）； https://www.w3.org/TR/webrtc/。
24. W3C。2020. 使用 Streams 的 WebRTC 可插入媒体（9 月 1 日）； https://w3c.github.io/webrtc-insertable-streams/。
25. W3C。2020. WebRTC 下一版本用例（11 月 30 日）； https://www.w3.org/TR/webrtc-nv-use-cases/。
26. W3C。2020. WebTransport（12 月 9 日）； https://w3c.github.io/webtransport/。
27. W3C。2021. Web 实时通信工作组； https://www.w3.org/groups/wg/webrtc。
Niklas Blum 是谷歌的集团产品经理。他领导谷歌视频通信产品（包括 Google Meet、Google Duo 和 Chrome/WebRTC）的音频/视频通话体验的战略和执行。他在通信领域工作了 15 年以上。他拥有德国波茨坦大学服务和软件工程博士学位，以及德国 ESMT 工商管理硕士学位。
Serge Lachapelle 是谷歌的产品管理总监。他在视频通信行业工作了 20 多年，最初是 Marratech AB 的联合创始人，该公司于 2007 年被谷歌收购。在谷歌，Lachapelle 发起了许多视频通话计划，包括 Gmail 视频聊天、Google Hangouts、WebRTC、Google Duo 和 Google Meet。他拥有加拿大蒙特利尔理工学院计算机科学学士学位。
Harald Alvestrand 是谷歌 WebRTC 项目的标准协调员。他自 1984 年以来一直在使用互联网，并几乎立即成为跨公司边界开放通信的倡导者。他曾担任 ICANN 董事会成员、IETF 主席和 IETF 应用程序领域主管。他拥有挪威科技大学 (NTNU) 电子学硕士学位。
版权所有 © 2021，所有者/作者所有。出版权已授权给 。
最初发表于 Queue vol. 19, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，用户采用率也更高。
Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖项
如果您曾经将钥匙锁在房屋或汽车内，您就会熟悉依赖循环。没有钥匙就无法打开锁，但没有打开锁就无法拿到钥匙。有些循环很明显，但更复杂的依赖循环可能难以在导致中断之前发现。跟踪和控制依赖项的策略对于维护可靠的系统是必要的。
Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模的服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的操作员如何在租户系统所有者进行故障排除期间配置补救策略，同时帮助保持租户系统尽可能稳定。
Štěpán Davidovič, Betsy Beyer - 金丝雀分析服务
期望从事产品开发或可靠性工作的工程师具备统计知识是不合理的；消除这个障碍导致了 CAS 的广泛采用。事实证明，即使对于不需要配置的基本案例，CAS 也很有用，并且显着提高了 Google 的发布可靠性。影响分析表明，CAS 可能阻止了数百起值得进行事后分析的中断，并且不使用 CAS 的组的事后分析率明显更高。
© 保留所有权利。