HTTP/2: Leveraging the modern web

What’s the story behind HTTP/2, and what do you need to understand about the protocol before you adopt it at your organization? This episode of the O’Reilly Podcast features my discussion with Stephen Ludin, Chief Architect at Akamai and co-author of the upcoming book Learning HTTP/2. In this conversation we talk about the limitations of HTTP/1.1, the benefits of HTTP/2, and how you can start using the protocol at your organization.

What are the limitations of HTTP/1.1, and what led people to want to revise the protocol?

When HTTP/1 first came about, the web was really about delivering textual content, perhaps with an image. People were fond of blink tags at the time, and it was a platform for simple communication.

Then the web caught fire, caught the imagination of the world, and the web as you know it was born. The web pages of today are nothing like the web pages of the early days. Now each page has, on average, 150 objects. It’s about two megabytes of data. You’re connecting to 50 different endpoints. This is all stuff that was not conceived when HTTP/1.1 was developed.

The limitations of 1.1 stem from the fact that it wasn’t built with the modern web in mind. It was built for the web of the day. It was creaking under its own weight, and people were going through many hoops and workarounds to try to get it to perform the way they wanted. In fact, one could argue that the entire Velocity movement around performance was based on people sharing these workarounds and best practices to try to get the most they could out of HTTP/1.1.

The goal of HTTP/2 was to try to address some of those shortcomings and develop a protocol that would address the web of today, and hopefully account for how it will grow tomorrow.

How else has the internet changed?

Physical changes: When HTTP/1.1 came out, a 24K baud modem was pretty nifty and fast. People’s ability to consume content has increased by several orders of magnitude.

Content changes: The size of the objects themselves are larger. When I say “objects,” I mean the elements on a page: the web page itself, the size of the web pages, streaming video. All these elements have conspired to make life difficult for good old HTTP/1.1. It’s time for something to come in and help it along.

What do practitioners need to know about HTTP/2 to really take advantage of it?

It depends on where you are on the stack. Let’s assume you are a DevOps web developer, working on delivering content. The really short and unhelpful answer is, “Absolutely nothing.” You’ll need to upgrade your web infrastructure to be able to speak HTTP/2, and all the major web servers of today that I can think of already support it in one way or another. Then it should just work.

Now, the longer and more helpful answer involves optimizing your content for HTTP/2. This is a significantly more complicated and fun answer. There are some things—patterns that we use with HTTP/1.1 for optimizations—that become anti-patterns in a world of HTTP/2.

For example, for HTTP/1.1, to get around limitations of socket management and number of sockets a browser will open, we shard, spreading our content across four or six different domains to maximize throughput. In HTTP/2, on the other hand, we’re trying to optimize for one socket. Going across many sockets is not necessarily a faster way to get the data. So, if you sharded for HTTP/1.1, you might want to look at un-sharding. Maybe you don’t need to come down from four to one, but coming down to two might get you a better experience.

Another thing to look at is your third-party content. If you’re looking for an increase in speed, one of the big offenders for web content performance is third parties. Are your third parties holding you back? Will they allow you to move to HTTP/2? Will they support HTTP/2? These are all questions to ask, and the answers may change your HTTP/2 conversion from a simple “flip the switch” to “okay, this is going to be a little bit of a migration to do it well.”

Are there a lot of companies already using HTTP/2 to great effect?

Some of the big ones you’ll find are Facebook, Twitter, Google—all these are using HTTP/2. Akamai, the company I work for, has had HTTP/2 out for quite some time now, and we seem to be training our customers on it daily. Last time we checked, around 14% or 15% of our current encrypted traffic is over HTTP/2, which is a pretty big number.

Are there potential downsides of HTTP/2 that people should be aware of?

One of the downsides of HTTP/2 is that no one ever talks about the downsides. All you ever hear about are all the upsides, how it’s going to improve your performance by X percent, and everyone will be happy and go home early.

The reality is, how much performance increase you’re going to see is very situational. In the research that my team has done, we see a 10% to 15% median increase in performance for most sites that we put under HTTP/2 and then test. Some sites see no performance increase. Some of them see performance increases on some parts of the site, and no improvement on other parts of the site. This is all impacted by how much content you have on that page, how it’s distributed, and how much of it is going to benefit from HTTP/2.

There are some cases that see a decrease in performance with HTTP/2, though that tends to be relatively rare, and tends to involve protocol implementation problems that are getting worked out in real time with servers and browsers as we speak.

What are some best practices for HTTP/2 that have emerged?

The short answer is that the technology is still too new. Really, the best practices are all baked into the protocol. I guarantee in 10 years there’s going to be a version two of one of Steve Souders’ books on best practices that will be all about the workarounds for HTTP/2.

Something to keep in mind is how browsers are approaching connection management today. Chrome and Firefox will go ahead and reuse a connection if they notice that a host name they’re going to connect to is actually valid on a cert they already have a connection with. What that means is, if you have multiple domains and they all use the same certificate, the browser will coalesce those onto a single socket using HTTP/2. That can be a great benefit when it comes to maintaining throughput and avoiding connection overhead.

That’s one best practice. Other than that, this page remains blank. We will be writing it as we move forward.

What are some quick tips for organizations that are just beginning the journey toward adopting HTTP/2?

Look at what web infrastructure you have today. Odds are, there’s an upgrade already available to just go ahead and turn on HTTP/2. Try it on a segment of your traffic and see how it works. Get some A/B testing going.

Really, if you have properties that you can easily flip onto HTTP/2, go ahead. It’s not going to blow up. You’ll probably learn a lot.

---

This post is part of a collaboration between Akamai and O’Reilly. See our statement of editorial independence.