Why Do We Still Need RPC When HTTP Exists? A Deep Dive into TCP, HTTP, and RPC

Starting from TCP

As programmers, to send data from process A to process B we usually use sockets, choosing between TCP and UDP. TCP is reliable, connection‑oriented, and based on a byte stream. fd = socket(AF_INET,SOCK_STREAM,0); SOCK_STREAM indicates a byte‑stream, i.e., TCP.

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

Once the connection is established we can use send() and recv() to exchange data.

Problems with raw TCP

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

Because there is no boundary, concatenated messages like “夏洛特烦恼” cannot be reliably split into the original parts, leading to the classic “sticky packet” problem.

Therefore a custom protocol must define a message header that specifies the length of the payload, allowing the receiver to extract complete messages.

The header can also carry other metadata such as compression flags or format identifiers; the whole structure is called a protocol.

HTTP and RPC

Both HTTP and RPC are application‑layer protocols built on top of TCP. HTTP is the standard for browser‑to‑server communication, while RPC provides a way to invoke remote methods as if they were local.

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

res = remoteFunc(req)

Popular RPC implementations include gRPC and Thrift. Although most RPCs use TCP, they can also be built on UDP or HTTP.

Key differences

Service discovery

HTTP relies on DNS to resolve domain names to IP addresses. RPC often uses a service registry such as Consul, etcd, or Redis to map service names to IP/port.

Underlying connection

HTTP/1.1 keeps a single TCP connection alive and reuses it. RPC also uses persistent TCP connections but typically adds a connection pool to improve performance.

Transported content

Both protocols transmit a header and a body. The body contains the actual data, which must be serialized (e.g., JSON, protobuf) into a binary form.

HTTP/1.1 was designed mainly for textual web pages, so its messages contain many redundant fields, making it verbose.

Custom RPC protocols can use compact binary serialization and omit unnecessary fields, resulting in better performance, especially for internal micro‑service communication.

HTTP/2 improves on HTTP/1.1 and can be faster than many RPCs, but it was introduced only in 2015, whereas many RPC systems have been in use for decades.

Summary

Raw TCP provides a boundary‑less byte stream; higher‑level protocols must define message formats to delimit messages.

RPC is not a protocol itself but a remote‑call paradigm; concrete implementations (gRPC, Thrift) define the actual protocol.

Historically HTTP served browser‑server (B/S) architectures, RPC served client‑server (C/S) internal services, but the lines are blurring.

RPC predates HTTP and often offers better performance for internal micro‑services.

HTTP/2 brings significant optimizations, yet many companies continue to use established RPC solutions.