求索阁

对于诸多业界开发者而言，对实时通信其实也并不陌生，毕竟从腾讯 QQ 音视频，到风靡国内的狼人杀、大吉大利的吃鸡游戏、线上抓娃娃、直播答题、线上 KTV，再到如今的微信小程序音视频等，其背后都离不开实时音视频的解决方案，更离不开 WebRTC 技术的支持。

对此，我们不禁产生疑问，WebRTC 究竟有何技术优势可以征服各种应用程序？当前 WebRTC 的发展又处于一个什么样的阶段？它是否有可能在未来实现浏览器、移动端的全面覆盖？

WebRTC 的前世

无论是在 PC 互联网时代、移动互联网时代，还是当下以云计算、人工智能、IoT 为主导的万物互联时代，WebRTC 的到来都是实时互联网技术标准演进过程中至关重要的一个节点。

回忆 Web 的早期发展，设备和 Web 服务器之间的通信非常有限。在访问网站时，只有当用户在地址栏中输入新地址或点击超链接时，浏览器才能与存储网站的网络服务器进行通信。而这就是静态网页需要运行的全部内容。

但是彼时的一些开发者意识到 Web 应该能以更具吸引力的方式实践应用。正因此，为了使各大网站更具动态性和响应性，诸如 Ajax 类似的框架最终在 90 年代后期被相继开发，从而浏览器也能够实时地与 Web 服务器通信、允许创建适当的 Web 应用程序或即时响应用户操作。不过，彼时的实时通信技术在 Web 浏览器和服务器之间仍存在很大的局限性。

具体而言，过去，两个不同用户的 Web 浏览器之间的通信速度很慢，因为其二者之间的所有流量都必须通过中间的服务器，这产生了明显的延迟。但是，我们也发现直接收发消息之类的延迟并不算是真正的问题。这是因为发送消息的一个用户和接收消息的另一个用户之间几秒钟的差异并没有真正影响到整体的传输效果。但是，服务器延迟导致了一系列的连接延迟，不过如果没有这种延迟则无法实现用户之间互相呼叫等实时视频的服务。

如今 WebRTC 的出现，可以完全实现桌面和基于移动的多人多媒体聊天应用程序。

WebRTC 的今生

那具体而言，到底何为 WebRTC？

WebRTC（Web Real-Time Communication，网页即时通信），是一个支持网页浏览器进行实时语音对话或视频对话的技术。它的起源，要从 2010 年 Google 以 6820 万美元收购 VoIP 软件开发商 Global IP Solutions 的 GIPS 引擎谈起，在经过收购之后没多久，Google 将该引擎改名为“WebRTC”，并宣布向开发者们开源了源代码。

2012 年，Google 将 WebRTC 集成到 Chrome 浏览器中。随后，在它的带动下，Mozilla、Opera、Ericsson 等 PC 浏览器以及手机浏览器均开始支持 WebRTC 技术。

2017 年，苹果在 WWDC17 上正式宣布其浏览器内核 WebKit 也正式支持 WebRTC。

如今，继去年微软宣布 Edge 将采用 Chromium 开源项目之后，就 WebRTC 技术应用而言，Bernard Aboba 表示，“基于 Chromium 的新版 Edge 现在可在预览版中使用。新版本的 Edge 提供了 WebRTC 开发者常用的许多功能，如支持数据通道、RTCPeerConnection 中的 Strem、VP9 编解码器和 MediaStream Recording。”

事实上，除了以上的浏览器以及文章伊始提及国内主流的应用程序之外，在 Discord、Google Hangouts 和 Facebook Messenger 等一些国内的多媒体网络应用中，也都需要 WebRTC 才能实现。

WebRTC 一统浏览器、移动端的实时音视频天下？

按照这样的发展趋势，WebRTC 能否一举成功夺下各层面的实时音频霸主之位？

其实，在 WebRTC 的全名——Web Real Time Communication 中，我们从 Web 一词就可以看出，最初这项技术是为浏览器量身打造用以实时音视频能力而准备的。而 WebRTC 项目一开始的初衷也是让 Web 开发者能够基于如 Chrome、Edge、Firefox 等浏览器平台轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web 开发者也仅需关注多媒体的数字信号处理过程，只需编写简单的 JavaScript 程序即可实现。

不过，就浏览器应用而言，WebRTC 的发展还面临着诸多的挑战。对此，Bernard Aboba 表示：

浏览器面临的主要挑战是完成 WebRTC 1.0 API 的实现，以及消除实现差异。为了达到提议标准，WebRTC 工作组需要记录每个功能的两个实现，并通过 Web 平台测试（WPT）的结果展示互操作性。当下，W3C 在实现这一目标方面一直在稳步前进，但在 WebRTC 以及 WebRTC-Stats 等相关规范方面仍有许多工作要做。其次，就 WebRTC 自身的发展而言，WebRTC API 在其历史中经历了三次主要迭代，最后一次迭代是 addTransceiver API，这是 WebRTC 1.0 候选推荐中的首选 API。随着浏览器现在实施候选推荐标准并融合“Unified Plan”SDP，WebRTC 工作组正在为开发人员一直要求的互操作性方面而努力，并且 W3C 需要将规范推进到推荐的标准中。就需要改进的领域而言，W3C 仍然需要改进同步广播等高级功能的测试覆盖率，并将 WebRTC-Statistics 规范纳入候选推荐标准中。当前实时音视频通信领域，也并不只有 WebRTC 一种可供选择的技术。事实上，在 WebRTC 诞生之前，很多领域的公司都有自己自研的通信协议。而如何保证自研协议与 WebRTC 协议在 Windows、Mac 等平台上做到互通？Bernard Aboba 建议道，专有的自研协议和 WebRTC 的互操作性通常使用网关实现。使用 Janus 等工具，开发人员可以通过在已建立的框架内构建模块。但是，在各种情况下测试兼容性的任务仍然很困难。对此，Bernard Aboba 也表示，由 Cosmo Consulting 开发的测试框架（如 KITE）可能会有所帮助。然而，除此之外，WebRTC 在移动端的应用也一直被开发者所诟病。针对这一点，Bernard Aboba 坦言道，“对移动或嵌入式设备优化 WebRTC，是一项重大的挑战，尤其是在内存、应用程序大小，以及连接性和功耗等方面。”

不过当下，W3C 组织为了解决这些难题，该团队的开发者们经常需要创建自定义构建，其中包含了许多更改改进，举例说明，例如，Ortc Lib 创建了 OpenPeer Foundation 的 Robin Raymond，支持使用 ORTC API 在移动设备上进行开发，同时允许开发人员自定义库，以便仅包含所需的功能。 事实证明这种方法非常成功。