CDN Protocol Negotiation: ALPN, NPN, and Automatic Protocol Selection

Modern CDNs don’t force a single HTTP version. Instead, they negotiate the optimal protocol — HTTP/1.1, HTTP/2, or HTTP/3 — in milliseconds during the TLS handshake using ALPN. Here’s how it works, why NPN was retired, and how automatic selection impacts performance at the edge.

When a user connects to a CDN edge, both sides support multiple application protocols. The client might speak HTTP/1.1, h2, and h3; the edge might support all three plus origins that only speak HTTP/1.1. Protocol negotiation is the mechanism that picks the best mutual option without extra round trips or failed connections. At scale, getting this right determines whether you benefit from multiplexing, header compression, and 0-RTT, or fall back to legacy behavior.

If you’re new to edge delivery, start with how a CDN works and what a CDN is before tuning protocol settings — negotiation only matters once you understand the TLS termination and caching layer in front of your origin.

1. Why Protocol Negotiation Matters at the CDN Edge

Unlike origin servers, a CDN must serve a wildly heterogeneous fleet: Chrome on HTTP/3, Safari on HTTP/2, legacy bots on HTTP/1.1, and IoT devices with limited TLS stacks. Hard-coding a protocol would break compatibility or waste performance.

Negotiation solves three edge-specific problems:

• Compatibility without downgrade attacks: The client and edge agree on the highest secure protocol both support, avoiding cleartext fallback.
• Connection efficiency: Multiplexed protocols (h2, h3) drastically reduce connection count, which lowers TLS and TCP overhead on PoPs handling millions of concurrent sessions.
• Origin shielding: The edge can speak h2/h3 to viewers while maintaining HTTP/1.1 keep-alive to origins that haven’t upgraded, isolating complexity.

This is also where caching strategies intersect with protocols: a single HTTP/2 or HTTP/3 connection can fetch dozens of cached assets in parallel, improving cache hit utilization and reducing origin load compared to six parallel HTTP/1.1 connections.

2. NPN: The SPDY-Era Predecessor

Next Protocol Negotiation (NPN) was introduced by Google around 2010 to negotiate SPDY — the precursor to HTTP/2. NPN worked, but with a critical flaw: the server sent its list of supported protocols after the TLS handshake completed, in an unencrypted ServerHello extension.

That design created two issues. First, middleboxes that inspected TLS could block or strip the extension. Second, it added complexity for strict TLS 1.3 implementations. The IETF deprecated NPN in favor of ALPN (RFC 7301) in 2014, and all major browsers removed NPN support by 2016.

You’ll still see NPN in legacy OpenSSL logs or old Nginx configs (ssl_protocols with npn). If you do, treat it as technical debt. Modern CDNs, including Cloudflare, Fastly, Akamai, and AWS CloudFront, exclusively use ALPN. There is no performance reason to keep NPN enabled, and it can trigger handshake failures with TLS 1.3-only clients.

3. ALPN: How It Works Inside the TLS Handshake

Application-Layer Protocol Negotiation (ALPN) moves negotiation into the TLS handshake. It’s elegant because it adds zero round trips.

Here’s the exact flow at a CDN edge:

1. ClientHello + ALPN Extension: The client sends a TLS ClientHello listing supported application protocols in priority order, e.g., h3, h2, http/1.1. This is sent in cleartext but within the TLS handshake.
2. Edge Selection: The CDN edge (e.g., Nginx, Envoy, or custom Rust stack) compares the client list against its own supported list and origin health. It selects the most performant mutual protocol.
3. ServerHello + ALPN: The edge returns its choice in the ServerHello ALPN extension, e.g., h2.
4. Encrypted Application Data: All subsequent data is sent using the negotiated protocol. For h3, the edge will also send an Alt-Svc: h3=":443"; ma=86400 header to advertise QUIC for the next connection.

