Hello everyone, I am Xianyu
With the development of Internet technology, distributed architecture is more and more adopted by people. In a distributed architecture, in order to implement complex business logic, applications require distributed communication to implement remote calls
At this time, a protocol is needed to support remote procedure calls in order to realize data exchange and information transfer between different application programs. Commonly used protocols include HTTP protocol and RPC protocol
The HTTP protocol and the RPC protocol are both protocols used to communicate between computers. So have you guys ever wondered what the difference is between them? Why do you need RPC when you have HTTP?
In order to answer the above questions, let's start with the introduction of these two protocols
HTTP 和 RPC
- HTTP
Friends who have studied computer networks believe that they are familiar with the following passage:
HTTP (HyperText Transfer Protocol, Hypertext Transfer Protocol) protocol is mainly used to transmit Hypertext Markup Language (HTML) files between Web browsers and Web servers (B/S architecture), and supports communication between clients and servers
The HTTP protocol is the most widely used network transmission protocol. The HTTP protocol is based on the request/response model and transmits data by exchanging requests and responses between the client and the server.
It's simple, flexible, scalable, and most importantly - it's a stateless protocol, that is, every time a request and response are exchanged between a client and a server, the HTTP protocol is a blank sheet of paper, will not remember any previous information
An important advantage of the stateless protocol is reliability. Even if a request fails or is lost, it will not affect the processing of other requests.
The HTTP protocol uses text format for transmission, which is convenient for developers to read and debug. It is widely used in web development because of its advantages of being cross-platform, scalable, cacheable, and reusable. It is often used in scenarios such as web page access and image loading.
Seeing this, my friends may think, **HTTP is so amazing, does it really have any shortcomings? **Of course there must be
We mentioned earlier that the HTTP protocol is stateless, that is to say, there is no correlation between each request and response, and the server will not remember any previous information, so it will cause the connection to be re-established for each request
When dealing with some long-term connections or high-concurrency scenarios, each request needs to re-establish the connection, and this process will not only increase network overhead and delay, but also consume server resources, thereby reducing efficiency. If you use a stateful protocol, the server can remember the previous information, avoiding the process of repeatedly establishing a connection
In addition, because the HTTP protocol was originally designed to transmit HTML documents between the client and the server, that is, the data transmission format is text-based
Therefore, the HTTP protocol does not support typed data transmission and custom protocol extensions. The formats of requests and responses are fixed, which makes it unable to support custom data structures and complex logic well.
Simply put, the HTTP protocol is a bit "rigid"
- RPC
The RPC (Remote Procedure Call) protocol is an inter-process communication protocol used to implement remote calls between distributed applications, so that different applications can call remote programs like calling local programs
The RPC protocol is based on a function call model . In the RPC protocol, when a client calls a function on a remote server, it packs the parameters into a message and sends it to the server. After receiving the message, the server unpacks the parameters and executes the corresponding function, and finally packs the result into a message and sends it back client,
This process is transparent to the client, just like calling a local function, that is, RPC can implement function calls between different processes or different machines
It has the advantages of fast network transmission speed and good protocol scalability (because of the use of binary data transmission format, compared with text-based protocols such as HTTP, binary format transmission of data is more efficient). Not only that, RPC is designed to support multiple data formats and transmission protocols, which makes it well able to support complex data structures and logic
In addition, the RPC protocol can use more efficient encoding and transport protocols, and can also use asynchronous calls to improve response speed
We often say that there is no perfect thing in the world, HTTP is like this, and so is RPC
RPC is more complex than HTTP. In order to achieve the design goals of the RPC protocol (efficient, flexible, and scalable), it needs to define more interfaces and protocols, and requires more configuration and management. Of course, this will increase the difficulty of development and operation and maintenance
In order to support cross-language, cross-platform remote calls, RPC usually does not include security mechanisms. If additional security measures are not taken, there may be security issues such as identity forgery, data tampering, and denial of service
To keep the network safe, we can implement additional security measures in RPC:
- For example, use SSL/TLS protocol for encrypted communication
- Authentication using digital certificates
- Authorization using access control lists
- Conduct security audits and vulnerability scans
As we mentioned earlier, RPC usually uses a binary data transfer format rather than a text-based format. Although the binary format has high transmission efficiency, it requires additional computing resources to serialize and deserialize parameters and return values
In RPC, parameters and return values need to be packaged into binary data between the client and the server, and transmitted on the network. This process requires converting parameters and return values to binary format, and compressing and encoding to reduce the amount of data transmission
For the receiver, the received binary data needs to be decoded and converted to the original data format. This process requires the consumption of additional computing resources
Therefore, RPC requires additional network bandwidth and computing resources to serialize and deserialize parameters and return values
The difference between HTTP and RPC
- different purpose
HTTP is a stateless protocol whose main purpose is to transfer text content by exchanging requests and responses between clients and servers
RPC is a stateful protocol whose main purpose is to pass information between client and server and call remote functions
- The transmission method is different
HTTP uses text (such as HTML, XML, JSON, etc.) as a carrier, and uses clear text transmission
RPC can be transmitted in a variety of formats (such as binary format), and can use additional security encryption technology to ensure transmission security
- Communication methods are different
HTTP uses a request/response model, where the client sends a request to the server and waits for a response. The client sends a request and the server returns a response
RPC uses a call/return model, where the client calls a remote function on the server and waits for the result to be returned. RPC supports a variety of different calling methods, such as synchronous calling, asynchronous calling, streaming calling, etc.
Why do you need RPC when you have HTTP?
Although HTTP has become one of the important standards of network communication and is widely used in various scenarios on the Internet, in some cases, it cannot meet the needs of users
For example, in some complex distributed application scenarios (service calls in distributed systems, communication between services in microservice architecture, etc.), the RPC protocol is more suitable than the HTTP protocol
Xianyu will explain why RPC is more suitable for complex distributed application scenarios from the following points
From the point of view of timeliness
- The data format of the HTTP protocol has certain limitations, such as only text can be transmitted, and the transmission efficiency is low
- The HTTP protocol is based on the request/response model, and each request needs to establish a new connection, which will increase network overhead
- Compared with the HTTP protocol, the RPC protocol usually uses binary data format for transmission, and usually has higher transmission efficiency and lower network delay
- Compared with the HTTP protocol, the RRPC protocol also supports advanced features such as asynchronous calls and batch calls, which can improve system performance and throughput
From a security point of view
- HTTP is a text protocol, and data transmission uses plain text, which makes it easy for middlemen to eavesdrop or tamper with data (but SSL/TLS protocols can be used to encrypt and authenticate data)
- Compared with the HTTP protocol, RPC supports the transmission of various types of data (such as binary), which can transmit large amounts of data faster and more flexibly , and can also encrypt the transmission to ensure security
From the perspective of scene complexity
- In complex business logic and data structure scenarios, multiple request and response operations are usually required, and HTTP, as a stateless protocol, cannot maintain the session state. Each request and response needs to re-establish the connection and transmit data, which will cause network Latency and performance degradation
- HTTP protocol requests and responses are usually based on text or binary data formats, which cannot directly support complex data structures, such as objects, arrays, enumerations, etc.
- Compared with the HTTP protocol, RPC is a stateful protocol, and RPC can encapsulate business logic by defining interfaces and methods, so that clients can complete complex operations through simple calls
- Compared with the HTTP protocol, the RPC protocol is an object-oriented protocol, which can directly support complex data structures, such as objects, arrays, enumerations, etc.