ALPN Explained


What Is ALPN?

ALPN, or Application-Layer Protocol Negotiation, is a TLS extension that includes the protocol negotiation within the exchange of hello messages. ALPN is able to negotiate which protocol should be handled over a secure connection in a way that is more efficient and avoids additional round trips. The ever-growing in popularity HTTP/2 protocol, makes use of ALPN to further decrease website load times and encrypt connections faster.

How Does a TLS Handshake Work?

In order to fully understand the benefits of using the ALPN extension, the process of how a TLS handshake works should first be explained. According to the RFC 5246 specification, TLS involves the following steps:

  1. The Client and Server exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.
  2. An exchange of the necessary cryptographic parameters allow the client and server to agree on a premaster secret.
  3. A master secret is generated from the premaster secret and exchanged random values.
  4. Security parameters are provided to the record layer.
  5. The Client and server verify that their peer has calculated the same security parameters and that the handshake took place without tampering by an attacker.

This handshake process is the equivalent of two round-trips from the client to the server and back. The more round trips incurred, the longer the latency times will be and the longer a user must wait to receive information from the server.

The number of round trips is largely due to the handshakes to start communicating between client and server (e.g. DNS, TCP, HTTP)… If we can improve protocols to transfer this data with fewer round trips, we should also be able to improve page load times. – Mike Belshe, More Bandwidth Doesn’t Matter (Much)

How Does ALPN Work?

According to the RFC 7301 specification, with ALPN the client will send a list of supported application protocols to the server as part of the TLS ClientHello message. The server then selects a protocol and sends back that protocol in its ServerHello message. The application protocol negotiation can therefore be accomplished over one single round trip within the TLS handshake. This method also allows the server to associate a different certificate with each application protocol.

To visually demonstrate, an abbreviated ALPN handshake looks similar to the following diagram.


As we can see, the list of support protocols is sent to the server upon the first message thus minimizing the amount of round trips necessary.


NPN, or Next Protocol Negotiation, is the predecessor of ALPN and was widely used in conjunction with SPDY. NPN is quite similar to ALPN, however the main difference being that NPN does not include the list of supported protocols in its ClientHello message. The NPN extension is included in the ClientHello message however it is the server which sends back the list of protocols for the client to choose from.

ALPN on the other hand reverses this process. Thus the ClientHello message includes the list of supported protocols for the server to choose from. This change was made to help further align ALPN with other protocol negotiation standards. ALPN is also advantageous for reverse proxies as they are able to begin the resource selection process immediately after receiving the ClientHello message.

The Move Towards ALPN

With the growing popularity of HTTP/2 due to it’s better user experience and faster load times, the move towards ALPN is growing. With the official deprecation of SPDY in 2016, there has never been a better time to move to HTTP/2. With impressive speed results, to enhanced security features, all websites owners and visitors can benefit from the improvements that the ALPN extension has to offer in combination with HTTP/2.

To see if your website supports HTTP/2 and ALPN visit our HTTP/2 Test Tool.