Understanding RPC vs HTTP Services and the OSI Model

The author, a senior architect, introduces the OSI seven‑layer model (Application, Presentation, Session, Transport, Network, Data Link, Physical) and notes that in practice the top three layers are often merged, focusing on the Application and Transport layers.

He then compares RPC and HTTP services, emphasizing that RPC, built on TCP/IP, generally offers higher efficiency than HTTP, which operates at the application layer over TCP.

OSI Model Layers

Application layer – defines communication interfaces.

Presentation layer – defines data format and encoding.

Session layer – manages sessions and logical connections.

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

Network layer – defines routing between devices.

Data Link layer – packages network packets into frames.

Physical layer – transmits binary data.

RPC Service Overview

RPC architecture consists of 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 server address, packages request parameters, and sends them over the network.

Server Stub – receives messages, unpacks them, and invokes local methods.

RPC is commonly used in large enterprises where many systems and complex business lines demand high efficiency. Projects typically use Maven to manage dependencies, sharing interface definitions via Java interfaces packaged as JARs.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until a result 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 based on HTTP/2, supporting multiple languages and built on Netty.

Thrift – Facebook’s cross‑language service framework with an IDL and code generator.

Dubbo – Alibaba’s widely used Java RPC framework with pluggable protocols and serialization, integrating well with Spring.

HTTP Service Overview

HTTP services follow a RESTful style, suitable for smaller projects with fewer interfaces, offering simplicity and rapid development but lacking the performance and features of RPC such as long‑connections and built‑in service registries.

Conclusion

RPC is preferable for large‑scale enterprise back‑ends due to its efficiency and rich ecosystem, while HTTP remains a good choice for smaller, faster‑to‑market applications; the decision should be based on project requirements rather than trends.