(Dis-)Advantages of using HTTP/2 or HTTP/3 for backend connections (reverse proxy -> backend)?

What are the advantages and disadvantages of using HTTP/2 or even HTTP/3 for connections between reverse proxies and backends?

I haven't really come across this and only ever see H2 and H2 deployed in front of reverse proxies and CDNs. ASFIK H2 and H3 usually (H2C is a thing, right?) require TLS which would make it unsuitable if you'd like to do TLS-termination away from the backend.

H2 could also be more difficult to set up and configure than a basic HTTP/1.1 backend. On the plus side, wouldn't multiplexing be an improvement over the fixed number of concurrent requests that you get over the n-number of TCP connections the reverse proxy will open for HTTP/1.1 backend connections?

What are the savings and costs in terms of load on CPU, memory, and IO?

Does anyone have real-world experience with this?

Solution 1:

I wrote this answer on the topic on Stack Overflow and it’s still pretty relevant.

The benefits of HTTP/2 (and HTTP/3) are primarily for the front end. You’re unlikely to see any real, noticeable benefits over the back end. And, given support is often lacking for these newer protocols I wouldn’t lull myself to enable it with so few gains.

The one interesting point (as noted as an edit at the bottom of my linked answer) is the security issues that can come into play when downgrading HTTP/2 (or 3) at front end to HTTP/1.1 at the backend. These are mostly due to problems in HTTP/1.1 (that 2 and 3 were designed to address) and bad implementations for these edge cases but still, it does give one good reason to avoid HTTP/1.1 at all if possible.

Saying that there definitely is a cost to HTTP/3 at present and I wouldn’t recommend it at the back end (or even the front end you manage to be honest - using via CDNs is the way to go IMHO). It’s still too new (the final RFCs have not even been published yet!) and we’ve spent years optimising TCP in operating systems and throughout the networking stack. The fact that QUIC is in user space rather than in the kernel has many advantages for the future but speed and efficiency are not one and of them. The gap is closing (as this report from Fastly shows) but it’s still there.

So once HTTP/2 becomes ubiquitous (which is happening fast than most would thought!) I’d go for it, but I wouldn’t stress over it for the back end (it is something that’s worth the extra effort on the front end). HTTP/3 is 5 years behind and only just being finalised so even less to recommend it at the back end for now. But I honestly believe QUIC and HTTP/3 is going to be exciting for the future, so definitely one to keep an eye on.