腾讯会议是如何保证服务质量的？
1、腾讯会议的“流控”：ARC
先看 ARC，ARC 在腾讯会议的概念就是“流控”，流控能干什么？
是三个大的层面，首先它是一个配置系统，无论双人或多人通话，系统所需要的基础配置参数，还有在什么场景下需要什么样的参数。通过这个云端的参数配置及开关配置，系统拥有了基本的云端可控手段。
然后动态控制是中间的这块，流控是把源端到目标端的传输行为，发出来数据想让对方解码，会存在动态的能力交换的要求。此外，系统如果发生了抖动，或者丢包的情况，我们会动态的去控制相应的模块去处理这些情况。所以能力交换，或者动态下发的能力，实际上是动态控制的第二层次水平。
最高层的能力，是聪明灵活自适应的能力，就是对 ARC 的指挥能力的更进一步的要求，丢包的时候怎样去抗丢包，抖动的时候怎么样去抗抖动，去动态控制，但是这些抗丢包、抗抖动的方法有可能会占用过多的网络带宽、或者以牺牲端到端延时为代价的、于是当网络发现了比如带宽不足，或者网络用户本身终端连接路由器质量有问题，甚至出现网络趋于拥塞的情况，这种情况怎么去把它及时挽救回来，这个配置是对 ARC 更高层次的要求，涉及到网络拥塞控制（Congestion Control）这个核心命题上来了。
2、“流控”在腾讯内部的演进过程
一开始是都写死的参数，比如解码器参数、音频前处理 3A 开关等、抗丢包和抗抖动参数也基本是固定的，效果肯定不好。后来我们 在系统增加了流控策略，根据客户端动态上报，动态去算 QoS 的参数下发。进化到多人通话以后，特别带宽预测是比较大的挑战，比如上行应该怎么算，下行是接收多交流又该怎么算，因为发送行为不一样，原来那种用一个算法对不同流进行预测，肯定不能用。
后来，我们还做了服务器混音。首先可以减少下行用户的流量，其次多路混音成一路，也可以对融合通信发挥基础作用。在对外提供 OpenSDK 的时代，因为对外用户的需求很不一样，因为应用场景的差别，有的用户需要不通类型 Codec，有的用户需要关掉 3A 处理，有的用户不需要那么大流量，有的用户更加在乎质量而不在乎流量，所以云端的 Spear 可配置参数的流控策略可以满足我们企业内部应用，包括外部用户的差异化需求。
腾讯会议对于拥塞控制的做法
接下来我们看比较核心的拥塞控制（Congestion Control）。其实拥塞控制在实时 RTC（Real Time Communication）音视频通讯领域应用中是必不可少的模块，WebRtc 在开源以后分别向社区贡献了 GCC1 和 GCC2 版本，当然这块不是说 Linux 系统下编译器的那个 GCC。
GCC1（Google Congestion Control ver.1）是一个基于接收端的算法，根据每家系统的软件架构的不同，它部署的位置也不一样。GCC1 核心算法是通过实时监控端到端延时的变化量（Jitter），从而判断当前这个网络是否趋于达到网络拥塞的情况。
我们首先看端到端延时这个基础概念，端到端延时由三部分组成：一个是传输延时，跟数据包大小及链路宽有关；第二个是队列延时，即数据包在路由器的队列中通过的时长；第三个传播延时，一般传播延时跟传输介质有关。
实际上在 GCC1 或者 GCC2 里面，它真正进入系统、进入计算的这个变量不是端到端延时，而是其变化量即 Jitter；Jitter=(TR(i)- TR(i-1))- (TS(i)- TS(i-1)) 包括前后两个数据包的接收时间戳之差再减去前后两个包发送时间戳之差，算法输入的是一个 Jitter，GCC1 通过 Kalman 自适应滤波器去除噪点，通过网络传输也好，通过整个链路传输过程也好，实际上这种延时的变化值 Jitter 是一种符合高斯分布的特征，当我们把噪点去掉以后就可以得出它的 Jitter 趋势。GCC1 算法将滤波后的 Jitter 值与动态阈值进行相应的状态判断，从而得出当前的网络是否趋于拥塞或者处于正常，与此同时还通过实时接收到的流量和预测算法给出当前一个合理的带宽预测值。
后来 GCC2 又更新了，是基于发端的，它的数据处理源还是 Jitter，就刚才说那个 Jitter，它是一个什么概念呢？自变量就是 Jitter，应变量是什么呢？应变量是它的历史平均值。所以它对自变量和应变量做了一个最小二乘法的一元线性回归，相当于去观察当前的 Jitter 值相比较历史平均值有怎样的发展趋势，被称作 TrendLine 算法。GCC 算法它在发送端也好还是在接收端也好，带来了工作上的灵活性，而 GCC1 中绝对值的阈值比较变成了 GCC2 中趋势线的判断，算法的准确性上有提高。而从及时性上来说，我们在 QQ 时代使用 GCC1 算法是，SDK 的架构还是有私有协议的，比如说反馈机制都是基于两秒的机制，在最新重构的第三代 xCast SDK 上上，完全兼容了标准协议，RTP 算法核心有准确度的提升，反馈上 RTCP 时机和及时性也有提升，所以“腾讯会议”相关的算法控制会远远老一代的 SDK 产品更加及时和准确。
FEC 如何把丢失的数据包恢复？
FEC（Forward Error Correction）实际上没有太多新意，这块无非就是利用其基本的特性。比如分组划分，接收端恢复不受数据包顺序影响等特征。举个例子：如果是分组是 4，那么在网络传输过程中任意丢掉一个，在接收端任意收到任何顺序的 4 个属于本分组的数据包，那就可以把丢失的包恢复。
那么它到底是怎么工作的呢？FEC 目前一般采用了 Reed Solomon 算法，Reed Solomon 算法的核心思想包含三个部分：
- 利用范德蒙德（Vandermonde）矩阵 F，通过 FEC 控制参数生成冗余矩阵。冗余矩阵的上半部分是一个单位矩阵，分组数据矩阵和这部分计算完以后还是原来的数据，接下来这部分数据则是实际用来产生冗余数据的矩阵。图示相当于 4 2 的原始数据生成 2 个冗余数据，ENCODING 就是这样范德蒙德矩阵与原始数据相乘，分组的原始数据相当于数据源，根据 FEC 编码参数额外生成的数据包就是冗余数据。
- 利用高斯消元法（Gaussian elimination）恢复损坏的数据，即算冗余矩阵的逆矩阵。使用逆矩阵与接收端凑齐分组的数据矩阵进行行列式乘法计算，从而恢复丢失的数据包。
- 为了方便计算机处理，所有的运算是在伽罗华域（Galios）的基础上进行。伽罗华域的特点是大小为 n 的集合，其上的任何四则运算的结果仍在集合中。伽罗华域上的加减法实际上等同于异或 Xor 运算，伽罗华域上的乘除法则通过查表计算非常快。
比如，传输过程中它可能会丢掉，比如 4 2 是 6 个包，任何顺序的 2 个包，还剩下 4 个包，就会去计算它的逆矩阵，这个逆矩阵去乘以接收端收到的任何顺序的，但是数量上凑够分组长度 4 个的数据包，通过矩阵算法可以恢复丢失的数据包。
从原理来讲很简单的，我们今天要讲 FEC，它在实际落地过程中还有一些技巧。比如在算法实际落地的时候，怎么样去评价 FEC 算法的效果，首先会有量化数据，比如基于一个统计算法，FEC 的恢复率是多少？加不加常态 FEC？多少倍的冗余公式去加这个 FEC？最终的效果什么样的？这些都需要强大的基于大盘数据的分析和 ABTest 运维能力才能逐步获取到的最佳值。比如，在一开始的版本，在没有加常态的 FEC 下，动态 FEC 恢复其实不到 90%。到再加常态 FEC，FEC 恢复率可以爬升至 95%，网络经常有小的丢包，那么指望系统、流控或者任何反馈机制，实际上不靠谱的，宁可去添加一些常态的 FEC 冗余。此外，对于实际的网络，突发的丢包是经常发生的，FEC 参数的设定也有融入控制论的相关思想，除了动态计算和下发 FEC 参数，还要考虑参数在一段时间的有效性，比如我们对 FEC 参数增加的缓降控制窗口逻辑，又进一步将 FEC 恢复率提升至最高的 99% 左右。
