Web Transport

TIL358 words#webdev

There is a new (to me) way to communicate between the browser and server - Web Transport. MDN

Technology Intended Use Direction Other Limitations MDN
Web Transport Real-time, Bidirectional, can have sub streams Server ↔ Client HTTP/3 only. Secure context. No Safari (for now) MDN
WebSocket Real-time, Bidirectional communication over a single TCP connection Server ↔ Client MDN
SSE (Server-Sent Events) One way stream of data from server Server → Client MDN
Web Push Low frequncy updates, push notifications. Server → Browser’s Server → Browser MDN
WebRTC Real-time communication (audio, video, data) between browsers Client A ↔ Client B ( could be a server) MDN

Web Transport fills a similar niche as Web Sockets. But it has a neat potential advantage over it. It allows multiple streams to be created on the same connection - crucially, each stream does not stall the connection. This solves a problem with Web Sockets where each message is sequentially processed. So if you send a large message followed by lots of small messages, the client has to wait for the large message.

In Web Transport, multiple independent streams can be created, allowing simultaneous processing of different message types.

example use case

Picture a collaborative document editor where multiple users are working together:

With Web Transport, all these can flow independently on the same connection, so cursor movements remain responsive even when large document changes are being processed. Unlike WebSockets, one user’s large edit won’t stall another user’s cursor position updates.

A prior solution was to open multiple WebSocket connections, one for each type of message. But this has a large overhead.


Also of note is the Background Synchronization API MDN although that is not really supported and is not triggerable from the server.