HTTP / 2での多重化の意味


回答:


214

簡単に言えば、多重化により、ブラウザは同じ接続で一度に複数のリクエストを開始し、任意の順序でリクエストを受け取ることができます。

そして今、はるかに複雑な答えのために...

Webページをロードすると、HTMLページがダウンロードされ、CSS、JavaScript、画像のロードなどが必要であることがわかります。

HTTP / 1.1では、HTTP / 1.1接続で一度にダウンロードできるのは1つだけです。ブラウザはHTMLをダウンロードし、CSSファイルを要求します。それが返されると、JavaScriptファイルを要求します。それが返されると、最初の画像ファイルを要求します...など。HTTP/ 1.1は基本的に同期です-要求を送信すると、応答が得られるまで行き詰まります。これは、ほとんどの場合、ブラウザが要求を発し、応答を待ってから、別の要求を発し、次に応答を待っているため、ブラウザがあまり機能していないことを意味します。もちろん、 JavaScriptの多くはブラウザが多くの処理を行うことを必要としますが、それはダウンロードされるJavaScriptに依存するため、少なくとも最初は、HTTP / 1.1への遅延の継承により問題が発生します。通常、サーバーは

したがって、今日のWebの主な問題の1つは、ブラウザーとサーバー間で要求を送信する際のネットワーク遅延です。それは数十ミリ秒またはおそらく数百ミリ秒である場合がありますが、それほど多くはないように見えるかもしれませんが、それらは合計され、多くの場合Webブラウジングの最も遅い部分です-特にWebサイトはより複雑になり、追加のリソース(必要に応じて)とインターネットアクセスが必要になるためモバイル経由の増加(ブロードバンドよりも遅延が遅い)。

例として、HTMLがロードされた後にWebページをロードする必要のあるリソースが10個あるとします(100以上のリソースが一般的であるため、今日の標準では非常に小さなサイトですが、ここでは単純にしてこれに進みます)例)。また、各リクエストがインターネットを介してWebサーバーに行き来するまでに100ミリ秒かかり、どちらの側の処理時間もごくわずかであるとします(簡単にするために、この例では0とします)。各リソースを送信し、一度に1つずつ応答を待つ必要があるため、サイト全体をダウンロードするには10 * 100ms = 1,000msまたは1秒かかります。

これを回避するために、ブラウザーは通常、Webサーバーへの複数の接続(通常は6)を開きます。これは、ブラウザーが複数の要求を同時に起動できることを意味します。これははるかに優れていますが、複数の接続をセットアップおよび管理する必要があるという複雑さを犠牲にします(ブラウザーとサーバーの両方に影響します)。前の例を続けて、4つの接続があるとしましょう。簡単にするために、すべてのリクエストが等しいとしましょう。この場合、4つの接続すべてにリクエストを分割できるため、2つは3つのリソースを取得し、2つは2つのリソースを取得して、合計10個のリソースを取得します(3 + 3 + 2 + 2 = 10)。その場合、最悪のケースは3回のラウンドタイムまたは300ms = 0.3秒です-良い改善ですが、この単純な例には、これらの複数の接続をセットアップするコストは含まれていません。

HTTP / 2では、同じリクエストに複数のリクエストを送信できます接続-したがって、上記のように複数の接続を開く必要はありません。したがって、ブラウザは「このCSSファイルをGimme、JavaScriptファイルをGimme、Gimme image1.jpg。Gimme image2.jpg ...など」と発声できます。単一の接続を完全に利用するため。これには、空き接続を待機している要求の送信を遅延させないという明らかなパフォーマンス上の利点があります。これらの要求はすべて、インターネットを介して(ほぼ)並列でサーバーに送信されます。サーバーがそれぞれに応答すると、サーバーは戻り始めます。実際、Webサーバーはそれよりもさらに強力であり、Webサーバーは任意の順序で応答し、ファイルを異なる順序で送信したり、要求された各ファイルを分割してファイルを混合したりできます。行頭ブロッキング問題)。次に、Webブラウザーはすべてのピースを元に戻す役割を果たします。最良の場合(帯域幅の制限がないと仮定-下記を参照)、10個のリクエストすべてがほぼ同時に並行して発生し、サーバーによって即座に応答される場合、これは基本的に1回のラウンドトリップ、つまり100ミリ秒または0.1秒、 10個すべてのリソースをダウンロードします。そして、これには、HTTP / 1.1に対して複数の接続が持っていた欠点がありません!これは、各Webサイトのリソースが増加するにつれて、さらにスケーラブルになります(現在、ブラウザーはHTTP / 1.1で最大6つの並列接続を開きますが、サイトが複雑になるにつれて増加する必要がありますか?)。

