Tangentially related.. like HTTP, Websockets currently operate over TCP.
Is there plans to port them to QUIC as well? It's been many years since my networking class but I'd assume Websockets would stand to gain quite a bit as well.
Websockets (the protocol) are mostly defunct in comparison to HTTP/2 and QUIC. Porting websocket based code should mean converting it to HTTP{2,3}. The main reason that's not possible today is due to large existing library support for websockets on both the server side and directly in browsers.
I disagree. Websockets sweet-spot is still the "server wants to send messages to the client" usecase. This does not work (as well) with http/2. Dunno about /3, but it's really a fundamentally different model than the reques/reply of http.
Websockets are largely obsolete because nowadays, if you create a HTTP/2 fetch request, any existing keepalive connection to that server is used, so the overhead that pre-HTTP/2 XHR connections needed is lost and with it the advantage of Websockets.
Exactly. I think most people didn't use Websockets due to the theoretical performance improvement over HTTP 1.1, but because it's a different programming model.
I think it's very shortsighted to assume people should (or want) to roll their own streaming protocol when Websocket is already a great fit for many applications.
You can use server-sent-events or use do some custom streaming format inside the response body. The latter might not work well, due to the fact that arbitrary streaming APIs might not yet be exposed by all browsers (ReadableStream on fetch API: https://caniuse.com/#feat=streams).
Afaik XHR allows you to access received data in a streaming fashion, but the XHR type will always buffer the full received payload internally. So if you try to stream a large amount of data over it you will eventually run out of memory. If you want to consume a potentially endless stream with custom encoding you need the fetch API with streaming support for that (https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...), as far as I understood. Or websockets.
That is one reason that e.g. gRPC streaming support doesn't work trivially in browsers.
gRPC is already HTTP/2.0 and has bidirectional streams. I imagine it would work like that.
Browsers are almost at the point where they can just talk gRPC to the backend, but gRPC uses HTTP trailers which browsers do not support.
I don't think, from a networking standpoint, that websockets was really necessary. A browser and a web server already have a socket open that they send messages in either direction on. It's just so much of the web was designed around "client asks for something, server sends the result and closes the connection" that some transition period was necessary to distinguish between the two cases. (You didn't necessarily provision your web server for maintaining hundreds of thousands of open connections.) But now that people are used to the idea of connections sticking around in the context of HTTP, it's no big deal to send arbitrary data over that connection.
But can the client in HTTP/2 send more data to the server after it has received something, without having to send a full HTTP request? If not, I don't see how something like agar.io, which requires constant updates to the server on every mouse movement, can work without tremendous header overhead.
Not really, it's rpc and websocket is not. I looked into this for a project and neither http/2 or gRPC does the same thing : fully bidirectional, long-lived stream with no weird semantics or hacks.
There is still a place for WebSockets in HTTP/2. The fairly recent RFC 8441 defines a mechanism to reserve a single HTTP/2 stream for bidirectional WebSockets.
It is feasible for a similar mechanism for also work for HTTP/3, just no-one has gone to the effort yet.
With quic I'm guessing you could have multiple Websocket and http3 streams within one connection and have them not block eachother on packet loss, which is pretty neat.
It's true that HTTP/2 could eventually replace lots of websocket use-cases, and integrate better with other HTTP code (e.g. frameworks, authentication, etc).
However currently if you need streaming and message ordering guarantees in both direction, you are currently still limited to websockets. HTTP might become more useful once body streaming APIs in both directions are available in browsers.
Is there plans to port them to QUIC as well? It's been many years since my networking class but I'd assume Websockets would stand to gain quite a bit as well.