Learning HTTP/2

Chapter 4. Transition to HTTP/2

To be flip and mildly unhelpful, one could say that in order to support HTTP/2 all you need to do is upgrade to a web server that speaks h2, or use a Content Delivery Network (CDN) that will front your website and speak it for you. Though true, it is glossing over a host of subtleties that may not be obvious and could result in unexpected higher costs or suboptimal performance. Here are a handful of the items you should consider before turning HTTP/2 on for your website:

• Browser support for h2

• Potential move to serving over TLS (HTTPS)

• Tuning your website for h2 (possibly untuning for h1)

• Third parties on your site

• Retaining support for old clients

This chapter explains what you need to know about each of these topics.

Browser Support

As of publishing time, around 80% of web browsers in use support h2 to some degree.¹ This means a significant portion of people will start reaping the benefits of h2 as soon as it is turned on. Since the protocol negotiation is transparent to non-h2 supporting browsers, anyone who does not speak h2 will simply fall back to h1 and still access your infrastructure. (You did keep h1 support for now, right?)

Table 4-1 lists browsers and the latest version supporting HTTP/2.

Table 4-1. HTTP/2 browser support

Name	Since version	Notes
Chrome	41
Firefox	36
Edge	12
Safari	9	OSX 10.11 and later
Internet Explorer	11	Windows 10 only
Opera	28
Safari - iOS	9.2
Android Browser	51
Chrome - Android	51

Moving to TLS

Since all major browsers will only access h2 over TLS (i.e., an HTTPS request), that means you need to support TLS or you do not get to play. On top of that the TLS bar has been set quite high: you need to support at least TLS 1.2 with a specific set of ephemeral ciphers (see section 9.2 of RFC 7540 for details). Most modern security-conscious websites are already on the “TLS everywhere” bandwagon so it might just be a no-op for you, but if not, then there is an investment in time and resources to be made.

Note

This section is not intended to be a primer on securing your website with TLS. Whole books have been written on the subject. Managing your site’s security is a tricky business with many traps for the unwary. Spend time to learn the tools your site depends on. For an excellent primer on TLS and certificates, check out Ilya Grigorik’s book High Performance Browser Networking.

Much has been done over the past five years or so to make moving to and using TLS on your website as painless as possible, but it is still additional work. Items to consider are:

Understand your web server

Every web server has a slightly different way to configure its HTTPS settings.

Obtain a certificate

EV, OV, DV, CN, CSR, X509, SAN—there’s a whole new alphabet soup of acronyms to wade through. Getting a certificate for your site generally involves a number of steps, including the creation of a Certificate Signing Request, verifying your identity and the ownership of the names the certificate is for, and purchasing the certificate from a Certificate Authority (CA). There are many CAs to choose from. Organizations such as Let’s Encrypt² are working to make it simple, fast, and even free to get a certificate.

Protect your private key

Your certificate is only as secure as you make it. To safely run a site over TLS, you need to consider how and where your private keys are stored and who has access to them. Solutions range from using very expensive Hardware Security Modules (HSMs) through finger crossing and good practices. If TLS is new to you, this will be an important aspect of your operational plan.

Prepare for increased server load

There has been a lot of effort to make TLS as inexpensive as possible, but it is a game of three steps forward and two back. Optimizations in symmetric ciphers have helped enormously, but moving to ephemeral key exchange has done the opposite (though it has made everything a lot more secure). Here are some best practices to get you started:

• Keep connections open as long as possible. The most expensive part of TLS is the handshake at connection time. If you keep the connection open for as long as possible, you will reduce the number of handshakes needed.

• Use session tickets. Session tickets allow a client to reconnect to the server, reusing the computationally expensive crypto work done in a previous handshake.

• Use a chipset with built-in crypto support. Intel’s AES-NI³ instructions in its modern processors make very quick work of symmetric cryptography.

Keep up with changes

Web security is a dynamic world. There is a new vulnerability in servers and HTTPS seemingly every couple of months. It is important to keep up with the “latest and greatest” to ensure your work of yesterday is not useless tomorrow.

Regularly check your site

You should use tools such as Qualys Lab’s SSL Test⁴ to check your site’s TLS configuration.

These best practices are good things to internalize for anyone standing up a service dependent on TLS, but TLS is a rich subject that requires a significant investment in time to fully appreciate. Remember:

A little learning is a dangerous thing; Drink deep, or taste not the Pierian spring.

Alexander Pope

Is TLS Required?

The short answer is no. The useful answer is yes. Though HTTP/2 does not require TLS by specification, and in fact provides the ability to negotiate the protocol in the clear, no major browsers support h2 without TLS. There are two rationales behind this.

The wholly practical reason is that previous experiments with WebSocket and SPDY showed that using the Upgrade header and going over port 80 (the in the clear HTTP port) resulted in a very high error rate caused by things such as interrupting proxies. Putting the requests over TLS on port 443 (the HTTPS port) resulted in a significantly lower error rate and a cleaner protocol negotiation. The second reason stems from a growing belief that everything should be encrypted for the safety and privacy of all. HTTP/2 was seen as an opportunity to promote encrypted communications across the web going forward.

