Replace quic-go with uQuic

[ll11l1lIllIl1lll]

我没有找到支持 bbr 的 quic-go ，当然 uQuic 好像也没有 bbr 。
没什么关系，只是顺便提一下而已

[Fangliding]

这个uquic依赖会让二进制大小膨胀9%(约等于把本来史的quic-go复制一遍) 我加个acme多6%都嫌依赖重了 用acme的绝对比用splithttp的多(我都没见过拿这个当主力的) 感觉直接用quic-go就行了
顺便客户端哪怕有bbr也用处不大 要服务端有才行

[yuhan6665]

个人意见：acme 是可有可无所以不倾向加
uquic 考虑到 quic 的长远发展（不是近期的封锁） 应该跟 utls 一样是一个必要依赖 咱们可以把 quic-go 完全迁移了？

[Mfire2001]

This uquic dependency will increase the binary size by 9% (equivalent to duplicating the original quic-go). I think adding acme for an extra 6% is too much of a dependency. There are definitely more people using acme than splithttp (I have never seen anyone using it as the main source). I think it is enough to just use quic-go. By the way, even if the client has bbr, it is not very useful unless the server has it.

Maybe add flags when building?like sing box, *ray could have --with-acme or --with-uquic or somthing like this,since like u said not a lot of people will use them

[yuhan6665]

This uquic dependency will increase the binary size by 9% (equivalent to duplicating the original quic-go). I think adding acme for an extra 6% is too much of a dependency. There are definitely more people using acme than splithttp (I have never seen anyone using it as the main source). I think it is enough to just use quic-go. By the way, even if the client has bbr, it is not very useful unless the server has it.

Maybe add flags when building?like sing box, *ray could have --with-acme or --with-uquic or somthing like this,since like u said not a lot of people will use them

我们需要考虑降低项目复杂度

[RPRX]

可以用 uquic 替代 quic-go，希望 uquic 库的维护活跃 @gaukas

[RPRX]

uquic 可以 release 一个今年的新版吗

[gaukas]

可以用 uquic 替代 quic-go，希望 uquic 库的维护活跃 @gaukas

I would definitely love to!

Currently we have been deliberating on the future development of uQUIC (as it is an important part of our research on TLS/QUIC fingerprint-ability). We have realized that uQUIC as a popular QUIC clients' parrot would definitely face the same amount of challenges, if not more, as uTLS did.

It is important to note that the Initial Packet(s) containing a TLS Client Hello isn't the only fingerprint-able feature in QUIC. To be honest with you all, it would be overall challenging to keep up-to-date with all the tweaking being implemented on popular QUIC clients. For example, most-recent change on Chrome has enabled post-quantum x25519kyber768 as one of its default key share algorithm, which hugely bloated the size of TLS Client Hello (as you all should have heard about) and makes it exceeds the size limit of one QUIC packet (which is ~1200B). The resulting TLS Client Hello is being split into first two Initial Packets. Non-standard behavior like such will consequently require major updates being implemented for uQUIC.

