Understanding RPC vs HTTP: Protocol Layers, Serialization, and Network Communication

RPC (Remote Procedure Call) and HTTP (HyperText Transfer Protocol) are both request‑response protocols used for communication in distributed systems, but they differ in origin, design philosophy, efficiency, and typical usage.

RPC was coined by Bruce Jay Nelson in 1981, while HTTP emerged around 1990. Both serve as application‑layer communication protocols, yet RPC frameworks often provide custom serialization, service discovery, and load‑balancing, whereas HTTP offers a universal, widely supported standard.

The core of any request flow consists of three layers: serialization , protocol , and network communication . The article compares these layers for RPC and HTTP.

Serialization (Encoding)

Serialization converts in‑memory data structures (e.g., Java classes, Go structs) into binary form for transmission; deserialization performs the reverse. HTTP/1.1 typically uses JSON, which is human‑readable but incurs higher overhead and lacks strong typing. Custom RPC protocols usually adopt Thrift or Protobuf, offering smaller payloads and faster (de)serialization.

Aspect

JSON (HTTP/1.1)

Protobuf (gRPC)

Advantages

Good readability, low learning curve

Compact size, high performance

Disadvantages

Large space overhead, no type information, slower parsing

Binary, not human‑readable

Suitable Scenarios

Small data transfers where readability matters

High‑performance, large‑scale services

Protocol Layer

Beyond raw bytes, a protocol defines message boundaries to avoid issues like packet sticking. HTTP is flexible and universally supported but carries many browser‑oriented fields that add overhead. Custom RPC protocols (e.g., Kitex TTHeader) allow tailored fields, reducing payload size and improving efficiency, though they may lack universal support.

Network Communication Layer

HTTP typically uses short connections with a three‑handshake TCP setup, optionally upgraded to keep‑alive or HTTP/2 multiplexing. RPC frameworks often maintain a TCP connection pool, reusing connections to avoid repeated handshakes, supporting short/long connections, multiplexing, and health‑check heartbeats.

While HTTP’s ubiquity makes it ideal for external services and front‑end APIs, internal micro‑services often benefit from RPC’s higher performance, custom load‑balancing, retries, and traffic control.

In practice, many teams combine the two: using HTTP as the transport while applying Protobuf or Thrift for serialization to gain performance without sacrificing compatibility with browsers and existing tooling.

Overall, RPC provides advantages in serialization, protocol customization, and network efficiency, but HTTP remains dominant due to its widespread ecosystem and browser support.