この図は違いを示しており、アニメーション版もあります。

注:HTTP / 1.1にはパイプライン処理の概念があり、複数の要求を一度に送信することもできます。ただし、要求された順に全体を返す必要があったため、概念的には似ていても、HTTP / 2ほど優れたものはありません。言うまでもなく、これはブラウザとサーバーの両方であまりサポートされていないため、めったに使用されません。

以下のコメントで強調されていることの1つは、帯域幅がここでどのように影響するかです。もちろん、インターネット接続はダウンロードできる量によって制限されており、HTTP / 2はそれに対応していません。したがって、上記の例で説明した10個のリソースがすべて印刷品質の大規模な画像である場合でも、ダウンロードには時間がかかります。ただし、ほとんどのWebブラウザーでは、帯域幅はレイテンシほど問題ではありません。したがって、これらの10個のリソースが小さなアイテム(特にCSSやJavaScriptのようなテキストリソースであり、gzipで圧縮して小さくできる)である場合、ウェブサイトでは非常に一般的ですが、帯域幅はそれほど問題ではありません。問題とHTTP / 2はそれに対処しようとします。これが、HTTP / 1.1で別の回避策として連結が使用される理由でもあります。たとえば、すべてのCSSが1つのファイルに結合されることがよくあります。HTTP / 2でのアンチパターン -完全に廃止することに対する反対意見もありますが)。

実例としてそれを置くために:あなたが宅配のために店から10のアイテムを注文しなければならないと仮定してください:

  • 接続が1つのHTTP / 1.1の場合、一度に1つずつ注文する必要があり、最後の商品が到着するまで次の商品を注文できません。すべてを完了するには数週間かかることを理解できます。

  • 複数の接続を持つHTTP / 1.1は、外出先で(限られた)数の独立した注文を同時に処理できることを意味します。

  • パイプライン処理を備えたHTTP / 1.1は、10アイテムすべてを順番に要求せずに順番に要求できることを意味しますが、それらはすべて、要求した特定の順序で到着します。また、1つの商品が在庫切れの場合は、それ以降に注文した商品が届くまで待たなければなりません。後の商品が実際に在庫にある場合でもです。これは少し良いですが、それでも遅延が発生する可能性があり、ほとんどのショップがとにかくこの注文方法をサポートしていないとしましょう。

  • HTTP / 2は、特定の順序でアイテムを注文できることを意味します-遅延なしで(上記と同様)。準備が整った時点でショップが発送するため、注文した順序とは異なる順序で到着する場合や、商品が分割されてその順序の一部が先に到着する場合もあります(上記よりも優れています)。最終的にこれは、1)すべてを全体的に迅速に取得し、2)各アイテムが到着したらすぐに作業を開始できることを意味します(「ああ、それは思ったほど良くないので、何か他のものを注文するか、代わりに注文したいかもしれません」 )。

もちろん、郵便配達員のバン(帯域幅)のサイズにはまだ制限があるため、荷物が満杯の場合、荷物を翌日まで仕分け事務所に戻さなければならない場合がありますが、これはめったに比較されません。実際に注文をやり取りする際の遅延に。ほとんどのWebブラウジングでは、かさばるパッケージではなく、小さな文字を前後に送信します。

お役に立てば幸いです。


8
素晴らしい説明。例は私がこれを得るために必要なものです。したがって、HTTP / 1.1では、応答が来るのを待ってから次の要求をディスパッチするまでに時間の無駄があります。HTTP / 2はこれを修正します。ありがとうございました。
user3448600

1
しかし、厳しいと思います。帯域幅にピースを追加するように要求されただけかもしれません。これは、このディスカッションが終了した後で、喜んで実行します。ただし、IMHOの帯域幅は、Web閲覧(少なくとも西側の世界では)ほど大きな問題ではありません。遅延が問題です。また、HTTP / 2はレイテンシを改善します。ほとんどのウェブサイトは多くの小さなリソースで構成されており、ダウンロードするための帯域幅があっても(多くの場合そうです)、ネットワークの遅延のために遅くなります。帯域幅は、大規模なリソースではさらに問題になります。大量の画像やその他のリソースを含むこれらのWebサイトは、依然として帯域幅の制限に達する可能性があることに同意します。
Barry Pollard

