The Changelog: Software Development, Open Source - The HTTP/2 Spec (Interview)

Episode Date: June 19, 2015

Ilya Grigorik is back again — this time we're talking about his true passion, internet plumbing, web performance, and the HTTP/2 spec. We cover everything around HTTP/2, the spec, HTTP/1 history, SPDY, binary framing layer, the semantics of HTTP/2, pipelining, multiplexing, header compression (HPACK), server push, TLS, "time to glass", upgrading, adoption, support, and more.

welcome back everyone this is the change log and i'm your host adams d'acovia this is episode 161 and on today's show we got ilia gregor joining us today he's an internet plumber as he said before working at google working on the HTTP2 spec. The precursor to this was known as Speedy. So if you've played with Speedy whatsoever, you know what H2 is all about or what it's proposed to be about. The spec is finalized. We talked deeply about it. This whole conversation is the definitive conversation around H2 and what it's all about. Binary framing layer, pipelining, multiplexing, header compression,

also known as HPAC, server push, TLS, time to glass, upgrading, support, adoption, you name it, we covered it. This is the definitive conversation around the H2 spec. We have three awesome sponsors, CodeShip, CodeSchool, and also DreamHost. Our first sponsor is CodeShip. They're a hosted continuous delivery service focusing on speed, security, and customizability. You can set up CodeShip in your app in a matter of seconds

and automatically deploy your code when your tests have passed. CodeShip supports your GitHub and your Bitbucket projects, so no worries there. And you can get started today with our free plan or you can go with a premium plan and stay at 20% off using our code. It'll save you 20% off any plan you choose for three months. Use the code THECHANGELOGEPODCAST. Head to CodeShip.com slash TheChangeLog to get started. 20% off any plane you choose for three months. Use the code THECHANGELOGEPODCAST.

Head to codeship.com slash thechangelog to get started. And now on to the show. All right, Jared, we're back. We got Ilya, the internet plumber himself, on here. Third time on this show. What do you think, Jared? I think three times puts him into an elite group of people. That's right. Sm time on this show. What do you think, Jared? I think three times puts him into an elite group of people. That's right. Smoking jacket and all.

Yes. Previously on Episode 55, Episode 144, back in February, we talked about GitHub Archive, Ilya, we talked about Nightly, which was his turn into ChangeLog Nightly. Pretty fun stuff. Everybody's enjoying that Nightly email that we've been shipping out, but welcome back into ChangeLog Nightly. Pretty fun stuff. Everybody's

enjoying that Nightly email that we've been shipping out. Welcome back to the show, Ilya. Thanks. Thanks for inviting me back. It's always fun chatting with you guys. Today's show is all about HTTP2, which will be a tongue twister for me. I don't know about you, Ilya, but do you get tired

of saying HTTP2? 1? Whatever? Get tongue-tied? I think every other sentence you, Ilya, but do you get tired of saying HTTP 2, 1, whatever? Get tongue-tied? I think every other sentence I say contains HTTP, so I don't notice it anymore. Have you found a way to say it faster or more, I don't know, that people can actually understand it other than geeks? Well, if you're talking to geeks, you can actually say just H2, which is a valid name for the ALPN upgrade token, which we'll talk about at some point.

H2, I like that. That is a lot easier to say. H2 is a lot easier, better than HTTP2. Even when I'm trying to say it just well, I still stumble over it. But anyways, so, you know, welcome back. Do you want to give another introduction for those who may not know who you are? I know you were on 55 and 144. We talked heavily about who you are and you described yourself as an internet plumber at Google. So anything else you want to add to that?

No, I think that's pretty much it. So I work on the developer relations team at Google. In particular, I focus on web performance. I work very closely with the Chrome team. And as of late, I've been doing lots of work in the web performance working group. So trying to define and improve existing APIs in a browser to allow developers to build better applications. And H2 is not related to the web proof group. It's part of the IETF effort.

But it's definitely something that was a big effort within Chrome. We'll talk about Speedy, of course, and something that I've been very passionate about. And I guess since this show is all about H2, since you've cracked that nut, we can say that, which saves me some stumbling. But if we're going to talk about H2, then we've got to go back and talk about H1 and talk about the history of this spec that we've been living in. And since you've been hanging out in that area, what's the best way to talk about the basics of what the original spec was and how it turned into Speedy and how it turned eventually into H2?

Sure. So I'll try to keep it brief. But as you said, it's good to kind of rewind the time clock and understand how we got to where we are today right and of course everything starts with uh htp 0.9 which is tim berners-lee basically creates this very simple protocol it's literally one line that says get you give it the name of the resource you hit enter and you get back a resource all right so this is about uh, 94. And the idea was, I just want to retrieve a text document, because that's what it's supposed to be, HTTP, right? Hypertext Transfer Protocol. Then after that, this web thing became kind of popular.

And people figured that, hey, we would like to actually fetch other things as well. So somebody had this crazy idea of putting images into a document and other people started inventing other mechanisms to style things like style sheets. And then of course, later we got JavaScript and we started kind of building up these use cases. And we also realized that it's nice to be able to say like cache a resource instead of having to fetch it all the time. So all of these use cases were emerging from the community. There wasn't an official effort around it, like a working group or an ITF effort. Now, this was basically just people picking up HTTP and just building servers and

just saying like, hey, I dreamt up with this cool feature, caching. So here it is. And then other browser and server implementers would just kind of pick and choose and say, like, okay, I like this feature and whatnot. And the way we arrived at HTTP 1.0, which was in 1997, it wasn't actually an official standard in the sense that somebody sat down and wrote everything from beginning to end. Rather, it was a document that tried to capture the existing best practices. So in the period of like four years, starting from when HTTP first came out, when Tim Berners-Lee first introduced it, to four years later,

there was just a lot of emergent behavior. And in HTTP 1.0, we tried to just document it. And that's all it was. There wasn't even a large attempt to rationalize it all. It was just like, here are the best practices that you'll find on a common web service today. So that's 0.9. Is that going into 1.0 and everything? Right. So that's what became 1.0, effectively.

1.0 was an attempt to capture best practices and the common usage patterns on the web. And then once we did that with 1.0, there was a second effort which was 1.1, which took another about two years or so to actually go back and start cleaning up the spec.

So to introduce common language, common terms into the spec, such that it becomes kind of rational and more easier to implement for new servers and user agents. And effectively, when HP 1.1 came out, which is in 1999, that's the HTTP protocol that we've built the web on. So there was that initial burst of creativity. We captured it. We kind of cleaned it up.

And then we just kind of left it there. And as you are well aware, if you think about if you've been online in 1999 and then you've visited the web recently, the web is very different, right? So we have not just pages, they're full-out applications, we have video, we have all kinds of interesting things happening on the web. And during this time, the web was evolving, but the HTTP protocol basically stayed where it was. And in around 2007 or 2008, the Chrome team, when we're working on Chrome, realized that as we were building the browser, that the protocol had a number of deficiencies, which didn't allow us to build and present the pages as quickly as we wanted to the user. So there was this new effort, kind of a bunch of studies that we started under the name of Speedy,

