12 ms·

Using WebTransport

175 points by politician 4y ago

rektide 4y ago
> The best way to experiment with WebTransport is to start up a compatible HTTP/3 server. 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 https://github.com/quicwg/base-drafts/wiki/Implementations
ok123456 4y ago
[1] was the first thing that popped into my head when I heard 'WebTransport.' [1] Open Transport. (2020, November 19). In Wikipedia. https://en.wikipedia.org/wiki/Open_Transport https://en.wikipedia.org/wiki/Open_Transport
orliesaurus 4y ago
I grep'd for websockets the first line is: > 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.
- have_faith 4y ago
  > I would have preferred if the author gave a way deeper answer of this rather important question. Like the paragraghs that come after it?
  - orliesaurus 4y ago
    I read the whole thing, my point is that it DOES NOT do a good job at explaining the reasoning behind build this. 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.
    - markdog12 4y ago
      I politely disagree. The article seems to intentionally compare existing APIs, and explains its relation to websockets fairly well, IMO. https://web.dev/webtransport/#is-webtransport-a-replacement-for-websockets https://web.dev/webtransport/#is-webtransport-a-replacement-...
    - tomxor 4y ago
      That's only referring to current maturity... the differences are more nuanced. I'd recommend reading the article, it's not super long.
    - yeeticus 4y ago
      I agree with this. There is probably some hidden 4d chess business reason at Google for building yet another competing solution. 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".
      - josephg 4y ago
        It’s not a Google project. And you don’t have to guess what it’s about - there have been public meetings about it for years, and there’s a public spec. (Both at IETF for the network parts, and at W3C for the javascript APIs). 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.
        deleted 4y ago
        [deleted]
- eyelidlessness 4y ago
  Did you go on to read the rest of the section? It seems pretty clear to me that the “maybe” addresses two factors: 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”.
  - strbean 4y ago
    I think the succinct answer is "Yes, but you probably want to wait for the ecosystem to mature". 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.
- marcosdumay 4y ago
  Do you really expect a deep discussion of the subject in a TL/DR line?
  - orliesaurus 4y ago
    No but a better one line answer, sure!
    - cush 4y ago
      Maybe answers your question. It does in some cases and not in others. So it might replace your need for websockets.
- jeroenhd 4y ago
  WebTransport isn't a replacement for all WebSockets. It's a replacement for some websockets in some use cases. "Maybe" is exactly the right answer because the person writing this introduction doesn't know your exact use cases and requirement. Answering yes or no would be inaccurate.
eis 4y ago
There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport. 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 https://caniuse.com/webtransport but have since verified it myself that at least Chrome v103 on Android 12 does indeed support WebTransport.
- markdog12 4y ago
  > Chrome on Android doesn't either 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.
  - strbean 4y ago
    Can I Use[1] gives mixed messages on this. Seems like it is either partially supported or fully supported and one of the entries is just misleading? [1]https://caniuse.com/?search=webtransport https://caniuse.com/?search=webtransport
    - eis 4y ago
      The information there is indeed incorrect. I have updated my comment accordingly.
hpx7 4y ago
Does anyone know of any websites/applications that utilize WebTransport? The only thing I've come across are the Showcase demos from https://github.com/yomorun/presencejs https://github.com/yomorun/presencejs
- afavour 4y ago
  It was only added to Chrome in January of this year and isn't in Firefox or Safari. So I suspect there isn't much beyond showcases for now.
- judah 4y ago
  I think it's too new. HTTP/3 has only recently been standardized, and Web Transport is built atop that. New tech, not many users yet. I suspect we'll see many web games utilize this in the near future.
- vasilvv 4y ago
  There's a simple echo server demo at https://webrtc.internaut.com/wt/ https://webrtc.internaut.com/wt/ 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/ 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).
aaaaaaaaaaab 4y ago
Another web "standard" unilaterally declared by Google. How wonderful!
- WHATDOESIT 4y ago
  Is there any alternative we could use? WebRTC is not it - that's much more complex than just simple client-server communication. Also, HTTP 3 is standardized - isn't it weird that we can't actually use it from a browser?
  - aaaaaaaaaaab 4y ago
    HTTP 3? Oh, you mean the thing that used to be HTTP-over-QUIC, another “standard” unilaterally declared by Google :-)
    - superkuh 4y ago
      I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons. As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
      - kmeisthax 4y ago
        >QUIC is a bad standard for human persons but excellent for corporate persons. ...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".
        jrockway 4y ago
        I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. 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.
