Application-Layer Protocol Negotiation (ALPN)
ALPN negotiates the application protocol such as HTTP/2 or HTTP/3 inside the TLS handshake, avoiding an extra round trip to upgrade after the connection is established.
Definition
ALPN is a TLS extension that lets the client advertise a list of application protocols and the server pick one during the handshake, so both ends agree on HTTP/2, HTTP/1.1, or HTTP/3 without a separate negotiation request.
Context and scope
It is the mechanism browsers and servers use to decide which HTTP version a connection will speak.
Common misconceptions
- ALPN inspects packet payloads to choose a protocol
- an HTTP upgrade header is still required after the handshake
Anti-patterns
- advertising a protocol the origin cannot actually speak end to end
- mismatching ALPN IDs between a load balancer and its backends
Related concepts
Related examples
Authoritative source
Definition
ALPN is a TLS extension that lets the client advertise a list of application protocols and the server pick one during the handshake, so both ends agree on HTTP/2, HTTP/1.1, or HTTP/3 without a separate negotiation request.
It is the mechanism browsers and servers use to decide which HTTP version a connection will speak. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
The client sends a protocol list in the ClientHello and the server answers with exactly one selection; if no selection is made, both sides fall back to HTTP/1.1.
Because the choice happens at the TLS layer, a proxy that advertises h2 on the client side must also be able to forward HTTP/2 semantics or deliberately downgrade the protocol toward the backend.
Trade-offs and alternatives
For HTTP/3 the connection actually runs over QUIC, so ALPN advertises h3 while the transport is UDP, and servers that terminate QUIC dedicate UDP listeners separate from TCP. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that ALPN inspects packet payloads to choose a protocol. Another is that an HTTP upgrade header is still required after the handshake. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to advertising a protocol the origin cannot actually speak end to end and to mismatching ALPN IDs between a load balancer and its backends. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include PROXY Protocol for Client Address Preservation, Server-Timing Metrics Header, Hop-by-Hop Versus End-to-End Headers.