HTTP / 2がWebを高速化する方法

ハイパーテキスト転送プロトコル（ HTTP ）は、World Wide Webの基礎となるシンプルで制限された、非常に退屈なプロトコルです。 実際、HTTPを使用すると、ネットワークに接続されたリソースからデータを読み取ることができ、何十年もの間、高速で安全かつ高品質の「仲介者」として機能しています。

このレビュー記事では、最新のテクノロジーを使用しようとしているエンドユーザー、開発者、および組織にとってのHTTP / 2の使用と利点について説明します。 ここでは、基本からより複雑な問題まで、HTTP / 2に関するすべての必要な情報を見つけることができます。



内容 ：

• HTTP / 2とは何ですか？
• HTTP / 2は何のために作成されましたか？
• HTTP 1.1の何が悪かったのですか？
• HTTP / 2機能
• HTTP / 2はHTTPSでどのように機能しますか？
• HTTP 1.x、SPDY、およびHTTP / 2の違い
• HTTP / 2の主な利点
• HTTPS、SPDY、およびHTTP / 2パフォーマンスの比較
• HTTP / 2ブラウザのサポートと可用性
• HTTP / 2の使用を開始するには？

HTTP / 2とは何ですか？

HTTPは、World Wide Webの作成者であるTim Berners-Leeによって開発されました。 彼は、Webサーバーとクライアント間で高レベルのデータ転送機能を提供するために、プロトコルをシンプルにしました。



HTTPの最初の文書バージョンであるHTTP 0.9は1991年にリリースされました。1996年にHTTP 1.0が登場しました。 1年後、HTTP 1.1が少し改善されました。







2015年2月、 Internet Engineering Council （ IETF ）のHTTPワーキンググループが HTTPプロトコルを改訂し、HTTP / 2の形式で2番目のメジャーバージョンを開発しました。 その年の5月、実装仕様は、Googleが作成したHTTP準拠のSPDYプロトコルへの応答として正式に標準化されました。 HTTP / 2とSPDYの議論は、この記事全体で議論されます。

プロトコルとは何ですか？

「HTTP / 2 vs. HTTP / 1」と言うために、この記事で「プロトコル」という用語自体がよく言及するものを最初に思い出しましょう。 プロトコルは、クライアント（データを要求するWebブラウザーなど）とサーバー（このデータを含むコンピューター）間のデータ転送メカニズムを管理する一連のルールです。



プロトコルは通常、ヘッダー（ヘッダー）、ペイロード（ペイロード）、フッター（フッター）の3つの主要部分で構成されます。 ヘッダーが最初に来て、送信元アドレスと宛先アドレス、およびサイズやタイプなどの他の情報が含まれます。 有用なデータとは、プロトコルを介して送信される情報です。 フッターは最後に送信され、クライアントサーバー要求を宛先にルーティングするための制御フィールドとして機能します。 ヘッダーとフッターにより、有用なデータの転送におけるエラーを回避できます。







通常の紙の手紙で類推すると、テキスト（有用なデータ）は受取人の住所とともに封筒（見出し）に入れられます。 送信前に、封筒は封印され、郵便切手（フッター）が貼られています。 もちろん、これは簡略化されたビューです。 ゼロと1の形式でデジタルデータを送信することはそれほど単純ではなく、インターネットの爆発的な使用に関連する増大する技術的課題に対処するための新しい次元が必要です。



HTTPプロトコルは、当初2つの主要なコマンドで構成されていました。



GET-サーバーから情報を受信し、

POST-ストレージのデータを受け入れます。



この単純で退屈な一連のコマンド-データの受信と要求の送信-は、他の多くのネットワークプロトコルの基礎を形成しました。 プロトコル自体はUXの改善に向けたもう1つのステップであり、そのさらなる開発のためには、HTTP / 2を実装する必要があります。

HTTP / 2は何のために作成されましたか？

1990年代初頭にHTTPが開始されて以来、HTTPのメジャーリビジョンは数回しか行われていません。 最新バージョン-HTTP 1.1-は15年以上使用されています。 コンテンツの動的更新、リソース集約型マルチメディア形式、およびWebのパフォーマンスを向上させたいという過度の欲求の時代に、古いプロトコルの技術は廃止されたもののカテゴリに移行しました。 これらの傾向はすべて、HTTP / 2が提供する重要な変更を必要とします。



