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

Starting from TCP

As a programmer, when we need to send data from a process on computer A to a process on computer B, we typically use socket programming. The two main options are TCP and UDP; TCP is reliable while UDP is not. For most cases that require reliability, developers choose TCP.

<code>fd = socket(AF_INET,SOCK_STREAM,0);</code>

SOCK_STREAM indicates a byte‑stream transmission, i.e., the TCP protocol.

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

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

A pure TCP connection can send and receive data, but it has inherent problems.

Problems with Pure TCP

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

The byte‑stream can be seen as a two‑way channel flowing binary 01 strings without any boundaries, making it impossible to know where one message ends and the next begins.

This lack of boundaries leads to the sticky‑packet problem, where concatenated messages become ambiguous (e.g., "夏洛特烦恼" could be interpreted as "夏洛"+"特烦恼" or "夏洛特"+"烦恼").

To solve this, a custom protocol must define a message header that specifies the length of the complete packet, allowing the receiver to extract each message body correctly.

The header can also carry additional information such as compression flags or format identifiers, forming a protocol.

Based on TCP, many higher‑level protocols have been created, including HTTP and various RPC protocols.

HTTP and RPC

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

HTTP (HyperText Transfer Protocol) is widely used for web browsing.

RPC (Remote Procedure Call) is a calling style rather than a specific protocol; implementations such as gRPC and Thrift are concrete protocols that enable RPC.

Example of a local function call:

<code>res = localFunc(req)</code>

And a remote function call that hides network details:

<code>res = remoteFunc(req)</code>

Many RPC protocols use TCP, but they can also operate over UDP or HTTP.

Why Both HTTP and RPC Exist

Browsers need a universal standard to communicate with any server, so HTTP serves the browser/server (b/s) architecture. RPC is often used in client/server (c/s) internal services where a custom protocol suffices.

In modern applications the distinction blurs: external APIs often use HTTP, while internal microservices use RPC for efficiency.

Differences Between HTTP and RPC

Service Discovery

HTTP relies on DNS to resolve domain names to IP addresses. RPC typically uses service registries such as Consul, etcd, or Redis to discover service endpoints.

Underlying Connection

Both use long‑lived TCP connections; RPC often adds a connection pool to reuse multiple connections under high load.

Transported Content

Both protocols consist of a header and a body. HTTP1.1 typically uses JSON for serialization, which can be verbose. RPC can use more compact formats like protobuf, reducing overhead.

HTTP2 improves performance and many RPC frameworks (e.g., gRPC) are built on top of HTTP2.

Summary

Pure TCP provides a boundary‑less byte stream; higher‑level protocols define message formats to establish boundaries.

RPC is fundamentally a calling style; specific implementations like gRPC and Thrift are protocols that enable remote calls, not necessarily based on TCP.

Historically HTTP served b/s architecture and RPC served c/s, but today both are used together: HTTP for external APIs, RPC for internal microservice communication.

RPC predates HTTP and often offers better performance, so it remains common in internal systems.

HTTP2 brings significant performance gains and many RPC frameworks leverage it, yet it does not replace RPC entirely.

Both HTTP and RPC follow a request‑response model, which can be limiting for scenarios where the server needs to push messages to the client.

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