Why RPC Still Matters Even With HTTP? Deep Dive into TCP, HTTP, and RPC

From TCP

As programmers, to send data from a process on computer A to a process on computer B we typically use sockets, choosing between TCP (reliable) and UDP (unreliable). Most applications use TCP for its reliability. fd = socket(AF_INET, SOCK_STREAM, 0); SOCK_STREAM indicates a byte‑stream transmission, i.e., TCP. After creating a socket we can bind an IP/port with bind() and establish a connection with connect(). Once connected, send() and recv() are used to exchange data.

Pure TCP works for sending and receiving data, but it has problems.

Problems with Pure TCP

TCP has three characteristics: connection‑oriented, reliable, and based on a byte stream. Because the byte stream has no inherent message boundaries, a sequence of 0/1 bits can be concatenated without clear delimiters, leading to the "sticky packet" issue where the receiver cannot distinguish where one message ends and the next begins.

To solve this, applications add custom rules such as a message header that specifies the length of the message body, allowing the receiver to extract complete messages.

The header can also carry other metadata (e.g., compression flag, format), forming a custom protocol.

HTTP and RPC

TCP operates at the transport layer, while HTTP and various RPC protocols are application‑layer protocols built on top of TCP.

HTTP (HyperText Transfer Protocol) is widely used for browser‑server communication. RPC (Remote Procedure Call) is a calling style that abstracts network details so that remote methods can be invoked like local ones. res = localFunc(req) When the function resides on a remote server, the call looks the same: res = remoteFunc(req) Popular RPC implementations include gRPC and Thrift. Although most RPCs use TCP, they can also work over UDP or HTTP.

Differences Between HTTP and RPC

Service Discovery

HTTP relies on DNS to resolve domain names to IP addresses (default port 80). RPC often uses a service registry (e.g., Consul, etcd, Redis) to map service names to IP/port.

Connection Model

HTTP/1.1 keeps a persistent TCP connection (keep‑alive) for multiple requests. RPC also uses persistent connections but typically adds a connection pool to reuse multiple TCP connections efficiently.

Payload

Both HTTP and RPC transmit a header and a body. HTTP headers are verbose and often carry redundant information; the body is usually JSON‑encoded text. RPC can use compact binary formats like protobuf, reducing overhead and improving performance.

Serialization converts structured data to binary; deserialization restores it.

Summary

Raw TCP provides an unbounded byte stream; higher‑level protocols must define message boundaries and formats.

RPC is a calling style, not a single protocol; implementations such as gRPC and Thrift define concrete protocols.

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

HTTP/1.1 is text‑oriented and verbose; RPC with binary serialization (e.g., protobuf) is more efficient for internal microservice communication.

HTTP/2 improves performance and can outperform many RPCs, yet legacy RPCs remain due to historical adoption and specific use‑cases.