著者はhttps://www.brightfunds.org/organizations/society-of-women-engineers[Society of Women Engineers]を選択してhttps://do.co/w4do-cta[Write DOnations]プログラム。

前書き

ハイパーテキスト転送プロトコル(HTTP)は、1989年の発明以来、World Wide Webでの通信の事実上の標準となっているアプリケーションプロトコルです。 1997年のHTTP / 1.1のリリースから最近まで、プロトコルの改訂はほとんどありませんでした。 しかし、2015年には、特にモバイルプラットフォームやサーバー集約型のグラフィックスやビデオを扱う場合に、待ち時間を短縮するためのいくつかの方法を提供するHTTP / 2と呼ばれる刷新バージョンが使用されるようになりました。 その後、HTTP / 2の人気はますます高まっており、世界のすべてのWebサイトの約3分の1がHTTP / 2をサポートしていると推定されています。 この変化する状況の中で、Web開発者はHTTP / 1.1とHTTP / 2の技術的な違いを理解することで利益を得ることができ、進化するベストプラクティスに関する情報に基づいた効率的な決定を行うことができます。

この記事を読んだ後、HTTP / 1.1とHTTP / 2の主な違いを理解し、HTTP / 2がより効率的なWebプロトコルを実現するために採用した技術的な変更に集中します。

バックグラウンド

HTTP / 2がHTTP / 1.1に対して行った特定の変更をコンテキスト化するために、最初にそれぞれの歴史的発展と基本的な動作を見てみましょう。

HTTP / 1.1

1989年にTimothy Berners-LeeがWorld Wide Webの通信標準として開発したHTTPは、クライアントコンピューターとローカルまたはリモートのWebサーバー間で情報を交換するトップレベルのアプリケーションプロトコルです。 このプロセスでは、クライアントは「+ GET 」や「 POST +」などの_method_を呼び出すことにより、テキストベースのリクエストをサーバーに送信します。 応答として、サーバーはHTMLページなどのリソースをクライアントに送り返します。

たとえば、ドメイン「+ www.example.com +」のウェブサイトにアクセスしているとします。 このURLに移動すると、コンピューターのWebブラウザーは、次のようなテキストベースのメッセージの形式でHTTP要求を送信します。

GET /index.html HTTP/1.1
Host: www.example.com

このリクエストは、「+ GET:」メソッドを使用します。このメソッドは、「+ Host:」の後にリストされているホストサーバーからのデータを要求します。 このリクエストに応じて、 ` example.com +` Webサーバーは、HTMLで要求される画像、スタイルシート、またはその他のリソースに加えて、HTMLページをリクエスト元のクライアントに返します。 データの最初の呼び出しですべてのリソースがクライアントに返されるわけではないことに注意してください。 Webブラウザが画面上のHTMLページのコンテンツをレンダリングするために必要なすべてのリソースを受信するまで、リクエストとレスポンスはサーバーとクライアントの間を行き来します。

この要求と応答の交換は、インターネットプロトコルスタックの単一の_アプリケーションレイヤー_であり、転送レイヤー(通常は伝送制御プロトコル、またはTCPを使用)および_ネットワークレイヤー_(インターネットプロトコル、またはIPを使用)の上にあると考えることができます。 ):

image:https://assets.digitalocean.com/articles/cart_63893/Protocol_Stack.png [インターネットプロトコルスタック]

このスタックの下位レベルについては多くの議論がありますが、HTTP / 2の高度な理解を得るためには、この抽象化されたレイヤーモデルと、HTTPがどこにあるかを知るだけで十分です。

この基本的なHTTP / 1.1の概要を理解したら、次に、HTTP / 2の初期の開発を振り返ります。

HTTP / 2

HTTP / 2は、主にGoogleで開発されたSPDYプロトコルとして始まり、圧縮、多重化、優先順位付けなどの手法を使用してWebページの読み込み遅延を削減することを目的としています。 このプロトコルは、https://www.ietf.org/ [IETF(Internet Engineering Task Force)]のハイパーテキスト転送プロトコルワーキンググループhttpbisが標準をまとめ、HTTPの出版に至ったときに、HTTP / 2のテンプレートとして機能しました。 / 2 2015年5月。 Chrome、Opera、Internet Explorer、Safariなど、多くのブラウザーが最初からこの標準化の取り組みをサポートしていました。 このブラウザーのサポートの一部により、2015年以降、プロトコルの採用率が大幅に向上しており、特に新しいサイトで高い採用率があります。

