Re:A Guide to HTTP/2 Server Push
by derefr on Monday April 10, 2017 @04:56PM
(#14082476)
If you have 100k people who've opened e.g. websocket connections to your backend, I doubt you're going to structure things as a 100k-socket connection pool open to your backend. You've probably either:
A. got that scaled across at least 100 backend servers, even if those servers' CPUs are almost entirely idle; or
B. have chosen a completely different, extremely roundabout architecture involving client async requests with HTTP 202 responses + client polling of a "status of server-side promises" endpoint; or
C. are effectively manually doing what HTTP2 does automatically, by having a "stateful-connection load-balancer server" (e.g. SocksJS) that mediates between long-lived client connections, and short-lived RPC requests with async responses from your backend.
Whereas, with HTTP2, that could very easily be one machine, taking in those 100k nearly-idle connections, and passing them over one TCP socket to one backend.
A. got that scaled across at least 100 backend servers, even if those servers' CPUs are almost entirely idle; or
B. have chosen a completely different, extremely roundabout architecture involving client async requests with HTTP 202 responses + client polling of a "status of server-side promises" endpoint; or
C. are effectively manually doing what HTTP2 does automatically, by having a "stateful-connection load-balancer server" (e.g. SocksJS) that mediates between long-lived client connections, and short-lived RPC requests with async responses from your backend.
Whereas, with HTTP2, that could very easily be one machine, taking in those 100k nearly-idle connections, and passing them over one TCP socket to one backend.