http2.0_html/css_WEB-ITnose の最初の紹介

http2.0 の初めての紹介

HTTP2.0 パフォーマンス強化の核心: バイナリ フレーミング

HTTP 2.0 の最大の特徴: HTTP、HTTP メソッド、ステータス コード、URI、ヘッダー フィールドのセマンティクスは変更されませんコアコンセプトは以前と同じですが、前世代規格の性能限界を打破し、伝送性能を向上させ、低遅延と高スループットを実現することに注力しています。 2.0 と呼ばれる理由は、新しいバイナリ フレーム レイヤーのためです。

HTTP のさまざまな動詞、メソッド、ヘッダーが影響を受けないことを確認する必要があるため、アプリケーション層 (HTTP2.0) とトランスポート層 (TCP または UDP) の間にバイナリ フレーミング層を追加する必要があります。 ）。

バイナリ フレーム層では、HTTP 2.0 は送信されるすべての情報を小さなメッセージとフレームに分割し、バイナリ形式でエンコードします。HTTP 1.x のヘッダー情報はヘッダー フレームにカプセル化され、リクエスト本文はヘッダー フレームにカプセル化されます。データフレーム。

HTTP 2.0 通信はすべて単一の接続上で行われ、任意の数の双方向データ ストリームを伝送できます。したがって、各データ ストリームはメッセージの形式で送信されます。メッセージは 1 つ以上のフレームで構成されており、順不同で送信され、各フレームのヘッダー内のストリーム識別子に基づいて再組み立てされます。

HTTP2.0 ヘッダー圧縮

HTTP 2.0 は、クライアント側とサーバー側で「ヘッダー テーブル」を使用して、同じデータについて、各リクエストと応答の通信を通じて送信されなくなりました。時間の経過とともにほとんど変化しない共通のキーと値のペア (ユーザー エージェント、許容可能なメディア タイプなど) は、一度送信するだけで済みます。実際、リクエストにヘッダーが含まれていない場合 (同じリソースに対するポーリングリクエストなど)、ヘッダーのオーバーヘッドはゼロバイトです。このとき、すべてのヘッダーは、前のリクエストによって送信されたヘッダーを自動的に使用します。

ヘッダーが変更された場合、変更されたデータをヘッダー フレームで送信するだけで、新しいヘッダー フレームまたは変更されたヘッダー フレームが「ヘッダー テーブル」に追加されます。ヘッダー テーブルは HTTP 2.0 接続中に常に存在し、クライアントとサーバーの両方によって徐々に更新されます。

一部の HTTP2.0 リクエストはすべて TCP リンク上にあります

すべての HTTP2.0 通信は TCP 接続上で完了します。 HTTP 2.0 は、HTTP プロトコル通信の基本単位をフレームに縮小し、これらのフレームは論理フロー内のメッセージに対応します。メッセージは、同じ TCP 接続上で双方向に並行して交換されます。同様に、ページ http://www.qq.com をリクエストします。ページ上のすべてのリソース要求は、クライアントとサーバー間の TCP を介して要求され、応答されます。

TCP パフォーマンスに注意を払う学生は、HTTP パフォーマンスの鍵は高帯域幅ではなく低遅延にあることを知っているでしょう。 ほとんどの HTTP 接続は存続期間が短く、バースト性が高くなりますが、TCP が最も効率的になるのは、長期間の接続で大量のデータを転送する場合のみです。 HTTP 2.0 では、すべてのデータ ストリームが同じ接続を共有できるようにすることで、TCP 接続をより効率的に使用できるため、高帯域幅が HTTP のパフォーマンス向上に真の役割を果たします。

同時に、単一リンクのマルチリソース アプローチは、トップダウン レベルで次のような利点をもたらします。 TCP 接続

3 の削減により、ネットワークの混雑状況が改善され、混雑とパケット損失の回復速度が速くなります。

つまり、「リソースをマージしてリクエストを減らす」という最適化手法は、HTTP2.0 では効果がなく、無駄な負荷を増やすだけです。

並列双方向バイトストリームリクエストとレスポンス

HTTP2.0 では、クライアントとサーバーは HTTP メッセージを互いに独立したフレームに分解し、順不同で送信し、最後に相手側で送信できます。最後に元に戻します。同じリンク上で、異なる方向に複数のデータ ストリームが送信されていることに注意してください。クライアントはストリームを順不同で送信したり、サーバーからの応答を受信したりできます。同様のことがサーバーにも当てはまります。

HTTP メッセージを独立したフレームに分解し、それらをインターリーブして送信し、相手側で再組み立てすることは、HTTP 2.0 の最も重要な機能強化です。実際、このメカニズムは Web テクノロジー スタック全体で一連の連鎖反応を引き起こし、それによってパフォーマンスが大幅に向上します。その理由は次のとおりです。相互に干渉せずに応答を送信します。

複数のリクエストと応答を並行して送信するために 1 つの接続のみを使用します。

つまり、「ドメイン名」が最適化されます。 HTTP 2.0 では、リソースが並行してインターリーブされて送信され、制限がないため、「パーティショニング」メソッドは役に立ちません。複数のドメイン名の追加の並行ダウンロードは必要ありません。

HTTP2.0 リクエスト優先度

各 HTTP2.0 フローには優先度値があり、この優先度値は、クライアントとサーバーが異なるフローを処理するために異なる優先度戦略を採用することを決定します。ただし、優先度の高いフローが最初に送信される必要があります。絶対ではありません。絶対的なコンプライアンスでは、ファースト チーム ブロッキングの問題が発生する可能性があります。つまり、優先度の高いリクエストは遅く、他のリソース配信がブロックされる原因になります。クライアントとサーバー間で処理リソースと帯域幅を割り当てるには、さまざまな優先順位を組み合わせる必要もあります。

HTTP2.0 サーバー プッシュ

HTTP 2.0 強力な新機能は、サーバーがクライアント リクエストに対して複数の応答を送信できることです。つまり、サーバーは、最初のリクエストに応答するだけでなく、クライアントが明示的にリクエストしなくても、追加のリソースをクライアントにプッシュできます。

HTTP2.0 サーバープッシュでは、HTTP1.x 時代の組み込みリソースの最適化は無意味になりました。さらに、サーバー プッシュ リソースを使用すると、クライアントがリソースをキャッシュしたり、異なるページ間で共有したりすることもできるため、より効率的です (同一オリジン ポリシーに従います)。

一部のコンテンツ参照: http://www.kuqin.com/shuoit/20150323/345378.html