Hot Posts

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.

web page 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

Screen Shot 2016-05-15 at 21.14.49.pngScreen Shot 2016-05-15 at 21.14.49.pngScreen Shot 2016-05-15 at 21.14.49.png

This solution has two main issues.

  1. TCP sockets are expensive to create and
  2. 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:

    <link rel="stylesheet" href="/style.css">
    <img src="logo.png">

You could run it through an inlining tool to get something like this:

      body {
        font-size: 18px;
        color: #999;
    <img src="data:image/png;base64,Rw0KGgoAAAANSUhEUgAAAEAABA...">
    console.log('Hello, World!');

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.

Screen Shot 2016-05-15 at 21.38.04.png



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

Screen Shot 2016-05-15 at 21.14.49.pngScreen Shot 2016-05-15 at 21.14.49.png –> Screen Shot 2016-05-15 at 21.14.49.png


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.


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

Screen Shot 2016-05-15 at 22.05.46


Once broken down into frames you can interweave the logical stream over a single TCP connection.


Stream 9 (h) -> <- stream 2 (h) : Stream 7 (d)  -> <- Stream 2 (d) : Stream 7 (h) -> <- Stream 4 (h)


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)

Screen Shot 2016-05-15 at 22.08.34

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
  • RST_STREAM, about errors, notifying there is an error, client rejects push request because it already has resource
  • PING,

Screen Shot 2016-05-15 at 22.13.16.png

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
Accept: text/html
:method: GET
:scheme: http
:path: /index.html
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
Content-Type: text/html

Hello World

: status: 200
content-length: 11
content-type: text/html

Hello World

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
:path: /index.html
accept: text/html
user-agent: Mozilla/5.0
:method: GET

:scheme: https
:path: /info.html
accept: text/html
user-agent: Mozilla/5.0


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: /index.html
accept: text/html
user-agent: Mozilla/5.0

: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.

Screen Shot 2016-05-15 at 22.39.06.png

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.





%d bloggers like this: