1

仕様が言うように：

フロー制御は接続に固有です。どちらのタイプのフロー制御も、エンドツーエンド パス全体ではなく、1 つのホップのエンドポイント間で行われます。

そして6.9 WINDOW_UPDATEでは

どちらのタイプのフロー制御もホップバイホップ、つまり 2 つのエンドポイント間のみです。仲介者は、従属接続間で WINDOW_UPDATE フレームを転送しません。ただし、受信者によるデータ転送のスロットリングは、フロー制御情報を元の送信者に間接的に伝播させる可能性があります。

しかし、これはどのように可能ですか？すべての仲介者が理解h2またはh2cプロトコルする必要があるようですが、2 つの質問があります。

  1. HTTP/2 は比較的新しい標準であり、多くの Web サイトで有効になっているのを見てきました (私のブログを含む)。問題なくこれらの Web サイトにアクセスできますが、それは、ルーターやハブなどの途中のすべての中間デバイスが、独自の HTTP/2 スタックとフロー制御アルゴリズムを既に実装していることを意味しますか (RFC7540 はフロー制御アルゴリズムを規定していないため)。

  2. ほとんどの Web サイトでは、アプリケーション層のデータを暗号化するh2ではなく を使用しています。h2cHTTP/2 のフロー制御は、アプリケーション層のデータでもあるフレームを送信する受信者によって行われWINDOW_UPDATEます。では、中間デバイスはこれらのデータが何であるかをどのように知るのでしょうか? データを復号化してその部分を見ることができない場合、フレームWindow Size Incrementを転送せずにフロー制御をどのように達成するのでしょうか?WINDOW_UPDATE

ここに画像の説明を入力

4

2 に答える 2

4

まず、いくつかの修正。

トークンh2cは、平文の HTTP/2 を参照します (したがって のc) h2c。2 番目の箇条書きでは、ほとんどの Web サイトで使用されていると述べていますが、実際にはほとんど使用されていません。ブラウザーが実装していないためです。Web サイトの大多数はh2.

トークンh2は、暗号化されたh2c、または同等h2cの TLS を参照します。

クライアントとサーバーが話すためにネゴシエートするとき、クライアントh2が送信するバイトは暗号化され、サーバーまでずっと暗号化されて移動します。これは、仲介者がトラフィックを復号化する機会がないことを意味します (ありがとうございます)。

この場合、HTTP/2 仕様で参照される「ホップ」は、クライアントとサーバーの間のネットワーク セグメント全体です。

ただし、HTTP/2 仕様は汎用的である必要があり、HTTP/2 などのワイヤ プロトコルを定義するときにブラウザーと Web サーバーがどのように対話するかについて心配する必要はありません。

server1クライアントが を使用して HTTP/2 リクエストを実行し、リクエストを満たすために を呼び出す必要がある状況を想像してくださいh2。server1今回server2は を使用しh2cます。たとえば、server1いくつかのロジックに応じて「正しい」バックエンド サーバーに要求を転送するフロントエンドの「プロキシ」である可能性があります。

この場合、client-server1 と server1-server2 の 2 つのホップがあります。

各ホップは独自のフロー制御を適用します。

たとえば、クライアントが大きなファイルをサーバーにアップロードするとします。通常、クライアント フロー制御の送信ウィンドウは小さく、たとえばデフォルトの 65535 オクテットです。クライアントは、アップロードを停止する前に最大 65535 オクテットしか送信できません。

これらの 65535 オクテットは によって受信されserver1ます。server1と通信するために、 がクライアントになりますserver2。server1のクライアントが と通信するときに、はるかに小さいフロー制御ウィンドウ、たとえば 16384 オクテットで構成されているとしますserver2。

この例でserver1は、アップロードを 16384 オクテット後に停止し、残りの 65535 ～ 16384 オクテットを維持して、アップロードされたデータが消費されたことを (WINDOW_UPDATE フレーム経由で) 通知するのをserver2待つ必要があります。server2

server1のクライアントが から WINDOW_UPDATE を受信するとserver2、さらにデータを に送信できますserver2。また、クライアントに WINDOW_UPDATE を送信するか (クライアントとのフロー制御ウィンドウに16384 オクテットを追加する余地があるため)、もう少し待つかどうかを決定する必要があります。たとえば、別の 16384 オクテットをに送信しserver2、 から 2 番目の WINDOW_UPDATE を受信したときにのみserver2、クライアントに WINDOW_UPDATE を送信することを決定できます (16384 + 16384 オクテットの更新を含む)。

上記の例からわかるように、クライアント と の間のフロー制御は、 と の間のフロー制御に関連server1していますが、独立しています。server1server2

フロー制御戦略の実装に関する議論については、この回答を読むこともできます。

于 2016-11-22T20:25:11.170 に答える
1

ホップ/仲介者の意味に依存します。

仲介者が下位レベル (TCP ゲートウェイ、NAT、スイッチなど) にある場合、HTTP/2 フロー制御は HTTP/2 クライアントとサーバーの間でエンドツーエンドで適用されるため、仲介者は HTTP/2 に対して透過的です。それらの間の個々のホップは、低レベルのフロー制御メカニズムを使用する場合があります。

仲介者が HTTP プロキシの場合、基本的に 2 つの別々の HTTP リクエストが進行中であり、それぞれが独自のフロー制御を適用します。プロキシ アプリケーションには、フロー制御プロパティを保持しながら、これらの個々のホップを接続する責任があります。たとえば、2 番目のホップから応答全体を一度に読み取るのではなく、それを最初のホップに転送するだけで、適切なデータのチャンクをストリーミングします。

HTTP プロキシの場合、HTTP/1.1 を HTTP/2 にプロキシしたり、その逆を行ったりする状況さえ発生します。このような状況では、プロキシは HTTP/2 フロー制御メカニズムを使用してそのホップのフロー制御を保証し、TCP フロー制御を使用して他のホップのフロー制御を提供します。プロトコル タイプがプロキシ アプリケーションで適切にカプセル化されている場合 (つまり、RequestおよびResponseタイプのフロー制御を尊重するストリーミング操作が提供されることを意味します)、異なるプロトコル タイプ間でストリームをプロキシすることはそれほど難しくありません。

于 2016-11-23T18:27:33.307 に答える