WebRTC GCC拥塞控制表现数据详测记录

本文主要对WebRTC的GCC拥塞控制机制进行一些分析，并记录一些数据， 对其拥塞控制有个定量的认识。

1. 测试版本 M126

2. 带宽容量限制 - Link Limit

可以看到 WebRTC在带宽容量限制场景下， 带宽容量的预估还是比较准确的，1000kbps，500kbps, 200kbps下基本都可以估测到 90%以上，基本占满了带宽容量，表现相当不错，可提升的空间基本没有。

3. 带宽抢占 UDP vs TCP

仅测试WebRTC与TCP的带宽抢占场景，总带宽容量限制在 800kbps, 在视频通话过程中通过TCP上传文件的方式模拟带宽抢占。

可以看到引入TCP后，UDP带宽迅速下降，基本被按在地上。停止文件上传后，UDP带宽慢慢爬升恢复。

测试平台为 MacOS，可能MacOS内核的TCP拥塞控制算法处理的较好，带宽抢占能力还是比较强的，WebRTC表现一般，在此中场景完败。

这个结果也说明了在视频通话过程中不要上传文件，或者通过微信发送大的文件等等有上传类型的操作。

WebRTC如果要能够抢占带宽，付出的成本也比较大，就是要在因带宽抢占照成丢包的情况下，大量重传丢失的包，基本上能抗过10 - 15%的丢包就可以竞争过TCP。

但是显然 WebRTC认为有一定丢包网络就出现了网络拥塞了，适当的去降低发送码率，以减缓网络拥塞。因为区分网络拥塞和带宽竞争还是挺难的，所以这块不是很好处理。

4. 丢包场景

带宽容量限制在 800kbps，添加随机丢包，在 15%左右的时候，GCC基本趴在地上了。这也验证了WebRTC处理网络拥塞的基本思想，网络丢包到一定程度认为网络拥塞了，就降低发送码率，以减缓网络拥塞。

具体丢包容忍数据在webrtc源码中最大是 10% 的丢包。

5. 网络拥塞优化建议

个人感觉WebRTC的网络拥塞处理策略和表现已经非常好了，能够比较精准的预估网络容量。之所以带宽容量利用率可能没有TCP高，是因为其发送数据来自于编码器，是实时变化的，并不能要多少就有多少数据可以发。

其对丢包的处理也是非常合理的，毕竟网络纯丢包的场景个人认为非常少，大部分还是因为网络带宽容量不够，所以产生的丢包。

所以有RTC厂商声称可以做到抗 网络丢包 70%，甚至更高丢包场景下依然流畅通信实际是没有意义。他们声称的抗丢包是在网络带宽不受限的场景下的表现。一旦网络带宽不足，依然疯狂重传丢失的包只会让网络拥塞变的非常糟糕。

所以这也仅仅是一个唬人的数据，一旦到线上生成环境，表现是十分糟糕的，优化的方向就错了。

大家可以测测腾讯会议在带宽 200kbps场景下的表现，基本用不了，腾讯会议的拥塞控制还是偏向抗丢包的。

6. 有意思的事

在测试过程中，iPhone通过数据线和Mac连接，两者会通过数据线传输网络数据，手机和Mac会虚拟一个网卡，而且IP还是一个美国的IP地址。

抓包