HTTP/2 y Protocol Buffers: la base de gRPC

gRPC's speed comes from two pieces: HTTP/2 for transport and Protocol Buffers for serialization. Together they explain why it beats JSON-over-HTTP/1.1.

HTTP/1.1 sends one request per connection at a time; pipelining is fragile and head-of-line blocking forces many connections. That's latency and overhead for chatty APIs.

HTTP/2 multiplexing sends many concurrent streams over one connection. Requests stop blocking each other, and it's what enables gRPC's bidirectional streaming.

HTTP/2 frames data in binary and compresses headers with HPACK. Fewer bytes on the wire plus cheaper parsing means lower latency than text-based HTTP/1.1.

Protocol Buffers is a compact, schema-driven binary format. You define messages once in a .proto file and tooling generates code in many languages.

On the wire each protobuf field carries a tag number, not its name — that's what keeps payloads tiny. Never reuse or change a tag, or you break compatibility.

Protobuf stays small and fast by dropping field names from the payload, using varint encoding for integers, and skipping JSON's whitespace and quotes.

The .proto file is a strong contract shared by client and server. Both generate type-safe code from it, killing a whole class of loosely-typed JSON bugs.

A gRPC call maps cleanly: the method is an HTTP/2 stream, request and response messages are protobuf bytes, and streaming uses multiple frames on that stream.

The trade-offs: binary payloads aren't human-readable, browsers need a grpc-web proxy, and you need codegen tooling. For internal high-throughput services, usually worth it.

Summed up: gRPC wins because HTTP/2 multiplexes efficiently and protobuf serializes compactly, while a shared schema keeps both ends type-safe.

gRPC's two foundations: HTTP/2 brings multiplexed streams and binary framing, while Protocol Buffers give a compact, schema-first format. Together: faster and type-safe.