GoogCcNetworkController : 整个 congestion_controller 模块的中心类，是对外的接口

AcknowledgedBitrateEstimatorInterface

AcknowledgedBitrateEstimator : 估算当前的吞吐量。

BitrateEstimator : 使用滑动窗口 + 卡尔曼滤波计算当前发送吞吐量。

RobustThroughputEstimator：更鲁棒的ACK码率(通过一段时间ack包数计算当前的吞吐量)估计。

Alr

ALR，即 Application Limit Region，即应用本身存在一些受限（非网络带宽导致），会导致发送码率相较于平常有较大降低。

突然存在一个较低的发送码率会导致我们的估计带宽存在一些偏差，因此我们需要对这样的一个场景去做检测和区别。

一般来说导致ALR的原因如：系统负载比较高，采集/编码帧率降低等等。

ALR的检测也比较简单，根据一段时间内发送的平均码率来判断，当前的码率是否偏离了正常的码率。

这个检测使用到了 pacing 中的 IntervalBudget 来检测，这是一个漏桶算法，每次发送数据消耗 budget，随着时间流逝增加 budget，最后通过查看 budget 剩余比例来判断发送数据量是否足够。

AlrDetector : 探测实际码率是否远低于目标码率

基于Loss的带宽估计

由于历史原因，基于丢包的估计在发送端，基于延迟（REMB）的估计在接收端。

因此基于丢包的代码在 SendSideBandwidthEstimation 里，基于延迟（REMB）的估计在 Remote 里。

有了新的基于延迟（Transport-CC）的估计，只能放到 DelayBasedBwe 里。

SendSideBandwidthEstimation: 发送端带宽评估。

• 结合了 LossBasedBandwidthEstimation 和 DelayBasedBwe 的评估结果，还有接收端通过 RTCP REMB/TMMBR 消息报告的带宽评估值，通过这几个值的比较得到 current_target_，current_target_ 就是接收端的带宽评估值。这个值最终会作用到pacing模块还有编码模块。
• 90版本（版本号通过src目录下的README.chromium查看）的webrtc的带宽评估都是通过发送端来实现的了，听说以前版本的 delay_based 的算法是由接收端实现，得到带宽评估值后再通过 RTCP REMB 消息反馈给发送端。

LossBasedBandwitdhEstimation : 基于丢包的带宽评估

基于延迟的带宽估计

DelayBasedBwe : 基于延迟预估码率

InterArrival : 计算包组的发送时间差，接受时间差，字节差等。不会得出拥塞结果。

SendTimeGroup : 包组的定义，WebRTC 以包组进行划分计算延迟。

TrendlineEstimator : 将 InterArrival 的输出当作输入，使用最小二乘法计算延迟趋势，评估网络状态。

AimdRateControl : 通过 TrendLine 预测出来的网络状态对码率进行aimd方式调整。

其他

ProbeBitrateEstimator : 根据 feedback 计算探测码率，PacingController 中会将包按照 cluster 进行划分，transport-CC 报文能得到包所属的 cluster 以及发送和接收信息，通过发送和接收的数据大小比判断是否到达链路上限从而进行带宽探测 (探针算法)

ProbeController : 探测控制器，通过目标码率判断下次是否探测，探测码率大小

CongestionWindowPushbackController : 基于当前的 rtt 设置一个时间窗口，同时基于当前的码率设置当前时间窗口下的数据量，通过判断当前窗口的使用量，如果使用量过大的时候，降低编码时使用的目标码率，加速窗口消退，减少延迟

NetworkStateEstimator 、 NetworkStatePredictor ： 此两者属于待开发类，只是在代码中有，但是还没开发完，没用上