拿下公司技术突破奖，腾讯 RTC 实时音视频技术内幕揭秘！

近些年来，随着移动宽带的不断提速，音视频应用的受欢迎程度也越来越高。尤其受上半年疫情的影响，更多原本线下的业务也被迫搬到了线上，这就更进一步的推动了以低延时见长的实时音视频产品的快速增长，腾讯实时音视频（Tencent-RTC，下文简称为 TRTC）正是在这个大背景下取得了新一轮的技术突破，并因此获得了腾讯公司级技术突破奖的。

本文将围绕三个主要的技术突破点，对该项目的阶段性成绩和其中涉及的技术细节进行一个全面的描述和总结。

什么是RTC？

RTC 是 Real Time Communication 的英文首字母缩写，也就是实时通信，不过业内经常说的 RTC 一般专指实时音视频通信。相比于目前已经广泛普及的直播 CDN 技术，RTC 这种音视频技术具备延迟更低和弱网络抗性更好的特点。因此可以满足一些对音视频传输延时和通信质量要求比较苛刻的场景。比如视频会议、在线教育、网络直播中的连麦和语聊房等等，这些场景都要求用户之间的音视频通信延迟要控制在 100ms 这个级别上，同时也要求卡顿率尽可能低，也就是通信质量不能轻易被网络的波动所影响到。

自开始到现在，TRTC已经成功在腾讯公司内部和外部的众多优秀产品中完成落地，伴随着这些产品成长，产品自身服务体量也在水涨船高。到2020年，TRTC 已经实现了千万级的并发规模，终端 SDK 也达到了亿级的 DAU 规模。

在疫情期间，TRTC支持腾讯会议和腾讯课堂在短时间内完成了千万 DAU 的快速增长。尤其是年初复工期间，TRTC 后台团队连续几天不眠不休，支撑腾讯会议在短短8天时间内完成了100万核心数的急速扩容，这一时期的腾讯会议的并发规模几乎每天都是翻一番。

同时，我们也支撑了企业微信的家校项目赶在春节结束前完成了项目上线，让众多老师和学生可以在家中用企业微信远程上课。

作为一款面向企业用户的 PaaS 产品，TRTC 除了支撑好内部业务，也在泛互联网行业和教育行业等领域取得了不错的收入和成绩，获得了这些行业内的一众知名客户的青睐和认可。之所以能取得以上的成绩，离不开 TRTC 团队过去几年里在三个方面取得的技术突破：

研发了一款面向企业服务的新一代音视频引擎；

构建了一套多架构互通的 RTC 融合通信系统；

打造了一个覆盖全球的实时 RTC 实时音视频云。

技术突破1

面向企业服务的新一代音视频引擎

TRTC 团队很早就开始在音视频领域进行摸索，最初是在 QQ 上做音视频功能，作为一个 ToC 的产品，QQ 音视频项目面临着非常大的挑战，但它需要解决的问题和应对的场景是确定的。但到了腾讯云的 ToB 的场景下，我们所面对的客户场景和技术挑战变得越来越多了：

在线教育场景中，客户对于课损率（也就是一天中不顺利的课程占总课程的比例）是非常重视的，如果一节课出现了音视频卡顿或者故障，家长会要求退费，这会让教育客户蒙受巨大的损失。所以在这个场景里，音视频链路的稳定和视频通话的可用性是最重要的。
在娱乐直播场景中，由于用户都是免费参与付费打赏，所以客户不会死盯着一次卡顿不放。但客户的技术团队往往都深谙互联网敏捷开发之道，两周一个版本的速度快速上线新特性和新功能是业内的常态，周六不休息，晚上不睡觉也是普遍现象。这种极快的迭代速度也对我们的研发效率提出了很高的要求。
在金融领域中，虽然没有类似互联网那种很快的版本迭代，但是各种复杂的内网环境，各种网络限制，各种子网划分，各种私有化的加解密方案，以及繁多的合规要求，都是在公有云项目中难以遇到的。
除了外部的企业客户，内部客户的挑战也同样严峻，腾讯内部的产品往往都配备经验丰富的研发团队，对产品体验的追求也是力求精益求精，对于服务可控性的要求也是很高的。这就要求我们本身内功必须过硬。

既要对外“赚钱讨生活”，又要对内支撑好各个明星产品，我们就不能简单地拿原来的技术拼拼凑凑，而是需要脚踏实地去开发一套面向企业服务的新一代音视频引擎。

首先，在引擎架构层面，这套引擎要具备很强的协同开发能力。为此我们严格采用了分层设计理念，并将内部各个模块进行了尽可能的解耦设计，目的就是为了让众多客户需求得以并行开发并减少相互之间的影响。与此同时，在 API 设计上也严格采用评审制的流程，任何 API 的增删都需要经过团队的推导和论证，避免“凭感觉”写 API，尽可能保证接口之间不相互干扰。

