Offer application protocols
01ALPN lets a TLS client offer application protocols without adding a separate negotiation round-trip.
After selection of h2 and successful completion of this ordinary handshake, application bytes use HTTP/2. ALPN does not add a protocol label to every TLS record.
Source for this drawing: RFC 7301 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
ALPN means Application-Layer Protocol Negotiation; TLS means Transport Layer Security. ALPN selects the application protocol inside a TLS connection, not a TLS version, cipher suite, hostname or port.
- ALPN means Application-Layer Protocol Negotiation; TLS means Transport Layer Security. ALPN selects the application protocol inside a TLS connection, not a TLS version, cipher suite, hostname or port.
- The client MAY include extension type16 in ClientHello. Its registered, non-empty opaque byte strings are listed in descending client preference. Names must not be truncated; they are not case-folded or treated as NUL-terminated text.
- The registered h2 identifier means HTTP/2 over TLS; its bytes are 68 32 in hexadecimal (RFC9113 §3.1). http/1.1 is eight bytes. Ordinary application data follows a successful TLS handshake in this example; early data has extra rules.
RFC7301 §6 registers http/1.1; RFC9113 §3.1 defines h2. ALPN is not a new encryption algorithm. RFC8447 §3 adds TLS to the registry name; it does not replace this byte-list mechanism.
Read the RFC section ↗