HTTP/2 — The basis for gRPC

In the previous article, we have seen HTTP/1.1 in detail and what the browsers perform in the background to make it faster. In this article, we will see HTTP2 in detail.

Understanding HTTP2 is very essential for every backend developer as, in the future, HTTP2 will be used widely. Today almost all web servers and browsers support HTTP2, even the browsers on mobile phones do support HTTP2.

1. Introduction

HTTP/2 is derived from the SPDY protocol which was developed by Google. At the highest level, HTTP/2 doesn’t change the semantics of HTTP/1 such as methods, status codes, headers, and URIs. But it introduces new ways of how the data is framed and transported between the client and server.

The primary goals for HTTP/2 are to reduce latency using techniques like;

1. Request and Response Multiplexing
2. Minimize the protocol overhead using header compression
3. Support for request Prioritization
4. Server push

To implement the above requirements, there are other supporting features such as new flow control, error handling and etc were implemented. But the above features are the most important that every web developer should understand. These features enable more efficient use of network resources and more efficient processing of messages through the use of binary message framing.

2. Binary Framing Layer

The Binary Framing layer is at the core of all performance enhancements of HTTP/2. It specifies how the HTTP messages are encapsulated and transferred between the client and server. This layer introduces a new optimized encoding mechanism of the message between the socket interface and the higher layer where the HTTP API is exposed to our applications. This means the HTTP semantics, such as verbs, methods, and headers, are not affected but the only thing that changes is how they are encoded in transmission.

As shown in the diagram, what happens in this layer is, in HTTP/1.1 the message is text-based and newline delimited. But in HTTP/2 the message is split into smaller messages and frames, each of which is encoded in binary format.

This encoding happens in the Application Layer. Any client and server that supports HTTP/2 perform all the necessary framing work on our behalf.

3. Header compression

In HTTP/1.1, the headers are always sent as plain text which resulted in several thousand bytes (sometimes kilobytes especially when cookies are involved) of overhead per transfer.

To reduce this overhead, HTTP/2 compresses request and response headers using the HPACK compression format based on Huffman coding algorithm.

Now, this new binary framing mechanism changes how the data is exchanged between the client and server and leads to new concepts such as Streaming, Messages and Frames.

4. Streams, Messages and Frames

To understand the process let us familiarize ourselves with the HTTP/2 terminology.

4.1. Stream

A stream is a bidirectional flow of bytes within a single established TCP connection, which can carry one or more messages. The term bidirectional refers to the fact that a particular request and its response happen in the same stream. A TCP connection can carry any number of bidirectional streams. Each Stream has a unique identifier and optional priority information that is used to carry the HTTP/2 messages.

4.2 Message

An HTTP/2 Message is a complete sequence of frames that represent a request or response. So a message in HTTP/2 consists of one or more frames.

4.3 Frame

A Frame is the smallest unit of communication in HTTP/2 that carries a specific type of data, for example, an HTTP Header, a message payload, or any other piece of information that is to be exchanged. Each frame is associated with a Stream ID in its header. The significance of the Stream ID Frames from different streams may be interleaved in the connection and then reassembled using the Stream ID.

1. Each stream is a bidirectional flow of bytes and each stream has a unique identifier.

2. A Message is a sequence of frames that represent the whole request or a response.

3. A frame is the smallest unit of communication with a stream id stamped in its header.

If you understand the above terminology properly in short what it says is that HTTP/2 breaks down the HTTP communication into several binary-encoded frames, which are then mapped to messages that belong to a particular stream, all of which are multiplexed within a single TCP connection. This is the very foundation that enables the performance optimizations provided by the HTTP/2 protocol. Below diagram explains this.

Now let's see what we mean by multiplexing.

5. HTTP/2 Multiplexing

We have seen in the previous article with HTTP/1.1 that if the client wants to make multiple requests at the same time, then it needs to open multiple TCP connections. And we have also seen what Head-of-Line blocking is.

The new binary framing layer in HTTP/2 completely avoids these techniques and enables full request and response multiplexing, by allowing the client and server to break down an HTTP message into independent frames, interleave them, and then reassemble them on the other end.

From the above diagram, you can see multiple streams flowing within the same connection. Lets look at the same in different perspective.

