QGrpcHttp2Channel Class

詳細な説明

QGrpcHttp2Channel クラスはQAbstractGrpcChannel を実装しており、 gRPC™HTTP/2のフレーム形式による通信を可能にします。

HTTP/2 は、その前身である HTTP/1.1 に比べていくつかの利点があり、QGrpcHttp2Channel は、多重化された TCP 接続を使用することで、セキュリティや信頼性を損なうことなく、効率的な通信を必要とする高性能なリアルタイムアプリケーションに最適です。

このチャネルは、必要なカスタマイズを含むQGrpcChannelOptions を使用して構築することで、SSLサポート、カスタムserializationFormat 、またはその他のオプションでカスタマイズすることができます。

トランスポート方式

QGrpcHttp2Channelの実装では、指定されたhostUri 、scheme 、およびオプションに基づいて、異なる転送方式が優先的に選択されます。以下の基準が適用されます：

Content-Type

HTTP/2上のgRPC におけるContent-Typeは、メッセージのシリアライズ形式を決定します。これはapplication/grpc で始まり、接尾辞を含めることができます。形式は以下のスキームに従います：

"content-type": "application/grpc" [("+proto" / "+json" / {custom})]

例：

• application/grpc+proto は Protobuf エンコーディングを指定します。
• application/grpc+json は、JSONエンコーディングを指定します。

シリアライズ形式は、メタデータ内でcontent-type を指定するか、serializationFormat を直接設定することで構成できます。デフォルトでは、application/grpc のコンテンツタイプが使用されます。

content-type メタデータを使用して、QGrpcHttp2ChannelをJSONシリアライズ形式で設定するには：

auto jsonChannel = std::make_shared<QGrpcHttp2Channel>(
    QUrl("http://localhost:50051"_L1),
    QGrpcChannelOptions().setMetadata({
        { "content-type"_ba, "application/grpc+json"_ba },
    })
);

カスタムシリアライザとcontent-type を使用する場合は、シリアライズ形式を直接設定できます:

class DummySerializer : public QAbstractProtobufSerializer
{
    ...
};
QGrpcSerializationFormat dummyFormat("dummy", std::make_shared<DummySerializer>());

auto dummyChannel = std::make_shared<QGrpcHttp2Channel>(
    QUrl("http://localhost:50051"_L1),
    QGrpcChannelOptions().setSerializationFormat(dummyFormat)
);

これにより、dummy というサフィックスが付いたメッセージのエンコードおよびデコードにDummySerializer が使用されます。HTTP/2トランスポートの場合、これによりコンテンツタイプはapplication/grpc+dummy となります。

予約済みメタデータキー

メタデータはHTTP/2ヘッダーとして送信されます。キーは大文字小文字を区別しないASCII文字列であり、値はASCII文字列またはバイナリデータです。以下のキーはHTTP/2またはgRPC プロトコルによって予約されており、リクエストが構築される際にユーザーメタデータから除外されます:

• HTTP/2 疑似ヘッダー（: で始まるすべてのキー）。
• grpc- またはqtgrpc- で始まるすべてのキー。
• te、content-type 、user-agent 。

ユーザーが指定したcontent-type は、シリアライザの自動検出のためにチャネル構築時に引き続き参照されます（Content-Type を参照）。ただし、これは Custom-Metadata エントリとして転送されることはありません。

HTTP/2 ヘッダーの詳細については、RFC 7540 のセクション 8.1.2 を参照してください。

受信ウィンドウ

HTTP/2 のフロー制御は、受信者が確認応答を行う前に送信者が送信できるデータ量を制限します。チャネルは、受信ウィンドウという 2 つの制限をサーバーに通知します。

• ストリームウィンドウは、単一の RPC における未確認データの最大量に上限を設けます。
• 接続ウィンドウは、1つの接続を共有するすべてのRPCの未確認データを合計した量に上限を設けます。

ウィンドウは転送中のデータ量を制限するものであり、転送サイズの制限ではありません。確認応答にはネットワークの往復1回分かかるため、ウィンドウはスループットの上限も設定します：