which was around experimenting with the protocol, the HTTP protocol, and trying to figure out what kind of changes we would have to make to the protocol to address some of the limitations. And specifically, one of the challenges with HTTP

has been the fact that it's a serialized request-response protocol in the sense that if I have a connection and I send a request and say, hey, I would like to get the index.html file, you have to wait until you get the full response back before you can reuse that connection to ask for a second thing,

which may not seem like a big problem, and it wasn't really a problem back in the 90s when all you were fetching is a document and maybe a couple of resources. But now an average page is fetching over 100 resources, which are things like images, JavaScript, CSS, and all the other stuff. And now that you have 100 resources, and you have to do this in serial, it becomes a bottleneck. So, you know, there's workarounds for that, of course, you just open more connections, but turns out that's also not great. Because if you open too many connections, it can actually hurt user experience, because now you run into troubles with congestion control and opening

unbounded number of connections may hurt the server that you're trying to talk to. So realistically, we have to cap that. And kind of through experimental deployments, we and other browsers determined that kind of arbitrarily six connections per origin is the optimal number. So what that means is with HTTP1, you can fetch up to six resources in parallel, which kind of worked in between 2000 and 2007. But in 2007, we realized that that's not sufficient.

This does not scale. Clearly, developers are putting more and more resources, they're building more ambitious applications, and to fix this issue, we need to rethink the protocol. And that was effectively the inception of Speedy. And Speedy tried to change some of the basics of how messages are exchanged within HCP

to address this thing. Does that make sense so far? Yeah, totally. So when you talk about the connections and limiting that, that's why we get things like, you know, sprites, for example, with images. That's why you have, you know, all of your website's images in one single file.

So you can just sort of sprite around and use CSS to move that as a background image. That's where you get practices like concatenating, you know, sevenarounds to get into this glorified six number where you guys have figured out that that's the best number to focus on. Yeah, exactly. And that's a really good point. So we call these things like concatenation as optimizations today. Like bundle all your JavaScript files into app.js or use an asset pipeline to create this thing on the fly for you. And really, it's exactly as you pointed out,

it's a workaround. It's a workaround for the fact that HTTP provides limited parallelism or lack of parallelism, if you want to call it that. So we've been forced down this path of doing things like spriting images and concatenating files, which actually has a lot

of negative side effects so for example say you take say you have you know you've developed a beautiful application which is modular and has everything all the logic is split into different files and you like you it's just a well-engineered software project right and now you want to ship it to the client so they can execute it. Well, today, in order to do that, the best practice, in air quotes there, is that you put all those files

into one giant application.js and you ship it to the user. Now, moments later, you realize that, hey, I made a mistake or maybe I need to update something. So you change a single character or a single byte in that one file. And now the user has to re-download the entire file.

So you change one byte, and you have to download the whole thing all over again, which of course is expensive data-wise. It also slows down your application, because now you have to download this giant thing when you only changed one little part of it, and this is just not a good user experience. So these best practices or these optimizations like concatenation

actually prevent us from deploying effective caching strategies. And the reason we were willing to put up with that in the past is precisely because the latency trade-off of this constraint of lack of parallelism was so bad that we just kind of brushed the caching concerns under the rug and said, that's okay, we'll just re-download it all over again. And so all this led into what was kicked off by Google, trademarked by Google even, SPDY. It's not an acronym, but it looks like it might be. And were you a part of the team when this kicked off originally?

Like you were the founder of this project, or what part did you originally play when SPDY came out? No, I actually came in after the project got started. So I think it's actually interesting to talk about why it started in the first place. And it all came down to this one experiment, which was done by a couple of engineers on the Chrome team. And what they tried to do was they took,

I think, the top 100 websites, and they tried to simulate what would happen in terms of the loading performance of those websites if we varied bandwidth and latency independently so say you have a one megabit connection and then you load all the pages and you just measure the how long it took to load each page and then you double that to two megabits and you measure that again and see if there was a difference right like intuitively you would expect or you would hope rather that going from one to two would make things significantly faster because you can just download a lot more stuff more quickly so they kept increasing that bandwidth

and then separately they ran the same experiment for latency so if we just keep increasing or decreasing latency from let's say 100 milliseconds to 200 milliseconds what's the impact and the thing that they realized was that after about five megabits per second which is uh more than uh the average uh broadband connection speed in the united states so basically if you're on broadband in the united states or in most of the countries you already exceed that five megabits upgrading from five to say 10 megabits will only give you like a single percentage point improvement in the page loading speed. Wow. A lot of people are spending too much on their internet too, potentially to not get a faster web.

Not because they're watching Netflix. Right, well, that's a good point. So there is some type of traffic on the web that is bandwidth constrained. So these large streams like video are definitely bandwidth constrained. So if you want to watch HD video, yeah, please go ahead and get yourself a,

you know, a hundred megabit connection. But upgrading from, let's say a five megabit to a hundred megabit connection does not, or will not significantly improve your browsing experience, which is kind of sad, right? If you think about it. That makes sense. Yeah. Cause you don't see, you know, ISPs marketing their, you know, their round trip times or their latency. All they even use is bandwidth, so you can't just go buy better latency, right?

Well, yeah, and therein is the actual rub here, right? So repeating the same experiment with changing latency, they saw a linear performance improvement. As in, the lower the latency, there's a very direct correlation between lower latency and improving the performance. So if you actually... Rather, performance of loading websites or browsing the web. So if you really want to have a faster experience of browsing the web,

you should find a connection that has the lowest latency. But as you said, I'm not aware of a single ISP out there that is actually advertising this sort of thing in their marketing, right? Which is a whole other discussion that we should have at some point. Yeah, I mean, some of that, of course, out of their control, right?

There's a lot of factors that play into latency, and they're just one player in a game of what is effectively like a mesh network. Is that fair to say? Yeah, that's true. There are many hops between you and the server,

and the ISP is perhaps the first couple of hops. In practice, it turns out that ISPs, or the last mile as we call it, can contribute a significant amount of latency. So that's typically because the area is under-provisioned. So everybody starts watching Netflix, and all of a sudden there's not enough capacity, and latency suffers, and all these things happen.

So there's definitely a lot that carriers can do to improve this sort of thing, but that's probably a whole separate discussion. So the outcome of this whole experiment was basically the realization that the web is not going to get faster unless we either decrease latency, which we can't as an outsider, or we re-examine our protocols and figure out what is it that prevents us from utilizing the bandwidth in a better way. And one way to improve latency is to pipeline requests, right? So instead of serializing every request one after the other,

what if we were able to just say, well, I need these 50 resources, so let me just send you all 50 requests at the same time. HSP does not allow us to do this, but what if it could? And that was effectively the premise for SPDY. What do we need to do to change the protocol

to allow that sort of thing? And further, if we're going down this path, we also know that as the web has evolved and we've put more and more different kinds of resources, these resources have different priorities. So for example, if I send you 50 resources, the HTML file is very, very important to me. And the image file is important important but not as important as html so it'd be kind of nice if i could communicate that to the server and say here's 50 resources but i would i could really use your help on getting the html file first because that allows me to display something to the user so uh hcp also or the hcp1 rather does not allow you to do that hcp2 does and then there's other use cases like dependencies.

