简体中文（ZH-CN）English（EN）繁体中文（ZH-TW）日本語（JA）한국어（KO）Melayu（MS）Français（FR）Deutsch（DE）
ホームページ
記事
に質問
コース
特集
ダウンロード
ゲーム
辞書
最近の更新

ホームページ  >  記事  >  バックエンド開発  >  grpc は go 言語のみをサポートしますか?

grpc は go 言語のみをサポートしますか?

青灯夜游
青灯夜游オリジナル
2022-12-16 15:51:295364ブラウズ

grpc は Go 言語だけをサポートしているわけではありません。 grpc は HTTP/2 に基づく通信プロトコルで、多言語 RPC フレームワークをサポートしています。現在、C、Java、Go 言語バージョン (grpc、grpc-java、grpc-go) が提供されています。C バージョンは C、C、Node.js をサポートしています。 、Python、Ruby、Objective-C、PHP、C# がサポートされています。

grpc は go 言語のみをサポートしますか?

このチュートリアルの動作環境: Windows 7 システム、GO バージョン 1.18、Dell G3 コンピューター。

grpc とは

gRPC は HTTP/2 に基づく通信プロトコルで、多言語 RPC フレームワークをサポートし、モバイルおよび HTTP/ 向けに設計されています。 2. gRPC は HTTP/2 標準に基づいて設計されており、単一の TCP 接続上で双方向ストリーミング、フロー制御、ヘッダー圧縮、リクエストの多重化などの機能を提供します。これらの機能により、モバイル デバイスでのパフォーマンスが向上し、電力とスペースが節約されます。

RPC：Remote Procedure Callの略で、リモートプロシージャコール（リモートメソッドコール、リモートコールとも訳せます）と訳され、コンピュータの通信プロトコルです。このプロトコルを使用すると、ネットワーク間、プラットフォーム間、言語間などの問題を心配することなく、ローカル サービスを呼び出すのと同じくらい簡単にリモート サービスを呼び出すことができます。

gRPC メッセージのシリアル化方法では通常、Protobuf が使用されます。Protobuf はバイナリ形式で、サイズが小さく、ネットワーク転送が速く、占有帯域幅とトラフィックが少なく、呼び出しパフォーマンスが高くなります。

grpc は go 言語のみをサポートしますか?

gRPC の機能

  • IDL

    gRPC ProtoBuf を使用してサービスを定義する ProtoBuf は、Google によって開発されたデータ シリアル化プロトコル (XML、JSON に似ています)。 ProtoBuf はデータをシリアル化でき、データ ストレージ、通信プロトコルなどで広く使用されています。

  • 多言語サポート

    gRPC は複数の言語をサポートしており、言語に基づいてクライアントおよびサーバー関数ライブラリを自動的に生成できます。現在、C版grpc、Java版grpc-java、Go版grpc-goが提供されており、このうちgrpcはC、C、Node.js、Python、Ruby、Objective-C、PHP、C#などの言語に対応しています。 . grpc-java には Android 開発のサポートがあります。

  • HTTP2

    gRPC は HTTP2 標準に基づいて設計されており、双方向ストリーミング、ヘッダー圧縮、リクエストの多重化など、より強力な機能を備えています。これらの機能は、帯域幅の節約、TCP リンク時間の短縮、CPU 使用率の節約、バッテリ寿命の延長などの大きなメリットをもたらします。同時に、gRPC はクラウド サービスや Web アプリケーションのパフォーマンスも向上させることができます。 gRPC はクライアント側とサーバー側の両方に適用できるため、クライアントとサーバー間の通信が透過的に実現され、通信システムの構築が簡素化されます。

grpc を使用する必要がある理由

  • 優れたエコロジー: Google による支援。たとえば、nginx は grpc のサポートも提供します。 : たとえば、protobuf のパフォーマンスは json よりも高く、http2.0 のパフォーマンスは http1.1 よりも高くなります。

  • 強力な型指定: コンパイラが問題の大部分を解決します。

  • ストリーミング処理 (http2.0 ベース): クライアント ストリーミング、サーバー ストリーミング、および双方向ストリーミングをサポート

  • 概要grpc の利点を実現

1. grpc の高いパフォーマンス: protobuf が json より優れているのはなぜですか?

1) protobuf とは何ですか?

Protobuf は、異なるサービス間でデータをシリアル化するために Google によって開発されたバイナリ形式です。これは IDL (インターフェース記述言語) 言語です。

2) json よりどれくらい速いですか?

  • 6 倍高速です。
    • 参考リンク

