Using WebTransport
web.dev
web.dev
That's disappointing. I have a peer-to-peer application where I'd like to be able to use QUIC streams rather than the current SCTP-based WebRTC data channels. In particular, it seems to me that QUIC streams would be better for transferring files peer-to-peer in a way that takes full advantage of available bandwidth without causing congestion or doing excess buffering on the sending end.
Edit: if I'm reading this correctly, then maybe there are already efforts underway to make this possible: https://github.com/w3c/p2p-webtransport
(I'm one of the original authors of the WebTransort spec and when I worked at Google years ago, some excellent engineers on my team shipped the original QuicTransport behind a field trial).
I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets.
> Additionally, there are performance benefits when establishing new connections, as the underlying QUIC handshake is faster than starting up TCP over TLS.
Huh? This isn't a problem for HTTP/3 in general, because there's only a single quic connection (as long as you're talking with a single endpoint). So creating new Websocket streams should just create a new quic stream within the same connection transparently – I mean... this is the main point of HTTP/3. This sounds like an argument against adding another almost identical standard. Can someone explain?
If they want datagrams (which I can kinda understand), why not just add that as an extension to the Websocket spec?
Maybe your products don't use Websockets but the days of polling HTTP requests are long gone. Almost every web framework I know has some kind of support for websockets in its design and every proxy I know can easily handle websockets.
Sure, stuff like lambdas don't work but that's because the proprietary cloud provider API chooses not to implement them, probably for good reason. These types of programs are abstractions on top of abstractions, taking away all difficulty in multi server scaling at the cost of low level control over your code, and it turns out Websockets are just that: low level, stateful APIs that people wanted the browser to have.
The reason WebTransport is implemented is that people wanted UDP websockets. Unity developers have been asking for this stuff for years, for example, because running game logic over TCP out even QUIC can be terribly slow and stuttery. The websocket stack isn't really built for datagram exchange and support for the new feature depends on other factors (HTTP/3, for one) so I think it makes sense to make this a separate API. The mental model of what APIs are out aren't lossy is a lot clearer this way.
Http/3 already uses quic so this is just using quic datagrams, which is sane.. But why not an extension to websockets (only available over http/3) when everything else is the same?
EDIT: Got annoyed enough to look it up and I think this is the key:
> While WebSockets starts as a HTTP/1.1 protocol, WebTransport works on top of several different protocols, including some that WebSockets doesn’t support.
So apparently you have to start websockets over http/1.1 before upgrade which necessitates a separate connection per stream. Still, couldn't this be.. Fixed within the existing spec, or a major version bump? In either case, I guess it doesn't matter much, but I suspect a lot of people will be confused with the name.
An breaking update in the HTTP spec would be quite painful, especially for backend libraries that are often updated only when absolutely necessary.
The fact the API isn't even finished yet, let alone standardised, also makes it a good idea to add it as a new feature. I don't think browsers should mess with standardised protocols to implement some draft that's still in progress because they're very likely to break something, especially since this particular type of socket is only available to a small number of websites and use cases (those on servers supporting transferring raw HTTP/3 to the application server, so probably not most CDN/DDoS protection services).
What do you think it was/is? (not disagreeing)
While it's certainly doable, it's disruptive to horizontally scale websockets servers and depending on how you use it, can result in significant amounts of duplicated data transfer.
From cost and UX perspectives, it's just not worth it. Either use websockets and accept the fact that you'll always be paying for all the capacity you might need or give up and poll a low latency endpoint.
That's how I've always done it for scalable deployments of my remote browser isolation service.
I'm sure there's something I'm missing though but I still can't figure out what.
I'd really like a little more getting started advice here. I'm not sure which if any http3 implementations have webtransport support.
I went looking last week for webtransport support, interested in playing around. I thumbed through QUIC implementations[1], and came close to concluding I was just too early to try to use webtransport. Even though it shipped in Chrome 97, >9 months ago.
[1] https://github.com/quicwg/base-drafts/wiki/Implementations
If you want an example of an application that actively benefits from using WebTransport, there's a proposed video streaming protocol called WARP: https://datatracker.ietf.org/doc/draft-lcurley-warp/
The lack of good examples mostly stems from the fact that there isn't really that many publicly available server libraries yet. The two I can name off the top of my head are aioquic (Python) and the Google QUIC implementation used in Chromium and ENvoy -- the latter is sadly not trivially embeddable by third-party code (I work on it, and I've been trying to make it easier to use, but given that it's a large C++ codebase with a lot of dependencies, this has been taking a while).
[1] Open Transport. (2020, November 19). In Wikipedia. https://en.wikipedia.org/wiki/Open_Transport
I think it's missing a killer app. But I am not sure what WebTransport would enable that isn't already possible with current APIs. Unreliable datagrams? WebRTC. Reliable bidirectional communication? WebSockets. WebTransport probably would make some of the usecases easier or more efficient but it's value proposition isn't well communicated or better yet, demonstrated.
To be clear: I like WebTransport and want to see it supported widely. But it needs a bit better communication of its value proposition. It needs a bunch of examples for both client and server side. Ideally with a comparison to their WebSocket and WebRTC counter parts to highlight the advantages.
EDIT: Chrome on Android DOES support WebTransport. I previously claimed it doesn't based on the incorrect info on https://caniuse.com/webtransport but have since verified it myself that at least Chrome v103 on Android 12 does indeed support WebTransport.
It's was an interminable wait for WebRTC data channels.
Is there a trivial way to get a WebRTC connection to a server now, without pretending that server is a peer and doing the whole handshake dance?
It's gotten better now, but WebTransport is the solution we've needed for a while.
I’m not the one who worked directly with Pion so I don’t have direct feedback on it, but one thing I think would do a lot of good for WebRTC data channels becoming widespread is client and server nodejs bindings that abstract away all the complexity so that it is as easy as using websockets. If developers could implement this stuff without having to learn acronyms like TURN and STUN, I think it could be pretty popular.
[1] https://twitter.com/drifting_corp/status/1552773567649091584
For my small projects I run my HTTP + WebRTC in the same server. My signaling is one POST. Maybe I am missing the complexity, but I don't feel any additional pain compared to running any network service?
> STUN Karate
Mind explaining more? You don't use STUN for connecting to a world routable host.
If you need it I use https://github.com/pion/turn and run my STUN server embedded in my HTTP server. I do do anything but point my `PeerConnection` at `my-service.com`
But then I test every xth frame to see if the peer or the socket is faster and switch to that. Websocket is often faster, but not always, so in practice I end up splitting the stream over both websocket and webrtc in real time.
I feel like this is partially because the main value of the API comes from working better on lower-quality networks, rather than providing the ability to do something completely brand new.
> FF and Safari don't support it yet.
For what it's worth, Mozilla are positive about it [0] and are actively involved in the standards process. I don't believe the WebKit team has stated their position, though there are Apple people who are involved in the standards process too.
> I think it's missing a killer app. But I am not sure what WebTransport would enable that isn't already possible with current APIs.
When we started out working on WebTransport, there were two major use cases we had in mind: live media and web games. IETF MoQ working group [1] will hopefully address the first one. I don't know whether anyone is using it for building games, but I don't actually have that much visibility into what's going on in that space.
[0] https://mozilla.github.io/standards-positions/#webtransport [1] https://datatracker.ietf.org/wg/moq/about/
Interesting, do you have a source? Or did you try it?
> I am not sure what WebTransport would enable that isn't already possible with current APIs. Unreliable datagrams? WebRTC. Reliable bidirectional communication? WebSockets. WebTransport probably would make some of the usecases easier or more efficient but it's value proposition isn't well communicated or better yet, demonstrated.
The article does seem to answer these questions.
> Interesting, do you have a source? Or did you try it?
> The article does seem to answer these questions.
I wonder btw why they compare WebTransports datagrams to WebSockets reliable streams. The equivalent to WebSockets would be the reliable Streams API of WebTransport. The issue with Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol.
Yeah, it seems there's an older entry in there that's confusing. Not sure.
> There's no usecase mentioned that is not possible today
WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods.
> Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol.
Yes, and solving it within the protocol is simpler and more efficient.
> It needs a bunch of examples
Agreed, that would be nice.
> Yeah, it seems there's an older entry in there that's confusing. Not sure.
> WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods.
Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin"
It won’t see adoption until firefox adopts it and HTTP/3 starts gaining traction. But I’d say it’s a lot further along than the “coffee stained napkin” stage. It’s older than covid.
So?
> It’s made it’s way through the IETF and W3C
It's status at W3C is "editor's draft"
> and it’s been implemented in Chrome and Edge since the start of the year.
Which makes it a Chrome-only non-standard.
> It’s older than covid.
Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track.
There's a process to get features like webtransport into browsers and available everywhere. The process started with some proposals at W3C, continued with some discussions and specs being written up at both the IETF and the W3C. The work more-or-less concludes with broad browser support and applications being written using the spec.
The process takes years and its nearly complete. Webtransport has been in the works since at least 2019. Support has landed in Chrome and Edge. Hopefully we'll soon see the spec be ratified, get implementations in Firefox and Safari and then we can start using it in production software.
You said:
> Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin"
We've come a long way from "a draft on a coffee-stained napkin". A draft on a coffee-stained napkin wouldn't have shipping code in Chrome. Just because you can't use it yet in Firefox doesn't mean there hasn't been a helluva lot of work put into making WebTransport come to life so far, from a whole lot of people who have done a lot more work improving the web than most of us will ever know.
Given all you've said, why? Why do you like it? I am trying to understand its purpose but you haven't really articulated its value proposition either. How could it have value if there are better alternatives to both things it offers?
When it comes to reliable streams and WebTransport vs WebSockets I really don't see much improvement. Where I do see a simplification is when it comes to WebTransport vs WebRTC data channels. It's just a simpler API and protocol.
Right now (as I understand it) WebSocket is HTTP1.1 only - which means if you’re using HTTP2/HTTP3 and want to use websockets, the websocket connection will create a separate TCP connection just for WS. This is slow to start - both due to needing another handshake and TLS dance. And you can run into a bunch of problems due to per-domain browser connection limits.
Reliable streams over webtransport will solve these problems. They’ll be faster, more reliable and a better fit for HTTP/3.
Looks like no Rust HTTP/3 "WebTransport" support yet?
WebTransport and QUIC are different, right?
The status is "Editor's Draft". It's in a prestandard stage.
Yes. Key word: experiment
> new features that's disconnected from the reality of how web standards are made
Ah yes. Disconnected from reality in which... a standard is not a standard until all parties agree on it, and there are at least two independent implementations before the standard is considered safe to move from experimentation stage.
No-no. We live in a new reality where Google couldn't care less about the process and release features with full disregard of any of that.
Yup. Same story as PWAs.
A very exciting technology that is completely useless without wide browser support.
Yes. Just like WebTransport. But it turns out the ones that matter, aren’t.
Manifests are not supported by iOS in any browser, making PWAs DOA for any serious app. And service workers/push notifications were not the promise of PWAs. It was that they would allow for seamless universal apps distributable in any app store (or outside of one). That has not, and will not ever happen without the other browsers onboard with manifests, which is likely never happening.
Firefox removed support for some obscure reason and Apple doesn't want to jeopardise its billion dollar app store but that doesn't mean most devices in the world don't support them. Just throw the PWA into a free, open source, prebuilt wrapper if you must please Apple, it's a lot less work than going the other way around.
There's no such thing as a "PWA standard". There are half a dozen to a dozen various standards, and Safari supports the vast majority of them.
> Firefox removed support for some obscure reason
Firefox usually clearly documents the reasons
> Apple doesn't want to jeopardise its billion dollar app store
Ah yes, jeopardizing by ... supporting 99% of what passes for standard PWA features.
The parent talks about the webmanifest standard which is essential for PWAs (it describes the application and its package in a standard way). Safari does not support this, which is a pretty major standard to not support.
> Firefox usually clearly documents the reasons
I disagree. They state they have done user research (no information available on this) and that there is "little to no benefit" for a feature that was buggy and hidden behind configuration flags while at the same time enabling full support by default in their mobile browser.
> Ah yes, jeopardizing by ... supporting 99% of what passes for standard PWA features.
...except for notifications on iOS (which are coming, apparently, but it's taking them until somewhere next year) or A2HS on desktop (which they do support on iOS except in alternative browsers), which are pretty major limitations. The 1% remaining is still significant, the rest of the PWA standards Apple supports are just normal web standards that PWAs happen to use.
In all these discussions on HN the set of "essential standards" is always in flux, and is different for different people.
> They state they have done user research (no information available on this) and that there is "little to no benefit" for a feature that was buggy and hidden behind configuration flags while at the same time enabling full support by default in their mobile browser.
Because it's quite possible that it's buggy and confusing on desktop, but not so on mobile. Not so different from Safari, BTW which also has A2HS on iOS, but not on MacOS
> The 1% remaining is still significant, the rest of the PWA standards Apple supports are just normal web standards that PWAs happen to use.
So... The other ones are not normal web standards? Or are all web standards normal?
Because that’s what it is basically… effectively, a way to work around firewalls.
That is a thing with UDP too.
Firewalls (whether NAT or SPI) keep track of connection state with UDP in a similar way to how they do with TCP. Because UDP doesn't have the TCP SYN/ACK/FIN/RST flags, those firewalls have to use simpler heuristics for UDP, but they do keep track of connections.
In detail, this means your client needs to send a UDP packet to your server, so that the firewall will add a connection entry to its table to allow more packets through in the server->client direction. Then your server needs to reply with a UDP packets back to the client's IP:PORT. After that there needs to be a steady trickle of traffic from the client, or the firewall will remove the connection entry. Firewalls vary, and some of them require the server sends from the same IP:PORT the client->server packet was sent to; some UDP server software fails to do this correctly, especially if the server has multiple IPs.
This makes sense with NAT, because it's required for rewriting the IP:PORT values as they pass through the NAT firewall. But even without NAT, SPI firewalls operate a similar connection table and block server->client packets if there is no connection entry created and maintained by client->server packets first.
With QUIC and HTTP/3 you can sometimes have a little more packet inspection than with plain UDP.
This asymmetry means the client-server concept exists for UDP in practice, the same as with TCP.
I was there in the early BoF sessions for webtransport in Montreal / Singapore. We had dozens of people from all over the tech landscape chiming in and contributing.
The IETF is an open, participatory community. Claiming its run by Google is completely wrong, and honestly pretty demeaning to the work people put in to design specs.
If you want more independent voices at IETF, instead of inventing false claims to whinge about on HN, why don’t you be part of the solution and get involved? The mailing list for Webtransport is just a Google search away. Here it is now.[2]
[1] https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/
(I was one of the original authors in the W3C but left shortly after the BoF happened).
Also, HTTP 3 is standardized - isn't it weird that we can't actually use it from a browser?
According to https://caniuse.com/http3, HTTP/3 is live now in both Chrome and Firefox, and is available behind "Experimental Features" in Safari.
QUIC went through the IETF and HTTP/3 is supported in all modern browsers now.
It also has a lot of technical advantages over previous versions. Google doesn't always do the right thing but I haven't heard a solid argument over why their contributions to QUIC and HTTP/3 are bad.
As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
...er, why? It keeps packet loss from slowing down site loading (as much as is possible). I'm not sure how this is "bad for human persons".
People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone.
It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that.
And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.
What is this?
HTTP/2 is HTTP/1.1+TLS with a custom binary encoding that allows stream multiplexing. This lets browsers download the image and the CSS over the same TCP connection without having to incur slow-start penalties every request. It's the reason why "reduce number of requests" is no longer good web dev practice.
HTTP/1.1 is the usual plaintext protocol people think of when they think "HTTP".
[0] Specifically a UDP overlay protocol that allows selective TCP-like delivery guarantees, called QUIC
I don't keep these bookmarked and I can't seem to find the really good one I remember seeing on HN but here's a random one: https://backlinko.com/page-speed-stats
I'd say reducing the number of requests is still a very high priority practice for web devs.
In the HTTP/1.1 days, requests were so expensive that you could drop an order of magnitude in load time by aggregating your resources. Like, to the point where if you had a big JS library that only one page used, you'd aggregate it anyway, because TCP Slow Start is a cruel mistress.
Now, you'd probably want to do some measuring and comparisons first in that situation, because you might be able to get away with saving page weight on pages that don't use the library rather than aggregating it everywhere to save the request.
Less requests means more bandwidth per request, means each request finishes faster (aka downloads faster), means page loads faster.
Put another way, it's faster to download something smaller. Truly mindblowing, I know.
Efficient use of available bandwidth will always remain a top concern, if fast page loads are a concern.
> Is WebTransport a replacement for WebSockets? # Maybe.
Seriously? You start with maybe? I would have preferred if the author gave a way deeper answer of this rather important question.
Like the paragraghs that come after it?
In fact the real answer is hidden here:
> If you need something that works "out of the box" with common server setups, and with broad web client support, WebSockets is a better choice today.
Given that the article emphasizes it supports reliable and unreliable modes, seems to me that the overarching goal is "single interface for everything that's not /HTTP\/[12]/".
Maybe it's just that QUIC is slightly better than TCP/HTTP.
Probably the real Google reason is "make another thing that Apple and Mozilla have to build", and "eventually they'll die or move to Chromium".
The objective is to make a websockets equivalent for HTTP/3 which can take advantage of h3’s features. The headline features are UDP support and proper multiplexing with other parallel requests.
It’s like websocket but it works over h3 and optionally unreliable. And it’s faster.
And it’s sort of like webrtc data channels but it’s much more “webby” - it’s server-client not p2p. It works over http, and it’s not a huge inconsistent mess.
https://web.dev/webtransport/#is-webtransport-a-replacement-...
1. Whether you use the Streams APIs (suitable for WebSocket use cases) versus the datagram APIs (not suitable as a general replacement).
2. The standard is relatively new, so the WebSocket ecosystem is currently more mature.
I would be more concerned if the author glossed over those fairly important distinctions to say “yes”.
If you use WebSocket, you are stuck with streams. You can migrate those to WebTransport. Then you also have the option of datagrams if those make sense for you.