# HTTP/2

## Summary


HTTP/2 is an alternative to HTTP/1.x that has been the workhorse protocol of the web for about 15 years. The older version served well in the days when web pages were simple. In February 2017, an average web page is seen to have more than a hundred assets -- JS files, CSS files, images, font files, iframes embedding other content, and more. This means that the browser has to make multiple requests to the server for a single page. User experience is affected due to long load times. HTTP/2 aims to solve these problems.

In particular, HTTP/2 allows multiple requests in parallel on a single TCP connection. HTTP/1.x allowed only a single request. HTTP/2 is also more bandwidth efficient since it uses binary encoding and compresses headers. It allows for Server Push rather than relying only on client requests to serve content.

## Discussion

### Are there any published results to show that HTTP/2 is better?

As of February 2017, a test comparing plain HTTP/1.1 against encrypted HTTP/2 showed that former is 73% percent slower. The server was in Dallas and the client was in Bangalore for this test. Early testing of HTTP/2 done in January 2015 showed that HTTP/2 uses fewer header bytes due to header compression. Its response messages were also smaller when compared against HTTP/1.1. For page loads, HTTP/2 took 0.772 seconds whereas HTTP/1.1 took 0.988 seconds. 


### How is the support for HTTP/2 from browsers and servers?

In 2015, popular browsers started supporting HTTP/2. This includes Chrome, Firefox, Safari, Opera and Edge. Chrome for Android started support in February 2017. 

At the server side, W3Techs reported that as of February 2017 12% of the servers support HTTP/2. Of these, 77% were on Nginx and 18% were on LiteSpeed. We see that when platforms that host a number of domains start supporting HTTP/2, there's a spike in HTTP/2 traffic. This can be seen when WordPress, CloudFlare, Blogspot and Wikipedia started support for the protocol. Apache introduced it on an experimental basis in version 2.4.17. KeyCDN reported that as of April 2016 68% of its traffic is HTTP/2. 


### Are there any security vulnerabilities with HTTP/2?

In August 2016, Imperva, Inc. reported four security vulnerabilities. These should be seen as implementation flaws rather than flaws in the protocol itself. At least one of these vulnerabilities was found in five different server implementations, which were subsequently fixed.


### Is the use of encryption mandatory for HTTP/2?

No. However, major browsers have said that they will support HTTP/2 only over TLS. The use of HTTP/2 over TLS is referred to as *h2*. The use of HTTP/2 over TCP, implying cleartext payload, is referred to as *h2c*.


### Do I have to change my application code when migrating to HTTP/2?

No. The idea of HTTP/2 was to improve the way packets are "put on the wire." For reasons of interoperability, HTTP Working Group was clear that the semantics of using HTTP should not be changed. This means that headers, methods, status codes and cache directives present in HTTP/1.x will remain the same in HTTP/2 as well. The semantics of HTTP remain unchanged. Hence, application code need not be changed. 

Of course, if you're building your own server code or custom client code, you will need to update these to support HTTP/2. The binary framing layer of HTTP/2 headers is not compatible with HTTP/1.x but this affects only HTTP clients and servers. A HTTP/1.1 client cannot talk to a server that supports only HTTP/2. 

If your application is using any of the well-known "best practices" for better performance over HTTP/1.1, the recommendation is to remove these best practices. The bigger migration challenge may be to use HTTP/2 over a secure connection if your applications are not currently using TLS.


### Didn't HTTP pipelining already solve this problem in HTTP/1.1?

HTTP/1.0 was really a stop-and-wait protocol. The client could not make another request until response to the pending request was received. HTTP/1.1 attempted to solve this by introducing HTTP Pipelining, which allows a client to send multiple requests to the server in a concurrent manner. Requirement from the server was that responses must be sent out in the same order in which requests were received.

