2017 已过大半，从年初盛起的《王者荣耀》、《狼人杀》却依然是最火爆的游戏产品，其共同特性都在于集成了实时语音功能，前者左手走位右手技能，语音自然也就成为了非常必要的属性，而后者更不用说，本就是纯粹依靠实时语音进行下去的游戏。

而从游戏到直播、在线教育/医疗以及 VR/AR、AI 等互联网垂直行业及创新技术，这样的例子还有很多。比如转型做直播的陌陌在最新的 8.0 版本中推出了“快聊”、“狼人杀”、“派对”等实时视频社交玩法；小米在新发布智能音箱中也集成了实时语音云服务。随着互联网服务越来越廉价易得，诸如网络电话、视频通话、全互动直播等实时场景已然成为用户的普遍需求，越来越多的规模化应用基于使用模式及场景集成了实时音视频功能，“实时”俨然已是互联网最热的标签词之一。

从互联网发展历程看 —— 实时通信和互联网交叉融合所带来的改变

但实际上，始建于上世纪 60 年代的互联网本身并非为“实时”所设计，受限于当时的应用场景和技术，再加上不同国家、运营商之间人为制造的屏障，通信技术在实时传输、质量保证等各方面都可谓差强人意。

也正因如此，从互联网诞生之日起，一代又一代的技术人便在对通信技术进行不断地更新升级。1989年，还在欧洲粒子研究中心（CERN）的 Tim Berners-Lee 研制出了三项突破性的数字通信技术：可用于排列文本文件的 HTML 语言、连接文件的 HTTP 系统以及用来对特殊节点信息进行定位的 URL。这三项创新改变了整个通信系统，使得信息能够更容易地穿越计算机网络。而在1993年，Berners-Lee 更是建立起万维网联盟（World Wide Web Consortium，简称 W3C），负责 Web 相关标准的制定。浏览器的普及和 W3C 的推动，使得 Web 上可以访问的资源逐渐丰富起来，然而此时 Web 的主要通信还是浏览器向服务器请求静态 HTML 信息。

不过，同在 1993 年，CGI（Common Gateway Interface，通用网关接口）的出现带动了 Web 上动态信息服务的蓬勃兴起。CGI 定义了 Web 服务器与外部应用程序之间的通信接口标准，Web 服务器可以通过 CGI 执行外部程序，让外部程序根据 Web 请求内容生成动态的内容。

到了 1995 年，NetScape 公司设计的 JavaScript 被用作浏览器上运行脚本语言为网页增加动态性，不仅能够做出非常酷的页面动态效果，还可以减少与服务器端的通信开销，而十年后，也就是 2005 年，当 Google 的崛起掀开了 Web 2.0 的大幕，应运而生的 AJAX 更使得 JavaScript 再次大放异彩。

我们知道，在 Web 应用中，用户提交表单时就向 Web 服务器发送一个请求，服务器进行接收处理，并返回一个新的网页，前后两个页面中的大部分 HTML 代码往往是一样的，由此也就造成了返回时带宽资源的浪费。而 AJAX 应用仅向服务器发送并返回必要的数据，且在客户端采用 JavaScript 处理来自服务器的响应，更新页面的局部信息。这样不仅让浏览器和服务器的数据交换大大减少，且客户端也可以更快速地响应用户操作。

而到了移动互联网时代，通信技术标准化也就成为了水到渠成的自然现象。在《苹果终于入伙 WebRTC，新一代移动 Web 应用爆发路上还有哪些坑？》一文中，我们曾谈到的 WebRTC 标准便是典型案例之一。

在 2011 年以前，浏览器之间要想实现实时通信，需要私有技术，其中大部分都是通过插件和客户端来安装使用。对于许多用户而言，插件的下载、安装和更新是一个复杂、繁琐和容易出错的操作。而对于开发人员来说，插件的调试、测试、部署、错误修复和维护同样困难重重，且不提还涉及到一些受版权保护的技术，整合相当复杂。再者，很多时候，服务提供商很难说服用户去安装插件。

但这一两头吃力还不讨好的局面就这样被 Google 将 WebRTC 项目开源所打破。2011 年，WebRTC 基于 BSD 协议开源，同年，W3C 启动 WebRTC 计划，让 WebRTC 成为了 HTML5 标准的一部分（目前，该规范还在开发中）。

另一方面，在移动互联网创业大潮涌动之时，不少创业者选择从移动 SDK 切入，将实时通信工具化，开发者及团队无需顾及实时通信背后繁琐的技术原理与逻辑实现，只需在应用开发中集成相应的 SDK 即可轻松实现实时通信功能。这方面的代表性企业可见声网 Agora.io，其提供了一个极简 SDK，让开发者接入 SD-RTN™ 实时虚拟通信网，在任何 App 和网站实现高质量的音频通话、视频通话、全互动直播。

