Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 31

gRPC and HTTP/2: Performance Deep Dive

Recommended resources

Welcome back! In our last lesson, we contrasted Protobuf with JSON and concluded that Protobuf's binary serialization is significantly more efficient in terms of size and speed, making it the superior choice for internal microservice communication. However, an efficient data format is only one half of the performance puzzle. The other half is how that data is transported across the network.

This lesson focuses on that transport layer. We'll explore how gRPC is built on top of HTTP/2, a modern version of the protocol that powers the web. You will learn precisely how gRPC leverages key HTTP/2 features like multiplexing and header compression to achieve its remarkable performance, setting it apart from traditional REST APIs that often rely on the older HTTP/1.1.

The Problem with HTTP/1.1: A Traffic Jam on the Information Superhighway

Before we appreciate HTTP/2, let's understand the limitations of its predecessor, HTTP/1.1, which has been the foundation of REST APIs for decades.

HTTP/1.1 suffers from a problem called Head-of-Line (HOL) blocking. Imagine a single-lane road. If a slow truck gets on the road, all the faster cars behind it are stuck. They can't overtake. In HTTP/1.1, a TCP connection is like that single-lane road. If a client sends multiple requests over the same connection, they are processed sequentially. A large or slow-to-process request blocks all subsequent requests.

To work around this, browsers open multiple TCP connections (typically 6-8) to a single server to download assets in parallel. This adds significant overhead: each new connection requires a three-way TCP handshake, which introduces latency. For a microservices architecture with hundreds of inter-service calls per second, this overhead is unacceptable.

HTTP/2 to the Rescue: Multiplexing and the Binary Framing Layer

HTTP/2 was designed specifically to solve these problems. Its most significant feature is multiplexing.

Instead of a single-lane road, HTTP/2 creates a multi-lane highway over a single TCP connection. This allows multiple requests and responses to be in flight simultaneously, without blocking each other.

This is made possible by the binary framing layer. HTTP/2 breaks down every request and response into small, binary-encoded chunks called frames. Each frame is tagged with a unique stream ID, indicating which request it belongs to. The client and server can interleave frames from different streams, send them over the single TCP connection, and reassemble them at the other end using the stream IDs.

HTTP 1 Vs HTTP 2 Vs HTTP 3!

The video "HTTP 1 Vs HTTP 2 Vs HTTP 3!" from ByteByteGo provides a great visual summary of these concepts.

First, watch the brief introduction to the binary framing layer. Then, focus on the explanation of full request and response multiplexing, which shows how this solves the head-of-line blocking problem.

The image below provides a clear visual contrast between the two protocols.

HTTP/1.1 vs HTTP/2: TCP Connection Comparison
This diagram illustrates how HTTP/1.1 requires multiple TCP connections to fetch multiple resources, while HTTP/2 uses multiplexing to fetch all resources over a single, more efficient TCP connection.

For gRPC, this is a game-changer. It means a client can make many concurrent RPC calls to a server over one long-lived connection, drastically reducing latency and resource usage compared to creating new connections for each call.

Shrinking the Overhead: Header Compression with HPACK

Another major source of overhead in HTTP/1.1 is the headers. In a typical client-server exchange, many headers are sent with every single request (e.g., Host, User-Agent, Accept). In a microservices environment, you also have custom headers for tracing, authentication, and routing. These headers are plain text and can add up to a significant amount of redundant data.

HTTP/2 introduces a sophisticated header compression mechanism called HPACK. HPACK is not a general-purpose compressor like Gzip; it's specifically designed for the repetitive nature of HTTP headers. It works in two main ways:

  1. Dynamic Table: Both client and server maintain a table of previously sent headers. If a subsequent request contains the same header (e.g., content-type: application/grpc), it can be replaced with a small integer index pointing to the entry in the table.
  2. Huffman Encoding: For new or changed header values, HPACK uses Huffman encoding to represent common characters with shorter bit sequences, further compressing the data.

This process is incredibly effective, often reducing header size by 80-90%.

gRPC vs. REST: Under the hood: gRPC and HTTP/2

The article "gRPC vs. REST" from the LogRocket blog provides an excellent technical deep dive into how gRPC benefits from HTTP/2.

Read the section "Under the hood: gRPC and HTTP/2". Pay close attention to the subsections on the Binary framing layer, Multiplexing, and especially Header compression with HPACK. The article clearly explains the technical details and lists the specific advantages for gRPC.

Tying It All Together: A gRPC Call Over HTTP/2

