WebRTC的拥塞控制方式主要有以下几个：Transport-cc、BBR-congestion、remb（BBR已被google从webrtc移除了）。mediasoup支持Transport-cc和remb。
一、前言
实时通信的延时指标
视频服务质量指标
音视频服务质量与带宽之间的矛盾、实时性与服务质量之间存在矛盾
提高服务质量的因素
影响网络质量的因素
影响网络质量的因素
丢包率(重点)
延时拥塞有关)
抖动(JitterBuffer、NetEQ)
乱序(JitterBuffer、NetEQ )
链路质量差、带宽满、主动丢包、光纤被挖
解决丢包的方法：NACK、FEC。如果RTT很长就不要用NACK，就用FEC。带宽充足的情况下可以用FEC，但是丢包因为网络拥塞不能用FEC，会加重拥塞。
NACK
丢包了不会立刻去请求而是会等一段时间，10ms-20ms通过RTCP的Nack，告诉发送端，然后发送端从发送历史记录中根据号找，然后再找到发过来。
一、webRTC拥塞控制算法
减少数据量、适当增加时延和更准确的带宽评估被统称为拥塞控制
WebRTC中包含多种拥塞控制算法：
- GCC：（Google Congestion Contro，Google拥塞控制）GCC根据其实现⼜可细分为基于发送端的拥塞控制算法Transport-CC（Transport-wide Congestion Control，传输带宽拥塞控制）和基于接收端的拥塞控制算法Goog-REMB（Google Receiver Estimated Maximum Bitrate Google接收端评估的最⼤码流）
- BBR：（Bottleneck Bandwidth and Round-trip propagation time），瓶颈带宽和往返传播时间
- PCC：（Performance-oriented Congestion Control），基于性能的拥塞控制。
重点关注一下GCC
二、GCC
2.1 Goog-REMB
⼀种是接收端的延时拥塞控制算法
Receiver Estimated Max Bitrate (REMB) 是一种RTCP 反馈消息，作为接收方，告诉发送方它可以接收的带宽是多少。发送者不知道接收方的带宽情况，它需要有一个机制由接收方告诉它有多少带宽可供传输, 这样发送方可以根据这个估计的带宽来调整分辨率(90p, 180p, 360p, 720p等)和帧率(每秒24, 30, 40, 60帧等)
RemoteBirate Estimator模块：它是接收端延时拥塞控制算法的管理模块，即“总负责⼈”。
Inter Arrival模块：将数据包按帧进⾏分组，然后对相邻的两组数据包进⾏单向梯度计算
OverUse Estimator模块：它利⽤Inter Arrival模块的计算结果，通过卡尔曼滤波器估算出下⼀时刻发送队列的增⻓趋势。
OverUse Detector模块：⽤于检测当前网络的拥塞状态。
AIMD Rate Controller：该模块⽤于计算发送码流大小。它通过OverUse Detec tor模块检测出的当前⽹络状态来变更⾃⼰的状态，并计算出发送码流的大小。
2.2 Transport CC
⼀种是发送端的延时拥塞控制算法【未完待续】
参考：流媒体学习之路(mediasoup)——拥塞控制分析
WebRTC 拥塞控制之 REMB - 接收方带宽估计
