Hacker News Reader

Comment by klabb3 | Hacker News Reader

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

View on HN

Websockets are implemented everywhere, though, to the point where they shouldn't have been (server side events are often a much better fit).

Maybe your products don't use Websockets but the days of polling HTTP requests are long gone. Almost every web framework I know has some kind of support for websockets in its design and every proxy I know can easily handle websockets.

Sure, stuff like lambdas don't work but that's because the proprietary cloud provider API chooses not to implement them, probably for good reason. These types of programs are abstractions on top of abstractions, taking away all difficulty in multi server scaling at the cost of low level control over your code, and it turns out Websockets are just that: low level, stateful APIs that people wanted the browser to have.

The reason WebTransport is implemented is that people wanted UDP websockets. Unity developers have been asking for this stuff for years, for example, because running game logic over TCP out even QUIC can be terribly slow and stuttery. The websocket stack isn't really built for datagram exchange and support for the new feature depends on other factors (HTTP/3, for one) so I think it makes sense to make this a separate API. The mental model of what APIs are out aren't lossy is a lot clearer this way.

> The reason WebTransport is implemented is that people wanted UDP websockets. [...] because running game logic over TCP out even QUIC can be terribly slow and stuttery.

Http/3 already uses quic so this is just using quic datagrams, which is sane.. But why not an extension to websockets (only available over http/3) when everything else is the same?

EDIT: Got annoyed enough to look it up and I think this is the key:

> While WebSockets starts as a HTTP/1.1 protocol, WebTransport works on top of several different protocols, including some that WebSockets doesn’t support.

So apparently you have to start websockets over http/1.1 before upgrade which necessitates a separate connection per stream. Still, couldn't this be.. Fixed within the existing spec, or a major version bump? In either case, I guess it doesn't matter much, but I suspect a lot of people will be confused with the name.

Yes, websockets follow an HTTP upgrade path and can't leverage datagrams.

An breaking update in the HTTP spec would be quite painful, especially for backend libraries that are often updated only when absolutely necessary.

The fact the API isn't even finished yet, let alone standardised, also makes it a good idea to add it as a new feature. I don't think browsers should mess with standardised protocols to implement some draft that's still in progress because they're very likely to break something, especially since this particular type of socket is only available to a small number of websites and use cases (those on servers supporting transferring raw HTTP/3 to the application server, so probably not most CDN/DDoS protection services).

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

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.

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.

Isn't a viable horizontal scale solution to have a central allocator, that assigns a new client to a pool instance that then has a direct websocket with the client? So there's no central choke point or "websocket load balancer that all frames flow through"

That's how I've always done it for scalable deployments of my remote browser isolation service.

How would one add datagrams to WebSockets?

Add JS APIs. Make http/3 a pre-requisite. Then use quic datagrams. So basically the same method they're proposing.

I'm sure there's something I'm missing though but I still can't figure out what.

So WebTransport does what you were proposing to do?

Reply on news.ycombinator.com