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