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

Starting from TCP

When a program needs to send data from a process on computer A to a process on computer B, it typically uses sockets. The two main transport options are TCP (reliable) and UDP (unreliable). For most cases that require reliability, TCP is the default choice. fd = socket(AF_INET, SOCK_STREAM, 0); Here SOCK_STREAM indicates a byte‑stream transmission, i.e., TCP. After creating a socket, you can bind an IP/port with bind() and establish a connection with connect(). Once the connection is established, send() and recv() are used to exchange data.

Problems with Using Bare TCP

TCP provides three key characteristics: connection‑oriented, reliable, and byte‑stream based. The byte‑stream nature means the data is just a continuous sequence of 0/1 bits without any inherent message boundaries. Consequently, when sending two separate logical messages, the receiver may see them concatenated and cannot tell where one ends and the next begins—this is the classic "sticky packet" problem.

To solve this, developers add a custom protocol on top of TCP, typically by prefixing each message with a header that specifies the length of the message body. The header can also carry other metadata such as compression flags or format identifiers. This defines clear message boundaries and allows the receiver to parse the stream correctly.

From TCP to HTTP and RPC

Both HTTP and RPC are application‑layer protocols that run over TCP (or sometimes UDP/HTTP). HTTP was created in the 1990s to provide a universal standard for browser‑to‑server communication (b/s architecture). RPC, originating in the 1980s, offers a way to invoke remote methods as if they were local, abstracting away network details (c/s architecture).

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 define their own message formats, often using compact binary serialization (e.g., protobuf) for better performance.

Key Differences Between HTTP and RPC

Service Discovery

HTTP relies on DNS to resolve domain names to IP addresses, typically using port 80. RPC systems often use a dedicated service‑registry (e.g., Consul, etcd, Redis) to map service names to IP/port, though DNS can also be used.

Connection Management

HTTP/1.1 establishes a TCP connection that is kept alive and reused for multiple requests. RPC also uses persistent TCP connections, but many implementations add a connection pool to reuse multiple connections efficiently under high load.

Payload Content

Both protocols transmit a header and a body. HTTP headers are verbose and often include fields like Content-Type. The body is usually JSON‑encoded text, which adds overhead. RPC can use compact binary formats (e.g., protobuf) and omit unnecessary metadata, resulting in smaller payloads and higher performance.

Performance Considerations

Because RPC messages are more compact and tailored to specific use cases, they typically achieve lower latency and higher throughput than HTTP/1.1. However, HTTP/2 (released in 2015) introduces multiplexing, header compression, and binary framing, narrowing the performance gap; in fact, gRPC is built on top of HTTP/2.

Summary

Raw TCP can transmit data but lacks message boundaries; a custom protocol with headers is required to define those boundaries.

RPC is not a single protocol but a calling style; concrete implementations (gRPC, Thrift) define the actual wire format, often over TCP.

Historically, HTTP served browser‑to‑server (b/s) communication, while RPC served internal service‑to‑service (c/s) calls, but the distinction is blurring as many systems use both.

RPC predates HTTP and generally offers better raw performance for internal micro‑service communication.

HTTP/2 brings significant performance improvements and can outperform many RPC solutions, yet legacy RPC systems remain in use due to historical adoption.

Reference: https://www.zhihu.com/question/41609070