【腾讯】一文读懂腾讯会议在复杂网络下如何保证高清音频( 二 ) |腾讯QQ|运营商|技术|

其实腾讯的音视频引擎又可以分为三个小代际。第一代就是 QQ 用的， 2011 年 TRAE 引擎，第二代是 2016 年开始向外界开放的 OpenSDK 引擎，到 2017 年腾讯开发了 XCast 引擎，这算作第三代，在最新的 XCast 引擎之上，诞生出今天的“腾讯会议” 。
2019 年 12 月 25 号腾讯会议上线， 2020 年 3 月 6 日腾讯会议已经登顶 App Store 免费软件 NO.1 ，到今天不过两个多月， 3 月份日活达一千万，成绩还是比较难得的。 ZOOM 人数日活突破一千万是 2014 年 6 月份，当时的 ZOOM 是用了 3 年时间。
VoIP 音频系统的主要构成 VoIP 从发送端到接收端大概有哪些模块呢？我今天着重讲网络的流量控制、拥塞控制，包括丢包、抗网络抖动的一些逻辑，以及他们怎么样融合才能更好提升服务质量。核心是 QoS 的概念。

本文插图
QoS（Quality of Services）概念当时在 IETF（The Internet Engineering Task Force 国际互联网工程任务组）提出的时候，只专注于纯网络范畴的指标，比如丢包、延迟、抖动、带宽等。进入新世纪以后，行业对 VoIP 或者融合通信的理解有变化，进入宽带时代以后对指标会有更高期许和更高要求，比如说音频采集，本来采集信源不好，再经过压缩、传输、解码，可能最终效果不好。如果从 QoE（Quality of Experience）环节来看，端到端不限于采集模拟接口出来的声音，甚至包括人的讲话环境和听音环境影响，用户感受到的音频质量，是整个体系反馈出来的诊断。
QoS 没有太多秘密，无非就是抗丢包，抗抖动，网络拥塞控制等等， ARC（Adaptive Rate Control）可以看做一个中央指挥官，它只能去指挥整合这些方式、手段，最终保证音频质量是良好的改动。所以说到这块， QoS 一般套路就类似于一个全家桶，无非这六种模块的合理有机组合，接下来会对这几块深入讲一下。

本文插图
腾讯会议是如何保证服务质量的？1、腾讯会议的“流控”：ARC
先看 ARC ， ARC 在腾讯会议的概念就是“流控” ，流控能干什么？
是三个大的层面，首先它是一个配置系统，无论双人或多人通话，系统所需要的基础配置参数，还有在什么场景下需要什么样的参数。通过这个云端的参数配置及开关配置，系统拥有了基本的云端可控手段。
然后动态控制是中间的这块，流控是把源端到目标端的传输行为，发出来数据想让对方解码，会存在动态的能力交换的要求。此外，系统如果发生了抖动，或者丢包的情况，我们会动态的去控制相应的模块去处理这些情况。所以能力交换，或者动态下发的能力，实际上是动态控制的第二层次水平。
最高层的能力，是聪明灵活自适应的能力，就是对 ARC 的指挥能力的更进一步的要求，丢包的时候怎样去抗丢包，抖动的时候怎么样去抗抖动，去动态控制，但是这些抗丢包、抗抖动的方法有可能会占用过多的网络带宽、或者以牺牲端到端延时为代价的、于是当网络发现了比如带宽不足，或者网络用户本身终端连接路由器质量有问题，甚至出现网络趋于拥塞的情况，这种情况怎么去把它及时挽救回来，这个配置是对 ARC 更高层次的要求，涉及到网络拥塞控制（Congestion Control）这个核心命题上来了。
2、“流控”在腾讯内部的演进过程
一开始是都写死的参数，比如解码器参数、音频前处理 3A 开关等、抗丢包和抗抖动参数也基本是固定的，效果肯定不好。后来我们在系统增加了流控策略，根据客户端动态上报，动态去算 QoS 的参数下发。进化到多人通话以后，特别带宽预测是比较大的挑战，比如上行应该怎么算，下行是接收多交流又该怎么算，因为发送行为不一样，原来那种用一个算法对不同流进行预测，肯定不能用。