gcc算法在局域网环境下，在高带宽下无法正确测出链路带宽的最大值，低带宽(拥塞)时可以测出，求大佬们指点一下🙏🏻

[Antinust]

环境：两台iPhone手机，手机A(发送端)开热点，手机B(接收端)连上A开的热点，手机A的发送程序通过udp给手机B的接收程序不断发数据。 测试1： 测试高带宽，手机端A不限速 经测试不同的START_SEND_BITRATE对带宽预测值有影响，测试数据如下： START_SEND_BITRATE: 3200K 最终预测带宽3572Kb START_SEND_BITRATE: 2400K 最终预测带宽2736Kb START_SEND_BITRATE: 1600K 最终预测带宽1890Kb

用测速工具测出手机B端网速：上行 2-4Mbps，下行 20-40Mbps；手机A端网速：上行 4-6Mbps，下行 20-40Mbps；

推测这个预测值与aimd_rate_control中的clamp_bitrate中限制max_bitrate_bps为coming_rate的1.5倍有关，这里为什么要设置成1.5倍？实际测试中不知道为啥coming_rate这个值最终稳定在60-90Kbps左右。

测试2： 测试低带宽，手机端A限速3Mbps，预测的带宽会不断地升和降 test1：起始设置成1.6M，到达2.8M后，下降到78K；之后上升到1.58M，下降到60K；之后又上升到96k，下降到66K；之后上升到144k，下降到77k；又上升到1.5M，下降到67K；又上升到1.49M，下降到63K； test2：起始设置成2.6M，13秒后恢复到277K，后续不断升降。

[yuanrongxi]

要看你发送测试数据的时候有没还有抖动和乱序，因为 GCC 是感觉发送间隔时间来判断网络拥塞的，如果有大抖动和乱序，就会认为是拥塞了。

[biehualihushao]

其实这涉及到TCP协议的拥塞控制机制：在网络发生拥塞时TCP会降低传输速率从而避免网络崩溃，低带宽下自动调整速率会导致带宽的准确测量出现问题，而GCC算法的测量原理是测量多个数据流的RTT和空闲时间，用来估计链路带宽，高带宽下数据包的到达时间非常短，所以空闲时间也很短，导致测量带宽不准确。

你这个测量一的问题，限制max_bitrate_bps是coming_rate的1.5倍可能就是为了避免网络负载过程发生拥堵，在coming_rate大于max_bitrate_bps的1.5倍时，算法将max_bitrate_bps限制为coming_rate/1.5，避免过多的数据包在网络中传输导致拥塞。根据动态因素的不同，coming_rate的值可能会相应受到影响。 至于测试的不同上下行带宽数据，就要根据你选择的测试工具来看了，可能是参数的原因。

测试二的话从测试结果预测带宽不断地升降可能与AIMD控制策略有关，如果网络数据包传输速率超过了当前的带宽预测值，算法就会降低预测带宽的值，避免拥塞，反之则会提升。可以尝试优化调整带宽限速策略或选择其它的网络优化工具再进行尝试。

[darkterrorooo]

在局域网测试，发现 gcc 基于延迟的算法没有起什么作用，起作用的是基于丢包的算法。猜测与 wifi 的特性有关，有朋友在局域测试发现过基于迟延的算法起作用吗？