For a long time, I never really understood the difference between RPC (Remote Procedure Call) and HTTP calls. Aren’t they just about writing a service and calling it on the client side? Please allow me a naive smile here~ Naive!

This article briefly introduces the two forms of C/S architecture, starting with their fundamental difference: RPC is primarily based on the TCP/IP protocol, while HTTP services are mainly based on the HTTP protocol. As we know, the HTTP protocol operates on top of the TCP transport layer protocol, so in terms of efficiency, RPC is certainly superior! Let’s discuss RPC services and HTTP services in detail.

OSI Seven-Layer Network Model

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

• Layer 1: Application Layer. Defines the interface for communication and data transmission over the network;

• Layer 2: Presentation Layer. Defines the data transmission format, encoding, and decoding specifications between different systems;

• Layer 3: Session Layer. Manages user sessions and controls the establishment and termination of logical connections between users;

• Layer 4: Transport Layer. Manages end-to-end data transmission across the network;

• Layer 5: Network Layer. Defines how data is transmitted between network devices;

• Layer 6: Link Layer. Encapsulates the data packets from the network layer into data frames for physical layer transmission;

• Layer 7: Physical Layer. This layer primarily transmits these binary data.

In practical applications, the five-layer protocol structure does not include the presentation and session layers. They should be said to have merged with the application layer. We should focus on the application layer and the 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 comprehend why RPC services are comparatively nicer than HTTP services!

RPC Services

Introducing 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. Allow me to shamelessly steal a diagram~ We can clearly see that a complete RPC architecture includes 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 holds the address information of the server and packages the client’s request parameters into network messages, which are then sent to the service provider over the network. The server stub receives the messages sent by the client, unpacks them, and calls the local method.

RPC is mainly used in large enterprises because they have numerous systems and complex business lines, where efficiency is crucial. In actual development, projects typically use Maven for management.

For example, suppose we have a service for processing orders. First, we declare all its interfaces (specifically referring to interfaces in Java), then package the entire project into a JAR file. The server-side imports this library and implements the corresponding functionality while the client-side only needs to import this library to call it.

Why do this? Mainly to reduce the size of the JAR file on the client side because having too many JAR files can impact efficiency during each packaging and release. Additionally, this decouples the client and server, improving code portability.

Synchronous and Asynchronous Calls

What are synchronous and asynchronous calls? A synchronous call means that the client waits for the execution to complete and return the result. An asynchronous call means that the client does not wait for the execution to complete but can still receive notifications of the returned result through callback functions, etc. 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 asynchronous execution result through the Future class. If we do not care about the execution result, we can directly use the Runnable interface since it does not return a result. Of course, Callable can also be used without retrieving the Future.

Popular RPC Frameworks

Currently, there are many popular open-source RPC frameworks. Below are three that are particularly noteworthy:

• gRPC is an open-source software recently released by Google, based on the latest HTTP/2.0 protocol and supports many common programming languages. We know that HTTP/2.0 is a binary-based upgrade of the HTTP protocol, and major browsers are rapidly supporting 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 by Facebook, mainly a cross-language service development framework. It has a code generator that automatically generates service code frameworks from its defined IDL files. Users only need to perform secondary development on it, while the underlying RPC communication, etc., are transparent to them. However, this requires users to learn a specific domain language, which has some cost.

• Dubbo is a well-known open-source RPC framework from Alibaba, widely used in many internet companies and enterprise applications. Its ability to plug and unplug protocols and serialization frameworks is a distinctive feature. The remote interface is based on Java interfaces and relies on the Spring framework for easy development. It can be easily packaged into a single file and run as an independent process, consistent with the current microservices concept. I’ll let you in on a little secret: the group internally doesn’t use Dubbo much anymore; they now use something called HSF, also known as “Very Comfortable.” It may be open-sourced in the future, so stay tuned.

HTTP Services

Actually, a long time ago, I characterized the development model of enterprises as HTTP interface development, which is what we commonly refer to as RESTful service interfaces. Indeed, in situations where there are not many interfaces and system interactions are limited, it is a communication method often used to solve information silos in the early stages; its advantages are simplicity, directness, and ease of development.

Utilizing the existing HTTP protocol for transmission. I remember during my undergraduate internship when I did backend development, I mainly focused on interface development and had to write a large interface document, clearly specifying the inputs and outputs, detailing each interface’s request methods, and noting the important aspects of request parameters.

For example, the following case: POST http://www.httpexample.com/restful/buyer/info/shar

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

However, for large enterprises with many internal subsystems and numerous interfaces, the benefits of RPC frameworks become apparent. Firstly, they maintain long connections, eliminating the need for the three-way handshake like HTTP does for each communication, thus reducing network overhead. Secondly, RPC frameworks generally have a registration center with rich monitoring and management capabilities; publishing and decommissioning interfaces, dynamic expansion, etc., are operations that the caller can perform without being aware of them, providing a unified experience.

Conclusion

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

In summary, the choice of framework should not be based on market popularity but should involve a complete evaluation of the entire project. After carefully comparing how the two development frameworks impact the entire project, one can then decide what is most suitable for the project. Do not adopt RPC for every project just because it exists; instead, adapt to the specific conditions and analyze the situation accordingly.