其次，在音视频效果层面，这部分是我们花费精力最多的地方。因为国内提供音视频 PaaS 服务的友商也不少，客户都是理性地用脚投票的。在音视频质量上，友商往往都会用“抗 xx 丢包，最低 xx 延时”这样的广告语进行宣传，但仅有这些刚性的指标还是不够的，因为这些指标往往是在带有实验性质的稳定弱网环境下得出的数据，比如测试抗丢包能力的弱网环境，往往会持续一个稳定的丢包率。只要您有一部 iPhone 手机，就可以用手机自带的 Network Link Conditioner 工具模拟出这种稳定的损伤环境。

但现实中的网络环境却是复杂的，中间会有很多随机的干扰因素。虽然上一秒还是四平八稳的 1Mbps 的流畅网速，下一秒钟突然的一个信号干扰，就可能会引发一个猝不及防的 80% 空口丢包，甚至一段时间内 WiFi 信号看着还有两格但就是不传输数据。

所以，我们创新性地引入了一套面向企业服务的 QoS 流控系统，这套系统内部设置了很多调节算法和调控策略，它不仅会有对单独网络模块的调节，也会在发送端和接收端将画质、音质、流畅度等一系列影响用户体验的音视频数据指标以很高的实时性收集上来，从而让整个流控模块可以为最终的用户体验和主观的音视频效果去做实时地调节。

特别值得一提的是，由于这套 Qos 系统跟客户的行业属性是绑定的，所以我们也会把对这些年来对于客户行业场景的理解和客户的差异化要求融入其中。比如在线教育客户的 1v1 海外英语教学就非常看重上课期间的语音是否流畅和洗练；社交型 App 里常见的美女秀场直播则更看重画质和音质；类似 CCTV 这样的广电客户，对主持人在线连麦的要求就是声音模块不能剪切音节也不能漏字。

总之，客户的业务场景是多样的，但有了这套全新的 QoS 系统，差异化的需求也都能差异化地去满足。

对于一款 PaaS 产品而言，光有效果还不行，客户对服务的稳定性也是非常看重的。ToB 服务不比 ToC 产品，可以灰度的方案和手段都非常少，而且给不给灰度的机会全都由客户掌控。有时候商务团队辛辛苦苦谈下来一个订单，我们就只有一次的“上台表演”机会，接不住就把机会给浪费了。所以客户每一次的体验和试水测试对我们都是一次考验，一旦遇到了关键时刻掉链子的情况，也就意味着订单的丢失。

所以，为了能够通过一次次客户的考试，同时也让终端 SDK 的可用性更强，我们也针对性地进行了可用性上的专项设计优化：参考服务端双机互备的思路，我们在关键模块上均采用了冗余设计的原则，努力做到每个关键模块都有两套实现方案，当一套方案遇到兼容性问题时，第二套方案会无缝接上。

由于在高可用性上的追求，过去几年，我们在设备兼容性上的表现还是可圈可点的：不管是成本不过百元的广电网络电视盒子，还是几十块钱的低成本 USB 摄像头，从孩子们手上的小天才智能手表到 CCTV 的可移动导播台。我们都进行了充分的适配，并且在这些林林总总的设备上都跑出了不错的成绩。

当然，终端 SDK 上的技术突破只是一小部分，对于一个强大的云服务产品而言，云端的能力建设才是唱主角的部分。为了面向各个行业差异巨大的行业需求，TRTC 的云端系统也在网络拓扑结构上进行了多梯度的差异化设计：

首先，采用了出口线路优质和性能优异的接口机集群承接低延时和强互动的实时通信需求，接入这个集群的用户可以体会到 100ms 级别的点到点通话效果。这对于视频会议，在线教育等场景下的应用非常关键。

同时，系统也使用了大批具备高并发能力的代理机，用于承载高并发的低延时观看需求，接入这个集群的用户可以体会到 1000ms 以内的低延时直播观看体验，并可以无缝地切换到接口机集群并在两套集群之间进行自由切换。

这就意味着我们不仅能给客户提供低延时和高流畅的实时视频通话体验，同时也能突破人数限制，让这种多人音视频能力可以扩展到 10W 级别的高并发观看。并且所有参与其中的用户都可以随时在“观众”和“主播”之间迅速切换，突破传统 RTC 方案中单个房间最多百来人的人数限制。

不仅如此，TRTC 系统还支持跟直播 CDN 系统的无缝融合，以及企业商用服务所必需的录制和监控能力，进而将众多云计算能力集成到这套高并发低延时的 RTC 系统中，从而能够应对各行各业的客户诉求。

作为一款打造了多年的 RTC 服务，以上介绍的这些都还只是整个体系中的部分技术点，过去几年的时间里，从系统搭建到质量提升，再到今天的服务体系。团队一直都非常专注地在这个方向持续深耕，几乎每个季度我们都会取得一些质量和能力上的突破，就这样一步一个脚印，逐步将整个系统的能力锻造成业内领先的水平。

技术突破2

构建多架构互通的 RTC 融合通信系统

