Understanding RPC Services vs HTTP Services: Architecture, Call Types, and Popular Frameworks

OSI Network Seven-Layer Model

Before comparing RPC and HTTP, it is helpful to understand the OSI seven-layer network model (although most practical applications use a five-layer model). From top to bottom the layers are:

Application layer – defines interfaces for communication and data transfer.

Presentation layer – defines data formats, encoding and decoding rules.

Session layer – manages user sessions and logical connections.

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

Network layer – defines how data is routed between devices.

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

Physical layer – transmits the binary data over the medium.

In real‑world applications the presentation and session layers are often merged with the application layer, so the focus is usually on the application and transport layers. HTTP is an application‑layer protocol, while TCP (used by most RPC implementations) operates at the transport layer, which explains why RPC can be more efficient.

RPC Services

RPC (Remote Procedure Call) services are typically used in large enterprises where many systems need high‑performance communication.

RPC Architecture

A complete RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub. The stubs act as proxies that package and unpack messages for remote execution.

Client – the caller of the service.

Server – the actual service provider.

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

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

In practice, developers often package interfaces into a JAR file, include that JAR on the server side to implement the functionality, and include the same JAR on the client side to invoke the service, reducing client JAR size and improving modularity.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until the remote method finishes and returns a result. Asynchronous calls return immediately; the client can later receive the result via a callback or a Future object. In Java, Callable with Future represents asynchronous execution with a return value, while Runnable represents fire‑and‑forget execution.

Popular RPC Frameworks

Several open‑source RPC frameworks are widely used:

gRPC – Google’s framework based 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 service code.

Dubbo – Alibaba’s mature Java RPC framework, plug‑inable protocol and serialization, integrates with Spring, and aligns with micro‑service concepts. (Internally, Alibaba now prefers HSF.)

HTTP Services

HTTP (often RESTful) services are simple, direct, and easy to develop, making them suitable for small projects or low‑traffic scenarios. Developers typically expose endpoints, document request methods and parameters, and return JSON or XML responses.

Example: POST http://www.httpexample.com/restful/buyer/info/shar

However, for large enterprises with many subsystems and a high volume of interfaces, RPC offers advantages such as persistent connections (reducing handshake overhead), built‑in service registries, monitoring, dynamic scaling, and better performance.

Conclusion

RPC and HTTP services serve different needs: RPC is favored in large‑scale, performance‑critical environments, while HTTP is more agile for smaller or less demanding projects. The choice should be based on a thorough evaluation of project requirements rather than simply following trends.