HTTP/2：背景、パフォーマンスの利点、実装

http/2：Webページの読み込み速度を大幅に改善するネットワークプロトコル

コアポイント：

• HTTP/2（2015年にリリース）は、HTTPヘッダーを圧縮し、単一の接続でサーバーのプッシュと多重化リクエストを実装することにより、前任者のHTTP/1.1の遅延問題を解決します。また、ヘッドオブチームブロッキングの問題を解決するように設計されており、デフォルトで暗号化が必要です。
• HTTP/1.1からHTTP/2への移行には、既存のWebサイトとの逆方向の互換性が必要であるため、課題がないわけではありません。プロトコルの改善は、インターネットを中断しない方法で実装する必要があります。
• すべての主流ブラウザーは現在HTTP/2をサポートしていますが、すべてのHTTP/2要求を暗号化する必要があります。これはHTTP/2仕様自体の要件ではありません。
• サーバーにHTTP/2の実装には、通常、サーバーソフトウェアまたはホスティング環境をHTTP/2をサポートするバージョンにアップグレードし、HTTP/2機能を有効にするようにサーバーを構成することが含まれます。 HTTP/2にはSSL証明書が必要であるため、WebサイトはHTTPSを通じてサービスを提供する必要があることに注意する必要があります。

httpプロトコルの進化：

インターネットのインフラストラクチャ（または物理ネットワークレイヤー）は、インターネットプロトコル（TCP/IPまたは輸送層の一部として）です。これは、ほとんどのインターネット通信のインフラストラクチャです。

上記の上記はアプリケーションレイヤーであり、さまざまなアプリケーションがさまざまなプロトコルを使用して情報を接続および送信します。たとえば、SMTP、POP3、および電子メールを送信してXMPPがあります。

インターネットと同義である最も有名なプロトコルは、HTTP（HyperText Transfer Protocol）です。私たちは毎日それを使用してウェブサイトにアクセスします。 1989年には、ティムバーナーズリーがCERNのCERNで設計しました。バージョン1.0の仕様は1996年にリリースされ（RFC 1945）、バージョン1.1は1999年にリリースされました。

HTTP仕様はWorld Wide Web Allianceによって維持されており、https：//www.w3.org/standards/techs/httpにあります。

HTTPプロトコルの第1世代（バージョン1.0および1.1）は、HTTP/2のリリース後、2015年までインターネットを支配していました。

HTTP/1.1の制限：

HTTPは、リクエスト応答構造に基づいたステートレスプロトコルです。つまり、クライアントはAtomicであるサーバーにリクエストを行います。 （そのため、Cookieを使用しています。たとえば、ユーザーセッションで複数のリクエストを接続して、ログインしたユーザーに認証されたバージョンを提供できるようにします）。

転送は通常、クライアント（ユーザーのブラウザ）によって開始され、サーバーは通常、これらの要求にのみ応答します。

現在のHTTP状態は非常に「不器用」であるか、むしろ低レベルであり、ブラウザーとサーバーに多くの「ヘルプ」が必要であり、効果的に通信する方法を説明することが必要であると言えます。既存のウェブサイトの多くは、導入された変更との後方互換性に依存しているため、この分野で変更を加えることは容易ではありません。プロトコルを改善するために設計された操作は、インターネットを中断することなくシームレスな方法で行う必要があります。

多くの点で、この厳格な要求応答、アトミック、同期モデルはボトルネックになり、通常はGoogleやFacebookなどの業界リーダーが率いるハッキングの形をとりました。通常の状況（さまざまな方法で改善されています）は、訪問者がWebページをリクエストし、ブラウザがサーバーからそれを受信するとき、HTMLを解析し、CSS、画像、画像などのページをレンダリングするために必要な他のリソースを見つけます。とjavascript。これらのリソースリンクに遭遇すると、他のすべてのコンテンツのロードを停止し、指定されたリソースをサーバーからリクエストします。受信するまではまったく動きません。次に、別のリソースなどを要求します。

