Interview: HTTP 2 explained by Google’s Surma

We had the chance to meet and interview a lot of very interesting Googler’s during the last Google I/O. Today it was Surma ! We’ll release those interviews (mostly in English) in the upcoming days.

Wassim Chegham: Hello, can you introduce yourself?

Surma: My name is Surma, I work for Google in London, I work on the Chrome team, in developer relations, so basically my job is to reach out to developers, tell them when we get new things, and they tell me what we are doing wrong, so we can change either Chrome or the Web or our strategy, these kinds of things.

So do you get feedback about HTTP 2?

Yes! Actually I’m one of the main people in DevRel to work on HTTP 2 and public messaging about HTTP 2.

Awesome! Can you explain to us what is HTTP2?

HTTP 2 is, as the name kind of suggest, the successor of HTTP 1. HTTP 1, at least in version 1.1, is what the entire Web current release is built upon. So it is a protocol but it’s actually very old. The first version was released around 1994 — I might not be 100% correct. But we reached HTTP 1.1 in 1996 or 1997 and it hasn’t changed ever since. So it’s really old. It was originally designed for scientific papers, so you could write documents and the big thing about this was Hypertext. That’s why it’s called HTTP (HyperText Transfer Protocol). Because these documents could have hyperlinks that link to other documents which in science — in papers — is really awesome because usually you have sources, you can just click on them and you get to the source. However, in the meantime, we have moved further along. We are not doing documents anymore, we are doing web apps. So apart from being a document, with maybe one or two images, we have assets and I mean a lot of assets! I think on average right now, a website needs to make a hundred requests until it can finally show up on screen. That’s a lot! And especially, this is something HTTP 1 was not designed for. So, in the past we have kind of made it work with workarounds, like the whole thing of concatenating JavaScript into one file, reduce the number of requests, etc. To be fair, we are working around an issue. And that’s why people sat down, among other things Chrome engineers sat down, and came up with solutions and SPDY was made. That was an experiment by Google. And on the base of SPDY, HTTP 2 was specified. And has been evolved in specs. It is done now. And it solves a lot of problems. And make a developer’s life much more convenient.

Surma, would you say it’s a game changer?

For developers, yes, for users, it is basically unnoticeable. Everything works the same but there are a few things to know: it is always encrypted. Technically there is an unencrypted version of HTTP 2 but no browser supports it. It is a very conscious decision because we want everyone to use TLS. Things load faster even websites that have not been optimized for HTTP 2. Even those have a big performance benefits.
So for the user, actually nothing changes. And also, it’s backwards compatible so everything works the same as before.

So, it is a stable API?

It is stable, the spec is finalized. All the evergreen browsers support it. So this means 88% of the web traffic would be HTTP 2 capable. People should start moving over to it as soon as possible.

You can start using HTTP2 right now?

You can and you should.

Speaking about developers, how would developers migrate from HTTP 1 to HTTP 2?

There are multiple approaches you can take here. There is the very easy “I just want to have it” approach which would be using something like Cloudflare. You put it in front of your server and they basically translate your old HTTP 1 into the new HTTP 2. That is actually already pretty good because you can reap almost all the benefits with this version already. One of the biggest drawbacks of HTTP 1 is you can have at most 6 open connections but this is something the browser enforces and CloudFlare can have much more. So it will basically open us as many connections as it needs, get all the documents, caching them for you as well because they are a CDN, right? And use it with the new HTTP 2 way which is a single connection and works way more efficiently…

But if you don’t use CloudFlare?

If you don’t use CloudFlare, it depends on what stack you’re using. If you’re using Apache or NginX, you got it, they support HTTP 2 now. Update to the new version, adjust your configuration. I wrote a blog post about this. If you’re using something without a front-end… what is it called… the load balancer…


HAProxy! Thank you. I don’t think they have support just yet. Sometimes, you have this single app which is just using the HTTP server of the language. I think Node has bindings, Go has bindings or has an HTTP 2 server, so does Node…


Java… has one actually — that is also on my blog post [laughs]. Some languages are still very much in development. They don’t expose all the features, some new features in HTTP 2 that HTTP 1 didn’t have. But to be fair, I’ll ignore them for now.

Speaking about features, what is the killer one for you?

The killer feature is that you don’t need to do anything to use this feature, which is the removal of Head-of-line blocking (HOL). Originally, HTTP 1 had six connections and the only reason we had only six connections is because when we send a request on a connection, that connection becomes useless until the response arrives. So that’s why they had six connections, so they can do something in the meantime. In HTTP 2 we do something different. Because we do multiplexing, we can use the connection at full bandwidth the entire time, even if one request is in the middle of being sent back and forth. That has a huge impact on how we structure and develop web apps because that mean HOL is gone, requests are cheap and we don’t need to do the whole concatenation and bundling any more. Before, for example we had like 80 JavaScript files and that gets concatenated into a single JavaScript file: that means, if you ever change one of these 80 files, the big blob would have to be redownloaded by the user, because the cache was invalidated. Now, with HTTP 2, you only need to download that single file that has changed, which is smaller, and all the other caches stay intact. It makes web apps that do lots of roll-outs much cheaper. That, for me, is the biggest feature. Because we do these weird things like concatenation, and spriting, etc. Don’t do it anymore! It’s for free, and it makes things much easier. It simplifies the build pipeline specially.

Do you have something to add about HTTP 2?

The biggest part is, if you’re trying to convince people to use HTTP 2, the CloudFlare way would be the way where almost no effort is involved. It will still make your app better and you don’t have to worry about excluding users because it’s backward compatible, if you don’t support it, it will still work just as before. So, there is no downside really. The only thing where we might have to measure a bit is when you say you stop making all concatenation, because requests are cheap, but they are not free. So make benchmarks before and after, but I guarantee you, 99% the time, you’re gonna do better than before without any effort…

So, you don’t have to do anything on the client…

Nothing. Your web app logic doesn’t care. The semantics stays the same. The request method: GET, POST, UPDATE, etc. You have headers, you have the body. Everything stays the same. Just the way it goes over the wire has changed.

Thank you Surma!

Thanks guys!


Note: Surma also gave a very good talk about Houdini at Google I/O, you can watch it here :

Vous aimerez aussi...