Should HTTP/3 Be Used Between a CDN Edge and an Origin?

Question

I'm familiar with the HTTP/3 and QUIC specifications somewhat, and I'm building web services and infrastructure for bringing an application online.

The general structure of a request to my service looks like this:

A client makes a request to the CDN edge, which sends traffic to the load balancer at my origin, which sends internal traffic to the actual application service.

Currently, clients use regular HTTP/2 over TCP and TLS for each hop. The final hop is not TLS but plaintext since it is within my network, but this could easily be upgraded to TLS.

One of the advantages of HTTP/3 is that since it is independent of TCP, multiple requests can occur in parallel without blocking each other. There are, of course, many other features that come with HTTP/3 like network roaming, etc. but I am primarily concerned with performance and concurrency.

I also see that many CDNs now offer HTTP/3 at the edge, and so it's relatively easy to enable this for the first hop from user to CDN edge. I can also most likely configure my origin (which is an AWS network load balancer) to accept traffic that is routed to Istio and ultimately to the application service. Istio supports HTTP/3 in beta so it's something I could enable there as well.

My main question is this: would it actually be worth it to configure HTTP/3 behind the CDN edge, ie at and within my origin? In theory, I'd imagine that even though the CDN will use multiple TCP connections to my origin for HTTP/1 and HTTP/2, each connection would still be subject to head-of-line blocking. If a request on a single connection takes a lot of time, the CDN edge will have to use other connections to send the request over in order to ensure a low response time and avoid blocking. Thus, it appears that every link in my chain would benefit to some degree from HTTP/3, but is there documentation that specifies whether this is important/worthwhile, or do I need to go do it myself and profile it? I'm primarily interested not in benchmarks and arbitrary tests, but whether doing HTTP/3 all the way through the stack is an architecturally sound and recommended choice by the designers of the protocol.

Answer 1

One of the advantages of HTTP/3 is that since it is independent of TCP, multiple requests can occur in parallel without blocking each other.

This generally doesn't end up being a significant factor. CDNs have the benefit of aggregating traffic from a large number of clients, which smooths out request rates. They can afford to open enough connections to the origin to handle most spikes, and leave them open during lulls, so that there's almost always an open socket to send a request over.

There will probably come a time when h3 from CDN to origin becomes the norm, but no, you shouldn't expect to see a big performance improvement from it. And h3 is new enough that we're still learning a lot about its security implications and how to tune it for performance. If you have a CDN, there's something to be said for letting them do all of the hard work while you get the benefit of HTTP/3 at the edge just by clicking a checkbox, and checking back in 5 years or so when the implementations are more mature.

Answer 2

The benefit of doing that will NOT be much.

Consider the big picture of having a content available at CDN edge and http/3 supported:

1. The user device can get the cached version of the content from nearest PoPs(Point of presence)
2. The content as example, if its video for example, will allow extreme low latency playback thanks to http/3 (no headline blocking and single connection)
3. No further blocking from server side processing is there because its content that is generated and is cache(able) for some duration.

Now considering the above if your request already needs a backend processing or refresh from origin server, than you are already introducing the latency to the end user request, than the benefit of http/3 would be next to negligible already, it would be just like connection numbers will be less overall and maybe little faster than normal http/2 but to user it will still be of not much gain.

hope this helps.