3) protobuf が json より速いのはなぜですか?
    • protobuf のバイナリ データ フローと json データ フローは次のとおりです。

    • json データと protobuf データ形式を比較すると、
    • サイズが小さい - 区切り文字は必要ありません: TLV 保存方法は区切り文字を必要としません。区切り文字 (カンマ、二重引用符など) でフィールドを区切ることができるため、区切り文字の使用を減らすことができます。
    • サイズが小さい空のフィールドは省略されます: フィールドにフィールド値が設定されていない場合、フィールドがシリアル化されるときのデータはまったく存在しません。つまり、エンコードは必要ありません。json はキーと null 値の値を渡します。
    • 小さいサイズのタグのバイナリ表現: フィールドの数値を使用して、それを次のように変換します。バイナリ表現は、JSON キーの文字列表現よりもスペースを節約します。
    • エンコードとデコードは高速です。: tag にはフィールドの型が格納されており、値の長さを直接知ることができます。また、value が文字列の場合は、length を使用して長さを格納します。length から n バイトを直接取得して、value の値を取得できます。値の長さが不明なので、文字列マッチングを行う必要があります
    • protobuf エンコーディングの詳細については、: varint および zigzag エンコーディング メソッド
    を参照してください。

    #2. grpc の高いパフォーマンス: http2.0 が http1.1 よりもパフォーマンスが高いのはなぜですか?

    1) 多重化

    • http2.0 と http 1.* および http1.1pipling の比較

      概略図

    grpc は go 言語のみをサポートしますか?

      #http/1.
    • *: 1 つのリクエスト、1 つの応答、接続が確立され、完了後に閉じられます。各リクエストは接続を確立する必要があります。
      • http1.1 パイプリング
    • : パイプリング ソリューションは、複数のリクエストをキューに入れることです。シリアル化されたシングル スレッド処理、その後のリクエストは、実行の機会を得る前に、前のリクエストが返されるのを待ちます。リクエストがタイムアウトすると、後続のリクエストはブロックすることしかできず、方法はありません。これは、人々がよくヘッドオブラインブロッキングと呼ぶものです
      • http2
    • : 1 つの接続上で複数のリクエストを同時に並行して実行できます。特定のリクエスト タスクは時間がかかりますが、他の接続の通常の実行には影響しません。
      • grpc 多重化のその他の利点は何ですか
      • TCP を削減します。この接続により、サーバーとクライアントのメモリ、CPU などの負荷が軽減されます。
      • TCP 接続が軽減され、TCP の再確立が頻繁にトリガーされなくなり、スロー スタートが頻繁に発生することがなくなります
      • TCP 接続を削減し、ネットワークの輻輳を改善します
      http/1.1 では多重化が実現できないのに、http2.0 では多重化が実現できるのはなぜですか?
      • http/1.1 伝送はテキストを使用するのに対し、http2.0 はバイナリ フレーム伝送を使用するためです
    2) ヘッダー圧縮

      固定フィールド圧縮
    • : http では http を介して本文を gzip 圧縮できるため、帯域幅を節約できますが、メッセージのヘッダーには圧縮されていないフィールドも多数あります。 Cookie などの圧縮、ユーザー エージェントの受け入れ、これらは圧縮する必要があります
      • 重複を避ける
    • : 多くのフィールド値は、多数の要求および応答メッセージで繰り返されるため、重複を避けるために必要です パフォーマンス
      • エンコーディングの改善
    • : フィールドは ASCII エンコードされており、非効率的です。バイナリ エンコーディングに変更すると改善できます上記は
      • HPACK アルゴリズム
    • 、アルゴリズムは主に 3 つの部分で構成されます
      • 静的辞書: 一般的に使用されるヘッダー フィールドを、{":method":"GET"} などの辞書に変換します。単一の数値 2
      • 動的辞書:静的辞書にヘッダー フィールドがない場合は、動的辞書を使用します
      • ハフマン エンコード:圧縮エンコード
    3) バイナリ分割フレーム

    バイナリ フレーム層では、HTTP 2.0 は送信されるすべての情報をより小さなメッセージとフレームに分割し、それらをバイナリ形式でエンコードします。 HTTP1.x ヘッダー情報はヘッダー フレームにカプセル化され、リクエスト本文はデータ フレームにカプセル化されます。
    • この方法でフレーム化した後、これらのフレームを順不同で送信し、各フレームのヘッダーのストリーム識別子に従って組み立てることができます。
    • http/1.1# と比較してください。 ##テキストに基づいているため、各 key:value を改行文字で分割すると、次の問題が発生します。
    • は、一度に 1 つのリクエストまたは応答しか処理できません。この種のデータは分割されるためです。区切り文字を含むメッセージは、完了するまで解析を停止できません。
        • この種のデータの解析に必要なメモリ量を予測することは不可能であり、サーバーに多大な負荷がかかります
      • #4) サーバーはリソースをアクティブにプッシュします
    • サーバーはリソースをアクティブにプッシュするようにサポートされているため、一部のリクエストは省略できます。たとえば、1.html と 1.css という 2 つのファイルが必要な場合、それが http1.0 であれば、2 回リクエストする必要があり、サーバーはそれを 2 回返します。ただし、http2.0 では、クライアントが 1 回リクエストすると、サーバーは 2 回直接応答します。

    プログラミング関連の知識の詳細については、プログラミング入門を参照してください。 ！

以上がgrpc は go 言語のみをサポートしますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

Python Java php ruby objective-c nginx node.js json css html 封装 Cookie xml 标识符 字符串 Length Interface 线程 Go语言 JS ASCII 算法 android objective-c http rpc
声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
前の記事：Go 言語は手動でメモリを管理する必要がありますか?次の記事：Go 言語は手動でメモリを管理する必要がありますか?

関連記事

続きを見る