Undoing HTTP 1.1 “Optimizations”

Web developers have put a lot of effort into getting the most out of h1. Best practices have emerged such as concatenation, sharding, minification, cookieless domains, and spriting, to name a few. So you may be surprised to learn that some of these patterns become anti-patterns under h2. For example, concatenation (taking many CSS or JavaScript files and melding them into one) can potentially save a browser from making a bunch of requests. This was important with h1 where requests were expensive, but under h2 they are much more optimized. Skipping concatenation might mean very little request overhead and better fine-grained browser caching of the individual files.

Table 4-2 lists some common tricks used to optimize h1 requests, and notes considerations for h2.

Table 4-2. HTTP/1 optimizations, and related suggestions for HTTP/2

Name	Description	Notes
Concatenation	Combining multiple files ( JavaScript, CSS ) into one to reduce HTTP requests	This is less needed in HTTP/2 since the request overhead in bytes and time is much less, though not zero.
Minification	Taking unnecessary bytes out of files such as HTML, JavaScript, and CSS	A great thing to keep doing with HTTP/2.
Sharding	Spreading objects across multiple domains to get browsers to use more sockets	HTTP/2 is designed to use a single socket and using sharding would break that goal. Undo sharding, but see the note that follows this table, which explores the grayness of this topic.
Cookieless Domains	Having domains for things such as images use no cookies to minimize request sizes	Separate domains for objects should be avoided (see sharding), but more importantly, because of header compression in HTTP/2, the overhead of a cookie is significantly reduced.
Spriting	Making image maps of multiple images and using CSS to slice and dice them on a web page	This is similar to minification with the added aspect that the CSS work can get quite expensive. Deprecate this when using HTTP/2.

To Shard or Not to Shard?

HTTP/2 was designed to work optimally over a single TCP/IP socket. The idea is that getting one socket up and running at an optimal congestion rate was more reliable and performant than getting multiple sockets tuned in. However, research by Akamai’s Foundry team indicates that this strategy is not a slam dunk.⁵ Depending on the makeup of the site, we may still be in a world where multiple sockets will win over a single socket. This has everything to do with how TCP congestion control works and how long it takes to dial in the optimal settings. Starting with a significantly higher initial congestion window would help mitigate this problem, but larger windows can come with their own problems on networks that cannot support them. This is just one example that shows we as an industry are learning in real time about how to best use and optimize h2. When it comes to your site: develop, test, tweak, and repeat in order to find the optimal setup.

Assuming you take the time to fully optimize your site for h2, a problem immediately surfaces: you still have 25% of your traffic coming from h1 clients and you want to maximize their performance as well. Making everyone happy is an onerous task. Careful analysis of your users might tell you which group you should optimize for. Alternatively, you can conditionally serve different content for your h1 and h2 users, or use a CDN or similar tool that can do the magic for you.⁶

Third Parties

We love them and hate them, but third-party content on our sites is a reality. The problem with third-party content is you do not directly control it and are therefore at the mercy of what those third parties do and do not support. If h2 works best when everything is on a single socket, where do third parties come in? Being realistic, they do not, and they can become a major drag on any potential performance gain you might see from HTTP/2. The headache becomes even bigger if the third parties you use do not have a TLS option. Research⁷ into the effect of third-party content on page performance has determined that, in many cases, it is one of the largest factors in a page’s performance.

So what to do about third-party content? Start by finding out the answers to the following questions:

• Does your third party have a TLS option?

• Do they have plans to support HTTP/2?

• Do they see minimizing performance impact as a critical element of what they provide?

If the answer to any of these questions is “no,” then there are two follow-up questions: “Are there other third parties that provide what I need?” and “Do I really need this third-party content, or could I live without?”

Supporting Older Clients

Some people do not like change. Their current browser works for them, and upgrading can be a nuisance. The problem is that these people may be your customers or users and you may not be ready to abandon them. Here is a real example. Microsoft ended support of Windows XP on April 8, 2014. This means that users on XP are falling farther and farther behind in terms of modern browsers and security. Needless to say, Internet Explorer on XP cannot talk h2, but more importantly, depending on how your TLS settings are configured and whether you have a clear-text fallback site, those users might not be able to even access your site over h1! On one hand this is the inevitability of progress, but on the other hand these could be important users and customers for you. This reality is yet one more item to consider before making the move to HTTP/2.

Summary

Though a transition to HTTP/2 is generally seen as a good thing and should be completely transparent to your website, there are certainly considerations that you need to take into account before flipping the switch. Even though many major websites have been running h2 for some time now, that does not mean it is a guaranteed win for your situation. It should be treated the same as any other significant change: test, test, test.

¹ http://caniuse.com/#search=http2

² https://letsencrypt.org

³ http://intel.ly/2onh9E4

⁴ https://www.ssllabs.com/

⁵ http://akamai.me/2oEPSOZ

⁶ http://akamai.me/2onjVcz

⁷ http://akamai.me/2oEI9k9