Hacker News Reader

Websockets but with UDP, and without all the offer, answer, TURN/STUN complications that webRTC brings? Lovely! Thanks for explaining!

Isn't http2 basically a replacement for websockets already? It's bidirectional. Has streams. Just missing a way to create a stream in browser iirc.

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.

Not sure if you missed it or not but QUIC is HTTP3. It has known advantages that are highly valued in domains like games as josephg has mentioned.

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?

Theoretically maybe, practically definitely not.

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.

Optional reliability and ordering is very important for real-time multiplayer games. Websockets doesn't support this as it uses TCP.

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).

You can read the response body as a stream, so that part works. You can't (last I checked) write to your request body. That's the only missing piece.

>Browsers and HTTP servers are adding all that functionality anyway

I am going to assume things will improve one HTTP/3 is finalised. But right now I dont see QUIC from non-google server at all.

And I cant help but think ( May be it is just me ), are we trying to over-engineer the Internet?

Edit: I just check on the clients side. Turns out Safari 14 may be the first browser to ship with HTTP/3 enabled by default.

> 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:

https://play.conf.meetecho.com/Playout/?session=IETF106-WEBT...

Or the direct youtube link (without the text from remote participants): https://youtu.be/o5cJEuO2-vk

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].

0. https://www.bram.us/2020/04/08/how-to-enable-http3-in-chrome...

1. https://mailarchive.ietf.org/arch/msg/quic/F7wvKGnA1FJasmaE3...

> Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets.

Is there anything wrong with websockets? I thought websockets were cool.

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.

WebSockets are not cool if you ask anybody who's worked with them in gaming. :)

This is great. One of the biggest hurdles for WebRTC is the sheer number of technologies used to create it.

I might have just found a weekend project.

Can I use WebTransport for multi-tenant non-p2p video conferencing?

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.