All browsers released since the end of 2015 support HTTP2. If the server supports it the browser will use it. Unlike HTTP3 this is all TCP.

If you connect to a WebSocket over an HTTP2 connection then you don't need to worry about multiplexing since you can rely on the browser doing it for you - HTTP2 connections support over 200 concurrent streams.

I think we're talking about different types of multiplexing. Are you referring to the browser domain connection limit? HTTP/2 does essentially solve that.

I'm referring to opening multiple data streams on a single connection, which is very useful in a number of contexts. This is supported by HTTP/2 and HTTP/3, but it's only exposed directly to the browser runtime through WebTransport.

HTTP 1.1 did not support multiplexing and browsers limited you to six connections per domain. That made opening multiple WebSockets prohibitive so you would generally need to implement your own multiplexing of logical data streams on top of a single WebSocket.

HTTP2 and HTTP3 connections support the multiplexing of hundreds of streams across a single TCP or QUIC connection. Each stream can be a request or WebSocket. So now you can just open a WebSocket per logical data stream and leave the multiplexing to the browser.

So now you will have a single transport level network connection whether you use multiple WebSockets or implement multiplexing yourself atop a a single WebSocket.

Yeah we're talking about different things. Imagine you had a process in the browser that can respond to many concurrent long-running requests from the server. In order to handle this with WebSockets, you need to implement your own multiplexing, because a) the server can't initiate a new WebSocket connection to the browser and b) opening a new WebSocket connect for each request doesn't fit the paradigm of request-response very well.

Note that WebTransport handles this for you, because the server can initiate new streams.

If you're sending lots of data, you also need per-stream backpressure.