概要
HTTP / 2は、 ハイパーテキスト転送プロトコル またはHTTP 【01]、ブラウザがWebサーバーと通信するために使用します。 以前のSPDYから派生 【02] プロトコル、HTTP / 2は、1.1年のRFC 2068でのHTTP / 1997の標準化以来、HTTPの最初の新しいバージョンです。
これは、IETF（Internet Engineering Task Force）HTTPワーキンググループによって開発されました。 httpbis （「bis」は「7540回」を意味します）、RFC XNUMXとして公開 【03] 月2015中。
HTTP / 2の採用
HTTP / 2は、公式の発表以来、作業中のWebサイトで採用される機会が増えています。 オンライン調査サービスW3Techs 【04] は、2017年2018月から2年16月にかけて、監視対象のすべてのWebサイトのHTTP / 30サポートがXNUMX％からXNUMX％に増加したことに言及しています。
さらに、主要なブラウザー（Chrome、Firefox、Edgeなど）はすでにHTTP / 2を完全にサポートしています。 【05]。 （一部はHTTP / 2が標準として受け入れられる前に実験的な実装を開発しました。）
この広範な採用は、HTTP / 2がWebの事実上の通信プロトコルになる可能性があることを意味します。
HTTP / 2の背後にある動機
HTTPS'チャーター 【06] は、HTTP / 1.1の動機として改善できるHTTP / 2のいくつかのコンポーネントについて言及しています。 ただし、グループの主な目的は、エンドユーザーが感じる待ち時間を減らすことでした。
これをする、 httpbis ヘッダーの圧縮と積極的なプリフェッチ技術（サーバープッシュなど）による帯域幅オーバーヘッドの最小化を検討すると同時に、接続の輻輳やヘッドオブライン（HoL）ブロッキング問題などの既知のパフォーマンス問題に体系的に対処しようとする 【07].
さらに、HTTP / 2には下位互換性が必要でした。つまり、HTTP / 1.1と同じメソッド動詞、ステータスコード、URI、および（ほとんどの）ヘッダーフィールドを使用する必要がありました。 また、HTTP / 2は、デスクトップおよびモバイルWebブラウザー、プログラミングインターフェイス、プロキシ、ファイアウォールなどの一般的なHTTPの使用例をサポートするように設計する必要がありました。
この互換性を維持するために、ワーキンググループは、クライアントとサーバーがHTTP / 1.1、HTTP / 2、または非HTTPプロトコルの中から選択できるようにするプロトコルネゴシエーションメカニズムを開発しました。
では、HTTP / 2の新機能は何でしょうか。
HTTP / 2は、HTTP / 1.1で使用されているのと同じURIスキームとポート番号を使用します（つまり、 http URI、およびポート443 https URI）ですが、多くのことは内部では異なる方法で行われます。
最も根本的な変化は、 フレーム HTTP / 2の基本データ単位として。
HTTP / 1.1は伝統的に パケット ネットワークデータを表します。 クライアントは、メソッド動詞（例： GET or POST）、接続を説明するヘッダーのリスト、およびアプリケーションデータを含む本文を追加します。
要求パケットを受信すると、HTTP / 1.1サーバーは、要求された情報を含む同様の応答パケットで応答します。 その結果、要求と応答のサイクルごとに新しい接続が必要になります。
逆に、HTTP / 2クライアントはサーバーとの単一のネットワーク接続を確立し、以降のすべてのネットワーク通信に使用します。 ヘッダー、ユーザーデータ、エラーメッセージ、およびそのような情報は、フレームと呼ばれる個別のバイナリデータ構造にパックされてから、ネットワーク経由で送信されます。
これは小さな変更のように見えますが、大きな影響があります。
ヘッダー圧縮
フレームを使用する大きな利点は、HTTP / 2ヘッダーが HEADER 通常の圧縮方法を使用して圧縮できるフレーム。 ヘッダーはデータの前に転送する必要があるため、ヘッダー圧縮により、HTTP / 2によって課せられる帯域幅のオーバーヘッドを減らすことができます。
ヘッダー圧縮は、以下のパフォーマンス向上HTTP / 2機能とともに、最小限のネットワーク使用が必要なモバイルまたはモノのインターネット（IOT）アプリケーションで特に役立ちます。
ストリームと多重化
意味的に関連するフレームの独立したシーケンスは、 流れ。 ストリームには、他のエンドポイントがそれらを区別できるように、ストリームを作成したエンドポイント（クライアントまたはサーバー）によって一意の識別子が割り当てられます。
エンドポイントは、同じHTTP / 2接続を介して複数のストリームからフレームをインターリーブできるため、単一のネットワーク接続で複数の同時に開いているストリームをサポートできます。このプロセスは、 多重化 【08].
同じ接続を再利用すると、前述の接続の輻輳やHoLの問題などが緩和され、以前のHTTPバージョンよりもパフォーマンスが向上し、ユーザーエクスペリエンスがスムーズになります。
ストリームの依存関係と優先順位付け
複数の並行ストリームを管理することは、一部のストリームが他のストリームより先に処理されることを意味します。 HTTP / 2では、開発者（または管理者）がこの動作を、 ストリームの依存関係.
ストリームは、処理される前に別のストリームの完全な転送に依存する場合があります。 たとえば、類似コンテンツの推奨の前にWebページのメインコンテンツをロードする必要があるサイトでは、HTTP / 2により、メインコンテンツストリームに依存する推奨ストリームを作成できます。
HTTP / 2もサポート ストリームの優先順位付け。 つまり、各ストリームに優先度を割り当てて、エンドポイントがストリームのフレームを処理するためにリソースをどの程度緊急に割り当てる必要があるかを提案できます。
優先順位付けとストリームの依存関係は、開発者とWebサイトの所有者がサイトのネットワーク使用を最適化するのに役立ち、サイトのユーザーエクスペリエンスを大幅に向上させることができます。
サーバープッシュ
最後に、HTTP / 2は「プッシュ」機能を提供することにより、Webサイトのパフォーマンスを向上させることができます。 HTTP / 2 Webサーバーは、クライアントが最初に要求したよりも多くのクエリのデータで応答できます。 これにより、サーバーは、ブラウザーが最初の応答を検査するのを待たずに、Webブラウザーがページをレンダリングする必要があることがわかっているデータを提供できるため、追加の要求サイクルのオーバーヘッドがありません。
サーバープッシュにより、開発者はブラウザーがWebサイトをレンダリングするために必要なリクエストの数を完全に制御できます。 この機能を正しく使用すると、ネットワークのオーバーヘッドを最小限に抑えることができます。
当然、プッシュ機能の誤用は、実際に必要な帯域幅よりも多くの帯域幅を浪費する可能性があります。 このため、HTTP / 2では、クライアントは最初に接続をネゴシエートするときにサーバープッシュを無効にするように要求できます。
HTTP / 2セキュリティ
ここまで読んだら、HTTP / 2の開発者がパフォーマンスの向上に本当に力を入れていることは明らかです。 ただし、HTTP / 2はブラウザユーザーのセキュリティ全体の向上にも役立つことに注意してください。
より具体的には、HTTP / 2はHTTP URI（つまり暗号化なし）とHTTPS URI（ TLS 暗号化されたチャネル）。 標準自体は暗号化を使用する必要はありませんが、すべての主要なブラウザー実装（Firefoxなど） 【09]、Chrome、Safari、Opera、IE、Edge）は、 の HTTP / 2 overをサポート TLS.
実際、ブラウザはクリアテキストのHTTP / 2と暗号化されたHTTP / 2を区別します TLS 2つの異なるプロトコルとして。 暗号化されたHTTP / XNUMXが呼び出されます h2 クリアテキスト h2c。 これを書いている時点では、主要なブラウザはどれもサポートしていません h2c 、それは意味すること TLS WebサイトがHTTP / 2の他の利点を利用するには、暗号化が必須です。 したがって、HTTP / 2がデフォルトのWebネットワークプロトコルになると、SSL /にまだアップグレードしていないレガシーWebサイトの所有者TLS、最終的にそうするよう強く動機付けられます。
まとめ
HTTP / 2の広範な採用により、新しく改善されたWebがもたらされます。 より高速で、必要な帯域幅が少なく、Webサイトのセキュリティを維持するのに役立ちます。 その主流の採用により、Webユーザーエクスペリエンス全体がよりスムーズで安全になります。
今日証明書を取得し、将来私たちに参加します。
