gRPC（HTTP / 2）は、HTTP / 2でRESTより高速ですか？
目標は、レイテンシおよびネットワークスループットで優れているトランスポートおよびアプリケーションレイヤプロトコルを導入することです。現在、アプリケーションはRESTとHTTP/1.1を使用しており、高いレイテンシが発生します。この遅延の問題を解決する必要があり、gRPC（HTTP/2）またはREST/HTTP2のいずれかを使用できます。
HTTP/2：
- 多重化
- 単一のTCP接続
- テキストではなくバイナリ
- ヘッダー圧縮
- サーバープッシュ
上記のすべての利点を認識しています。 質問番号1：HTTP/2でのRESTを使用すると、HTTP /でのREST /と比較して、パフォーマンスが大幅に向上します。 1.1ですが、これはgRPC（HTTP/2）とどのように比較されますか？
また、gRPCがプロトバッファを使用することも知っています。これは、ワイヤ上で構造化データを送信するための最良のバイナリシリアル化テクニックです。プロトバッファは、言語に依存しないアプローチの開発にも役立ちます。私はそれに同意し、graphQLを使用してRESTに同じ機能を実装できます。しかし、私の懸念はシリアル化です：質問番号2：HTTP/2がこれを実装する場合バイナリ機能、protoバッファを使用すると利点が追加HTTP/2の上に？
質問3：ストリーミング、双方向ユースケースに関して、gRPC（HTTP/2）は（RESTおよびHTTP/2）とどのように比較されますか？
インターネットには非常に多くのblogs/videosがあり、 this のようにgRPC（HTTP/2）と（RESTおよびHTTP/1.1）を比較しています。前述したように、GRPC（HTTP/2）と（RESTとHTTP/2）を比較することの違い、利点を知りたいと思います。
gRPCは、デフォルトではHTTP/2を介したRESTよりも高速ではありませんが、高速にするツールを提供します。 RESTでは困難または不可能なことがいくつかあります。
- 選択的なメッセージ圧縮。 gRPCでは、ストリーミングRPCはメッセージを圧縮するかどうかを決定できます。たとえば、単一のストリーム（または実際に圧縮可能な混合コンテンツ）でテキストと画像の混合をストリーミングしている場合、画像の圧縮をオフにすることができます。これにより、圧縮されたデータを圧縮する必要がなくなります。圧縮されたデータは小さくなりませんが、CPUを燃焼させます。
- ファーストクラスの負荷分散。ポイントツーポイント接続の改善ではありませんが、gRPCはトラフィックを送信するバックエンドをインテリジェントに選択できます。 （これはライブラリ機能であり、ワイヤプロトコル機能ではありません）。これは、プロキシを使用することなく、負荷の最も少ないバックエンドサーバーにリクエストを送信できることを意味します。これはレイテンシーの勝利です。
- 大幅に最適化されています。 gRPC（ライブラリ）は 連続ベンチマーク の下にあり、速度の低下がないようにします。これらのベンチマークは常に改善されています。繰り返しますが、これはプロトコルgRPCとは何の関係もありませんが、プログラムはgRPCを使用した方が高速です。
Nfirvineが言ったように、Protobufを使用するだけでパフォーマンスの改善の大部分がわかります。あなたはcouldRESTでprotoを使用できますが、gRPCと非常にうまく統合されています。技術的には、gRPCでJSONを使用できますが、ほとんどの人はプロトに慣れた後はパフォーマンスコストを支払いたくありません。
私は決してこれに関する専門家ではなく、これをバックアップするデータもありません。
あなたが話している「バイナリ機能」は、HTTP/2フレームのバイナリ表現です。コンテンツ自体（JSONペイロード）は引き続きUTF-8です。 HTTP/1と同様に、そのJSONを圧縮してContent-Encoding: gzipを設定できます。
ただし、gRPCはgzip圧縮も行います。本当に、私たちはgzip圧縮されたJSONとgzip圧縮されたprotobufsの違いについて話している。
ご想像のとおり、圧縮されたprotobufは圧縮されたJSONをあらゆる点で上回るはずです。
JSONとプロトブフの普遍性に加えて、プロトブフを使用することの唯一の欠点は、たとえばtcpdumpの状況で.protoをデコードする必要があることです。