MuffinFlavored 4y ago
What does WebTransport do that WebSockets do not do? How is performance comparatively?
- hpx7 4y ago
  WebSockets is built on top of TCP, whereas WebTransport is built on top of UDP. This makes WebTransport better suited for handling latency-sensitive applications like multiplayer games.
  - MuffinFlavored 4y ago
    https://github.com/cloudflare/quiche/issues/1114 https://github.com/cloudflare/quiche/issues/1114 Looks like no Rust HTTP/3 "WebTransport" support yet? WebTransport and QUIC are different, right?
    - kevinmgranger 4y ago
      WebTransport is an HTTP/3 only protocol, and HTTP/3 is a QUIC only protocol. Different but interlinked.
      - MuffinFlavored 4y ago
        UDP -> QUIC -> HTTP/3 -> WebTransport?
        DrBenCarson 4y ago
        Correct
encryptluks2 4y ago
Would this be a good API to communicate with say a local server that communicates with a native application, live the Native Messaging API for extensions?
mwcampbell 4y ago
> WebRTC data channels support peer-to-peer communications, but WebTransport only supports client-server connection. If you have multiple clients that need to talk directly to each other, then WebTransport isn't a viable alternative. 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.
- felipellrocha 4y ago
  If you are doing p2p, though, webrtc makes a lot of sense since the apis there are designed to punch through a nat
- jeffparsons 4y ago
  As a user of QUIC, I've found it to be pretty much everything I've been wanting for the last 20 years. Hopefully WebTransport can grow the features required (e.g. by stealing them from WebRTC) to make real P2P WebTransport possible. Edit: if I'm reading this correctly, then maybe there are already efforts underway to make this possible: https://github.com/w3c/p2p-webtransport https://github.com/w3c/p2p-webtransport
  - CMCDragonkai 4y ago
    Do you see any resources on hole punching with QUIC, and NAT traversal? So far I can't even easily find a reference in existing QUIC libraries if it is possible to just send single QUIC packets to perform only hole punching while having separate streams to be established when the punch packets pass through.
    - pthatcherg 4y ago
      You can use ICE and QUIC together. That's what the original version of WebTransport did (back when it was called QuicTransport).
EGreg 4y ago
I got curious about HTTP/3 and hit a 404 LMAO What is this?
- kmeisthax 4y ago
  HTTP/3 is HTTP/2 over UDP[0]. The advantage of this is that packet loss no longer delays processing of independent streams: if you lose a packet of one image it doesn't delay processing the rest of the CSS. 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
  - arcbyte 4y ago
    Actually I've seen more and more evidence over the past two years that even with multiplexing, reducing the number of requests is still at the top of the list in improving page speed. It's the single most impactful thing that can be done. 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 https://backlinko.com/page-speed-stats I'd say reducing the number of requests is still a very high priority practice for web devs.
    - Dalewyn 4y ago
      It really doesn't (shouldn't, anyway) take an understanding of rocket science to understand why. 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.
    - kmeisthax 4y ago
      I may have misspoke. It's not bad advice to reduce your requests, it's just less critical. 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.
dmitriid 4y ago
Once again Chrome pretends it's a standard that is agreed on, and launched. The status is "Editor's Draft". It's in a prestandard stage.
- ramesh31 4y ago
  > Once again Chrome pretends it's a standard that is agreed on, and launched. Yup. Same story as PWAs. A very exciting technology that is completely useless without wide browser support.
  - abraham 4y ago
    PWAs are a collection of standards, many if which are broadly supported. E.g. service workers. Additionally they are progressive so PWAs should be designed to function without the specific features.
    - ramesh31 4y ago
      > PWAs are a collection of standards, many if which are broadly supported. Yes. Just like WebTransport. But it turns out the ones that matter, aren’t.
      - abraham 4y ago
        You'd have to be more specific. As far as I know the main features service workers are supported everywhere, web manifests are supported everywhere, and as of iOS 16 this week push notifications are supported everywhere.
        ramesh31 4y ago
        >As far as I know the main features service workers are supported everywhere, web manifests are supported everywhere, and as of iOS 16 this week push notifications are supported everywhere. 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.
