Slide break down
S1 The Goal of HTTP/2
Increased Web Performance
The goal of HTTP/2 is to increase the perceived performance of the web browsing experience.
Why Do We Need HTTP/2
We have been using HTTP/1.1 successfully for the last 15 years so why do we need HTTP/2.0? What is the motivation for the new version of the HTTP protocol? Lets start by looking at the problems with HTTP/1.1.
Problem with HTTP/1.1
S2 What’s in a Web page?
If you decompose a web pages you will see that it consists of many resources: images, CCS style sheets, JavaScript files and so on. All theses resources are loaded and rendered by the browser.
In fact over the last five years, since April 2011, the average size of a top 1,000 web page has increased by over 300% to 2101 bytes according to the HTTP Archive and the average web page now loads over 120 resources.
S3 How a browser loads a webpage?
The browser requests the webpages and finds that it requires a number of resources. It then starts to request these resources one at a time.
In the beginning HTTP/1.0 allowed only one request to be made via a single TCP connection. In HTTP/1.1 this was addressed with pipelining, the browser can make multiple requests
A request is sent for all the required resources. A request is sent for style_1.css, image_1.pgn and javascript_1.js and the browsers waits for the server to respond with the requested resources. The server will respond in the order in which the resources were requested, but what happens if the image returns quickly and the JavaScript takes time to return to the client: the browser must wait until the JavaScript file is return, the other requested resources are not returned until the server responds with the JavaScript file. This is called head-of-line blocking.
Hacks AKA Work-Arounds
What are the ways we solved this problem?
S4 Solution to Head-Of-Line Blocking
Multiple Connections
Multple connections are set up. On connection one the browsers loads the style_1.css file on connection two it loads the javaScript_1.js file on connection 3 it loads the image_1.png file and so on.
connect 1 connect 2 connect 3
style_1.css javaScript_1.js image_1.png
This solution has two main issues.
- TCP sockets are expensive to create and
- For a given browser there is maximum number of connection per host
Given these restrictions we looked for a different way to optimise page loading.
S5 HTTP/1.1 Optimisation
Many of the solution devised to address these issue are workarounds to overcome the shortcomings in HTTP/1.1. So what are these hacks?
Workarounds to Host Restrictions
S6 CSS/JavaScript File Concatenation
Create one large CSS file containing all the site’s styles and one large JavaScript file with all the required dynamic logic, even the page itself could contain all it’s required CSS and JavaScript.
S6.5 CSS and Javascript inlining
Inlining assets is a special case of file concatenation. It’s the practice of embedding CSS stylesheets, external JavaScript files, and images directly into an HTML page. For example, if you have web page that looks like this:
<html>
<head>
<link rel="stylesheet" href="/style.css">
</head>
<body>
<img src="logo.png">
http://scripts.min.js
</body>
</html>You could run it through an inlining tool to get something like this:
<html>
<head>
<style>
body {
font-size: 18px;
color: #999;
}
</style>
</head>
<body>
<img src="data:image/png;base64,Rw0KGgoAAAANSUhEUgAAAEAABA...">
console.log('Hello, World!');
</body>
</html>This can reduce the number of HTTP requests for a given web page to one.
S7 Image Sprite Sheet
An image sprite is a single image file made up of all the sprites you use on the web page. Instead of 10 images we have just one. Each sprite is cut from the sprite sheet on the client side before use.
Image sprites in the wild from Amazon, Google and Facebook.
S8 Domain sharding
To over come the maximum number of connection to a host by the browser we can host the style sheets on one host and the JavaScript on another. This way we are not bound to one host.
s9 Inlined Assests
Resources can be embedded inside the web page. We have seen that the CSS and JavaScript can be embedded but it is possible to embed an image into the HTML as well. The image is base64 encoded and inserted into the web page then when the web page is loaded it is extracted and decoded using base 64.
A lot of time is spent encoding and decoding and caching cannot be easily done.
Sockets
S10 What HTTP1.1 Says About Sockets
Socket are seen by HTTP1.1 as a throw away resource as the specification does not say much about how they are to be used nor is there any mention of how many sockets a browser should open to a given host. It just by industry consensus that they open 5 or 8. Mosaic opened just one and then Internet Explorer opened 4.
S11 What HTTP/2 Says About Sockets
In contrast sockets are seen as a scares resource and the specification talks much about how they are to be used. Ideally a browser should open only one socket to the server and do all it needs over this one socket. Everything that was done in N sockets is now done over one socket connection.
S12 All connection now operate as one connection
–>
S11 Top Line Features of HTTP/2
HTTP2 is much more complicated to implement
S12 Request/Response Multiplexing
The most important change in HTTP/2.0 is the multiplexing of request/response even over one connection it is bidirectional.
- Connection – A TCP socket
- Stream – A channel of communication within a connection
- Message – A request/response and control message
- Frame – The smallest unit within a communication.
For a given request you would have just one HTTP request now, with HTTP/2, we break it down into smaller frames and this is how we resolve head of line blocking.
S13
The TCP connection is broken down into frames.
For a given connection you have multiple stream you can have multiple message and for a given message you have multiple frames. You can see that there is a hierarchy .
Frame is the fundamental unit of communication
S14
Once broken down into frames you can interweave the logical stream over a single TCP connection.
BROWSER
Stream 9 (h) -> <- stream 2 (h) : Stream 7 (d) -> <- Stream 2 (d) : Stream 7 (h) -> <- Stream 4 (h)
SERVER
Stream 7 sends its headers first then later it sends its data which is its HTTP request body and before the server receives the completed stream 7 its sends back response to stream 2.
Because the server does not have to wait for the completed communication before it does something else the head of line blocking problem does not occur.
Not a new idea borrowed from netwrking (1960)
S15 Binary Framing (Decomposition of the frame.)
- Solves head-of-line blocking problem
- Type fields
The frame has a header and the head consists of some information:
A frame consists of Length of payload (24), type(8), configuration flags(8), R (reserved bit), Stream identifier(31) and Frame Payload (0 …)
The stream identifier refers to the 9, 2, 7, 4 in the previous diagram.
There are many different types of frames:
Type fields can be
- DATA corresponds to the HTTP request body. If you have a large body you may have multiple of them data 1, data2 etc
- HEADER, corresponds to the HTTP headers
- PRIORITY,
- RST_STREAM, about errors, notifying there is an error, client rejects push request because it already has resource
- SETTING,
- PING,
- GOAWAY,
- WINDOW_UPDATE,
- CONTINUATION
Lets see how the HTTP request is mapped to frames
s16 Mapping the HTTP Request to Frames
On the left we have an HTTP request and on the right we have it mapped into a header frame.
| HTTP request | Header Frame |
| GET /index.html HTTP/1.1 Host: example.com Accept: text/html |
HEADERS +END_STREAM -END_HEADERS :method: GET :scheme: http :path: /index.html :authority: example.org accept: text/html |
In the header frame you have two configurations the first is END_stream which is set to true (the plus means true) this means that this is the last frame for this request and if you set end_headers to true then this frame is the last frame in the stream that contains header information.
Then we map the familiar header information from the HTTP 1.1 request.
The colon denotes that this is a sudo header and references its definition in the HTTP2 specification.
Lets look at the response.
S17 Mapping the HTTP Response to Frame
| HTTP Response | Header Frame |
| HTTP/1.1 200 OK
Content-Length: 11 Hello World |
HEADERS -END_STREAM +END_HEADERS : status: 200 content-length: 11 content-type: text/html DATA |
The end_stream is minus because this is not the last frame and the end_header is true as this is the last frame with header information.
The header frame contains a lot of information that has been duplicated between requests. How can we optimize this?
S18 Header Compression
HPACK – header compression
Between request there is a lot of information that is the same. Between request 1 and 2 the only difference is the path. So why send this over and over again?
| HTTP Request 1 | HTTP Request 2 |
| :method: GET :scheme: https :host: example.com :path: /index.html :authority: example.org accept: text/html user-agent: Mozilla/5.0 |
:method: GET
:scheme: https |
Instead of sending the data over and over again.
In HPACK it tries to keep a table of the headers on the client and servers then when the second and subsequent headers are sent across you just reference the header number on the header table. Then the server/client knows which header you are actually using.
| HEADERS frame (Stream 1) | HEADERS frame (Stream 3) |
| :method: GET
:scheme: https |
:path: /info.html |
Stream Prioritization
HTTP/2 provides the ability to attach priority information to streams which gives priority to one resource over another.
The priority can be entered in the header frame or the priority frame.
We can also define a hierarchy between stream however it is only advise to the server which is completely free to ignore the priority information.
Stream A, b, d, c
C will take 3 times the resources as B
S19 Server Push
Eliminate the need for resource inlining.
The sever can proactively send resources to the client.
The server tries to prepopulates the browsers cache with resources so that when the resource is needed it is already available. and does not need to be requested saving time.
The way it works.
The server will push the resources to the browser and send and SSE to the browser with the name of the resources as data in the event. The browser will use JavaScript to look at the event and say OK I want this resource and then he will look at the cache because it was pushed earlier.
The way it works.
The client sends header frames to the server to get a file in this case an index.html at some point the server will send me the file.
The server knows that if I am requesting that file I will also want to request the resources that the file requires to render that html file. In this case a CCS and an image. the Server can decide to proactively send those resources to the client even though the client has not asked for those resources.
The server knows the those resources will be requested. So the server sends a push promise frame for the CSS and a push promise frame for the image. Then the server sends the index file.
The client can ignore those resources. It knows that those resources are in the cache so it declines the push promise so it will not be sent to the client.
S20 HTTP1.1 Upgrade
- alpn
- switching protocols
Most websites are in HTTP1.1 so how do they talk in HTTP2. Two ways.
If you are using HTTP in clear text you can use the upgrade mechanise in HTTP1.1 to send upgraded header to upgrade to a protocol called h2c, c means clear text then the server will react and upgrade to h2c.
if you are using HTTPS you can use ALPN (application layer protocol negation) which is a TLS extension. You send an extension during the handshake to the server side and server figures out that it is h2 and the communication continues in h2.