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 client application is the entry point of the RPC call on the caller side. It invokes a local-looking method defined on the generated stub as if the method were running in-process, kicking off request serialization and stream queuing on the client card.

Client Stub (Auto-Generated)

The auto-generated client stub hides network complexity and wire protocol details from application code. It marshals typed parameters into Protobuf bytes, attaches deadlines, and passes the call to the HTTP/2 transport layer, surfacing status errors such as DEADLINE_EXCEEDED when a call times out.

HTTP/2 Transport Layer (Client & Server)

The HTTP/2 transport layer manages the underlying TCP connection and carries RPC data efficiently. It frames messages into binary HEADERS and DATA blocks, multiplexes concurrent streams, and compresses repeated metadata headers through the dynamic HPACK table.

Network Pipe / Connection

The network pipe is the physical or virtual link between the client and server. This connection transports binary HTTP/2 frames as packet particles over a single multiplexed TCP/IP socket.

Server Skeleton / Dispatcher

The server skeleton is the auto-generated server-side counterpart to the client stub. It demultiplexes incoming HTTP/2 streams, parses Protobuf bytes back into typed request objects, and forwards the unmarshaled payload to the matching server handler.

Server Handler (Service Implementation)

The server handler contains the custom business logic written by the service developer. It executes database reads, computations, or downstream RPCs and returns a typed response object together with the final grpc-status trailer frame.

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.