HTTP/2 - The secret weapon of gRPC

Hi everyone! In this lecture, we will learn what HTTP/2 is, how it works, what makes it a great weapon of gRPC, and compare it with the old HTTP/1.1.

Here's the link to the full gRPC course playlist on Youtube
Github repository: pcbook-go and pcbook-java
Gitlab repository: pcbook-go and pcbook-java

Why HTTP/2?

gRPC uses HTTP/2 as its transfer protocol, so it inherits some great features that HTTP/2 offers, such as binary framing, which is high performance and robust, lighter to transport and safer to decode compared to other text-based protocols. And because it’s binary, it’s a great combination with protocol buffer.

HTTP/2 also compresses the headers using HPACK, which will reduce the overhead cost and improve the performance.

Multiplexing is possible in HTTP/2, which means the client and server can send multiple requests and responses in parallel over a single TCP connection. This will help reduce the latency and improve network utilisation.

And finally, HTTP/2 allows server-push, where with 1 single request from client, server can send back multiple responses. This is extremely valuable to reduce the round-trip latency between client and server in many cases, when server knows exactly what resources client will need and send them before they’re even requested.

Let’s checkout this demo to see how fast HTTP/2 is compared to HTTP/1.1. Basically in this demo, we will try to load 200 small images from the server.

As you can see, HTTP/2 loads almost twice as fast as HTTP/1.1.

How HTTP/2 works

So, how HTTP/2 works under the hood? Its logical structure can be represented as in this picture:

There’s a single TCP connection that carries multiple bidirectional streams. Each stream has a unique identifier, and carries multiple bidirectional messages.

Each message, can be request or response, is broken down into multiple binary frames. A frame is the smallest unit that carries different types of data, for example HEADERS, SETTINGS, PRIORITY, DATA, and so on.

In fact, the streams do not actually flow separately, but their frames are interleaved on the connection, and will be reassembled when reaching the other side. Thanks to this binary framing layer, stream multiplexing is possible in HTTP/2

HTTP/2 vs HTTP/1.1

OK, so now you’ve understood how HTTP/2 works. Let’s do a comparison with HTTP/1.1 to see the differences between them.

• First, HTTP/2 is a binary protocol, while HTTP/1.1 is a text protocol.
• Headers are compressed in HTTP/2, while it’s plain text in HTTP/1.1
• HTTP/2 allows multiplexing, HTTP/1.1 doesn’t
• We can send multiple requests and responses in a single connection in HTTP/2, while in HTTP/1.1 we can send only 1, which means that we must create multiple TCP connections to send multiple requests.
• Server-push is possible with HTTP/2, but not in HTTP/1.1
• HTTP/2 was released recently in 2015, while HTTP/1.1 was released in 1997.

So that’s wrap up our lecture about HTTP/2. In the next lecture, we will learn about different use cases of gRPC and compare it with REST.

If you like the article, please subscribe to our Youtube channel and follow us on Twitter for more tutorials in the future.

If you want to join me on my current amazing team at Voodoo, check out our job openings here. Remote or onsite in Paris/Amsterdam/London/Berlin/Barcelona with visa sponsorship.