Zenn
Open3

grpc, grpc-web, connectの違いなど

gRPC
#
HTTP2
#
grpcweb
#
rpc
#
connect
ピン留めされたアイテム
nitakingnitaking

gRPC, gRPC-web, Connectの違いについて説明できるほど知識が整理できないのでまとめる。

nitakingnitaking

gRPC

  • gRPC: Google製、OSSのリモートプロシージャコール（[1]）システム。

RPC

  • RPCは別のアプリケーションの処理を直接呼び出す仕組み。（直訳で遠隔手続き呼び出しの意味）
    • RPC自体は歴史ある技術だが、gRPC自体の歴史は浅い（2015年2月 [2]）

RESTとgPRC

  • RESTはリソース思想が強く、リソース（オブジェクト）を起点にHTTPメソッドで操作する
  • gRPCはメソッド呼び出しを起点に、データを操作する
  • 思想の方向性が逆なので比較の対象となりやすい
  • HTTP/2をベースにしているため、低レイテンシ、高パフォーマンス

HTTP/2

  • データはテキストではなくバイナリ。小容量で転送可能であり効率が良い。
  • 1コネクションで複数リクエスト/レスポンスがやり取りできる
    • Stream という単位で、HTTPリクエスト・HTTPレスポンスを多重化し扱う。ストリーム＝多重化？[3][4]
  • 1HTTPリクエスト・1HTTPレスポンス＝1つのストリームに所属
    • HTTPレスポンスが返るとストリームは使われなくなる
  • フレーム
    • HTTP/1.1ではテキスト形式だが、HTTP/2ではフレームというバイナリ形式でメッセージをやりとりする
  • リクエストのたびに通信を切断する必要がなく、ヘッダーを都度送信する必要もないので効率的。故にマイクロサービスと相性がよく、運用実績が多い。それぞれのAPIがプライベート通信でネットワーク通信するため、応答速度が全体のボトルネック隣りやすいため。

HTTP/2 フレーム

chatGPTに出力させたフレーム一覧は以下。（精査中）

フレームタイプ フレームタイプ番号 説明
DATA 0 データフレームは実際のペイロードデータを含み、HTTPボディ部分を転送します。
HEADERS 1 ヘッダフレームはHTTPヘッダ情報を転送します。HTTPリクエストやレスポンスの開始を示します。
PRIORITY 2 プライオリティフレームはストリームの優先順位と依存関係を表現します。
RST_STREAM 3 RST_STREAMフレームは特定のストリームの終了を示します。エラー発生時によく使用されます。
SETTINGS 4 SETTINGSフレームはHTTP/2接続の設定値を伝達します。
PUSH_PROMISE 5 PUSH_PROMISEフレームはサーバからのリソースのプッシュを表現します。
PING 6 PINGフレームは接続の生存性を確認するために使用されます。
GOAWAY 7 GOAWAYフレームは接続の終了を通知します。
WINDOW_UPDATE 8 WINDOW_UPDATEフレームはフロー制御のウィンドウサイズを調整します。
CONTINUATION 9 CONTINUATIONフレームはHEADERSやPUSH_PROMISEといったフレームのシーケンスを続けます。
脚注

  1. 「あるプログラムがネットワーク上の異なる場所に配置されたプログラムを呼び出して実行すること」
    引用：武上 将樹. スターティングgRPC (Japanese Edition) (p.9). Kindle 版. ↩︎

  2. https://developersjp.googleblog.com/2015/03/http2rpcgrpc.html
    武上 将樹. スターティングgRPC (Japanese Edition) (p.24). Kindle 版. ↩︎

  3. https://knowledge.sakura.ad.jp/7734/ ↩︎

  4. https://www.nic.ad.jp/ja/newsletter/No68/0800.html ↩︎

nitakingnitaking

gRPC / protobuf

gPRCは protobuf を利用しており、効率的なデータシリアライゼーションを可能にしている。

効率的なデータシリアライゼーションとは？

  • データサイズが小さい：バイナリなので、JSONやXMLより小さいサイズで表現可能。ネットワーク上の転送速度が高速に。
  • パース速度が高速：バイナリ形式なのでJSONとXMLよりパース（データ読み込み・解釈）が高速
  • 言語互換性：多くの言語で利用可能＝対応言語間で用意にやり取り可能
  • スキーマによる型安全：データ形式をスキーマで定義することにより、構造と型が明示され、間違ったデータ形式を防ぐ。

Connectとは

弊社CTO記事を拝読するのがよいのだが

https://www.awarefy.dev/blog/better-grpc-connect-go/
https://buf.build/blog/connect-a-better-grpc
https://connect.build/docs/introduction/?ref=awarefy.dev#seamless-multi-protocol-support

Connectにすることで、gRPC, Connect, gRPC-Webの３つのプロトコルをサポート[1]され、gRPC-Webの場合に（Envoyなどの）プロキシが必要だったが、それが不要になる。

Connectプロトコル：HTTP/1.1またはHTTP/2で動作する、gRPCでも動作し、gRPC-Webでも動作します。
gRPC-Webプロトコル：gRPC通信をWebで利用するためのプロトコル。ブラウザでも動作するように制限に合わせたプロトコル定義。

なぜgRPC-WebではEnvoy が必要になるのか？

主要なブラウザはHTTP/2をサポートしている。しているのだがHTTP/2で通信する場合はHTTP/2で通信、そうでない場合は勝手にHTTP/1.1にフォールバックするとのこと。つまりWEBブラウザからの通信にはHTTP/2での通信であることを担保することができない。これにより、HTTP/1.1での通信をプロキシがHTTP/2にトレースすることでgRPCサーバーと通信をすることが可能になり、プロキシが必要な理由である。

EnvoyはgRPC-Webのプロキシとして使用されるツールの一つである。
gRPC-WebのリクエストをgRPCリクエスト（HTTP/2）に変換し、gRPCサーバへ転送する。

https://symthy.hatenablog.com/entry/2022/09/24/160309

Connectは前述したとおり、

Connectにすることで、gRPC, Connect, gRPC-Webの３つのプロトコルをサポート[1:1]され、gRPC-Webの場合に（Envoyなどの）プロキシが必要だったが、それが不要になる。

ということでプロキシが担っていた役割もConnectが果たしており、プロキシなしでのWebからのgRPC通信が可能になった。

脚注

  1. https://www.awarefy.dev/blog/better-grpc-connect-go/ ↩︎ ↩︎