HTTPの新しいバージョンを開発する主な目的は、追加のネットワークテクノロジーを必要とせずに、単一のネットワークプロトコルにほとんど関連付けられない3つのプロパティ（シンプル、高性能、および安定性）を提供することでした。 これらのプロパティは、サーバーのイニシアチブ（サーバープッシュ）での多重化、圧縮、要求の優先順位付け、データ送信などの手段を使用して、ブラウザー要求を処理する際の待ち時間を短縮することによって提供されます。



HTTP拡張では、フロー制御、アップグレード、エラー処理などのメカニズムが使用されます。 開発者は、Webアプリケーションの高いパフォーマンスと安定性を提供できます。 集合システム（集合システム）を使用すると、サーバーは要求されたよりも多くのコンテンツをクライアントに効果的に転送できます。これにより、サイトがブラウザーウィンドウに完全に読み込まれるまで、情報を絶えず要求できなくなります。 たとえば、サーバーの主導でデータを送信する機能（サーバープッシュ）は、HTTP / 2によって提供され、ブラウザーキャッシュに既に存在するものを除き、ページ上のすべてのコンテンツをすぐに提供できます。 HTTPヘッダーを効率的に圧縮することにより、プロトコルのオーバーヘッドが最小限に抑えられ、各ブラウザー要求とサーバー応答を処理する際のパフォーマンスが向上します。







HTTP / 2は、HTTP 1.1との互換性と互換性を備えて設計されました。 HTTP / 2の導入は、プロトコルのさらなる発展に弾みをつけることが期待されています。



IETF HTTPワーキンググループのヘッドであり、W3C TAGメンバーであるマークノッティンガム ：

「...すべてのHTTPメソッド、ステータスコードを変更するわけではなく、ほとんどのヘッダーは同じままです。 使用効率を改善するという点でのみ修正しました。そのため、インターネットとの関係でより節約されます...」

HTTPの新しいバージョンはその前身の拡張版であり、近い将来にHTTP 1.1を置き換える可能性は低いことに注意することが重要です。 HTTP / 2の実装は、HTTP 1.1で使用可能なすべてのタイプの暗号化の自動サポートを意味するものではありませんが、より興味深い代替手段の使用、または近い将来の暗号化互換性の追加更新を確実に奨励します。 ただし、HTTP / 2対HTTP 1およびSPDY対HTTP / 2の比較では、この記事の主人公がパフォーマンス、セキュリティ、および信頼性の面で勝者です。

HTTP 1.1の何が悪かったのですか？

HTTP 1.1では、TCP接続ごとに1つの着信要求のみを処理できるため、ブラウザーは複数の要求を同時に処理するために複数の接続を確立する必要があります。



ただし、複数の接続を並行して使用すると、TCPが過負荷になり、ネットワークリソースが不公平に独占されます。 複数の接続を使用して追加のリクエストを処理するブラウザは、利用可能なネットワークリソースの大部分を占有するため、他のユーザーのネットワークパフォーマンスが低下します。







ブラウザーで複数のリクエストを送信すると、伝送ネットワークでデータが重複するため、追加のプロトコルを使用する必要があり、エンドノードで必要な情報を正しく抽出することができます。



ネットワーク業界は、実際には、ドメインのシャーディング、連結、データの埋め込みおよび分割などの手法を使用して、これらの制限をハッキングする必要がありました。 HTTP 1.1の基本的なTCP接続を非効率的に使用すると、リソースの優先順位付けが不十分になり、その結果、Webアプリケーションの複雑性、機能性、量が増えるにつれてパフォーマンスが指数関数的に低下します。











開発中のネットワークには、すでにHTTPテクノロジーの機能が欠けています。 何年も前に開発されたHTTP 1.1の主要な機能により、Webサイトやアプリケーションのセキュリティとパフォーマンスを低下させるいくつかの不快な抜け穴を使用できます。



たとえば、Cookieハックを使用すると、攻撃者は以前の作業セッションを再利用して、ユーザーのパスワードへの不正アクセスを取得できます。 そしてその理由は、HTTP 1.1は究極の認証ツールを提供しないからです。 彼らがHTTP / 2で同様の抜け穴を探すことに気付いて、その開発者は新しいTLS機能の改善された実装の助けを借りてプロトコルのセキュリティを高めようとしました。

