CDN Connection Reuse: HTTP Keep-Alive, Multiplexing, and Connection Coalescing

Every new TCP + TLS connection costs 3 round trips before the first byte of content. At CDN scale, that cost multiplies across millions of requests. Connection reuse — through Keep-Alive, multiplexing, and coalescing — is how modern CDNs eliminate that overhead and deliver consistently low TTFB.

1. Why New Connections Are Expensive

When a browser or CDN edge opens a fresh connection to an origin, it must complete three sequential handshakes:

1. TCP handshake: SYN → SYN-ACK → ACK (1 RTT)
2. TLS handshake: ClientHello → ServerHello + certificate → Finished (1–2 RTT, even with TLS 1.3)
3. TCP slow start: Congestion window starts small, throttling initial throughput

On a 60ms RTT link, that is 180–240ms of dead time. For a CDN serving 50 assets per page, creating a new connection per asset would be catastrophic. If you are new to how edges and origins interact, start with our primer on how CDN works before tuning connection behavior.

Connection reuse solves this by keeping an established, warmed-up TCP/TLS session open for subsequent requests. The CDN maintains two reuse pools: client ↔ edge (browser to PoP) and edge ↔ origin (PoP to your origin). Both matter, but edge-to-origin reuse often yields the largest origin offload.

2. HTTP Keep-Alive: The Foundation

HTTP Keep-Alive (persistent connections) keeps the TCP connection open after a transaction completes, signaled by Connection: keep-alive in HTTP/1.1. It is enabled by default in HTTP/1.1 and mandatory in HTTP/2 and HTTP/3.

Without Keep-Alive, every request pays the full handshake tax. With it, the second request reuses the socket instantly:

Two directives control behavior:

• timeout: Idle seconds before the server closes the connection. CDN edge-to-origin is typically 60–90s.
• max: Maximum requests per connection before forced close. Set to 1000+ to avoid premature churn.

CDN Edge-to-Origin Keep-Alive Configuration

Most origins disable Keep-Alive by default or set timeouts too low (5–15s). The CDN then re-establishes connections constantly. Fix this at the origin:

For high-traffic origins, also tune net.ipv4.tcp_tw_reuse and file descriptor limits. A single CDN PoP may hold 500–2000 idle connections to your origin. That is expected and far cheaper than handshakes. Learn more about protecting that origin pool in our CDN security guide.

3. HTTP/2 Multiplexing: Many Streams, One Connection

Keep-Alive allows sequential reuse — one request at a time per connection. HTTP/2 multiplexing allows concurrent reuse. Multiple request/response streams share a single TCP connection via binary framing.

This eliminates HTTP/1.1 head-of-line blocking where browsers opened 6 parallel connections per domain to work around the one-request-at-a-time limit. With multiplexing, a page needing 80 assets needs one connection, not six.

Key multiplexing details for CDN tuning:

• Stream limits: Servers advertise SETTINGS_MAX_CONCURRENT_STREAMS (typically 100–128). The CDN respects this when fetching from origin over H2.
• Flow control: Each stream has its own window. A large asset will not block small API responses.
• Prioritization: Clients send priority signals. CDNs like Cloudflare and Fastly forward these to origin or reorder at edge.
• Head-of-line blocking: H2 still suffers TCP-level HOL blocking — one lost packet stalls all streams. HTTP/3 over QUIC fixes this with independent streams over UDP.

Enable H2 end-to-end. If your CDN negotiates H2 to the client but falls back to H1.1 to origin, you lose multiplexing where it matters most — the longer, higher-latency edge-to-origin path. Check your provider’s origin H2 setting and ensure your origin supports ALPN h2.

4. Connection Coalescing: One Connection for Multiple Origins

Connection coalescing lets a browser reuse a single HTTP/2 or HTTP/3 connection for multiple domains that resolve to the same IP and share a certificate. For example, www.example.com, static.example.com, and api.example.com can all share one connection if they are all on the CDN and covered by a SAN or wildcard cert.

This is critical for e-commerce and media sites that shard assets across subdomains for legacy reasons. Without coalescing, each shard forces a new connection. With it, sharding becomes free. See how this impacts storefront performance in our CDN for e-commerce guide.

Requirements for Coalescing

• Same IP address: All hostnames must resolve to the same CDN edge IP (typically via CNAME to the same distribution).
• Shared certificate: The TLS certificate must cover all hostnames via Subject Alternative Name (SAN). A wildcard *.example.com works for subdomains, but not for apex + subdomains unless both are listed.
• Same certificate authority trust: No cross-cert issues.
• HTTP/2 or HTTP/3: Coalescing does not apply to HTTP/1.1.

If coalescing fails, browsers open a second connection despite meeting the IP/cert criteria. Common causes: the first connection used a different IP due to DNS load balancing, or the server sent 421 Misdirected Request handling incorrectly. Using Anycast at the edge and a single SAN certificate minimizes these failures.

For HTTP/3, coalescing works identically but over QUIC. Since QUIC connections migrate across networks, coalesced H3 sessions survive client IP changes better than H2 — useful for mobile shoppers.

5. Comparing Connection Reuse Mechanisms

6. CDN Implementation Checklist

Use this sequence to maximize reuse without exhausting resources:

1. Enable Keep-Alive everywhere: Client→edge is automatic with modern CDNs. For edge→origin, set origin keepalive_timeout to 60–90s and ensure the CDN is configured to pool connections (e.g., AWS CloudFront origin keep-alive timeout, Cloudflare Argo).
2. Enable HTTP/2 and HTTP/3 to origin: Do not terminate H2 at edge and downgrade to H1.1. Test with curl --http2 -v https://origin.example.com from an edge-like location.
3. Consolidate certificates: Use one SAN certificate covering example.com, *.example.com, and any alternate domains served from the same distribution. This is the cheapest coalescing win.
4. Unify IPs: Point all coalescible hostnames to the same CDN distribution/CNAME. Avoid separate distributions per subdomain.
5. Set sensible pool sizes: For Nginx, keepalive 32 per worker is a good start for 4–8 workers. Too low causes churn; too high wastes memory.
6. Monitor reuse ratio: Track origin_reuse_ratio = reused_connections / total_requests. Aim for >0.85. Below 0.7 indicates timeout or pool misconfiguration.
7. Consider origin connection limits: If your origin is behind a WAF or DDoS protection layer, ensure idle connection limits do not evict CDN pools prematurely.

When Not to Reuse Aggressively

Long-lived pools can hold stale connections through origin deploys or firewall state timeouts. Implement:

• Health checks that proactively close pools on 502/503
• Graceful drain on origin restart (send Connection: close)
• Edge retry with fresh connection on first failure (most CDNs do this automatically)

For dynamic, authenticated APIs served via edge computing, consider shorter timeouts (30s) to avoid holding connections with per-request auth context.

7. Measuring the Impact

Before and after enabling reuse, measure:

• TTFB p50/p95: Expect 15–30% improvement on cache misses that hit origin.
• TLS handshakes/sec at origin: Should drop 60–80%.
• Origin CPU: TLS handshakes are CPU-intensive. Reuse often cuts origin CPU 10–20%.
• Connection count: ss -s or netstat -an | grep ESTAB | wc -l at origin.

Use WebPageTest with “First View vs Repeat View” and Chrome DevTools’ Connection ID column to visualize reuse. A well-tuned CDN should show 1–2 connections per domain for an entire page load, not 6+.

Connection reuse is not an optional optimization — it is the transport foundation that makes every other CDN feature faster. If you understand what a CDN is at the network level, reuse is the mechanism that turns geographic proximity into actual latency reduction.