[HN Gopher] Using WebTransport
___________________________________________________________________
Using WebTransport
Author : politician
Score : 107 points
Date : 2022-09-16 15:41 UTC (7 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| hpx7 wrote:
| 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
| afavour wrote:
| 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.
| vasilvv wrote:
| There's a simple echo server demo at
| 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/
|
| 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).
| judah wrote:
| 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.
| eis wrote:
| 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 but have since verified it
| myself that at least Chrome v103 on Android 12 does indeed
| support WebTransport.
| dmitriid wrote:
| > 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.
|
| Because it's not a standard. The status is "Editor's draft"
| which is barely above "A draft on a coffee-stained napkin"
| josephg wrote:
| Well, it's been in the works for years (since at least 2019
| from recollection). It's made it's way through the IETF and
| W3C, and it's been implemented in Chrome and Edge since the
| start of the year.
|
| 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.
| nonethewiser wrote:
| > To be clear: I like WebTransport and want to see it supported
| widely
|
| 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?
| eis wrote:
| Good question :)
|
| 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.
| josephg wrote:
| Even reliable streams benefit from webtransport.
|
| 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.
| markdog12 wrote:
| > 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.
| eis wrote:
| > Interesting, do you have a source? Or did you try it?
|
| https://caniuse.com/webtransport > The
| article does seem to answer these questions.
|
| Not for me. There's no usecase mentioned that is not possible
| today unless you count using it from inside a worker as a
| usecase I guess.
|
| 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.
| markdog12 wrote:
| > https://caniuse.com/webtransport
|
| 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.
| eis wrote:
| > Yeah, it seems there's an older entry in there that's
| confusing. Not sure.
|
| I have just tried it on Chrome 103 on Android 12 and
| WebTransport worked. The information on caniuse.com is
| indeed incorrect. > WebTransport does not
| really do anything that was previously impossible from an
| API standpoint, it improves on existing methods.
|
| Yup, that's why I want to see it widely supported. Any
| simplification is good for the web. Though WebTransport
| unfortunately does not improve on every aspect of the
| existing APIs. It also has limitations that WebRTC does
| not have like P2P or easily piping media for using in
| MediaStreams.
| strbean wrote:
| 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
| eis wrote:
| The information there is indeed incorrect. I have updated
| my comment accordingly.
| vasilvv wrote:
| > There seems to be not too much interest in or hype about
| WebTransport.
|
| 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/
| strbean wrote:
| > Unreliable datagrams? WebRTC
|
| 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?
| Sean-Der wrote:
| Do you still see challenges with doing WebRTC on a server? I
| work on https://github.com/pion/webrtc so would love to hear
| what could be better :)
| paulgb wrote:
| We've done some cool things with Pion, like running GIMP
| server-side and streaming it to a browser[1]. So thanks!
|
| 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/15527735676490
| 91584
| ptrwis wrote:
| And are you going to run a dedicated signaling service and
| do all that STUN karate to just connect the peer to a
| publicly available server?
| Sean-Der wrote:
| > dedicated signalling
|
| 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`
| ptrwis wrote:
| What I mean is that compared to, for example, WebSockets
| and WebTransport, WebRTC is more difficult to use (not
| through third-party libraries but "native" WebRTC data-
| channel API). But you are right and I was wrong, STUN is
| not necessary.
| moron4hire wrote:
| God, I wish I could find something like this for .NET.
| eis wrote:
| You don't need STUN to connect to a publicly available
| WebRTC server.
| smasher164 wrote:
| Yeah I just wanted to do a client-server app on a UDP-like
| socket, but WebRTC had so much complexity that it put me off.
|
| It's gotten better now, but WebTransport is the solution
| we've needed for a while.
| EGreg wrote:
| I got curious about HTTP/3 and hit a 404 LMAO
|
| What is this?
| mmh0000 wrote:
| Check out this book written by the main cURL developer. It
| covers all the benefits and drawbacks:
|
| https://http3-explained.haxx.se/en/
| kmeisthax wrote:
| 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
| dmitriid wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| mwcampbell wrote:
| > 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.
| jeffparsons wrote:
| 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
| felipellrocha wrote:
| If you are doing p2p, though, webrtc makes a lot of sense since
| the apis there are designed to punch through a nat
| ok123456 wrote:
| [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
| aaaaaaaaaaab wrote:
| Another web "standard" unilaterally declared by Google. How
| wonderful!
| WHATDOESIT wrote:
| 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 wrote:
| HTTP 3? Oh, you mean the thing that used to be HTTP-over-
| QUIC, another "standard" unilaterally declared by Google :-)
| superkuh wrote:
| 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 wrote:
| >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 wrote:
| 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.
| intelVISA wrote:
| I just want QUIC over QUIC (QUICly) but I don't have the
| same lobby power over the IETF sadly.
| seabrookmx wrote:
| gQUIC != QUIC, though it definitely inspired it (the same
| way SPDY inspired HTTP/2).
|
| 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.
| CharlesW wrote:
| > _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.
| josephg wrote:
| WebTransport wasn't designed or "declared" by Google. It came
| through the IETF. I'm not sure who wrote the initial draft, but
| the WG chairs are at Google and Microsoft, and the current
| draft has authors from Apple and Facebook.[1]
|
| 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/
|
| [2] https://datatracker.ietf.org/wg/webtrans/about/
| orliesaurus wrote:
| 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.
| eyelidlessness wrote:
| 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 wrote:
| 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 wrote:
| Do you really expect a deep discussion of the subject in a
| TL/DR line?
| orliesaurus wrote:
| No but a better one line answer, sure!
| cush wrote:
| Maybe answers your question. It does in some cases and not
| in others. So it might replace your need for websockets.
| have_faith wrote:
| > 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 wrote:
| 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.
| tomxor wrote:
| That's only referring to current maturity... the
| differences are more nuanced. I'd recommend reading the
| article, it's not super long.
| yeeticus wrote:
| 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 wrote:
| 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.
| markdog12 wrote:
| 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-...
| rektide wrote:
| > _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
| Eduard wrote:
| 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/
| kirbyfan64sos wrote:
| 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?
| encryptluks2 wrote:
| 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?
| znpy wrote:
| Basically udp over udp?
|
| Because that's what it is basically... effectively, a way to work
| around firewalls.
| MuffinFlavored wrote:
| What does WebTransport do that WebSockets do not do? How is
| performance comparatively?
| hpx7 wrote:
| 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 wrote:
| https://github.com/cloudflare/quiche/issues/1114
|
| Looks like no Rust HTTP/3 "WebTransport" support yet?
|
| WebTransport and QUIC are different, right?
| kevinmgranger wrote:
| WebTransport is an HTTP/3 only protocol, and HTTP/3 is a
| QUIC only protocol. Different but interlinked.
| MuffinFlavored wrote:
| UDP -> QUIC -> HTTP/3 -> WebTransport?
| DrBenCarson wrote:
| Correct
___________________________________________________________________
(page generated 2022-09-16 23:00 UTC)