3 ms·
> 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
by klabb3 4y ago
> 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.
- jeroenhd 4y agoYes, 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).