>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.

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.

>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.

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.

> Required TLS would also increase security.

TLS is not inherently required for HTTP/2 on the backend.

TLS is sort of required on the frontend mainly because browser vendors don’t want to deal with broken middleware that expects all traffic on TCP port 80 to be HTTP/1.x.

This is less of a concern on the backend, and there are practical implementations of cleartext HTTP/2 today, including nginx and Apache on the server side, libcurl on the client side, and others.

Sure, not absolutely required but it's the default way and most of the time you want all the links to be encrypted. What's the use of a secure last-mile when the origin isn't?

Since backend servers will usually be running internet-facing web-servers, HTTPS on HTTP/2 is already included. I'm sure the certificate checking can be skipped though in certain cases but the overall required by default mode is much better than HTTP/1 now.