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

RPC is based on the TCP/IP protocol, while HTTP services rely on the HTTP protocol built on TCP. Because RPC works directly over TCP, it generally offers higher efficiency than HTTP.

OSI Seven‑Layer Model

Understanding the OSI model helps explain why RPC can be faster. The model consists of seven layers (Application, Presentation, Session, Transport, Network, Data Link, Physical). In practice the top three are often merged, leaving Application and Transport as the relevant layers: HTTP is an application‑layer protocol, TCP is a transport‑layer protocol.

RPC Service

RPC Architecture

A typical RPC system contains 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 the server address, packages request parameters into a network message, and sends it.

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

Large enterprises use RPC because it reduces network overhead, supports long‑lived connections, and often includes a service registry and monitoring.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until a result is returned; asynchronous calls return immediately and notify the client later, e.g., via callbacks or futures. In Java, Callable with Future implements asynchronous execution, while Runnable runs without a result.

Popular RPC Frameworks

Three widely used open‑source RPC frameworks are:

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

Thrift – Facebook’s cross‑language service framework with an IDL compiler that generates code.

Dubbo – Alibaba’s Java‑centric RPC framework, pluggable protocol and serialization, integrates with Spring.

HTTP Service

HTTP (often RESTful) is simple, direct, and suitable for small‑scale or low‑traffic services. A typical request looks like:

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

Responses are usually JSON or XML. However, for large enterprises with many services, RPC offers advantages such as persistent connections, reduced handshake overhead, built‑in service discovery, and richer monitoring.

Conclusion

RPC services are generally better suited for large‑scale enterprise systems where performance and maintainability matter, while HTTP services excel in rapid development and smaller projects. Choose the technology that fits the project’s requirements rather than following trends blindly.