HTTP/2 is here! Goodbye SPDY? Not quite yet

Why choose, if you can have both? Today CloudFlare is introducing HTTP/2 support for all customers using SSL/TLS connections, while still supporting SPDY. There is no need to make a decision between SPDY or HTTP/2. Both are automatically there for you and your customers.

If you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you. With this improvement, your website’s audience will always use the fastest protocol version when accessing your site over TLS/SSL.

Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard.

In February of 2015, the IETF’s steering group for publication as standards-track RFCs approved the HTTP/2 and associated HPACK specifications.

After more than 15 years, the Hypertext Transfer Protocol (HTTP) received a long-overdue upgrade. HTTP/2 is largely based on Google's experimental SPDY protocol, which was first announced in November 2009 as an internal project to increase the speed of the web.

The main focus of both SPDY and HTTP/2 is performance, especially latency as perceived by the end-user while using a browser, with a secondary focus on network and server resource usage. One large benefit of HTTP/2 is the ability to use a single TCP connection from a browser to a website, or in the case of CloudFlare, a reverse proxy. As such, CloudFlare is in the perfect position to provide the benefits of HTTP/2 to all CloudFlare users by accelerating the web surfing experience between browsers and CloudFlare, without the need to change anything on the origin server.

Although HTTP/2 is based on Google's experimental SPDY protocol, it has evolved, incorporating several improvements in the process. Nevertheless, it maintains many of the benefits known from SPDY:

• Multiplexing and concurrency: Several requests can be sent over the same TCP connection, and responses can be received out of order, eliminating the need for multiple connections between the client and the server and reducing head-of-line blocking.

• Stream dependencies: The client can indicate to the server which resources are more important than others.

• Header compression: HTTP header size is reduced.