同时，随着网络基础设施到位、硬件配件发展成熟，以及 4G、Wi-Fi 的普及，用户开始对更丰富的功能、场景有了更多的需求。譬如在当前人工智能如火如荼之时，诸多智能设备都集成了实时音视频的功能，前文提到的小米 AI 音箱即是其中之一。

对此，声网 Agora.io CEO 赵斌如此总结道：

中国互联网发展迅猛，基础云服务、开源技术、HTML5、移动 SDK 等技术，让中国的开发者能最快速地开发移动和网页 App，与世界比肩。下一个风口，一定会是融合了实时通信技术的应用。

那么，在风口之上，实时通信还存在哪些技术难点尚待完全攻克？

接下来，我们进行具体分析。

• 网络传输：现存的互联网作为冷战时代的产物最早其实是为了用于保障美国通信网络，其在网络传输方面的种种局限也直接导致了现在的互联网在大文件传输、实时传输方面的窒碍难行。而语/视频通信、直播连麦对实时性要求非常高，要求延迟低至几百毫秒，因此，现存的互联网并不能满足这种新型的实时应用场景。

• 编解码：传统的编解码算法，也非应用于复杂的互联网实时场景的良选，就导致卡顿、模糊等不可用的情况发生。

• 硬件适配：在音视频通话中，除了延迟，还有一个严重影响用户体验的问题 —— 回声。所谓“回声”，即是指自己的声音传到远端再通过远端的麦克风录音传回来。我们需要通过信号处理算法来进行回声消除，但由于手机的音量控制是非线性的，不同的手机材质、手机壳会导致声音传导性有差异，设备种类差异导致算法不能普适。且Android 手机碎片化严重，也就直接导致了移动端适配工作量庞杂。

• QoE 质量保障： 来自北欧的实时通信数据测试公司 Callstats.io 曾分享过欧美市场实时通信行业现状的调研数据，基于公网的 WebRTC 通话中有 16% 通话质量不可接受。而实际情况中，类似东南亚、中东这些基建不发达地区会糟糕得多。如何保障 RTC 服务的高连通性、高质量，也就成为了 RTC 领域的一大技术难点。

想要从根源上解决这些问题，还需要先对 RTC 整个技术栈做个了解。

RTC 从功能流程上来讲，包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节，下图是一个 RTC 通信的粗略流程，每一个细分环节还有更细分的技术模块。比如在前后处理环节，有美颜、滤镜、回声消除、噪声抑制等，采集有麦克风阵列等，编解码有 VP8、VP9、H.264 等。

在这里，来自声网的技术专家分享了他们的实践：

• 通过专为内容实时传输而设计的网络架构 SD-RTN 解决网络传输问题。在互联网上不同地区的数据中心放置软件组网单元，相互连接互相调度，在现有的公共互联网基础上构建一层新的虚拟网络；
• 针对互联网信道的实时一对一、多人通讯设计了专门的私有编解码，以适应互联网丢包、抖动、延迟等问题；

• 将“免”适配和适配相互配合，依靠线上数据的反馈，判断“免”的效果；
• 基于大数据开发了可供开发者 7*24 查看的“实时数据监控平台”。开发者可以查看的每个用户的通话质量情况，包括网路分布、设备分布、质量分布、通话质量、接通率、通话分钟数等。

值得一提的还有，不少开发者直接将 RTC 和 WebRTC 划上了等号。实际上，WebRTC 是 Google 的一个专门针对网页实时通信的标准及开源项目，只提供了基础的前端功能实现，包括编码解码和抖动缓冲等，开发者若要基于 WebRTC 开发商用项目，需要自行做服务端实现和部署，信令前后端选型实现部署，以及手机适配等一系列具体工作。除此之外，还要在可用性和高质量方面进行大量的改进和打磨，对自身开发能力的门槛要求非常高。而一个专业的 RTC 技术服务系统，除了涵盖上述的通信环节外，实际上还需要有解决互联网不稳定性的专用通信网络，以及针对互联网信道的高容忍度的音视频信号处理算法。当然，常规云服务的高可用、服务质量的保障和监控维护工具都只能算是一个专业服务商的基本模块。

那么，当实时通信无处不在之时，我们该怎么做？

当各式智能硬件、移动应用以及 Web App 中的许多模块都越来越依赖于音视频技术，实时通信已然成为了所有行业的一大基础设施，不仅仅是在直播、游戏这些泛娱乐行业，更渗透到在线医疗、教育、金融等领域。在不同场景下，推动着人们沟通互动方式的改变。

但是，就是这样一个已与各个垂直行业进行深度融合需求庞大的技术领域，却仍然匮乏核心技术高端人才。RTC 核心技术最需求的是通信工程相关专业的人才，而这些专业的应届毕业生此前就业一般集中于华为、爱立信等传统通信行业厂商，也不具有 RTC 的经验，一般都是工作后二次学习。开发者需要对实时通信有更深层次的理解，建立起 RTC 技术体系，帮助自己在各个行业开拓创新的可能。