feat: Add support for hysteria2 dialer and protocol

[mnixry]

Background

ref: daeuniverse/outbound#9

This PR is currently a draft and needs user feedback to move forward. Users interested in testing this feature are encouraged to use the GitHub Action build.

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 Hysteria2 protocol support.

Issue Reference

Closes #48
Closes #450

Test Result

This feature should be tested by end user.

[douglarek]

This is a highly anticipated feature support, extremely impressive. It has passed the test on my Linux (kernel 6.9), although there seem to be some warning logs, I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

[xmapst]

This is a highly anticipated feature support, extremely impressive. It has passed the test on my Linux (kernel 6.9), although there seem to be some warning logs, I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

是的 在openwrt上运行也出现这种情况 但不影响正常使用

[mnixry]

I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

@douglarek @xmapst Thank you for your feedback. I plan to address this issue shortly, likely by Wednesday or Thursday. Should you encounter any additional problems during extended use, please don't hesitate to follow up.

During my personal usage, I've encountered a few issues:

• Subpar HTTP/3 performance is expected with UDP-over-TCP proxy methods; however, it shouldn't be the case for protocols like Hysteria2 that utilize QUIC and connection multiplexing. The source of this problem is unclear to me, and I lack the expertise to diagnose and debug it. (I'll later compare this with the official client to determine whether the issue is on our end or a more widespread problem.)

[Integral-Tech]

It works on Arch Linux, kernel 6.9.3-arch1-1.

[mzz2017]

@mnixry For the udp over tcp problem, could you please revert my patch on your local and test it again?

[douglarek]

This is a highly anticipated feature support, extremely impressive. It has passed the test on my Linux (kernel 6.9), although there seem to be some warning logs, I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

The current implementation has too high of a delay. The same server is simultaneously configured with tuic (sb implementation) and hy2 (original version). The udp4(DNS) delay results for dae, the former is between 1~4s, while tuic is around 200ms.

[mnixry]

For the udp over tcp problem, could you please revert my patch on your local and test it again?

@mzz2017 Reverting the patch did not resolve the issue for me. Further testing indicates that both the official client and the sing-box implementation exhibit similar problems, suggesting that the issue may not lie with the Hysteria2 dialer.

Here's my benchmarking method:

• Install a curl build with HTTP/3 support, such as the one available at https://github.com/stunnel/static-curl.
• Use the following command for benchmarking:

  ./curl -L4v --http3-only "https://h3.speed.cloudflare.com/__down?bytes=25000000" > /dev/null

• The following 4 benchmarks were conducted:
  1. Running on dae with the built-in Hysteria2 dialer provided in this PR. The download speed peaks at 30kB/s, then drops to 0b/s, and continues to fluctuate between 30kB/s and 0b/s.
  2. Running on dae with an external sing-box, connected via socks5 protocol. The behavior is the same as above.
  3. Running on dae with an external apernet/hysteria client, connected via socks5 protocol. The behavior is the same as above.
  4. Running on dae with an external apernet/hysteria client with bandwidth provided (i.e., enabling the brutal cc algorithm), the speed remains at 30kB/s without dropping or increasing.

Since curl does not support directly using a socks5 proxy with the HTTP/3 protocol, I am currently unable to provide examples without using dae. Additionally, testing under various network conditions is also needed.

[mzz2017]

@mnixry You can use curl -x http://YOUR_PROXY or curl -x socks5://YOUR_PROXY to achieve

[mnixry]

You can use curl -x http://YOUR_PROXY or curl -x socks5://YOUR_PROXY to achieve

@mzz2017 Sadly, this approach does not work for curl with HTTP/3 protocol.

$ ./curl -L4vx socks5://localhost:2080 --http3-only "https://h3.speed.cloudflare.com/__down?bytes=25000000" > /dev/null
* HTTP/3 is not supported over a SOCKS proxy
* Closing connection
curl: (3) HTTP/3 is not supported over a SOCKS proxy

I am also wondering if there is any networking tools like curl supports h3 over socks5 proxy.

ref: https://github.com/curl/curl/blob/267c3b31e911dc96c2445c0342bab7b827f9c0a8/lib/vquic/vquic.c#L653-L656

[mzz2017]

@mnixry What about sing-box tun inbound with auto-route?

[mnixry]

What about sing-box tun inbound with auto-route?

@mzz2017 The TUN mode in Sing-box appears to function well with HTTP/3 connections, progressively increasing speeds up to approximately 1 MB/s. Interestingly, even when using UDP-over-TCP proxy solutions, HTTP/3 downloads perform significantly faster than dae (also about 1 MB/s).

Could you reproduce these results on your end? Since this appears to be unrelated to the current pull request, we should probably open a new issue for tracking purposes.

[mnixry]

The current implementation has too high of a delay. The same server is simultaneously configured with tuic (sb implementation) and hy2 (original version). The udp4(DNS) delay results for dae, the former is between 1~4s, while tuic is around 200ms.

@douglarek Apologies for the delayed response. I'm unable to replicate the issue on my side; it might stem from network jitter or a delay due to initial protocol handshaking.

Could you try using tools such as 'dig' from BIND to assess any DNS resolution delays?

[mzz2017]

@mnixry I'll look into it as long as i'm free.

[mnixry]

I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

是的 在openwrt上运行也出现这种情况 但不影响正常使用

@douglarek @xmapst The issue has been fixed in f2d5302. Could you check out the latest build and confirm whether the warning still persists?

[douglarek]

I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

是的 在openwrt上运行也出现这种情况 但不影响正常使用

@douglarek @xmapst The issue has been fixed in f2d5302. Could you check out the latest build and confirm whether the warning still persists?

It's indeed fixed, the warn log has disappeared. This is so awesome.

[xmapst]

I'm not sure if it matters: level=warning msg="handleConn: handleTCP relay error: deadline exceeded". However, it doesn't affect the basic proxy experience.

是的 在openwrt上运行也出现这种情况 但不影响正常使用

@douglarek @xmapst The issue has been fixed in f2d5302. Could you check out the latest build and confirm whether the warning still persists?

太棒了 确实修复了

[mzz2017]

The TUN mode in Sing-box appears to function well with HTTP/3 connections, progressively increasing speeds up to approximately 1 MB/s. Interestingly, even when using UDP-over-TCP proxy solutions, HTTP/3 downloads perform significantly faster than dae (also about 1 MB/s).

@mnixry I fixed a possibly related problem that caused download speed zeroing. The problem dies away on my local. Could you please try this PR? #539

[xmapst]

进展如何了? 大概什么时候合并?

[mnixry]

进展如何了? 大概什么时候合并?

@xmapst I believe there are two things blocking:

1. Wait for the merge of fix: incidental packet drop and weird UDP state maintaining #539 to confirm that stateful UDP connections function properly.
2. Require more user testing. I'd like to wait ~1 week to ensure that this build operates without any additional issues.

However, members of the daeuniverse who determine if this PR will ultimately be merged may hold different opinions.

[xmapst]

进展如何了? 大概什么时候合并?

@xmapst I believe there are two things blocking:

1. Wait for the merge of fix: incidental packet drop and weird UDP state maintaining #539 to confirm that stateful UDP connections function properly.
2. Require more user testing. I'd like to wait ~1 week to ensure that this build operates without any additional issues.

However, members of the daeuniverse who determine if this PR will ultimately be merged may hold different opinions.

好的 感谢告知

[mzz2017]

Ready to merge

[dae-prow]

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