Eduard 4y ago
Is WebTransport safe to bet on, and is there a risk it will be removed as HTTP/2 Server Push was? https://developer.chrome.com/blog/removing-push/ https://developer.chrome.com/blog/removing-push/
- kirbyfan64sos 4y ago
  HTTP/2 Server Push is largely just a "bonus" on HTTP/2, and removing it isn't exactly going to break a ton of things. Any chance you're thinking of server-side events, which are still supported?
  - AgentME 4y ago
    Yeah, in previous discussions I've seen about HTTP/2 Server Push, it seems like a lot of people are confused about what it was and thought it could be used to let a server spontaneously message a client (like you can do with websockets or server-side events). The only thing Server Push does is let a server respond to one request with multiple responses together ("I see you're requesting X, but I know clients who ask for X end up asking for Y shortly after, so here's Y with your X so you can cache it for later").
    - SV_BubbleTime 4y ago
      I’m not a web guy, was Server Push replaced with / rolled back to a socket for server async communication?
      - AgentME 4y ago
        Server push doesn't let a server spontaneously communicate with a client like a socket does. It's purely an optimization to let the server include in a response to the client extra resources for the client to cache for later, possibly making it so the client doesn't have to request them later. If server push doesn't happen, then it just means the client might not have certain resources pre-cached and will have to request them later.
  - 4y ago
znpy 4y ago
Basically udp over udp? Because that’s what it is basically… effectively, a way to work around firewalls.
- klabb3 4y ago
  I don't think so, because WebTransport is only client-server, so there's no firewall to worry about. You may be thinking of WebRTC?
  - lordofgibbons 4y ago
    I'm not sure I understand. UDP is connection-less so it doesn't matter if it's client-server. In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP
    - jlokier 4y ago
      *> In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP 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.
klabb3 4y ago
> Using WebTransport [...] means that you don't have to worry about head-of-line blocking, which can be an issue with WebSockets. 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?
- jbaczuk 4y ago
  > I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets. What do you think it was/is? (not disagreeing)
  - klabb3 4y ago
    Primarily load balancers and other cloudy middleware stuff. Most existing infrastructure is built on the request-response model (for good and bad). Maintaining a long lived connection makes more sense in the traditional single-beefy-server world, but with lambdas, containers, reverse proxies and everything being transparent and ephemeral it was too big of a game changer for cloud providers, in particular PaaS, I think.
    - inhumantsar 4y ago
      100% this. Scaling websockets is fine if your app sees consistent load or don't mind paying for unused capacity. 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.
fanweixiao 4y ago
Here is a public WebTransport Echo Server: https://webtransport.day https://webtransport.day, can try by Chrome.

175 points by politician 4y ago

> The best way to experiment with WebTransport is to start up a compatible HTTP/3 server. 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 https://github.com/quicwg/base-drafts/wiki/Implementations

ok123456 4y ago

[1] was the first thing that popped into my head when I heard 'WebTransport.' [1] Open Transport. (2020, November 19). In Wikipedia. https://en.wikipedia.org/wiki/Open_Transport https://en.wikipedia.org/wiki/Open_Transport

orliesaurus 4y ago

I grep'd for websockets the first line is: > 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.

have_faith 4y ago
> I would have preferred if the author gave a way deeper answer of this rather important question. Like the paragraghs that come after it?
- orliesaurus 4y ago
  I read the whole thing, my point is that it DOES NOT do a good job at explaining the reasoning behind build this. 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.
  - markdog12 4y ago
    I politely disagree. The article seems to intentionally compare existing APIs, and explains its relation to websockets fairly well, IMO. https://web.dev/webtransport/#is-webtransport-a-replacement-for-websockets https://web.dev/webtransport/#is-webtransport-a-replacement-...
  - tomxor 4y ago
    That's only referring to current maturity... the differences are more nuanced. I'd recommend reading the article, it's not super long.
  - yeeticus 4y ago
    I agree with this. There is probably some hidden 4d chess business reason at Google for building yet another competing solution. 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".
    - josephg 4y ago
      It’s not a Google project. And you don’t have to guess what it’s about - there have been public meetings about it for years, and there’s a public spec. (Both at IETF for the network parts, and at W3C for the javascript APIs). 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.
      - deleted 4y ago
        [deleted]
eyelidlessness 4y ago
Did you go on to read the rest of the section? It seems pretty clear to me that the “maybe” addresses two factors: 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”.
- strbean 4y ago
  I think the succinct answer is "Yes, but you probably want to wait for the ecosystem to mature". 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.
marcosdumay 4y ago
Do you really expect a deep discussion of the subject in a TL/DR line?
- orliesaurus 4y ago
  No but a better one line answer, sure!
  - cush 4y ago
    Maybe answers your question. It does in some cases and not in others. So it might replace your need for websockets.
