HTTP があるのになぜ RPC が必要なのでしょうか?

皆さんこんにちは、Xianyuです

インターネット技術の発展に伴い、分散アーキテクチャが人々にますます採用されています。分散アーキテクチャでは、複雑なビジネスロジックを実装するために、アプリケーションはリモート呼び出しを実装するための分散通信を必要とします。

このとき、異なるアプリケーションプログラム間でのデータ交換や情報転送を実現するために、リモートプロシージャコールをサポートするプロトコルが必要となります。一般的に使用されるプロトコルには、HTTP プロトコルと RPC プロトコルが含まれます

HTTP プロトコルと RPC プロトコルは、どちらもコンピューター間の通信に使用されるプロトコルです。では、両者の違いは何なのか考えたことはありますか? HTTP があるのになぜ RPC が必要なのでしょうか?

上記の質問に答えるために、これら 2 つのプロトコルの紹介から始めましょう。

HTTP と RPC

HTTP

コンピュータネットワークを勉強したことのある友人は、次の文章をよく知っていると信じています。

HTTP (ハイパーテキスト転送プロトコル、ハイパーテキスト転送プロトコル) プロトコルは、主に Web ブラウザと Web サーバー (B/S アーキテクチャ) の間でハイパーテキストマークアップ言語 (HTML) ファイルを送信するために使用され、クライアントとサーバー間の通信をサポートします。

HTTP プロトコルは、最も広く使用されているネットワーク伝送プロトコルであり、要求/応答モデルに基づいており、クライアントとサーバー間で要求と応答を交換することによってデータを送信します。

シンプル、柔軟、拡張性があり、そして最も重要なことは、ステートレスプロトコルであることです。つまり、クライアントとサーバー間でリクエストと応答が交換されるたびに、HTTP プロトコルは白紙の紙となり、以前の情報はまったく記憶されません。

ステートレスプロトコルの重要な利点は信頼性であり、リクエストが失敗したり失われたりしても、他のリクエストの処理には影響しません。

HTTP プロトコルは、送信にテキスト形式を使用します。これは、開発者が読み取りおよびデバッグするのに便利です。クロスプラットフォーム、スケーラブル、キャッシュ可能、および再利用可能という利点があるため、Web 開発で広く使用されています。次のようなシナリオでよく使用されます。 Web ページへのアクセスや画像の読み込みなど。

これを見た友人は、**HTTP はとても素晴らしいのに、本当に欠点があるのでしょうか?と思うかもしれません。**もちろんあるはずです

HTTP プロトコルはステートレスであると前述しました。つまり、各リクエストとレスポンスの間に相関関係がなく、サーバーは以前の情報を記憶しないため、リクエストごとに接続が再確立されます。

一部の長期接続または同時実行性の高いシナリオを処理する場合、リクエストごとに接続を再確立する必要があります。このプロセスにより、ネットワークのオーバーヘッドと遅延が増加するだけでなく、サーバーリソースが消費され、効率が低下します。ステートフルプロトコルを使用すると、サーバーは以前の情報を記憶し、繰り返し接続を確立するプロセスを回避できます。

また、HTTP プロトコルはもともとクライアントとサーバー間で HTML ドキュメントを送信するために設計されたものであるため、データ送信形式はテキストベースです。

したがって、HTTP プロトコルは型付きデータ送信やカスタムプロトコル拡張をサポートしておらず、リクエストと応答の形式が固定されているため、カスタムデータ構造や複雑なロジックを十分にサポートできません。

簡単に言えば、HTTP プロトコルは少し「厳格」です。

RPC (リモートプロシージャコール) プロトコルは、分散アプリケーション間のリモート呼び出しを実装するために使用されるプロセス間通信プロトコルであり、さまざまなアプリケーションがローカルプログラムを呼び出すのと同じようにリモートプログラムを呼び出すことができます。

