4 ms·

>The lack of HTTP/2 on the backend to origin connections is a big sad mystery. Sad, sure, but its not a mystery. As of HTTP/1.1 these proxies already pools TCP

>The lack of HTTP/2 on the backend to origin connections is a big sad mystery. Sad, sure, but its not a mystery. As of HTTP/1.1 these proxies already pools TCP/IP connections between the proxy and its origin (the backend server), so it doesn't gain the same connection multiplexing/windowing/cardinality benefits that HTTP/2 to end client gets. This means for many proxy code bases H2 to origin is just a nice to have. Obviously, by prioritizing like that you miss other nice to haves like push.

manigandham 9y ago
HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking. HTTP/2 connections will also be pooled but are able to sustain many more concurrent requests because of multiplexing, while also setting certain requests as higher priority. It's a major improvement for high volume services. The performance and features are why Google's gRPC uses it as the foundation for microservice communications at scale and low-latency.
- voidlogic 9y ago
  >HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking. This is true, however this limitation just increases the size of the connection tool needed for the same concurrency. I'm not saying HTTP/2 isn't better, I'm saying its less better for middleware than end user connection optimization.
  - derefr 9y ago
    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.

manigandham 9y ago

HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking. HTTP/2 connections will also be pooled but are able to sustain many more concurrent requests because of multiplexing, while also setting certain requests as higher priority. It's a major improvement for high volume services. The performance and features are why Google's gRPC uses it as the foundation for microservice communications at scale and low-latency.

voidlogic 9y ago
>HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking. This is true, however this limitation just increases the size of the connection tool needed for the same concurrency. I'm not saying HTTP/2 isn't better, I'm saying its less better for middleware than end user connection optimization.
- derefr 9y ago
  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.