Connection coalescing with ORIGIN Frames: fewer DNS queries, fewer connections

One Web Page, Dozens of Connections

Rendering a modern web page is rarely a single request. Browsers routinely open dozens of TCP or QUIC connections just to load one page: each distinct hostname referenced by the HTML typically requires its own DNS query and its own connection. On the Cloudflare blog alone, there are 32 different hostnames involved. That translates to 32 DNS lookups and at least 32 connections if none of them can be reused.

Every new connection adds load to server infrastructure and exposes client metadata to the network. Plaintext hostnames in DNS queries and TLS handshakes reveal a user’s browsing habits to any on-path observer. Reducing the number of connections is therefore both a scalability and a privacy concern.

Research presented at the ACM Internet Measurement Conference 2022 examines how connection coalescing — particularly via the HTTP/2 ORIGIN Frame extension — can cut down that overhead. The work combines large-scale measurements of the web’s structure with a live deployment on production traffic to show that a fairly small change from server operators can produce significant gains.

Coalescing Requires More Than a Shared Certificate

Connection coalescing is not the same as connection reuse. Reusing an existing TLS channel for another request to the same hostname is simply standard HTTP behavior. Coalescing is more ambitious: it allows a browser to send requests for a different hostname over an existing connection.

The basic precondition is that both hostnames appear in the TLS certificate’s Subject Alternative Name (SAN) list. But that alone is not enough. The certificate proves the server is authorized for both names; it says nothing about whether the second hostname is actually reachable at that same server. Browsers need an explicit signal before they will route a request for a different name over an existing connection rather than opening a new one.

There are two signals available. The first is IP-based: if two hostnames resolve to the same IP address, a browser may infer they are served by the same endpoint. This is implicit and often accidental, and it forces operators to tightly couple their DNS records to their server deployment — a fragile dependency to manage at scale. The second signal is the ORIGIN Frame, an HTTP/2 and HTTP/3 extension that lets a server explicitly declare on an established TLS connection which origin set it is authorized to serve. The hostnames listed in the frame must appear in the certificate’s SAN entries, but crucially, they do not need to share IP addresses with the connection’s original hostname.

The ORIGIN Frame gives operators a way to decouple coalescing from DNS. It is also safe to deploy if implemented per the specification: a client that receives an ORIGIN Frame can send requests for those origins, and can expect no HTTP 421 (Misdirected Request) errors in response. A client that doesn’t support the frame simply keeps opening new connections as before.

Where Coalescing Would Work Best

The first experimental step was to measure the scale of the opportunity. The researchers captured page load data for 500,000 popular websites using an automated Chrome (v88) instance for each visit. They logged DNS queries, TLS connections, and certificate details in HTTP Archive (HAR) format.

To approximate where coalescing would help, they mapped each hostname to its autonomous system (AS) number. If subresources for a page are spread across few ASes, few server operators control the relevant certificates and connections — meaning change is easier to roll out. The measurements showed that more than 50% of web pages require contact with no more than six ASes to load all subresources. Roughly 14% of pages need exactly two ASes. In other words, a small number of large operators (CDNs, chiefly) are in a position to enable coalescing for a large fraction of the web.

Modeling on top of those measurements predicted what the impact could be. By combining observed DNS lookup counts with an idealized deployment of ORIGIN Frames on existing certificates, the analysis points to reductions of over 60% in both DNS queries and TLS connections at the median.

The same analysis suggests that certificate changes need to be modest. Over 60% of existing certificates could already benefit from ORIGIN Frames without modification. With at most ten hostnames added to a certificate’s DNS SAN entries, over 92% of the websites in the study could achieve successful coalescing. For CDNs, adding just three or four of the most commonly requested hostnames to each certificate would yield most of the benefit.

Testing ORIGIN Frames on Production Requests

Modeling is one thing; the second experiment asked whether browsers actually behave as expected. During early 2022, the team selected 5,000 websites that used cdnjs.cloudflare.com as a subresource. For the experimental group, they modified the TLS termination endpoint to send an HTTP/2 ORIGIN Frame on each connection listing cdnjs.cloudflare.com as an additional origin. The control group received a frame with an arbitrary, unused hostname.

Certificates for all sites in both groups were renewed. For the experimental set, cdnjs.cloudflare.com was added to the SAN list. For the control set, a third-party hostname of identical size was added instead, so that any measured difference could not be attributed to certificate size.

Among the 1% sample of Firefox requests to the experimental sites, the results showed a reduction of over 50% in new TLS connections per second. The control group showed no such change. Fewer new connections mean fewer full TLS handshakes and less cryptographic verification on both client and server. What the live experiment did not show was meaningful page-load performance gains. The interaction between connection count, congestion control, and resource object sizes varies with network conditions, so “no worse” is the more accurate way to summarize the performance effect.

Why Coalescing Matters Beyond Performance

The gains from the ORIGIN Frame experiment are mostly about removing work: fewer handshakes and fewer DNS lookups, with the associated operational costs on the server and CPU overhead for the client. But connection coalescing also has a direct privacy benefit. When a browser opens a new connection or makes a plaintext DNS query, the hostname is exposed to any network observer — even when TLS is protecting the HTTP payload itself. SNI in the TLS handshake and DNS queries sent over port 53 give on-path adversaries a clear view of a user’s activities.

Connection coalescing reduces exposure to such metadata leaks. If a subresource request at cdnjs.cloudflare.com can be multiplexed onto an existing connection that was established for the main site, there is no new TLS handshake and no extra DNS query in plaintext. The client and server carry out fewer distinct handshakes across the whole load, meaning fewer pieces of cleartext metadata are exposed.

For browsers, fewer connections also open up longer-term possibilities: endpoint resource scheduling, content prioritization, and HTTP early hints become more attractive when a connection is used for a broader set of requests rather than being pointlessly duplicated for each hostname.

Future work may make the deployment burden even smaller. The IETF’s CERTIFICATE Frame draft would allow a server to prove its authority over additional hostnames after the connection is established, without requiring those names to appear in the initial certificate at all. That would remove the certificate modification step entirely. Until then, renewing certificates with a few extra SAN names and sending the ORIGIN Frame on an existing edge is a relatively contained change.

Better Defaults for the Web

Looking across the two experiments, the conclusion is straightforward: the infrastructure to cut DNS queries and TLS connections by more than half already exists, but almost no one is using it. The research shows the change is feasible — no new certificate infrastructure for most servers, only a few SAN additions for CDNs — and that serious reductions in connection counts result.

The work also highlights that the standards are still waiting for wider adoption. With only Firefox supporting ORIGIN Frames among browsers, and no major server implementation deployed as of the writing of the paper, the ecosystem has not yet turned the RFC into practice. The project’s forks of Go’s net and http packages were released as open-source or intermediate implementations to allow others to test the behavior themselves.