HTTP / 2機能

多重化ストリーム

HTTP / 2を介して両側に送信されるテキストフレームのシーケンスは、クライアントとサーバー間で交換され、「ストリーム」と呼ばれます。 HTTPの以前のバージョンでは、一度に1つのストリームしかブロードキャストできず、異なるストリーム間でわずかな遅延がありました。 この方法で大量のメディアコンテンツを転送することは、非効率的でリソースを大量に消費します。 この問題を解決するために、HTTP / 2はフレームの新しいバイナリレイヤーを使用します。



このレイヤーを使用すると、サーバーからクライアントに送信されるデータを、小さな独立したフレームの制御されたシーケンスに変換できます。 そして、フレームのセット全体を受信すると、クライアントは送信されたデータを元の形式で復元できます。 このスキームは、クライアントからサーバーに反対方向に転送される場合にも機能します。







バイナリフレーム形式により、ストリーム間の遅延なしに、双方向に送信される複数の独立したシーケンスを同時に交換できます。 このアプローチには多くの利点があります。

• 並列多重化された要求と応答は互いにブロックしません。
• 多数のデータストリームが送信されますが、ネットワークリソースを最も効率的に使用するために単一のTCP接続が使用されます。
• スプライト、連結、ドメインの断片化など、ネットワークパフォーマンスの他の領域に悪影響を及ぼす最適化ハックを使用する必要がなくなりました。
• 遅延は低く、ネットワークパフォーマンスは高く、検索エンジンのランキングは優れています。
• ネットワークおよびITリソースは、運用コストと資本投資を削減します。

説明されている機能により、異なるストリームからのデータのパケットは、単一のTCP接続を介して混同されます。 エンドポイントでは、これらのパケットは分割され、個別のデータストリームとして提示されます。 HTTP 1.1以前では、複数の要求の並列送信のために同じ数のTCP接続を確立する必要があり、これは、より多くのデータストリームのより高速な転送にもかかわらず、ネットワーク全体のパフォーマンスのボトルネックです。

サーバーが開始したデータの送信（サーバープッシュ）

この機能を使用すると、サーバーは追加のキャッシュされた情報をクライアントに送信できますが、それは要求しなかったが、将来の要求には必要になる可能性があります。 たとえば、クライアントがリソースYを参照するリソースXを要求した場合、サーバーはクライアントが追加の要求を要求するのを待たずにXとともにYを送信できます。







サーバーから受信したリソースYは、将来使用するためにクライアントにキャッシュされます。 このメカニズムにより、要求と応答のサイクルが節約され、ネットワークの待ち時間が短縮されます。 サーバープッシュは元々SPDYプロトコルで登場しました。 :path



ような擬似ヘッダーを含むストリーム識別子は、キャッシュする必要がある追加情報を送信するためにサーバーを開始します。 クライアントは、サーバーがHTTP / 2経由でキャッシュされたリソースを転送することを明示的に許可するか、特別な識別子で開始されたフローを中断する必要があります。



キャッシュプッシュと呼ばれる他のHTTP / 2機能は、クライアントのキャッシュを事前に更新または無効にします。 同時に、サーバーは、クライアントが実際に要求しなかったリソースが必要な場合があることを判断できます。



HTTP / 2の実装は、プロアクティブなリソースを操作するときに高いパフォーマンスを示します。

• 最初に転送されたリソースはクライアントのキャッシュに保存されます。
• クライアントは、これらのリソースを異なるページで再利用できます。
• サーバーは、同じTCP接続内で、イニシアチブ送信されたリソースと要求された情報を多重化できます。
• サーバーはプロアクティブなリソースに優先順位を付けることができます。 これは、HTTP / 2とHTTP 1の主要なパフォーマンスの違いです。
• クライアントは、リポジトリの効率を維持するためにプロアクティブなリソースを拒否するか、サーバープッシュ機能を完全に無効にする場合があります。
• クライアントは、プロアクティブに送信されるデータで同時に多重化されるストリームの数を制限することもできます。

インライン化などの最適でない手法でも、プッシュ機能を使用して、サーバーが要求に応答するようにします。 同時に、サーバープッシュはプロトコルレベルのソリューションであり、最適化ハッキングによる大騒ぎを回避するのに役立ちます。