RPC プロトコルは、関数呼び出しモデルに基づいています。RPC プロトコルでは、クライアントがリモートサーバー上の関数を呼び出すと、パラメーターをメッセージにパックしてサーバーに送信します。サーバーはメッセージを受信した後、パラメーターを解凍して対応する関数を実行し、最後にメッセージをパックします。結果をメッセージに変換してクライアントに送り返します。

このプロセスは、ローカル関数の呼び出しと同様に、クライアントに対して透過的です。つまり、RPC は、異なるプロセスまたは異なるマシン間の関数呼び出しを実装できます。

ネットワーク伝送速度が速く、プロトコルのスケーラビリティが優れているという利点があります (バイナリデータ伝送形式を使用するため、HTTP などのテキストベースのプロトコルと比較して、バイナリ形式のデータ伝送はより効率的です)。それだけでなく、RPC は複数のデータ形式と送信プロトコルをサポートするように設計されているため、複雑なデータ構造とロジックを十分にサポートできます。

さらに、RPC プロトコルは、より効率的なエンコードおよびトランスポートプロトコルを使用でき、非同期呼び出しを使用して応答速度を向上させることもできます。

世の中に完璧なものは存在しない、HTTP もそうだし RPC もそうだ、とよく言います。

RPC は HTTP よりも複雑です。RPC プロトコルの設計目標 (効率的、柔軟、スケーラブル) を達成するには、より多くのインターフェイスとプロトコルを定義する必要があり、より多くの構成と管理が必要になります。当然、開発や運用保守の難易度は上がります。

クロス言語、クロスプラットフォームのリモート呼び出しをサポートするために、RPC には通常、セキュリティメカニズムが含まれていません。追加のセキュリティ対策が講じられていない場合、ID の偽造、データの改ざん、サービス妨害などのセキュリティ上の問題が発生する可能性があります。

ネットワークを安全に保つために、RPC に追加のセキュリティ対策を実装できます。

たとえば、暗号化通信には SSL/TLS プロトコルを使用します。
デジタル証明書を使用した認証
アクセス制御リストを使用した認可
セキュリティ監査と脆弱性スキャンを実施する

前述したように、RPC は通常、テキストベースの形式ではなく、バイナリデータ転送形式を使用します。バイナリ形式は伝送効率が高いですが、パラメータと戻り値をシリアル化および逆シリアル化するために追加のコンピューティングリソースが必要です。

RPCでは、クライアントとサーバー間でパラメータや戻り値をバイナリデータにパッケージ化し、ネットワーク上で送信する必要があります。このプロセスでは、データ転送量を削減するためにパラメータと戻り値をバイナリ形式に変換し、圧縮およびエンコードする必要があります。

受信側では、受信したバイナリデータをデコードし、元のデータ形式に変換する必要があります。このプロセスには追加のコンピューティングリソースの消費が必要です

したがって、RPC では、パラメーターと戻り値をシリアル化および逆シリアル化するために、追加のネットワーク帯域幅とコンピューティングリソースが必要になります。

HTTPとRPCの違い

目的が違う

HTTP はステートレスプロトコルであり、その主な目的はクライアントとサーバー間でリクエストとレスポンスを交換することによってテキストコンテンツを転送することです。

RPC はステートフルプロトコルであり、その主な目的はクライアントとサーバー間で情報を渡し、リモート関数を呼び出すことです。

送信方法が違います

HTTP はテキスト (HTML、XML、JSON など) をキャリアとして使用し、クリアテキスト送信を使用します。

RPC はさまざまな形式 (バイナリ形式など) で送信でき、追加のセキュリティ暗号化テクノロジを使用して送信のセキュリティを確保できます。

コミュニケーション方法が違う

HTTP はリクエスト/レスポンスモデルを使用し、クライアントはサーバーにリクエストを送信し、レスポンスを待ちます。クライアントがリクエストを送信し、サーバーがレスポンスを返します。

RPC は呼び出し/戻りモデルを使用します。このモデルでは、クライアントはサーバー上のリモート関数を呼び出し、結果が返されるのを待ちます。RPC は、同期呼び出し、非同期呼び出し、ストリーミング呼び出しなど、さまざまな呼び出し方法をサポートしています。