技術的な観点から見ると、HTTP / 1.1とHTTP / 2を区別する最も重要な機能の1つは、インターネットプロトコルスタックのアプリケーション層の一部と考えることができるバイナリフレーミング層です。 すべての要求と応答をプレーンテキスト形式で保持するHTTP / 1.1とは対照的に、HTTP / 2は、バイナリフレーミングレイヤーを使用して、すべてのメッセージをバイナリ形式でカプセル化しながら、動詞、メソッド、ヘッダーなどのHTTPセマンティクスを維持します。 アプリケーションレベルのAPIは従来のHTTP形式でメッセージを作成しますが、基礎となるレイヤーはこれらのメッセージをバイナリに変換します。 これにより、HTTP / 2より前に作成されたWebアプリケーションが、新しいプロトコルと対話するときに通常どおり機能し続けることが保証されます。

メッセージをバイナリに変換することで、HTTP / 2はHTTP / 1.1では利用できないデータ配信への新しいアプローチを試すことができます。これは、2つのプロトコルの実際の違いの根本にあります。 次のセクションでは、HTTP / 1.1の配信モデルを見てから、HTTP / 2によってどのような新しいモデルが可能になるのかを説明します。

配信モデル

前のセクションで説明したように、HTTP / 1.1とHTTP / 2はセマンティクスを共有し、両方のプロトコルでサーバーとクライアント間を移動する要求と応答が、 + GET + `および + POST + `。 しかし、HTTP / 1.1はこれらをプレーンテキストメッセージで転送しますが、HTTP / 2はこれらをバイナリにエンコードするため、配信モデルの可能性が大きく異なります。 このセクションでは、最初にHTTP / 1.1が配信モデルで効率を最適化しようとする方法と、これから生じる問題を簡単に検証し、次にHTTP / 2のバイナリフレーミングレイヤーの利点と優先順位付け方法について説明します。リクエスト。

HTTP / 1.1-パイプライン化と行頭ブロッキング

クライアントがHTTP `+ GET +`リクエストで受け取る最初の応答は、多くの場合、完全にレンダリングされたページではありません。 代わりに、リクエストされたページに必要な追加リソースへのリンクが含まれています。 クライアントは、ページの完全なレンダリングがページをダウンロードした後にのみサーバーからこれらの追加リソースを必要とすることを発見します。 このため、クライアントはこれらのリソースを取得するために追加の要求を行う必要があります。 HTTP / 1.0では、クライアントは新しい要求ごとにTCP接続を切断して再作成する必要がありましたが、これは時間とリソースの両方の点でコストのかかる問題です。

HTTP / 1.1は、永続的な接続とパイプライン化を導入することにより、この問題を処理します。 持続的接続の場合、HTTP / 1.1は、閉じるように直接指示されない限り、TCP接続を開いたままにすることを前提としています。 これにより、クライアントは各接続への応答を待たずに同じ接続で複数の要求を送信でき、HTTP / 1.0 over HTTP / 1.0のパフォーマンスが大幅に向上します。

残念ながら、この最適化戦略には自然なボトルネックがあります。 同じ宛先に移動する場合、複数のデータパケットは互いに通過できないため、キューの先頭にある要求がその必要なリソースを取得できない場合、その背後にあるすべての要求がブロックされる状況があります。 これは_ head-of-line(HOL)ブロッキング_と呼ばれ、HTTP / 1.1で接続効率を最適化する際の重大な問題です。 個別の並列TCP接続を追加するとこの問題を軽減できますが、クライアントとサーバー間で可能な同時TCP接続の数には制限があり、新しい接続ごとにかなりのリソースが必要になります。

これらの問題は、前述のバイナリフレーミングレイヤーを使用してこれらの問題を解決することを提案したHTTP / 2開発者の心の最前線にありました。これについては、次のセクションで詳しく説明します。

HTTP / 2-バイナリフレーミングレイヤーの利点

