HTTP / 1.1とHTTP / 2：違いは何ですか？

ハイパーテキスト転送プロトコル（HTTP）は、1989年の発明以来、World Wide Webでの通信の事実上の標準となっているアプリケーションプロトコルです。 1997年のHTTP / 1.1のリリースから最近まで、プロトコルの改訂はほとんどありませんでした。 しかし、2015年には、特にモバイルプラットフォームやサーバー集約型のグラフィックスやビデオを扱う場合に、待ち時間を短縮するためのいくつかの方法を提供するHTTP / 2と呼ばれる刷新バージョンが使用されるようになりました。 HTTP/2 has since become increasingly popular, with some estimates suggesting that around a third of all websites in the world support it. この変化する状況の中で、Web開発者はHTTP / 1.1とHTTP / 2の技術的な違いを理解することで利益を得ることができ、進化するベストプラクティスに関する情報に基づいた効率的な決定を行うことができます。

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

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

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

[[http-1-1 -—-パイプラインおよびヘッドオブラインブロッキング]] === HTTP / 1.1 —パイプラインおよびヘッドオブラインブロッキング

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

HTTP/1.1 takes care of this problem by introducing persistent connections and pipelining. 持続的接続の場合、HTTP / 1.1は、閉じるように直接指示されない限り、TCP接続を開いたままにすることを前提としています。 これにより、クライアントは各接続への応答を待たずに同じ接続で複数の要求を送信でき、HTTP / 1.0 over HTTP / 1.0のパフォーマンスが大幅に向上します。

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

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

[[http-2 -—- advantages-of-the-binary-framing-layer]] === HTTP / 2 —バイナリフレーミングレイヤーの利点

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

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

最も詳細なレベルでは、通信チャネルは、それぞれが特定のストリームにタグ付けされた一連のバイナリエンコードフレームで構成されます。 識別タグにより、接続は転送中にこれらのフレームをインターリーブし、もう一方の端で再組み立てできます。 インターリーブされた要求と応答は、背後にあるメッセージをブロックすることなく並行して実行できます。これは、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 -—- stream-prioritization]] === HTTP / 2 —ストリームの優先順位付け

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

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

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

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

この依存関係ツリーでは、ストリーム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がこのメカニズムの異なるバージョンを使用して、異なる配信モデルに従ってフロー制御を処理する方法の概要を説明します。

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

ただし、この問題には解決策があります。サーバーはクライアントが追加のファイルを必要とすることを事前に知っているため、サーバーはこれらのリソースを要求する前にクライアントに送信することでクライアントの時間を節約できます。 HTTP/1.1 and HTTP/2 have different strategies of accomplishing this, each of which will be described in the next section.

[[http-1-1 -—- resource-inlining]] === HTTP / 1.1 —リソースのインライン化

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

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

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

[[http-2 -—- server-push]] === HTTP / 2 —サーバープッシュ

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

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

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

この機能には多くの可能性がありますが、サーバープッシュがWebアプリケーションの最適化の答えとは限りません。 たとえば、クライアントに既にリソースがキャッシュされている場合でも、一部のWebブラウザーはプッシュされたリクエストを常にキャンセルできない場合があります。 クライアントが誤ってサーバーに重複リソースの送信を許可した場合、サーバープッシュは接続を不必要に使い果たす可能性があります。 最終的に、サーバープッシュは開発者の裁量で使用する必要があります。 サーバープッシュを戦略的に使用してWebアプリケーションを最適化する方法の詳細については、Googleが開発したPRPL patternを確認してください。 サーバープッシュで発生する可能性のある問題の詳細については、Jake Archibaldのブログ投稿HTTP/2 push is tougher than I thoughtを参照してください。

Webアプリケーションを最適化する一般的な方法は、圧縮アルゴリズムを使用して、クライアントとサーバー間を移動するHTTPメッセージのサイズを小さくすることです。 HTTP/1.1 and HTTP/2 both use this strategy, but there are implementation problems in the former that prohibit compressing the entire message. 次のセクションでは、なぜそうなるのか、そしてHTTP / 2がソリューションを提供する方法について説明します。

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

HTTP /1.1とHTTP / 2のパフォーマンスの比較を確認したい場合は、さまざまなレイテンシーのプロトコルを比較するこのGoogle demoを確認してください。 コンピューターでテストを実行する場合、ページの読み込み時間は、帯域幅、テスト時に使用可能なクライアントおよびサーバーリソースなどのいくつかの要因によって異なる場合があります。 より徹底的なテストの結果を調べたい場合は、記事HTTP/2 – A Real-World Performance Test and Analysisをご覧ください。 最後に、最新のWebアプリケーションを構築する方法を探求したい場合は、How To Build a Modern Web Application to Manage Customer Information with Django and React on Ubuntu 18.04チュートリアルに従うか、How To Set Up Nginx with HTTP/2 Support on Ubuntu 16.04チュートリアルを使用して独自のHTTP / 2サーバーをセットアップできます。