Let's say you are trying to stream a video file. It'd be kind of silly for the server to send you a frame, a subsequent frame, before it was able to send you the first frame ahead of it. It's like, I don't want the second frame before I can get the first one. So there's some notion in there of saying, here's two requests, but please deliver the other request or the response after you've sent me the first one. So there's some notion in there of saying like, here's two requests, but please deliver the other request or the response after you've sent me the first one. And kind of between

all of this, that was the foundation of Speedy. And that started in around 2008. We ran some experiments, we saw some significant improvements in terms of the actual performance. So at first, we were actually able to deploy it or implement the first version in Chrome. And we also implemented the server portion on some Google servers. And we ran an experiment where we opted in some users into using Speedy. And there were significant performance improvements for those users that we saw that were using Speedy. And this was mainly on document-based sites, not so much video-based sites or these non-web-based

sites, like non-document sites? No, no, no. It wasn't that specific. We saw improvements across the board just because we were able to remove these bottlenecks. But it is true that the biggest benefits were typically for sites that had a lot of requests because now we were able to pipeline and eliminate these unnecessary latencies, like queuing latencies and headline blocking. We're definitely getting into HTTP2 landscape here um is there anything else on speedy we

should cover in terms of like you know as the precursor it's it was the originating experiment to get to what is now the h2 spec so is there anything else we need to cover on speedy to sort of migrate into talking deeply about h2? I think we covered the main points. I guess I'll just say that Speedy was meant as an experiment. And with time, because we did see good improvements in performance,

it was actually becoming well-adopted outside of Google. So we had Firefox that enabled Speedy as well in their browser. Safari announced that they will support it. I think it was from Safari 9. IE also added support for SPDY.

So in effect, it was becoming a de facto protocol. And similarly, server support was emerging. So there was Apache, Nginx, and other servers that were all supporting it. And kind of on the basis of that, the HTTP working group said, well, look, clearly there's something here. So let's start an effort to modernize HTTP. And they did a call for proposals. Google and others submitted their proposals. Google submitted the SPDY protocol. And after a couple of rounds of discussions and feedback, the SPDedy spec was adopted as a basis or a starting point for the HTTP2 protocol.

And then from that point forward, as HTTP2 development proceeded, Speedy was also being developed, but it was effectively kind of like an experimental branch where we were able to prototype new ideas, kind of test them, see if they pan out. And then that feedback would get merged into HTTP2. So that's kind of test them, see if they pan out, and then that feedback would get merged into HTTP2. So that's kind of the history. So HTTP2 development started in around, I think it was 2011. Before we get into that, I do have kind of a big picture question around the idea of replacing the current application layer protocol HTTP with something better. Um, the goal being to make the web faster, reduce latency, you know, network computers,

you know, have lots of different technologies at play. Um, the network stack for, for those who aren't quite familiar with the network inside has many layers, uh, Depending on how you look at it, there's seven or five. And regardless of the way you look at it, HTTP is that top layer. That's the application layer where developers kind of play and it integrates with your apps and whatnot. Below that, there's the session layer where you have your encrypted connections. There's transport layer this is where you know tcp and udp are often used and then you have your ip layer which we're most familiar with ip addresses and whatnot was there efforts to swap out lower down to say well maybe tcp is not the best way to deliver the web and um was there research that went into that were there efforts that are trying to do that or have tried to do that um so funny that you ask yes uh even at the very beginning

back in kind of 2007 uh we knew that we would probably need to solve problems at multiple layers but at the same time it didn't make sense to try to tackle everything at once right i think that would have been just too much to bite off yeah so initially the focus was on htp so what can we do to solve that and then once we unblock those issues we will immediately run into the performance issues at the layer below and that in particular here this would be the question about tcp like we've solved issues at the application layer of HTTP, we removed head-of-line blocking, but it turns out that TCP also has its own failure modes

with head-of-line blocking. And now there's actually a different effort within Chrome called QUIC, which is effectively, think of it as HTTP2 over UDP. There's some other things, but it's an experiment that we're working on now, which is using UDP to mitigate some of these issues that we're running into within TCP. But that's probably a whole other episode on this one.

So long story short, there are some ancillary efforts that aren't just sitting at the application layer, they're going further down like the TCP layer, the transport layer, as Jared mentioned, that's kind of hanging out there, or the UDP layer. That's right, yeah. And TCP continues to improve, right? So there's lots of work happening in all parts of the stock.

I also think that it seems like the further down you go, the more tightly integrated into the operating systems that you are. And so, perhaps more difficult, even as a wide, you go, the more tightly integrated into the operating systems that you are. And so perhaps more difficult even as a wide, you know, as far as adoption goes, as a rollout, you know, we see how IPv6,

you know, still not out there in droves. Over years and years of it being, you know, pretty much done, I guess, or available. So perhaps starting at the top and working your way down is even the most effective way to do it, so that makes some sense. We're getting into the transition between Speedy and H2.

You covered a little bit of how Speedy was being adopted. Can you maybe reiterate or at least tell us why the need to move away from Speedy as a thing and do the H2 thing instead? Sure. So the intent here was to standardize on a protocol. So to bring in... We came up with some ideas within Speedy

for how to address the particular issues that we thought were important to move the web forward in terms of performance. Then you take that to ITF, and there's just a lot more people around the table with different kinds of experiences, different perspectives on what is important, and that was the intent

behind taking it to ITF, and that's the intent of ITF. And that's where HTTP2 was developed. So over the period of about two years, there was 14 drafts, 14 kind of big milestones along the way that we went through. And now, actually, back in May, so about a month ago now, these specs have been officially published.

So there's actually two specs. One is the HTTP2 specification, and another one is the HPAC, or the header compression specification, which we actually haven't talked about this yet, but we can in a little bit. And I guess one thing I'll mention here is you kind of hinted at this a little bit earlier.

Modifying something as big as HTTP is a big task. And I think this is why, to some degree, it took us so long to get to this point because there's so much built on HTTP that any thought of trying to modify it would be just a huge undertaking. So one interesting point to keep in mind with HTTP2

is that HTTP2 does not actually modify any of the semantics of the HTTP protocol. So the headers, the header names, the methods, kind of all your RESTful stuff, all of that is exactly the same. And that is intentional. So in fact, some people criticize HTTP2 for not tackling some of the higher level issues that they think should be addressed in HTTP2. But that was explicitly out of scope when we chartered the whole HTTP2 effort, because we knew that there's so much that we could do. But we wanted to focus

on kind of this lowlevel performance and framing. So any application that you have today that runs over HTTP, you can put that over HTTP2 and everything will work as is because nothing has changed semantically. And I think this is very, very important. Whether we should modify some other things, like semantics HTTP, is now beyond that. And now that we've finished HTTP 2, we can now start that discussion. So it's backwards compatible in many ways, is what you're trying to say.