HTTP / 2では、バイナリフレーミングレイヤーが要求/応答をエンコードし、それらを情報の小さなパケットに分割し、データ転送の柔軟性を大幅に向上させます。

これがどのように機能するかを詳しく見てみましょう。 複数のTCP接続を使用してHOLブロッキングの影響を軽減する必要があるHTTP / 1.1とは対照的に、HTTP / 2は2つのマシン間に単一の接続オブジェクトを確立します。 この接続内には、複数の_ストリーム_のデータがあります。 各ストリームは、使い慣れた要求/応答形式の複数のメッセージで構成されています。 最後に、これらの各メッセージは、_frames_と呼ばれる小さな単位に分割されます。

image:https://assets.digitalocean.com/articles/cart_63893/Streams_Frames.png [ストリーム、メッセージ、およびフレーム]

最も詳細なレベルでは、通信チャネルは、それぞれが特定のストリームにタグ付けされた一連のバイナリエンコードフレームで構成されます。 識別タグにより、接続は転送中にこれらのフレームをインターリーブし、もう一方の端で再組み立てできます。 インターリーブされた要求と応答は、それらの背後にあるメッセージをブロックすることなく、_multiplexing_と呼ばれるプロセスで並行して実行できます。 多重化は、メッセージが別のメッセージの終了を待つ必要がないようにすることで、HTTP / 1.1の行頭ブロッキングの問題を解決します。 これは、サーバーとクライアントが同時に要求と応答を送信できることを意味し、より優れた制御とより効率的な接続管理を可能にします。

多重化により、クライアントは複数のストリームを並列に構築できるため、これらのストリームは単一のTCP接続を使用するだけで済みます。 オリジンごとに単一の永続的接続を使用すると、ネットワーク全体でメモリと処理のフットプリントが削減されるため、HTTP / 1.1が改善されます。 これにより、ネットワークおよび帯域幅の使用率が向上し、全体的な運用コストが削減されます。

また、単一のTCP接続により、HTTPSプロトコルのパフォーマンスが向上します。これは、クライアントとサーバーが複数の要求/応答に同じ保護されたセッションを再利用できるためです。 HTTPSでは、TLSまたはSSLハンドシェイク中に、両当事者はセッション全体で単一のキーを使用することに同意します。 接続が切断されると、新しいセッションが開始され、さらに通信するために新しく生成されたキーが必要になります。 したがって、単一の接続を維持すると、HTTPSのパフォーマンスに必要なリソースを大幅に削減できます。 HTTP / 2仕様ではTLSレイヤーの使用は必須ではありませんが、多くの主要なブラウザーはHTTPS付きのHTTP / 2のみをサポートしていることに注意してください。

バイナリフレーミングレイヤーに固有の多重化はHTTP / 1.1の特定の問題を解決しますが、同じリソースを待機する複数のストリームがパフォーマンスの問題を引き起こす可能性があります。 HTTP / 2の設計では、これを考慮しますが、次のセクションで説明するトピックであるストリームの優先順位付けを使用します。

HTTP / 2-ストリームの優先順位付け

ストリームの優先順位付けは、同じリソースを求めて競合する要求の問題を解決するだけでなく、開発者が要求の相対的な重みをカスタマイズして、アプリケーションのパフォーマンスを最適化できるようにします。 このセクションでは、この優先順位付けのプロセスを分解して、HTTP / 2のこの機能をどのように活用できるかについてのより良い洞察を提供します。

ご存知のとおり、バイナリフレーミングレイヤーはメッセージをデータの並列ストリームに編成します。 クライアントがサーバーに同時要求を送信する場合、各ストリームに1〜256の重みを割り当てることで、要求している応答に優先順位を付けることができます。 数字が大きいほど、優先度が高くなります。 これに加えて、クライアントは、依存するストリームのIDを指定することにより、各ストリームが別のストリームに依存していることも示します。 親識別子が省略された場合、ストリームはルートストリームに依存していると見なされます。 これを次の図に示します。

image:https://assets.digitalocean.com/articles/cart_63893/Stream_Priority2.png [ストリームの優先順位付け]

