[Bug]: 在大BDP网络中，xqc_send_ctl_detect_lost引起quic性能变低

alibaba / xquic

XQUIC Library released by Alibaba is a cross-platform implementation of QUIC and HTTP/3 protocol.

Apache License 2.0

1.65k stars 326 forks source link

Closed linsy007 closed 12 months ago

linsy007 commented 1 year ago

xqc_send_ctl_detect_lost 函数遍历sndq_unacked_packets队列，检测某个报文是否丢失，当po->po_pkt.pkt_num > send_ctl->ctl_largest_acked[pns]时，可以不必检测后续的报文，可以直接break

通过把continue改为break后，系统quic传输性能有明显改善
从广州到北京IDC下载200MB文件
采用continue，吞吐率只有42MBps
改为break后，吞吐率提升到102MBps

coding-ha commented 1 year ago

为什么要break 呢

linsy007 commented 1 year ago

为什么要break 呢 quic的pkt_num是线性递增的，越大的pkt_num肯定越晚发送，所以当pkt_num大于largest_acked时，后面的报文是不会判断为丢失的。

coding-ha commented 1 year ago

为什么要break 呢 quic的pkt_num是线性递增的，越大的pkt_num肯定越晚发送，所以当pkt_num大于largest_acked时，后面的报文是不会判断为丢失的。

所以收到ack 的时候是要判断最大ack 包号之前的是不是丢了，最大ack 包号之后的unack 的包并不在这次的判断候选范围内？

coding-ha commented 1 year ago

即使continue 了，耗时是发生在哪儿呢？for 多了几次循环而已

adcen0107 commented 1 year ago

即使continue 了，耗时是发生在哪儿呢？for 多了几次循环而已

可不只有几次哦，若北京到广州的RTT达到100-200ms，那当时那个unacked packet queue有接近1000个大于largest_acked的包，这个消耗还是不小的

Kulsk commented 12 months ago

fixed on #287