xmux for grpc and h2

[mmmray]

(trying to "plan" this thing so that the designing doesn't happen on the PR itself)

xmux is a setting in splithttp. however, the principle can be applied to h2 and grpc transports. there are a few ways to port it:

Option 1: Just copy it to grpcSettings

"grpcSettings": {
    "xmux": ...
}

Option 2: Make it global

xmux replaces the mux key. For transports that support xmux, it is used. For transports that do not support xmux, mux.cool is used:

"network": "websocket",
"mux": { // mux.cool
    "concurrency": 8
}

"network": "grpc",
"mux": { // h2mux/xmux
    "concurrency": 8
}

can add a "type" setting like sing-box, but IMO it can be chosen automatically (for each transport, there is an "obvious best" one)

thoughts?

[APT-ZERO]

Why there is no minConnections? and what about H1
If xmux support all transports, then it's perfect and can replace Mux.Cool

[mmmray]

What does minConnections do?

"xmux" just means that it uses the "native mux of HTTP" (H2 mux or QUIC). H1 cannot be done, as HTTP/1.1 has no mux capability.

there will always be some transports that can't do it, in fact most transports can't (only the h2, h3 based ones)

[APT-ZERO]

What does minConnections do?

Create multiple physical connection initially and use both from the beginning like roundRobin load balance

"xmux" just means that it uses the "native mux of HTTP" (H2 mux or QUIC). H1 cannot be done, as HTTP/1.1 has no mux capability.

oh I thought it means Xray's Multiplex
I think the best way and future proof option is to have 'type' in 'mux' settings

[RPRX]

H2 准备删掉，用 streaming request 代替，gRPC 可以有 xmux，先不改 mux，此贴终结

[RPRX]

#3819 (comment)

[RPRX]

我仔细看了一下，原则应当是 xmux 写在哪就作用在哪，比如 xhttp、grpc、mux，以及暂时先不要管用户配置了双层 mux 的情况

[RPRX]

以及对于 grpc，Xray 已经改了太多了，我想的是重新设计一下命名为 xgrpc，然后把 grpc 这个名称滥用给移除

[RPRX]

大概就是建议迁移至 xhttp 和 xgrpc，2025 移除 h2 和 grpc

[mmmray]

Personal opinion, create xhttp, xgrpc, ... first, long before deprecating the other stuff. In hindsight, the removal of QUIC would've probably been better if xhttp3 (that is, streaming upload, streaming download, over QUIC) was already launched, because there would've been clear empirical evidence that one is working better (or just as good) as the other. However, QUIC transport itself has few users, so it's fine. I feel differently about gRPC and H2.

For example, there is the assumption that xhttp is a killer for h2 because it has the ability to pass nginx. But from my understanding, xhttp will inherently consume more resources due to the global sessions map, and if we assume this protocol will be fully embraced by users, then we have to assume that these additional anti-censorship properties are so useful in practice that users are happy to make this tradeoff.

This is not yet clear to me, so I'd like to A/B test all of this. I still believe in "let a thousand flowers bloom", but not because the user should just try random protocols until one works, but because when I have to "remote-debug" somebody else's firewall, it's useful to know things like "the plain http3 transport got blocked, but splithttp with the weird upload worked fine".

The other thing is that you say "xray does what it thinks is right", but actually I feel that nowadays it has to coexist with other software. Lots of people nowadays use sing-box on mobile and xray on the server. I feel that it is already pretty hard today to find a protocol that works in this combination.

[Fangliding]

grpc别删吧 很多人还在用 一来它可以双向流过cf 二来是算在代理软件里通用的一个多路复用的协议(v2fly clashmeta singbox ...)

[ImMohammad20000]

grpc别删吧 很多人还在用 一来它可以双向流过cf 二来是算在代理软件里通用的一个多路复用的协议(v2fly clashmeta singbox ...)

I agree with you deleting grpc just break compatibility with other core and it not a good move for xray

I think it better to add hystria2 because all other cores added that

[mikeesierrah]

I have to "remote-debug" somebody else's firewall, it's useful to know things like "the plain http3 transport got blocked, but splithttp with the weird upload worked fine".

I agree with mmmray on this since xray is also a tool to analyze gfw behaviour - people will analyze and log the loopholes using the multiple transport and many options in xray

its truly a shame we don't have many transports in xray since its the base platform and core for distribution firewall bypassing configurations

[yuhan6665]

Personal opinion:

1. Please don't delete grpc and h2 transport
2. Please don't delete it without there is an alternative available where most of the community accepts.

[KobeArthurScofield]

Personal Opinion:

a) Better not to remove HTTP/2 and gRPC, at least until the next next year.
b) If the alternative transport is not been unveiled and used long enough and spread wide enough, better not to remove the one that will be replaced.
c) For xgPRC, I think the better way is , the config still writes "grpc" (less breaking for users and GUI clients), and keep optimizing the code and adding some unique features like xmux. So that when unique features is on it is the real xgRPC, and when the unique feature is off it just works like normal gRPC. And for HTTP/2, keep it longer for interoperability, unless there are few people use it, and we can still have the best HTTP/2 transport experience among others. xHTTP has its unique shining points, but only time can make it shine brighter.
d) I have a self built proxy server, my friends have self built proxy servers, and we share connection information to each other so that we won't completely get blacked out. The servers may use Xray, V2Ray, or blabla... So we will keep something that everyone can use without switching the proxy apps, HTTP/2 and gRPC transport (gRPC is slightly more) became our common selection for that because they have mux and have no ALPN problem. If they got removed completely (or just a rename in config), it would be a headache again, like interoperability and sharing links.

