Web Transport

TIL 358 words #webdev

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

TechnologyIntended UseDirectionOther LimitationsMDN
Web TransportReal-time, Bidirectional, can have sub streamsServer ↔ ClientHTTP/3 only. Secure context. No Safari (for now)MDN
WebSocketReal-time, Bidirectional communication over a single TCP connectionServer ↔ ClientMDN
SSE (Server-Sent Events)One way stream of data from serverServer → ClientMDN
Web PushLow frequncy updates, push notifications.Server → Browser’s Server → BrowserMDN
WebRTCReal-time communication (audio, video, data) between browsersClient 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.