gRPC（HTTP / 2）はHTTP / 2を使用したRESTよりも高速ですか？

96

目標は、遅延とネットワークスループットが優れたトランスポートおよびアプリケーション層プロトコルを導入することです。現在、アプリケーションはHTTP / 1.1でRESTを使用しており、待ち時間が長くなります。このレイテンシーの問題を解決する必要があり、gRPC（HTTP / 2）またはREST / HTTP2のいずれかを使用できます。

HTTP / 2：

  1. 多重化
  2. 単一のTCP接続
  3. テキストではなくバイナリ
  4. ヘッダー圧縮
  5. サーバープッシュ

私は上記のすべての利点を認識しています。質問1：HTTP / 2でRESTを使用すると、HTTP / 1.1でRESTと比較するとパフォーマンスが大幅に向上すると確信していますが、これはgRPC（HTTP / 2）とどのように比較されますか？

また、gRPCがproto bufferを使用していることも認識しています。これは、ネットワーク上で構造化データを送信するための最良のバイナリシリアル化手法です。Proto Bufferは、言語にとらわれないアプローチの開発にも役立ちます。私はそれに同意し、graphQLを使用してRESTに同じ機能を実装できます。しかし、私の懸念はシリアル化に関するものです。質問2：HTTP / 2がこのバイナリ機能を実装する場合、proto bufferを使用すると、HTTP / 2に加えて追加の利点が得られますか？

質問番号：3の観点では、ストリーミング、双方向ユースケース、どのgRPCは（HTTP / 2）（RESTとHTTP / 2）と比較しますか？

非常に多くありますブログ/動画（RESTとHTTP / 1.1）でgRPC（HTTP / 2）を比較し、インターネットでのアウトは次のように、この。先に述べたように、GRPC（HTTP / 2）と（RESTとHTTP / 2）を比較することの違いと利点を知りたいと思います。

rest  http  google-cloud-platform  http2  grpc 
— ラクシュマンディワアカー
ソース
何を使うことになったのですか？HTTP2 + RESTのフレームワークはありますか？
— knocte 2017年
@knocte私はgPRCを使用することになりました。それは待ち時間をかなり短縮しました。HTTP / 2 + RESTに関しては、特定のフレームワークはありません。使用しているサーバーで変更する必要があるのは設定です。たとえば、nginxを使用している場合は、ドキュメントを調べてHTTP / 2を設定する手順を確認してください。
— ラクシュマンディワアカー2017年
また、HTTP /1.1が接続を再利用することを確認する必要があります。それ以外の場合は、「tcpコールドスタート」を検索します。gRPCはデフォルトで接続を再利用します。
— bohdan_trotsenko 2018年

回答:

93

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

  • 選択的なメッセージ圧縮。gRPCでは、ストリーミングRPCはメッセージを圧縮するかどうかを決定できます。たとえば、単一のストリーム（または実際には任意の混合圧縮可能コンテンツ）で混合テキストと画像をストリーミングしている場合は、画像の圧縮をオフにすることができます。これにより、圧縮済みのデータを圧縮する必要がなくなります。データは小さくなりませんが、CPUが消費されます。
  • ファーストクラスの負荷分散。ポイントツーポイント接続の改善ではありませんが、gRPCはトラフィックを送信するバックエンドをインテリジェントに選択できます。（これはライブラリ機能であり、ワイヤプロトコル機能ではありません）。これは、プロキシを使用せずに、最も負荷の少ないバックエンドサーバーにリクエストを送信できることを意味します。これはレイテンシーの勝利です。
  • 大幅に最適化されています。gRPC（ライブラリ）は、速度の低下がないことを保証するために継続的なベンチマークの下にあります。これらのベンチマークは常に改善されています。繰り返しますが、これはgRPCプロトコルとは何の関係もありませんが、gRPCを使用した方がプログラムは高速になります。

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

— カール・マスタンジェロ
ソース
答えてくれてありがとう@Carl。上記のすべてを説明するリンク/ドキュメントとベンチマークのリンクを教えてください。
— ラクシュマンディワアカー2017
3
ダッシュボードにリンクするように応答を更新しました。これらを直接説明するドキュメントはありませんが、私は中心的な貢献者です。
— Carl Mastrangelo 2017
ロードバランシングを提供してくださいlibraryリンク
— BozoJoe
15

私は決してこれに関する専門家ではなく、これを裏付けるデータもありません。

あなたが話している「バイナリ機能」は、HTTP / 2フレームのバイナリ表現です。コンテンツ自体（JSONペイロード）は引き続きUTF-8です。Content-Encoding: gzipHTTP / 1と同じように、そのJSONを圧縮して設定できます。

しかし、gRPCはgzip圧縮も行います。つまり、実際には、gzipで圧縮されたJSONとgzipで圧縮されたprotobufsの違いについて話しているのです。

ご想像のとおり、圧縮されたプロトブフはあらゆる点で圧縮されたJSONを打ち負かす必要があります。そうしないと、プロトブフは目標を達成できませんでした。

JSONとprotobufsの遍在性に加えて、protobufsを使用することで私が見ることができる唯一の欠点は、たとえばtcpdumpの状況で、それらをデコードするために.protoが必要なことです。

— nfirvine
ソース
1
質問に対するご意見をありがとう@nfirvine。シリアル化機能はちょっと理にかなっています。RESTとgRPCでシリアル化がどのように行われるかについての詳細/説明を追加できますか？あなたが同じ上でいくつかのリンクを共有することができれば、それは素晴らしいことです。
— ラクシュマンディワアカー2017
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.