図では、チャネルには6つのストリームが含まれており、各ストリームには一意のIDがあり、特定の重みに関連付けられています。 ストリーム1には親IDが関連付けられておらず、デフォルトではルートノードに関連付けられています。 他のすべてのストリームには、いくつかの親IDがマークされています。 各ストリームのリソース割り当ては、保持する重みと必要な依存関係に基づきます。 たとえば、図では同じウェイトと同じ親ストリームが割り当てられているストリーム5と6は、リソース割り当ての優先順位が同じになります。

サーバーはこの情報を使用して依存関係ツリーを作成します。これにより、サーバーはリクエストがデータを取得する順序を決定できます。 前の図のストリームに基づいて、依存関係ツリーは次のようになります。

image:http://assets.digitalocean.com/articles/cart_63893/Dependency_Tree.png [依存ツリー]

この依存関係ツリーでは、ストリーム1はルートストリームに依存しており、ルートから派生した他のストリームはないため、すべての利用可能なリソースは他のストリームより先にストリーム1に割り当てられます。 ツリーは、ストリーム2がストリーム1の完了に依存することを示しているため、ストリーム1はタスク1が完了するまで続行しません。 次に、ストリーム3と4を見てみましょう。 これらのストリームは両方ともストリーム2に依存しています。 ストリーム1の場合のように、ストリーム2は、ストリーム3および4より先に利用可能なすべてのリソースを取得します。 ストリーム2がタスクを完了すると、ストリーム3と4がリソースを取得します。これらは重みで示されるように2:4の比率で分割され、ストリーム4のリソースのチャンクが大きくなります。 最後に、ストリーム3が終了すると、ストリーム5と6は同等の部分で利用可能なリソースを取得します。 これは、ストリーム4がより大きなリソースチャンクを受信した場合でも、ストリーム4がタスクを完了する前に発生する可能性があります。下位レベルのストリームは、上位レベルの依存ストリームが終了するとすぐに開始できます。

アプリケーション開発者は、ニーズに基づいてリクエストに重みを設定できます。 たとえば、Webページにサムネイル画像を提供した後、高解像度の画像を読み込むために低い優先度を割り当てることができます。 この重み割り当て機能を提供することにより、HTTP / 2を使用すると、開発者はWebページのレンダリングをより適切に制御できます。 また、このプロトコルにより、クライアントは依存関係を変更し、ユーザーの操作に応じて実行時に重みを再割り当てできます。 ただし、特定のストリームへの特定のリソースへのアクセスがブロックされている場合、サーバーは割り当てられた優先順位を独自に変更する可能性があることに注意することが重要です。

バッファオーバーフロー

2台のマシン間のTCP接続では、クライアントとサーバーの両方に、まだ処理されていない着信要求を保持するために使用可能な一定量のバッファースペースがあります。 これらのバッファは、ダウンストリーム接続とアップストリーム接続の速度が不均一であることに加えて、多数の、または特に大きなリクエストに対応する柔軟性を提供します。

ただし、バッファーが十分でない状況もあります。 たとえば、サーバーは、バッファサイズが制限されているか帯域幅が狭いためにクライアントアプリケーションが対応できないペースで大量のデータをプッシュしている場合があります。 同様に、クライアントが巨大な画像またはビデオをサーバーにアップロードすると、サーバーバッファーがオーバーフローし、いくつかの追加パケットが失われる可能性があります。

バッファオーバーフローを回避するために、フロー制御メカニズムは、送信側がデータで受信側を圧倒しないようにする必要があります。 このセクションでは、HTTP / 1.1とHTTP / 2がこのメカニズムの異なるバージョンを使用して、異なる配信モデルに従ってフロー制御を処理する方法の概要を説明します。

HTTP / 1.1

HTTP / 1.1では、フロー制御は基礎となるTCP接続に依存しています。 この接続が開始されると、クライアントとサーバーの両方がシステムのデフォルト設定を使用してバッファーサイズを確立します。 受信者のバッファが部分的にデータで満たされている場合、送信者に「受信ウィンドウ」、つまり、バッファに残っている利用可能なスペースの量を通知します。 この受信ウィンドウは、_ACKパケット_と呼ばれる信号でアドバタイズされます。これは、受信機がオープニング信号を受信したことを確認するために送信するデータパケットです。 このアドバタイズされた受信ウィンドウサイズがゼロの場合、送信側は、クライアントが内部バッファーをクリアしてからデータ送信の再開を要求するまで、データを送信しません。 ここで重要なのは、基礎となるTCP接続に基づいて受信ウィンドウを使用すると、接続のどちらかの端でのみフロー制御を実装できることです。