jeroenhd 4y ago
WebTransport isn't a replacement for all WebSockets. It's a replacement for some websockets in some use cases. "Maybe" is exactly the right answer because the person writing this introduction doesn't know your exact use cases and requirement. Answering yes or no would be inaccurate.

eis 4y ago

There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport. 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 https://caniuse.com/webtransport but have since verified it myself that at least Chrome v103 on Android 12 does indeed support WebTransport.

markdog12 4y ago
> Chrome on Android doesn't either 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.
- strbean 4y ago
  Can I Use[1] gives mixed messages on this. Seems like it is either partially supported or fully supported and one of the entries is just misleading? [1]https://caniuse.com/?search=webtransport https://caniuse.com/?search=webtransport
  - eis 4y ago
    The information there is indeed incorrect. I have updated my comment accordingly.

hpx7 4y ago

Does anyone know of any websites/applications that utilize WebTransport? The only thing I've come across are the Showcase demos from https://github.com/yomorun/presencejs https://github.com/yomorun/presencejs

afavour 4y ago
It was only added to Chrome in January of this year and isn't in Firefox or Safari. So I suspect there isn't much beyond showcases for now.
judah 4y ago
I think it's too new. HTTP/3 has only recently been standardized, and Web Transport is built atop that. New tech, not many users yet. I suspect we'll see many web games utilize this in the near future.
vasilvv 4y ago
There's a simple echo server demo at https://webrtc.internaut.com/wt/ https://webrtc.internaut.com/wt/ 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/ 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).

aaaaaaaaaaab 4y ago

Another web "standard" unilaterally declared by Google. How wonderful!

WHATDOESIT 4y ago
Is there any alternative we could use? WebRTC is not it - that's much more complex than just simple client-server communication. Also, HTTP 3 is standardized - isn't it weird that we can't actually use it from a browser?
- aaaaaaaaaaab 4y ago
  HTTP 3? Oh, you mean the thing that used to be HTTP-over-QUIC, another “standard” unilaterally declared by Google :-)
  - superkuh 4y ago
    I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons. As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
    - kmeisthax 4y ago
      >QUIC is a bad standard for human persons but excellent for corporate persons. ...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".
      - jrockway 4y ago
        I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. 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.

MuffinFlavored 4y ago

What does WebTransport do that WebSockets do not do? How is performance comparatively?

hpx7 4y ago
WebSockets is built on top of TCP, whereas WebTransport is built on top of UDP. This makes WebTransport better suited for handling latency-sensitive applications like multiplayer games.
- MuffinFlavored 4y ago
  https://github.com/cloudflare/quiche/issues/1114 https://github.com/cloudflare/quiche/issues/1114 Looks like no Rust HTTP/3 "WebTransport" support yet? WebTransport and QUIC are different, right?
  - kevinmgranger 4y ago
    WebTransport is an HTTP/3 only protocol, and HTTP/3 is a QUIC only protocol. Different but interlinked.
    - MuffinFlavored 4y ago
      UDP -> QUIC -> HTTP/3 -> WebTransport?
      - DrBenCarson 4y ago
        Correct

encryptluks2 4y ago

Would this be a good API to communicate with say a local server that communicates with a native application, live the Native Messaging API for extensions?

mwcampbell 4y ago

> WebRTC data channels support peer-to-peer communications, but WebTransport only supports client-server connection. If you have multiple clients that need to talk directly to each other, then WebTransport isn't a viable alternative. 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.

felipellrocha 4y ago
If you are doing p2p, though, webrtc makes a lot of sense since the apis there are designed to punch through a nat
jeffparsons 4y ago
As a user of QUIC, I've found it to be pretty much everything I've been wanting for the last 20 years. Hopefully WebTransport can grow the features required (e.g. by stealing them from WebRTC) to make real P2P WebTransport possible. Edit: if I'm reading this correctly, then maybe there are already efforts underway to make this possible: https://github.com/w3c/p2p-webtransport https://github.com/w3c/p2p-webtransport
- CMCDragonkai 4y ago
  Do you see any resources on hole punching with QUIC, and NAT traversal? So far I can't even easily find a reference in existing QUIC libraries if it is possible to just send single QUIC packets to perform only hole punching while having separate streams to be established when the punch packets pass through.
  - pthatcherg 4y ago
    You can use ICE and QUIC together. That's what the original version of WebTransport did (back when it was called QuicTransport).

EGreg 4y ago

I got curious about HTTP/3 and hit a 404 LMAO What is this?

