[解決済み] gRPC(HTTP/2)はREST with HTTP/2より速いのか？

質問

目標は、より優れたトランスポートおよびアプリケーション層プロトコルを導入することである。 レイテンシー と ネットワークスループット . 現在、アプリケーションは REST を使用しています。 HTTP/1.1 で、高いレイテンシが発生します。私はこの遅延の問題を解決する必要があり、私はどちらかを使うことに前向きです。 gRPC(HTTP/2) または REST/HTTP2 .

HTTP/2です。

1. 多重化
2. シングルTCPコネクション
3. テキストではなくバイナリ
4. ヘッダ圧縮
5. サーバープッシュ

上記の利点はすべて承知しています。 質問No: もし私が HTTP/2でREST と比較した場合、大幅な性能向上が得られると確信しています。 HTTP/1.1によるREST と比べてどうでしょうか？ gRPC(HTTP/2) ?

私はgRPCがプロトバッファを使用していることも知っていますが、これは最適な バイナリシリアライゼーション 技術です。プロトバッファは、言語に依存しないアプローチの開発にも役立ちます。私はそれに同意しますし、同じ機能をRESTでgraphQLを使って実装することができます。しかし、私の懸念は直列化に関するものです。 質問No.2 いつ HTTP/2 はこれを実装しています。 バイナリ機能

プロトバッファを使用すると、HTTP/2の上に追加の利点を与えるのでしょうか？

質問No.3。 という点では ストリーミング、双方向のユースケース gRPC(HTTP/2) は (REST と HTTP/2) と比べてどうなのでしょうか？

非常に多くの ブログ/ビデオ のような gRPC(HTTP/2) と (REST と HTTP/1.1) を比較するブログがインターネット上にたくさんあります。 この . 前述したように、GRPC(HTTP/2)と(HTTP/2のREST)を比較する上での違い、メリットを知りたいです。

どのように解決するのですか？

gRPC は、デフォルトでは REST over HTTP/2 よりも高速ではありませんが、高速化するためのツールを提供します。 RESTでは難しい、あるいは不可能なことがあります。

• 選択的なメッセージ圧縮。 gRPC では、ストリーミング RPC はメッセージを圧縮するかしないかを決めることができます。 たとえば、テキストと画像が混在したストリームを 1 つのストリームで配信する場合 (または、実際に圧縮可能なコンテンツが混在している場合)、画像の圧縮をオフにすることができます。 これにより、すでに圧縮されているデータを圧縮しなくてもよくなり、より小さくなることはありませんが、CPU を消費することになります。
• ファーストクラスのロード バランシング。 ポイントツーポイント接続の改善ではありませんが、gRPC はトラフィックを送信するバックエンドをインテリジェントに選択することができます。 (これはライブラリの機能であり、ワイヤ プロトコルの機能ではありません)。 これは、プロキシを使用することなく、最も負荷の低いバックエンドサーバにリクエストを送ることができることを意味します。 これはレイテンシーの勝利です。
• 高度に最適化された gRPC (ライブラリ) は 連続ベンチマーク を行っており、速度低下がないことを確認しています。 これらのベンチマークは常に改善されています。 繰り返しますが、これはプロトコルであるgRPCとは何の関係もありませんが、gRPCを使用したことであなたのプログラムはより高速になります。

nfirvine が言ったように、Protobuf を使用するだけで、ほとんどの性能向上が見られます。 一方 は protoはRESTでも使えますが、gRPCと非常にうまく統合されています。 技術的には、gRPC で JSON を使用することもできますが、ほとんどの人は proto に慣れた後、パフォーマンス コストを支払いたくはないでしょう。