端到端传输链路上的时延

[stopandjoin]

请教一下，默认情况下，tquic stream的发送端和接收端的内部有多大的buffer，最多会产生多大的时延？
我在自己的项目发现一种情况，两条stream A 和 B，优先级A高于B， A和B同时发送数据， 保证发送端都正常写入了（quic_stream_write 返回正确）。弱网情况下， 在接收端，stream A收到数据没什么明显的时延， 但是stream B，接收到数据时，时延很大（可以达到10秒以上），可能是哪里缓冲住了这么久吗？

[iyangsj]

@stopandjoin 发送端只要可发送，就会发送当前已缓冲端数据。把完整的debug级别日志发出来看看。
看起来发送端由于受到流量控制/拥塞控制限制，导致无法发送（例如弱网环境下流控窗口更新帧，或确认帧持续出现丢包重传）。

[stopandjoin]

好的，我复现一下抓个日志。

[stopandjoin]

@iyangsj 复现概率非常低，发现是在网络带宽非常低的时候出现的，应该就是你推测的“确认帧持续出现丢包重传“”。
这种情况下，有什么优化建议吗？ 比如调节发包的大小是否能有改善。

[iyangsj]

可以添加微信iyangsj讨论

[stopandjoin]

tquic_client.txt

[stopandjoin]

tquic_server.txt

[stopandjoin]

@iyangsj 复现了一次，以上是两端的tquic日志， 时间点在18:21 前后。

[stopandjoin]

找到了复现路径： 将带宽限制到很低，1Mbps以下然后连接。 刚连接上前2分钟内，很容易复现。 可能是写到tquic 内部buffer中的数据在慢慢发送。 我们现在是实时音视频场景，看tquic的api，好像没有主动清理掉 tquic 内部的buffer的接口。 是否还有其他办法。
刚有复现到一次，log如：
0802_server.log
0802_client.log

[stopandjoin]

了解啦。不过业务需求是A优先级要最高。 较低优先级的数据，时延是没法保证吧，那有没有接口，可以把这条流的buffer设置小一点？这样可以在业务层主动丢包。 @iyangsj

[stopandjoin]

@iyangsj 或者能不能只对延时大的这条stream 执行RESET_STREAM ，然后重新建立？

[iyangsj]

使用shutdown_stream 可以强制Reset关闭流

[iyangsj]

了解啦。不过业务需求是A优先级要最高。 较低优先级的数据，时延是没法保证吧，那有没有接口，可以把这条流的buffer设置小一点？这样可以在业务层主动丢包。

后续版本会增加相关接口

[stopandjoin]

使用shutdown_stream 可以强制Reset关闭流
我尝试过了，shutdown stream后， 使用相同 id 重新 new stream， 但是不成功。代码中这个逻辑会影响吧：

后续版本会增加相关接口
如果我们自己修改tquic代码，新增这个接口，需要改哪个地方，是不是设置一下这个max_data：

@iyangsj

[stopandjoin]

新发现一个问题：在client端关闭stream调用 quic_stream_shutdown 会偶尔失效，表现情况有两种：
1，server端可以收到 stream closed 回调， 但是 client端没有 stream closed 回调。stream实际断了。
2， 两端都没有 stream closed 回调。stream依旧保持着。

client端调用方法：
int ret_w = quic_stream_shutdown(mConn,id,QUIC_SHUTDOWN_WRITE,0);
int ret_r = quic_stream_shutdown(mConn,id,QUIC_SHUTDOWN_READ,0);

[stopandjoin]

@iyangsj 补充一下信息，tquic版本是0.8.0， client和server两端都是Android平台，NDK 23