shoes icon indicating copy to clipboard operation
shoes copied to clipboard

[Discussion&Suggestion]: Mux protocols

Open radiumatic opened this issue 1 year ago • 5 comments

It's pretty evident that opening a new connection for each tunneled one eats through the battery pretty fast. So Mux seems a pretty good feature.

The problem that none of the mux protocols in Xray-Core and Sing-Box handle (for some reason) is that ISPs throttle long-lived connections. Maybe a switch can be added to move to a new connection after an arbitrary amount of time? (The same is true for Hysteria and QUIC, they're throttled after a while, port hopping would help those as well)

radiumatic avatar Dec 11 '24 15:12 radiumatic

I think the benefit of multiplexing is to reduce handshake delay, but the CPU usage is actually increased.

xiaorong61 avatar Feb 24 '25 10:02 xiaorong61

moving to a new connection would ideally be handled by the client - QUIC connections can have an idle timeout, but i am not sure a good way the server would handle force-closing a connection while it's still being used. session id/association ids eg in hysteria and tuic are connection-local; so it wouldn't be possible to continue a proxied TCP connection after the switch.

cfal avatar Mar 05 '25 17:03 cfal

the client would also need to support port hopping - you can listen on as many ports as you want on the server. there's no way that the server could coordinate with the client to close a port and switch to a new one when it hops, unfortunately.

cfal avatar Mar 05 '25 17:03 cfal

That's precisely what I meant. The client should use a different port on its end to communicate so the 4-way tuple changes shape. The server doesn't need to do anything.

radiumatic avatar Mar 05 '25 20:03 radiumatic

I think the benefit of multiplexing is to reduce handshake delay, but the CPU usage is actually increased.

Really? Still, it reduces the number of samples for detection and messes up size-timing fingerprints.

radiumatic avatar Mar 05 '25 20:03 radiumatic