Analysis of the Relationship Between HTTP and RPC

During program development, remote calling is an unavoidable issue. With the prevailing trends of microservices and distributed systems, remote calls are becoming increasingly frequent.

What Are HTTP and RPC?

In the context of remote calls, the most common protocols are HTTP and RPC.

HTTP is a widely familiar protocol, operating at the Application Layer (Layer 7) of the OSI model. Based on this communication protocol, many remote call solutions can be implemented.

RPC, on the other hand, stands for Remote Procedure Call. It is a more recent concept, referring to a complete solution for efficient calling architecture.

It’s easy to mistakenly place HTTP and RPC on an equal footing when unclear about the concepts. However, they aren't equivalent.

HTTP is merely a communication protocol, whereas RPC is a comprehensive solution encompassing the communication protocol, serialization protocol, dynamic proxy, among other aspects. In other words, HTTP can be a part of RPC.

That said, this is not an entirely accurate statement because the communication protocol for RPC may not necessarily be HTTP; it could also be TCP or UDP, or a custom protocol based on these. The relational diagram can be illustrated as follows:

How Does RPC Work?

In a microservice or distributed architecture, each service has a single responsibility. Frequently, Service A may need to invoke functionality from Service B.

The immediate solution might be to send an HTTP request. Indeed, this is a viable solution as HTTP has numerous advantages, one being its strong readability.

The readability stems from HTTP containing abundant information, including but not limited to request headers, validation, connection info, and endpoint info. However, in frequent remote calls, this can lead to inefficiency.

RPC’s goal is to establish an efficient, high-performing, and low-cognitive-load remote call solution.

Here’s a simple example to illustrate the RPC call process: Suppose Invoker A needs to call Function Y of Service B.

In an RPC solution, a fake implementation X of Function Y will be set locally in Client A. Since X is just a fake Y, it indeed doesn’t implement Y’s functionality but has the same method signature as Y.

At this point, when Client A requires invoking Service B's Function Y, it doesn’t need to consider B’s connection and reception. Instead, it directly calls its local Function X as if making a local call.

Here, dynamic proxies in RPC come into play, linking X and Y together, then returning the result of Y to Client A. During this step, the RPC framework handles all networking details such as parameter serialization, sending requests, waiting for responses, deserializing responses, etc.

Advantages of RPC

The advantage of this process is that Invoker A does not need to consider how to connect with B or how to locate Function Y in B. They can simply call X as a local function, leaving most of the work to be handled by the RPC framework.

In summary, the advantages are:

1. Simplified Invocation Process: Invoker A doesn’t need to understand the details of network communication and can invoke proxy object methods like local functions.
2. Reduced Cognitive Load: Developers can focus solely on business logic without spending time dealing with the complexities of remote service calls, including connection management, data transmission, and error handling.
3. Increased Development Efficiency: Since the RPC framework deals with many low-level details, developers can develop and maintain distributed systems more efficiently.

Of course, there are more operations within the RPC solution which are not detailed here. Interested readers can delve deeper.

If any experts have additional insights, feel free to comment and contribute to collective learning.