The author of quic-go has expressed the unwillingness on taking fingerprint-ability into account (quic-go/quic-go#4007 (comment)), and I would ask for help from our good open source community, especially those who concern about anti-censorship.

---

我当然乐意！

目前，我们一直在讨论 uQUIC 的未来发展（因为它是我们 TLS/QUIC 可指纹性研究的重要组成部分）。我们意识到，uQUIC 作为流行的 QUIC 客户端鹦鹉，肯定会面临与 uTLS 相同甚至更多的挑战。

值得注意的是，包含 TLS Client Hello 的 Initial Packet(s) 并不是 QUIC 中唯一可被指纹识别的特性。说实话，要跟上流行 QUIC 客户端的所有调整，总体上是一项挑战。例如，Chrome 浏览器最近的一次改动启用了后量子签名算法
x25519kyber768 作为默认 KeyShare 算法之一，这极大地膨胀了 TLS Client Hello 的大小（你们应该都听说过），使其超过了一个 QUIC 数据包的大小限制（约 1200B）。由此产生的 TLS Client Hello 将被拆分进前两个 Initial Packet。这样的非标准行为导致我们需要对 uQUIC 进行主要更新。

quic-go的作者已经表示不愿意将指纹识别能力考虑在内 (quic-go/quic-go#4007 (comment)) ，所以我希望向我们优秀的开源社区寻求帮助，尤其是那些在乎反审查的人们。

[gaukas]

uquic 可以 release 一个今年的新版吗

Most likely it will happen at some point after September. As I mentioned we will need major updates to mimic some new behaviors.

---

最有可能在 9 月之后的某个时间点进行。正如我提到的，我们需要进行主要更新以模仿一些新的行为。

[RPRX]

所以现在指纹是只有 chrome 和 firefox 吗，transport/internet/splithttp/dialer.go 这个文件需要 fmt 一下

[RPRX]

打算合并另外两个 PR 后再继续这个 PR，如果我们不想用去年的 v0.0.5，@gaukas 有推荐的 commit 吗？

[gaukas]

打算合并另外两个 PR 后再继续这个 PR，如果我们不想用去年的 v0.0.5，@gaukas 有推荐的 commit 吗？

既然如此，我可以创建新的 tag v0.0.6 以供使用。不过请留意，当前版本仍然缺乏对部分已知特征的模仿。因此直至我们的初期工作完成我都并不鼓励大规模的应用 uQUIC。一旦我们认为 uQUIC 已经有足够的基础功能，我们将会释出 v0.1.0 作为首个生产版本。

---

If you say so, I can create a new tag v0.0.6 for you to use. Please be advised, the current build still lacks mimicry on certain known patterns. As a result, I do not encourage large-scaled application of uQUIC until our preliminary work is done. Once we determined that uQUIC has enough basic features we would release v0.1.0 as our first production-ready version.

[RPRX]

我可以创建新的 tag v0.0.6 以供使用

感谢

当前版本仍然缺乏对部分已知特征的模仿

只要 Client Hello 看着一样就行

[RPRX]

@mmmray 请修复这个 PR，使用 uquic v0.0.6，还有 #3550 (comment)

[RPRX]

quic-go 仍然存在

[Fangliding]

没办法依赖路径里有( 不知道replace能不能编出来

[mmmray]

I think the transport/quic test failure is way over my head. I don't recommend pushing this in 1.8.20 today unless it's obvious to somebody what's happening.

[yuhan6665]

Agree, we can study it later

[RPRX]

=== RUN   TestQUICNameServer
2024/07/19 18:06:56 [Info] app/dns: Localhost got answer: google.com -> [172.253.122.138 172.253.122.139 172.253.122.102 172.253.122.113 172.253.122.100 172.253.122.101]
2024/07/19 18:06:56 localhost got answer: google.com -> [172.253.122.138, 172.253.122.139, 172.253.122.102, 172.253.122.113, 172.253.122.100, 172.253.122.101] 9.3086ms
2024/07/19 18:06:56 [Info] app/dns: DNS: created Local DNS-over-QUIC client for quic://dns.adguard.com
2024/07/19 18:06:56 [Info] app/dns: quic://dns.adguard.com querying: google.com.
2024/07/19 18:06:56 DNS accepted udp:dns.adguard.com:853 [local]
2024/07/19 18:06:57 DNS accepted udp:dns.adguard.com:853 [local]
Error: /19 18:06:57 [Error] app/dns: failed to open quic connection > CRYPTO_ERROR 0x178 (remote): tls: no application protocol
2024/07/19 18:06:57 DNS accepted udp:dns.adguard.com:853 [local]
2024/07/19 18:06:57 DNS accepted udp:dns.adguard.com:853 [local]
Error: /19 18:06:57 [Error] app/dns: failed to open quic connection > CRYPTO_ERROR 0x178 (remote): tls: no application protocol
--- FAIL: TestQUICNameServer (2.01s)
panic: context deadline exceeded [recovered]
	panic: context deadline exceeded

goroutine 271 [running]:
testing.tRunner.func1.2({0xce7ea0, 0x1aa7ee0})
	C:/hostedtoolcache/windows/go/1.22.5/x64/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
	C:/hostedtoolcache/windows/go/1.22.5/x64/src/testing/testing.go:1634 +0x377
panic({0xce7ea0?, 0x1aa7ee0?})
	C:/hostedtoolcache/windows/go/1.22.5/x64/src/runtime/panic.go:770 +0x132
github.com/xtls/xray-core/common.Must(...)
	D:/a/Xray-core/Xray-core/common/common.go:23
github.com/xtls/xray-core/app/dns_test.TestQUICNameServer(0xc00057c680)
	D:/a/Xray-core/Xray-core/app/dns/nameserver_quic_test.go:27 +0x2ca
testing.tRunner(0xc00057c680, 0xe17a80)
	C:/hostedtoolcache/windows/go/1.22.5/x64/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
	C:/hostedtoolcache/windows/go/1.22.5/x64/src/testing/testing.go:1742 +0x390
FAIL	github.com/xtls/xray-core/app/dns	10.237s

[mmmray]

...I get this as test failure:

2024/07/19 20:35:39 [Info] transport/internet/quic: dialing quic to udp:127.0.0.1:38590
2024/07/19 20:35:39 [Debug] transport/internet: dialing to udp:127.0.0.1:38590
2024/07/19 20:35:39 [Info] transport/internet/quic: failed to accept QUIC connection > quic: server closed
--- FAIL: TestQuicConnection (1.04s)
panic: CRYPTO_ERROR 0x170 (remote): tls: unrecognized name [recovered]
        panic: CRYPTO_ERROR 0x170 (remote): tls: unrecognized name

goroutine 18 [running]:
testing.tRunner.func1.2({0xbe48e0, 0xc000058540})
        /usr/local/go/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
        /usr/local/go/src/testing/testing.go:1634 +0x377
panic({0xbe48e0?, 0xc000058540?})
        /usr/local/go/src/runtime/panic.go:770 +0x132
github.com/xtls/xray-core/common.Must(...)
        /home/markus/projects/Xray-core/common/common.go:23
command-line-arguments_test.TestQuicConnection(0xc00015e680)
        /home/markus/projects/Xray-core/transport/internet/quic/quic_test.go:72 +0x90b
testing.tRunner(0xc00015e680, 0xd0f1f0)
        /usr/local/go/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
        /usr/local/go/src/testing/testing.go:1742 +0x390
FAIL    command-line-arguments  1.071s
FAIL

so I tried changing www.example.com in the test to localhost (like splithttp's QUIC test) -- didn't work

[Fangliding]

In fact there are 3 (

[RPRX]

--- FAIL: TestVMessQuic (4.11s)

[RPRX]

当时好像也是风扇说别急着删

记错了，#1596

[APT-ZERO]

It was said more than a year ago that the QUIC transport layer would be deleted together with KCP.

QUIC and KCP was unpopular because of multiple reasons

1. QUIC performance was bad before
   but it's fixed in latest versions of quic-go
   Test in VPS [Server = Xray 1.8.20 / Client = Xray 1.8.21] :
   

2. UDP was blocked in most of ISPs before 2024
   but it's unblocked because of H3 is becoming the standard and is already supported by Web Browsers and CDNs

3. Clients didn't supported them
   But now we can send Xray json configs to v2rayN, v2rayNG and Streisand clients

I use QUIC because of it's obfuscations, and KCP for when UDP packet-loss rate is high and they are working well
I don't understand why you want to remove them
I just wanted to ask you to add dns obfuscation of kcp to quic too, and i hear you want to remove them both :(

[yuhan6665]

虽然我知道 @APT-ZERO 一般不靠谱 但是这次我支持
@RPRX 我们需要一个不 split，不 hy 的 quic transport（虽然删了新写 h3 也行。。）

[mmmray]

but it's fixed in latest versions of quic-go

do you know which version of quic-go caused this? my guess is 0.44 after looking through their changelogs. it's a bit unsettling. what if splithttp+h3 had been released without this random dependency bump? would we have concluded it's useless?

[mmmray]

also I want to note, uquic 0.0.6 is synced with quic-go 0.42: https://github.com/refraction-networking/uquic/releases/tag/v0.0.6

we are on quic-go 0.45

so if this PR is fixed, and we merge it, we still might encounter a performance regression, and it should be tested before release. I just didn't have the time to follow up on this PR.

v0.44 contains a lot of fixes related to HTTP Datagrams, new logic to determine (and configure) the QUIC packet size, as well as a significant speedup of the various parsers.

https://github.com/quic-go/quic-go/releases/tag/v0.44.0

[RPRX]

also I want to note, uquic 0.0.6 is synced with quic-go 0.42: https://github.com/refraction-networking/uquic/releases/tag/v0.0.6

we are on quic-go 0.45

so if this PR is fixed, and we merge it, we still might encounter a performance regression, and it should be tested before release. I just didn't have the time to follow up on this PR.

v0.44 contains a lot of fixes related to HTTP Datagrams, new logic to determine (and configure) the QUIC packet size, as well as a significant speedup of the various parsers.

https://github.com/quic-go/quic-go/releases/tag/v0.44.0

既然如此，我觉得我们可以等两个月 uquic 更新后再用它替代 quic-go。GFW 对 CDN 的 IP 有更高的容忍度，目前也尚未观察到连接到 CDN 的 quic-go 被实时阻断，毕竟这是条新路尚未引来 GFW 的关注，可以打一个时间差，况且我们已有 Browser Dialer。

[RPRX]

虽然我知道 @APT-ZERO 一般不靠谱 但是这次我支持
@RPRX 我们需要一个不 split，不 hy 的 quic transport（虽然删了新写 h3 也行。。）

会有这样的 transport，就是删了 quic transport 新写支持 h3 的 streaming request，优势是它能用 Browser Dialer，Chrome 支持

[RPRX]

插播两段来自 2022 年 7 月的讯息（截取）：

......（马赛克）

// Chromium 105 的 streaming requests with fetch 比 websocket over http/2 更合适：
// 1. 后者目前只有 haproxy 和 envoy 支持，而它们没有 web 服务，要多跑一个软件，麻烦。
// 2. 后者不能跨站复用 h2，只能把中转网页放在服务端，非常麻烦。
// 3. 后者的前提是有个 h2 长连接在，否则无声走 http/1.1，得另开 SSE 长连接，麻烦。
// 4. 前者虽然 cf 也不支持，但把请求分片应该能过 CDN。
// 5. 前者仅限于 h2，似乎还支持 h3，连 WebTransport 都省了。

// fetch：三种模式，兼容（用于苹果和 CDN）、半双工、全双工；独立的分享链接......
// fetch://password@example.com:port/path?duplex=none/half/full（最高支持等级，客户端看着办）
......
至于是否公开...不，不要再去趟那滩浑水了，从任何方面来讲都不值得，真的不值得。

[RPRX]

差点忘了还有个 XTLS/REALITY#2 (comment) 可以说是无视 GFW，我都用一年多了还是只有 @yuhan6665 知道，反正他也不会说

[RPRX]

差点忘了还有 #1758 (comment) ，@yuhan6665 你看下它现在是不是还在干这破事

[mmmray]

how about moving to apernet/quic-go instead? it has hooks for congestion control, I believe BBRv3 can be achieved. on the other hand it will conflict with integration of uquic. maybe all the forks can be merged together.

[wyx2685]

@mmmray 是时候组建xquic了

[yuhan6665]

how about moving to apernet/quic-go instead? it has hooks for congestion control, I believe BBRv3 can be achieved. on the other hand it will conflict with integration of uquic. maybe all the forks can be merged together.

So many forks (efforts) on quic-go, yet seems no one care about uQuic (fingerprints). Are those people (who work on quic protocols) serious about anti-censorship or just fooling around?

[yuhan6665]

Moved to #3964
I fixed the uquic server side and formalized fingerprint setting. Thanks all!