HTTP / 2は、他の要求/応答ストリームの場合と同様に、パフォーマンスを改善するために、積極的に送信されるデータでストリームを多重化し、優先順位を付けます。 組み込みのセキュリティメカニズムがあります。これにより、その後のリソースのプロアクティブな転送のためにサーバーを事前に承認する必要があります。

バイナリプロトコル

HTTPの最新バージョンでは、機能の面で大幅な変更が行われ、テキストプロトコルからバイナリプロトコルへの変換が実証されています。 ループを完了するために、HTTP 1.x要求/応答ループはテキストコマンドを処理します。 HTTP / 2は、バイナリコマンド（1と0で構成される）で同じ問題を解決します。 これにより、フレームの操作が簡単になり、コマンドがテキストとオプションのスペースで構成されているために混乱する可能性のあるコマンドの実装が簡素化されます。



バイナリコマンドの読み取りは、同様のテキストコマンドよりも難しくなりますが、ネットワークがそれらを生成してフレームを解析するのは簡単です。 セマンティクスは変更されません。 HTTP / 2を使用するブラウザは、ネットワークに送信する前にテキストコマンドをバイナリに変換します。 フレームのバイナリレイヤーは、HTTP 1.xを使用するクライアントおよびサーバーと下位互換性がありません。 これは、SPDYおよびHTTP 1.xよりもパフォーマンスを大幅に向上させる重要な要素です。 インターネット企業およびオンラインサービスにバイナリコマンドを使用する利点は何ですか。

• 低い解析オーバーヘッドは、HTTP / 2がHTTP 1よりも重要な利点です。
• エラーの可能性を低くします。
• ネットワーク負荷が少ない。
• ネットワークリソースの効率的な使用。
• HTTP 1.xのテキストの性質に起因する応答分割攻撃などのセキュリティ問題の解決。
• 圧縮、多重化、優先順位付け、フロー制御、効率的なTLS処理など、その他のHTTP / 2機能が実装されています。
• チームのコンパクトさにより、チームの処理と実装が簡素化されます。
• クライアントとサーバー間で送信されるデータを処理するときの効率とフォールトトレランスの向上。
• ネットワーク遅延を減らし、帯域幅を増やします。

スレッドの優先順位付け

HTTP / 2を使用すると、クライアントは特定のデータストリームを優先できます。 サーバーはそのようなクライアントの指示に従う必要はありませんが、それにもかかわらず、このメカニズムはサーバーがエンドユーザーの要件に従ってネットワークリソースの分配を最適化するのに役立ちます。







優先順位付けは、各スレッドに依存関係と重みを割り当てることによって行われます。 実際、すべてのスレッドはすでに互いに依存していますが、1〜256の範囲の重みの割り当てが追加されています。優先順位付けメカニズムの詳細については、まだ議論中です。 ただし、実際の状況では、サーバーがCPUやデータベース接続などのリソースを管理することはほとんどありません。 実装自体が複雑であるため、サーバーがスレッドの優先順位付けの要求を満たすことができません。 プロトコルは単一のTCP接続内で複数のストリームを処理できるため、この方向で作業を継続することは、長期的にHTTP / 2を成功させるために特に重要です。



優先順位付けは、エンドユーザーのニーズに応じてサーバーに同時に送信される要求を分離するのに役立ちます。 また、データストリームをランダムな順序で処理すると、HTTP / 2の効率と利便性が損なわれます。 同時に、フローに優先順位を付けるための考え抜かれた広範なメカニズムには、次の利点があります。

• ネットワークリソースの効率的な使用。
• プライマリコンテンツリクエストの配信時間を短縮します。
• ページの読み込み速度を改善します。
• クライアントとサーバー間のデータ転送の最適化。
• ネットワーク遅延の悪影響を減らします。

ステートフルヘッダー圧縮

ユーザーに最高の印象を与えるには、最新のWebサイトにコンテンツとグラフィックが豊富に含まれている必要があります。 HTTPはステートレスプロトコルです。つまり、サーバーが対応する操作を実行するためには、各クライアントリクエストに可能な限り多くの情報を含める必要があります。 その結果、サーバーは以前のクライアント要求からの情報を保存する必要がないため、データストリームには複数の繰り返しフレームが含まれます。