• Server push: The server can send resources the client has not yet requested (This is not yet implemented within NGINX or at CloudFlare, but will become available in the future. It is currently enabled on the experimental test bed server https://http2.cloudflare.com/).

While the HTTP/2 specification does not require TLS, all major browser vendors have indicated that they will only support HTTP/2 over a TLS connection. As a result, CloudFlare only supports HTTP/2 over TLS. Of course, TLS is free with CloudFlare’s Universal SSL.

Let’s have a look at some real life numbers from the CloudFlare website (https://www.cloudflare.com) for average page load time. These values (based on a 48h timeframe) should provide an estimate of what improvements you can expect using SPDY and HTTP/2:

Access via HTTP Protocol Version

Average Page Load time

HTTP 1.x

9.07 sec.

SPDY/3.1

7.06 sec.

HTTP/2

4.27 sec.

CC BY 2.0 image by woodleywonderworks

It's no secret that CloudFlare uses a modified version of NGINX as the reverse proxy component in charge of terminating the end-user connection. After NGINX announced availability of the NGINX Open Source 1.9.5 Release with HTTP/2 support on September 22nd, the wait for HTTP/2 seemed to be over.

The introduction of the new HTTP/2 module for NGINX also meant that the existing NGINX SPDY module could not be used in parallel. You had to choose to either support the termination of HTTP/2 or SPDY connections on a single NGINX server, but not both. The justification for this approach was based on Google saying goodbye to SPDY and deprecating the protocol, starting in January 2016.

But what would have actually happened if CloudFlare turned off SPDY today while turning on HTTP/2? What would be the impact on our existing user base as well as our customers? As the best decisions are always ones backed by solid data, we looked at what replacing SPDY with HTTP/2 today would mean.

CloudFlare started support for SPDY in June of 2012 and upgraded to the current version of SPDY (3.1) in February 2014. It’s pretty straightforward for us to determine how many SSL/TLS connections are established today via SPDY/3.1 versus HTTP/1.x.

During the week before our HTTP/2 launch, 80.38% of all SSL/TLS connections to our own website at www.cloudflare.com were made over SPDY/3.1.

The overall ratio of SPDY/3.1 connections that we see on our network is lower than this due to the number of bots, scrapers, and attackers using HTTP/1.x. Instead, the above number is a good representation of what legitimate traffic a regular website should see, after traffic has been sanitized.

HTTP/2 usage

Without actually rolling out HTTP/2, it’s not that easy to determine what percentage of users to any individual website will benefit. But, there are two approaches to getting a useful estimate up front.

Let's start with the one that you could easily replicate yourself for your own website by using Google Analytics.

The well-known website caniuse.com provides information on what browsers and their version support HTTP/2. Combine this with data from Google Analytics on how often a website was accessed by this type of browser for a given time, and you you gain the information of what ratio of requests could have been served over HTTP/2. During the last 48 hours, web traffic to our own website from HTTP/2-capable browsers looked like this:

HTTP/2 capable browser

Global Market Share

IE 11 on Windows 10

0.14%

Edge 12, and 13

0.35%

Firefox 36 - 45

5.09%

Chrome 41 - 49

15.06%

Safari 9

0.91%

Opera 28 - 34

0.57%

Safari for iOS 9.1

1.07%

Opera 30 for Android

0.01%

Chrome 46 for Android

3.59%

Firefox 41 for Android

0.01%

Total

26.79%

This would mean that a little more than a quarter of all browsers accessing our website could have used HTTP/2 during this time frame.

Again, we see a larger number of non-browsers, which don’t fall into any of the above buckets, on our edge. This is due to bots, crawlers, scrapers and the like. The numbers above represent typical website traffic after it has been sanitized by CloudFlare.

After looking at the ratio of browsers that caniuse.com estimates to support HTTP/2 today, we can see a large discrepancy between our estimated 26.79% and the ratio of between 61.7% and 67.89% that caniuse.com estimates. Unfortunately, caniuse.com is overestimating the ratio of some of the above browsers. In particular, the value for "Chrome 46 for Android" appears to incorrectly include all Chrome for Android versions, even though these versions do not have HTTP/2 support.

Both SPDY and HTTP/2 provide numerous benefits to website owners. Without support for HTTP/2 or SPDY on the browser or server side, the connection can only be established via HTTP/1.x, which usually means higher page load times and a reduced experience.

Replacing SPDY with HTTP/2 today would have meant dropping support for faster web surfing from 80.38% of our end-users to 26.79% of them, which is a difference of 53.59 percentage points.

Instead, by doing both, we ensure that users with browsers only supporting SPDY/3.1 can still get the best web surfing experience on our customers’ sites, while at the same time ensuring that users with newer browser versions that only support HTTP/2 are and will continue to get the best experience possible.

After running our own Website www.cloudflare.com with HTTP/2 and SPDY support for more than 48 hours, we were able to extract some real-life numbers for connections established over HTTP/2 and SPDY versus HTTP/1.x:

Protocol Version

Percentage of Hits

HTTP/1.x

19.36%

SPDY/3.1

57.02%

HTTP/2

23.62%

These real-life numbers show that we were on the right path with not removing SPDY in favor of HTTP/2.

CC BY 2.0 image by Chris Potter

You can easily check the HTTP/2 support status for a web page yourself. For this, we need to understand first how the protocol negotiation for both HTTP/2 and SPDY works. Browser and web servers use Application-Layer Protocol Negotiation (ALPN) or the slightly older Next Protocol Negotiation (NPN) Transport Layer Security (TLS) extension to negotiate what protocol the server and client "speak".

Using OpenSSL, you can easily validate what versions CloudFlare's Edge servers are able to use:

openssl s_client -servername www.cloudflare.com -connect www.cloudflare.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: h2, spdy/3.1, http/1.1

The advertised protocols include h2 for HTTP/2, spdy/3.1 for the current version of SPDY and http/1.1 for HTTP/1.1 as a fallback mechanism.

In a similar way, clients will present to the web server the protocols they support.

Want to learn more about how HTTP/2 and SPDY works, the benefits it brings to your website's audience, and how we can help you speed up your website? Check out our HTTP/2 resources at cloudflare.com/http2