A lot of people here seem confused why this is needed or wanted with WebRTC. I sat in the BOF session at IETF 106 in Singapore last year when we talked about this. Happy to answer any questions as I understand them. (Though I'm no expert.)
Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets. You can think of it like websockets but better (faster handshake, it reuses the http2 / QUIC connection, and you can relax websocket's reliability & ordering constraints). Or you can think of it as WebRTC, except way simpler for the 95% case where you want to communicate server/client.
I'm excited about it for browser based video games.
It looks complicated, but there's very little thats new here for browsers and web servers to implement. Remember QUIC is already built on top of UDP, and internally, QUIC supports basically all of webtransport's features natively. Webtransport mostly just re-exposes many of QUIC's features to applications. Browsers and HTTP servers are adding all that functionality anyway - so we may as well take advantage of it in our web applications.
My favorite criticism voiced at the IETF was the name - webtransport has nothing to do with the web, and its not a transport. Its mostly just an application API around some of QUIC's features, with fallbacks for HTTP 1.1 and HTTP2.
You are right. If browsers would expose APIs which would allow to access request and response bodies in a streaming fashion then HTTP/2 (and actually even HTTP/1.1 with chunked encoding!) can be alternatives to websockets.
The remaining difference would be websockets having builtin frame delimiters and a meaning of text and binary frames - whereas with HTTP streams you would need to do that on the appliction level.
Getting Streaming APIs for HTTP was planned to be part of the ReadableStream and WritableStream extensions for fetch - but I have no idea how that effort went since I last looked at it (5 years ago).
HTTP is still very much geared towards request/response semantics, just sometimes serving requests you didn‘t yet know you want to make.
Also, WebTransport seems to be more of an extension of the idea of WebSockets to UDP and other reliability/ordering semantics than an outright replacement.
There’s some discussion around doing HTTP/2 streams (reliable, stream-based) with the fetch API (I am not certain which browsers allow for this), but note that these are only one use of WebTransport - the main thing I’m excited for is doing unreliable datagrams without bringing in an entire WebRTC stack.
Yeah, but what does that have to do with what I wrote? My question is, if HTTP can now do streaming and all of these other useful things that you previously got with WebSockets, why do we need a WebTransport API? Why don't we just use HTTP instead?
> But right now I dont see QUIC from non-google server at all.
You won't see webtransport appearing for awhile either. Its all still in draft status. The IETF doesn't rush these things.
And for what its worth, the spec for Webtransport is being worked on with close collaboration with the QUIC (HTTP/3) working group at the IETF. Everyone wants webtransport and QUIC to be a good fit for one another, and straightforward to implement in browsers once its ready.
I worry about over-engineering too; but the best way to express those fears is to get involved. Standards are written by those who show up. And the IETF welcomes anyone who's interested to join the mailing lists and attend IETF sessions. (So long as you accept the community norms.) Even the in-person events (when they come back) bend over backwards to welcome remote attendance and remote questions.
This is the video of the webtransport BoF session from Singapore last year, if you're curious how this sort of thing plays out in person. There were only about 25 people there:
Safari will likely be the last browser to support HTTP/3 as it will only be available in the unreleased MacOS 10.16. HTTP/3 is already in the other browsers with instructions on how to enable [0]. Firefox Nightly and Chrome Dev already support Draft 29 (which is Working Group Last Call [1].
Websockets work on HTTP/1.1 (not later versions) and turns the TCP connection into a packet-based transport, unrelated to HTTP.
WebTransport works on HTTP/3 and exposes a part of the underlying UDP QUIC connection (while still allowing HTTP/3 messages to travel across the same underlying connection), allowing for stream-based or packet-based subconnections, reliable or unreliable. Basically, it’s a lot more flexible and doesn’t require setting up an entire new connection to work.
> Is there anything wrong with websockets? I thought websockets were cool.
I'm excited for the option of having an unreliable connection. Currently you'd need to establish a webrtc data connection to the server, which is a bit cumbersome when you really don't need or want the rest of webrtc.
tl;dr seems to be "probably" - my setup for this would be a MediaRecorder on your webcam and microphone input, piping data into a modified version of SRT for some level of reliability, error correction and buffering so the data arrives at the decoder at the right time. The problem is that MediaRecorder is not particularly configurable, and seems to spit out something different from the WebRTC encoder.
I can't find the video link, but the slides from that session are here: https://datatracker.ietf.org/meeting/106/materials/slides-10...
Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets. You can think of it like websockets but better (faster handshake, it reuses the http2 / QUIC connection, and you can relax websocket's reliability & ordering constraints). Or you can think of it as WebRTC, except way simpler for the 95% case where you want to communicate server/client.
I'm excited about it for browser based video games.
It looks complicated, but there's very little thats new here for browsers and web servers to implement. Remember QUIC is already built on top of UDP, and internally, QUIC supports basically all of webtransport's features natively. Webtransport mostly just re-exposes many of QUIC's features to applications. Browsers and HTTP servers are adding all that functionality anyway - so we may as well take advantage of it in our web applications.
My favorite criticism voiced at the IETF was the name - webtransport has nothing to do with the web, and its not a transport. Its mostly just an application API around some of QUIC's features, with fallbacks for HTTP 1.1 and HTTP2.