Why RPC Beats HTTP: Architecture, Sync/Async Calls, and Top Frameworks

OSI Seven‑Layer Model

Before comparing RPC and HTTP, it is useful to understand the OSI seven‑layer network model (often simplified to five layers in practice). From top to bottom the layers are:

Application layer – defines interfaces for communication and data transfer.

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

Session layer – manages sessions and logical connections.

Transport layer – handles end‑to‑end data transmission (e.g., TCP).

Network layer – determines routing of data between devices.

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

Physical layer – transmits raw binary bits.

In most real‑world applications the presentation and session layers are merged with the application layer, so the focus is on the application and transport layers: HTTP operates at the application layer, while TCP works at the transport layer.

RPC Services

Remote Procedure Call (RPC) is a communication paradigm widely used in large enterprises because it can provide higher efficiency than plain HTTP.

RPC Architecture

An RPC system consists of four core components:

Client – the caller of the remote service.

Server – the provider of the service implementation.

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

Server stub – receives the message, unmarshals it, and invokes the local method.

Synchronous vs Asynchronous Calls

Synchronous RPC blocks the client until the remote method finishes and returns a result. Asynchronous RPC returns immediately; the client can later receive the result via a callback, a Future object, or by polling. In Java, Callable with Future is used for asynchronous calls, while Runnable represents fire‑and‑forget operations.

Popular RPC Frameworks

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

Thrift – Facebook’s cross‑language service framework that generates code from an IDL; it abstracts the underlying RPC transport but requires learning its IDL.

Dubbo – Alibaba’s widely adopted Java RPC framework with pluggable protocols and serialization, tightly integrated with Spring and suitable for micro‑service architectures.

HTTP Services

HTTP (often in a RESTful style) is simple and convenient for small‑scale or low‑traffic scenarios. A typical request looks like:

POST http://www.httpexample.com/restful/buyer/info/share

Responses are usually JSON or XML, which the client parses. However, for large enterprises with many internal subsystems, HTTP incurs higher overhead due to repeated TCP handshakes and lacks features such as persistent connections, built‑in service discovery, and centralized monitoring that RPC frameworks provide.

Conclusion

RPC and HTTP serve different needs: RPC is generally better suited for large‑scale enterprise systems where performance, long‑lived connections, and advanced management features matter, while HTTP remains attractive for simpler, faster‑to‑develop services. Choosing the right approach requires a thorough evaluation of project requirements rather than following trends blindly.