共计 7810 个字符，预计需要花费 20 分钟才能阅读完成。
通过上次的《RTC 零碎音视频传输弱网反抗技术概览》，咱们晓得 RTC 的三大外围指标为实时性、清晰度、晦涩度。在整个通话过程中外围体现达标，能力给用户一个根本的良好体验。关注【融云寰球互联网通信云】理解更多
然而音视频数据在网络中传输时，网络是变化多端和不可预知的，比方地铁、公交、家里、公司专用 WiFi，以及不同时间段流量顶峰等造成的网络变动都不一样，这些都会造成网络的抖动、带宽容量动态变化等，最终影响音视频的体验。
因而，咱们须要对网络带宽变动进行无效的动静探测和评估，保障音视频链路上发送的音视频数据流不超过链路容量下限。否则，就会带来大量丢包，难以复原，最终造成通信一端或单方视频卡顿、语音卡顿、丢字等问题。
本文次要分享音视频传输弱网问题中，针对网络拥塞的反抗技术。
典型动静带宽探测办法
网络拥塞钻研不是一个新的话题，前后有近四十年的历史，因为以前内存比拟低廉，传统的动静带宽探测个别是基于丢包拥塞的办法，这种办法不能在丢包之前发现网络曾经处于拥塞状态，当探测到丢包时，实际上音视频体验就曾经呈现了卡顿问题，不太适宜音视频利用。
随着内存价格的升高，当初当网络拥塞时，个别会把发送不过去的数据包先暂存到网络队列内存 buffer 中，待后续发送，只有当 buffer 满了才会抛弃包。
利用网络队列 buffer 较大这个个性，当初比拟典型的办法是基于提早梯度预计和丢包相结合的带宽预计办法。
有三种比拟经典计划：
GCC 算法 [1] 是出自 Google 的一种延时预计和丢包相结合的拥塞控制算法，在 WebRTC 中被默认应用。
NADA 算法 [2] 是思科公司提出的一种基于延时预计的办法，这种算法带宽利用率高，跟踪带宽变动方面体现很优良。
SCReAM 算法 [3] 是爱立信公司提出的一种基于延时预计的算法，在 OpenWebRTC 中被采纳。
这篇论文 [4] 比拟了以上三种算法的成果：
多路 GCC 可能平衡利用整个带宽，但在动静链接中具备锯齿特色，收敛比 NADA 迟缓；在有损链路方面具备更好的性能，这也使得它特地实用于无线网络。
NADA 能够在动静链路中疾速稳固速率，收敛较快，在链路不受随机丢包影响时，带宽利用率高，但若遇随机丢包状况，带宽利用率会变得很低；同时受“后来者效应”影响，体现为后来者会应用更多的带宽，在带宽平衡应用方面不如 GCC。
SCReAM 将链路队列提早放弃在低水平，但带宽利用率低，且对带宽变动比拟机灵。
总体来说，GCC 更优越一些。
GCC 算法为 Google 提出的基于延时梯度预计和丢包的拥塞控制算法，在 WebRTC 中失去了⼴泛利用，目前为 WebRTC 默认应用的算法。
该算法有两个版本，一个版本是散布在发送端和接收端，接收端通过对提早进行预计，并通过 REMB RTCP 报文反馈评估进去的带宽；发送端则依据丢包率和接收端反馈的带宽来计算最终的代码码率，进而调整编码器编码码率，这个框架将其称之为 REMB- GCC。
另一个版本是所有估算都放在发送端，即基于提早带宽预计和丢包率预计都放在发送端，接收端通过定时向发送端反馈 Transport-wide RTCP 包，告知发送端的收包状况，这个办法个别称之为 TFB-GCC。
两种算法的框架原理基本一致。TFB-GCC 比 REMB-GCC 更优，也是 WebRTC 后续举荐应用的拥塞控制算法，上面对这两种算法做详细分析。
REMB-GCC 算法
（REMB-GCC 算法架构图）
基于 REMB 形式的 GCC 算法，分为两大部分，发送端局部和接收端局部。
接收端 局部负责基于工夫延时梯度的变动来评估接收端的带宽变动，这部分次要分五个子局部，Arrival filter、Adaptive threshold、Overuse Detector、Remote Rate Controller、Remb Processing；
接收端最终评估进去的带宽将通过 REMB RTCP 包反馈到 发送端，发送端联合丢包率及反馈的带宽计算最终的带宽，这个最终带宽将用来调整发送端编码器编码带宽，FEC 和 pacing 带宽及重传包的带宽，上面具体介绍各个模块。
接收端模块
Arrival filter
以 RTP 传输的包，每帧可能被分成多个 RTP 包发送，每个发送的 RTP 包携带了一个 RTP 扩大，称其为 abs-send-time 扩大，这个扩大记录了发送端发送该包时的工夫信息；接收端在接管每个 RTP 包时，也会记录该包的达到工夫。
该算法将通过如下（公式 1）计算相邻两帧的接管时间差和发送时间差之间的距离，这个距离即为该帧在网络传输的工夫上的⼀个变动，这个变动蕴含如下三个局部内容：
① 该帧数据在网络传输工夫绝对于上⼀帧在网络传输工夫的变动，这是包 size 变动方面的度量
② 包在网络队列排队的工夫变动
③ 网络噪声烦扰
这三个方面的变动，在测量上来看，都体现在以下公式 1 及示意图中。
公式 1：dmi = ti − ti -1 − (Ti − Ti-1)
（公式 1 示意图）
须要阐明的是：
① ti 示意第 i 帧的最初⼀个 RTP 包收到的工夫
② ti-1 示意第 i-1 帧的最初⼀个 RTP 包收到的工夫
③ Ti 示意第 i 帧的第⼀个 RTP 包发送的工夫
④ Ti-1 示意第 i-1 帧的第⼀个 RTP 包发送的工夫
⑤ RTP 包的发送工夫都是携带在 RTP 包的 abs-send-time 扩大中
延时梯度预计的另一个示意办法为：
公式 2：dmi = dLi/Ci + mi + ni
Ci 为接管第 i 帧时刻的链路容量预计，dLi/Ci 为接管第 i 帧时刻包在网络中传输的工夫变动，次要受包 size 大小的变动和链路容量变动影响，这个也能够作为评估抖动的⼀个要害指标。
ni 为接管第 i 帧时刻网络 jitter 引入的噪声，mi 为接管第 i 帧时刻网络队列延时深度变动预计，dLi 示意第 i 帧和 i − 1 帧两相邻包的大小差，按如下公式 3 计算：
公式 3：dLi = Li −Li-1
获取到 dmi 和 dLi 两个样本数据后，将它们作为 kalman 滤波器的输出，利用 kalman 滤波器来估测延时梯度的变动 mi。
补充阐明：
在延时带宽预计中, 使⽤ kalman 滤波器对输出样本进行预计，但只用到了网络队列延时变动这⼀个指标。
其实，还能够预计网络抖动，在 video jitter buffer 中就应用同样的办法进行了网络抖动的预计，只是延时带宽预计这块只用了“包在网络队列排队延时的变动这⼀个指标而已”，没有用抖动；而 jitter buffer 中只⽤ kalman 滤波器估算抖动。
所以在抗抖动问题上，能够尝试应用这些指标进行相干优化⼯作，融云也将在这方面进行继续优化。
因而，Arrival filter 的性能就是利用 kalman 滤波器，通过测量失去的 dmi 和 dLi 估算出 mi，它反馈了网络链路包进入 buffer 队列变动状况；同时 mi 也将作为 Adaptive threshold 和 Overuse Detector 兄弟模块的输出。
卡尔曼滤波（Kalman filter）是一种⾼效率的递归滤波器（自回归滤波器），它可能从一系列的不齐全及蕴含噪声的测量中，预计动静零碎的状态。
卡尔曼滤波会依据各测量量在不同工夫下的值，思考各工夫下的联结散布，再产生对未知变数的预计，因而会比只以繁多测量量为根底的预计形式要准。
Adaptive threshold
该模块依据 Arrival filter 估测的 mi 来定时更新阈值 γi，mi 和 γi 将作为 Overuse Detector 模块的输出，评估以后网络是否处于过载状态。
阈值 γi 是⼀个动静调整的过程，计算如下：
公式 4：γi = γi + ∆T ⋅ kγi(∣mi∣−γi)
公式 5：∆T = ti − ti -1
公式 6：kd 倡议值为 0.039，ku 倡议值为 0.0087
Overuse Detector
该子模块依据前两个模块输入的阈值和队列延时变动预计来评估以后网络是否处于过载状态。
mi 大于 0，示意网络中的队列深度正在减少，阐明链路中的包发送量在减少，延时变大，当不做任何解决时，将呈现网络队列变满而导致大量丢包；
mi 等于 0，示意以后网络发送延时没有变动，网络发送量没有队列；
mi 小于 0，示意以后网络队列正在缩小，网络拥塞在改善。
算法通过比拟 mi 和 的 γi 值来判断以后网络负载情况，如下公式 7 和图所示：
（公式 7 示意图）
Remote Rate Controller
该子模块将依据 Overuse Detector 模块输入的网络过载状态来调整带宽。
GCC 保护了 increase、decrease、hold 三个状态，三个状态的转换关系如下图所示：
（GCC 保护的三个状态关系）
这三种状态下的带宽调整策略如下公式 8 所示：
Ri 示意接管第 i 帧时刻，统计进去的接收端理论收包带宽
Ari 示意接管第 i 帧时, 基于延时预计估算进去的网络带宽
在 increase 状态时，在上⼀次估算带宽根底上晋升 8%，但理论值不超过接管码率的 1.5 倍，即不超过 1.5 ∗ Ri；
在过载状况下，须要降低码率，并且以理论接收端接管的码率为参考，按其 0.85 倍为以后估算带宽，即 0.85 ∗ Ri。
这样可疾速升高发送端带宽，复原网络拥塞状态。
Remb Processing[5]
Remote Rate Controller 子模块计算出最终的接收端的评估带宽后，将通过 REMB RTCP 报文反馈到发送端，用来告知发送端接收端评估的链路带宽。REMB 的报文格式如下所示：
该音讯中蕴含如下几个信息：
- 反馈音讯类型（FMT）为 15
- 有效载荷类型（PT）为 206
- 该报文发送端的 SSRC
- 媒体源 SSRC, 个别为 0
- 标识为“REMB”
- 接管包的 SSRC 条数
- 估算带宽值
- 估算该带宽链路上接管的媒体流 SSRC，1 个或多个
GCC 算法在反馈 REMB RTCP 报文时，个别是每隔 200ms 发送一次，当探测到带宽过载时，探测的带宽小于上次带宽的 95%，则立刻反馈。目标是疾速升高，安稳回升。
发送端模块
发送端次要是依据丢包率修改带宽，目标是：当提早预计模块带宽没有及时调整发送端带宽，拥塞还存在时，可能基于丢包来调整带宽。
发送端最终的带宽将联合丢包调整的带宽和 REMB 反馈过去的带宽，取两者中较小的值。基于丢包率调整带宽的逻辑如下公式 9 及公式 10：
公式 10：Ai = min(Asi, Ari)
Ai 为第 i 帧时刻最终 GCC 依据发送端和接收端估算进去的带宽，并为发送端基于丢包计算的带宽和接收端基于延时预计的带宽的较小值。
编码器带宽、发送端 pacing 带宽、重传带宽都将参考该带宽进行调整，个别编码器带宽为：max(0.5 ∗ Ai，Ai − FecRi − RtxRi) , pacing 带宽为 2.0 ∗ Ai，重传带宽为 1.5 ∗ Ai。
注 : Asi 为第 i 帧时刻发送端依据丢包率估算的带宽值，fli 为第 i 帧时刻接管到接收端反馈的丢包率。
REMB-GCC 算法总结
REMB-GCC 算法目前曾经被 Google 放弃保护，因为其散布公布端和接收端，须要发送端和接收端相互配合，而且应用了 kalman 滤波估算延时梯度变动，理论应用中存在一些问题，如 kalman 滤波估算不够精确且简单，接收端和发送端同时参加带宽估算不如都放在一端进行估算不便、精确和疾速。
因而，Google 在 WebRTC 后续版本中应用了 TFB-GCC 代替 REMB-GCC。
TFB-GCC 算法
（TFB-GCC 算法架构图）
从上图能够看到，对带宽的估算大部分工作都放在发送端，接收端仅做两件事，一个是定期反馈 transport-wide-seqnumber rtcp 包和丢包率 fl，fl 这里形容的丢包率是 RR 反馈的，当有多路流时理论计算是有 SR 和 RR ⼀起计算出来的。基于提早预计和基于丢包预计都放在发送端解决了，基于丢包预计和 REMB-GCC 一样，没有变动；基于提早预计次要是用 TrendLine filter 替换了 kalman filter。
Transport-wide sequence number[7]
发送端发送的 RTP 包会携带⼀个扩大头 Transport-wide sequence number，扩大头内容如下：
这里是单个字节示意扩大头（0xBEDE）为标识符，length = 1，示意该扩大占有 4 个字节，L=1，示意 Transport-wide sequence number 占 2 个字节。
当发送端每收回一个包，都会将该包的该扩大字段的 Transport-wide sequence number 累加 1，须要留神的是，当发送端发送多路流时（每路流的 SSRC 不⼀样），所有流的 RTP 包的该扩大字段都是间断计数的，不会离开独立计数。该扩大头的作用是为了标识发送的包和反馈的包对应关系。
接收端反馈 Transport-wide RTCP 包[6]
接收端在 TFB-GCC 框架下，次要是定期发送 Transport-wide 反馈包，用来告知发送端，接收端收包相干信息，包含包的达到状况及包的达到工夫等信息，其音讯格局及外围字段解析如下：
base sequence number：此反馈中第⼀个数据包的传输范畴序列号，该数字不⼀定会随着每个反馈减少，在从新排序的状况下，它可能会缩小。
packet status count：此反馈蕴含多少个 RTP 数据包的数量，从由根本序列号标识的数据包开始；比方记录的第一个 RTP 包的 transport sequence number 为 base sequence number，那么记录的第二个 RTP 包 transport sequence number 为 base sequence number + 1。
reference time：示意参考工夫，以 64ms 为单位，RTCP 包记录的 RTP 包达到工夫信息以这个 reference time 为基准进行计算。此数据包中的第⼀个 recv 增量是绝对于参考工夫的。即便某些反馈数据包失落，参考工夫也能够计算反馈之间的增量，因为它始终应用雷同的时基。
feedback packets count：用于记录接收端发送的 Transport-wide 反馈包的个数，每发送⼀个反馈数据包，计数器就加一。这个字段可用于检测反馈包是否失落。
packet chunk：数据包状态块列表，用来批示数据包达到的状态，批示的 RTP 数据包范畴是从根本序列号标识的数据包开始的多个数据包。
recv delta：对于 packet chunk 中的“packet received”状态的包，也就是收到的 RTP 包，在 recv delta 列表中增加对应的的达到工夫距离信息，用于记录 RTP 包达到工夫信息。通过后面的基整工夫以及 recv delta，发送端能够计算出该 RTP 包在接收端的达到工夫。
Delay-based controller
该模块为基于延时预计带宽模块，等同于 REMB-GCC 的接收端局部。
具体蕴含了 ATF（等同于 REMB-GCC 中的 Arrival filter/Adaptive threshold）/Overuse Dectector/Remote Rate Controller。
ATF
其次要性能是估算延时梯度变动 mi，它依据输出 dmi，利用 Trendline 滤波器中的最小二乘法对 mi 做最优预计 , Trendline 最小二乘法过程如下：
公式 11：dmi = ti − ti -1 − (Ti − Ti-1)
注：ti 和 ti - 1 是通过客户端反馈的 Transport-wide RTCP 包的达到工夫获取，发送端在发送 RTP 数据包时，会为每个 Transport-wide sequence number RTP 包记录⼀个发送工夫 T。
以下公式 12 形容累计的队列工夫延时：
以下公式 13 为平滑累计队列工夫延时：
公式 13：
smoothedDelayi =smoothingCoef∗smoothedDelayi_1 +(1−smoothingCoef)∗accuDelayi
以下公式 14 依照第 i 帧的收包绝对工夫和平滑时间延迟来结构了⼆元组：
(xi, yi) ⇒ (ti − t1 , smoothedDelayi)
二元组将依照以下公式 15 来估算 mi
这里的 TrendlineSlope 即为 mi。
趋势线斜率是链路队列状态的反映。当链路队列长度减少时，数据包达到距离也趋于减少，当小于 0 时，表明链路队列正在放大；数据包达到距离也在缩小；等于 0 示意数据包达到距离恒定。
Adaptive threshold 和 REMB-GCC ⼀样，即同公式 4。
Overuse Detector
依据上节计算出来的 mi 和阈值 γi 判断以后网络的状态，是否过载、低负载还是失常，依据网络状态确定接下来对带宽预计的调整，是减少、升高还是保留不变，这个和 REMB-GCC ⼀样。
Remote Rate Controller
这⾥依据 Overuse Detector 输入的后果，来调整估算带宽。与 REMB-GCC 不同的是，这里次要应用 AIMD 形式调整带宽，即当减少估算带宽时，能够柔和⼀些，也能够激进⼀些。
因为 TFB-GCC 会跟踪每次链路过载时的带宽，当以后理论接管带宽离之前链路估算带宽近时，须要减少带宽时，就应用柔和形式减少一些带宽，减少幅度小；
当以后理论接管带宽离链路带宽变差很大时，采纳激进形式减少带宽，即减少幅度大；
当辨认网络过载时，须要升高带宽，以以后理论带宽的 0.85 倍作为估算带宽。
最终基于延时预计计算出来的带宽为 Ari
基于丢包的网络拥塞带宽预计
这里和 REMB-GCC 的丢包网络拥塞预计一样, 为了避免基于延时预计生效，通过接收端反馈的 RR 来计算丢包率 fli，利用 fli 来预计拥塞状态，这里同样应用公式 9 来确定最终带宽 Asi，最终估算的带宽 Ai 计算如下：
公式 16：Ai = min(Asi, Ari)
TFB-GCC 算法总结
采纳此架构的 GCC 算法，因为估算带宽都放在发送端，不须要接收端的同步优化，不便后续版本的部署和优化。准确性和及时性绝对更高更好，同时应用 Trendline 滤波器，较 kalman 滤波器简略且准确性更高，灵敏性也更高。
因为思考了对每次过载时链路带宽的预计，在减少带宽时，体现得更加灵便和平安。
论文[4] 给出了 TFB-GCC 和 REMB-GCC 的一个带宽受限的比拟，能够看出 TFB-GCC 成果较 REMB-GCC 复原更快，追随链路带宽更精确，整体成果更好。
（TFB-GCC 与 REMB-GCC 比拟）
GCC 算法优化点
REMB-GCC 优化点
- 接收端应用 TrendLine 中的滤波器替换 kalman 滤波器
- 过载逻辑判断优化，剔除噪点引入误判
- 理论接管带宽优化
- 基于丢包拥塞预计分场景优化
- 基于提早预计带宽减少或升高计算算法优化
- 针对过载可能不会降带宽进行优化
- 针对当延时预计带宽始终处于回升，而理论接管带宽却起伏稳定，可能造成加大累计误差问题进行优化
- ……
TFB-GCC 优化点
- 依据 Transport-wide RTCP 报文，估算接管带宽优化
- Trendline 滤波器优化
- 依据 Transport-wide RTCP 包统计丢包率优化
- 延时预计中应用 RTT 优化
- 过载逻辑优化及阈值优化
- 过载可能被疏忽逻辑优化
- AIMD 带宽计算等相干逻辑优化
- 链路带宽预计优化
- 基于丢包拥塞带宽预计优化
- TFB-GCC 发送端⽀持接管 REMB 优化
- ……
参考资料：
[1] https://datatracker.ietf.org/…
[2] https://datatracker.ietf.org/…
[3] https://www.rfc-editor.org/rf…
[4] Congestion Control for RTP Media: a Comparison on Simulated Environment
[5] https://tools.ietf.org/id/dra…