闭关锁国必然导致落后挨打。

虽然有了新的引擎，但仅仅在这套体系之上不断地添砖加瓦还是不够的。我们需要让这套系统保持极高的开放性，使其能够不断地外延，跟更多的异构 RTC 方案进行互通，这样才能让 TRTC 的使用场景越铺越开。

首先要扩展的就是对 WebRTC 的支持。WebRTC 在 2016 年底开始支持 264 编码方案。在 2017 年，支持 WebRTC 系统的浏览器已经占据了 60% 以上的市场份额。所以我们很快意识到，让 TRTC 跟 WebRTC 互通是大势所趋。

但是这个互通确实不是一件容易的事情，其核心问题就在于 WebRTC 是一个面向 1v1 音视频通话这样一个细分场景的解决方案，而且其研发团队对浏览器终端的侧重远远多过于后台，所以在谷歌官方的设计方案中，WebRTC 的客户端源码是很复杂的，而服务端所需要做的仅仅是提供一个简单的数据包转发服务。而且，两个 WebRTC 客户端之间的通信全部采用了点对点加密，作为服务端虽然有转发职责，但是并不知道转发的内容是什么。

与之相悖的是，企业客户所需要 RTC 服务则不是简单的 1v1 通话，而是需要配合一整套强大的云端服务。以腾讯会议为例，数百人的多人通话和实时会控能力是必须的。同时，为了减少每一路的数据传输，云端会采用 MCU 系统对声音进行多路混合。为了存档的需求，云端转发的音视频数据也需要进行实时的录制，这都是基本的刚性需求，而标准的 WebRTC 要实现这些能力都是不可能的，因为标准方案中，服务端只是被作为一个中转服务器而存在，而且并不是必须的。

所以团队创新性地引入了一种技术方案绕开这种限制：即在云端引入了跟客户端 1v1 通信的镜像实例，这些镜像模块就相当于一个个在云端运行 WebRTC 的“假用户”，它们跟浏览器中的真实用户进行数据通信，但是会将接收到的数据进行实时“翻译”，转换成 TRTC 系统理解的数据格式，从而接入到了 TRTC 现有的系统中。

如果上面的这段描述不好理解，那我们就打个比方，两个 WebRTC 客户端就好像两个讲阿拉伯语的伊拉克朋友，我们的服务器就好像一个不懂阿拉伯语的中国人，如果我们单纯夹在中间，可能完全不知道他们相互在说什么。所以我们就找了一位既懂阿拉伯语又懂中文的朋友，让他在中间负责实时的翻译，这样大家就都明白各自在说什么了。也就是采用了这套方案，我们将 TRTC 的能力扩展到了支持 WebRTC 能力的浏览器上。

不过遗憾的是，虽然 PC 端的 Chrome 和 Safari 浏览器对于 WebRTC 的支持非常不错，但是移动端浏览器的支持情况则非常差劲，尤其是 Android 手机上的表现很不理想。

为此，我们团队跟微信小程序团队进行了深入的合作，微信小程序团队的同事们非常开放地新增了两个音视频标签 live-pusher 和 live-player，虽然有标准协议的种种限制，但我们依靠云端强大的节点分布和协议互转能力，在微信小程序上实现了非常不错的音视频体验。

如果您问：如果浏览器不行，微信版本也太旧，是不是就没有办法了？我要说这样也是可以的，通过跟 sip 协议的打通，TRTC 还将自己的音频通信能力扩展到了蜂窝电话上，比如现在腾讯会议中的电话入会，就是采用了这种能力实现了网络线路和传统电话线路的互通。

技术突破3

覆盖全球的实时 RTC 实时音视频云

巧妇难为无米之炊，前两个技术突破说的都是单点的技术提升，但再好的技术也敌不过资源的短缺。尤其是在海外质量这个方面，如果没有很近的接入点，顶着 1000ms 的网络延迟，再好的技术也难以实现不错的使用体验。

不过 TRTC 在这方面还是做得很不错的，通过多年厉兵秣马的建设，目前 TRTC 在海外的接入质量已经达到了公司内的领先水平：所有腾讯云的海外接入点，TRTC 都有覆盖。

不当家不知柴米油盐贵作为一个面向企业服务的 PaaS 产品，只是技术做得好还是远远不够的，成本的优化也是异常关键。在 RTC 系统中，多路画面的混合和多路声音的混音是一个基本刚需，而这个能力需要消耗大量的计算资源，在这部分的成本优化就显得格外重要。

TRTC 并没有采用目前业内比较普遍的硬件 MCU 解决方案，因为这样的 MCU 硬件由于没有产业规模，往往单机价格都非常昂贵。为了节省成本，团队学习谷歌当年用廉价 PC 机组合搜索服务后台的思路，自研了一套基于指令加速的软件 MCU 系统，该系统可以运行于最普通的云主机上，从而将硬件成本从昂贵的特种服务器变成了具备规模化优势的云服务器，实现了成本上的大幅缩减。