maximum throughput = window / round-trip time

両方のウィンドウは、環境変数を通じてバイト単位で設定されます：

• QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE ストリームウィンドウ用（デフォルトは4 MiB ）
• QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE 接続ウィンドウ用（デフォルトはストリームウィンドウの4倍、16 MiB ）

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE のみを設定すると、接続ウィンドウは自動的にストリームウィンドウの4倍にスケールされます。異なる比率を使用するには、QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE を明示的に設定してください。

デフォルト値は、ローカルネットワークやほとんどのインターネット経路では帯域を飽和させてしまいます。一方、高速なリンクで往復時間が長い場合には不十分です。例えば、アプリケーションが遠方のサーバーから大きなメッセージを受信する場合を考えてみましょう。

link: 1 Gbit/s (125 MB/s), 100 ms round-trip time

サーバーは1つのストリームウィンドウ分のデータを送信し、その後、確認応答を1往復分待ちます。デフォルトのウィンドウでは、100 msごとに最大4 MiBを送信します：

4 MiB / 0.1 s = 42 MB/s, 34% of the 125 MB/s the link carries

リンクを飽和させるには、ウィンドウが1回の往復通信中にリンクから送信されるすべてのデータ、つまりリンクの帯域幅遅延積（BDP）を保持する必要があります：

BDP = 125 MB/s x 0.1 s = 12.5 MB

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=12500000
12.5 MB / 0.1 s = 125 MB/s, the link is saturated

並行して実行される RPC は、単一の接続受信ウィンドウを共有します。すべてのストリームが継続的に読み込まれている限り、転送中のデータ総量は BDP の範囲内に収まります。しかし、あるストリームが読み込まれない場合、そのバッファされたデータが共有接続ウィンドウの一部を占有し、他のストリームをブロックする可能性があります。 経験則として、接続ウィンドウのサイズは、同時にアクティブなすべてのストリームウィンドウの合計に合わせて設定するのが良いでしょう。上記のリンクで8つの転送を並行して行う場合：

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=12500000       (12.5 MB = BDP)
QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE=100000000  (8 x 12.5 MB)

各RPCは、それが唯一のアクティブな転送である場合、125 MB/sをフルに利用できます。8つのRPCが並行して実行される場合、各RPCはおよそ15 MB/sずつリンクを共有することになります。最悪の場合、アプリケーションがすべてのストリームからの読み取りを停止すると、チャネルには最大100 MBのデータがバッファリングされる可能性があります。

あるいは、ストリームウィンドウのサイズを、BDPに等しい接続ウィンドウにまとめて収まるように設定する方法もあります。これにより、バッファに蓄積されるデータの最大量は制限されますが、たとえ単独で転送を行っている場合でも、各RPCは割り当てられたシェア内に制限されます：

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=1562500        (12.5 MB / 8)
QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE=12500000   (= BDP)

各RPCは、単独で転送する場合でも他の7つのRPCと並行して転送する場合でも、およそ15 MB/sに制限されます。この利点は、チャネルが未読データを最大で約12.5 MB以上バッファリングすることがないことです。

転送遅延の最小化がメモリ使用量よりも重要である場合は、フルサイズのストリームウィンドウを使用します。メモリ消費量の抑制が優先される場合は、より小さなストリームウィンドウを使用します。いずれの場合も、複数のストリームウィンドウを収容できる十分な大きさの接続ウィンドウを維持してください。そうしないと、1つの未読み取りストリームだけで共有接続ウィンドウが枯渇し、他のすべてのRPCがブロックされてしまう可能性があります。

どちらのウィンドウも、最大2147483647 バイトまでの値を受け付けます。ストリームウィンドウの下限は1024 バイトであり、これによりメモリに制約のある受信側はストリームごとのバッファリングを制限できます。接続ウィンドウの下限は65535 バイトであり、これはプロトコルの初期ウィンドウです。

環境変数によるフォールバック

一部のチャネル設定は、環境変数を介して設定できます。これらは、各チャネルが構築される際に評価されます。環境変数が設定されていない場合は、組み込みのデフォルト値が使用されます。