Chapter 1: What is RPC?

When the term RPC comes up in conversation, what exactly does it refer to? If you've clicked on this article, it's likely because you share the same curiosity.

I found myself pondering this question as I listened to colleagues discuss RPC. A quick search for "what is RPC" led me to discover that Remote Procedure Call is a communication protocol in software that allows one program to request services from another program on a different computer within a network, all without needing to grasp the intricacies of the network itself. Essentially, RPC lets us invoke functions on remote systems just like we would on our local machines. This invocation is also referred to as a function call or subroutine call.

Upon reading this definition, a series of new questions arose:

Isn’t requesting a service from another computer similar to how HTTP works? What distinguishes HTTP from RPC? And when it mentions function calls, what exactly does that entail?

With these inquiries in mind, I delved deeper into the subject. RPC first saw practical application in the 1980s, while HTTP came into existence in the 1990s.

In the case of HTTP, it's clear that when a server needs to fetch resources externally, it does so by passing a URL, which the server then uses to return a response. Conversely, RPC is not strictly a protocol but rather an invocation of a remote function. For instance, invoking a local method might look something like this:

response = localFunction(request)

However, if that function resides on a remote server, it would appear as follows:

response = remoteFunction(request)

This leads to a pertinent question: if RPC exists, why do we still need HTTP?

Consider antivirus and firewall software from earlier days. These applications functioned as clients, establishing connections to their own servers for communication — a classic client/server (c/s) architecture. During that period, RPC was sufficient for internal communications within organizations.

However, browsers like Google Chrome and Microsoft Edge require a broader scope of connectivity. They not only access servers from Google and Microsoft but also from other companies. This necessity for varied inter-company communication has led to the adoption of HTTP in a browser/server (b/s) architecture.

At present, the distinctions between b/s and c/s architectures are beginning to blur, as many applications now support multiple client types. For example, the Slack messaging platform operates across browsers, PCs, and mobile devices.

Next, one might wonder: if HTTP can be adapted for a c/s architecture, why not just eliminate RPC altogether?

To address this, we must explore the key differences between these two methods of communication.

Section 1.1: Key Differences Between RPC and HTTP

HTTP utilizes JSON in its message body for serialization and deserialization. This process requires manual declaration of fields such as Content-Type, User-Agent, and Accept-Encoding, along with their respective values.

In contrast, RPC offers greater flexibility in message customization. In gRPC, which is a popular RPC framework, the interface definition language typically used is Protobuf. Protobuf has its own mechanisms that differ from conventional REST APIs, which generally transmit JSON strings as bytes. This allows for a much smaller payload, resulting in enhanced performance.

Subsection 1.1.1: Connection Management

Taking HTTP/1.1 as an example, once a TCP connection is established, subsequent requests and responses reuse the same connection. In contrast, RPC typically employs a connection pool. As request volumes rise, it draws from this pool to avoid establishing new connections for each request, thus optimizing resource use and improving overall performance.

This efficiency is why certain programming languages, such as Golang, incorporate connection pooling for HTTP requests.

In general, RPC tends to outperform HTTP, which is why many companies prefer RPC for internal communication. However, we do observe a trend toward integrating both technologies for improved communication efficiency. For instance, gRPC is built atop HTTP/2, offering speeds up to seven times faster than REST for data retrieval and approximately ten times faster for data transmission.

I trust this article has been insightful. If you’re on a journey to learn Java and delve deeper into backend engineering, feel free to follow my channel for updates on my experiences and insights from my daily work and life.

Chapter 2: Additional Resources

This video titled "Introduction to RPC - Remote Procedure Calls" provides a foundational overview of RPC, explaining its significance and functionality in software development.

The second video, "What is RPC?", further explores the concept of Remote Procedure Calls, breaking down its applications and advantages in a straightforward manner.

Read More:

A Case About Java Static Keyword During My Job

How Can You Solve This Java Multithreading Interview Problem?

Get Connected:

My LinkedIn