Refresher Series: HTTP/2
This article serves as a quick refresher or hight level overview of the changes that HTTP/2 brings to the table.
What is HTTP2?
HTTP/2 is the next version of HTTP, following HTTP/1.1, and includes some changes that the HTTP Working Group thought would be helpful. It fixes some problems with existing HTTP/1.1, while also adding in some useful new features.
Evolved out of SPDY, which was an effort by Google to address some of the issues present in HTTP 1.1, most specifically latency. In HTTP/1.1, latency arises from all the handshaking and round trips between client and server and from the transport layer (TCP: transmission control protocol). In fact, according to google studies, at a certain point, latency can have a larger effect on page load speed than the actual bandwidth speed.
What are the changes?
Request and response multiplexing
Basically, allowing multiple resources to be requested through the same TCP connection, where previously only 4-8 resources could be retreived at a time. This lead to slower speeds and congestion before. now, instead of using all of those 4-8 connections, 1 connection does everything. From google: ‘All communication is performed over a single TCP connection that can carry any number of bidirectional streams’. So, 1 TCP connection handles the communication of requests and responses within individual items called BINARY-ENCODED FRAMES. Requests and responses live within a stream, which is made up of Binary-Encoded Frames. And the streams live within the tcp connection. and ONE TCP connection now handles all of these streams instead of 4-8. HTTP/1.1 used TCP connections inefficiently, and only allowed one response to be delivered at a time and each TCP connection handles only one request.
Prioritize more important assets
The server can specify a prioritization tree that delivers more important files first, and can also specify dependencies on other files. the prioritization tree looks like a tree data structure, with nodes and each node having a value. parent nodes are loaded first with the idea that the child nodes depend on the parent node, then the child nodes are allocated resources according to their value. the key word here is PRIORITIZATION. this does not mean the files will be delivered in the exact order you specified, that would not be desired in case a file was blocked for some reason.
It allows the receiver to tell the sender that it is overloaded, and for the sender to back off for a bit while receiver catches up. like when loading a large video, the client can say tell the server how many bytes it wants to be downloading at a given time. you don’t want to unnecessarily load resources that aren’t going to be viewed.
The server can send multiple responses/resources to the client from a single request, without the client needing to have requested the specific resource. for example) when the request for the initial html is sent to the server, the server can also send the css with the html, because we know its going to do that next anyway. this means the user gets the resource faster since there were less trips. just make sure you are pushing resources that the user DEFINITELY is going to get anyway. the server push will first send a push_promise to make sure the resource isn’t already in the cache or whether the client doesn’t want it.
Header and field compression
Reduces the size of headers by compressing them with HPACK and also by keeping a table that keeps track of all the headers that have been sent so far. in HTTP/1.1 the size of the header could add 500-800 bytes of overhead to the request and response, so compressing these is a good thing.
How will this impact creating things for the web
- you’ll need to enable your server to use http/2 and probably do a little bit of server work to optimize things, but many things work the same way. Nothing should break initially when you switch over.
- no longer need to domain shard now that 1 TCP connection can handle everything through the binary framing layer.
- don’t need to concatenate files
- in general, don’t need to worry about loading many seperate files, so concatenation, image sprites, etc are unnecessary
- lower page loading times because of the decrease in latency
- with server push, essentially don’t need to inlince css in the head anymore