That's right. So you can deploy, you'll have to swap out the server, because it'll need to understand HTTP 2, but you don't have to modify your application. There's nothing about your application that will be HTTP 2 incompatible. That said, there are things that you can do within your application to There's nothing about your application that will be HTTP2 incompatible. Now, that said, there are things that you can do

within your application to make it perform better over HTTP2, but that's a very different discussion. This is the, coming back to your earlier point, like you were concatenating files. Well, perhaps you shouldn't do that now because it actually hurts performance. Yeah, we were just talking about that actually in the last show. We were talking about that, and it was sort of the discussion of things that have become,

in quotes, what we said earlier, which have become best practices around the HTTP1 spec that you're doing now to concatenate and all that stuff. And now that might not be a good thing since you have different things like pipelining or multiplexing that can support that better now. Right, exactly. The problem with that, I guess, and where it gets complicated, of course, I'm an application developer, so I'm always thinking about how does it complicate my workflows and stuff.

And that sounds great as far as HTTP2 actually simplifies my workflow because I don't need to do all that stuff anymore. But it's not like H1 is going anywhere anytime soon. So we're still going to have to support both for you know for years to come um let's do this let's get a high level overview because we haven't actually talked about what it brings to the table we know what it's trying to do which is improve performance reduce latency you know kind of be a more modern protocol for more modern web uh ilia why don't you give us kind of the big tentpole tentpole features of h2 and then we'll take a break and come back and we'll we'll dig deep in each one all right sure um so let's see where to start um so we talked about uh the

fact that everything in hcp1 is kind of has a serial request response model. And that was one of the main things that we wanted to address with HTTP 2. We know that in HTTP 1 world, we also had these six connections. And we don't want that either. So the first premise that HTTP 2 started with in speed as well is that we want to optimize and transfer everything over a single TCP connection. There shouldn't be a reason why we need multiple connections. Opening multiple connections to the same server doesn't actually give you anything in terms of throughput. You can transfer everything

over the same connection or six. Except that you will actually get better performance of the transport layer if you reuse the same connection. Because there's just a lot of mechanisms within, say, TCP and other protocols that are optimized for making the best use of available bandwidth. So one TCP connection is the start.

And then if you have one TCP connection, what do we need to do to actually be able to send and receive multiple requests and responses at once. So to do that, we added this notion of framing, where a message, so in HTTP world, a message is a collection of headers, which are just key value pairs, like get this and this header, that content length with the number and the actual payload. So a message can be split into many different frames. So for example, headers can be transferred independently of the body, and body itself can be split into many different frames so for example headers can be transferred independently of the body and body itself can be split into many different chunks which we kind of had before right with chunks encoding but you couldn't interleave multiple messages like you couldn't say here's a little bit of the body of the request or the response for this request that you sent and here is the other bit for another request.

You couldn't interleave those. And that's what binary framing provides. It introduces this notion of a stream ID. So in HTTP2 world, requests are, we refer to them as streams. So you open multiple streams to the server, and each one of those streams carries, say, HTTP headers and GET headers for all of your

requests. The server receives all of those streams. Each stream has an ID and it just starts generating responses. And in order to send data back, it just packages each chunk of data and appends that stream ID plus some other metadata and sends it back to the server. And now all of a sudden, because we can split these messages into smaller chunks, we can actually interleave them. So say you get two requests and one is for, I don't know, a CSS file and another one for an image. You start sending the CSS file because it's the most, it has a higher priority,

which is something that the client communicated to you. But then the server blocks, maybe your application is kind of slow. So then the server can say, okay, well, I'll pause that and I'll start sending you the image data. And then once the CSS data is available once again, it resumes that.

So now that this data can flow over the single connection, it can be prioritized. We no longer need multiple connections, right? Everything is just transferred within the same stream. So that's multiplexing and prioritization. Another thing that was added now that we have this notion of streams is flow control so if you're familiar with things like tcp flow control this is a similar thing but it allows you to express things like

i want to receive so here's a request here's a stream and i'm willing to receive, so here's a request, here's a stream, and I'm willing to receive up to X many bytes of the stream. And then I will tell you when to resume it. And this is kind of cool because that actually opens up new opportunities for the client and server to interact in ways which it couldn't before. For example, say images, right? Many, or not many, some image formats allow progressive rendering, where you can fetch a little bit of the file

and you can render a preview of the image. Well, before, we had to fetch basically the entire image and then display it. Now, with something like flow control, we can say, well, I have a lot of very important things I need to fetch, but I also want

to render a preview of the image because that would help me get the page displayed to the user more quickly. So I'm willing to accept like 10 kilobytes of the image because that's sufficient for me to render a preview. But then after that, I want all the other more important stuff. And then once I receive

that, I can resume that stream and receive the rest of the image. So this is something that is fundamentally new and previously not possible. And HTTP2 provides that. And then the other interesting feature that was added is server push. So the idea here is today in HTTP1, you send the request and you get a response. And there's a one-to-one correlation. But what if the server could actually send you back multiple responses?

And concretely, the use case here is you send the request for, let's say, a page, about.html. And then we send you back the HTML and you immediately come back to us and say well yes I also want the style sheet that you declared in that file. But the server already knew that. The server could already know about that. So why can't it just say here's the

index.html file and by the way I know that you will also need the style file or the style sheet file so here it is as well. Don't waste the round trip. There's absolutely no reason to block on a round trip. I know you will also need the style file or the style sheet file so here it is as well so like don't waste the round trip there's absolutely no reason to block on a round trip i know you will need this so please have it and uh this sounds kind of crazy but we've actually been already using this this is what inlining does right because when you inline right the contents of a file you're effectively saying don't don't come back and ask me for this like i know you will need this so here just have it.

So it effectively formalizes and enables this sort of interaction at the protocol layer, which is nice because one of the side effects of inlining is that you can't cache it independently, right? And so now you're inflating the size of the other file, it has problems with prioritization, or you can't prioritize it, you have to invalidate it more frequently. So push enables that, which is really cool. And once again, it's kind of a new capability has problems with prioritization or you can't prioritize it, you have to invalidate it more frequently. So Push enables that, which is really cool.

And once again, it's kind of a new capability that we just didn't have access to before. So some of these features are kind of direct. They're directly addressed the limitations of the previous limitations of the protocol. And some of these features just enable fundamentally new patterns of interaction between the client and server that I think we're yet to explore really effectively. And we'll talk about, I guess, the adoption and the current state of servers a little

bit later. But I think there's just a lot of room for innovation for how we deliver web applications with HTTP2. Good deal. That's definitely a good overview of HTTP2. We'll break here. Actually, you know what? There's one more, isn't there?

Yes, there's one more. There's one more thing. I almost forgot. Header compression. I mentioned that this is a separate specification. The problem that this was trying to address is that HTTP1 allows you to transfer data in compressed form.

For example, you can gzip your content, your text content, right? Which is very nice because it just so happens that gzip is very effective at compressing text content, typically reducing its file size by like 30 to 80%, which is huge savings. But the problem is that the actual metadata about

the request, things like your headers, your cookies and all the rest, was always transferred uncompressed. And over time, because we rely so much on headers and cookies and other things, this stuff has kind of accrued and we're now sending

