RPC vs HTTP: Which Wins for Enterprise Services?

RPC is based on TCP/IP while HTTP services are based on HTTP protocol, which runs on top of TCP, making RPC generally more efficient. Below we compare RPC and HTTP services.

OSI Network Seven-Layer Model

Before discussing RPC vs HTTP, it is useful to understand the OSI seven-layer model (commonly simplified to five layers):

Application layer – defines interfaces for communication and data transfer.

Presentation layer – defines data format, encoding, decoding.

Session layer – manages sessions and logical connections.

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

Network layer – defines how data is transferred between devices.

Data link layer – encapsulates network‑layer packets into frames.

Physical layer – transmits binary data.

In practice the presentation and session layers are often merged with the application layer, so the focus is on the application and transport layers: HTTP is an application‑layer protocol, TCP is a transport‑layer protocol. Understanding this helps explain why RPC can be more efficient than HTTP.

RPC Services

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

RPC Architecture

A typical RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub.

Client – the caller of the service.

Server – the provider of the service.

Client Stub – stores server address information, packages request parameters into a network message, and sends it to the server.

Server Stub – receives the message, unpacks it, and invokes the local method.

RPC is widely used in large enterprises where many systems and complex business lines require high efficiency. In Java projects, interfaces are defined, packaged into a JAR, and shared between client and server to reduce client JAR size and decouple components.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until the result is returned. Asynchronous calls return immediately; the client can receive the result later via callbacks or futures. In Java, Callable and Future support asynchronous execution, while Runnable represents fire‑and‑forget calls.

Popular RPC Frameworks

Three widely used open‑source RPC frameworks are highlighted:

gRPC – Google’s framework built on HTTP/2, supporting many 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, integrated with Spring and suitable for micro‑service architectures.

HTTP Services

Traditional HTTP (RESTful) services are simple and convenient for small projects with few interfaces. They use standard HTTP methods and return JSON or XML. However, for large enterprises with many subsystems, RPC offers advantages such as persistent connections, reduced handshake overhead, built‑in service registry, monitoring, and dynamic scaling.

Conclusion

RPC services differ from HTTP services in architecture, performance, and suitability for large‑scale enterprise systems. Choose the framework based on project requirements rather than trends; use RPC when high efficiency and rich management features are needed, and HTTP when rapid development and simplicity are priorities.