HTTP/2 is the official name for a new version of the network protocol made famous by the success of the World Wide Web. The previous version, HTTP/1.1, was standardized in RFC 2616 [1] in 1999, and the web has changed a lot since then. Modern websites are made up of many elements that browsers need to load successively: scripts, CSS files, images, advertising, and much more.

The top 1000 sites in 1999 contained only an average of about 10 objects. In the years between 2009 and 2012, the number of objects doubled from 50 to 100, and as a result, the average load time increased by 48 percent between 2010 and 2012 – despite faster systems and higher bandwidths [2]. The steady rise in website complexity led to a need for web standards that use network resources more efficiently.

HTTP/2 is mostly compatible with HTTP/1.1 because methods, status codes, URIs, and headers remain the same [3]. You won't need to change your existing web applications. However, new applications will benefit from the new functions available in HTTP/2. The new version aims to speed up surfing, play well with common HTTP applications, and support web servers, web APIs, proxy servers, firewalls, and content delivery networks.

The important changes included with the new HTTP include header compression, server-push functionality, the elimination of head-of-line blocking, and parallel loading of multiple resources with a single TCP connection.

Remembering HTTP/1.1

Before describing some new features of HTTP/2, I'll begin with a review of some features of HTTP/1.1 and why they leave some room for improvement.

Loading a website with HTTP 1.x automatically results in a wait because the browser needs to establish a TCP connection. Establishing a connection generates overhead, which connectionless transport protocols such as UDP consciously avoid. However, the TCP protocol needs a connection to provide higher reliability. HTTP 1 requires a separate TCP connection for each individual HTTP request, and the connection closes after the server responds.

HTTP/1.1 introduced persistent connections. A connection established between an HTTP client and an HTTP server is considered persistent if it is not immediately cut off after a resource is transferred; instead, a persistent connection offers the option to send further HTTP requests. Persistent connections are defined with the header Connection: Keep-Alive.

A persistent connection lets the web browser load two images through the same connection. However, loading can still take a while because clients process the data received before they request more. This problem was recognized at an early stage, and developers made an attempt to solve it using pipelining in HTTP/1.1.

HTTP pipelining is certainly useful for high-latency connections that send multiple HTTP requests within a TCP connection without the need to wait for the corresponding responses. Pipelining could be used with idempotent HTTP operations such as GET, HEAD, PUT, and DELETE. Unfortunately, pipelining is hardly used: Only a few servers and browsers support it.

The reason pipelining is hardly used is because of a requirement that is difficult to implement in practice: The response from the server needs to comply with the order of the requests. However, some server implementations process requests in parallel and respond as soon as results are available. If the client has sent several queries, and processing the first one takes longer than processing the second, the client receives the responses in the wrong order, which contradicts the HTTP specification.

The order might not play a role for static content, but it is important for dynamically computed content. To ensure the correct order, the server must line up the requests and then work through them one after another, which reduces any performance benefits.

Because of the complications associated with pipelining, HTTP/1.1 places its requests one after another. A client must therefore wait for the response to the first query before it can proceed with the second. If the first request must transfer a large amount of data, the second request will be blocked for some time, even if it only transfers a small amount of data.

Loading a modern website would be too slow if web browsers couldn't open multiple TCP connections at the same time. Firefox, for example, uses six persistent connections per host by default.

However, six connections is still too few to quickly load a website's many individual resources, so some websites use domain sharding. The sharding process distributes the website's resources to multiple hosts so the web browser can open more connections. However, the additional sockets for the connections take up storage space and CPU time on both the client and the server.

Google developed the experimental network protocol SPDY [4] to counter this problem. HTTP/2 adopted parts of the SPDY protocol. Head-of-line blocking improves performance by multiplexing and transferring multiple resources at the same time (Figure 1). Using this technology, it is possible to transfer a small resource while the data transfer for a big resource is still going.

Figure 1: Parallel streams allow simultaneous data transfer in both directions.

HTTP/2 Connections

Theoretically, HTTP/2 only requires one TCP connection between the client and server. The data traffic in this connection is divided into multiple streams, which exchange one or more messages in both directions. A message implements either a client request or a server response. The messages themselves consist of frames, the smallest units of communication in HTTP/2. Each frame has a header, with which it is uniquely associated with a stream. HTTP/2 uses a binary format for the frames instead of text.

Practically any number of streams can open within a connection in order to send multiple messages at the same time. Both sides keep the exchanged messages apart on both sides with the unique numbering of streams. The new HTTP connection multiplexing revolutionizes communication between the browser and server. A browser can submit new requests through the mechanism while the server is still transferring data packages.

Header compression provides additional performance benefits. Hpack [5] is the compression format for the efficient representation of header fields in HTTP/2. Originally, we wanted to use Gzip for this purpose, but then the decision was made to use a less efficient but safer method because of the CRIME exploit [6].

Push Options

Once the client and server establish a connection, the server can transfer additional resources for the browser. For example, if a web browser requests an HTML page using GET, the web server can anticipate that the browser will also want images, scripts, and stylesheets referenced in the HTML page. The server can push these resources to the browser independently (Figure 2).

Figure 2: HTTP/2 transfers page elements using push operations.

WebSockets, which were introduced in HTML version 5 to provide full-duplex communication, are not yet obsolete. A common HTTP connection for transferring push notifications from the server to the client can be used with the server-sent events and the HTML 5 WebSockets.

HTTP/2 also prioritizes the streams and can transfer text with a higher priority than images in order to reduce the discernible latency on the client side. In principle, a server should first transfer all the data the browser needs to build the website; all other content can follow afterwards.