sometimes megabytes of header metadata. I was recently looking at one website which had a lot of analytics and other beacons that during a single page load, it was generating one megabyte of traffic of just uncompressed

HTTP headers. What? That's crazy. How can you do that? Because the cookies are maxed out at a certain size, right? Yeah, different browsers actually have different ways to enforce it, but if you send enough requests, it all adds up pretty quickly.

It turns out that on average, the request response, even without cookies, adds about 800 bytes of metadata, which doesn't seem like much. But then you have to multiply it by a couple of hundred requests per page. And then if you do add cookies, you're very quickly approaching some pretty significant territory, like hundreds of kilobytes. So header compression was our way to address that, to say we should be able to compress this, and that's what HPAC is. HPAC actually provides two different mechanisms.

One is it uses Huffman coding with a static dictionary just to compress value. So you just give it a string, and there's a predefined dictionary which is used to compress these transferred data. And then the other mechanism it has is that the client and server keep state about what data has been exchanged.

So think of something like, say, the user agent header, which is kind of this long string which vaguely describes, I should say, the user agent and some properties about the device. That data does not change between requests. But in HTTP 1, we keep sending it on every single request, which adds hundreds of

bytes of data. With HTTP 2, the way it works is you just send it once. That goes into what we call a dynamic table, which basically just remembers that, okay, this thing has been sent, and let's say its ID is 55.

So next time, on the next request, I can just say 55. And you immediately know that, oh, okay, you want to communicate that you're also sending this header. So that significantly reduces the amount of metadata that's being transferred. We're talking

by a couple of orders of magnitude, where the lowest overhead of a HTTP2 stream now is about 9 bytes, as compared to, say, 900 bytes with HTTP1, which makes it very appealing for many other use cases. HTTP2, or HTTP in general is very popular outside of browsers as well, API traffic and all the rest. But one of the issues has been this high overhead of HTTP headers.

And with HTTP2, that's no longer a concern. So you can actually use it for much and many other use cases. Good deal. So you got one TCP connection, you got request and stream with multiplex and prioritized streams, binary framing layer, header compression, also known as HPAC. That sort of comprises HTTP2 in sort a one whack there let's take a break real quick we'll come back um and talk more deeply about each of these sections here but we'll hear from a sponsor and we'll be right back dream host now has managed vps hosting built for speed and scalability including solid state drives and that's awesome these vps's are built open-source developers and now include one-click installs of Node.js,

custom Ruby, and RVM support. Speed, speed, and more speed is what it's all about. Their VPS servers use SSD hard drives and are 20% faster than traditional SATA drives. All virtual private servers from DreamHost include SSD storage, Ubuntu 1204 LTS, web-based control panel, scalable RAM, which is super awesome. You can go from 1GB of RAM and easily scale up to 8GB if you need it. No JS one-click install, Ruby version manager, unlimited bandwidth, unlimited hosted domains, unlimited 24-7 support.

Go check them out and learn more at dreamhost.com slash the changelog all right we're back and uh so deep dive here on all the details of hdb2 i think the next question really is where from here we got server support browser support security concerns where is the best place to start with how HTTP2 actually becomes a thing to developers out there? Let's start with how it's implemented and how a conversation between a client

and server goes from H1 to H2. How does that all work? Right, so the upgrade cycle. I think this will take a short detour into the security discussion as well, or not security, TLS in particular. So in order to upgrade to HTTP2,

we have to somehow figure out if the client and server support it. Previously, we've just assumed that HTTP1. Now we need to somehow figure that out, and ideally we'd like to do that without any additional latency because that would kind of defeat the whole purpose of doing the performance optimization. So it turns out HTTP actually provides

some mechanisms to do upgrade and negotiation. So there's this upgrade flow. But for some interesting reasons that is actually not practically useful for hp2 in particular one of the things we we learned when we first started experimenting with speedy was that there's a lot of existing middleware on the web things like proxies even antivirus software running on' computers and other things that are looking at the flows over port 80 as they happen. And oftentimes when they detect something that doesn't smell like HTTP 1 or something that they don't understand,

they assume that it's either bad, malformed, or malicious, and just shut it down. And this is actually not new. We actually had the same experience with WebSockets because they also flow over port 80. And it turns out that if you try to deploy WebSockets over just unencrypted connections, oftentimes things just fail

and you have no idea why they fail. It's just for some reason the connection's aborted or it hangs or something else. But then you switch that same connection into 443 or you run it over TLS and everything's fine. So in practice, you'll find that today, the best practice for deploying WebSockets is over TLS. And we ran into the same issue with Speedy

where we would try to make connections over the unencrypted channel and sometimes these things would just fail. And like 20 to 30 percent of the time connections would just fail which is obviously unacceptable right if you try to browse the web like imagine trying to open google and 20 to 30 percent of the time a third of the time it just fails like that that's just not going to happen bad ux right for sure that's more than back ux that's just like we failed the user right yeah mean, it's just a horrible all-around.

That's no UX. Right, exactly. There's no experience for that. So, like, for that reason alone, we had to deploy Speedy over HTTPS because it provides an end-to-end encrypted tunnel, which means that these intermediaries and other things just see encrypted data flow, and encrypted data flow, they all look the same, so they can't really choke on it or do bad things to it. And it turns out that that same reasoning applies to HTTP2.

So the spec itself does not mandate that you use HTTPS. It actually provides mechanisms for you to use HTTP2 over unencrypted connections and you can certainly do that but the browsers that have implemented HTTP2 which are Chrome and Firefox have already shipped support for HTTP2

have said that they will only do HTTP2 over HTTPS on the public web. Why a discrepancy between the spec and the implementations? Well, so the spec just says, like, there's no reason... Say you're in a controlled environment. Say you have two servers that you control, and you control the path between them. There's no reason for the spec to mandate HTTPS from that perspective.

And we know that HTTP is being used in a variety of different environments. Now, with my security hat on, I will tell you that even though you think you have a clear path, you should still use HTTPS between your server-to-server communication or some sort of encrypted tunnel because we know that malicious people

do malicious things and they sniff on traffic and they can do things, bad things, with that traffic. Never heard of it. You heard it here first, Brooks. Using cryptic connections. It's a good thing. But at the same time, there's no reason,

there's no fundamental reason why we need to require that. So the spec says, yes, you can use it, but in practice, on the web, if you want to deploy it, you need HTTPS. And further, the browsers will only negotiate HTTP2 over TLS. And now the question is, okay, so now that we have TLS tunnel, how do we actually know that the client and server support

HTTP2 in particular? And there, there's actually a mechanism called ALPN negotiation, which is used to negotiate which protocols are supported during the TLS handshake. You said ALPN? That's right. ALPN, okay. So what happens there is when the client starts the establishment of the secure channel,

the client and server negotiate the parameters for the secure connection. Things like what kind of crypto are you going to use and other stuff. And as part of that handshake, there's now an extension that negotiates, or rather the client advertises

