SPDY (pronounced speedy); NPN (Next Protocol Negotiation); ALPN (Application Layer Protocol Negotiation) and HTTP/2

SPDY (pronounced as SPeeDY) :-



SPDY is an experimental protocol developed at Google, designed to reduce the latency of web pages. Specifically, its goal is to address the limitations of HTTP/1.1 and to remove existing bottlenecks like:-

  • head of line blocking,
  • inefficient use of underlying TCP connections,
  • and header bloat

SPDY achieves reduced latency through compression, multiplexing, and prioritisation.
The name "SPDY" is a trademark of Google and is not an acronym.

Implementing a new protocol across the web, where varieties of devices exists along with multiple range of OS across platforms, is like play with fire. This may lead to random dropped connections with no or very little troubleshooting information and will cause frustration for the end user. To deal with this, SPDY is delivered via SSL. End-to-end encrypted tunnel allows the client and the server to exchange SPDY frames without intervention by intermediate nodes. It's important to note that SPDY does not require SSL, but in practice, SSL is a pragmatic choice to get to a working solution.

So, how the client and server will know to use the SPDY after the establishment of TLS/SSL session ?
Here comes NPN is picture.
Next Protocol Negotiation (NPN) is a TLS extension, which was developed as part of the SPDY effort at Google to enable efficient application protocol negotiation during the TLS handshake.

The biggest difference between HTTP/1.1 and SPDY, is that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY splits requests into either control or data. SPDY has shown evident improvement from HTTP, with a new page load speedup ranging from 11.81% to 47.7%.

On February 2015, Google had announced that following the final ratification of the HTTP/2 standard, support for SPDY would be deprecated, and that support for SPDY will be withdrawn completely in 2016.

Application Layer Protocol Negotiation (ALPN):-

ALPN is a revised and IETF approved version of the NPN extension. Application Layer Protocol Negotiation (ALPN) is a TLS extension that introduces support for application protocol negotiation into the TLS handshake (please see TLS Handshake blog), thereby eliminating the need for an extra roundtrip required by the HTTP Upgrade workflow.

Specifically, the process is as follows:

  • The client appends a new ProtocolNameList field, containing the list of supported application protocols, into the ClientHello message.
  • The server inspects the ProtocolNameList field and returns a ProtocolName field indicating the selected protocol as part of the ServerHello message.

The server may respond with only a single protocol name, and if it does not support any that the client requests, then it may choose to abort the connection. As a result, once the TLS handshake is complete, both the secure tunnel is established, and the client and server are in agreement as to which application protocol will be used, they can begin communicating immediately.

ALPN eliminates the need for the HTTP Upgrade exchange, saving an extra roundtrip of latency. However, note that the TLS handshake itself still must be performed; hence ALPN negotiation is not any faster than HTTP Upgrade over an unencrypted channel. Instead, it ensures that application protocol negotiation over TLS is not any slower.

In NPN, the server advertised which protocols it supports, and the client then chose and confirmed the protocol whereas in ALPN, this exchange is reversed: the client now specifies which protocols it supports, and the server then selects and confirms the protocol. The rationale for the change is that this brings ALPN into closer alignment with other protocol negotiation standards. In other words, ALPN is a successor to NPN, and NPN is deprecated. Clients and servers that rely on NPN negotiation will have to be upgraded to use ALPN instead.

HTTP/2 :-

HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web. It is based on SPDY. HTTP/2 was developed by the Hypertext Transfer Protocol working group (httpbis, where bis means "repeat" or "twice") of the Internet Engineering Task Force. HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardised in RFC 2068 in 1997.

Why not HTTP/1.2 ?

To achieve the performance goals set by the HTTP Working Group, HTTP/2 introduces a new binary framing layer that is not backward compatible with previous HTTP/1.x servers and clients. Hence the major protocol version increment to HTTP/2.

HTTP/2 leaves most of HTTP 1.1's high level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.

The standardisation effort came as an answer to SPDY, an HTTP-compatible protocol developed by Google. HTTP/2 uses a fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for attacks on the protocol.

The httpbis working group considered Google's SPDY protocol, Microsoft's HTTP Speed+Mobility proposal (SPDY based), and Network-Friendly HTTP Upgrade.

HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).

Although the standard itself does not require usage of encryption, most client implementations (Firefox, Chrome) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

Roughly 1.2% of all websites support HTTP/2 till August 2015.

OTHER