
Our journey from WebSockets to HTTP/2: A story of what we learned - fjaguero
https://building.sentisis.com/our-journey-from-websockets-to-http-2-4d069c54effd
======
Matthias247
Some remarks on that:

> What if I still want to use WebSockets? You can either hold your breath and
> wait for WebSockets support on HTTP/2 or just stick with them under
> HTTP/1.1.

There's not a need to have "Websockets on HTTP/2". Websockets through an
HTTP/1.1 update work fine and will continue to work in the future. The thing
is: Both websockets and HTTP/2 take control over the whole TCP connection
after you switch to one of those protocols, so they are exclusive. But that's
fine, if you use websockets on HTTP/1 you also use one TCP connection
exclusively for that websocket connection, and other HTTP requests must
utilize different connections. It might be possible to embed websocket frames
in HTTP/2 streams, but it's not really worthwhile, since you get the HTTP/2
overhead (per-stream flow-control on top of TCP flow control) and not much of
the benefit (sites typically have one websocket connection, not dozens or
hundrets).

On SSE vs Websockets:

Both have some advantages and disadvantages: SSE is easy to use, works with
the standard HTTP programming model (one request and a loooong streamed
response) and can therefore also use HTTP-related infrastructure (proxies,
load-balancers, etc.). However you might not be able to use subscriptions from
lots of SSE sources, since they also need an individual TCP connection in
HTTP/1, and browsers limit those. With HTTP/2 that's less of a problem, but
some might want to support HTTP/1 for backward compatibility reasons. Also if
you have multiple SSE endpoints you do not have ordering guarantees, since
they are running fully independent on different TCP connections.

With websockets you are not restricted to HTTP semantics, it's just a
bidirectional connection which supports and kind of semantics on top
(including request-response models, arbitrary streaming from client to server
and the other way around). And on top of that connection there's an ordering
guarantee. Websockets also have a better support for binary data transmission
compared to SSE, which only supports "lines of text" by default. Of course you
can base64 encode everything, but e.g. encoding JSON as base64 just in order
to send it as "messages" over SSE sounds not very sexy from a performance
perspective.

All in all I would say one should prefer SSE for stateless systems where the
main usecase in server->client notifications, and websockets for stateful
systems where there is some stored state on the server for each connection.

