
WebTransport API - Jarred
https://wicg.github.io/web-transport/
======
josephg
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.)

I can't find the video link, but the slides from that session are here:
[https://datatracker.ietf.org/meeting/106/materials/slides-10...](https://datatracker.ietf.org/meeting/106/materials/slides-106-webtrans-
webtrans-bof-slides-03)

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.

~~~
Touche
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.

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

~~~
Touche
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.

------
dfabulich
Folks who are interested in the WebTransport API may find it easier to read
the "explainer" document. [https://github.com/wicg/web-
transport/blob/master/explainer....](https://github.com/wicg/web-
transport/blob/master/explainer.md)

It addresses a number of the top comments here, e.g. why not just use WebRTC
data channels:

"While WebRTC data channel has been used for client/server communications
(e.g. for cloud gaming applications), this requires that the server endpoint
implement several protocols uncommonly found on servers (ICE, DTLS, and SCTP)
and that the application use a complex API (RTCPeerConnection) designed for a
very different use case."

------
smaddock
The WebTransport API looks to bring WebSockets up to speed with similar
features provided by WebRTC: reliable or unreliable connections and
multiplexing. The addition of a Stream interface means it will be efficient
for uploads and downloads too.

I can see this replacing most use cases of WebSockets once brought to
ubiquity.

~~~
saurik
Do you know the answer to "Why not just use WebRTC?"? I am used to documents
like this having an explanation of the "why", but I am not seeing it here (or
an extra stupid today).

~~~
smaddock
I use WebRTC and WebSockets in a side project of mine [0]. WebRTC requires
coordination of multiple services and fallbacks (relay servers) when peers
can't establish a direct connection due to firewalls among other things.

STUN, TURN, and ICE are a few technologies you need to understand to get
started with WebRTC. I'd guess most folks aren't familiar when first looking
into it.

The complexity is worth it if you're determined to push most bandwidth costs
to clients like I am.

If you want near 100% connectivity at a lower complexity, WebSockets are
almost always preferred.

