簡単に言えば、多重化により、ブラウザは同じ接続で複数のリクエストを一度に起動し、リクエストを任意の順序で受信できます。
そして今、はるかに複雑な答えのために...
Webページをロードすると、HTMLページがダウンロードされ、CSS、JavaScript、画像のロードなどが必要であることがわかります。
HTTP/1.1では、HTTP/1.1接続では一度に1つしかダウンロードできません。ブラウザはHTMLをダウンロードし、CSSファイルを要求します。それが返されると、JavaScriptファイルを要求します。それが返されると、最初の画像ファイルを要求します...など。HTTP/ 1.1は基本的に同期です。リクエストを送信すると、レスポンスを取得するまでスタックします。これは、ほとんどの場合、ブラウザーがリクエストを実行し、応答を待機してから、別の要求を実行し、応答を待機しているなど、あまり実行していないことを意味します。多くのJavaScriptはブラウザに多くの処理を要求しますが、それはダウンロードされているJavaScriptに依存するため、少なくとも最初はHTTP/1.1に継承された遅延は問題を引き起こします。通常、サーバーは静的リソース（CSS、JavaScript、画像、フォントなど）に対してほぼ即座に応答する必要があるため、サーバーはどちらもあまり実行していません（少なくとも要求ごと-もちろん、混雑しているサイトでは追加されます）。できれば、（データベース呼び出しなどを必要とする）動的なリクエストであっても長すぎないことを願っています。
そのため、今日のWebの主な問題の1つは、ブラウザーとサーバー間でリクエストを送信する際のネットワーク遅延です。数十またはおそらく数百ミリ秒で、それほど多くないように見えるかもしれませんが、それらは加算され、多くの場合、Webブラウジングの最も遅い部分です。モバイル経由でますます（ブロードバンドより遅延が遅い）。
例として、HTMLがロードされた後にWebページをロードする必要があるリソースが10個あるとしましょう（100以上のリソースが一般的であるため、今日の標準では非常に小さなサイトですが、これをシンプルに保ち、これを使用します）例）。そして、各リクエストがインターネットを介してウェブサーバーに行き来するのに100msかかり、両端の処理時間は無視できるとしましょう（簡単にするためにこの例では0としましょう）。各リソースを送信し、応答を1つずつ待機する必要があるため、サイト全体をダウンロードするには10 * 100ms = 1,000msまたは1秒かかります。
これを回避するために、ブラウザは通常、Webサーバーへの複数の接続（通常6）を開きます。これは、ブラウザーが複数の要求を同時に起動できることを意味しますが、これははるかに優れていますが、複数の接続をセットアップして管理する複雑さが犠牲になります（ブラウザーとサーバーの両方に影響します）。前の例を続けて、4つの接続があるとしましょう。簡単にするために、すべての要求が等しいとしましょう。この場合、4つの接続すべてにリクエストを分割できるため、2つは取得するリソースが3つ、2つは合計10のリソースを取得する2つのリソース（3 + 3 + 2 + 2 = 10）になります。その場合、最悪の場合は3ラウンド時間または300ミリ秒= 0.3秒です-良い改善ですが、この単純な例には、これらの複数の接続を設定するコストや、それらを管理するリソースへの影響は含まれていません（私は行っていません）この回答はすでに十分長いので、ここに進みますが、別個にTCP接続を設定するには時間がかかり、他のリソースがかかります-TCP接続、HTTPSハンドシェイク、 TCPスロースタート）により、最高速度に到達します。
HTTP/2では、same接続で複数のリクエストを送信できます。したがって、上記のように複数の接続を開く必要はありません。したがって、ブラウザは「このCSSファイルをGimmeします。そのJavaScriptファイルをGimmeします。Gimmeimage1.jpg。Gimme image2.jpg ...など」と言うことができます。単一の接続を完全に活用します。これには、空き接続を待機している要求の送信を遅延させないという明らかなパフォーマンス上の利点があります。これらの要求はすべて、インターネットを介して（ほぼ）並行してサーバーに送られます。サーバーはそれぞれに応答し、その後、戻り始めます。実際、Webサーバーは任意の順序でそれらに応答し、異なる順序でファイルを送り返すことができるため、それよりもさらに強力です。要求された各ファイルを分割して、ファイルを混ぜ合わせることもできます。これには、1つの重い要求が他のすべての後続の要求をブロックしないという副次的な利点があります（ head of line blocking issue）。次に、Webブラウザーは、すべての要素を元に戻します。最良の場合（帯域幅の制限がないと仮定-以下を参照）、10個の要求すべてがほぼ同時に並行して実行され、サーバーによってすぐに応答される場合、これは基本的に1回のラウンドトリップまたは100msまたは0.1秒があることを意味します10個すべてのリソースをダウンロードします。そして、これには複数の接続がHTTP/1.1に対して持っていた欠点はありません！また、各Webサイトのリソースが大きくなるにつれて、これははるかにスケーラブルになります（現在、ブラウザーはHTTP/1.1で最大6つの並列接続を開きますが、サイトが複雑になるにつれて、それは大きくなりますか？）.
注：HTTP/1.1には pipelining という概念があり、複数の要求を一度に送信することもできます。ただし、要求された順序で返される必要があったため、概念的には似ていても、HTTP/2ほどではありません。言うまでもなく、これはブラウザーとサーバーの両方であまりサポートされていないため、めったに使用されません。
以下のコメントで強調されていることの1つは、帯域幅がここでどのように影響するかです。もちろん、インターネット接続はダウンロードできる量によって制限されますが、HTTP/2はそれを解決しません。したがって、上記の例で説明したこれらの10個のリソースがすべて印刷品質の大きな画像である場合、ダウンロードは依然として遅くなります。ただし、ほとんどのWebブラウザーでは、待ち時間よりも帯域幅の方が問題は少なくなります。そのため、ウェブサイトで非常に一般的であるように、これらの10個のリソースが小さなアイテム（特に、gzipで圧縮できるCSSやJavaScriptなどのテキストリソース）である場合、帯域幅は実際には問題になりません-多くの場合、リソースの膨大な量です問題とHTTP/2はそれを解決するように見えます。これは、連結が別の回避策としてHTTP/1.1で使用される理由でもあるため、たとえば、すべてのCSSが1つのファイルにまとめられることがよくあります。CSSのダウンロード量は同じですが、1つのリソースとして実行することでパフォーマンスが大幅に向上します（ただし、 HTTP/2ではそうではなく、実際には連結は HTTP/2でのアンチパターン である必要があると言う人もいます-ただし、連結を完全に廃止することに反対する議論もあります）。
現実世界の例として言えば：宅配のために店から10個の商品を注文する必要があると仮定します：
接続が1つのHTTP/1.1では、一度に1つずつ注文する必要があり、最後のアイテムが到着するまで次のアイテムを注文することはできません。すべてを理解するには数週間かかることを理解できます。
複数の接続を使用するHTTP/1.1では、同時に（限られた）数の独立した注文を行うことができます。
パイプライン処理を使用したHTTP/1.1では、待機せずに10個すべてのアイテムを次々に要求できますが、それらはすべて、要求した特定の順序で到着します。そして、1つのアイテムが在庫切れの場合、その後注文したアイテムを入手する前に、それを待つ必要があります-それらの新しいアイテムが実際に在庫がある場合でも！これはもう少し良いですが、まだ遅延の影響を受けます。そして、ほとんどの店はとにかくこの注文方法をサポートしていないとしましょう。
HTTP/2は、特定の順序でアイテムを注文できることを意味します-遅延なし（上記と同様）。ショップは準備ができたら発送しますので、あなたが要求したのとは異なる順序で到着するかもしれませんし、その注文の一部が先に到着するようにアイテムを分割するかもしれません（上記よりも優れています）。最終的に、これは1）全体をより速く取得し、2）到着した各アイテムで作業を開始できることを意味する必要があります（「ああ、私は思っていたほどナイスではないので、他の何かを注文したいかもしれません」 ）。
もちろん、郵便配達員のバンのサイズ（帯域幅）によってまだ制限されているため、その日いっぱいになった場合、翌日までいくつかの荷物を仕分けオフィスに残しておく必要がありますが、それはめったに問題ではありません実際に前後に注文を送信する際の遅延と比較して。ほとんどのWebブラウジングでは、かさばるパッケージではなく、小さな文字を前後に送信します。
お役に立てば幸いです。
簡単なAns（ ソース ）：
多重化とは、ブラウザが複数のリクエストを送信し、複数の応答を単一のTCP=接続にまとめられる]を受信できることを意味します。
複雑/詳細な回答：
@BazzaDPが提供する答えをご覧ください。
HTTP 2.0の多重化は、単一の接続を使用して複数の要求と応答を並行して配信し、このプロセスで多くの個々のフレームを作成するブラウザーとサーバー間の関係のタイプです。
多重化は、厳密な要求と応答のセマンティクスから脱却し、1対多または多対多の関係を可能にします。
