What's new in HTTP 2

A fourth draft of the in-development HTTP 2.0 protocol was published by the Internet Engineering Task Force (IETF) on July 8. The update to HTTP was first published in draft form in late 2012, but this revision is "marked for implementation", with interoperability tests slated to begin in August. HTTP 2.0 is largely a remapping of existing HTTP semantics that is designed to improve throughput of client-server connections. Consequently, it should not significantly affect the design or implementation of web applications. Browsers and web servers, however, can use HTTP 2.0 to replace many of the tricks they are already employing to decrease HTTP latency.

HTTP 2.0 is adapted largely from earlier work done on SPDY, an experimental extension to HTTP cooked up at Google, but supported by a number of other prominent software vendors (e.g., Mozilla). The newly-published IETF draft splits the changes up into three categories: HTTP Frames, HTTP Multiplexing, and a new "server push" feature. HTTP Frames are the message format for HTTP 2.0; they are designed to serialize HTTP requests, responses, and headers in a manner suited to faster processing. HTTP Multiplexing interleaves multiple requests and responses over a single HTTP connection. The server push feature allows servers to pre-emptively initiate the transfer of a resource to clients. The intent of the push functionality is that the server would know that a request for the resource is likely to come soon (such as another resource on the same page), so starting the transfer ahead of time makes better use of the available bandwidth and reduces perceived latency.

"Perceived latency" is an oft-recurring phrase in the new protocol; most if not all of the changes are tailored to allow servers to optimize delivery of web content to clients. Some of these changes mimic techniques already found in other protocols (such as TCP), which is perhaps what has prompted criticism of HTTP 2.0 from several bloggers and social media commenters. After all, TCP already has multiplexing and flow control, so it seems fair to ask whether implementing them in HTTP as well really adds anything. The presumed answer, of course, is that the web server is in the position to do application-level flow control and make quality-of-service (QoS) decisions while the underlying TCP stack is not. How effectively that works out in practice will presumably be seen once interoperability testing begins in earnest.

Frames and headers

HTTP 2.0 connections are initiated in the same way as they are in HTTP 1.x. The first difference comes in the enclosure of requests and responses in frames over the HTTP connection. Frames begin with an eight-byte binary header that lists the length of the frame payload, the frame type, any necessary flags, and a 31-bit HTTP stream identifier. A "stream" in HTTP 2.0 is one of the independent sequences that is multiplexed over the HTTP connection; in general each resource (HTML page, image, etc.) could get a separate stream, with the frames from all of the streams interleaved over the same HTTP connection. A stream can also be kept open and used to move subsequent requests and resources. However, the stream IDs are not reused over the connection; once a stream is closed, a new ID is created for the next stream. The IDs also reflect who initiated the stream: even numbers for server-initiated streams, odd for client-initiated.

The adoption of a binary header is certainly a difference from HTTP 1.x, even if the requests and responses that HTTP 2.0 frames encode are unchanged. But the differences are designed to decrease apparent latency. Marking the frame size at the beginning allows the connection endpoints to better manage multiplexing the connection. In addition, HTTP HEADERS frames can be compressed to reduce the payload size—a feature that was previously available only for HTTP resource data.

The frame types defined include the aforementioned HEADERS, the DATA frames carrying page resources, SETTINGS frames for exchanging connection parameters (such as the number of allowable streams per connection), RST_STREAM frames to terminate a stream, PING frames for measuring the round-trip time of the connection, WINDOW_UPDATE frames for implementing flow control, PRIORITY frames for marking a specific stream as important, and the new server push frames.

Server push uses two frame types; PUSH_PROMISE is a server-to-client frame that designates a stream ID that the server wants to push to the client. An uninterested client can reject the suggestion by sending a RST_STREAM frame, or accept the DATA frames that the server sends subsequently. For dealing with an overly pushy server, the other new frame type, GOAWAY, is provided. Clients can send this frame to a server to tell it to stop initiating new streams altogether. The nightmare scenario of mobile web users paying by the kilobyte, of course, is chatty servers pushing unwanted streams; the HTTP 2.0 specification mandates that a server must stop initiating streams when it is told to shut up via a GOAWAY frame.

Multiplexing

Intelligently managing the stream IDs on a connection is the essence of HTTP 2.0's multiplexing. Both the client and the server can create new streams, and can use their streams to send resource requests or to return data. By multiplexing several streams over one HTTP 2.0 connection, the idea is that several requests and responses can share the bandwidth, without setting up and tearing down a separate connection for each request/response pair. To a degree, bandwidth sharing is already available in HTTP 1.1's pipelining feature, but it has serious limitations.

For example, HTTP 1.1 requires that servers answer requests in the order that they arrive. In practice, browsers often open up multiple HTTP connections to a single server, which consumes additional memory on both sides, and gives the server multiple requests to handle at once. Naturally, the web application has other mechanisms available to decide that these connections are part of a single conversation, but by shuffling them into a single HTTP connection, the server has less guesswork to do and can do a better job of optimizing the connection. Furthermore, it can do this without maintaining a large collection of open ports and without spinning up separate processes to handle each connection.

QoS features are enabled by HTTP 2.0's WINDOW_UPDATE and PRIORITY frames. The client can increase the amount of data in flight by widening the flow-control window with WINDOW_UPDATE. Or, rather than telling the server to send more, the client can decrease the window to throttle back the connection. The server, in turn, can designate a stream ID with a PRIORITY frame, which allows it to send the most important resources first, even if the requests came in in a different order.

It is also noteworthy that the flow control options offered in HTTP 2.0 are defined to be hop-to-hop, rather than being between the server and browser endpoints. This enables intermediate nodes like web proxies to influence the throughput of the connection (presumably for the better).

Last, but not least, the HTTP 2.0 draft mandates one change to HTTPS support. Supporting endpoints are required to implement the Application Layer Protocol Negotiation Extension to TLS (TLSALPN), which is itself an in-progress IETF draft specification. TLSALPN is a mechanism for TLS clients and servers to quickly agree on an application-level protocol; mandating its presence means that HTTP 2.0–capable endpoints can agree on the use of HTTP 2.0 and begin taking advantage of its throughput from the very start of the conversation.

Apart from these new features, HTTP 2.0 introduces no changes to the established semantics of HTTP: the request methods, status codes, and headers from HTTP 1.1 remain the same. The stated goal is to provide backward compatibility; the hope being that server and browser implementations can provide an HTTP 2.0 encapsulation layer and begin offering throughput improvements without changing web pages or applications themselves. Both the Google Chromium and Mozilla Firefox teams have expressed their support for the protocol, as have several of the proprietary browser vendors. At this point, the big questions still to be answered are things like how HTTP 2.0 will affect WebSockets, which also implements multiplexing and QoS, but is usually considered part of HTML5.

Microsoft had pushed for a different approach to HTTP 2.0—reusing the framing, multiplexing, and encoding semantics of WebSockets—but at this stage is the standardization process, the draft resembles SPDY considerably more. There will no doubt continue to be other means for clients and servers to reduce the perceived latency of the web (for instance, by shuttling binary data over WebRTC's data channels), but as the fundamental layer of web connections, HTTP has more places to make an impact—not just browsers and servers, but proxies, gateways, and all of the other nodes along the route.