protobuf vs gRPC

Question 1

私はprotobufとgRPCを理解し、両方をどのように使用できるかを理解しようとしています。次のことを理解するのを手伝っていただけませんか。

OSIモデルを考えると、たとえば、レイヤー4のProtobufはどこにありますか？
メッセージ転送を通して考えると、「フロー」はどのようになっていますか、gRPCはprotobufが見逃していることを何をしていますか？
送信者がprotobufを使用する場合、サーバーはgRPCを使用できますか、それともgRPCはgRPCクライアントのみが配信できるものを追加しますか？
gRPCが同期および非同期通信を可能にする場合、Protobufはマーシャリング専用であるため、状態とは何の関係もありません-trueまたはfalse？
RESTやGraphQLの代わりに通信するフロントエンドアプリケーションでgRPCを使用できますか？

私はすでに知っています-または私がそうすると思います-それ：

Protobuf

データ交換用のバイナリプロトコル
Googleによる設計
クライアントとサーバーで生成された「構造」のような説明を使用して、メッセージをマーシャル解除します

gRPC

protobuf（v3）を使用します
再びグーグルから
RPC呼び出しのフレームワーク
HTTP / 2も利用します
同期および非同期通信が可能

すでにこのテクノロジーを使用している人にとっては、簡単な質問だと思います。それでも私を我慢して助けてくれてありがとう。また、ネットワークでテクノロジーを深く掘り下げてくれたことにも本当に感謝しています。

Question 2

プロトコルバッファは、インターフェイス定義言語およびシリアル化ライブラリです。

IDLでデータ構造を定義します。つまり、使用するデータオブジェクトを記述します。
ディスクからのデータの書き込み/読み取りなど、データオブジェクトをバイナリとの間で変換するルーチンを提供します。

gRPCは同じIDLを使用しますが、構文「rpc」を追加して、Protobufデータ構造をデータ型として使用してリモートプロシージャコールメソッドのシグネチャを定義できるようにします。

データ構造を定義します
rpcメソッド定義を追加します
ネットワークを介してメソッドシグネチャを提供および呼び出すためのコードを提供します
必要に応じて、Protobufを使用してデータオブジェクトを手動でシリアル化することもできます。

質問への回答：

gRPCはレイヤー5、6、7で機能します。Protobufはレイヤー6で機能します。
「メッセージ転送」と言うとき、Protobufは転送自体には関係しません。データ転送の両端でのみ機能し、バイトをオブジェクトに変換します
デフォルトでgRPCを使用するということは、Protobufを使用していることを意味します。Protobufを使用するがgRPCを使用しない独自のクライアントを作成してgRPCと相互運用したり、他のシリアライザーをgRPCにプラグインしたりできますが、gRPCを使用する方が簡単です。
本当
はい、できます

Question 3

実際、gRPCとProtobufはまったく異なる2つのものです。簡単にしましょう：

gRPCは、クライアントとサーバーが相互作用する方法を管理します（REST APIを備えたWebクライアント/サーバーのように）
protobufは単なるシリアル化/逆シリアル化ツールです（JSONと同じように）

gRPCには、サーバー側と、サーバーにダイヤルできるクライアント側の2つの側面があります。サーバーはRPC（つまり、リモートで呼び出すことができる関数）を公開します。そして、そこにはたくさんのオプションがあります：通信を保護する（TLSを使用する）、認証レイヤーを追加する（インターセプターを使用する）、...

クライアント/サーバーである必要のない任意のプログラム内でprotobufを使用できます。データを交換する必要があり、それらを強く型付けしたい場合は、protobufが優れたオプションです（高速で信頼性があります）。

そうは言っても、両方を組み合わせて、優れたクライアント/サーバーシステムを構築できます。gRPCがクライアント/サーバーコードになり、データプロトコルをprotobufします。

PS：このペーパーは、Goを使用してgRPCとprotobufを使用してクライアント/サーバーを構築する方法を段階的に示すために作成しました。

Question 4

grpcはグーグルによって構築されたフレームワークであり、グーグル自体からの本番プロジェクトで使用され、＃HyperledgerFabricはgrpcで構築されていますgrpcで構築された多くのオープンソースアプリケーションがあります

protobuffはjsonのようなデータ表現であり、これもgoogleによるものです。実際、本番プロジェクトで数千のprotoファイルが生成されています。

grpc

gRPCは、Googleによって開発されたオープンソースフレームワークです。
これにより、RPCの要求と応答を作成し、フレームワークによって残りを処理できます。
RESTはCRUD指向ですが、grpcはAPI指向です（制約なし）
HTTP / 2の上に構築する
>>>>>認証、負荷分散、監視、ロギングを提供します
[HTTP / 2]
- HTTP1.1はずっと前に1997年にリリースされました
- HTTP1は、リクエストごとにサーバーへの新しいTCP接続を開きます
- ヘッダーは圧縮されません
- サーバープッシュはありません。Req、Resでのみ機能します。
- 2015年にリリースされたHTTP2（SPDY）
- 多重化をサポート
- クライアントとサーバーは、同じTCP接続を介してメッセージを並行してプッシュできます
- レイテンシーを大幅に削減
- HTTP2はヘッダー圧縮をサポートしています
- HTTP2はバイナリです
  - プロトバフはバイナリなので、HTTP2に最適です。
[タイプ]
- 単項
- クライアントストリーミング
- サーバーストリーミング
- 双方向ストリーミング
- grpcサーバーはデフォルトで非同期です
- grpcクライアントは同期または非同期にすることができます

プロトバフ

プロトコルバッファは言語に依存しません
プロトコルバッファ（バイナリ形式）の解析はCPUに負担がかかりません
[ネーミング]
- メッセージ名にキャメルケースを使用する
- フィールドのunderscore_seperated
- 列挙型にはキャメルケースを使用し、値名にはCAPITAL_WITH_UNDERSCOREを使用します
【コメント】
- サポート //
- サポート /* */
【メリット】
- データは完全に入力されています
- データは完全に圧縮されています（帯域幅の使用量が少ない）
- コードを生成してコードを読み取るには、スキーマ（メッセージ）が必要です
- ドキュメントはスキーマに埋め込むことができます
- データはどの言語でも読み取ることができます
- スキーマはいつでも安全に進化できます
- XMLよりも高速
- コードが自動的に生成されます
- Googleはprotobuffを発明し、48000のprotobufメッセージと12000.protoファイルを使用します
- grpcを含む多くのRPCフレームワークは、プロトコルバッファを使用してデータを交換します