SplitHTTP: Server supports HTTP/3

[ll11l1lIllIl1lll]

我不知道为什么会有人尝试直连 SplitHTTP3 而不去使用 tuic, hysteria 或者直接用 quic transport ，不过我去实现一下也不会有什么坏处。或许我应该直接加一个 UpDownSplit 用于使上下行各自用一个连接。
让 tlssettings.alpn 只有 ["h3"] 即可使用 SplitHTTP3 Server，虽然说一个正常的服务器支持了 h3 也应该支持 h2 和 http/1.1 ，不过其他的 QUIC 协议都没有这么做，所以我不在意，试试加两个 inbound
或许考虑一下 RFC 9220: Bootstrapping WebSockets with HTTP/3 会更好。
此提交使用原版 quic-go 而不是 uQuic ，与 #3550 平行。

[mmmray]

in general, i see a lot of new fields and it leads to bug like random nil pointer deref. are these interfaces not mutually compatible, can't quic.Foo be stored in the same variable as net/http.Foo?

[mmmray]

I don't know why anyone would try to connect directly to SplitHTTP3 instead of using tuic, hysteria or directly using quic transport

I actually wondered the same when h2 was added. It's still useful for testing. Since there is now a quic server and client, I suggest to adapt one of the tests from splithttp_test and test direct connections.

[RPRX]

再给 SplitHTTP 加个 streaming request 模式，还支持 Browser Dialer，我们就可以把 QUIC 甚至 H2 传输层删掉了

SplitHTTP 基于标准 HTTP 所以更有优势，没有开玩笑，本来 就是这样，套 CDN 只是“兼容模式”，直连可以更快

[RPRX]

要不这些都开发完成后改名叫 XHTTP 吧，v1.9 时正式发布

[mmmray]

Okay that makes sense long-term and certainly justifies this PR, but let's make smaller steps for now. 😅 Development has moved really quickly the past days, and the adoption has not caught up, so there's not much feedback. Is there a need to accelerate the cat-and-mouse game further at the moment? The streaming request thing is probably a good idea, but until that happens I want to be sure the current uploads are optimized as much as possible. I don't think that's the case right now. If the protocol is renamed, I think it would be best to have a list of breaking changes we want to do.

It also remains to be seen what happens to hy2 now and what kind of solutions they come up with. I like the idea of being compatible with other cores, eventually...

1. raw cipherstream is not enough, let's use TLS -- XTLS
2. TLS is not enough, let's also use HTTP -- XHTTP
3. HTTP is not enough, let's encode all traffic as HTML -- XHTML

[RPRX]

It also remains to be seen what happens to hy2 now and what kind of solutions they come up with.

我的观点是 QUIC 是未来趋势所以 GFW 不会完全封锁 QUIC 但也不会不管，肯定会像针对 TLS in TLS 那样找特征挑出代理来封锁

按此逻辑，像 SplitHTTP 这样完全基于标准 HTTP/3 的已经是最保守的了，如果 GFW 连它都封，那就没什么 QUIC 类代理能用了

[RPRX]

或者我们只给 streaming request 模式起名 XHTTP，下行和 SplitHTTP 一致，支持上下行分离

[RPRX]

我发现 #3543 结合 dialerProxy 会 panic

[Fangliding]

"唔 UDP" dispatcher捂着肚子痛苦地倒到地上 像蛆一样扭了几下 似了

[mmmray]

Or we can just name the streaming request mode XHTTP.

It sounds ok to me, I'm also generally ok with a name change for the entire transport. I had hoped that SplitHTTP is more self-descriptive than more "X", but actually the "split" is really meaningless.

My main point is not to rush more things now, and instead wait for adoption. (I have some other plans for splithttp/xhttp as well, just not sure if they are necessary or even feasible, still need to see how this thing runs in Iran)

will panic when combined with dialerProxy

suggest to move forward with this PR anyway and file a bug, there is another udp-dialerProxy issue that may be fixed at the same time (if it is related) #2850

[RPRX]

并且我可以复现 2dust/v2rayNG#3344 @2dust

[RPRX]

等 @ll11l1lIllIl1lll 确认这个 PR is ready 后，可以合并

[RPRX]

It sounds ok to me, I'm also generally ok with a name change for the entire transport. I had hoped that SplitHTTP is more self-descriptive than more "X", but actually the "split" is really meaningless.

我觉得长远来看同一个名称包含两种上传模式不太方便交流，所以我们可以服务端只有 SplitHTTP，客户端多一个 XHTTP

客户端 SplitHTTP 和 XHTTP 的区别就是前者上行的每个包都可以分离、多路径到达服务端，而后者是 streaming request

[RPRX]

其实还能实现下行的每个包都可以分离（meek？）、多路径到达客户端

如果同时就几个相对固定的下行连接的话，下行效率应该还行，毕竟不用像上行分包那样每个包都是一个 HTTP POST 请求

Meek 的下行效率很差，是因为它不用 HTTP chunked transfer encoding

[mmmray]

#3555 let's continue here

[ll11l1lIllIl1lll]

I completely fucked my lcoal git up.
再也不会尝试 push --force 了，除了这次

[RPRX]

本来我想让 v1.8.19 成为最新的稳定版，现在我想合了这几个 PR 然后发个 v1.8.20

[RPRX]

所以这个 PR ready 了吗

[mmmray]

I can confirm that this merged together with #3559 fixes splithttp+h3 on android, so I think both PRs can be released.