期待能够感知到当前链路RTT,丢包率等状态

[justchen]

在实时直播中,如果能够在应用中感知当前链路RTT/RTO及丢包率时,可以及时调整编码码率以适应用当前网络状况,这个很有用,所以希望能有API感知当前链路详细状态.
另外现在是使用c api来测试.希望官方能将C API更加完善化.

[glime-ai[bot]]

TQUIC提供了丰富的API接口，包括多路径传输、拥塞控制算法等，以支持高性能和高可靠性的传输需求。对于您提到的实时直播场景中，感知当前链路的RTT（Round-Trip Time）、RTO（Retransmission Timeout）及丢包率，以便及时调整编码码率以适应当前网络状况的需求，TQUIC的API文档中并未直接提及具体的接口能够直接获取这些信息。

然而，TQUIC支持多种拥塞控制算法，如CUBIC、BBR等，这些算法的实现本身就是为了根据网络状况（包括RTT、丢包等信息）动态调整传输速率。虽然文档中没有明确指出有直接获取RTT、RTO或丢包率的API，但是通过正确配置和使用TQUIC提供的拥塞控制算法，可以间接达到根据网络状况调整传输策略的目的。

关于希望官方能将C API更加完善化的部分，由于TQUIC是开源项目，建议您可以直接在其GitHub项目页面上提出issue或者参与到项目贡献中来。开源社区的力量可以帮助TQUIC不断完善和改进。

最后，对于实时直播这样的应用场景，除了关注网络层面的指标外，还需要综合考虑编解码效率、应用层协议优化等多方面因素。TQUIC作为传输层协议库，能够提供强大的传输性能支持，但实现最佳的直播体验还需要在应用层做进一步的优化和调整。

[iyangsj]

@justchen 后续版本计划支持。目前已有的链路统计指标参见：
https://github.com/Tencent/tquic/blob/develop/src/connection/recovery.rs#L981

[iyangsj]

调用Path::stats()接口，返回的是调用时刻对应的pacing_rate
（注：recovery模块本身是实时计算pacing_rate的，仅在调用接口Path::stats()时，才将最新值复制到PathStats结构中）

[stopandjoin]

谢谢！ 我在0.8.0版本基础上修改，在stats成员中添加了pacing_rate：

带宽估计一般如何计算，用pacing_rate * rttvar 吗。 可以在每次调用Path::stats() 接口时计算一次吗， 还是需要一段时间内的pacing_rate平均值 * rttval平均值？

[iyangsj]

这里的pacing_rate的单位是bps，可以使用这个值

注：以BBR算法为例，pacing_rate根据近期的估计的带宽*增益系数来计算
https://github.com/Tencent/tquic/blob/develop/src/congestion_control/bbr.rs#L440-L450

[stopandjoin]

@iyangsj 测试了一下这个 pacing_rate，发现在持续发包时，还比较准确，在暂停一段时间发包后，这个值就降得很低了， 没法表示真实带宽情况。 有什么建议吗？

[iyangsj]

取决于你所使用的CC算法和应用场景需求，没有one-fits-all的做法