目標は、より優れたトランスポート層およびアプリケーション層プロトコルを導入することです。レイテンシーそしてネットワークスループット現在、アプリケーションは休むと1.1 のレイテンシーが高くなっています。このレイテンシー問題を解決する必要があり、HTTP/2 の実装またはREST/HTTP2。
HTTP/2:
- 多重化
- 単一のTCP接続
- テキストではなくバイナリ
- ヘッダー圧縮
- サーバープッシュ
私は上記の利点をすべて認識しています。質問1:もし私がHTTP/2 を使用した REST、私は、比較すると、大幅なパフォーマンスの向上が得られると確信していますHTTP/1.1 を使用した RESTしかし、これと比べるとHTTP/2 の実装?
gRPCはプロトバッファを使用していることも知っています。これはバイナリシリアル化構造化されたデータをネットワーク上で送信する技術。Proto buffer は言語に依存しないアプローチの開発にも役立ちます。私もこれに同意し、graphQL を使用して REST で同じ機能を実装できます。しかし、シリアル化について懸念しています。質問2:いつHTTP/2これを実装するバイナリ機能プロトバッファを使用すると、HTTP/2 に加えてさらに利点が得られますか?
質問3:に関してはストリーミング、双方向ユースケースgRPC(HTTP/2) は (REST および HTTP/2) とどのように比較されますか?
たくさんあるブログ/ビデオgRPC(HTTP/2)と(RESTとHTTP/1.1)を比較したインターネット上の記事これ前述のように、GRPC(HTTP/2)と(REST with HTTP/2)を比較した場合の違いや利点を知りたいです。
ベストアンサー1
gRPC はデフォルトでは HTTP/2 経由の REST より高速ではありませんが、それを高速化するためのツールを提供します。REST では困難または不可能なことがいくつかあります。
- 選択的なメッセージ圧縮。gRPC では、ストリーミング RPC はメッセージを圧縮するかしないかを決めることができます。たとえば、テキストと画像が混在するストリーム (または実際には圧縮可能な混合コンテンツ) を 1 つのストリームでストリーミングする場合、画像の圧縮をオフにすることができます。これにより、すでに圧縮されているデータを圧縮せずに済みます。圧縮されたデータは小さくなりませんが、CPU を消費します。
- ファーストクラスの負荷分散。ポイントツーポイント接続の改善ではありませんが、gRPC はトラフィックを送信するバックエンドをインテリジェントに選択できます。(これはライブラリ機能であり、ワイヤプロトコル機能ではありません)。つまり、プロキシを使用せずに、負荷が最も少ないバックエンドサーバーにリクエストを送信できます。これはレイテンシの削減につながります。
- 高度に最適化されています。gRPC（ライブラリ）は継続的なベンチマーク速度の低下がないことを確認するためです。これらのベンチマークは絶えず改善されています。繰り返しますが、これは gRPC プロトコルとは何の関係もありませんが、gRPC を使用することでプログラムはより高速になります。
nfirvineさんが言ったように、Protobufを使うだけでパフォーマンスの向上がほとんど見られます。できたREST で proto を使用すると、gRPC と非常にうまく統合されます。技術的には、gRPC で JSON を使用することもできますが、ほとんどの人は proto に慣れた後はパフォーマンス コストを支払いたくないでしょう。