ALPN identifiers are strict strings registered with IANA: h2 for HTTP/2 over TLS, http/1.1 for HTTP/1.1, and h3 for HTTP/3 (though h3 is technically negotiated via QUIC’s TLS 1.3 + Alt-Svc, many CDNs still echo h3 in ALPN for consistency).

Because ALPN is part of the handshake, it’s visible in packet captures and openssl s_client output. That makes debugging straightforward compared to NPN’s post-handshake dance.

4. Automatic Protocol Selection: How CDNs Choose

ALPN tells the edge what the client supports. Automatic selection decides what to use based on a policy engine. Most CDNs follow this hierarchy:

4.1 Client Preference + Edge Capability

The edge intersects the client’s ALPN list with its own. If the client offers h2, http/1.1 and the edge supports both, it picks h2. If the client is a legacy crawler offering only http/1.1, the edge honors it — no upgrade attempt.

4.2 Network Conditions and QUIC Fallback

HTTP/3 over QUIC uses UDP. Some corporate firewalls block UDP 443. A smart CDN won’t force h3 on first contact. Instead, it completes the first connection over h2, advertises Alt-Svc, and lets the browser probe QUIC in parallel. If QUIC succeeds, the next connection uses h3 with 0-RTT. If it times out, the browser stays on h2. This is why you’ll see h3 in ALPN but actual h3 usage at ~65-85% depending on geography.

4.3 Origin Protocol Compatibility

The viewer-facing protocol is independent from the origin-facing one. A CDN can terminate h3 at the edge and proxy to origin over h2 or HTTP/1.1 keep-alive. This is configured via origin protocol policy. For dynamic APIs where load balancing algorithms spread requests across origins, keeping origin connections as HTTP/1.1 or h2 avoids QUIC’s UDP complexity inside the data center.

5. Performance Impact: Does Negotiation Cost You?

Measured overhead is negligible, but the choice has major performance consequences:

• Handshake size: ALPN adds 10-30 bytes to ClientHello. No extra RTT.
• Multiplexing gain: h2/h3 multiplex 100+ streams over one connection vs. 6 connections for http/1.1. This cuts TLS handshakes by 80%+ on asset-heavy pages.
• Head-of-line blocking: h2 still suffers TCP HoL blocking; h3 over QUIC eliminates it. On lossy mobile networks, h3 can reduce p95 load time by 10-30%.
• Header compression: h2 uses HPACK, h3 uses QPACK — both reduce header overhead by ~30-50% vs. http/1.1, significant for API-heavy sites.

When evaluating cost vs. speed, remember that fewer connections also mean lower cost optimization impact — fewer edge CPU cycles for handshakes and better cache coalescing.

6. Configuring and Debugging Protocol Negotiation

You rarely configure ALPN directly on a CDN — it’s automatic. But you should verify it and tune origins.

Verify ALPN from the edge

Origin configuration (Nginx example)

If you terminate TLS at origin or use “Full Strict” mode, ensure your origin advertises ALPN correctly:

Common pitfalls

• Forcing h2 at origin breaks health checks: Some load balancer health checks use HTTP/1.0. Keep http/1.1 in your ALPN list.
• Old OpenSSL: OpenSSL 1.0.1 supports NPN but not ALPN. Upgrade to 1.1.1+ for ALPN + TLS 1.3.
• QUIC blocked: If your WAF blocks UDP, clients will never upgrade to h3. Monitor alt-svc success rate in CDN analytics.

For a broader architecture view, review CDN fundamentals to see where negotiation fits between DNS, TLS, and caching.

Conclusion

NPN proved that protocol negotiation was necessary; ALPN proved how to do it cleanly inside the TLS handshake. Today, automatic protocol selection at the CDN edge means you don’t choose between compatibility and performance — the edge negotiates h2 for multiplexing, upgrades to h3 when QUIC is reachable, and falls back to http/1.1 when needed, all without extra latency.

Leave negotiation on automatic, verify with openssl s_client and curl -v, and ensure your origin supports ALPN with a modern OpenSSL build. The result is fewer connections, faster page loads, and a future-proof edge ready for HTTP/3 ubiquity.