Webサイトに多数のメディアコンテンツが含まれている場合、クライアントはヘッダーを持つほぼ同一のフレームを送信します。これにより、遅延が増加し、無限ではないネットワークリソースが過剰に消費されます。 優先順位付けされたデータストリームの組み合わせをさらに最適化しないと、目的の同時実行パフォーマンス基準を達成できません。







HTTP / 2では、これは多数の冗長ヘッダーフレームを圧縮することで解決されます。 圧縮はHPACKアルゴリズムを使用して実行されます。これは単純で安全な方法です。 クライアントとサーバーは、以前のリクエストで使用されたヘッダーのリストを保持します。



HPACKは各ヘッダーの値を圧縮してからサーバーに送信し、サーバーは以前に受信した値のリストで暗号化された情報を検索して、ヘッダー情報を完全に復元します。 HPACK圧縮は、信じられないほどのパフォーマンス上の利点を提供し、以下も提供します。

• 効率的なスレッドの優先順位付け。
• 多重化メカニズムの効果的な使用。
• リソース使用時のオーバーヘッドを削減します。 これは、HTTP / 2とHTTP 1およびSPDYを比較するときに議論される最初の問題の1つです。
• 頻繁に使用される大規模なヘッダーのエンコード。これにより、ヘッダー付きのフレーム全体を送信できなくなります。 各ストリームの送信サイズは急速に減少します。
• CRIMEなどの攻撃に対する耐性-圧縮されたヘッダーを持つデータストリームの悪用。

HTTP 1.xとSPDYの違い

ステータスコード、URI、テクニック、ヘッダーファイルなど、最後のHTTP / 2の繰り返しにおけるHTTPアプリケーションの基本的なセマンティクスは変更されていません。 HTTP / 2は、Googleが作成したHTTP 1.xの代替であるSPDYに基づいています。 主な違いは、クライアント/サーバー要求を処理するメカニズムにあります。 この表は、HTTP 1.x、SPDY、およびHTTP / 2の主な違いを示しています。

HTTP 1.x	SPDY	HTTP2
SSLは必須ではありませんが、推奨されます。	SSLが必要です。	SSLは必須ではありませんが、推奨されます。
暗号化が遅い。	高速暗号化。	暗号化はさらに高速です。
1つのTCP接続に対する1つのクライアントサーバー要求。	1つのTCP接続に対する多くのクライアントサーバー要求。 同じホストに同時に実装されます。	マルチホスト多重化。 単一インスタンスの複数のホストに実装されます。
ヘッダー圧縮なし。	ヘッダー圧縮が導入されました。	改善されたヘッダー圧縮アルゴリズムが使用され、パフォーマンスとセキュリティが向上します。
スレッドの優先順位付けはありません。	スレッドの優先順位付けが導入されました。	スレッドの優先順位付けメカニズムの改善。

HTTP / 2がHTTPSで機能する方法

HTTPSは、高度なセキュリティのネットワーク接続を確立するために使用されます。これは、重要なビジネスおよびユーザー情報の処理において重要な役割を果たします。 攻撃者の主な目的は、金融取引を処理する銀行と、医療記録を蓄積する医療機関です。 HTTPSは、絶え間ないサイバー脅威に対する保護のレイヤーとして機能しますが、貴重な企業ネットワークを狙った複雑な攻撃の反映は、セキュリティ上の考慮事項だけではありません。







HTTP / 2ブラウザのサポートにはHTTPS暗号化が含まれ、実際、HTTPSを使用する場合の全体的なセキュリティパフォーマンスが向上します。 機密性の高いネットワーク環境でデジタル通信を保護するのに役立つHTTP / 2の主な機能は次のとおりです。

• TLSハンドシェイクの減少、
• クライアント側とサーバー側のリソースの消費が少ない
• 既存のWebセッションの再利用機能が改善されましたが、HTTP 1.xに固有の脆弱性はありません。

HTTPSは、有名企業だけでなく、サイバーセキュリティを確保するためにも使用されます。 このプロトコルは、オンラインサービスの所有者、通常のブロガー、オンラインストア、さらにはソーシャルネットワークのユーザーにも役立ちます。 HTTP / 2にはTLSの最新で最も安全なバージョンが必要であるため、すべてのオンラインコミュニティ、会社の所有者、およびウェブマスターは、サイトがデフォルトでHTTPSを使用することを確認する必要があります。



