How gRPC Uses HTTP/2 and Transitions to HTTP/3

This article explores how the gRPC framework leverages the core features of HTTP/2 over TCP for high-performance communication, examines the network-level limitations inherent to this architecture, and explains how gRPC is adapting to HTTP/3 over QUIC (UDP) to achieve lower latency, zero-head-of-line blocking, and resilient connection migration.

How gRPC Uses HTTP/2 (over TCP)

gRPC is designed around the capabilities of HTTP/2, using it as its primary transport layer to provide efficient, low-overhead Remote Procedure Calls (RPCs).

• Binary Framing and Protocol Buffers: gRPC serializes structured data into Protocol Buffers (protobuf) and transmits these payloads within HTTP/2 binary DATA frames. Unlike HTTP/1.1’s plain-text model, HTTP/2’s binary framing enables lightweight, fast parsing on both client and server.
• Multiplexing over a Single TCP Connection: HTTP/2 allows multiple concurrent RPC calls (streams) to be interleaved across a single underlying TCP connection. Each RPC is assigned a unique Stream ID, allowing clients and servers to send and receive messages asynchronously without opening multiple sockets.
• Streaming Semantics: HTTP/2’s bidirectional stream capability maps directly to gRPC’s communication patterns:
  • Unary (single request, single response)
  • Server-streaming (single request, stream of responses)
  • Client-streaming (stream of requests, single response)
  • Bidirectional streaming (both sides send streams of messages independently)
• Headers, Trailers, and HPACK Compression: gRPC relies heavily on HTTP/2 metadata. Request parameters and authentication tokens are sent via HTTP/2 headers using HPACK compression to minimize bandwidth. Crucially, gRPC uses HTTP/2 Trailers (headers sent after the payload data) to deliver execution status codes (grpc-status) and error details (grpc-message) without tearing down the stream prematurely.

Limitations of HTTP/2 over TCP

While HTTP/2 is a substantial improvement over HTTP/1.1, running over TCP introduces bottlenecks in modern, distributed networks:

• TCP Head-of-Line (HoL) Blocking: TCP guarantees in-order byte delivery. If a single packet is dropped, the entire TCP connection is stalled while waiting for retransmission. Consequently, all multiplexed gRPC streams on that connection freeze, even if the dropped packet only belonged to one specific RPC.
• Connection Handshake Latency: Establishing a secure gRPC connection over TCP requires separate TCP (3-way handshake) and TLS handshakes, introducing 2 to 3 round-trip times (RTT) of latency before any RPC data can be transferred.
• Lack of Connection Migration: TCP connections are bound to a 4-tuple (source IP, source port, destination IP, destination port). If a client switches networks (such as switching from Wi-Fi to 5G), the connection drops, terminating all active gRPC streams and requiring full re-authentication and reconnection.

How gRPC Transitions to HTTP/3 (over UDP)

HTTP/3 replaces TCP with QUIC, an encrypted transport protocol implemented on top of UDP in user space. Transitioning gRPC to HTTP/3 addresses the architectural bottlenecks of HTTP/2 while preserving gRPC’s high-level semantics.

+-----------------------------------+       +-----------------------------------+
|               gRPC                |       |               gRPC                |
+-----------------------------------+       +-----------------------------------+
|              HTTP/2               |  -->  |              HTTP/3               |
+-----------------------------------+       +-----------------------------------+
|             TLS 1.2/1.3           |       |           QUIC (Crypto)           |
+-----------------------------------+       +-----------------------------------+
|                TCP                |       |                UDP                |
+-----------------------------------+       +-----------------------------------+

Key Architectural Improvements

• Elimination of Stream-Level HoL Blocking: QUIC manages packet loss per-stream rather than per-connection. If a packet is lost in Stream A, only Stream A pauses for retransmission; Stream B, Stream C, and other concurrent gRPC calls continue processing without interruption.
• Faster Connection Establishment (0-RTT / 1-RTT): QUIC integrates cryptographic handshakes (TLS 1.3) directly into the transport layer. Initial connections complete in 1 RTT, and repeated connections support 0-RTT, allowing gRPC to send RPC payloads immediately in the initial flight of packets.
• Connection Migration: QUIC identifies connections via unique Connection IDs rather than IP/port tuples. If a client device changes networks, gRPC streams remain intact and continue transmitting data without requiring a reconnect cycle or failing long-running streaming calls.
• QPACK Header Compression: HTTP/3 replaces HPACK with QPACK, which accommodates out-of-order delivery of headers across streams without reintroducing head-of-line blocking.

Implementation and Semantic Compatibility

Because HTTP/3 retains the core abstractions of HTTP/2—specifically streams, frames, headers, and trailers—gRPC’s application programming interface (API) and core behaviors remain identical.

To run over HTTP/3: 1. Transport Layer Substitution: gRPC core libraries integrate QUIC transport implementations (such as quiche, msquic, or Cronet) beneath the gRPC wire protocol layer. 2. Framing Mapping: gRPC maps its protobuf payloads directly into HTTP/3 DATA frames and continues to communicate RPC termination and status via HTTP/3 trailing headers. 3. Transport Discovery: Clients discover HTTP/3 capabilities on the server using the Alt-Svc (Alternative Services) header or DNS HTTPS resource records, enabling a fallback to HTTP/2 if UDP/QUIC traffic is filtered or blocked by intermediate firewalls.