Why Use RPC When We Have HTTP?

↓Recommended Follow ↓

• OSI Network Seven-Layer Model

• RPC Services
• RPC Architecture
• Sync and Async Calls
• Popular RPC Frameworks
• HTTP Services
• In Summary

RPC is mainly based on the TCP/IP protocol, while HTTP services are primarily 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 upper hand! 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 generally reduced to five layers). It can be divided into the following layers (from top to bottom):

• Layer 1: Application Layer. Defines the interfaces for communication and data transmission over the network;
• Layer 2: Presentation Layer. Defines the data transmission formats, encoding, and decoding standards between different systems;
• Layer 3: Session Layer. Manages user sessions and controls the establishment and interruption 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 is primarily responsible for transmitting binary data.

In practical applications, the five-layer protocol structure does not include the presentation and session layers. It should be said that they have merged with the application layer. We should focus on the application and transport layers. Since HTTP is an application layer protocol and TCP is a transport layer protocol, understanding the network layering model allows us to better grasp why RPC services are comparatively nicer than HTTP services!

RPC Services

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. Allow me to shamelessly steal a diagram~ We can clearly see that a complete RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub. The Stub can be understood as a placeholder. Let’s discuss these components:

• Client, the caller of the service.
• Server, the actual service provider.
• Client Stub, which stores the address message of the server and packages the client’s request parameters into a network message, then sends it remotely to the service provider.
• Server Stub, which receives the messages sent by the client, unpacks them, and calls the local methods.

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

For example, we have a service for processing orders. We first declare all its interfaces (specifically referring to interfaces in Java), then package the entire project into a JAR file. The server side imports this dependency and implements the corresponding functionality, while the client side only needs to import this dependency to make calls. Why do it this way? Mainly to reduce the size of the JAR file on the client side, as too many JAR files during packaging can impact efficiency. Additionally, this decouples the client and server, improving code portability.

Sync and Async Calls

What are synchronous calls? What are asynchronous calls? Synchronous calls mean the client waits for the call to complete and return a result. Asynchronous calls mean the client does not wait for the call to finish and return a result, but can still receive notifications of the return 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 result information through the Future class. If we don’t 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; we just don’t retrieve the Future.

Popular RPC Frameworks

Currently, there are quite a few popular open-source RPC frameworks. Here are three key ones:

1. 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 for support at the lower level.

2. 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 files. Users only need to perform secondary development on it, while the underlying RPC communication is transparent. However, users need to learn a specific domain language, which incurs some cost.

3. Dubbo is a very famous RPC framework open-sourced by Alibaba Group, widely used in many internet companies and enterprise applications. Its distinctive feature is the pluggable protocol and serialization framework. The remote interface is based on Java interfaces and relies on the Spring framework for easy development. It can be conveniently packaged into a single file and run as an independent process, in line with the current microservices concept.

HTTP Services

Actually, long ago, I characterized enterprise development models as HTTP interface development, commonly known as RESTful style service interfaces. Indeed, in cases where there are few interfaces and little interaction between systems, this is a communication method often used in the early stages to solve information silos; its advantages are simplicity, directness, and ease of development by utilizing the existing HTTP protocol for transmission.

I remember during my undergraduate internship when I worked on backend development, I mainly focused on interface development and had to write a large interface document, strictly specifying the inputs and outputs. I clearly stated the request methods for each interface and the precautions for request parameters. For example, the following:

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

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 apparent. First, there are long connections, eliminating the need for the three-way handshake like HTTP for each communication, thus reducing network overhead. Secondly, RPC frameworks generally have a registry center, with rich monitoring and management capabilities; publishing, taking down interfaces, and dynamic expansion can be performed uniformly without the caller’s awareness.

In Summary

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

In conclusion, the choice of framework should not be determined by what is popular in the market, but rather by a complete evaluation of the entire project. After carefully comparing the impacts of the two development frameworks on the entire project, we can decide which is the most suitable for this project. One should not use RPC for every project just because it’s RPC; rather, one should adapt to the specific situation and analyze it accordingly.