which protocols it supports. And then one of those protocols is HTTP2, if you support it. And then the server sees that and it can confirm that and say, okay, well, I also support HTTP2, so I will be talking to you in HTTP2. So this negotiation happens as part of the

TLS handshake, and this is important because it does not add extra latency. So if you're using HTTPS already, that would happen over TLS, the negotiation bit. And then your server would just automatically know to encode frames with

HTTP2 format as opposed to HTTP. And this is great because it actually makes the whole thing transparent. The server can take care of all of those details for you, and there's no extra latency. So just as a quick aside, certain people would complain

about the practical requirement of HTTPS. Because it raises the barrier to entry on the web. It costs money, at least until the FF gets their thing rolling. It's complicates things. I'm,

you know, it's a hobby project. It's my blog. I don't need security. What do you say to that? Oh, well, that's,

that's a very long discussion. So in practice, make it quick. Yeah. There's no, there's no such thing as insensitive traffic on the web. Uh, you can,

a malicious observer can infer a lot about your behaviors based on, uh, navigation patterns of things that you may not consider to be sensitive, but which in fact leak information about you, those around you, and all the rest. So the argument of, oh, but I'm just navigating, like I'm just serving a personal blog, does not stand in my books.

And many different people have made very good arguments in both directions. I happen to be on the side that I believe that we should encrypt all these things because the uh the incidentary uh kind of damage of revealing all of these bits adds up and you can infer a lot about the user and their intent just by observing these uh traffic patterns yeah so then there is the questions the practical concerns over how does this affect my performance? Obviously, doing crypto requires more work than not doing crypto. So how expensive is that?

It turns out that a decade ago, that was actually very expensive. Modern CPUs are optimized to execute crypto very, very quickly. You don't need dedicated hardware for that sort of thing. You did before. For example, Google, Facebook, Twitter, all the big companies run TLS purely in software. We're not buying additional hardware. And further, actually, as an interesting side effect of deploying things like speed in HTTP2, because we require far fewer connections, it actually can decrease your operational costs. Because you have to maintain fewer operational costs because you have to

maintain fewer sockets, you have to do fewer handshakes, and handshakes are actually the most expensive part of TLS. So we've seen studies where if you run a load test against an HTTP 1 server and then enable HTTP 2, the resource usage is actually lower because of all the things we just mentioned. So yes, there are costs to it. The whole certificate question, it depends on what kind of certificate you need, whether you need to support older browsers or not,

and all the rest. So yes, it adds a bit more complexity, but practically speaking, it is a requirement because we're just not willing to accept 30% failure rate. Right on. So while we're talking complexity and knee-jerk reactions, I admit that I had a knee-jerk reaction around the binary framing layer when I first heard about it. Being a fan of HTTP and the plain text aspect of it, and of course a binary communication protocol, doesn't let you just see what's going on down the wire. I'm sure you've had that come at you. What do you say about

people that complain about that particular aspect of H2? Sure, sure. So I think there's a couple of different perspectives that we should untangle there. One is implementation. Second one is kind of observability, right, as a user. So it turns out that implementation-wise, binary protocols are actually simpler and easier to implement correctly. I happen to have some experience with implementing both. I've implemented both HTTP2 and HTTP1 in Ruby. And from my own experience, I can tell you that parsing text protocols, which have kind of very ambiguous semantics about things, where they terminate,

how they terminate, and all the rest, is much harder than a length-prefixed binary protocol, which is very particular, right? It just says how many bytes I'm going to send you, and then the type of frame, and you have specific rules for how to parse the data. So in practice, it's actually easier to implement binary protocols. It is more provably correct

in the sense that there's far fewer edge cases that you have to consider. And performance-wise, because you're twiddling bits, it's actually better as well for the server. Because now you're not parsing strings, you're parsing just bits and bytes. So that's the implementation bits. There are

other implementation concerns with things like HPAC and all the rest, and there's more complexity on the server in terms of dealing with priorities, but that's kind of a separate discussion. Then, from the observability part, I'm sympathetic to the use case of, well, I just want to open Telnet and type in get and make the request, or observe it. But realistically, I don't think that's a very compelling

use case, or very common think that's a very compelling use case or very common at that. And if you need observability, then it's just a question of tooling. Maybe we just need better tools. We already have great plugins for Wireshark that will parse all the binary data and show you all of the things that you're used to. Similarly, if you open, say, Chrome DevTools or any DevTools in any browser, it doesn't matter whether you're running to similarly if you open say chrome dev tools or any dev tools in any browser it doesn't matter where you whether you're running over htp1 or htp2 like all of it is already parsed and you can see all the data there right and further like if you use tls then that's already binary framing right like so there's nothing new here it's just a question of tooling

and it like i do see some kind some short-term pain where we go from something that was easily inspectable because it could just run a grep on a stream to something that needs to take the stream, parse it, and then grep it. But I think that's very

easily solved. So essentially it sounds like the binary framing layer has allowed you to provide a more testable, provable method to do it rather than with text-based where before it had more edge cases to work around and more potential to fail. Yep, exactly. Yep. We talked about security. We talked about several things. Does it make sense to dive into the HPAC whatsoever?

I know there was kind of two components to that. We talked a bit about that, but not quite that deeply on how that changes the headers to the fact that it's got the frame layer and the data, the header frame and then the data frame. I think that particular aspect is most interesting to implementers. As a user, I'm more thinking about how do I use this? Who's using this? What's the upgrade process? How does it impact browser clients and server clients? Maybe we can go there, Ilya, and talk about adoption and who's adopting it, how it's rolling out,

and then how do we adopt it. Sure, yeah. So I guess let's start at the beginning with the spec itself. So the spec has been finalized, has been published as RFC. So I believe it's RFC 7540 and 7541. I think that's correct. So that's out in the wild as of a month ago. Back in February, Firefox was the first browser to enable HTTP2 in their stable browser.

So if you're using Firefox and you're talking to a server that is capable of talking HTTP2, then you're already talking HTTP2, which is great. Chrome has already also enabled support that was shortly after Firefox. So both browsers support HTTP2 in stable today. IE has indicated that they will ship HTTP2 support. And actually, let me make that stronger. So IE, their new browser, Edge,

is shipping with Windows 10, which is coming out, I believe, at the end of july i want to say 29th of july and edge supports hsp2 so as of early august you can get your hands on our users real users will start getting their hands on on stable version of windows windows 10 which will have edge which will talk hsp2. Safari also supports Speedy. Safari or Apple in general does not generally comment on their plans, but there's

absolutely no reason to believe that they will not support HTTP2 sooner rather than later. And in fact, because we do not want to maintain both protocols, Speedy and HTTP2, and we want to maintain both protocols, SPDY and HTTP2, and we want to move people towards HTTP2,

Chrome has actually announced that we will deprecate SPDY in Chrome in early 2016, which is kind of a nudge to the community to say that, like, hey, you've deployed SPDY, but there's a better thing and an official thing called HTTP2, so let's move over there. So there's kind of this year grace period where we've more or less formalized HTTP2 to deprecating Speedy.