kmeisthax 4y ago
HTTP/3 is HTTP/2 over UDP[0]. The advantage of this is that packet loss no longer delays processing of independent streams: if you lose a packet of one image it doesn't delay processing the rest of the CSS. 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
- arcbyte 4y ago
  Actually I've seen more and more evidence over the past two years that even with multiplexing, reducing the number of requests is still at the top of the list in improving page speed. It's the single most impactful thing that can be done. 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 https://backlinko.com/page-speed-stats I'd say reducing the number of requests is still a very high priority practice for web devs.
  - Dalewyn 4y ago
    It really doesn't (shouldn't, anyway) take an understanding of rocket science to understand why. 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.
  - kmeisthax 4y ago
    I may have misspoke. It's not bad advice to reduce your requests, it's just less critical. 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.

dmitriid 4y ago

Once again Chrome pretends it's a standard that is agreed on, and launched. The status is "Editor's Draft". It's in a prestandard stage.

ramesh31 4y ago
> Once again Chrome pretends it's a standard that is agreed on, and launched. Yup. Same story as PWAs. A very exciting technology that is completely useless without wide browser support.
- abraham 4y ago
  PWAs are a collection of standards, many if which are broadly supported. E.g. service workers. Additionally they are progressive so PWAs should be designed to function without the specific features.
  - ramesh31 4y ago
    > PWAs are a collection of standards, many if which are broadly supported. Yes. Just like WebTransport. But it turns out the ones that matter, aren’t.
    - abraham 4y ago
      You'd have to be more specific. As far as I know the main features service workers are supported everywhere, web manifests are supported everywhere, and as of iOS 16 this week push notifications are supported everywhere.
      - ramesh31 4y ago
        >As far as I know the main features service workers are supported everywhere, web manifests are supported everywhere, and as of iOS 16 this week push notifications are supported everywhere. 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.

Eduard 4y ago

Is WebTransport safe to bet on, and is there a risk it will be removed as HTTP/2 Server Push was? https://developer.chrome.com/blog/removing-push/ https://developer.chrome.com/blog/removing-push/

kirbyfan64sos 4y ago
HTTP/2 Server Push is largely just a "bonus" on HTTP/2, and removing it isn't exactly going to break a ton of things. Any chance you're thinking of server-side events, which are still supported?
- AgentME 4y ago
  Yeah, in previous discussions I've seen about HTTP/2 Server Push, it seems like a lot of people are confused about what it was and thought it could be used to let a server spontaneously message a client (like you can do with websockets or server-side events). The only thing Server Push does is let a server respond to one request with multiple responses together ("I see you're requesting X, but I know clients who ask for X end up asking for Y shortly after, so here's Y with your X so you can cache it for later").
  - SV_BubbleTime 4y ago
    I’m not a web guy, was Server Push replaced with / rolled back to a socket for server async communication?
    - AgentME 4y ago
      Server push doesn't let a server spontaneously communicate with a client like a socket does. It's purely an optimization to let the server include in a response to the client extra resources for the client to cache for later, possibly making it so the client doesn't have to request them later. If server push doesn't happen, then it just means the client might not have certain resources pre-cached and will have to request them later.
- 4y ago

znpy 4y ago

Basically udp over udp? Because that’s what it is basically… effectively, a way to work around firewalls.

klabb3 4y ago
I don't think so, because WebTransport is only client-server, so there's no firewall to worry about. You may be thinking of WebRTC?
- lordofgibbons 4y ago
  I'm not sure I understand. UDP is connection-less so it doesn't matter if it's client-server. In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP
  - jlokier 4y ago
    *> In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP 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.

klabb3 4y ago

> Using WebTransport [...] means that you don't have to worry about head-of-line blocking, which can be an issue with WebSockets. 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?

jbaczuk 4y ago
> I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets. What do you think it was/is? (not disagreeing)
- klabb3 4y ago
  Primarily load balancers and other cloudy middleware stuff. Most existing infrastructure is built on the request-response model (for good and bad). Maintaining a long lived connection makes more sense in the traditional single-beefy-server world, but with lambdas, containers, reverse proxies and everything being transparent and ephemeral it was too big of a game changer for cloud providers, in particular PaaS, I think.
  - inhumantsar 4y ago
    100% this. Scaling websockets is fine if your app sees consistent load or don't mind paying for unused capacity. 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.

fanweixiao 4y ago

Here is a public WebTransport Echo Server: https://webtransport.day https://webtransport.day, can try by Chrome.