HTTP2 multi-origin connection sharing vs DNS requests

I’m trying to understand the behavior observed in my tests.

We use an HTTP2-enabled CDN that is available under multiple domain names (that all resolve to the same IP at the end for a given user, normally – unless the DNS requests happen at different time and the load balancing kicks in), for example:

The domains were created long time ago for sharding + differentiating http vs https calls, but essentially they are all equivalent nowadays.

I was thinking this would be an antipattern as it would cause a DNS+TCP+TLS for each of those domains, but actually it’s not true. It seems that HTTP2 is intelligent enough to reuse the connection even across the domains if it’s sure it’s talking to the same server.

Test page:


As you can see, Chrome immediately reuses the existing h2 connection (no DNS, no TCP, no TLS).
Firefox does a DNS query first, and then reuses the existing h2 connection (no TCP, no TLS).

I can explain the behavior of Firefox:

  • DNS request to both servers, notices the same IP
  • TLS handshake returns a cert with *, subjectAltName

What is surprising to me though is that Chrome doesn’t do DNS request to get IP of the second server. How does it know that static1 and static2-ssl are the same thing then?

Having read a bit, seems that the things I observed are known as “connection coalescing” and “ORIGIN frame”, and that Chrome (and Safari) support ORIGIN frame without the DNS query.

(edited): But apparently only Firefox has implemented ORIGIN frame as of today:

So I’m still puzzled how the requests to the two subdomains get merged into one H2 connection in Chrome, and the second subdomain doesn’t trigger a DNS request?

Appears there’s a second DNS requesting being made in the Chrome case

Doesn’t appear in the waterfall but it’s in the packet capture

@andydavies Thanks a lot!