Understanding RPC vs HTTP: Architecture, Protocols, and Popular Frameworks
This article explains the fundamental differences between RPC and HTTP services, reviews the OSI network model, describes RPC architecture and sync/async calls, compares popular RPC frameworks such as gRPC, Thrift, and Dubbo with traditional RESTful HTTP, and offers guidance on choosing the right approach for a project.
The article introduces the distinction between RPC (Remote Procedure Call) and HTTP services, noting that RPC typically operates over TCP/IP while HTTP is an application‑layer protocol, and sets the stage for a deeper technical comparison.
It briefly reviews the OSI seven‑layer network model, emphasizing the relevance of the application and transport layers for understanding RPC (TCP) and HTTP (application protocol).
RPC architecture is outlined with four core components: Client, Server, Client Stub, and Server Stub, explaining each component’s responsibilities in remote method invocation.
The discussion then covers synchronous versus asynchronous calls, using Java's Callable and Runnable interfaces as analogies to illustrate how clients can wait for results or proceed without blocking.
Three widely used open‑source RPC frameworks are presented:
gRPC : Google’s framework built on HTTP/2, supporting multiple languages and leveraging Netty.
Thrift : Facebook’s cross‑language service framework with an IDL and code generator.
Dubbo : Alibaba’s mature RPC solution with pluggable protocols and serialization.
The article then describes traditional HTTP services, typically RESTful, and provides a simple example request:
POST http://www.httpexample.com/restful/buyer/info/shar
It compares the two approaches, highlighting that RPC offers higher efficiency, long‑lived connections, and built‑in service registries suitable for large enterprises, whereas HTTP is simpler, faster to develop, and better for smaller projects.
Finally, the article advises developers to evaluate project requirements, performance needs, and ecosystem before deciding between RPC and HTTP, emphasizing that the choice should be driven by technical fit rather than trends.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.