[Feature-Request] splithttp using http3

[Mfire2001]

I just saw the new realease and saw httpsplit,from my undrasting it works by having multiple connections for upload and download and can be used with cdns without websocket
Is it possible to have the same thing with http3?cloudflare supports quic but I think it deliveres connections to origin server using http1.1
This is what came to my brain:the server side is the same but the client send each GET /?session= and POST /?session= using http3 instead of http1.1 or h2

[Fangliding]

H3 is probably too complicated, especially now there are still many issues with QUIC

[mmmray]

the transport just uses golang http.Client, you can probably replace http2.Transport with this: https://pkg.go.dev/github.com/quic-go/quic-go/http3#RoundTripper

and it could work.

if it's useful, I think depends on the country...

but yeah i have no idea how things like utls would work with it

[Mfire2001]

H3 is probably too complicated, especially now there are still many issues with QUIC

U are right, but i think it kinda worth it,since quic has built in multiplexing and u can have all the get and post requests using the same udp socket,xray uses http.client for handling requests right?I will see xray's code and see what I can do,

[mmmray]

U are right, but i think it kinda worth it,since quic has built in multiplexing

h2 already has mux, and with less annoyance around utls (still quite a bit of annoyance!). it's likely that there is only one tcp connection per connection in the end. it would need a different motivation, maybe to blend in with other quic traffic or to achieve some performance goal, but it seems unlikely. also, if iran can just block UDP for fun, is it worth it?

but I think it should be prototyped, I think it is possible that the performance is better than h2.

[PoneyClairDeLune]

My two pennies on this: It's not really worth it to pair any form of Meek with HTTP/3.

UDP packets are usually under heavy scrutiny in repressive regimes, often made slower than the equivalent transports over TCP. If you want to argue on general performance, it's not possible to force CDNs to use a custom flavour of congestion control algorithm; heck, for direct connections, there already exist a whole bunch of fully-duplex and performant solutions.

To Meek itself, in all intents and purposes, is a technique reconstructing states over underlying transports. Between reconstructed and native duplex connections, I don't think any sane person would choose the former any day.

However, Meek over DNS has greater potential, despite it always being a dial-up sim. Iodine is a (kinda) great example.

[mmmray]

I will see xray's code and see what I can do

Right, so here: https://github.com/XTLS/Xray-core/blob/main/transport/internet/splithttp/dialer.go#L102

...h2 is enabled for all TLS connections

I suggest to try and replace http2.Transport with http3.Transport, basically

I think there are implications for how connections are created (I don't think the existing dialContext will work at all anymore), but let's see :)

[Fangliding]

What I want to say is that the main purpose of this protocol is to pass through CDN, and even Cloudflare does not support h3 to origin, let alone other CDN.
If not use CDN, just as PoneyClairDeLune said there already be many good solutions.

[mmmray]

In theory http3 deals with packet loss better due to lack of head of line blocking, and there is plenty of packet loss in iran between CDN and user. so it could still pay off, even if the requests get converted to HTTP/1.1

(the issue with origin requests isn't even the CDN... the xray server only supports HTTP/1.1 🙈) wrong, xray server supports all protocols, h1, h2, tls, doesn't matter

[Fangliding]

In theory http3 deals with packet loss better due to lack of head of line blocking, and there is plenty of packet loss in iran between CDN and user. so it could still pay off, even if the requests get converted to HTTP/1.1

(the issue with origin requests isn't even the CDN... the xray server only supports HTTP/1.1 🙈)

Don't have too much hope for the performance of QUIC. One of the problems I just mentioned one of ray's QUIC issues is that its performance is worse than that of TCP protocol in the same network environment, not to mention the attitude of middle box towards UDP packets

[APT-ZERO]

one of ray's QUIC issues is that its performance is worse than that of TCP protocol in the same network environment

Because nobody touched Xray's QUIC code for years, performance of Sing-Box QUIC Based protocols are great

[mmmray]

@APT-ZERO it's true that hy2 works well. i am not sure the ideas can be applied to this transport. do you mean another protocol in sb?

[APT-ZERO]

I meant Hy2 too, Have a look at this https://github.com/SagerNet/sing-quic
It seems like Clash.Meta(Mihomo) made improvements to QUIC, and Sing-Box used the same but even optimized it more
Everything they did, must be applicable to Xray too

[Fangliding]

The acceleration method used by hy2 is not applicable to CDN(in fact, I can implement a similar acceleration in TCP, but it is also not used for CDN)
In short, its performance is far from what you imagine

[RPRX]

我觉得可以为了 diversity 而支持 HTTP/3，无论有没有 acceleration，反正饼已经画在 release note 中了