1
HTTPは、そのような保証を提供しないため、順序付けを強制するために使用しないでください。HTTP / 2では、配信の優先順位を提案できますが、注文は提案できません。また、JavaScriptアセットの1つがキャッシュされているが、もう1つはキャッシュされていない場合、HTTPは優先度にも影響を与えることができません。代わりに、asyncまたはdeferの適切な使用と組み合わせたHTMLの順序付け(growingwiththeweb.com/2014/02/async-vs-defer-attributes.html)、またはrequire.jsなどのライブラリを使用する必要があります。
バリー

1
素晴らしい説明。ありがとう!
hmacias

2
これは、HTTP / 1.1がテキストのストリームであり、HTTP / 2がパケットベースであるためです。これらは、パケットではなくHTTP / 2のフレームと呼ばれます。したがって、HTTP / 2では、各フレームをストリームにタグ付けして、フレームのインターリーブを可能にすることができます。HTTP / 1.1では、ヘッダーと本文の一連のテキスト行であるため、そのような概念はありません。ここでは詳細:stackoverflow.com/questions/58498116/...
バリー・ポラード

5

多重化をリクエスト

HTTP / 2は、単一のTCP接続を介して、データに対する複数の要求を並行して送信できます。1つのサーバーから非同期でWebファイルをダウンロードできるため、これはHTTP / 2プロトコルの最も高度な機能です。最新のブラウザのほとんどは、TCP接続を1つのサーバーに制限しています。これにより、追加のラウンドトリップ時間(RTT)が短縮され、最適化なしでWebサイトの読み込みが速くなり、ドメインシャーディングが不要になります。

ここに画像の説明を入力してください


4

単純なAns(ソース):

多重化とは、ブラウザーが複数の要求を送信し、単一のTCP接続に「バンドル」された複数の応答を受信できることを意味します。そのため、DNSルックアップとハンドシェイクに関連するワークロードは、同じサーバーからのファイルに対して保存されます。

複雑/詳細な回答:

@BazzaDPが提供する回答をご覧ください。


1
これは、http 1.1でもパイプラインを使用して実現できます。HTTP2での多重化の主な目的は、順番どおりに応答を待たないことです
Dhairya Lakhera '19

3

HTTP 2.0での多重化は、単一の接続を使用して複数の要求と応答を並行して配信し、このプロセスで多数の個別のフレームを作成する、ブラウザーとサーバー間のタイプの関係です。

多重化は、要求と応答の厳密なセマンティクスから分離し、1対多または多対多の関係を可能にします。

HTTP1 VS HTTP2交換プロセス


あなたのHTTP / 2多重化の例は、実際には多重化を示していません。図のシナリオは、HTTP / 1.1で導入されたHTTPパイプライン処理を示しています。
ich5003

@ ich5003単一の接続を使用するため、多重化です。ただし、1回のリクエストで複数の応答を送信するケースは、ここでは示されていません。
Juanma Menendez

1
私が言いたいのは、上記のシナリオはHTTPパイプラインを使用した場合にのみ達成できるということです。
ich5003

ここでの混乱の原因は、右側の図の要求/応答の順序にある​​と思います。HTTP/ 1.1でパイプライン処理することによっても実現できる、HTTP / 2での多重化の特殊なケースを示しています。図の応答順序が要求順序と異なる場合でも、混乱は起こりません。
レイク

1

@Juanma Menendezの答えは彼の図が混乱している間は正しいので、多重化とパイプライン化の違いを明確にすることで改善することにしました。

パイプライン処理(HTTP / 1.1)

複数の要求が同じ HTTP接続を介し送信されます。応答は同じ順序で受信されます。最初の応答に時間がかかる場合、他の応答は並んで待機する必要があります。命令が別の命令がデコードされている間にフェッチされるCPUパイプライン処理に似ています。複数の指示が同時に実行されていますが、それらの順序は保持されます。

多重化(HTTP / 2)

複数の要求が同じ HTTP接続を介し送信されます。応答は任意の順序で受信されます。他を妨げている遅い応答を待つ必要はありません。最近のCPUでのアウトオブオーダーの命令実行に似ています。

うまくいけば、改善された画像が違いを明らかにします:

標準HTTP / 1.1フロー/パイプライン/多重化

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.