Why RPC Still Matters When HTTP Exists: A Deep Dive into TCP, HTTP, and RPC

Starting from TCP

When a programmer needs to send data from a process on computer A to a process on computer B, they typically use sockets. The choice is usually between TCP (reliable) and UDP (unreliable); for most cases with reliability requirements, TCP is the default. fd = socket(AF_INET, SOCK_STREAM, 0); The SOCK_STREAM flag indicates a byte‑stream transmission, i.e., the TCP protocol.

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

Once the connection is established, send() transmits data and recv() receives data.

However, using raw TCP alone has problems.

Problems with Pure TCP

TCP has three key characteristics: connection‑oriented, reliable, and based on a byte‑stream.

The byte‑stream is essentially a two‑way channel of binary data (a long string of 0s and 1s). Because there are no inherent boundaries, the receiver cannot know where one message ends and the next begins. This leads to the classic “sticky‑packet” problem where concatenated messages become ambiguous (e.g., "夏洛特烦恼" could be "夏洛"+"特烦恼" or "夏洛特"+"烦恼").

To solve this, a custom protocol adds a message header that records the length of the message body, allowing the receiver to delimit messages correctly.

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 as application‑layer protocols.

HTTP (HyperText Transfer Protocol) is widely used for browser‑to‑server communication. RPC (Remote Procedure Call) is not a single protocol but a calling style that abstracts network details so that remote methods can be invoked like local ones.

Example of a local function call: res = localFunc(req) Calling a remote method via RPC: res = remoteFunc(req) Popular RPC implementations include gRPC and Thrift. Although many RPC protocols use TCP, they can also operate over UDP or even HTTP.

Differences Between HTTP and RPC

Service Discovery

To contact a server, a client must know its IP and port. HTTP relies on DNS to resolve domain names to IPs (default port 80). RPC often uses a dedicated service‑registry (e.g., Consul, etcd, Redis) to map service names to addresses, though DNS can also be used.

Underlying Connection Model

HTTP/1.1 establishes a TCP connection that is kept alive for multiple requests. RPC also uses long‑living TCP connections, but typically adds a connection pool to reuse many connections under high load.

Transmitted Content

Both protocols send a header and a body. The header often contains the body length. The body carries the actual payload, which must be serialized (e.g., JSON, protobuf) into a binary stream.

HTTP/1.1 was originally designed for textual web pages, so its messages are often verbose, carrying many headers. RPC can use compact serialization formats (e.g., protobuf) and avoid HTTP‑specific concerns like redirects, resulting in better performance for internal micro‑service communication.

Note that modern HTTP/2 improves performance dramatically and even underpins gRPC, but HTTP/2 is relatively recent (2015) and does not fully replace existing RPC implementations.

Summary

Raw TCP can send and receive data but provides no message boundaries; a custom protocol with headers is needed to define those boundaries.

RPC is essentially a calling style; concrete implementations like gRPC or Thrift define the actual protocol, often using TCP but not limited to it.

Historically, HTTP targets browser‑server (B/S) architectures, while RPC targets client‑server (C/S) architectures, though the lines are blurring as many applications support multiple front‑ends.

Internally, many companies still prefer RPC for its performance advantages over HTTP/1.1, even though HTTP/2 can be faster than some RPC protocols.