WebTransport

[endel]

Request for position on an emerging web specification

Information about the spec

• Spec Title: WebTransport
• Spec URL: https://www.w3.org/TR/webtransport/
• GitHub repository: https://github.com/w3c/webtransport
• Issue Tracker: https://github.com/w3c/webtransport/issues
• Explainer: https://github.com/w3c/webtransport/blob/main/explainer.md

Design reviews and vendor positions

• TAG Design Review: WebTransport review request w3ctag/design-reviews#669
• Mozilla standards-positions issue: WebTransport mozilla/standards-positions#167

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Anything else we need to know

Chrome added their prototype support to it on version 97: https://chromestatus.com/feature/4854144902889472

[othermaciej]

I wonder if this could be built as an extension of the WebSocket API instead? It seems like an anti-pattern for each distinct network protocol to have a disjoint web-exposed API, even when the purpose is broadly similar. (I suppose one advantage of this way is that it's easy to feature-test client-side for support for the Web Transport protocol).

[litherum]

I think it’s pretty unfortunate that WebSocket, WebTransport, and some communication parts of WebRTC all seem to have overlapping goals and designs, and yet seem to have been developed completely in isolation from each other.

[hober]

cc @youennf

[youennf]

I wonder if this could be built as an extension of the WebSocket API instead?

Some parts could have been done this way but the WebSocket API is rather old.
Starting from scratch allows to build a more modern API (similar to XHR -> fetch). See for instance the integration with streams. The efforts to modernise WebSocket/RTCDataChannel have also stalled AFAIK.

Some functionalities are beyond WebSocket also (datagrams) so it would have been difficult to reuse WebSocket API.

It seems like an anti-pattern for each distinct network protocol to have a disjoint web-exposed API

We gave that feedback (initially the API was prefixed by QUIC for instance) and this was taken into account.
WebTransport is now defined as an abstraction on top of which different protocols can be used (H2 or H3 for instance...).

I think it’s pretty unfortunate that WebSocket, WebTransport, and some communication parts of WebRTC all seem to have overlapping goals and designs, and yet seem to have been developed completely in isolation from each other.

That is not entirely true. RTCDataChannel for instance is duck typing the WebSocket API for instance.
WebTransport is also being standardised with the help of WebRTC WG members.

WebRTC is a high level API that provides limited control on what happens on the network, but the defaults are pretty good and it works consistently.
WebTransport on the reverse is much lower level and leave most of the actual work to web pages.

[aboba]

For performance reasons, the WebTransport API intentionally did not use the message approach of WebSockets and RTCDataChannel. A problem was found in the WebSocket and RTCDataChannel specification which manifests in low-end devices such as mobile devices or game consoles. When the application's onmesssage handler cannot keep up with the volume of incoming messages, the TCP or SCTP receive window does not close to exert backpressure on the sender. This is because TCP/SCTP only track whether a segment has been transferred from the receive queue, not whether the message has been consumed by the browser application. This problem does not occur in WebTransport API, because the WHATWG streams supports back pressure and the WHATWG streams send and receive queues are kept small. Therefore if the application cannot keep up with incoming data, the QUIC receive window will contract, exerting back pressure on the sender.