世界のトップウェブサイトの読み込みに必要なリクエストの数は通常数百です。

これには、多くの待ち時間と、訪問者が白い画面や半レンダリングされたWebサイトのみを見ることができる多くの往復時間が含まれます。これらはすべて無駄な数秒です。これらの要求サイクル中、利用可能な帯域幅の大量はアイドル状態で未使用です。

CDNはこれらの問題の多くを軽減できますが、それらは単なる一時的な解決策でもあります。

MozillaのDaniel Stenberg（HTTP/2標準化に関与する人々の1人）が指摘したように、プロトコルの最初のバージョンは、基礎となる輸送層TCPの容量を最大限に活用するのが困難です。 Webサイトの読み込み速度の最適化に取り組んでいるユーザーは、これが通常、それをe曲的に置くために何らかの創造性を必要とすることを知っています。

時間が経つにつれて、インターネット帯域幅の速度は大幅に向上しましたが、HTTP/1.1 ERAのインフラストラクチャはこれを最大限に活用していません。 HTTPパイプラインなどの問題に対処するのに苦労しています。これは、同じTCP接続の上でより多くのリソースをプッシングするなどです。ブラウザのクライアントは、ほとんどのドラッグをサポートしていますが、FirefoxとChromeはデフォルトでそれを無効にします。または、IE、Firefox 54バージョンなど、まったくサポートされていません。これは、小さなリソースでさえ新しいTCP接続を開く必要があることを意味し、TCPハンドシェイク、DNSルックアップ、遅延など、続くすべての膨満感が必要です。他のリソースの読み込み。

非パイプライン接続のパイプライン接続の比較を同期し、負荷時間の節約の可能性を示します。

HTTP/1モデルでは、Web開発者がWebサイトに最適化するために使用する必要がある最適化手法、CSS、JavaScript接続、シャード（訪問者のリソースリクエストが複数のドメインまたはサブドメインに配布されます）。

改善が必要です。これらの問題は、既存のWebの作業を中断しないように、シームレスで後方互換性のある方法で対処する必要があります。

spdy and http/2：

2009年、Googleは次世代のプロトコルSPDYのドラフト提案になるプロジェクトを発表し、Chromeのサポートを追加し、今後数年間でそれを押しましたサービス。その後、ApacheやNginxなどのTwitterやサーバーメーカーは、サポート、node.js、およびその後のFacebook、WordPress.com、およびほとんどのCDNプロバイダーも提供しました。 Spdyは、単一のTCP接続で複数のリソースを並行して分析する多重化を導入します。接続はデフォルトで暗号化され、データは圧縮されます。まず、Spdy White Paperの最初の25のWebサイトの予備テストでは、速度が27％以上増加して60％以上であることが示されました。

生産環境での有効性を証明した後、SPDYバージョン3は、2015年にハイパーテキスト転送プロトコルのワーキンググループであるHTTPBISによって開発された最初のドラフトHTTP/2の基礎となりました。

HTTP/2は、プロトコルの最初のバージョンを次のように悩ませる遅延問題を解決するように設計されています。

httpヘッダーを圧縮

サーバープッシュを実装
• 単一の接続でのマルチプレックスリクエスト
• また、正面遮断の問題を解決するように設計されています。それがバイナリ形式で送信するデータは、効率を改善し、デフォルトで暗号化を必要とします（または、少なくとも、これは主流のブラウザーによって課される要件です）。

ヘッド圧縮は、HPACKアルゴリズムを使用して実行されます。HPACKアルゴリズムは、SPDYの脆弱性を解決し、Webリクエストのサイズを半分に削減します。

サーバープッシュは、無駄な待機時間を解決するために設計された機能の1つであり、ブラウザリクエストの前にブラウザのサーバーにリソースを提供します。これにより、往復時間が短縮されます。これは、ウェブサイトの最適化における主要なボトルネックです。