[0]
[https://github.com/samuelmaddock/metastream](https://github.com/samuelmaddock/metastream)

~~~
smaddock
Additionally, during the 3 years I've had experience with WebRTC, I've come
across at least 2-3 browser bugs causing compatibility issues when connecting
peers cross-browser.

This is just not something you run into with WebSockets.

I'd recommend simple-peer for anyone who does choose to use WebRTC. The
maintainers are usually able to smooth these issues out in a reasonable
timeframe. <3

[https://github.com/feross/simple-peer](https://github.com/feross/simple-peer)

~~~
Sean-Der
I don't think the issues with WebRTC is the protocol, but the tooling. The
community did a really good job of creating tooling for Websockets with stuff
like [https://github.com/crossbario/autobahn-
testsuite](https://github.com/crossbario/autobahn-testsuite). There is nothing
like that for WebRTC.

We tried to do it, but the IETF event was cancelled
[https://twitter.com/steely_glint/status/1230447935307026432](https://twitter.com/steely_glint/status/1230447935307026432).
I am hoping that in the next 6 months we can have something like that so that
all the WebRTC implementations will work together a lot better.

------
francislavoie
How is this expected to work for apps that having a webserver fronting the app
that terminates TLS/QUIC/HTTP3 and proxies over fastcgi/http1.1/h2c for
example?

Specifically, how would this work for say, a PHP app that wants to stream
stuff? I use [https://reactphp.org/](https://reactphp.org/) for websockets in
PHP (so I can have a shared codebase with my main app, etc).

I don't think I understand how this would look on the server-side. I'm
interested to understand how it would look like to support this in Caddy (I'm
one of the core contributors).

------
bullen
If you need real-time both-ways communication in the browser you could look at
Comet-Stream (since IE7 is now in all practical senses gone). It's simpler,
consistent and scales like a monster on the server:

[https://github.com/tinspin/rupy/wiki/Comet-
Stream](https://github.com/tinspin/rupy/wiki/Comet-Stream)

The only thing that is annoying in the browser is that Chrome does not allow
you to remove or change the User-Agent header which wastes a little bandwidth.

~~~
lxgr
What is the benefit of this over WebSockets? More generally, what is it even,
and what problems does it solve?

~~~
bullen
It uses HTTP/1.1 so it goes through all firewalls and the server
implementation is simple enough for it to be rock solid and it scales with
"joint parallelism" which only Java can do because of the complex memory-model
and VM.

Rupy is a complete beast in terms of multi-core power, as long as the selector
thread is not saturated it can scale linearly on all cores on shared memory =
no memory copying or locks like all other solutions!

But the real upside is you get one process for async. HTTP (client and
server), including database; which means you can use micro services the way
they should be used by hosting all services on all machines and call them
locally = more robust and less complex (no discovery after the initial client
-> server DNS) completely without IO-wait!

WebSockets are completely over-engineered, as is HTTP/2 and 3...

So to answer your question: rupy is the final solution to internet servers. ;)

Now I'm working on the final solution for internet clients:
[http://talk.binarytask.com/task?id=5959519327505901449](http://talk.binarytask.com/task?id=5959519327505901449)

And internet 2.0: [http://radiomesh.org](http://radiomesh.org)

And the final computer:
[http://talk.binarytask.com/task?id=8015986770003767235](http://talk.binarytask.com/task?id=8015986770003767235)

~~~
fulafel
What do you mean by joint parallelism?

~~~
bullen
Most parallel systems are embarrassingly parallel = they are trivial to
distribute in the first place = you could run them on separate machines.

Joint parallel is the opposite of that, where you need very fast shared memory
between the cores. Meaning all cores touch all data, it's a rarer form of
parallelism because it is hard.

But if you want to write a MMO server f.ex. you need to understand how this
works all the way down to the hardware.

~~~
fulafel
Ok. I think fine-grained parallelism is the established term for this.

~~~
bullen
Partly, but "fine-grained parallelism" refers to how small you can make the
sub-parts of the parallel execution and then adds "Another definition of
granularity takes into account the communication overhead between multiple
processors or processing elements." which is confusing! t compute / t
communicate (where communicate probably does not differentiate between memory
copy and waiting for memory due to a lock or cache-miss)?

According to that definition If you have a really tiny task that has fast
memory (embarrassingly parallel + little memory) and a huge task that has
really slow memory they are the same (1/1 == 100000/100000) so really what
does that definition say!

Also it seems only instruction levels of parallelism are fine-grained. This
means everything I will ever do and talk about is coarse-grained. So how can I
tell people my software is 10x faster than Erlang for a MMO type of server
problem space?

I'm going to access contiguous memory with 2 separate threads simultaneously
without locks in C when I finalize my 3D MMO engine client this fall and then
I'll understand more on how these things really work, right now I'm a little
confused.

I think "Joint Parallelism " is more telling, it puts focus on the bottle neck
of our civilization which is / and will always be: memory speed!

F.ex. Erlang is completely meaningless for "joint parallelism", because it
uses memory copying instead of monitors/locks and even there Java can be even
more performant according to the creator of the Java concurrency package:

"While I'm on the topic of concurrency I should mention my far too brief chat
with Doug Lea. He commented that multi-threaded Java these days far
outperforms C, due to the memory management and a garbage collector. If I
recall correctly he said "only 12 times faster than C means you haven't
started optimizing"." \- Martin Fowler
([https://martinfowler.com/bliki/OOPSLA2005.html](https://martinfowler.com/bliki/OOPSLA2005.html))

I have mailed Doug to get an explanation, but the only thing I can tell you is
that my implementation of what he talks about in that quote is proof that he
is right. How he is right, I still don't totally understand! He hasn't and
probably wont reply though!

More worrying is the memory copying that the kernel is doing, I think the last
step for computing advances is to go back and simplify the OS.

My prediction is that we will get kernel bypass for network IO pretty soon and
disk IO will follow after that, at least for servers.

------
Fr33maan
finally a specification for datagrams, unordered and unreliable ! This was one
of the big struggles of bringing mmo to the browser. DatagramTransport seems
really promising as it provides encryption and congestion control which are
the most complicated parts of any netcode. Good luck !

~~~
toomim
SCTP already provides that in WebRTC.

~~~
seangrogg
But requires a lot of mucking around with STUN/TURN/ICE, which is far less
desirable than just "send UDP packets to a browser".

~~~
pthatcherg
You don't need to use STUN and TURN for client->server use cases, but you do
need ICE, DTLS, and SCTP.

------
fulafel
I think this is harmful for the internet because we need webrtc to become more
ubiquitous, to keep it from being blocked at firewalls.

Also webrtc functionality is a superset of this so it's not a technically
necessary protocol.

~~~
pthatcherg
If anything, an increase in the use of QUIC will reduce the amount of UDP
blocking, which would be good for WebRTC.

~~~
fulafel
I think UDP is often whitelisted by port in these cases and rarely blanket
blocked, as dns, VPN protocols etc are still needed. So quic, webrtc, and
webtransport all have their own battles.

------
jand
To my understanding, the ability to perform browser-to-browser communication
with WebTransport API is not touched by the document. Is my reading right?

~~~
pthatcherg
That's in a separate doc. Search for "RTCQuicTransport".

------
vasilvv
Really glad to see people excited about this!

If anyone is wondering if this is already implemented anywhere, we're
currently experimenting with it in Chrome:
[https://web.dev/quictransport/](https://web.dev/quictransport/) \-- I'd be
curious to hear what people think about it.

------
gioscarab
Could PJON [https://github.com/gioblu/PJON](https://github.com/gioblu/PJON) be
used as one of the underlying pluggable protocols? It would be cool to be able
to use the browser along with an open-hardware physical network
infrastructure.

