全球“移动端到端”通信的挑战与应对

本文将探讨标准的 WebRTC 方案在为真正的全球化、移动化的应用程序交付可靠、一致的体验质量 (QoE) 方面所面临的挑战，并讨论可化解这些挑战并针对全球化而优化的体系结构。本文最初发布在《WebRTC World》，参见这里。

实时通讯的发端

如今，应用程序和用户的主要特点是全球化和移动化，而且通常具有“移动到移动”的性质。实际上，“移动爆发点”发生在2014 年，就在这一年，移动智能手机用户达到近20 亿人，超过了全球的台式机用户数量。这些统计数据表明，80% 的互联网用户拥有智能手机，并且这些移动用户的在线时间更长，内容消费量也大幅增多。诸如Facebook 和Twitter 等社交媒体平台指出，如今移动交互次数显著多于台式机交互次数，而且大多数新的社交媒体应用程序（例如Instagram、WhatsApp、WeChat、Snapchat 等）主要都是移动应用程序。

在应用程序中加入实时通信功能，让参与者可根据需要在任何地方与对方交谈并能看到对方，这种全球化的和移动化的实时通信无疑是一个巨大的挑战。第一家真正切实简化互联网全球通信的公司是Skype，正因为如此，我们中的许多人仍在使用Skype 与远在其他国家/ 地区的亲属进行交谈。然而，Skype 已成为一个僵化的孤立平台，由于其API 较少，因此无法以灵活、隐形的方式轻易嵌入在其他应用程序中。此外，Skype 现已纳入Microsoft 麾下，已经成为Microsoft 为扩展MS Office 并取代MS Lync 而重点开发的Skype-For-Business 中的关键一环，似乎不会再回过头来加入可以轻易嵌入的通信功能。

那么，对于自行构建应用程序来直接纳入通信功能的应用程序开发人员而言，有什么替代方案呢？过去四年来，在Google 和Mozilla 以及最近Microsoft 和其他公司的推动下，在 IETF 和 W3C 开展的标准制定计划的支持下，WebRTC 登上了历史舞台，成为一种可将通信功能轻松集成到应用程序中的全新开放式标准

“标准的”对等 WebRTC 体系结构所面临的挑战

WebRTC 应用程序的基础体系结构模式是“三角形”模式，如下所示：

无论应用程序位于移动应用程序之中，还是位于浏览器的 JavaScript 代码中，都会与集中式的 Web 应用程序服务器进行通信，这些服务器为每个设备提供在各设备之间协调通信所需的信息。在每个设备上，API 用于根据需要获取对麦克风、扬声器和摄像头的访问，并计算设备之间的网络路径，此过程可能会因为防火墙、NAT 和其他机制而变复杂。建立通信后，语音、视频和数据通信媒体将以对等端到对等端的方式直接在设备之间流动。一切看似完美无缺。

然而，虽然互联网对等通信因为简便、免费且不需要其他基础架构而堪称是“理想的”方案，但是用户能否在整个通信过程中获得出色的体验质量，则完全取决于网络连接的质量以及此质量在整个通信会话期间的稳定性。

理想的 WebRTC 使用情形通常表述如下：

两个端点均为浏览器，二者分别基于具有适当性能且配备 WiFi 或有线网络连接的笔记本电脑，并通过具有适当一致性的网络在同一国家 / 地区内进行通信。

在这种情况下，不会有什么问题。但是，如果这些设备是具有 3G、4G 或 WiFi 连接且可能在这些连接之间切换的手机，带宽在用户移动过程中经常波动，而且这些设备处于完全不同的国家 / 地区，其中某些国家 / 地区的网络很不通畅，那么通信质量就可能非常糟糕！因此，许多具有跨国家 / 地区通信经历的应用程序开发人员发现，WebRTC 的体验质量是一个真正的挑战。标准互联网不对实时通信提供任何类型的“服务质量”保证，这一点可从私有企业网络中看出；因此，只要存在某种连接，就不会对用户之间传输语音和视频数据包的方式进行任何重新路由或更改。即使状况很糟，也会照旧进行。

全球性的“移动到移动”应用程序

就本质而言，WebRTC 提供了各种库和编解码器，它们包括在某些 Web 浏览器中，或者由不同公司打包为 SDK 以供移动应用程序使用，但是 WebRTC 并不为这些端点提供针对 QoE 优化的网络。网络质量完全取决于您以及用户之间变化莫测的诸多移动网络和互联网连接！

HelloTalk 是一款典型的全球性移动应用程序，同时适用于 Apple iOS 和 Android，可为任何国家 / 地区的用户提供一个交互式社交环境来学习新的语言。案例研究已经说明了对于像 HelloTalk 这样的公司，为何必须要让全球性的“移动端到端”通信每次都得提供卓越的体验质量，并且无论用户处于哪个国家 / 地区，无论采用何种网络连接。

端到端的 RTC 网络优化

对于“移动端到端”的 WebRTC 挑战，其解决方案在于提供一个针对 RTC 优化的全球虚拟网络，尽可能以本地方式连接各个移动设备，然后确保这些用户之间的全球连接在整个通信会话期间都保持出色的 QoE。

此体系结构包含两个重要部分：

1. 即使在移动中的最后一英里，也能通过“高速通道”从移动设备接入网络。
2. 网络中的各个设备之间建立全球性连接。

移动设备可通过 3G、4G 或 WiFi 和宽带连接至 Agora.io 网络，延迟和连接类型可能会在用户移动中不断变化。因此，这里的重点是容错，并基于网络状况不断调优音频 / 视频。由于预计会出现“数据包丢失”和“抖动”等技术问题，因此体系结构在设计上也必须能够处理它们。这需要对编解码器和传输协议进行创新，使之针对移动设备而高度优化。对于特定的设备，即使是回声消除这类功能，也必须高度调优，确保从一开始就提供最佳语音质量。

为确保从当地进行快速访问，需要提供大量的访问节点——Agora.io 目前在全球拥有超过 65 个数据中心，而且还在不断扩张。通信将会直接进入 Agora.io 网络，而不是在全球进行随机的对等传输。这使得“虚拟”Agora.io 网络可以自动、持续地针对 QoE 进行优化。

当通信抵达 Agora.io 网络节点后，如何将此通信路由至目标就成了关键问题。为确保在全球保持较低的成本，Agora.io 采用全球的互联网，但其路由和优化并不是完全依赖互联网。Agora.io 不断监视其所有节点，知道全球在每一时刻的最佳实时通信网络路径。因此，在路由过程中，系统会根据需要动态重新路由实时通信，从而绕开瓶颈并确保实现良好的 QoE。Agora.io 网络节点还直接管理低层级冗余选项和重新传输决策，对实时语音和视频通信提供最适当的处理，这一点不同于普通的 Web 需求或单向流式传输需求。

此方式对于处理网络“不良”(Brown-Out) 状况具有重要意义。在网络状况不良时，各互联网路径仍然有效，但状况很糟，无法满足实时通信对于低延迟和低数据包丢失率的需求。“中断”(Black-Out) 则与此不同，其中各连接均已中断，互联网可自行（缓慢）确定建立新路由的必要性。Agora.io 虚拟网络可快速发现整个网络中较好和较差的通信状况，并实时采取相应的措施。

因此，在整个会话期间，大部分 Agora.io 通信并非采取对等传输（尽管在本地可实现此功能），而是接受动态管理。其结果则是一款真正的端到端全球 SDK 和网络管理解决方案，可确保为语音和视频通信提供出色的体验质量，尤为注意满足移动设备的严苛要求。

优化的体验质量

为支持新一代“移动端到端”的全球性应用程序，以及台式机 / 浏览器和移动混合情形实现实时通信，开发人员需要一种针对 RTC 优化的全球网络。当今的大多数 WebRTC 方案只是提供相应的库，而网络是否够好则完全取决于您！而且，这些库和工具通常针对浏览器使用情形而优化，不一定适合性能和网络连接质量均波动剧烈的移动设备。

感谢魏星对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。