Transport: Add HTTP3 to HTTP

[yuhan6665]

既然我在测试的 Quic 被删了 那只能用 H3 加回来。。

            "streamSettings": {
                "network": "http",
                "security": "tls",
                "httpSettings": {
			"host": ["xray.com"],
			"path": "/random/path",
                },
                "tlsSettings": {
                    "serverName": "example.com", // Change to your domain.
                    "alpn": [
                        "h3"
                    ]
                }
            },

[RPRX]

哈哈哈

[RPRX]

但我仔细看了一下，其实 http 也准备删，换成支持 browser dialer 的 splithttp streaming request

[yuhan6665]

但我仔细看了一下，其实 http 也准备删，换成支持 browser dialer 的 splithttp streaming request

browser dialer 支持可以加吧 我（觉得有 use case）不想要 split

而且退一步讲就算是做 splithttp 的对照组也好啊

[RPRX]

但我仔细看了一下，其实 http 也准备删，换成支持 browser dialer 的 splithttp streaming request

browser dialer 支持可以加吧 我（觉得有 use case）不想要 split

而且退一步讲就算是做 splithttp 的对照组也好啊

Streaming request 就是流式上行，不 split

[RPRX]

@APT-ZERO 这次是我折叠的，不要问这些问题，该有的都会有，总是这样真的很烦

[RPRX]

@yuhan6665 如果我们私聊讨论确实需要这个再 reopen

[RPRX]

@APT-ZERO 没有人有义务回答你的这些问题，真的很烦，你能想到的我们都想了，建议提升下自己的水平再来 comment

[RPRX]

受不了了，看着就烦，以后再有小白喜欢这样我 tm 直接 block #from_end_user，不浪费时间了

[RPRX]

其实我的计划是给 SplitHTTP 加 streaming request，unblock REALITY，然后重命名为 XHTTP，删掉现有的 HTTP（H2） 传输层

[RPRX]

#3823 (comment)

[RPRX]

#3823 (comment)

[RPRX]

So, as discussed in #3823 (comment), I will reopen and merge this PR, then merge SplitHTTP and HTTP (H2, H3) into XHTTP.

[RPRX]

请大家测试一下新的直连 H3 传输层的可用性，并且我们有计划给它加上不那么 brutal 的增强

[yuhan6665]

请大家测试一下新的直连 H3 传输层的可用性，并且我们有计划给它加上不那么 brutal 的增强

感谢 测试了一下可以正常使用~
不过测速表现可能比以前的 quic 稍差一点
因为复用同一链接的关系 如果连续测速跟 quic split 一样会有明显降速的情况 （可能跟我测试线路有关）

[RPRX]

请大家测试一下新的直连 H3 传输层的可用性，并且我们有计划给它加上不那么 brutal 的增强

感谢 测试了一下可以正常使用~ 不过测速表现可能比以前的 quic 稍差一点 因为复用同一链接的关系 如果连续测速跟 quic split 一样会有明显降速的情况 （可能跟我测试线路有关）

多了一点点数据头，理论上会比直接的 QUIC 慢 1%，实际上几乎没差，它和 SplitHTTP 合并为 XHTTP 后就有 xmux 能限制复用了

外层都是 quic-go 的特征，感觉暂时不适合 fallbacks 或 REALITY，实际部署应放在 Nginx 后面，改它的 QUIC 拥塞控制就能提速

所以我觉得现阶段多加一点点数据头换来能放在反代软件后面是很值得的，这也是 XHTTP 和 Hysteria / TUIC / Juicity 的最大区别

[Ardentwheel]

请大家测试一下新的直连 H3 传输层的可用性，并且我们有计划给它加上不那么 brutal 的增强

感谢 测试了一下可以正常使用~ 不过测速表现可能比以前的 quic 稍差一点 因为复用同一链接的关系 如果连续测速跟 quic split 一样会有明显降速的情况 （可能跟我测试线路有关）

多了一点点数据头，理论上会比直接的 QUIC 慢 1%，实际上几乎没差，它和 SplitHTTP 合并为 XHTTP 后就有 xmux 能限制复用了

外层都是 quic-go 的特征，感觉暂时不适合 fallbacks 或 REALITY，实际部署应放在 Nginx 后面，改它的 QUIC 拥塞控制就能提速

所以我觉得现阶段多加一点点数据头换来能放在反代软件后面是很值得的，这也是 XHTTP 和 Hysteria / TUIC / Juicity 的最大区别

NGINX 的 stream 模块不支持quic，测试版是支持的，正式版就删除了。好像没法通过sni分流
nginx/nginx#146

[RPRX]

NGINX 的 stream 模块不支持quic，测试版是支持的，正式版就删除了。好像没法通过sni分流 nginx/nginx#146