In the above diagram, while the client is tranmitting the request frames in different streams, the server is transmitting a DATA frame (stream 3) to the client. The client and server here are transmitting an interleaved sequence of frames between themselves. As a result, there are three parallel streams in flight.

The ability to break down an HTTP message into independent frames, interleave them, and then reassemble them on the other end is the single most important enhancement of HTTP/2. This very feature enables us to:

• send multiple requests in parallel without blocking on any one.
• receive multiple responses in parallel without blocking on any one.
• use a single connection to send and receive multiple requests and responses in parallel.

This makes our applications faster and simpler. Now, browsers don’t need to do any of those that we discussed in this article. In fact, all the best practices of optimizing HTTP/1.1 now become the anit-patterns in HTTP/2.

The splitting of many individual frames also enables us the client and server to choose the order in which the frames can be delivered. This is known as Stream Prioritization.

6. Stream prioritization

Once the frames from multiple streams can be multiplexed into a single TCP connection, the order in which the frames are interleaved both by the client and server becomes a critical performance consideration. For this to be facilitated, the HTTP/2 standard allows each stream to have an associated weight and dependency:

6.1 Stream Weight:

A stream can be assigned an integer weight between 1 and 256.

6.2 Stream Dependency:

A stream can be given another stream as dependency using their ids.

With the stream dependencies and weights, the client is allowed express how it would prefer to receive responses. The client basically creates a prioritization tree with the combination of weight and dependency.

The server then uses this information to prioritize to process the streams then returns the responses to the client based on the priorities.

7. One connection per origin

With the new binary framing mechanism in place, HTTP/2 no longer needs multiple TCP connections. All HTTP/2 connections are persistent, and only one connection per origin is required and it makes more efficient use of each TCP connection, and also significantly reduce the overall protocol overhead. The use of fewer connections also reduces the memory and processing footprint along the full connection path. This reduces the overall network costs and further improves network utilization and capacity. You can now understand the ripple of advantages that HTTP/2 offers.

8. Server push

Another important feature that HTTP/2 offers is server push — the ability of the server to send multiple responses for a single client request. For example, if a client requests a single HTML page that has the external java script and css files, the HTTP/2 server has the capability of pushing the the java script and css files, probably in different streams, with out an explict request from the client.

What is the benefit of this?

Well, a conventional html page rendered by a web application comprises of various references to external files css, html, javascript, images, video files, and etc. In HTTP/1.1 all of these are discovered by the browser by examining the document, and then opens different connections to request different resources needed by that HTML page. This is avoided by HTTP/2. When the server already knows which resources the client will require; it just sends those resources without an explicit request from the client. This is called Server Push.

Now, in HTTP/2, when the server pushes the other resources how does the browser know to evaluate these resources together and how does it know which resources belong which page? This is where the concept of PUSH_PROMISE comes into picture.

Each server push stream is initiated using the specifal frames called PUSH_PROMISE frames. This dictates the client or the browser that the server’s is pushing the described resources to the client. And these PUSH_PROMISE frames need to be delivered ahead of the actual response data. This delivery order is critical as the client needs to know which resources the server intends to push. This also comprises of stream dependency and stream weights which we mentioned earlier.

Once the client receives a PUSH_PROMISE frame, it can make a choice of declining it, as the resource may already be in the cache.

There is a lot to talk about HTTP/2 of what it offers and its disadvantages. One single article is not enough to mention all the details. In the upcoming article we learn more about the HTTP/2 and how the gRPC works based on HTTP/2.

Stay Tuned. And let me know if you have any questions or improvements or any other concepts that you want to learn in the comments section. If any corrections(typos or conceptual) please highlight them as well. Because nobody is perfect. And I will be very happy to receive negative comments as well if they help in improving these articles. Together we may understand it better.

*** Follow me on LinkedIn. Have a Happy Learning. :) *** *** Together we may understand it better. ***

If you liked this content and want to read more like this, consider supporting me and thousands of other writers by signing up for a membership. It only costs $5 a month giving you unlimited access to stories on Medium. You even have a chance to make money with your own writings as well. If you sign up using my link, I’ll be supported directly with a small portion of your fee. If you do so, thank you plenty!