Replace quic-go with uQuic #3550

ll11l1lIllIl1lll · 2024-07-17T17:52:18Z

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

Fangliding · 2024-07-17T18:09:56Z

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

yuhan6665 · 2024-07-17T19:23:57Z

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

Mfire2001 · 2024-07-17T23:22:35Z

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 · 2024-07-18T00:06:28Z

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 · 2024-07-18T07:25:26Z

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

RPRX · 2024-07-18T07:27:56Z

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

gaukas · 2024-07-18T07:47:02Z

可以用 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 · 2024-07-18T08:02:15Z

~~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 · 2024-07-19T11:22:08Z

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

RPRX · 2024-07-19T11:29:43Z

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

gaukas · 2024-07-19T11:45:04Z

打算合并另外两个 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 · 2024-07-19T11:51:33Z

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

感谢

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

~~只要 Client Hello 看着一样就行~~

RPRX · 2024-07-19T17:56:41Z

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

RPRX · 2024-07-19T18:15:32Z

~~quic-go 仍然存在~~

Fangliding · 2024-07-19T18:20:32Z

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

mmmray · 2024-07-19T18:25:34Z

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 · 2024-07-19T18:29:14Z

Agree, we can study it later

RPRX · 2024-07-19T18:33:31Z

=== 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 · 2024-07-19T18:36:41Z

...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 · 2024-07-19T18:39:15Z

In fact there are 3 (

RPRX · 2024-07-19T18:42:19Z

--- FAIL: TestVMessQuic (4.11s)

RPRX · 2024-07-20T05:58:51Z

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

~~记错了~~，#1596

APT-ZERO · 2024-07-23T08:47:39Z

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

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] :
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
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 · 2024-07-23T14:39:53Z

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

mmmray · 2024-07-23T16:16:15Z

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 · 2024-07-23T16:20:12Z

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 · 2024-07-24T00:59:28Z

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 · 2024-07-24T01:15:28Z

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

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

RPRX · 2024-07-24T02:03:14Z

~~插播两段来自 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 · 2024-07-24T02:10:10Z

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

RPRX · 2024-07-24T02:36:23Z

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

mmmray · 2024-08-31T00:38:53Z

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 · 2024-08-31T00:46:02Z

@mmmray 是时候组建xquic了

yuhan6665 · 2024-09-01T01:00:28Z

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 · 2024-11-03T02:13:00Z

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

SplitHTTP: Client supports uQUIC

fd9ef70

ll11l1lIllIl1lll changed the title ~~SplitHTTP: Client supports uQUIC~~ SplitHTTP: Client supports uQuic Jul 17, 2024

Replace quic-go with uQuic

1bcb650

ll11l1lIllIl1lll changed the title ~~SplitHTTP: Client supports uQuic~~ Replace quic-go with uQuic Jul 17, 2024

ll11l1lIllIl1lll mentioned this pull request Jul 18, 2024

SplitHTTP: Server supports HTTP/3 #3554

Merged

mmmray added 3 commits July 19, 2024 13:00

Merge remote-tracking branch 'origin/main' into uqic

e20414f

bump uquic

be8c04c

formatting

a1d469f

remove quic-go entirely

f7faecb

This comment was marked as off-topic.

Sign in to view

RPRX force-pushed the main branch from 3710b56 to 59f6685 Compare July 29, 2024 06:25

BrewTestBot mentioned this pull request Jul 29, 2024

xray 1.8.23 Homebrew/homebrew-core#178854

Merged

1 task

RPRX force-pushed the main branch from b11fcf0 to 7e24239 Compare August 2, 2024 21:48

RPRX mentioned this pull request Aug 3, 2024

SplitHTTP client: Raise idle timeout to 5 minutes #3624

Merged

mmmray force-pushed the main branch from f3dc545 to f0547bc Compare August 12, 2024 10:59

Fangliding force-pushed the main branch from abb654d to 8da6954 Compare August 15, 2024 11:49

RPRX force-pushed the main branch from 8da6954 to b612da2 Compare August 16, 2024 00:59

RPRX mentioned this pull request Aug 30, 2024

add support uQuic #3742

Closed

yuhan6665 force-pushed the main branch from 0d1e4cd to f357245 Compare September 6, 2024 01:41

RPRX mentioned this pull request Sep 20, 2024

xmux for grpc and h2 #3823

Closed

RPRX force-pushed the main branch from 98a517c to 8809cbd Compare October 18, 2024 02:16

RPRX force-pushed the main branch from 539b641 to b7aacd3 Compare November 2, 2024 21:07

yuhan6665 closed this Nov 3, 2024

ll11l1lIllIl1lll deleted the main branch December 1, 2024 05:33

Replace quic-go with uQuic #3550

Replace quic-go with uQuic #3550

Conversation

ll11l1lIllIl1lll commented Jul 17, 2024 • edited Loading

Fangliding commented Jul 17, 2024 • edited Loading

yuhan6665 commented Jul 17, 2024

Mfire2001 commented Jul 17, 2024

yuhan6665 commented Jul 18, 2024

RPRX commented Jul 18, 2024

RPRX commented Jul 18, 2024

gaukas commented Jul 18, 2024 • edited Loading

gaukas commented Jul 18, 2024 • edited Loading

RPRX commented Jul 19, 2024

RPRX commented Jul 19, 2024

gaukas commented Jul 19, 2024 • edited Loading

RPRX commented Jul 19, 2024

RPRX commented Jul 19, 2024

RPRX commented Jul 19, 2024

Fangliding commented Jul 19, 2024 • edited Loading

mmmray commented Jul 19, 2024

yuhan6665 commented Jul 19, 2024

RPRX commented Jul 19, 2024

mmmray commented Jul 19, 2024

Fangliding commented Jul 19, 2024

RPRX commented Jul 19, 2024

RPRX commented Jul 20, 2024

APT-ZERO commented Jul 23, 2024

yuhan6665 commented Jul 23, 2024

mmmray commented Jul 23, 2024

mmmray commented Jul 23, 2024

RPRX commented Jul 24, 2024

RPRX commented Jul 24, 2024

RPRX commented Jul 24, 2024

RPRX commented Jul 24, 2024

RPRX commented Jul 24, 2024

This comment was marked as off-topic.

This comment was marked as off-topic.

mmmray commented Aug 31, 2024

wyx2685 commented Aug 31, 2024

yuhan6665 commented Sep 1, 2024

yuhan6665 commented Nov 3, 2024

ll11l1lIllIl1lll commented Jul 17, 2024 •

edited

Loading

Fangliding commented Jul 17, 2024 •

edited

Loading

gaukas commented Jul 18, 2024 •

edited

Loading

gaukas commented Jul 18, 2024 •

edited

Loading

gaukas commented Jul 19, 2024 •

edited

Loading

Fangliding commented Jul 19, 2024 •

edited

Loading