XTLS
Replace quic-go with uQuic
这个uquic依赖会让二进制大小膨胀9%(约等于把本来史的quic-go复制一遍) 我加个acme多6%都嫌依赖重了 用acme的绝对比用splithttp的多(我都没见过拿这个当主力的) 感觉直接用quic-go就行了 顺便客户端哪怕有bbr也用处不大 要服务端有才行
个人意见：acme 是可有可无所以不倾向加 uquic 考虑到 quic 的长远发展（不是近期的封锁） 应该跟 utls 一样是一个必要依赖 咱们可以把 quic-go 完全迁移了？
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
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
我们需要考虑降低项目复杂度
可以用 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 (https://github.com/quic-go/quic-go/issues/4007#issuecomment-2209885517), 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的作者已经表示不愿意将指纹识别能力考虑在内 (https://github.com/quic-go/quic-go/issues/4007#issuecomment-2209885517) ，所以我希望向我们优秀的开源社区寻求帮助，尤其是那些在乎反审查的人们。
~~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 月之后的某个时间点进行。正如我提到的，我们需要进行主要更新以模仿一些新的行为。
所以现在指纹是只有 chrome 和 firefox 吗，transport/internet/splithttp/dialer.go 这个文件需要 fmt 一下
打算合并另外两个 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.
@mmmray 请修复这个 PR，使用 uquic v0.0.6，还有 https://github.com/XTLS/Xray-core/pull/3550#issuecomment-2238934903
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.
=== 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
...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
Believe me, I tried. :sweat_smile: The Vmess failure is a downstream issue of the transport/quic failure. The DNS issue, I don't know what's wrong either. It seems to me we might set some weird ALPN in nameserver_quic.go that could cause this issue, but changing or removing it doesn't make a difference.
DOQ的问题解决了 wireshark拆开结合报错发现请求中没有alpn 因为utls没法正确传递alpn(我是不是说过这事)
剩下两个还是boom的 原因 都是 [CRYPTO_ERROR 0x170 (remote): tls: unrecognized name] 这个我找到的相关信息就一个 https://github.com/golang/go/issues/18377 ray的QUIC在没有配置的证书的情况下默认会自签证书通讯 这个请求wireshark拆不开 不知道里面SNI是啥样 不清楚是不是这个的问题
~~I made the tests for splithttp and quic transports exactly the same and now it works. The important difference was DNSNames vs CommonName. I think they are supposed to be equal if no CommonName is set. I'm a bit skeptical because it used to work before like this, so I think this may still be a user-visible behavior change in quic transport.~~
forget about it. :facepalm: the tests pass on main branch.. in this branch, now both tests fail. Legitimately so, because splithttp DialEarly did not actually raise any certificate errors.
--- FAIL: TestVMessQuic (4.10s)
FAIL 只剩这个了，~~其实我觉得要不这个版本就把 QUIC Transport 删掉吧，反正也没人用吧~~
https://github.com/XTLS/Xray-core/pull/3550/commits/dd876d59eb7e10a59b7d1d4e59c09a78a0f771b8 这个 commit 不行，应该会导致用户能手动修改浏览器指纹的 ALPN？~~还好看了一眼~~