So that's client support. There's also a growing and a good list of implementations for HTTP2 for various languages, so kind of libraries and all the rest. If you just search for HTTP2 for various languages, so libraries and all the rest. If you just search for HTTP2 wiki, you will come to a GitHub site that has a list of implementations.

And maybe we can share that in the notes afterwards. You'll find, I think, most every popular language, you'll find support for it. Is that http2.github.io? Is that the one you're talking about? Yep, that's the one. And then at the top there you'll see a link to implementations.

Yes. And that contains a table. It's just a wiki page on GitHub that contains the list. So if you're working on an implementation, please do add it there. So let's see. That's client. In terms of servers, there are some really good implementations out there already so uh there is

there are a number of big sites that have enabled it on their servers so twitter google facebook a bunch of others there are also open source implementations so coming out of this whole htf where there's actually a couple of new. There are also open source implementations. So coming out of this whole HTTP effort, there's actually a couple of new servers that have merged. For example, NG, HTTP, and H2O, both built by the HTTP2 community in Japan. They're very good. What was the second one, Ilya?

H2O. H2O. Some high quality H2O. Nice. Yep, yep.O nice they're very good you can try and deploy them today you can play with them rather and there is support coming to more popular

servers as well Nginx has announced that they will support HCP2 or they will add support for HCP2 sometime in I think Q3 or Q4 of this year that they will support HTTP2 or they will add support for HTTP2 sometime in, I think, Q3 or Q4 of this year. So they support SPDY today, but that will be replaced with HTTP2.

That's a big one. Yep. Varnish said that they're working and that's likely coming kind of in early 2016. That's my understanding. Then there is Apache Traffic Server already supports HTTP2. There is a couple of modules for Apache

that implement HTTP2. So, what else? Node, there's good implementations for HTTP2. I mentioned that I built a Ruby version. It's a library, not a server, but you can build a client or server with it so all that to say the support is coming, it's growing

the client support is there the servers are coming online there is lots of usage of it on the web today already which I think is really important to note HTTP2 is not some kind of newfangled thing

that has not been tested. Recall the fact that SPDY has been in development in parallel with HTTP2, and effectively we've been testing all of these ideas for a very long time, for like five years plus. So a significant portion of the traffic on the web today is already using HTTP2, and this is a very well-tested protocol.

So it's safe to deploy and production ready. Awesome. Well, I think we will take a break here, and when we come back, we'll talk about straddling the line between H1 and H2, and also, if you're interested in the nitty-gritty details, how you can learn more. Let's take a break, and we'll be right back. All right, put them them away put them back put the books back on the shelf you don't need them and learn to code by doing with code school code school offers a variety of courses javascript html css ruby ios git and many many more to help you expand your skills and learn new technologies.

CodeSchool knows that learning to code can be a daunting task, and they've combined experienced instructors with proven learning techniques to make coding educational and memorable. It gives you the confidence you need to continue past those rough, tough hurdles that you will definitely face learning the code. CodeSchool also knows that languages are a moving target. They're always updating their content to give you the latest and the greatest learning resources. You can even try before you buy. Roughly one out of every five courses on CodeSchool is absolutely and totally free.

This includes instructor classes on Git, Ruby, jQuery, and much more, which allow free members to play full courses with coding challenges all included. You can also pay as you go. One monthly fee gives you access to every CodeSchool course, and if you ever need a breather, take a break, you can suspend your account at any time. Don't worry. Your account history, your points history your points your badges they'll

all be there when you're ready to pick things up again get started on sharpening your skills today at codeschool.com once again that is codeschool.com all right we are back we are talking with ilia gregoric about http2 aka h2 AKA the new hotness in web performance. It's here. It's arrived. The spec is finalized. Support is coming. H1's going to be around for a long time, isn't it? It's not going to air.

We're not going to full-on replace it. It's with us for a while. But the nice news is that as people that deploy websites, it doesn't matter too much because we can just wait for the client to say they support the new hotness and then just kind of upgrade them and not worry about anything else. Is there anything at an application level? I mean, server push, I thought maybe would play in, but really that's just like pushing assets. It's not like server push as opposed to long polling. Is there anything at the application

level, somebody who's building a web app, that they could leverage in H2 feature-wise? Yeah, definitely. It comes back to the question of whether and what you can do to optimize for HTTP2. So we said earlier that any application will continue to optimize for HTTP2. So we said earlier that any application will continue to work over HTTP2.

So if you just deploy a new server that happens to talk HTTP2, everything will just work. Then the question becomes, can I make it better? And the answer is there's probably most definitely yes. And this is where we have to get into a whole separate discussion about let, let's re-examine some of our existing in air quotes, best practices to revisit them and see if we can undo some of the damage. So I don't think we have enough time to get into all of these, but things like domain charting is clearly an anti-pattern on,

on HP two. So you want to avoid that. And there's actually some good and nifty tricks that will allow you to do that without changing anything in your application. So I'll just, I have a resource that talks about that in particular that we'll mention later. Then there's concatenation. So you can actually start undoing some of that. And then the question becomes like, well, if I want to optimize for both protocols, because I have clients in both camps, how do I do that? And I think the practical answer there is, you can make it arbitrarily complex in the sense that you can actually say,

well, I know which protocol the client negotiated. So I'll serve one version of a website here and another version of a website there. Perhaps it's a little too involved. I think a more interesting question now becomes like, maybe there's a happy middle uh as more and more users migrate towards hdp2 i think you will see a very quick rise in adoption of hdp2 in terms of capabilities i think the server basically by the end of this year will have very good server support i expect very good client support as well and at that point the majority of of the users are on HTTP2. I think that should be sufficient to nudge most websites to say, well, we're willing to sacrifice some of the performance in HTTP1

without adding too much complexity in our actual development process in order to optimize for HTTP2. So perhaps we'll undo some of the concatenation. Maybe we won't ship 100 files, but we can now consider sending 10 files, right? Which may have some slightly negative repercussions for HTTP1, but it makes things much better because we can do caching and all these other things.

Similar things with server push. There is lots of cool opportunities there for total automation. So one cool example is Jetty. Jetty, Java HTTP web server, has had support for HTTP2 for a long time. And they actually have this really cool mode where the server observes the requests that come in.

So say the client requests the index file, and then the client also comes back and asks the CSS file and JavaScript file. There's a refer header that it can use to infer kind of that map of, well, you asked this and then you came back for these other things.

It observes that traffic pattern and then automatically starts server push for future clients. So you as a developer don't have to do anything. The server just takes care of all of these things. So I think we're going to see a lot of innovation in that space. There's new capabilities in terms of like, well, can you push cache invalidations? So if I told you to cache something for a year, can I push a record that says, well, please delete that out of your cache? So I think that those are the new and interesting things

that we're still yet to explore. But we're in pretty good shape. Awesome. So I think by now, our listeners are probably in two camps. Camp one is thinking HTTP2 sounds awesome. I can't wait till Nginx supports it so I just get better performance kind of out of the box for my web app.

And then camp two is probably like, I want to dig in. I want to understand HPAC. I want to understand server push and the binary framing and stuff. I think for the second group, we have good news with regards to your book, High Performance Browser Networking. You want to tell us about that? Yeah. So that's a book I've been working on or worked on with O'Reilly it's available today

