Understanding RPC vs HTTP: Architecture, Call Types, and Popular 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). The layers from top to bottom are Application, Presentation, Session, Transport, Network, Data Link, and Physical. In practice, the Presentation and Session layers are usually merged with the Application layer, leaving the focus on the Application and Transport layers: HTTP operates at the Application layer, while TCP operates at the Transport layer.

RPC Services

RPC (Remote Procedure Call) is typically built on top of TCP/IP, offering higher efficiency than HTTP. A typical RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub. The client stub packages request parameters and sends them over the network, while the server stub receives, unpacks, and invokes local methods.

RPC is favored in large enterprises with complex systems because of its performance advantages. Development usually involves packaging interfaces into a JAR, allowing the client to depend only on the interface library, reducing client JAR size and improving decoupling.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until the result is returned, whereas 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

Three widely used open‑source RPC frameworks are highlighted:

gRPC : Developed by Google, based on HTTP/2, supports many languages, and uses Netty under the hood.

Thrift : Originated at Facebook, provides cross‑language service development with an IDL code generator.

Dubbo : An Alibaba open‑source framework, highly extensible with pluggable protocols and serialization, integrates tightly with Spring.

HTTP Services

Traditional HTTP (RESTful) services are simple to develop and suitable for small projects or low‑traffic scenarios. They rely on standard HTTP methods and often return JSON or XML. However, for large enterprises with many internal subsystems, RPC offers advantages such as persistent connections, reduced handshake overhead, built‑in service registries, and richer monitoring.

Example of a simple HTTP request:

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

Conclusion

RPC and HTTP each have distinct use cases: RPC excels in performance‑critical, large‑scale environments, while HTTP provides rapid development for smaller services. The choice should be based on a thorough evaluation of project requirements rather than blindly following trends.

Final Note (Please Follow)

The author offers three PDF collections—"Spring Cloud Advanced", "Spring Boot Advanced", and "Mybatis Advanced"—available by following the public account and replying with the respective keywords.