WebRTC 中带宽估计与拥塞控制算法

WebRTC 中的带宽估计与拥塞控制算法有很多,以下是其中几种:

- GCC(Google Congestion Control):基于丢包的带宽估计,其基本思想是根据丢包的多少来判断网络的拥塞程度。丢包越多则认为网络越拥塞,发送速率就需要降低;如果没有丢包,则说明网络状况较好,可以提高发送码率以探测是否有更多的带宽可用。

- Goog-REMB:基于接收端的延迟算法,利用延迟值,通过卡尔曼滤波器估计出下一时刻的网络带宽趋势。但效果的准确性和公平性不如 Transport-CC,目前已经被 WebRTC 的新版本所淘汰。

**- Transport-CC:**基于发送端的延迟算法,也是利用区间延迟值,通过 TrendLine 滤波器(最小二乘法滤波器),通过斜率的增加或者减小来判断当前网络的拥塞状况。

Transport-CC将拥塞评估算法从接收端移动到了发送端,是通过接收端记录数据包到达时间,构造相关RTCP包,然后反馈给发送端,在发送端做带宽估计,从而进行拥塞控制实现的。这样做除了方便维护,也增加了相关算法的灵活性,因为大多数处理逻辑都放到了发送端。

**- BBR:**一种基于模型的拥塞控制算法,BBR 的模型包括两个显式估计参数:Bottleneck Bandwidth(瓶颈带宽)和 Round Trip Propagation Delay(双向往返传播延迟)。BBR 使用其模型寻找具有高吞吐量的操作点和低延迟,以在最佳工作点附近工作,系统需要保持两个条件:Rate Balance(最大发送速率)和 Full Pipe(BDP = BBR.BtlBw * BBR.RTprop)。

这些算法在 WebRTC 中都有广泛的应用,具体使用哪种算法取决于实际需求和网络状况。

相关推荐
三十_A16 分钟前
WebRTC 入门:一分钟理解会议系统的三种架构(Mesh/SFU/MCU)
架构·webrtc
qq_3106585119 小时前
webrtc源码走读(五)核心引擎层——传输模块
服务器·网络·音视频·webrtc
三十_1 天前
WebRTC 入门:一分钟理解会议系统的三种架构(Mesh/SFU/MCU)
前端·后端·webrtc
qq_310658511 天前
webrtc源码走读(六)核心引擎层——安全模块
服务器·c++·音视频·webrtc
REDcker1 天前
WebRTC-HTTP 出口协议 (WHEP) draft-murillo-whep-01 中文翻译
网络协议·http·webrtc
qq_310658511 天前
webrtc源码走读(七)核心引擎层——Qos模块
服务器·c++·音视频·webrtc
xiejiashu1 天前
大小仅1M,WebRTC原生SDK(EasyRTC)即将发布,免费
webrtc·webrtc原生sdk·webrtc c sdk·webrtc c++ sdk·webrtc安卓sdk
qq_310658512 天前
webrtc源码走读(八)系统接口层
服务器·c++·音视频·webrtc
qq_310658514 天前
webrtc源码走读(四)核心引擎层——视频引擎
服务器·c++·音视频·webrtc
qq_310658514 天前
webrtc源码走读(三)核心引擎层——音频引擎
服务器·c++·音视频·webrtc