Nginx 支持 QUIC 只是时间问题，鉴于可预见的未来内暂无服务端 QUIC 特征伪装方案，Xray 放在反代软件后面是非常有必要的

我重来，才看清说的是 stream，我还纳闷 Nginx 咋会还不支持 H3，然而 Xray 用到的不是 stream 而是 H3 反代（变为 H2/H1）

根据 H2 传输层的 文档，它可以被 Nginx 中转，但似乎未经测试（这也是我最初希望上下行分离的原因之一），可以测试一下 Nginx 支持这种全双工吗？不过我现在决定即使 Nginx 不支持，XHTTP 也会支持这种经典的全双工模式

[Yochee]

NGINX 的 stream 模块不支持quic，测试版是支持的，正式版就删除了。好像没法通过sni分流 nginx/nginx#146

Nginx 支持 QUIC 只是时间问题，鉴于可预见的未来内暂无服务端 QUIC 特征伪装方案，Xray 放在反代软件后面是非常有必要的

我重来，才看清说的是 stream，我还纳闷 Nginx 咋会还不支持 H3，然而 Xray 用到的不是 stream 而是 H3 反代（变为 H2/H1）

根据 H2 传输层的 文档，它可以被 Nginx 中转，但似乎未经测试（这也是我最初希望上下行分离的原因之一），可以测试一下 Nginx 支持这种全双工吗？不过我现在决定即使 Nginx 不支持，XHTTP 也会支持这种经典的全双工模式

nginx貌似只能反代grpc的h2流量，没有h2c的反代功能。其实只要xray传输层的http支持http1.1就行了？nginx接收h3流量用http/1.1反代给后端xray。

另外测了下裸奔的vless+h3+tls，性能符合预期能跑满，但不如hy2，除了qos限流外，好像还会断流要重启客户端才行。还有就是没有伪装功能

[RPRX]

nginx貌似只能反代grpc的h2流量，没有h2c的反代功能。其实只要xray传输层的http支持http1.1就行了？nginx接收h3流量用http/1.1反代给后端xray。

这两天我和 @yuhan6665 也在研究这件事，Nginx 暂不支持 h2c 回源，所以 H2 传输层的文档写 Nginx 是错的，应该写 Caddy。以前缺乏 Web 伪装大概也是 H2 传输层几乎没人用的原因之一（另一个原因是 v2 有断流 bug），就像此前被删掉的 QUIC 传输层。

HTTP/1.1 的流式上行也需要 chunked encoding，还没测 Nginx 是否支持把 h3/h2 转译成它，然后还有些问题需要研究。

Caddy 或许还支持把 h3 转译成 h2c，正在测试，但那样又成 quic-go 了，感觉 Caddy 像玩具，能用主流的 Nginx 更好。

另外测了下裸奔的vless+h3+tls，性能符合预期能跑满，但不如hy2，除了qos限流外，好像还会断流要重启客户端才行。还有就是没有伪装功能

目前只推荐放在反代软件后面，我们计划修改 Nginx 的 QUIC 拥塞控制代码，就像其它协议改 quic-go，但不会那么 brutal。

至于断不断流，盲猜代码应该没那种断流 bug，可能是运营商给你 Q 没了，需要换本地端口，以后也支持 xmux 就能自动换了。

总体上还是 SplitHTTP 比较成熟，基本上什么都支持什么都有了，即使上行 Split 也问题不大，毕竟通常上行流量很少。打算把 v24.9.30 标为 latest，下个版本可能 xmux 会有默认值以及 path 也能设置参数，XHTTP 是合并还是单独指代直连还在考虑。

[Yochee]

HTTP/1.1 的流式上行也需要 chunked encoding，还没测 Nginx 是否支持把 h3/h2 转译成它，然后还有些问题需要研究。。

嗯，刚才用freedom出站的redirect给vless+裸tcp套了层http，用nginx反代，果然没通...

[RPRX]

嗯，刚才用freedom出站的redirect给vless+裸tcp套了层http，用nginx反代，果然没通...

是哪种 HTTP，Xray 的 HTTP 传输层暂不支持 HTTP/1.1，不过搞这么复杂应该不是？

其实我越来越觉得直连 QUIC 干脆改 Nginx 的 QUIC 加 SplitHTTP 就行了，上行流量那么少 Split 也没啥，可惜它一开始没改名 X

你有兴趣研究一下修改 Nginx 的 QUIC 拥塞控制代码并分享出来吗？编译很简单，以前我用 OpenResty 都是自己编译的

[Yochee]

你有兴趣研究一下修改 Nginx 的 QUIC 拥塞控制代码并分享出来吗？编译很简单，以前我用 OpenResty 都是自己编译的

可惜我只是个小卡拉米enduser，只会写配置不会写代码...要研究的话学习曲线有点陡峭啊，还是靠大佬们了，我就当个测试吧

[Fangliding]

taking some review