As toomim also replied, HTTP/2 is fine, and honestly, is probably preferable for your use case, since you won't also have to deal with QUIC/UDP, and can keep us

As toomim also replied, HTTP/2 is fine, and honestly, is probably preferable for your use case, since you won't also have to deal with QUIC/UDP, and can keep using TCP. (HTTP/3 is ~90% the same as HTTP/2, just over a different transport layer, and ditching HTTP/2 prioritization mechanisms which you probably won't care about.) > A key point of our WebSocket and http transports is to support environments where TCP connections aren't available. Are there environments that would let us send and receive binary data following an http CONNECT that wouldn't simply allow an ordinary TCP connection? Based on the network diagram in your article, it looks like the edge functions speak HTTP to the proxy, upgrade that to WS, and then the proxy routes raw TCP to the conn pool/db. If so, CONNECT would be the same. The edge function sends an HTTP CONNECT request, the proxy would set it up, and afterwards, both hops are using the same transports as with websockets. The edge function would send HTTP/2 DATA frames wrapping the raw bytes, the proxy would unwrap those bytes, and then route the bytes over TCP to the conn pool/db. If I understand your setup correctly, HTTP/2 CONNECT would be applicable everywhere WS is.