Implement WebTransport (QUICTransport) API

[starkpsmichael]

Once we have QUIC support implemented, we should consider implementing the WebTransport API.

A long way to go, but just to have a place for discussions for this feature.

More informations:

• https://web.dev/webtransport/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[lucsoft]

Info: WebTransport will land in Chrome stable in 76 days (Jan 4).
If everything goes as planned

[ekanna]

Info: Webtransport landed in chrome 97

[mreinstein]

ieft just published rfc for http/3 : https://www.theregister.com/2022/06/07/http3_rfc_9114_published/

And just to add more acronyms, omg, bbq, wtf

[realtimetodie]

I am working on this

https://github.com/diceride/deno/tree/feat-ext-webtransport

[tom-sherman]

How does this feature relate to WebSocketStream that has already shipped and available in deno unstable?

As far as I understand WebTransport is a superset of WebSocketStream? The latter only supporting backpressure ontop of the existing WebSocket spec (ie. ordered messages).

[mreinstein]

How does this feature relate to WebSocketStream that has already shipped and available in deno

Really good question! WebSocketStream provides a way to have back pressure and other elegant streaming primitives via traditional websockets.

Web sockets are TCP based, and WebTransport is UDP based. It's usually presented as a tradeoff between reliable, ordered messages and unreliable but lower latency message delivery. e.g., most commercial multiplayer video games and video streaming apps are built upon UDP because latency is one of the biggest problems with these kinds of networked applications.

WebTransport's inclusion in deno will open up a new class of real-time apps, without having to resort to messy hacks like using WebRTC on the server, or having Websocket<->udp socket bridge apps.

[tom-sherman]

Web sockets are TCP based, and WebTransport is UDP based.

WebTransport also supports reliable delivery (TCP) via transport.datagrams. This API is essentially the same as WebSocketStream infact.

I suppose what I'm getting at is this: WebTransport seems to be a superset of WebSocketStream, and be mature with regards to its specification.

Has the Deno team considered proceeding with a WebTransport implementation instead of promoting WebSocketStream to stable?

[mreinstein]

datagrams are not reliable or ordered. UDP packets are typically datagrams (User Datagram Protocol). This is the key difference between websockets and webtransport.

WebTransport seems to be a superset of WebSocketStream

It's not. Under the hood they are fundamentally different transport protocols

Has the Deno team considered proceeding with a WebTransport implementation instead of promoting WebSocketStream to stable?

They are complementary; WebSocketStream is good for handling traditional websockets as streams, and WebTransport is good for enabling UDP.

[mreinstein]

Although technically if we want to get into the fine details, WebTransport is not pure UDP access either. It's another protocol that offers things on top of UDP, such as TLS encryption.

[tom-sherman]

Ah, apologies. I got this mixed up with streams portion of the API. From the web.dev explainer:

WebSockets communications are modeled around a single, reliable, ordered stream of messages, which is fine for some types of communication needs. If you need those characteristics, then WebTransport's streams APIs can provide them as well.

I don't see how then this can't replace WebSocketStreams as again, it seems to be a superset.

[mreinstein]

https://www.lifesize.com/blog/tcp-vs-udp/

think of websockets as the tcp example, and webtransport as the udp example

[tom-sherman]

@mreinstein it is a superset tho 😅

https://web.dev/webtransport/#stream

[mreinstein]

I understand what you mean now. There does appear to be a reliably-ordered stream API described in this explainer doc.

I'm not sure though that because both websocket streams and webtransport streams provide a similar api that webtransport is truly a superset. Under the hood they are still completely different transports, with different network behavior.

Maybe the better question is why shouldn't deno support both WebSocketStreams and WebTransport? They are both legitimate web apis with different use cases.

[realtimetodie]

No, WebTransport is neither a super-set of WebSocketStream nor are these Web APIs related. They are based on different networking protocols.

[realtimetodie]

The implementation should be finished by next week. I just need to get my ass up. No one is paying me for doing this and I'm just a simple blue-collar worker. I clean floors and move pallets within a warehouse. Computer programming is my hobby. I'm usually just too exhausted at the end of day.

[o-t-w]

There's a relevant discussion here WebKit/standards-positions#18
Both WebTransport and WebSocketStream are only prospective web standards at this point. Deno should only stabilise things that are actually standards rather than Chrome only. WebTransport is a draft spec, WebSocketStream doesn't even have a spec.

[petamoriken]

Deno should only stabilise things that are actually standards rather than Chrome only.

It makes sense. However, since Firefox will also implement WebTransport, it will soon become a web standard.
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/fe76d1e4-cd4c-be11-99d2-6a58550b39dd%40mozilla.com

[o-t-w]

Safari have now officially marked their position as "support". Also enabled in Firefox Nightly.

[lucsoft]

Quic is really the next big thing and I hope that the new flash server "rewrite" will have quic support.

[SOVLOOKUP]

https://github.com/BiagioFesta/wtransport

[lucsoft]

If HTTP3 is the current blocker for this feature wouldn't it be more beneficial for everyone if the first version would be WebTransport over HTTP2 and then when the time comes adding HTTP3 to it?

[mreinstein]

the first version would be WebTransport over HTTP2

That doesn't provide benefit because HTTP/2 lacks a non-TCP transport mode. Anything based on HTTP/2 would effectively have identical latency characteristics to websockets. The point of WebTransport is it gives you a UDP based delivery with encryption.

[lucsoft]

@mreinstein thats a myth quic is kinda like tcp on udp (simplified).
Because pure UDP could lead into data loss or out of order and so on.
So if you run it TCP you still get all the new stream based API features and stuff like back pressure.
The only effect would be datagrams as that is intended to be "unreliable".

[mreinstein]

thats a myth quic is kinda like tcp on udp (simplified).

It's not a myth, and it's documented pretty clearly, in both the chrome intro article:
https://developer.chrome.com/articles/webtransport/#datagram

As well as the mdn docs:
https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream