HTTP/2 RFC 8441 WebSockets (Multiple websocket connections over a single TCP connection)

[feliperaul]

I was recently reading Falcon's async websockets guide here: https://socketry.github.io/async-websocket/guides/rails-integration/index#using-http/2

Found this piece interesting:

Falcon supports HTTP/2, which can be used to improve the performance of WebSocket connections. HTTP/1.1 requires a separate TCP connection for each WebSocket connection, while HTTP/2 can handle multiple requessts and WebSocket connections over a single TCP connection. To use HTTP/2, you'd typically use https, which allows the client browser to use application layer protocol negotiation (ALPN) to negotiate the use of HTTP/2.
HTTP/2 WebSockets are a bit different from HTTP/1.1 WebSockets. In HTTP/1, the client sends a GET request with the upgrade: header. In HTTP/2, the client sends a CONNECT request with the :protocol pseud-header.

Centrifugo does have a question about this in it's FAQ: https://centrifugal.dev/docs/faq#does-centrifugo-work-with-http2

Keep in mind that when using WebSocket you are working only over HTTP/1.1, so HTTP/2 support mostly makes sense for HTTP based transports such as our WebSocket bidirectional fallbacks (Server-Sent Events (SSE) and HTTP-streaming with bidirectional emulation) and unidirectional transports (unidirectional Server-Sent Events (SSE) and HTTP-streaming).

Asking Claude about this, it seems that Falcon implemented what is known as "RFC 8441 WebSockets". Even tough this is from 2018, it seems that it's not widely implemented, but the mention that it can support multiple Websocket connections over a single TCP connection seems interesting.

Curious to know what the impact on scaling this could unlock for Centrifugo - if any -, and if there's any plan to support this in the future.

[FZambia]

Regarding HTTP/2 and https://www.rfc-editor.org/rfc/rfc8441.html - it's generally interesting, and it should be possible in Go now, or very soon (need to read golang/go#53208 more carefully).

The question here though is how traffic is load balanced. Usually Centrifugo nodes are placed behind reverse-proxy or load balancer. So in this scenario need to understand whether balancer proxies HTTP/2 traffic to the backend upstream, or it's HTTP/1.1 traffic. So maybe https://www.rfc-editor.org/rfc/rfc8441.html should be first supported on that level.

If you see the potential of having that with you stack – let me know, any information may help to have a better understanding.