これらのすべての改善により、http/2によってもたらされる負荷の時間差は、imagekit.ioの例で見ることができます。

積み込み時間を節約すればするほど、ウェブサイトのリソースが明らかになります。

Webサイトがhttp/2を介してリソースを提供するかどうかを確認する方法 FirefoxやChromeなどの主流のブラウザでは、「ネットワーク」タブを開き、リソースリストの上のストライプを右クリックすることにより、InspectorツールのHTTP/2プロトコルに対するWebサイトのサポートを確認できます。ここでは、「プロトコル」アイテムを有効にできます。

サーバーサイドの実装：

この記事の執筆時点では、すべての主流のブラウザはHTTP/2をサポートしていますが、すべてのHTTP/2要求が必要であり、HTTP/2仕様自体は暗号化を必要としません。

サーバー

Apache 2.4は、mod_http2モジュールを通じてそれをサポートしています。 Apacheは、-enable-http2パラメーターを./configureコマンドに追加することにより、構築する必要があります。また、libnghttp2ライブラリの少なくともバージョン1.2.1がインストールされていることを確認する必要があります。システムがそれを見つけるのに苦労している場合、-nghttp2 =を追加することにより、./configureへのパスを提供できます。

次のステップは、Apacheの構成にディレクティブを追加してモジュールをロードすることです。

<code>LoadModule http2_module modules/mod_http2.so</code>

次に、仮想ホストブロックにプロトコルH2 H2C HTTP/1.1を追加し、サーバーをリロードします。 Apacheの文書は、HTTP/2を有効にする際の注意事項について警告しています。

ApacheサーバーでHTTP/2を有効にすると、リソースの消費が影響します。ビジーサイトがある場合は、その影響を慎重に検討したい場合があります。

HTTP/2が有効になっている場合、最初に注意するのは、サーバープロセスが追加のスレッドを開始することです。その理由は、HTTP/2ハンドはすべて、処理のために独自の労働者スレッドに受け取る要求、結果を収集し、クライアントにストリーミングするためです。

Apache Configurationの詳細については、こちらをご覧ください。

nginxは、バージョン1.9.5以来HTTP/2をサポートしています。仮想ホスト仕様に

http2パラメーターを追加するだけで有効にすることができます。

その後、nginxをリロードします。

<code>server {
    listen 443 ssl http2 default_server;

    ssl_certificate    server.crt;
    ssl_certificate_key server.key;</code>

残念ながら、この執筆時点では、サーバープッシュは公式に実装されていませんが、開発ロードマップに追加されており、来年リリースされる予定です。より冒険的な人々のために、HTTP/2サーバーのプッシュのサポートを追加する非公式のNginxモジュールがあります。

litespeedとopenlitespeedは、HTTP/2のサポートも誇っています。

サーバー側でHTTP/2をアクティブにする前のメモは、SSLサポートがあることを確認することです。これは、上記のすべての仮想ホストコードスニペット（Apacheとnginxについて）が、仮想ホストブロックのSSLバージョンを入力してポート443を聴く必要があることを意味します。 ApacheまたはNginxをインストールし、通常の仮想ホストを構成した後、LetsEncrypt SSL証明書を取得し、主要なLinuxディストリビューションにインストールすることは、わずか数行のコードの問題でなければなりません。 CERTBOTは、プロセス全体を自動化するコマンドラインツールです。

概要：

この記事では、新たな第2世代のWebプロトコル仕様であるHTTP/2の概要を簡単に説明します。

新世代のHTTPの実装の完全なリストは、こちらをご覧ください。

テクノロジーについてあまり知らない人にとって、この新しいプロトコルへの移行のショートカットは、CDNがHTTP/2を採用した最初のベンダーの1つであるため、単にWebスタックにCDNを実装することである可能性があります。

http/2 FAQ：

（FAQパーツは、以前の出力と高度に複製されているため、ここでは省略されています）

以上がHTTP/2：背景、パフォーマンスの利点、実装の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。