6 ms·

WebTransport is almost here to allow UDP-like exchange in the browser

57 points by BinaryIgor 11mo ago

ktpsns 11mo ago
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.
- silverwind 11mo ago
  Yeah, I don't see this or HTTP/3 gaining any widespread adoption because HTTP/3 needs obscure DNS records and messing with firewalls.
  - kaoD 11mo ago
    HTTP/3 does not need obscure DNS records (but it's greatly enhanced by them). Messing with firewalls in what way?
  - baggy_trough 11mo ago
    All it really needs is a UDP port 443 hole punch. The DNS stuff is an optional optimization.
  - CharlesW 11mo ago
    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-world/ https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-w...
  - deleted 11mo ago
    [deleted]
- chrismorgan 11mo ago
  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.
- advisedwang 11mo ago
  There is a proposal to do this: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...
- KPGv2 11mo ago
  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.
mort96 11mo ago
I think WebTransport is cool. 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.
- yladiz 11mo ago
  You should be able to use things like WebTransport locally, localhost is considered a secure context.
  - mort96 11mo ago
    192.168.0.x is not though
    - vscode-rest 11mo ago
      port fwd through localhost?
      - mort96 11mo ago
        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.
        11mo ago
rustyconover 11mo ago
Where are the server side implementations?
- pphysch 11mo ago
  Like this? Golang: https://github.com/quic-go/webtransport-go https://github.com/quic-go/webtransport-go
- KPGv2 11mo ago
  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).
- kixelated 11mo ago
  I maintain https://github.com/kixelated/web-transport 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.
mehagar 11mo ago
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.
- valorzard 11mo ago
  Did you try using the unreliable datagram extension?
- Sean-Der 11mo ago
  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.
  - kixelated 11mo ago
    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.
- kixelated 11mo ago
  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.
  - greenavocado 11mo ago
    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.
ilaksh 11mo ago
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?
kykat 11mo ago
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 ...
- user3939382 11mo ago
  10 years? We’re slowly re implementing yet another layer on the whole monster insane stack that already made no sense.
- api 11mo ago
  Everything that is extensible eventually becomes an OS.
- deleted 11mo ago
  [deleted]
mattvr 11mo ago
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.
- Sean-Der 11mo ago
  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-quic/ 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 :)
  - mattvr 11mo ago
    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.
- ranger_danger 11mo ago
  > peer-to-peer UDP connections Doesn't it require DTLS over UDP though?
  - kixelated 11mo ago
    Yeah, technically it's SCTP over DTLS for data channels. Only the media layer gets to use raw UDP, limiting the scope.
r3tr0 11mo ago
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 https://yeet.cx)
dabinat 11mo ago
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.

57 points by BinaryIgor 11mo ago

ktpsns 11mo ago

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.

silverwind 11mo ago
Yeah, I don't see this or HTTP/3 gaining any widespread adoption because HTTP/3 needs obscure DNS records and messing with firewalls.
- kaoD 11mo ago
  HTTP/3 does not need obscure DNS records (but it's greatly enhanced by them). Messing with firewalls in what way?
- baggy_trough 11mo ago
  All it really needs is a UDP port 443 hole punch. The DNS stuff is an optional optimization.
- CharlesW 11mo ago
  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-world/ https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-w...
- deleted 11mo ago
  [deleted]
chrismorgan 11mo ago
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.
advisedwang 11mo ago
There is a proposal to do this: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...
KPGv2 11mo ago
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.

mort96 11mo ago

I think WebTransport is cool. 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.

yladiz 11mo ago
You should be able to use things like WebTransport locally, localhost is considered a secure context.
- mort96 11mo ago
  192.168.0.x is not though
  - vscode-rest 11mo ago
    port fwd through localhost?
    - mort96 11mo ago
      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.
      - 11mo ago

rustyconover 11mo ago

Where are the server side implementations?

pphysch 11mo ago
Like this? Golang: https://github.com/quic-go/webtransport-go https://github.com/quic-go/webtransport-go
KPGv2 11mo ago
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).
kixelated 11mo ago
I maintain https://github.com/kixelated/web-transport 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.

mehagar 11mo ago

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.

valorzard 11mo ago
Did you try using the unreliable datagram extension?
Sean-Der 11mo ago
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.
- kixelated 11mo ago
  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.
kixelated 11mo ago
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.
- greenavocado 11mo ago
  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.

ilaksh 11mo ago

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?

kykat 11mo ago

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

user3939382 11mo ago
10 years? We’re slowly re implementing yet another layer on the whole monster insane stack that already made no sense.
api 11mo ago
Everything that is extensible eventually becomes an OS.
deleted 11mo ago
[deleted]

mattvr 11mo ago

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.

Sean-Der 11mo ago
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-quic/ 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 :)
- mattvr 11mo ago
  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.
ranger_danger 11mo ago
> peer-to-peer UDP connections Doesn't it require DTLS over UDP though?
- kixelated 11mo ago
  Yeah, technically it's SCTP over DTLS for data channels. Only the media layer gets to use raw UDP, limiting the scope.

r3tr0 11mo ago

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 https://yeet.cx)

dabinat 11mo ago

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.