Why Use RPC When HTTP Exists? Unpacking TCP, HTTP, and RPC Differences

1. TCP basics

To exchange data between a process on computer A and a process on computer B, a socket is created. The common transport choices are TCP (reliable, connection‑oriented byte stream) and UDP (unreliable). TCP is used for most application‑level protocols. fd = socket(AF_INET, SOCK_STREAM, 0); After creating the socket, bind() and connect() establish a connection, and send() / recv() transfer bytes.

2. Sticky‑packet problem in raw TCP

TCP provides a continuous byte stream without inherent message boundaries. When two logical messages are sent back‑to‑back, the receiver may read them as a single concatenated chunk, making it impossible to know where one message ends and the next begins. This is known as the sticky‑packet (or packet‑framing) problem.

Typical solution: define a custom protocol layer on top of TCP that prefixes each payload with a fixed‑size header containing the length of the message body. The receiver reads the header, extracts the length, then reads exactly that many bytes to obtain a complete message.

3. HTTP and RPC built on TCP

Both HTTP (HyperText Transfer Protocol) and RPC (Remote Procedure Call) are application‑layer protocols that use TCP as their transport by default.

HTTP is the standard protocol for browsers to request web resources. An HTTP request/response consists of a textual header block followed by an optional body (often JSON, HTML, etc.).

RPC is a calling style that makes a remote method appear like a local function call. Implementations such as gRPC or Apache Thrift define their own wire formats (often protobuf) and may use TCP, UDP, or HTTP as the underlying transport.

res = localFunc(req)   // local call
res = remoteFunc(req) // RPC call

4. Differences between HTTP and RPC

4.1 Service discovery

HTTP clients resolve a domain name to an IP address via DNS and connect to the default port (80 for HTTP, 443 for HTTPS). RPC frameworks often rely on a dedicated service‑registry (e.g., Consul, etcd, Redis) that maps logical service names to host/port pairs.

4.2 Connection handling

HTTP/1.1 keeps a single TCP connection alive and reuses it for multiple requests (keep‑alive). Many RPC libraries also use a connection pool: a set of persistent TCP connections is created in advance, borrowed for each request, and returned to the pool after use.

4.3 Payload format

HTTP headers are textual and verbose, containing many fields for compatibility with browsers. RPC payloads usually employ compact binary serialization formats such as Protocol Buffers, reducing overhead and improving performance.

4.4 Evolution

HTTP/2 (released 2015) adds multiplexing and header compression, narrowing the performance gap with many RPC frameworks. Nevertheless, legacy RPC systems remain common in internal micro‑service communication because they predate HTTP/2 and give tighter control over serialization and latency.

5. Summary

Raw TCP provides a reliable byte stream but lacks message boundaries; a custom protocol layer (e.g., length‑prefixed header) is required to delimit messages.

RPC is a calling style; concrete implementations like gRPC or Thrift define their own wire formats (often protobuf) and may use TCP, UDP, or HTTP as transport.

HTTP is primarily designed for browser‑to‑server (B/S) interactions, while RPC is historically used for client‑server (C/S) internal services. Modern systems often blend both.

Both protocols can run over TCP; RPC can also be built on UDP or HTTP.

HTTP/2 introduces multiplexing and header compression, achieving performance comparable to many RPC solutions, yet many organizations continue to use established RPC frameworks for internal communication.