Understanding RPC vs HTTP Services: Architecture, Protocols, and Popular Frameworks

OSI Network Seven-Layer Model

Before comparing RPC and HTTP, it is useful to understand the OSI model, which traditionally includes seven layers from the application layer down to the physical layer, though most practical implementations use a simplified five‑layer version where the presentation and session layers are merged into the application layer.

RPC Services

RPC (Remote Procedure Call) operates primarily over TCP/IP, offering higher efficiency than HTTP because it works at the transport layer. A typical RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub.

RPC Architecture

The client initiates a request, the client stub packages the call into a network message, the server stub receives and unpacks the message, and the server executes the requested method. This design promotes decoupling, reduces client JAR size, and improves portability.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until a response is returned, while asynchronous calls allow the client to continue processing and receive results later via callbacks or futures, similar to Java's Callable and Runnable interfaces.

Popular RPC Frameworks

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

Thrift : Facebook’s cross‑language service framework with an IDL code generator, requiring developers to learn its specific language.

Dubbo : Alibaba’s widely used Java RPC framework with pluggable protocols and serialization, often integrated with Spring; newer internal projects may use HSF.

HTTP Services

HTTP (RESTful) services are simpler to develop, suitable for small‑scale systems with fewer interfaces. They rely on the HTTP protocol for transport, making them easy to document and test, but they involve additional handshakes and lack the long‑connection efficiency of RPC.

When to Use RPC vs HTTP

For large enterprises with many subsystems and high performance requirements, RPC offers persistent connections, built‑in service registries, and richer monitoring, making it more efficient. For smaller projects or rapid iteration, HTTP services provide quicker development cycles.

Conclusion

Choosing between RPC and HTTP should be based on a thorough evaluation of project size, performance needs, and ecosystem compatibility rather than simply following market trends.