Why RPC Beats HTTP for Enterprise Services: A Deep Dive

For a long time many people confuse RPC (Remote Procedure Call) with HTTP calls, assuming both simply involve writing a service and invoking it from a client. This article briefly introduces the two C/S architectures and highlights their fundamental difference: RPC operates over TCP/IP, while HTTP services use the HTTP protocol built on top of TCP, making RPC generally more efficient.

OSI Network Seven‑Layer Model

Before comparing RPC and HTTP, it helps to understand the OSI model (often simplified to five layers in practice). The layers from top to bottom are:

Application layer – defines interfaces for communication and data transfer.

Presentation layer – defines data format, encoding, and decoding.

Session layer – manages sessions and logical connections.

Transport layer – handles end‑to‑end data transmission.

Network layer – defines how data moves between devices.

Data link layer – packages network‑layer packets into frames for physical transmission.

Physical layer – transmits binary data over the medium.

In real‑world implementations the presentation and session layers are often merged with the application layer, so the focus is on the application layer (HTTP) and the transport layer (TCP). Understanding this helps explain why RPC can be more efficient than HTTP.

RPC Services

RPC services are described from three perspectives: architecture, synchronous vs asynchronous calls, and popular frameworks.

RPC Architecture

A complete RPC system consists of four core components: Client, Server, Client Stub, and Server Stub. The client initiates calls, the server provides the actual service, the client stub packages requests and sends them over the network, and the server stub unpacks the request and invokes the local method.

Client – the caller of the service.

Server – the provider of the service.

Client stub – stores server address information, packages request parameters into network messages, and sends them remotely.

Server stub – receives messages, unpacks them, and calls the local method.

RPC is commonly used in large enterprises where many systems and complex business lines demand high efficiency. In practice, projects often use Maven to manage dependencies: interfaces are defined in a Java interface, packaged into a JAR, and shared between client and server, reducing client JAR size and improving decoupling and portability.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until the result is returned. Asynchronous calls return immediately, allowing the client to receive results later via callbacks or futures. This is similar to Java's Callable (which returns a Future) versus Runnable (which does not return a result).

Popular RPC Frameworks

Several open‑source RPC frameworks are widely used:

gRPC – Google’s framework built on HTTP/2, supporting many programming languages and using Netty under the hood.

Thrift – Facebook’s cross‑language service framework with an IDL code generator; it abstracts RPC communication but requires learning its IDL.

Dubbo – Alibaba’s mature Java RPC framework with pluggable protocols and serialization; it integrates tightly with Spring and aligns with microservice concepts. (Note: Alibaba now promotes HSF internally.)

HTTP Services

Traditional enterprise development often uses HTTP (RESTful) APIs, which are simple, direct, and easy to develop, especially for small systems with few interfaces. However, in large enterprises with many subsystems, RPC offers advantages such as persistent connections (reducing handshake overhead), built‑in service registries, rich monitoring, and seamless dynamic scaling.

Summary

RPC and HTTP services differ in many ways. RPC is typically suited for large enterprises needing high efficiency, while HTTP is better for smaller projects requiring rapid iteration. Choosing a framework should be based on a thorough evaluation of project requirements rather than simply following market trends.