and the book actually came out let's see a year and a half ago and in the original version I talked about the earlier drafts of HTTP2 and Speedy and I recently updated that so the print version does not have the latest content, but the good news is that you can go online and read the up-to-date content for free in your web browser. And you can find it at hpbn.co. And if you just add slash HTTP2, you can just go to the chapter directly, or you can just scan through the entire book. And it covers all the things we talked about here, but probably much more coherently and in more detail. So you can learn about kind of all the nitty gritty

of the protocol. And there's also a follow-up section on, well, now that we have this, how can we, what should we revisit and how can we optimize our applications? Awesome. So we'll link that up in the show notes. And you did hear him right.

The print version is not up to date. So whatever you do, don't buy the book. O'Reilly would be really happy with that message. Yeah. So I should say, we've been updating. So the beauty about writing technical books is they go out of date the moment you hit publish. So I've been updating the content kind of in small and incremental bits ever since it was published and we've actually released updates

print updates since then uh and the hp2 one is just much newer so it hasn't yet made it into the print version so if you were to buy a copy today when we're recording this it wouldn't have the the latest hp2 but the plan is to definitely have it there. And you mentioned potentially even like a smaller volume just for this new protocol coming in place and sort of diving deep into that. That's right. Actually, if you go to the O'Reilly website and you search for HTTP2, they published the new chapter, the new HTTP2 chapter as a separate ebook. So if you just want to read that, you can get that as a Kindle PDF

or whatever version you prefer. Gotcha. We'll definitely link up the chapter 12 is the chapter it is. So if you're on the high-performance browser networking site and you're already there, then just navigate to chapter 12 and you'll see the new chapter there for HTTP2. Can you restate the URL that you said was the blessed one for you? Because I got the long version, which I think was a redirect.

Are you tracking that or something like that? Yeah, it's just more convenient. It's a shortened version. So it's hpbn, which is the High Performance Browser Networking. It's just the first letters of the book. .co. Slash HTTPB2. Yep.

And that should take you to, I guess, Chapter 12. Gotcha. Perfect. Well, Jared, what else we got to cover? I know we talked about pretty much everything. I think the only thing we didn't talk about really was something that was sort of off-topic, but sort of in this camp to a degree which was ilia your focus on time to glass and jared and i before the call we talked about time to glass

and i was like well what is what is time to last year do you know what this is this is a term you've heard before and jared what did you say uh google glass time to google glass how to get our websites onto google glass fast it was what he thought it was. How long it takes someone to buy Google Glass. That's your time to Glass. I think today that's pretty long. I think that's quite the wait list. We talked about H2 and what that's bringing.

We talked quite a bit about straddling the line and what your suspected best practice is to support H2 and H1 at the same time, which is to sort of monitor your usage. And as the number teeters more towards H2, support more performance enhancements that are prescribed by H2 versus H1. But what is this thousand milliseconds time to glass challenge that was in one of your slides as you talked about H2? Sure. So the general premise is that we want to make pages visible or respond to user input within less than a second. And that means from the moment that you type in a URL to you hitting enter, regardless of what type of network you're on, whether you're on a mobile phone with a crappy connection or on a fast gigabit connection, you should have something visible to you within a second. And if you accept that as a challenge, then it becomes a question of, well, okay, so what are the mechanics behind that? Like, if you factor in all the

latencies for setting up a connection and making the request and getting a response, you very quickly arrive at the conclusion that you actually don't have a lot of time. Like a second seems like a long, a lot of time, but it's actually not very much. Like it puts very hard constraints on how quickly your server has to respond, how you structure pages, and a lot of other details. And actually, if you're curious about this particular topic, I'll do another plug. I actually have a Udacity course, which will probably take you a couple of hours to go through, but we kind of talk through in great detail about how the browser actually constructs a page,

like from receiving the first HTML bytes to parsing CSS and executing JavaScript. What does that pipeline look? And what do you need to think about to allow the browser to paint something very quickly? Because you can take the same page with the same assets and you can make it block

and not render anything for arbitrarily long, say five or ten seconds. And you can make the same page render something very quickly but then continue progressively adding content later. And the latter is the behavior that we want to enable. So this is both on the browser, like there's lots of things that the browser has to do

to make this happen, but also on the developer, because there are certain things that you do that the browser just can't work around. And the reason why it's accompanied in your HTTP2 talks is because a lot of this is really depending upon this entire conversation we just had, which was H2 being more supported. And that's going to,

like getting to one second on H1 is probably a lot harder or near impossible, but H2 makes it more possible. Yeah, exactly. So that's a question about, like, I need to fetch this many assets and only have this much time, but HTTP2 or HTTP1 places strict

restrictions on how many things I can fetch in parallel, so that prohibits me from, say, hitting that goal. Whereas with HTTP2, we can actually work around a lot of those things, or rather not work around. HTTP2 fixes all of those things.

And one of the reasons why I wanted to bring that into, I know it's sort of slightly off topic in addition to the conversation we just had, but if you've been following along in ChangeLog Weekly, which we ship out every Saturday, the last two weeks we've talked about this time to glass term, and one of them linked to something you had done, Ilya, I can't recall the link, but to recommend right now, but I'll put it in the show notes for those listening and even to the issues of weekly. But I wanted to bring that up since you were here on the show. We talked about time to glass recently in Change Law Weekly.

So for those listeners that read that email once every week, it sort of closes some of the gap on the term itself and what that means for H2 and getting closer to one second or 1,000 milliseconds or one second time to glass. Yeah, it's a really interesting topic if you're interested in kind of web development in general, but also just performance. Because it turns out that a lot of use cases right now are driven by mobile, which places a lot of restrictions on latency and also emerging markets. So there's explosive growth in terms of number of users coming online in places like India, Brazil and Russia and everywhere else. And networks are kind of slow there.

And they're also expensive. And we need to think really, really carefully about how we build pages and all the rest. So that's probably enough material there to talk about on another three episodes. Yes. Actually, I went back and looked. Episode 54, sorry, issue 54 of Change the Law Weekly, we actually linked to this chapter 12 that we've just been talking about here. So that was the one link. The other one was talking about rails and turbo links

and how turbo links aren't as bad as everyone says they are. The Rails community has been seeing this all along. And bonus, we actually linked out to your talk on breaking the 1,000 millisecond time to glass mobile barrier, which is what we've been talking about here. So there you go. Circle completed. Well, it's definitely fun having you back for for three times we'll get your jacket out to you soon enough uh so you can wear that with pride it's got the changelog emblem on there

and it's got i've been on the changelog three times on the back you can wear it to the office or local meetups whatever you know sweet. Whatever's particularly fancy on that part there. Jared, any thoughts on the closing here? No, just really appreciate you coming on the show. We really enjoyed it. I've been interested in the innards of what's coming on the pipeline with H2 for a while, so I'm glad we got to chat. Good deal.

All right, well, that is the show. And for now, let's say goodbye everybody see ya see ya thanks We'll see you next time.