fix: incidental packet drop and weird UDP state maintaining

[mzz2017]

Background

ebpf drop

The past two PRs #493, #505 have introduced a weird problem: erroneous UDP status maintenance will occur when a large number of concurrent messages are sent.

This results in some packets of stateful udp connection being incorrectly sent directly (such as what should be proxied and sent to dae control plane), resulting in sporadic packet drop. May be relevant: #533 (comment).

This problem is particularly likely to be triggered when the original traffic is udp and the throughput is large, such as http3 traffic and bt traffic.

Although I haven't fully verified, this fix may incidentally resolve the DNS leak issue.

unordered udp packets

The data which should be in order will be handled as unordered by dae, which may cause more resources by quic to process.

Checklist

• The Pull Request has been fully tested
• There's an entry in the CHANGELOGS
• There is a user-facing docs PR against https://github.com/daeuniverse/dae

Full Changelogs

• [Implement ...]

Issue Reference

Closes #513

Test Result

NA

[dae-prow]

❌ Your branch is currently out-of-sync to main. No worry, I will fix it for you.

[mnixry]

Thank you! The fix has been confirmed to work effectively in my local tests. HTTP/3 connections are now able to maintain a reasonable speed.

In real-world scenarios, HTTP/3 now enables smooth playback of 4K videos at 60fps on YouTube without buffering, a feat that was nearly impossible before.

[mnixry]

Further testing has shown that HTTP/3 upload speeds still drop to zero after a short time. The following command can be used to establish a benchmark for this issue:

./curl -X POST --form file=@/tmp/test.bin -Lv --http3-only "https://h3.speed.cloudflare.com/__up" > /dev/null

The results from https://h3.speed.cloudflare.com/ also indicate there is a problem:

[jschwinger233]

Maybe also fix #513? Orz

[mzz2017]

Further testing has shown that HTTP/3 upload speeds still drop to zero after a short time.

@mnixry Thanks for your rapid feedback. I have reproduced this problem.

[mzz2017]

I observed an interesting phenomenon. Like yours, the data sending was stuck after sending 1023K.

[mzz2017]

@mnixry It seems that the data should be in-order and dae handle all packets as unordered. I'll fix it soon.

[mzz2017]

@mnixry I've pushed a commit a0a1ace that may fix the problem. Could you please take a try?

[dae-prow]

🧪 Since the PR has been fully tested, please consider merging it.