• OSI Network Seven Layer Model
• RPC Service
• RPC Architecture
• Sync and Async Calls
• Popular RPC Frameworks
• HTTP Service
• Summary

For a long time, I haven’t really clarified the difference between RPC (Remote Procedure Call) and HTTP calls. Aren’t they just about writing a service and then calling it on the client side? Allow me to chuckle at my naivety!

…

This article briefly introduces the two forms of C/S architecture. First, the most essential difference is that RPC is primarily based on the TCP/IP protocol, while HTTP services are mainly based on the HTTP protocol. We know that the HTTP protocol operates on top of the transport layer protocol TCP, so in terms of efficiency, RPC certainly has the advantage! Let’s discuss RPC services and HTTP services in detail.

OSI Network Seven Layer Model

Before discussing the differences between RPC and HTTP, I think it’s necessary to understand the OSI seven-layer network model (although in practical applications, it is usually reduced to five layers). It can be divided into the following layers (from top to bottom):

• First Layer: Application Layer. Defines the interfaces used for communication and data transmission over the network;
• Second Layer: Presentation Layer. Defines the data transmission format, encoding, and decoding standards between different systems;
• Third Layer: Session Layer. Manages user sessions and controls the establishment and termination of logical connections between users;
• Fourth Layer: Transport Layer. Manages end-to-end data transmission across the network;
• Fifth Layer: Network Layer. Defines how data is transmitted between network devices;
• Sixth Layer: Link Layer. Encapsulates the data packets from the network layer into data frames for physical layer transmission;
• Seventh Layer: Physical Layer. This layer mainly transmits binary data.

In actual applications, the five-layer protocol structure does not include the presentation and session layers. They should be considered merged with the application layer. We should focus on the application layer and transport layer because HTTP is an application layer protocol, while TCP is a transport layer protocol. Now that we understand the layered model of the network, we can better grasp why RPC services are generally nicer compared to HTTP services!

RPC Service

Let’s introduce RPC services from three perspectives: RPC architecture, synchronous and asynchronous calls, and popular RPC frameworks.

RPC Architecture

First, let’s discuss the basic architecture of RPC services. Please allow me to shamelessly borrow a diagram! We can clearly see that a complete RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub. The term ‘Stub’ can be understood as a placeholder. Let’s discuss these components:

• Client, the caller of the service.

• Server, the actual service provider. The client stub stores the address of the server and packages the client request parameters into a network message, which is then sent to the server over the network. The server stub receives the messages sent by the client, unpacks them, and invokes the local methods.

RPC is primarily used in large enterprises because these enterprises often have numerous systems and complex business lines, where efficiency is a critical factor. In actual development, projects usually use Maven for management.

For example, we have a system service for processing orders. First, declare all its interfaces (which specifically refers to interfaces in Java), then package the entire project into a jar file. On the server side, this library is included, and the corresponding functions are implemented. The client side only needs to include this library to make calls.

Why do it this way? The main reason is to reduce the size of the client jar file because too many jar files during each packaging release can affect efficiency. Additionally, it decouples the client and server, improving code portability.

Synchronous and Asynchronous Calls

What is a synchronous call? What is an asynchronous call? A synchronous call means the client waits for the call to complete and return a result. An asynchronous call means the client does not wait for the call to complete and return a result, but can still receive notifications of the result through callback functions. If the client does not care about the result, it can become a one-way call.

This process is somewhat similar to the callable and runnable interfaces in Java. When we perform asynchronous execution, if we need to know the execution result, we can use the callable interface and obtain the result information through the Future class. If we do not care about the execution result, we can directly use the runnable interface, which does not return a result. Of course, callable can also be used, and we can simply not obtain the Future.

Popular RPC Frameworks

Currently, there are several popular open-source RPC frameworks. Here are three of them:

• gRPC is an open-source software recently announced by Google, based on the latest HTTP2.0 protocol and supports many common programming languages. We know that HTTP2.0 is an upgrade of the HTTP protocol based on binary. Major browsers are quickly adopting it. This RPC framework is implemented based on the HTTP protocol and uses the Netty framework at its core.

• Thrift is an open-source project from Facebook, primarily a cross-language service development framework. It has a code generator that automatically generates service code frameworks from its defined IDL definition files. Users only need to perform secondary development on top of it, while the underlying RPC communication is transparent. However, this requires users to learn a specific domain language, which has some cost.

• Dubbo is a well-known RPC framework open-sourced by Alibaba Group, widely used in many internet companies and enterprise applications. Its distinct feature is that protocols and serialization frameworks are pluggable. The remote interface is based on Java Interface and relies on the Spring framework for convenient development. It can be easily packaged into a single file and run as an independent process, in line with the current microservices concept.

HTTP Service

In fact, a long time ago, I characterized the enterprise development model as HTTP interface development, which is commonly referred to as RESTful style service interfaces. Indeed, in cases with few interfaces and minimal interaction between systems, it was a communication method used to address information silos in the initial stages; its advantages are simplicity, directness, and ease of development.

Using the existing HTTP protocol for transmission, I remember during my undergraduate internship when I was doing backend development, I mainly developed interfaces and had to write a large interface document, clearly stating the inputs and outputs, detailing each interface’s request methods, and the precautions for request parameters.

For example, the following:

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

The interface might return a JSON string or an XML document. The client then processes this returned information, allowing for relatively quick development.

However, for large enterprises with many internal subsystems and numerous interfaces, the benefits of RPC frameworks become evident. First, long connections eliminate the need for three-way handshakes for each communication like HTTP, reducing network overhead;

Secondly, RPC frameworks generally have a registration center, offering rich monitoring and management; publishing, taking down interfaces, and dynamic expansion are all operations that are seamless and unified for the caller.

Summary

RPC services and HTTP services have many differences. Generally speaking, RPC services are aimed at large enterprises, while HTTP services are more suited for small enterprises, as RPC is more efficient, while HTTP service development iterations are quicker.

In summary, the choice of framework should not be based on market popularity, but rather on a comprehensive assessment of the entire project. Carefully compare the impact of the two development frameworks on the project before deciding what is best suited for it. Do not use RPC for every project just because it is available; instead, adapt to the specific situation and analyze the specifics accordingly.