一般的なHTTPS設定手順には、Webホスティングプランの使用、セキュリティ証明書の購入、アクティブ化、インストール、およびHTTPSを使用できるようにサイト自体を更新することが含まれます。

HTTP / 2の主な利点

ネットワーク業界では、従来のHTTP 1.xを別のプロトコルに置き換える必要があります。このプロトコルの利点は、一般ユーザーにとって有用です。 HTTP 1.xからHTTP / 2への移行は、ほぼ完全に、現代の期待に応える技術的利点の可能性が最大限に増加したためです。



eコマースおよびインターネットユーザーの観点からは、ネットワーク上の関連性の低いコンテンツとリッチメディアほど、動作が遅くなります。



HTTP / 2は、クライアントとサーバー間のデータ交換の効率を高めることを目的として作成されました。これにより、ビジネスマンは市場セグメントの範囲を拡大し、ユーザーは高品質のコンテンツにすばやくアクセスできます。 とりわけ、今日のウェブはかつてないほど状況的です。







インターネットアクセス速度は、特定のネットワークと地理的な場所によって異なります。 モバイルユーザーの割合は急速に増加しており、過負荷のセルラーネットワークがブロードバンドアクセスと競合できない場合でも、あらゆるフォームファクターのモバイルデバイスで十分に高速のインターネットを提供する必要があります。 この問題の完全な解決策はHTTP / 2です。これは、完全に改訂および再設計されたネットワークメカニズムとデータ転送メカニズムの組み合わせです。 HTTP / 2の主な利点は何ですか？

ネットワーク性能

この概念は、すべてのHTTP / 2イノベーションの複合効果を反映しています。 ベンチマークの結果（「HTTPS、SPDY、およびHTTP / 2のパフォーマンス比較」の章を参照）は、HTTP / 2を使用した場合のパフォーマンスが、先行モデルおよび代替ソリューションと比較して向上していることを示しています。







各クライアント/サーバーデータ交換サイクルでより多くのデータを送受信するプロトコルの機能は、最適化のハックではなく、HTTP / 2の現実的で手頃な価格で実用的な利点です。 たとえば、 真空トレインと従来の真空トレインを比較できます。摩擦と空気抵抗がないため、車両はより速く移動し、より多くの乗客を乗せ、より強力なエンジンを設置せずに利用可能なチャネルをより効率的に使用できます。 列車の重量も軽減され、空力特性が改善されました。



多重化などの技術は、より多くのデータを同時に転送するのに役立ちます。 座席がぎっしり詰まった複数のフロアを備えた大型旅客機のように。



データ転送メカニズムがネットワークパフォーマンスを改善するためのすべての障壁を一掃するとどうなりますか？ サイトの高速化には副作用があります。ユーザーの喜び、検索サービスの最適化の改善、リソースの効率的な使用、視聴者と販売量の増加などです。



幸いなことに、HTTP / 2の導入は、大型旅客列車用の真空トンネルを作成するよりも比較にならないほど実用的です。

モバイルネットワークのパフォーマンス

毎日、何百万人ものユーザーがモバイルデバイスからネットワークにアクセスしています。 私たちは「ポストPC時代」に住んでいます。多くの人は、スマートフォンを主なデバイスとして使用し、長時間デスクトップモニターの前に座る代わりに、外出先でオンラインサービスにアクセスし、ほとんどのルーチンコンピューティングタスクを実行します。



HTTP / 2は、ネットワーク使用の現在の傾向に合わせて設計されました。 モバイルインターネットの小さな帯域幅を平準化するタスクは、ヘッダーの多重化と圧縮による遅延を減らすことで十分に解決されます。 新しいバージョンのプロトコルのおかげで、モバイルデバイスでのデータ交換のパフォーマンスとセキュリティは、デスクトップで一般的なレベルに達しました。 これは、オンラインビジネスが潜在的なオーディエンスにリーチする能力にすぐにプラスの効果をもたらします。

インターネットは安い

World Wide Webの作成以来、インターネットの使用コストは急速に低下しています。 ネットワークテクノロジーの開発の主な目的は、常にアクセスの拡大と速度の向上です。 しかし、特に電気通信プロバイダーの独占に関する申し立てに照らして、価格の下落は停滞しているようです。







