WebTransport Proposal

#1

API that allows web applications to establish interactive, bidirectional, multiplexed network connections

It fills gaps in the web platform:

  • Lack of UDP-like networking API
  • Lack of WebSocket-like API without head-of-line blocking

It provides:

  • Reliable streams
  • Unreliable datagrams
  • Encryption and congestion control
  • An origin-based security model
  • Bindings for QUIC
  • Multiplexing with existing HTTP/3 connections
  • Flexible API that can be extended to other protocols, such as TCP fallback and p2p
  • Ability to change transport without changing application code

It’s great for:

  • sending or receiving high-frequency, small messages that don’t need to be reliable (like game state)
  • sending or receiving low-latency media
  • transferring files

See the explainer for more info.

See the proposed spec.

9 Likes
A list of proposals that can make PWAs substantially more powerful, useful, and comprehensive
#2

I wrote up Internet Drafts for how this would look on the wire: https://github.com/vasilvv/webtransport

Feedback would be much appreciated. I believe people would find the Http3Transport one interesting.

#3

If I’m understanding correctly, this could technically support TCP, but that hasn’t been explicitly considered so far?

If so, I think it would be great to make TCP something promised by the spec. Admittedly, we would likely need to place restrictions on the domains a page could access, and add permission prompts. Those could be bypassed in the case of QUIC. I think that shouldn’t put people off, however, as it would fill such a huge gap in the web today - email clients, database explorers and a whole host of other applications could be built. I know this has been generally something for extensions, and that there are concerns about DDOS attacks. However, I think this will give the web too much power to miss out on, and hence is a challenge we should embrace.

#4

WebTransport is designed to be an API that can map onto different protocol, so it’s possible it could map onto TCP. However, there are some considerations:

  1. TCP is already available via WebSocket. Victor (vvv) is planning on writing an implementation of the WebTransport API on top of WebSocket so that one could have a better API but with existing protocols (an API with multiple streams, albeit with head of line blocking).

  2. For security reasons, a TCP-based WebTransport would likely be TCP+TLS, not just TLS.

  3. Again, for security reasons, the server would need to opt-in to the client’s connection much like the QUIC WebTransport (QuicTransport) does, and like WebSocket does. This would require changes to the servers that you want to connect to which would be similar to supporting WebSockets (which could already do).

  4. TCP would prevent many of the benefits of WebTransport: support for multiple streams and avoiding head-of-line-blocking. A protocol on top of TLS/WebSockets could provide for multiple streams (much like vvv plans to write, or HTTP/2 does), but you still have head-of-line blocking.

So, it could be done, but I’m not sure how much you’re gaining compared to what you can do now with WebSockets. On the other hand, it might be worth doing something for good fallback for networks on which UDP is blocked (and thus QUIC and HTTP/3 cannot work).

#5

I very much endorse the idea but not the proposed API as explained a while ago.

This API should use streams.

#6

I’ve been meaning to make a branch that uses WHATWG streams. We have built a very early prototype in Chromium that uses ReadableStream, which sheds some light on how feasible it is.

#7

OK, here’s a branch with an explainer that uses WHATWG streams:

Take a look. If you think that’s good, I could update the spec in that branch as well.

#8

[BA] Not only would the API not provide gains over TCP, it could hurt. Head-of-line blocking can have very undesirable effects on the behavior of applications written to the API – loss on a TCP connection will block i/o on all streams sharing that connection. That would not happen if individual TCP connections were used. Overall, an application desiring fallback would do better to utilize legacy APIs (e.g. Websockets) if QUIC is unavailable, even if more code is required to do so.

#9

I’ve been trying to reach out to people shipping games for the Web and gather their thoughts on this proposal. Jukka Jylänki (Unity) provided the following comments, which I found really helpful:

Pthatcher’s notes on the missing gaps (unordered datagrams, avoiding head-of-line blocking) are spot on. Something I’d like to highlight here is that WebRTC data channels did add UDP-like communication, but because of the complexity involved in implementing both a client and a server stack for WebRTC data channels, adoption has remained practically zero in games. Contrast this to WebSockets, which is quite lightweight in its definition, and much easier for a programmer to implement a client stack or a server stack to converse in WebSockets.

In order for any kind of new server-client protocol spec to be successful, it is not enough that there is a spec for the feature that browser/shell vendors implement as part of a tight spec+development iteration cycle, but the spec needs to be friendly towards independent implementors who need to ground up build a stack to talk the protocol. Back with WebRTC the browser implementations were initially riddled with quirks that were not well defined in the spec, and Chrome and Firefox had a long tail of bug bashing work stemming from confusion with unspecified scenarios, due to the complexity of the spec. So I would like to stress how important it is that a protocol spec of this kind is built up with simplicity and practicality in focus, keeping independent implementations in mind. Reading through https://pthatcherg.github.io/web-transport/ , it has user guide examples, and from there the transport spec leads to https://tools.ietf.org/html/draft-pauly-quic-datagram-02 which is a bit short treatise - so I am not sure how much work will currently be involved in implementing the protocol stack.

In summary, “implementor’s guide” is as important as “user’s guide”, or perhaps even more important, to guarantee adoption.

It is great to see efforts on this front progress - game networking with WebSockets is really painful, and game networking with WebRTC data channels is too messy to pull off.

I think the part about independent implementers matches with what we’ve been trying to achieve with QuicTransport design: minimizing the gap between basic QUIC and QUIC as useful for the web.

#10

I’ve gave a brief presentation on Wednesday at the QUIC IETF interim meeting (slides). Some notes on the feedback that I got while at the meeting (pthatcher has his own notes, so he should feel free to correct me if I’m missing something):

  • Mark Nottingham noted that due to freeform nature of WebSockets, the service providers in traditional HTTP space (CDNs, load balancers, etc) have struggled to provide services for WebSockets, and this will likely be the case with this proposal too.
  • Roberto Peon said he’s very interested and “have been waiting for something like this for 8 years”, and provided some helpful comments about importance of scatter-gather and TTL that is transmitted across hops (something I should add to Http3Transport at some point).
  • Mirja Kühlewind pointed out that we should take a closer look at TAPS, since a lot of the design problems we have are also faced by TAPS.
  • Lucas Pardue mentioned that there might be projects at Cloudflare that would benefit from API like this.
  • David Schinazi said he’s interested in Http3Transport as a potential basis for MASQUE.

I feel like we do have a fair amount of interest. I’m also pretty convinced that there will be a fair share of smaller Web developers to whom I don’t have good means of reaching out to who would benefit from this proposal. At this point, is it possible for us to go ahead and move the draft to the WICG org?

#11

Sounds like there is wide-agreement on the use-case the proposal is solving, even if not on all the proposal’s details. which is a great starting point for more engaged incubation.

Moving the repo over to the WICG org SGTM.

1 Like
#12

And I’m interested enough to sign up to make comments and other contributions :slight_smile:

#13

The repo is now live at https://github.com/WICG/web-transport!

1 Like