ALPN

What is ALPN?

ALPN (Application-Layer Protocol Negotiation) is a TLS handshake extension that lets the client and server agree on which application protocol they’ll speak — for example, HTTP/2 versus HTTP/1.1 — during the TLS handshake itself, rather than after the secure connection is already established. The client lists the protocols it supports in its opening handshake message, the server picks one, and by the time the encrypted connection is ready, both sides already know what protocol to use. It’s a small piece of plumbing with outsized importance: ALPN is what made HTTP/2 deployable on the web.

Why negotiating during the handshake matters

The problem ALPN solves is efficiency and cleanliness. Without it, if a client wanted to use a newer protocol like HTTP/2, it would have to establish the connection and then negotiate an upgrade — an extra round trip, and an awkward one over TLS. ALPN folds the protocol choice into the handshake that’s happening anyway, so there’s no additional round trip and no separate upgrade dance. This mattered enormously for HTTP/2 adoption: browsers and servers use ALPN to negotiate HTTP/2 over TLS seamlessly, falling back to HTTP/1.1 if the other side doesn’t support the newer version. In practice, essentially all HTTP/2 (and now HTTP/3-related negotiation contexts) rely on ALPN — when your browser loads a site over HTTP/2, ALPN is the invisible mechanism that agreed on it. It works hand-in-glove with SNI: SNI (in the same ClientHello) tells the server which site you want so it can pick the right certificate, while ALPN tells it which protocol you want to speak — together they let a single TLS endpoint serve many sites over the best mutually-supported protocol.

Where engineers actually encounter it

For most application developers ALPN is invisible — it just works inside the TLS libraries and the browser/server stack. But it surfaces in real infrastructure situations. Load balancers and reverse proxies must support and correctly pass ALPN for HTTP/2 to work end-to-end; a common gotcha is a load balancer that terminates TLS and negotiates HTTP/2 on the front side but only speaks HTTP/1.1 to the backend (often fine, but something to understand when reasoning about performance and protocol behavior). TLS termination points (CDNs, ingress controllers, API gateways) all participate in ALPN, and misconfiguration there is why “HTTP/2 isn’t being used even though I enabled it” tickets happen. ALPN is also the negotiation vehicle for other protocols layered on TLS beyond HTTP. The practical mental model: ALPN and SNI are the two ClientHello extensions that make modern multi-tenant, multi-protocol TLS endpoints possible — SNI answers “which host?”, ALPN answers “which protocol?”, both settled before the first byte of encrypted application data flows.

What people get wrong

• Blaming the app when HTTP/2 doesn’t engage — often it’s a load balancer or proxy not passing ALPN correctly, not the application itself.
• Confusing ALPN with SNI: they ride in the same handshake but do different jobs — SNI selects the certificate/host, ALPN selects the protocol.
• Overlooking it in the TLS termination chain — every hop that terminates TLS (CDN, LB, ingress) must handle ALPN for the intended protocol to be negotiated end to end.

Primary source: RFC 7301: TLS Application-Layer Protocol Negotiation