HTTP / 1.1はトランスポート層に依存してバッファオーバーフローを回避するため、新しいTCP接続ごとに個別のフロー制御メカニズムが必要です。 ただし、HTTP / 2は単一のTCP接続内でストリームを多重化するため、異なる方法でフロー制御を実装する必要があります。

HTTP / 2

HTTP / 2は、単一のTCP接続内でデータのストリームを多重化します。 その結果、TCP接続レベルの受信ウィンドウは、個々のストリームの配信を規制するには不十分です。 HTTP / 2は、トランスポート層に依存するのではなく、クライアントとサーバーが独自のフロー制御を実装できるようにすることで、この問題を解決します。 アプリケーション層は利用可能なバッファスペースを通信し、クライアントとサーバーが多重化ストリームのレベルで受信ウィンドウを設定できるようにします。 この細かいフロー制御は、最初の接続後に「+ WINDOW_UPDATE +」フレームを介して変更または維持できます。

このメソッドはアプリケーション層のレベルでデータフローを制御するため、フロー制御メカニズムは、受信ウィンドウを調整する前に信号が最終的な宛先に到達するのを待つ必要はありません。 中間ノードは、フロー制御設定情報を使用して、独自のリソース割り当てを決定し、それに応じて変更できます。 このようにして、各中間サーバーは独自のカスタムリソース戦略を実装できるため、接続効率が向上します。

このフロー制御の柔軟性は、適切なリソース戦略を作成するときに有利です。 たとえば、クライアントは画像の最初のスキャンを取得してユーザーに表示し、ユーザーがより重要なリソースを取得しながらプレビューできるようにします。 クライアントがこれらの重要なリソースを取得すると、ブラウザは画像の残りの部分の取得を再開します。 したがって、フロー制御の実装をクライアントとサーバーに延期することで、Webアプリケーションの認識されるパフォーマンスを改善できます。

前のセクションで説明したフロー制御とストリームの優先順位付けに関して、HTTP / 2はより詳細なレベルの制御を提供し、最適化の可能性を広げます。 次のセクションでは、同様の方法で接続を強化できるプロトコル固有の別の方法、_server push_を使用したリソース要求の予測について説明します。

リソース要求の予測

典型的なWebアプリケーションでは、クライアントは `+ GET `リクエストを送信し、HTMLのページ(通常はサイトのインデックスページ)を受信します。 インデックスページのコンテンツを調べている間、クライアントはページを完全にレンダリングするために、CSSやJavaScriptファイルなどの追加のリソースを取得する必要があることに気付く場合があります。 クライアントは、最初の「 GET +」リクエストからの応答を受信した後にのみこれらの追加リソースが必要であると判断します。したがって、これらのリソースを取得してページをまとめるために追加リクエストを行う必要があります。 これらの追加リクエストにより、最終的に接続のロード時間が長くなります。

ただし、この問題には解決策があります。サーバーはクライアントが追加のファイルを必要とすることを事前に知っているため、サーバーはこれらのリソースを要求する前にクライアントに送信することでクライアントの時間を節約できます。 HTTP / 1.1とHTTP / 2には、これを達成するための異なる戦略があります。それぞれの戦略については、次のセクションで説明します。

HTTP / 1.1-リソースのインライン化

HTTP / 1.1では、クライアントマシンがページをレンダリングするために必要な追加リソースを開発者が事前に知っている場合、_resource inlining_と呼ばれる手法を使用して、サーバーが最初の「+ GET +」リクエスト。 たとえば、クライアントがページをレンダリングするために特定のCSSファイルを必要とする場合、そのCSSファイルをインライン化すると、クライアントに要求する前に必要なリソースがクライアントに提供され、クライアントが送信する必要のあるリクエストの総数が減ります。

