WebTransport is almost here to allow UDP-like exchange in the browser(developer.mozilla.org)
developer.mozilla.org
WebTransport is almost here to allow UDP-like exchange in the browser
https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API
63 comments
I just read the MDN article of WS and you are right: WT is indeed treated as the successor of WS (in many use cases), which I did not expect at all:
'Additionally, the WebTransport API is expected to replace the WebSocket API for many applications. WebTransport is a versatile, low-level API that provides backpressure and many other features not supported by either WebSocket or WebSocketStream, such as unidirectional streams, out-of-order delivery, and unreliable data transmission via datagrams.'
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
Designed a protocol to supersede an old one is a good design goal. It makes encompassing all of the previous functionality and use cases a design priority.
It doesn't imply that websockets would be deprecated by WebTransport. It's a goal to make WebTransport an easy choice.
> Also, it's messed up that WT is only available in HTTPS. There are so many cool use cases for web technologies in local contexts where HTTPS is not a practical option
WebTransport is relatively heavy compared to websockets. Once you consider all of the layers, HTTP/3, possible HTTP/2 fallback, and transports, adding TLS is minimal overhead for code size.
For contexts where setting up certificates is not practical, I assume the workaround will be to generate a self-signed certificate and then tell the client to ignore certificate validation problems.
It doesn't imply that websockets would be deprecated by WebTransport. It's a goal to make WebTransport an easy choice.
> Also, it's messed up that WT is only available in HTTPS. There are so many cool use cases for web technologies in local contexts where HTTPS is not a practical option
WebTransport is relatively heavy compared to websockets. Once you consider all of the layers, HTTP/3, possible HTTP/2 fallback, and transports, adding TLS is minimal overhead for code size.
For contexts where setting up certificates is not practical, I assume the workaround will be to generate a self-signed certificate and then tell the client to ignore certificate validation problems.
Performance isn't really my main concern; I have some projects with configuration web GUIs running on MCUs where it could matter (especially the code size to include mbedtls), but most of the stuff I care about is on Linux machines which are powerful enough that it doesn't matter.
See my response to the certificates thing here: https://news.ycombinator.com/item?id=45820782#45956556
See my response to the certificates thing here: https://news.ycombinator.com/item?id=45820782#45956556
> I have some projects with configuration web GUIs running on MCUs where it could matter
I don’t think these are a fit for an entire HTTP/3 or HTTP/2 stack with WebTransport anyway.
WebSockets is fine for these applications and won’t be going away.
> See my response to the certificates thing here
If you don’t care about validating the certificate you can skip all of the renewals and DNS setup and everything else. The client will complain that it can’t verify the certificate against anything trusted and you tell the client that’s okay, just ignore it and continue.
If you don’t care about encryption then you also don’t care about setting up the certificate properly. You put something in there to enable the connection and then have the client ignore the fact that it’s not verified.
If your complaint is that browsers show warning signs for certs that can’t be validated and those might scare other users, that’s not going away.
I don’t think these are a fit for an entire HTTP/3 or HTTP/2 stack with WebTransport anyway.
WebSockets is fine for these applications and won’t be going away.
> See my response to the certificates thing here
If you don’t care about validating the certificate you can skip all of the renewals and DNS setup and everything else. The client will complain that it can’t verify the certificate against anything trusted and you tell the client that’s okay, just ignore it and continue.
If you don’t care about encryption then you also don’t care about setting up the certificate properly. You put something in there to enable the connection and then have the client ignore the fact that it’s not verified.
If your complaint is that browsers show warning signs for certs that can’t be validated and those might scare other users, that’s not going away.
I don't think you understand. I don't want to make services which, by design, show scare screens to people and make it sound like they're being hacked. It's better to use HTTP and restrict myself to features which work in "insecure" contexts.
There are material performance overheads to TLS
You should be able to use things like WebTransport locally, localhost is considered a secure context.
192.168.0.x is not though
not disagreeing with your point here, or in the follow-ups of the pain of https for "local network" apps... but I really wish that we could get to a place where we could get away from this distinction. Obviously, ipv6 is not that easy or realistic, but that really is, imho, the "right" long term answer.
Having gone down the path of being able to just spin up "local" services that get a publicly routable (but most often firewalled off) ipv6 IPs and then good DNS integration is really neat... but still requires lots of technical chops. I wish that weren't the case
Having gone down the path of being able to just spin up "local" services that get a publicly routable (but most often firewalled off) ipv6 IPs and then good DNS integration is really neat... but still requires lots of technical chops. I wish that weren't the case
I work with embedded Linux stuff and MCU stuff where we make a significant number of units. Even in an IPv6 world, there's no way each of those would get their own public static IPv6 address with an associated DNS record just for the purpose of being able to spin up a debug web interface. It's explicitly desirable for these devices to not be reachable through the public Internet.
Well then you set your firewall to default-deny. It doesn't make sense to hobble the internet just because NATs are inadvertently a convenient firewall.
And how do I assign the devices globally unique IP addresses? SLAAC is only for local addresses, right?
Wouldn't IPv6 work for that?
I don't know what you mean. I asked what process you would use to assign IPv6 addresses.
Maybe I'm not understanding the use case. Why can't you use DHCPv6 or SLAAC wherever the device is deployed?
DHCP doesn't give you a globally unique IP address...
If you're suggesting getting using a non-unique DHCP-assigned local IP address, I don't understand what difference you think v6 does compared to v4.
If you're suggesting getting using a non-unique DHCP-assigned local IP address, I don't understand what difference you think v6 does compared to v4.
DHCP does give you a globally unique IP address when your ISP has allocated a prefix to your router, that's how all the Internet-connected IPv6 devices get their addresses. Where is our misunderstanding?
port fwd through localhost?
You're missing the point. The useful thing is to run some service on the LAN, be it a web interface for a NAS, a web interface to control some lighting, a web interface into a media PC to do remote desktop type stuff or control media playback, a debug interface into some embedded product I'm working on, or a whole host of other things. The thing that makes web technologies useful for this is that it Just Works, from any other machine on the LAN (my laptop, my phone, a guest's phone, etc).
By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
You can get a free cert from letsencrypt using their dns challenge. No need to expose to the internet. Add a DNS record that points to the address of your LAN and it’ll make things even easier for your guests.
Not interested in going through the effort of setting up a DNS record, go through the whole DNS challenge process, and go through a periodic manual renewal process, for every stupid little thing (many even just temporary things which don't even have a static DHCP lease). There's literally no advantage for my use case, except that I'd be allowed by the web standard bodies to use their shiny new toys that they artificially lock away otherwise.
For the permanent installation case, it's typically easier to use mDNS domains since they're shorter. 'mediapc.local' is easier for guests to type than 'mediapc.local.mort.coffee' or whatever I'd end up with.
What would be a good solution is self-signed certificates, but that too is a non-option until all browser vendors downgrade the warning from a "Someone is trying to hack you!" style scare screen to a more informative "this is a self signed certificate, do you trust it?" style warning screen.
For the permanent installation case, it's typically easier to use mDNS domains since they're shorter. 'mediapc.local' is easier for guests to type than 'mediapc.local.mort.coffee' or whatever I'd end up with.
What would be a good solution is self-signed certificates, but that too is a non-option until all browser vendors downgrade the warning from a "Someone is trying to hack you!" style scare screen to a more informative "this is a self signed certificate, do you trust it?" style warning screen.
Self signed for 192.x would be one thing, self signed for gmail.com would be another.
I would be perfectly happy with a solution where browsers show a scare screen for self-signed certificates on the public internet but a benign-looking "Do you want to trust this certificate?" screen for 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 or mDNS .local domains.
> you VILL spend effort to placate the corporate letencrypt gods with pointless encantations and you VILL like it
Gee thanks corporate overlords, whatever would we do without your cloying efforts to provide quote-unquote-"security"?
Gee thanks corporate overlords, whatever would we do without your cloying efforts to provide quote-unquote-"security"?
I like to frame WebTransport as multiple WebSocket connections to the same host, but using a shared handshake.
It's common to multiplex a WebSocket connection but you don't need that with WebTransport, while also avoiding head-of-line-blocking.
But yeah I wish WebTransport had a better TCP fallback. I still use WebSocket for that.
It's common to multiplex a WebSocket connection but you don't need that with WebTransport, while also avoiding head-of-line-blocking.
But yeah I wish WebTransport had a better TCP fallback. I still use WebSocket for that.
The thing is, I very rarely (or arguably never) have a use case which requires that one client has multiple connections to the same server. The thing I want is almost always to have a bidirectional stream of messages where messages arrive in order. Essentially a simple message envelope protocol on top of TCP.
For sure, if you want an ordered/reliable stream then WebSocket is ideal. WebTransport is useful when you also want prioritization and semi-reliable networking, similar in concept to WebRTC data channels.
Agreed. WebSocket works perfectly when someone wants a lightweight message-based protocol on top of TCP and doesn't want to implement it themselves, potentially in multiple languages. It being originally browser tech became a minor detail.
With all these new APIs, I worry what the web will look like in 10 years, will be have this huge API surface always will us? Will we start to see deprecations in the web api? I'm worried if the XSLT is setting a precedent on deprecating "complex" and "hard to maintain" APIs.
EDIT: Think also about webgl1/2, webgpu, webxr, websocket, webrtc, webauthn ...
EDIT: Think also about webgl1/2, webgpu, webxr, websocket, webrtc, webauthn ...
Everything that is extensible eventually becomes an OS.
10 years? We’re slowly re implementing yet another layer on the whole monster insane stack that already made no sense.
[deleted]
I wonder why they did not extend the existing websocket API. Now if you want to be HTTP/1 or HTTP/2 backward compatible, you have to add another abstraction ontop of these two because WebTransports is HTTP/3 only.
WebSocket and WebTransport are pretty wildly incompatible in an API sense. One provides a single reliable bidirectional stream. The other provides arbitrarily many unreliable and reliable unidirectional and bidirectional streams, according to your own orchestration.
It’s like saying “I had a violin, why didn’t they make this new ‘orchestra’ thing behave the same way?”
If you’re willing to limit yourself to a single reliable bidirectional stream, abstracting over both WebTransport and WebSocket will be easy.
WebTransport, in its fullness, also pretty clearly depends on HTTP/3. Any implementation based on HTTP/1 or HTTP/2 (which is in progress) will lack unreliable delivery and independence of streams (due to using TCP), and possibly more features.
It’s like saying “I had a violin, why didn’t they make this new ‘orchestra’ thing behave the same way?”
If you’re willing to limit yourself to a single reliable bidirectional stream, abstracting over both WebTransport and WebSocket will be easy.
WebTransport, in its fullness, also pretty clearly depends on HTTP/3. Any implementation based on HTTP/1 or HTTP/2 (which is in progress) will lack unreliable delivery and independence of streams (due to using TCP), and possibly more features.
Yeah, I don't see this or HTTP/3 gaining any widespread adoption because HTTP/3 needs obscure DNS records and messing with firewalls.
I can't find 2025 stats, but HTTP/3 adoption was already widespread two years ago. https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-w...
HTTP/3 does not need obscure DNS records (but it's greatly enhanced by them).
Messing with firewalls in what way?
Messing with firewalls in what way?
All it really needs is a UDP port 443 hole punch. The DNS stuff is an optional optimization.
[deleted]
There is a proposal to do this: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...
The websocket RFC is designed around TCP, and "extending" WS to work over UDP would essentially be a new protocol. Which is what this is.
You can think about this with HTTP/1 vs HTTP/3: HTTP/3 isn't an extension of HTTP/1. It's radically different.
You can think about this with HTTP/1 vs HTTP/3: HTTP/3 isn't an extension of HTTP/1. It's radically different.
We tested this against WebRTC data channels (which also uses UDP) and found that the congestion control algorithm used for WebTransport limits its use for videoconferencing. We'll probably look into it again if browsers start allowing this to be configured.
SCTP and by extension, WebRTC data channels, are supposed to use the same congestion control algorithms as TCP/QUIC. But I don't know which CC libsctp does these days.
WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.
WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.
SCTP: The FORWARD-TSN chunk was introduced to support selective unreliability: it allows the sender to tell the receiver that it will not retransmit some number of chunks, and requests that the receiver consider all these chunks as received.
QUIC has a much better alternative to FORWARD-TSN, either via RESET_STREAM or QUIC datagrams.
I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing.
QUIC as a protocol is significantly better than SCTP. I really recommend the RFC
I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing.
QUIC as a protocol is significantly better than SCTP. I really recommend the RFC
Wow thanks for the tip
I haven't used WebTransport myself, how much can you control? I wonder how often libwebrtc does stuff that wouldn't be allowed in Javascript. Things like probing and overshooting the window?
Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.
Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.
There's no probing in any QUIC implementation but it's possible. There's a QUIC extension in the IETF similar to transport-wide-cc but it would still be up to the browser to use it for any upload CC.
Did you try using the unreliable datagram extension?
While WebTransport is promising, it's limited to client-server communication unlike WebRTC.
WebRTC supports peer-to-peer UDP connections as well. Thus it's better for use cases like low-latency games, video calling, and secure direct communication between devices.
A better push might be to make WebRTC more simple and modern, but I'm not sure if any standards committees are working on this yet.
WebRTC supports peer-to-peer UDP connections as well. Thus it's better for use cases like low-latency games, video calling, and secure direct communication between devices.
A better push might be to make WebRTC more simple and modern, but I'm not sure if any standards committees are working on this yet.
What do you think a more simple/modern WebRTC looks like?
* RTP over QUIC is promising https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over...
Do you want a new PeerConnection API? Are you annoyed with the Offer/Answer model? Do you have beef with the protocols. The possibility are endless :)
* RTP over QUIC is promising https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over...
Do you want a new PeerConnection API? Are you annoyed with the Offer/Answer model? Do you have beef with the protocols. The possibility are endless :)
In a nutshell, ideally `peer.connect(remoteId)`. An API like peer-js/simple-peer. And symmetric negotiation would be great as well.
WebRTC should be the universal networking primitive for the next phase of the web, but the API exposes too many implementation details – its abstractions leak.
This plus the overall weight of integrations limit mass adoption by developers.
WebRTC should be the universal networking primitive for the next phase of the web, but the API exposes too many implementation details – its abstractions leak.
This plus the overall weight of integrations limit mass adoption by developers.
> peer-to-peer UDP connections
Doesn't it require DTLS over UDP though?
Doesn't it require DTLS over UDP though?
Yeah, technically it's SCTP over DTLS for data channels. Only the media layer gets to use raw UDP, limiting the scope.
I have been counting down the days.
It will help a ton with the low latency streaming we need to do in our eBPF based Linux performance tool. (https://yeet.cx)
It will help a ton with the low latency streaming we need to do in our eBPF based Linux performance tool. (https://yeet.cx)
Okay so if sending raw binary is a normal use case, does that mean HTTP/3 is a misnomer? Or are they confusing me with the way they present Web transport ad being equivalent to HTTP/3 and WebTransport just sending binary data?
Also, what client libraries are there for Python, Rust etc. for WebTransport? Does it work with any HTTP/3/QUIC implementation?
Also, what client libraries are there for Python, Rust etc. for WebTransport? Does it work with any HTTP/3/QUIC implementation?
Where are the server side implementations?
I would guess there aren't as many because, in order to implement this, your language must already have an HTTP/3 library. My language of choice doesn't even support QUIC yet (so I'm writing the library for it, then for HTTP/3). I wouldn't be surprised if other languages are similar.
As of one month ago, Java still didn't have HTTP/3 support. Though it's apparently coming in March (with JDK 26).
As of one month ago, Java still didn't have HTTP/3 support. Though it's apparently coming in March (with JDK 26).
Like this?
Golang: https://github.com/quic-go/webtransport-go
Golang: https://github.com/quic-go/webtransport-go
I maintain https://github.com/kixelated/web-transport
But yeah the HTTP/3 integration definitely makes WebTransport harder to support. The QUIC connection needs to be shared between HTTP/3 and WebTransport.
But yeah the HTTP/3 integration definitely makes WebTransport harder to support. The QUIC connection needs to be shared between HTTP/3 and WebTransport.
I’m completely unsurprised the holdout is Safari. I really wish Apple decoupled Safari updates from iOS updates. There are legitimate reasons why people might be stuck on an old OS (due to unsupported hardware) or simply not want to upgrade (e.g. because of the recent controversial UI changes). Tying updating your browser to updating your whole OS means web platform changes take much longer to become full baseline.
Plus Safari is often the last browser to get certain features anyway.
Plus Safari is often the last browser to get certain features anyway.
What worries me is that some people involved in standardisation seem to be of the opinion that WebTransport supersedes WebSocket. WS has become my go-to transport when I just need to be able to reliably send messages back and forth, whether or not the web is involved at all, and I don't see WebTransport as a replacement for that use case. I hope WS sticks around forever.
Also, it's messed up that WT is only available in HTTPS. There are so many cool use cases for web technologies in local contexts where HTTPS is not a practical option, it's a shame most new technologies are arbitrarily banned from those use cases.