HTTP/2 support in the client

[vercas]

It would be wonderful if you could support HTTP/2 in the client at least.
This would greatly improve the performance when running the server behind a reverse proxy, to help mix wstunnel traffic with other HTTPS traffic.

[erebe]

Hello,

What do you mean by supporting HTTP2 ? Websocket is a different protocol than http2, and has less overhead than it. If you are referring to the first request (the upgrade one) which in made with http1.1 that's normal, this is the way ws protocol is doing handshake.

[vercas]

I mean this: https://www.rfc-editor.org/rfc/rfc8441

[erebe]

Thanks for pointing out the RFC, I understand better the request :)

Regarding its support, I won’t implement it because websocket over http2 is using the stream notion from it. Sadly, while using http2 stream would speed up the connection process for new tunnels, it will create a head of line blocking issue. All stream of a http2 connection share the same underlying TCP stream, which mean that if a packet is dropped for this http2 connection, all streams/tunnels are going to stale. As wstunnel, especially with socks5, can multiplex a lot of parallel stream, it is damageable for user experience.

If speed-up of new connections are an issue, you can use the -c option. You will get fast new tunnels, and without the issue of head of line blocking, as there is 1 tunnel per tcp connection.

 -c, --connection-min-idle <INT>
          Client will maintain a pool of open connection to the server, in order to speed up the connection process.
          This option set the maximum number of connection that will be kept open.
          This is useful if you plan to create/destroy a lot of tunnel (i.e: with socks5 to navigate with a browser)
          It will avoid the latency of doing tcp + tls handshake with the server [default: 0]

[vercas]

Fair enough.
I suppose the more future-proof course of action is implementing WebTransport for HTTP/3, but that's a different matter.
I'll close the ticket, then.