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

TCP Basics

Creating a TCP socket in C (or similar) uses socket(AF_INET, SOCK_STREAM, 0). After bind() and connect(), data is exchanged with send() and recv(). TCP provides a reliable, connection‑oriented byte‑stream.

Because the stream has no intrinsic message boundaries, the receiver cannot know where one logical message ends. This “sticky‑packet” problem is solved by defining an application‑layer header that contains the payload length (and optional flags such as compression). The receiver reads the length, extracts exactly that many bytes as the message body, then processes the next header.

From TCP to Application‑Layer Protocols

HTTP and RPC are both built on top of TCP (or other transports) and define different message formats.

RPC as a calling style

RPC lets a client invoke a remote function as if it were local:

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

Popular implementations include gRPC and Thrift . Although many RPC frameworks use TCP, they can also run over UDP or HTTP.

Why both HTTP and RPC exist

Historically HTTP was created for browser‑to‑server (B/S) interactions, while RPC was used for internal client‑server (C/S) services. Modern systems often expose public APIs via HTTP and use RPC for internal micro‑service communication.

Key Technical Differences

Service discovery

HTTP relies on DNS to resolve domain names (default port 80). RPC systems typically use a service‑registry such as Consul, Etcd, Nacos, ZooKeeper, or Redis to map service names to IP/port.

Connection handling

HTTP/1.1 keeps a single TCP connection alive (keep‑alive) for multiple requests. RPC frameworks also maintain long‑lived connections and often add a connection pool to reuse many sockets efficiently.

Message format

Both protocols transmit a header and a body. The header usually carries the body length. The body must be serialized. Common formats are JSON (text‑based) and Protocol Buffers (binary).

HTTP/1.1 typically uses JSON, which adds verbosity in both headers and body. RPC can use compact binary formats like Protobuf, reducing overhead and improving performance for internal traffic.

Transport evolution

HTTP/2 (released 2015) multiplexes streams over a single TCP connection, adds header compression, and can match or exceed the performance of many RPC implementations. gRPC is built on top of HTTP/2.

Practical Takeaways

Raw TCP provides a reliable byte stream but lacks message boundaries; custom protocols add a length header to delimit messages.

RPC is a calling paradigm; concrete protocols such as gRPC or Thrift define the wire format and transport.

HTTP is the de‑facto standard for external client‑server communication; RPC is preferred for internal micro‑service calls where low latency and compact payloads matter.

Both HTTP/2 and modern RPC frameworks achieve high performance; the choice depends on ecosystem, tooling, and deployment constraints.