# HTTP/2 and Protocol Buffers — gRPC

Source: https://www.skillbyai.com/en/grpc/f-transport

> Why gRPC is fast.

## Binary messages over multiplexed streams

gRPC runs over **HTTP/2**, which multiplexes many concurrent calls over one TCP connection, compresses headers, and supports streaming in both directions. Messages are encoded with **Protocol Buffers (protobuf)**, a compact binary format that is smaller and faster to parse than JSON and is generated from the schema. Each call maps to an HTTP/2 request: the path is `/package.Service/Method`, metadata travels as headers, and the status is sent in trailers.

## One unary call on the wire

Simplified view of the HTTP/2 frames.

```text
HEADERS  :method POST
         :path /shop.v1.OrderService/GetOrder
         content-type: application/grpc
         grpc-timeout: 2S
         authorization: Bearer <token>
DATA     <5-byte prefix: compressed flag + length><protobuf-encoded GetOrderRequest>

<- HEADERS :status 200, content-type: application/grpc
<- DATA    <prefix><protobuf-encoded Order>
<- TRAILERS grpc-status: 0  (OK)
```

## Reuse channels

Creating a channel (connection) per call wastes the main benefit of HTTP/2; create channels once and share them.

**Quiz:** Where does gRPC send the final status of a call?

- [x] In HTTP/2 trailers (grpc-status)
- [ ] In the URL
- [ ] In the first request header only
- [ ] In a separate TCP connection

*Answer:* In HTTP/2 trailers (grpc-status). Status arrives after the response messages.