[RPRX]

Relax, and just trust me

[RPRX]

我是觉得有时候你们想得太多或想得不够多

先说下 h2 传输层，v5ray 已经删了，REALITY 救了它一命，不然用的人不会比 QUIC 传输层多多少，且跨代理软件时人们更喜欢用 grpc 传输层。XHTTP streaming request 就跟 h2 传输层差不多，分离的请求与响应以支持 chrome（browser dialer）和那些反代软件，加了 header padding，我觉得 h2 传输层实在没必要留下来对比，此外支持 xmux，话说 xmux 好像还没考虑 browser dialer

然后是 grpc 传输层，毫无疑问 xgrpc 经过设置一定能兼容现有的 grpc，我只是想改个名以避免名称滥用（虽然当初是我建议的但那才符合 v2 的习惯），也能一目了然让大家知道这是 Xray 的增强版 grpc，因为真的加了好多东西，有些配置参数我也想顺便改得更合理，但 grpc 的用户比较多、需要时间迁移配置，所以可以推迟到 v26 再移除，至于 h2 传输层我觉得下个版本就可以移除

[yuhan6665]

v5ray 没有删 h2 呀 姑且不说用的人多少 我喜欢它的简单
grpc split xmux 以及以后的东西 本质上都是在它的基础上加 为什么要把最简单的东西删掉？

[RPRX]

v5ray 没有删 h2 呀 姑且不说用的人多少 我喜欢它的简单 grpc split xmux 以及以后的东西 本质上都是在它的基础上加 为什么要把最简单的东西删掉？

v5ray 的文档中没有 h2 传输层，可能是因为比较 buggy（fly 的 h2 没修过），代码没删应该是为了是兼容 v4

多一个 h2 传输层就要多一些工作，比如要不要给它加 header padding、要不要加 xmux 支持，过于重复了

若实在想留着这种“最简单的东西”，可以把它变成 XHTTP 的一个 mode，即全双工，默认给 REALITY 用

其实现在我也不喜欢“HTTP 传输层”这个命名，和 HTTP 出入站还重名了，所以更倾向于干脆删掉它

[RPRX]

这样的话就干脆说是把 SplitHTTP 和 h2 传输层和 @yuhan6665 pr 的 h3 传输层合并为 XHTTP 吧，支持 header padding 与 xmux

[PoneyClairDeLune]

I hate to point out how jaw-dropping the comment supporting the removal of HTTP/2 transport is.

Let's start with the h2 transport, v5ray has been deleted, REALITY saved its life, otherwise it wouldn't have been used much more than the QUIC transport, and people prefer the grpc transport for cross-proxy software.

Is it really as you claim? HTTP/2 has been one of the longest-existing transports among the *ray ecosystem, and is currently one of the few transports to offer implementation-agnostic multiplexing support, predating gRPC by a long margin. As one of the fundamental transports, the existence of REALITY doesn't really matter for the adoption of HTTP/2.

If it's really an argument that V2Fly removed it in version 5... Well they marked VLESS as deprecated, and they added Hysteria 2 support. Is Xray going to follow suit? Feel free to merge the vanilla HTTP/2 into some other transport and provide an alias, but do not remove it.

gRPC? Until it could have custom header support...

[RPRX]

@PoneyClairDeLune 你的认知太浅薄我懒得说，如果你有问题，去 fork 一个 Yray

[RPRX]

@PoneyClairDeLune 说白话，你最大的问题就是没有看明白我要删 h2 传输层并不是因为 v2fly 删了，然后给我扯什么 vless 和 hy2。我要删 h2 传输层主要是出于自己的考虑，只是他们提到了与其它软件的兼容性，我才说 h2 传输层的老家早就不要它了，也就 Xray 主导的 REALITY 会用一下。还有 h2 传输层存在久不代表它用得多，没 REALITY 的话它比 XTLS 少得多，几乎没人用。

错误太多本来懒得喷，而且最关键的是，我不是来跟你们辩论的，而是一种通知，都说了 just trust me，每一步都是为了让 Xray 更好

[KobeArthurScofield]

看完之后感觉能接受。
分享链接标准会出名称兼容性改动吗

[RPRX]

分享链接标准会出名称兼容性改动吗

取决于搞出来的东西兼不兼容现有的 h2 传输层

[RPRX]

@mmmray So the plan is:

1. Merge SplitHTTP and HTTP into XHTTP, with header padding and xmux support, don't forget @yuhan6665's h3. Forget about steaming request for now as it is only for browser dialer, we can add it later.
2. Translate SplitHTTP as XHTTP, HTTP as XHTTP with the normal mode. Mark them as deprecated and will be deleted in v25.
3. When XHTTP is combined with REALITY, use the normal mode by defaul, otherwise use the splitiupload mode by default.

喝晕了只会打英文了懒得翻译成中文了卧槽，将就着看一下

[RPRX]

发现少打了一个 t，但喝晕了少打一个字母不是很正常吗，不改了

[RPRX]

甚至我都在 #3550 (comment) 写了有全双工模式，结果还跟你们扯了这么久，真他妈的无语了，可能是觉得两个半双工和全双工差不多，反正都在 TLS 或 QUIC 里面，也就是每个子连接需要两次 requests 而已

[RPRX]

I'm waiting for XHTTP, and I will not release the next version of Xray-core until XHTTP is ready, or there will be no next version.

[fodhelper]

gRPC has no xmux yet? or just undocumented?