しかし、リソースのインライン化にはいくつかの問題があります。 HTMLドキュメントにリソースを含めることは、小さなテキストベースのリソースの実行可能なソリューションですが、非テキスト形式の大きなファイルはHTMLドキュメントのサイズを大幅に増加させる可能性があり、最終的に接続速度を低下させ、得られた元の利点を無効にする可能性がありますこのテクニックを使用することから。 また、インライン化されたリソースはHTMLドキュメントから分離されていないため、クライアントが既に持っているリソースを拒否したり、キャッシュにリソースを配置したりするメカニズムはありません。 複数のページにリソースが必要な場合、新しいHTMLドキュメントごとに同じリソースがコード内にインライン化されるため、リソースが最初に単にキャッシュされた場合よりもHTMLドキュメントが大きくなり、ロード時間が長くなります。

リソースのインライン化の主な欠点は、クライアントがリソースとドキュメントを分離できないことです。 接続を最適化するには、より高度な制御が必要です。これは、HTTP / 2がサーバープッシュに対応しようとするニーズです。

HTTP / 2-サーバープッシュ

HTTP / 2はクライアントの最初の「+ GET +」リクエストに対する複数の同時応答を可能にするため、サーバーはリクエストされたHTMLページとともにリソースをクライアントに送信し、クライアントが要求する前にリソースを提供できます。 このプロセスは_server push_と呼ばれます。 このようにして、HTTP / 2接続は、プッシュされたリソースとドキュメント間の分離を維持しながら、リソースのインライン化という同じ目標を達成できます。 これは、クライアントがメインHTMLドキュメントとは別にプッシュされたリソースをキャッシュまたは拒否することを決定できることを意味し、リソースのインライン化の主な欠点を修正します。

HTTP / 2では、サーバーがリソースをプッシュすることをクライアントに通知するためにサーバーが `+ PUSH_PROMISE `フレームを送信すると、このプロセスが開始されます。 このフレームにはメッセージのヘッダーのみが含まれ、クライアントはサーバーがプッシュするリソースを事前に知ることができます。 既にリソースがキャッシュされている場合、クライアントは応答で ` RST_STREAM `フレームを送信することでプッシュを拒否できます。 ` PUSH_PROMISE +`フレームは、サーバーがプッシュするリソースを認識しているため、クライアントがサーバーに重複したリクエストを送信することも防ぎます。

ここで重要なのは、サーバープッシュの重点がクライアントコントロールであることです。 クライアントがサーバープッシュの優先度を調整する必要がある場合、または無効にする場合でも、いつでもこのHTTP / 2機能を変更するために `+ SETTINGS +`フレームを送信できます。

この機能には多くの可能性がありますが、サーバープッシュは常にWebアプリケーションを最適化するための答えではありません。 たとえば、クライアントに既にリソースがキャッシュされている場合でも、一部のWebブラウザーはプッシュされたリクエストを常にキャンセルできない場合があります。 クライアントが誤ってサーバーに重複リソースの送信を許可した場合、サーバープッシュは接続を不必要に使い果たす可能性があります。 最終的に、サーバープッシュは開発者の裁量で使用する必要があります。 サーバープッシュを戦略的に使用してWebアプリケーションを最適化する方法の詳細については、Googleが開発したhttps://developers.google.com/web/fundamentals/performance/prpl-pattern/[PRPLパターン]をご覧ください。 サーバープッシュで発生する可能性のある問題の詳細については、Jake Archibaldのブログ投稿https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/[HTTP/2プッシュは思ったよりも難しい]をご覧ください。

圧縮

Webアプリケーションを最適化する一般的な方法は、圧縮アルゴリズムを使用して、クライアントとサーバー間を移動するHTTPメッセージのサイズを小さくすることです。 HTTP / 1.1とHTTP / 2はどちらもこの戦略を使用しますが、前者には実装上の問題があり、メッセージ全体の圧縮が禁止されています。 次のセクションでは、なぜそうなるのか、そしてHTTP / 2がソリューションを提供する方法について説明します。

HTTP / 1.1

gzipなどのプログラムは、HTTPメッセージで送信されるデータを圧縮するために、特にCSSファイルとJavaScriptファイルのサイズを縮小するために長い間使用されてきました。 ただし、メッセージのヘッダーコンポーネントは常にプレーンテキストとして送信されます。 各ヘッダーは非常に小さいですが、この非圧縮データの負荷は、より多くの要求が行われるにつれて接続でますます重くなります。特に、多くの異なるリソース、したがって多くの異なるリソース要求を必要とする複雑でAPIが重いWebアプリケーションにペナルティを課します。 さらに、Cookieを使用すると、ヘッダーが非常に大きくなる場合があり、何らかの圧縮の必要性が高まります。

