For a long time it was difficult to make a clear distinction between Remote Procedure calls (RPC) and HTTP calls. Please allow me to be Naive!

This article briefly introduces the two forms of C/S architecture, first say their most essential difference, is RPC is mainly based on TCP/IP protocol, and HTTP service is mainly based on HTTP protocol, we all know that HTTP protocol is on the transport layer protocol TCP, so efficiency, RPC is certainly better! Let’s talk more specifically about RPC services and HTTP services.

# OSI network seven-layer model,

Before I talk about the difference between RPC and HTTP, I think it’s important to understand OSI’s seven-tier network architecture (although in practice it’s almost always five-tier), which can be divided into the following layers :(from top to bottom)

  • Layer 1: application layer. Defines the interface for communicating and transmitting data in the network;
  • Layer 2: Presentation layer. Define data transmission format, encoding and decoding specifications in different systems;
  • The third layer: the session layer. Manage user sessions and control the establishment and interruption of logical connections between users.
  • The fourth layer: transport layer. Manages the end-to-end data transfer in the network;
  • Layer 5: network layer. Define how data is transmitted between network devices;
  • Layer 6: link layer. The packets of the network layer are encapsulated into data frames for easy transmission at the physical layer.
  • Layer 7: Physical layer. This layer is all about transferring binary data.

In practice, there is no presentation layer and session layer in the five-layer protocol structure. I should say they merge with the application layer. We should focus on the application layer and the transport layer. Because HTTP is an application layer protocol and TCP is a transport layer protocol. Now that we know the layered model of the network we can better understand why RPC services are nicer than HTTP services!

# the RPC service

RPC services are introduced from three perspectives: RPC architecture, synchronous asynchronous invocation and popular RPC framework.

# RPC architecture

Let’s start with the basic architecture of RPC services. We can clearly see that a complete RPC architecture contains four core components, namely the Client,Server,Client Stub and Server Stub. Tell us about these components separately:

  • A Client is the caller of a service.

  • A Server is a real service provider.

    Client stubs that store server address messages and package client request parameters into network messages that are sent to the server remotely over the network.

    The server stub receives the message sent from the client, unpacks the message, and invokes local methods.

RPC is mainly used in large enterprises, because large enterprises have many systems and complex business lines, and the efficiency advantage is very important. At this time, THE advantage of RPC is more obvious. This is done in real development, where projects are generally managed using Maven.

Synchronous versus asynchronous invocation

What is a synchronous call? What is an asynchronous call? A synchronous call is when the client waits for the call to complete and returns the result. An asynchronous call is one in which the client does not wait for the call to complete and return the result, but can still receive notification of the return result through callback functions, etc. If the client doesn’t care about the result, it can become a one-way call.

# Popular RPC framework

There are many popular open source RPC frameworks. The following two types are mainly introduced:

  • GRPC is Google’s recently announced open source software, based on the latest HTTP2.0 protocol, and supports many common programming languages. We know that HTTP2.0 is a binary based update to the HTTP protocol, which is currently being rapidly supported by browsers. This RPC framework is based on HTTP protocol implementation, the underlying use of Netty framework support.
  • Thrift is an open source project from Facebook that is primarily a cross-language service development framework. It has a code generator to automatically generate the service code framework for the IDL definition files it defines. As long as the user before the secondary development on the line, for the underlying RPC communication and so on are transparent. But there is a cost to the user of learning the domain-specific language feature.

# HTTP service

In fact, long ago, I defined the mode of enterprise development as HTTP interface development, which is often referred to as RESTful service interface. Indeed, in the case of few interfaces and less system-to-system interaction, it is a communication means often used to solve the early stage of information islands; The advantages are simplicity, directness and ease of development.

Use the existing HTTP protocol for transport. We remember that when I was doing background development in the company during my undergraduate internship, I was mainly engaged in interface development, and I had to write a large interface document to strictly indicate what the input and output were. Make clear the request method of each interface, and the matters needing attention of request parameters, etc.

Such as the following example: POST www.httpexample.com/re…

The interface may return a JSON string or an XML document. The returned information is then processed by the client, allowing for faster development.

However, for large enterprises, when there are many internal subsystems and interfaces, the benefits of RPC framework will be shown. First of all, the long link does not need to shake hands three times like HTTP for each communication, which reduces the network overhead.

Secondly, RPC frameworks generally have registries and rich monitoring management. Publishing, offline interfaces, dynamic extensions, etc., are unaware and unified operations for callers.

# summary

There are many differences between RPC services and HTTP services. Generally speaking, RPC services are mainly targeted at large enterprises, while HTTP services are mainly targeted at small enterprises, because RPC is more efficient and HTTP service development iterations are faster.

In short, the choice of framework is not determined by what is popular in the market, but by a complete evaluation of the entire project, so as to carefully compare the impact of the two development frameworks on the overall project, and finally decide what is best for the project. Make sure you don’t use RPC for every project just to use IT.