In the real world, performance improvement due to pipelining is not proven. Proxies when implemented wrongly can lead to erroneous behaviours. Other factors including round trip time, packet size and network bandwidth affect performance. There's also the problem of head-of-line blocking whereby packets pending from one request can block other pipelined requests. For these reasons, most modern browsers disable HTTP pipelining by default. 


### What sort of hacks did developers use to improve performance before HTTP/2?

Some of the "best practices" to improve performance were really hacks to overcome the limitations of HTTP/1.x. These included domain sharding, inlining, image sprites and concatenation. The idea was to minimize the number of requests. With the coming of HTTP/2, these hacks will no longer be required.

There's one trick that browsers have used to improve performance without using HTTP pipelining. Browsers opened multiple TCP connections to enable concurrent requests. As many as six requests were used per domain. This is the reason why some applications deployed their content across domains so that multiple TCP connections to multiple domains will lead for faster page loads. With HTTP/2, multiple TCP connections will not be required. Multiple HTTP requests can happen on a single TCP connection. 


### What's the rationale for using binary encoding?

HTTP/1.x was a textual protocol, which made it easier to inspect and debug the messages. But it was also inefficient to transmit. Implementation was also complex since the presence of newlines and whitespaces resulted in variations of the message, all of which had to be decoded properly by the receiver. Binary formats are more efficient since fewer bytes are needed. Since the structure is fixed, decoding becomes easier. Debugging a binary protocol is more difficult but with the right tool support it's not much of a problem. Wireshark supports decoding and analysis of HTTP/2 over TLS. 


### Can you give some details of multiplexing HTTP requests on a single TCP connection?

HTTP/2 defines three things: 

    + Frame: Smallest unit of transmission that contains its own header.
    + Message: A sequence of frames that correspond to a HTTP request or response.
    + Stream: A bidirectional flow of messages and identified by a unique identifier.Thus, multiple streams are multiplexed (and interleaved) on to a single TCP connection. Each stream is independent of others, which means that even if one is blocked or delayed, others are not affected. HTTP/2 also allows prioritization of streams, which was not possible with HTTP/1.1.


### How is header compression done in HTTP/2?

Headers in HTTP/1.x can typically 500-800 bytes but can grow to the order of kilobytes since applications use headers to include cookies and referers. It therefore makes sense to compress these headers. HPACK is the name give to HTTP/2 header compression. It was approved by IETF in May 2015 as RFC 7541. 

Huffman coding is used to compress each header frame, which always appears at the start of each message within a stream. In addition, many fields of the header will remain the same across messages. HPACK removes this redundancy by replacing the fields with indices that point to tables that map these indices to actual values. There are predetermined static tables defined by HPACK. Dynamic tables allow further compression. 

A test on CloudFlare gave 76% compression for ingress headers, which translates to 53% savings on total ingress traffic. The equivalent numbers for egress are 69% and 1.4%. Results also showed that with more traffic, the dynamic table grows, leading to higher compression. KeyCDN reported savings of 30% on average. 


### How does Server Push improve performance?

In a typical client-server interaction, the client will request one page, parse it and then figure out other assets that need to be requested from the server. Server Push is a feature that enables the server to push assets without the client asking for it. For example, if a HTML page references images, JS files and CSS files, the server can send these after or before sending the HTML page. Each pushed asset is sent on its own stream and therefore can be prioritized and multiplexed individually. 

Since Server Push changes the way clients and servers interact, it's still considered experimental. Wrong configuration could lead to worse performance. For example, the server may push an asset even if the client has cached it from an earlier request. Likewise, servers may push too much data and affect user experience. Proper use of cookies, cache-aware Server Push and correct server configuration can aid in getting Server Push right. 

## Milestones

2012

IETF's HTTP Working Group begins looking at Google's **SPDY** protocol as a starting point for defining HTTP/2. 

Feb  
2015

IESG approves HTTP/2 as a **proposed standard**. 

May  
2015

HTTP/2 is published as **RFC 7540**.