4 ms·
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 gen
by laurencerowe 3y ago
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.
- apitman 3y agoYeah 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.