gRPC over HTTP/2 Visual Walkthrough

gRPC is a high-performance Remote Procedure Call (RPC) framework developed by Google.

Mental Model

Instead of utilizing traditional HTTP JSON payloads over REST, gRPC defines APIs using Protocol Buffers (Protobuf) contracts and transports them over HTTP/2 connections. The client application initiates a standard method call, which is intercepted by an auto-generated client stub. This stub serializes the typed request into binary Protobuf format and passes it to the HTTP/2 layer, which wraps it in binary frames (HEADERS and DATA). These frames are multiplexed over a single TCP connection, allowing multiple concurrent requests. At the server, the process is reversed: the server skeleton deserializes the binary payload and invokes the server-side business logic, returning results via response frames and trailers.

Components and Why They Exist

Client Application / Local Code

The entry point of the RPC call on the client side. Calls a local-looking method defined in the generated stub as if it were running locally in-process. In the demo, watch how the call triggers serialization and stream queuing.

Client Stub (Auto-Generated)

Hides network complexity and protocol details from the client code. Marshals typed parameters into Protobuf bytes, sets deadlines, and interacts with the HTTP/2 layer. In the demo, watch the Stub serialize the request and handle status errors (like DEADLINE_EXCEEDED).

HTTP/2 Transport Layer (Client & Server)

Manages TCP connections and carries data efficiently. Implements binary framing (HEADERS and DATA), manages multiplexed streams, and compresses headers using HPACK. In the demo, observe how HEADERS and DATA frames are generated and how HPACK compresses repeated headers.

Network Pipe / Connection

The physical or virtual network link between client and server. Transports binary frames as packet particles over TCP/IP. In the demo, observe packet dots moving along the connection path.

Server Skeleton / Dispatcher

The auto-generated server-side counterpart to the client stub. Demultiplexes incoming HTTP/2 streams, parses Protobuf bytes back into typed objects, and dispatches the call to the actual implementation. In the demo, watch it receive the DATA frames, unmarshal them, and forward the request to the server handler.

Server Handler (Service Implementation)

The custom business logic written by the developer on the server. Executes database reads, computations, or further RPCs, and returns the response. In the demo, watch it process the request and trigger the response serialization.

Edge Cases and Misconceptions

• Misconception: gRPC is just a faster REST: REST is a resource-oriented architectural style, whereas gRPC is a service-oriented method-call framework. They have different interface contract definitions and wire protocols.
• Misconception: A successful HTTP status means a successful RPC: In gRPC, a connection might return an HTTP status of 200 OK, but the actual method call could fail. The true gRPC status is returned in the grpc-status trailer.
• Edge Case: Deadline Exceeded and Resource Leaks: If a client times out (expires its deadline), it cancels the stream. If the server handler does not actively check for cancellation, it might continue processing the cancelled request, wasting server resources.
• Edge Case: HOL Blocking at the TCP Level: While HTTP/2 multiplexing solves Head-of-Line (HOL) blocking at the HTTP stream level, packet loss at the TCP level will still block all multiplexed streams on that connection until the lost packet is retransmitted.