HTTP / 2の実装中のスループットの向上とデータ交換の効率の改善により、プロバイダーはアクセス速度を低下させることなく運用コストを削減できます。 また、運用コストを下げることで、プロバイダーは低価格セグメントでより積極的に動き、既存の料金内でより高速なアクセスを提供できます。

広範なリーチ

アジアとアフリカの人口密度の高い地域では、依然として許容できる速度でインターネットにアクセスできません。 プロバイダーは、大都市と先進地域でのみサービスを提供することにより、利益を最大化しようとします。 HTTP / 2の利点のおかげで、遠隔地や未開発地域の居住者にリソースとチャネル容量の一部を割り当てることにより、ネットワークの負荷を減らすことができます。

リッチメディア

今日、インターネットユーザーは、実質的にマルチメディアが豊富なコンテンツと、インスタントページロードのサービスを要求しています。 さらに、競争を成功させるために、サイト所有者は定期的にコンテンツを更新する必要があります。 対応するインフラストラクチャのコストは、クラウドベースのサブスクリプションサービスを使用している場合でも、インターネットスタートアップにとって必ずしも高揚するとは限りません。 HTTP / 2の利点と技術的特徴は、おそらくファイルサイズを大幅に削減する助けにはなりませんが、クライアントとサーバー間で「重い」メディアコンテンツを転送する際のオーバーヘッドから数バイトを削除します。

モバイルインターネットエクスペリエンスの改善

進歩的なオンライン企業は、急成長中のモバイルユーザーに効果的にリーチするためのMobile-Firstの戦略に従っています。 おそらく、モバイルインターネットの使用に影響する主な制限は、スマートフォンとタブレットのハードウェアコンポーネントの最も顕著な特性ではありません。 これは、リクエスト処理の遅延が長くなることを意味します。 HTTP / 2は、ダウンロード時間とネットワーク遅延を許容可能なレベルまで削減します。

ネットワークのより効率的な使用

複雑なデザインの「重い」メディアコンテンツとサイトは、クライアントとサーバーがブラウザーのリクエストを処理する際に、リソース消費の顕著な増加につながります。 Web開発者は受け入れ可能な最適化ハッキングを開発しましたが、HTTP / 2の形で安定した信頼できるソリューションの出現は避けられませんでした。 , , — , .

安全性

HTTP/2 . HPACK , . , , HTTP/2 « » (Security by Obscurity): , HTTP-. , Transport Layer Security (TLS1.2).

HTTP/2 . , . , HTTP/2, SPDY, HTTP 1.x. HTTP/2 SPDY, HTTP. - .

HTTP/2 SEO

SEO- - . - , , SEO- . - . , , , , . , , .



-. . SEO-, -, . HTTP/2 , - .







HTTP/2 . -, , HTTP/2, SEO. -, - HTTP/2 .

HTTPS, SPDY HTTP/2

.







HTTP/2 , , , , .



:



:

• : HTTP/2 , . SPDY . HTTPS .
• : HTTP/2- , .
• TCP- : () HTTP/2 SPDY , , .
• : HTTP/2 SPDY. HTTPS - .

HTTP/2

HTTP/2 , . , HTTP 1.x, HTTP/2 . , . , — . , - . : , HTTP/2.

HTTP/2 — «» . Chrome Firefox , Safari HTTP/2 2014. IE Windows 8.







, Android Browser, Chrome Android iOS, Safari iOS8 , HTTP/2. , .

: Apache Nginx

-, , HTTP/2 . , HTTP/2, .



Nginx -, 66% - , HTTP / 2. HTTP/2 Apache, mod_spdy . Google Apache 2.2 , . Apache Software Foundation.

HTTP/2?

HTTP/2 :

1. , HTTPS:
   
   
   • SSL TLS.
   • .
   • .
   • HTTPS.
2. , HTTP/2 . Nginx , Apache 2015 ( 2.4). HTTP/2 .
3. , . Apache. - , HTTP/2.
4. HTTP/2 .

おわりに

HTTP/2. , , HTTP 1.x, - . HTTP/2 , HTTP 1.x .



, HTTP/2 — . - , , , - -.