O'Reilly logo

Learning HTTP/2 by Javier Garza, Stephen Ludin

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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.1 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 Encrypt2 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-NI3 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 Test4 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

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.

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.6

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. Research7 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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required