このボトルネックを解決するために、HTTP / 2はHPACK圧縮を使用してヘッダーのサイズを縮小します。これについては、次のセクションで詳しく説明します。

HTTP / 2

HTTP / 2で何度も登場しているテーマの1つは、バイナリフレーミングレイヤーを使用して、より詳細な詳細をより細かく制御できることです。 ヘッダー圧縮に関しても同じことが言えます。 HTTP / 2は、データからヘッダーを分割し、ヘッダーフレームとデータフレームを作成できます。 HTTP / 2固有の圧縮プログラムhttps://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12[HPACK]は、このヘッダーフレームを圧縮できます。 このアルゴリズムは、ハフマンコーディングを使用してヘッダーメタデータをエンコードできるため、サイズが大幅に縮小されます。 さらに、HPACKは以前に伝達されたメタデータフィールドを追跡し、クライアントとサーバー間で共有される動的に変更されたインデックスに従ってさらに圧縮します。 たとえば、次の2つのリクエストを受け取ります。

リクエスト#1

method:     GET
scheme:     https
host:       example.com
path:       /academy
accept:     /image/jpeg
user-agent: Mozilla/5.0 ...

リクエスト#2

method:     GET
scheme:     https
host:       example.com
path:       /academy/images
accept:     /image/jpeg
user-agent: Mozilla/5.0 ...

これらのリクエストのさまざまなフィールド(「+ method i」、「+ scheme&」、「+ host 」、「 accept」、「+ user-agent」など)の値は同じです。 `+ path `フィールドのみが異なる値を使用します。 その結果、 ` Request#2 `を送信するとき、クライアントはHPACKを使用してこれらの共通フィールドを再構築し、 ` path +`フィールドを新たにエンコードするために必要なインデックス値のみを送信できます。 結果のヘッダーフレームは次のようになります。

リクエスト#1のヘッダーフレーム

method:     GET
scheme:     https
host:       example.com
path:       /academy
accept:     /image/jpeg
user-agent: Mozilla/5.0 ...

リクエスト#2のヘッダーフレーム

path:       /academy/images

HTTP / 2は、HPACKおよびその他の圧縮方法を使用して、クライアントサーバーの待ち時間を短縮できるもう1つの機能を提供します。

結論

このポイントごとの分析からわかるように、HTTP / 2は多くの点でHTTP / 1.1と異なり、一部の機能はWebアプリケーションのパフォーマンスをより最適化するために使用できるより高いレベルの制御を提供し、その他の機能は単に以前のプロトコル。 2つのプロトコルの違いについて概要を把握したので、多重化、ストリームの優先順位付け、フロー制御、サーバープッシュ、HTTP / 2の圧縮などの要因がWeb開発の変化する状況にどのように影響するかを検討できます。

HTTP / 1.1とHTTP / 2のパフォーマンス比較をご覧になりたい場合は、異なるレイテンシのプロトコルを比較するhttps://http2.golang.org/gophertiles[Googleデモ]をご覧ください。 コンピューターでテストを実行する場合、ページの読み込み時間は、帯域幅、テスト時に使用可能なクライアントおよびサーバーリソースなどのいくつかの要因によって異なる場合があります。 より徹底的なテストの結果を調べたい場合は、https://css-tricks.com/http2-real-world-performance-test-analysis/ [HTTP / 2 – A Real-世界パフォーマンステストと分析]。 最後に、最新のWebアプリケーションを構築する方法を調べたい場合は、https://www.digitalocean.com/community/tutorials/how-to-build-a-modern-web-application-to- django-and-react-on-ubuntu-18-04で顧客情報を管理する[DjangoとReact on Ubuntu 18.04で顧客情報を管理する最新のWebアプリケーションを構築する方法]チュートリアル、または独自のHTTP / Nginxのセットアップ方法Ubuntu 16.04でのHTTP / 2サポートチュートリアル。