Now, let's see how these pieces come together to make a gRPC call so efficient. When a gRPC client calls a server method:

  1. Connection: The client establishes a single, long-lived TCP connection to the server.
  2. Stream Creation: A new HTTP/2 stream is initiated for the RPC call.
  3. Headers: gRPC metadata (method name, authority, timeouts, etc.) is packed into an HTTP/2 HEADERS frame. These headers are heavily compressed by HPACK.
  4. Payload: The Protobuf-serialized request message is broken into one or more HTTP/2 DATA frames. Because the Protobuf payload is already a compact binary format, this part is also very efficient.
  5. Execution & Response: The server receives the frames, reassembles the request, and executes the service logic. The Protobuf-serialized response is then sent back in DATA frames on the same stream.
  6. Trailers: At the end of the call, the server sends a final HEADERS frame, often called a TRAILERS frame. This contains the final gRPC status of the call (e.g., grpc-status: 0 for OK) and any optional status message. Sending status in the trailers is efficient because it allows the server to stream the response body first and determine the final status afterward.

The image below shows what this looks like in a network inspection tool. Notice the grpc-status appearing in the "Trailers" section, separate from the main response body.

gRPC Traffic Inspection with HTTP/2 Headers and Trailers
This screenshot from a network analyzer shows a gRPC call. Note how the gRPC status and message are communicated via HTTP/2 trailers after the main response body, a key feature of the gRPC-over-HTTP/2 protocol.

This entire process benefits from multiplexing, meaning hundreds of these RPC calls can be happening concurrently over the same single connection, without blocking each other.

What is RPC? gRPC Introduction.

This video from ByteByteGo succinctly summarizes the relationship between gRPC and HTTP/2.

Watch the segment from gRPC on HTTP/2 to reinforce how multiple gRPC streams run over a single, long-lived TCP connection.

Interview Prep: Your Turn

Imagine you're in a system design interview. The interviewer asks:

"We're currently using REST APIs for our microservices. Some engineers have proposed moving to gRPC for better performance. Another engineer argues, 'Our REST APIs can run over HTTP/2, so we'll get the same benefits without changing our whole stack.' How would you respond to that?"

Click to reveal a suggested response

That's a great point, and it's true that REST can technically run over HTTP/2. However, the performance benefits are not equivalent to what gRPC offers, for a few key reasons:

  1. It's a Two-Part Equation: gRPC's performance comes from the combination of Protobuf's efficient serialization and HTTP/2's efficient transport. A REST API using HTTP/2 would still be sending verbose JSON payloads, missing out on the significant size and parsing-speed advantages of Protobuf. You need both parts for maximum efficiency.

  2. Designed vs. Adapted: gRPC was designed from the ground up to leverage HTTP/2's advanced features. Its entire programming model, including client/server stubs and streaming capabilities, is built around the concept of long-lived connections and bidirectional streams. Most REST frameworks, on the other hand, are designed around the HTTP/1.1 request-response model. While they can be served over HTTP/2, they don't natively expose features like bidirectional streaming in a standardized way.

  3. Streaming Capabilities: gRPC treats streaming as a first-class citizen (client, server, and bidirectional). Replicating this functionality with REST over HTTP/2 is complex and non-standard. You'd essentially be building a custom RPC protocol on top of HTTP/2, whereas gRPC provides this out of the box with strong tooling and cross-language support.

In summary, while using HTTP/2 with REST is an improvement, gRPC provides a more holistic and powerful performance solution because its entire stack—from data format to transport to the programming model—is optimized for high-performance RPC.

Conclusion

You now understand that gRPC is not just "RPC with Protobuf." Its foundation on HTTP/2 is a critical component of its performance story. By leveraging a single, multiplexed connection and aggressively compressing header metadata, gRPC overcomes the fundamental limitations of traditional REST-over-HTTP/1.1 communication.

Key Takeaways:

  • Multiplexing: gRPC uses HTTP/2 to run many concurrent RPCs over a single TCP connection, eliminating head-of-line blocking and reducing connection overhead.
  • Binary Framing: HTTP/2's binary protocol is more efficient to parse than text-based HTTP/1.1 and is the mechanism that enables multiplexing via streams and frames.
  • Header Compression (HPACK): gRPC significantly reduces network overhead by using HPACK to compress repetitive metadata, which is especially beneficial in chatty microservice environments.
  • Combined Advantage: gRPC's performance is the product of both Protobuf's efficient serialization and HTTP/2's efficient transport layer.

Preview of the Next Lesson

We have now covered the two pillars of gRPC performance: the Protobuf data format and the HTTP/2 transport protocol. With this foundational knowledge in place, we are ready to start defining our own services. In the next lesson, you will learn how to write a .proto file to define a complete gRPC service, including unary (simple request/response) and the four powerful streaming communication patterns that HTTP/2 enables.