WebRTC使用的是Google Congestion Control (简称GCC)拥塞控制，目前有两种实现：
- 旧的实现是接收方根据收到的音视频RTP报文, 预估码率，并使用REMB RTCP报文反馈回发送方。 * 新的实现是在发送方根据接收方反馈的TransportFeedback RTCP报文，预估码率。
个人技术博客： fuqifacai.github.io
更多技术资讯下载: 2img.ai
相关配图由微信小程序【字形绘梦】免费生成
基于延迟的拥塞控制原理
先来看下Google Congestion Control（GCC）的标准草案：https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02 结合草案，可以得知GCC是基于网络延迟梯度的拥塞控制算法，判断的依据如下图：
发送方发送两个包组的间隔为 ： Ds = Ts1 – Ts0
接收方接收两个包组的间隔为： Dr = Tr1 – Tr0
如果网络没有任何抖动，那么 [ delta = Dr – Ds ] 应该是一个恒定不变的值，但是现实中网络有抖动、拥塞、丢包等情况，所以delta也是一个抖动的值。 GCC通过测量delta，来判断当前网络的使用情况，分为 OverUse (过载)，Normal(正常)，UnderUse(轻载) 这三种情况。 有同学可能会问，发送方和接收方时钟不统一，怎么计算差值呢，需要做时间对齐或者NTP同步吗?
不需要，因为我们对比的是delta，只需要单位一致即可，举个例子: seq1的包 发送时间为 16000ms(发送方时钟)，接收时间为 900ms(接收方时钟) seq2的包 发送时间为 16001ms(发送方时钟)，接收时间为 905ms(接收方时钟) 那么延迟梯度delta=(905-900) – (16001-16000) = 4
Pacing和包组
值得注意的是，延迟梯度的判断是以包组为单位的，而且必须在发送方开启pacing发送, 有以下几点原因： 单个包测量误差会过大，基于包组的测量更能反应网络的情况。
burst发送容易冲击网络，影响测量的精度。 那么怎么判断哪几个包属于一个包组呢，非常简单，按发送方的pacing速率分包组。 WebRTC pacing默认是5ms一个包组，如下图所示
TransportFeedback RTCP报文
再来看看transport-feedback的包结构：https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
解析这个报文，我们可以得到下面的信息：
- 接收到的包seq和包的接收时间
- 丢失的包seq
- 可以看到本质上transport-feedback是接收方对数据的ACK，并且捎带了接收的延迟梯度。
Paragoger衍生者AI训练营。发布者：稻草人，转载请注明出处：https://www.shxcj.com/archives/6632
