gRPC How HTTP/2 Works

gRPC runs entirely on HTTP/2. Understanding HTTP/2 explains why gRPC is fast and why it supports features that HTTP/1.1 cannot offer. This topic breaks down what HTTP/2 does differently — using plain analogies and diagrams.

The Problem with HTTP/1.1

HTTP/1.1 handles one request at a time per connection. If your browser or app sends three requests, the second request waits for the first to finish. The third waits for the second. This is called head-of-line blocking.

HTTP/1.1 — One lane, cars must wait in order:
─────────────────────────────────────────────
Connection 1: [Request A] → wait → [Request B] → wait → [Request C]

Time wasted waiting: significant
Fix used in HTTP/1.1: open multiple connections (6 per browser tab)
Problem: each connection is expensive (handshake, memory)

What HTTP/2 Does Instead

HTTP/2 opens one connection and sends many requests over it simultaneously. Each request travels in its own numbered stream inside that single connection.

HTTP/2 — One highway, many lanes:
─────────────────────────────────────────────
                   ┌─ Stream 1: Request A ──►
One TCP Connection ├─ Stream 3: Request B ──►  Server
                   └─ Stream 5: Request C ──►
                   ◄─ Stream 2: Response A
                   ◄─ Stream 4: Response B
                   ◄─ Stream 6: Response C

Five Core HTTP/2 Features gRPC Uses

1. Multiplexing

Multiple gRPC calls travel over one TCP connection at the same time. A slow call does not block a fast one.

Without Multiplexing (HTTP/1.1):
Call 1: ████████████████ (200ms)
Call 2:                 ████ (100ms — had to wait)
Call 3:                     ████ (100ms — had to wait)
Total: 400ms

With Multiplexing (HTTP/2):
Call 1: ████████████████ (200ms)
Call 2: ████             (100ms — runs in parallel)
Call 3: ████             (100ms — runs in parallel)
Total: 200ms (limited by the slowest call)

2. Header Compression (HPACK)

HTTP headers repeat on every request. In HTTP/1.1, the same headers (like Authorization and Content-Type) are sent in full every single time.

HTTP/2 uses a compression algorithm called HPACK. It builds a shared dictionary of headers already sent. Repeated headers are replaced with a short index number.

HTTP/1.1 — Full headers on every request:
  Request 1: Authorization: Bearer eyJhbGciOi... (500 bytes)
  Request 2: Authorization: Bearer eyJhbGciOi... (500 bytes again)
  Request 3: Authorization: Bearer eyJhbGciOi... (500 bytes again)

HTTP/2 with HPACK:
  Request 1: Authorization: Bearer eyJhbGciOi... (500 bytes — stored)
  Request 2: [index:42]  (2 bytes — refers to stored header)
  Request 3: [index:42]  (2 bytes — refers to stored header)

3. Binary Framing

HTTP/1.1 sends text. HTTP/2 sends binary frames. Text is easy for humans to read but slow for computers to parse. Binary frames skip the text-parsing step entirely.

HTTP/1.1 text frame (server must parse character by character):
  "Content-Length: 128\r\nContent-Type: application/json\r\n\r\n"

HTTP/2 binary frame (server reads fixed-size bytes directly):
  [frame length][frame type][flags][stream id][payload]
  Each part is a known number of bytes — no parsing needed.

4. Server Push

HTTP/2 lets the server send data the client has not asked for yet. gRPC uses this concept for server-side streaming — the server keeps sending updates until the stream closes.

Server Push example in gRPC:
  Client: "Give me live stock prices for AAPL"
  Server: [sends AAPL price every second without client re-requesting]
  Server: $182.00 → $182.45 → $181.90 → $183.10 → ...

5. Stream Prioritisation

HTTP/2 lets callers assign a priority to each stream. A health-check call can be given lower priority than a user-facing payment call. The server sends higher-priority frames first when bandwidth is limited.

Priority queue on one connection:
  Stream 5 (Payment) — Priority: HIGH   ──► processed first
  Stream 7 (Log export) — Priority: LOW ──► processed when idle

How gRPC Maps to HTTP/2

┌─────────────────────────────────────────────────────────┐
│                gRPC over HTTP/2                         │
│                                                         │
│  gRPC Request   →  HTTP/2 HEADERS frame (metadata)      │
│                 →  HTTP/2 DATA frame (protobuf bytes)   │
│                                                         │
│  gRPC Response  ←  HTTP/2 HEADERS frame (status)        │
│                 ←  HTTP/2 DATA frame (protobuf bytes)   │
│                 ←  HTTP/2 HEADERS frame (trailers)      │
│                                                         │
│  Each gRPC call = One HTTP/2 stream                     │
│  Many calls     = Many streams on one TCP connection    │
└─────────────────────────────────────────────────────────┘

gRPC-Specific HTTP/2 Headers

gRPC adds its own headers on top of HTTP/2. These headers tell the server what kind of content it is receiving.

Key gRPC headers sent with every request:
  :method        = POST
  :path          = /package.ServiceName/MethodName
  :scheme        = https
  content-type   = application/grpc
  grpc-encoding  = gzip  (if compression is on)
  grpc-timeout   = 5S    (5-second deadline)

What Happens at Connection Close

gRPC keeps the HTTP/2 connection alive for as long as possible. When the connection closes (server restart, network failure), the gRPC client retries the connection automatically using a configurable backoff strategy — waiting 1 second, then 2 seconds, then 4 seconds, and so on.

Summary

HTTP/2 gives gRPC multiplexing (many calls at once), header compression (smaller payloads), binary framing (faster parsing), server push (streaming), and priority control. These features together make gRPC far faster and more efficient than anything built on HTTP/1.1 with text-based JSON.