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

From TCP Talk

As a programmer, when we need to send data from a process on computer A to a process on computer B, we typically use sockets in code. The choice is usually between TCP (reliable) and UDP (unreliable); for most cases we pick TCP.

fd = socket(AF_INET,SOCK_STREAM,0);

SOCK_STREAM

indicates a byte‑stream transmission, i.e., the TCP protocol.

After creating a socket we can bind an IP/port with bind() and establish a connection with connect().

Once the connection is established, send() transmits data and recv() receives it. A raw TCP connection can exchange data, but it has problems.

Problems with Pure TCP

TCP has three key characteristics: connection‑oriented, reliable, and based on a byte stream. The byte stream is just a continuous flow of binary 0/1 data without any inherent message boundaries.

Because there are no boundaries, concatenated messages like "夏洛" and "特烦恼" become indistinguishable as "夏洛特烦恼" on the receiving side.

This is the classic "sticky‑packet" problem. To solve it, each message must be wrapped with a custom protocol that defines a message header (including the length of the body) and a message body.

The header can also carry other metadata such as compression flags or format identifiers, forming a complete application‑layer protocol.

HTTP and RPC

Both HTTP and various RPC protocols are built on top of TCP, which resides in the transport layer of the OSI model.

HTTP (HyperText Transfer Protocol) is an application‑layer protocol widely used by browsers to fetch web pages. RPC (Remote Procedure Call) is not a concrete protocol but a calling style that makes remote methods look like local ones.

Example of a local call: res = localFunc(req) Example of a remote call using RPC:

res = remoteFunc(req)

Popular RPC implementations such as gRPC and thrift typically use TCP, but they can also run over UDP or HTTP.

Why Have Both HTTP and RPC?

Browsers need a universal standard to communicate with any server on the Internet, which is why HTTP became the de‑facto protocol for the browser/server (B/S) model. In contrast, many client‑server (C/S) applications can use a proprietary RPC protocol because they only talk to their own backend.

Modern software often supports multiple front‑ends (web, mobile, PC). Using HTTP for external communication allows a single server stack, while internal micro‑service communication frequently relies on RPC for efficiency.

Differences Between HTTP and RPC

Service Discovery

HTTP resolves hostnames via DNS to obtain IP and port. RPC typically uses a service registry (e.g., Consul, etcd, Redis) or DNS to discover service endpoints.

Underlying Connection

HTTP/1.1 keeps a persistent TCP connection (keep‑alive). RPC also uses long‑living TCP connections, often with a connection pool to reuse sockets efficiently.

Payload Content

Both protocols transmit a header and a body. HTTP headers are verbose and often carry textual metadata; bodies are usually JSON strings. RPC can use compact binary serialization formats such as Protobuf, reducing overhead.

Because RPC protocols are more customizable, they often achieve better performance than HTTP/1.1. However, HTTP/2, introduced in 2015, brings many optimizations (multiplexing, header compression) that can make HTTP faster than many RPC implementations; gRPC even runs on top of HTTP/2.

Summary

Raw TCP can send and receive data but provides no message boundaries; a custom protocol must define headers to delimit messages.

RPC is essentially a calling style; concrete implementations like gRPC and Thrift are protocols that enable remote method invocation, often over TCP but not limited to it.

Historically, HTTP served the browser/server (B/S) model, while RPC served client/server (C/S) scenarios; today the distinction blurs as many applications support both web and native clients.

RPC predates HTTP and generally offers better raw performance, which is why many internal micro‑service architectures still prefer RPC.

HTTP/2 improves upon HTTP/1.1 and can outperform many RPC protocols, yet its recent emergence means it coexists with, rather than replaces, RPC.