Backend Development 8 min read

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

This article explains the fundamental differences between RPC and HTTP services, covering the OSI network model, RPC architecture components, synchronous and asynchronous calls, and introduces popular open‑source RPC frameworks such as gRPC, Thrift, and Dubbo, before comparing their suitability for various enterprise scenarios.

Top Architect
Top Architect
Top Architect
Understanding RPC vs HTTP: Architecture, Protocols, and Popular Frameworks

For a long time many developers have confused Remote Procedure Call (RPC) with HTTP calls, assuming both simply involve writing a service and invoking it from a client. This article clarifies their essential differences: RPC typically operates over TCP/IP, while HTTP services use the HTTP protocol.

The OSI seven‑layer model is introduced to provide context, highlighting that the application layer (where HTTP resides) and the transport layer (where TCP resides) are the most relevant when comparing RPC and HTTP.

RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub. The client initiates a request, the client stub packages the request and sends it over the network, the server stub receives and unpacks the request, and the server processes the call.

Synchronous calls block the client until a response 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.

Three widely used open‑source RPC frameworks are highlighted:

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

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

Dubbo : Alibaba’s mature RPC solution featuring pluggable protocols and serialization.

HTTP services are typically RESTful APIs built on the HTTP protocol, offering simplicity and rapid development for small‑scale or low‑traffic scenarios. However, for large enterprises with many services, RPC provides advantages such as persistent connections, reduced handshake overhead, built‑in service registries, and richer monitoring.

The article concludes that RPC is better suited for high‑performance, large‑scale systems, while HTTP is preferable for quick, lightweight development, and the choice of framework should be based on a thorough evaluation of project requirements rather than current popularity.

Microservicesbackend developmentRPCDubbogRPCHTTPThrift
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.