HTTP/2 のパフォーマンスを高速化する 7 つのヒント
HTTP/2 の詳細については、弊社の人気ウェビナー「HTTP/2 の新機能」の録画をご覧ください。
由緒あるハイパーテキスト転送プロトコル ( HTTP ) 標準が更新されました。 HTTP/2 標準は 2015 年 5 月に承認され、現在はブラウザーや Web サーバー ( NGINX PlusやNGINX Open Sourceを含む) に実装されています。 HTTP/2 は現在、使用されているすべての Web ブラウザーの約3 分の 2 でサポートされており、その割合は毎月数パーセントずつ増加しています。
HTTP/2 は Google の SPDY プロトコルに基づいて構築されており、Google Chrome ブラウザでのサポートが2016 年初頭に終了するまで、SPDY は引き続きオプションとして使用できます。 NGINX は SPDY の先駆的なサポート者であり、現在は HTTP/2 でも同じ役割を果たしています。 弊社の包括的なホワイト ペーパー「Web アプリケーション開発者向け HTTP/2 (PDF)」では、HTTP/2 について説明し、SPDY を基盤として HTTP/2 を構築する方法を示し、実装方法について説明しています。
HTTP/2 の主な機能は SPDY と同じです。
- HTTP/2はテキストではなくバイナリプロトコルなので、よりコンパクトで効率的です。
- 複数の接続でそれぞれ1つのファイルを運ぶのではなく、ドメインごとに1つの多重接続を使用します。
- ヘッダーは、専用の HPACK プロトコルで圧縮されます (SPDY の gzip ではなく)
- HTTP/2 には、ブラウザが最も必要なファイルを最初にリクエストできるようにするための複雑な優先順位付けスキームがあり、これは NGINX で完全にサポートされています (SPDY ではより単純なスキームでした)。
ここで、HTTP/2 を導入するかどうかを決定する必要があります。そのためには、HTTP/2 を最大限に活用する方法を知る必要があります。 このブログ投稿では、意思決定と実装プロセスのパフォーマンス関連の側面について説明します。 HTTP/2 パフォーマンスに関する次の 7 つのヒントを確認してください。
- 今すぐ HTTP/2 が必要かどうか判断する
- HTTP/2とTLSを終了する
- SPDYから始めることを検討してください
- コード内の HTTP/1.x 最適化を特定する
- HTTP/2またはSPDYを実装する
- HTTP/1.x の最適化の見直し
- スマートシャーディングを実装する
注記： 厳密に言えば、SPDY も HTTP/2 も TLS を必要としませんが、どちらも SSL/TLS と併用すると主にメリットがあり、ブラウザは SSL/TLS が使用されている場合にのみ SPDY または HTTP/2 をサポートします。
ヒント 1 – 今すぐ HTTP/2 が必要かどうかを判断する
HTTP/2 の実装は簡単です。ホワイト ペーパー「Web アプリケーション開発者向け HTTP/2 (PDF)」で説明しています。 ただし、HTTP/2 は万能薬ではありません。一部の Web アプリケーションには役立ちますが、他のアプリケーションにはそれほど役立ちません。
SSL/TLS (以下、TLS) を使用している場合、HTTP/2 を使用すると Web サイトのパフォーマンスが向上する可能性が高くなります。 ただし、まだ追加していない場合は、HTTP/2 を使用する前に TLS サポートを追加する必要があります。 その場合、TLS の使用によるパフォーマンスの低下は、HTTP/2 の使用によるパフォーマンス上の利点によってほぼ相殺されると予想されますが、実装を決定する前に、これが実際にサイトに当てはまるかどうかをテストしてください。
HTTP/2 の 5 つの主な潜在的な利点は次のとおりです。
- サーバーごとに 1 つの接続を使用します- HTTP/2 では、ファイル要求ごとに 1 つの接続ではなく、サーバーごとに 1 つの接続が使用されます。 つまり、時間のかかる接続設定の必要性が大幅に減ります。これは、TLS 接続の作成に特に時間がかかる TLS の場合に特に有益です。
- より高速な TLS パフォーマンスを実現- HTTP/2 では高価な TLS ハンドシェイクが 1 回だけ必要となり、多重化により単一の接続を最大限に活用できます。 HTTP/2 はヘッダー データも圧縮し、ファイルの連結などの HTTP/1.x パフォーマンス最適化を回避することで、キャッシュがより効率的に機能します。
- Web アプリケーションを簡素化– HTTP/2 を使用すると、アプリ開発者とクライアント デバイスの負荷を高める HTTP/1.x の「最適化」から脱却できます。
- 混合 Web ページに最適– HTTP/2 は、HTML、CSS、JavaScript コード、画像、および制限されたマルチメディアが混在する従来の Web ページに最適です。 ブラウザはファイル要求に優先順位を付けて、ページの重要な部分を最初に素早く表示することができます。
- より強力なセキュリティをサポート– TLS によるパフォーマンスへの影響を軽減することで、HTTP/2 はより多くの Web アプリケーションで使用できるようになり、ユーザーに強力なセキュリティを提供します。
次に、遭遇する可能性のある 5 つの欠点を示します。
- 単一接続のオーバーヘッドが大きくなる– HPACK データ圧縮アルゴリズムは両端でルックアップ テーブルを更新します。 これにより、接続はステートフルになり、単一の接続に追加のメモリが必要になります。
- 暗号化が必要ない場合があります– データの保護が必要ない場合、またはデータがすでに DRM やその他のエンコードによって保護されている場合、TLS セキュリティはあまり役に立ちません。
- HTTP/1.x の最適化は悪影響を及ぼします– HTTP/1.x の最適化は実際には HTTP/2 をサポートするブラウザーのパフォーマンスを低下させます。また、最適化を解除するには余分な作業が必要です。
- 大きなダウンロードにはメリットがありません– Web アプリケーションが主に大きなダウンロード可能なファイルやメディア ストリームを配信する場合は、TLS はおそらく必要ありません。また、1 つのストリームのみが使用されている場合は、多重化によるメリットはありません。
- 顧客は気にしないかもしれません– 顧客がサイトで共有する猫の動画が TLS と HTTP/2 で保護されているかどうかを気にしないと思っているかもしれません。そして、その考えは正しいかもしれません。
すべてはパフォーマンスにかかっています。そして、その点では良いニュースと悪いニュースがあります。
良いニュースとしては、NGINX で実行した最初の内部テストで、理論が予測した結果が示されたことです。つまり、一般的なインターネット遅延の接続を介して要求された混合コンテンツの Web ページの場合、HTTP/2 は HTTP/1.x や HTTPS よりも優れたパフォーマンスを発揮します。 結果は、接続の典型的な往復時間 (RTT) に応じて 3 つのグループに分類されます。
- 非常に低い RTT (0～20 ミリ秒) – HTTP/1.x、HTTP/2、HTTPS の間には実質的に違いはありません。
- 一般的なインターネット RTT (30～250 ミリ秒) – HTTP/2 は HTTP/1.x よりも高速であり、どちらも HTTPS よりも高速です。 米国の都市同士が近い場合、RTT は約 30 ミリ秒で、東海岸から西海岸 (約 3,000 マイル) までは約 70 ミリ秒です。 東京とロンドン間の最短ルートでは、RTT は約 240 ミリ秒です。
- 高い RTT (300 ミリ秒以上) – HTTP/1.x は HTTP/2 よりも高速で、HTTP/2 は HTTPS よりも高速です。
この図は、最初の描画までの時間、つまり、ユーザーが Web ページのコンテンツが画面に表示されるのを初めて見るまでの時間を示しています。 この測定は、Web サイトの応答性に対するユーザーの認識にとって重要であるとよく考えられています。
テストの詳細については、nginx.conf 2015 での私のプレゼンテーション「NGINX の HTTP/2 モジュール」をご覧ください。
ただし、Web ページはそれぞれ異なり、ユーザー セッションもそれぞれ異なります。 ストリーミング メディアや大きなダウンロード可能なファイルがある場合、または HTTP/1.x の最適化を科学的に（つまり、砂糖を）取り除いた場合（ The Martianに謝罪します）、結果は異なるか、反対になる可能性があります。
結局のところ、コストと利益のトレードオフが不明確であると感じるかもしれません。 もしそうなら、できる限り多くのことを学び、自分のコンテンツのパフォーマンステストを行ってから、電話をかけてください。 (ガイダンスについては、弊社のウェビナー「HTTP/2 の新機能」をご覧ください。)
ヒント 2 – HTTP/2 と TLS を終了する
プロトコルを終了するということは、クライアントが TLS や HTTP/2 などの目的のプロトコルを使用してプロキシ サーバーに接続することを意味します。 次に、図に示すように、プロキシ サーバーは必ずしも同じプロトコルを使用せずに、アプリケーション サーバー、データベース サーバーなどに接続します。
終了に別のサーバーを使用するということは、マルチサーバー アーキテクチャに移行することを意味します。 サーバーは、個別の物理サーバー、仮想サーバー、またはAWSなどのクラウド環境内の仮想サーバー インスタンスである場合があります。 これは、単一のサーバー、またはアプリケーション サーバーとデータベース サーバーの組み合わせと比較すると、複雑さが増します。 しかし、それは多くの利点をもたらし、事実上、忙しいサイトにとって必須のものです。
既存のセットアップの前にサーバーまたは仮想サーバーを配置すると、さまざまなことが可能になります。 新しいサーバーは、他のサーバーからクライアント通信のジョブをオフロードし、負荷分散、静的ファイル キャッシュなどの目的に使用できます。 必要に応じてアプリケーション サーバーやその他のサーバーの追加や置き換えが容易になります。
NGINX と NGINX Plus は、TLS と HTTP/2 の終了、負荷分散など、これらすべての目的でよく使用されます。 NGINX サーバーで「フロントエンド」化する以外、既存の環境をまったく変更する必要はありません。
ヒント 3 – SPDY から始めることを検討する
編集者 – このブログ投稿の公開以降、SPDY は主要ブラウザからのサポートが終了しました。 SPDY から始めることは、広範囲に展開するための選択肢ではなくなりました。
SPDY は HTTP/2 の前身のプロトコルであり、全体的なパフォーマンスはほぼ同じです。 SPDY は数年前から存在しているため、 HTTP/2 をサポートするWeb ブラウザーよりもSPDY をサポートするWeb ブラウザーが多くなっています。 ただし、この記事の執筆時点では、その差は縮まりつつあり、Web ブラウザーの約 3 分の 2 が HTTP/2 をサポートし、5 分の 4 が SPDY をサポートしています。
新しいスタイルの Web トランスポート プロトコルを急いで実装し、現在可能な限り多くのユーザーをサポートしたい場合は、まず SPDY を提供することから始めることができます。 その後、2016 年初頭に SPDY サポートが削除され始めると、HTTP/2 に切り替えることができます。少なくとも NGINX では、これは簡単な変更です。その時点では、HTTP/2 をサポートするブラウザーを使用するユーザーが増えるため、この移行期間中に最大数のユーザーにとって最善の対応を行ったことになります。
ヒント 4 – HTTP/1.x 最適化の使用状況を確認する
HTTP/2 を実装することを決定する前に、コード ベースが HTTP/1.x 用にどの程度最適化されているかを特定する必要があります。 注意すべき最適化には次の 4 つの種類があります。
- ドメイン シャーディング– Web ブラウザーへのファイル転送の並列処理を高めるために、すでにファイルを異なるドメインに配置している場合があります。コンテンツ ドメイン ネットワーク (CDN) はこれを自動的に実行します。 しかし、HTTP/2 ではパフォーマンスに役立たず、むしろ低下させる可能性があります。 HTTP/2 対応のドメイン シャーディング (ヒント 7を参照) を使用して、HTTP/1.x ユーザーのみをシャーディングできます。
- 画像スプライト– 画像スプライトは、1 つのファイルにダウンロードされる画像の集合体です。その後、別のコードで必要に応じて画像を取得します。 HTTP/2 では画像スプライトの利点は少なくなりますが、それでも役に立つ場合があります。
- コード ファイルの連結- イメージ スプライトと同様に、通常は個別のファイルとして維持および転送されるコード チャンクが 1 つに結合されます。 ブラウザは必要に応じて連結されたファイル内で必要なコードを見つけて実行します。
- インライン化ファイル- CSS コード、JavaScript コード、さらには画像も HTML ファイルに直接挿入されます。 つまり、最初のダウンロードで HTML ファイルが肥大化する代わりに、ファイル転送の回数が減ります。
最後の 3 種類の最適化はすべて、小さなファイルを大きなファイルに結合することで、新しい接続と初期化ハンドシェイクを削減します。これは、TLS にとって特にコストがかかります。
最初の最適化であるドメイン シャーディングは、その逆のことを行います。つまり、図に追加のドメインを含めることで、より多くの接続を強制的に開きます。 一見矛盾しているように見えるこれらのテクニックを組み合わせることで、HTTP/1.x サイトのパフォーマンスをかなり効果的に向上させることができます。 ただし、これらすべての設計、実装、管理、実行には時間、労力、リソースがかかります。
HTTP/2 を実装する前に、これらの最適化がどこに存在し、それが現在組織内のアプリケーション設計とワークフローにどのように影響しているかを特定し、HTTP/2 への移行後にそれらを変更または元に戻せるようにします。
ヒント 5 – HTTP/2 または SPDY を導入する
実際に HTTP/2 や SPDY を導入するのはそれほど難しくありません。 NGINX ユーザーの場合は、ホワイト ペーパー「Web アプリケーション開発者向け HTTP/2 (PDF)」で HTTP/2 について詳しく説明しているように、NGINX 構成でプロトコルを「オン」にするだけです。 次に、ブラウザとサーバーはプロトコルを選択するためにネゴシエートし、ブラウザも HTTP/2 をサポートしている場合 (および TLS が使用されている場合) は HTTP/2 が選択されます。
サーバー レベルで HTTP/2 を実装すると、HTTP/2 をサポートするブラウザー バージョンのユーザーは、Web アプリとのセッションを HTTP/2 で実行できるようになります。 古いバージョンのブラウザを使用しているユーザーの場合、図に示すように、セッションは HTTP/1.x で実行されます。 混雑したサイトに HTTP/2 または SPDY を実装する場合は、実装前と実装後のパフォーマンスを測定し、大きな悪影響がある場合は変更を元に戻すプロセスを用意する必要があります。
注記： HTTP/2 と単一接続の使用により、NGINX 構成のいくつかの詳細がより重要になります。 NGINX の設定を確認し、 output_buffers 、 proxy_buffers 、 ssl_buffer_sizeなどのディレクティブの設定の調整とテストに特に注意してください。 一般的な設定手順については、NGINX Plus 管理者ガイドの「NGINX SSL/TLS 終了」を参照してください。 より具体的なヒントについては、弊社のブログ「NGINX を使用した SSL オフロード、暗号化、証明書」および「HTTPS と NGINX を使用して SEO を改善する方法」をご覧ください。弊社のホワイト ペーパー「NGINX SSL パフォーマンス」では、サーバー キー サイズ、サーバー合意、バルク暗号の選択がパフォーマンスにどのように影響するかについて説明しています。
注記： HTTP/2 で使用する暗号の使用には特別な注意が必要になる場合があります。 HTTP/2 の RFC には回避すべき暗号スイートの長いリストがあり、暗号リストを自分で構成することをお勧めします。 NGINX および NGINX Plus では、 ssl_ciphersディレクティブを調整し、 ssl_prefer_server_ciphers を有効にして、一般的なブラウザ バージョンで構成をテストすることを検討してください。 Qualys SSL サーバー テストはSSL Web サーバーの構成を分析しますが、(2015 年 11 月現在) HTTP/2 ハンドシェイクについては信頼できません。
ヒント 6 – HTTP/1.x の最適化を修正する
驚くべきことに、HTTP/1.x の最適化を元に戻したり修正したりすることが、実は HTTP/2 実装の最もクリエイティブな部分です。 考慮すべき問題はいくつかあり、何をすべきかについては多くの自由度があります。
変更を開始する前に、古いブラウザのユーザーが変更によって不利益を受けるかどうかを検討してください。 これを念頭に置くと、HTTP/1.x の最適化を元に戻すか修正するための 3 つの戦略が広く考えられます。
- 皆さん、ここには何も見るべきものはありません。アプリケーションを HTTP/1.x 用に最適化していない場合、または維持しても問題ない程度の変更を加えた場合は、アプリで HTTP/2 をサポートするための作業は必要ありません。
- 混合アプローチ- ファイルとデータの連結を減らすことはできますが、完全に排除することはできません。 たとえば、小さな画像のまとまりのあるグループのための画像スプライトはそのまま残りますが、インライン データを含む最初の HTML ファイルの容量を増やす処理は削除される可能性があります。
- HTTP/1.x の最適化を完全に元に戻します(ただし、ヒント 7のドメイン シャーディングに関する注記を参照してください)。これらの最適化を完全に取り除く必要がある場合があります。
キャッシュはちょっとしたワイルドカードです。 理論的には、キャッシュは多数の小さなファイルがある場合に最適に動作します。 ただし、ファイル I/O が大量に発生します。 密接に関連するファイルを連結することは、ワークフローとアプリケーションのパフォーマンスの両方にとって意味がある場合があります。 HTTP/2 を実装する際には、自分の経験と他の開発者が共有する内容を慎重に検討してください。
ヒント7 – スマートシャーディングを実装する
ドメイン シャーディングは、おそらく最も極端で、最も成功した HTTP/1.x 最適化戦略です。 HTTP/1.x ではパフォーマンスが向上しますが、HTTP/2 では基本的に無視され、有益なドメイン シャーディングのバージョンを使用できます。 (単一の接続を使用するため、通常はドメイン シャーディングのメリットは得られません。)
HTTP/2 対応のシャーディングを行うには、次の 2 つのことを行います。
- シャードされたリソースのドメイン名が同じ IP アドレスに解決されるようにします。
- 証明書に、シャーディングに使用されるすべてのドメイン名に対して有効となるワイルドカードが含まれていること、または適切なマルチドメイン証明書があることを確認してください。
詳細については、 RFC 7540 、ハイパーテキスト転送プロトコル バージョン 2 (HTTP/2)を参照してください。
これらの条件が満たされている場合、HTTP/1.x ではシャーディングが発生します (ドメインが十分に異なるため、ブラウザーが追加の接続セットを作成するようにトリガーされます)。一方、HTTP/2 ではシャーディングは発生しません。個別のドメインが 1 つのドメインとして扱われ、1 つの接続でそれらすべてにアクセスできます。
結論
HTTP/2 と TLS により、サイトのパフォーマンスが向上し、サイトとのやり取りが安全であることをユーザーに知らせることができるようになります。 HTTP/2 を最初に実装する場合でも、競合他社に追いつく場合でも、HTTP/2 サポートを迅速かつ適切に追加できます。
これらのヒントを使用すると、最小限の継続的な労力で最高の HTTP/2 パフォーマンスを実現できるため、保守と実行が容易な高速で効果的かつ安全なアプリケーションの作成に集中できます。
リソース
- HTTP/2 の詳細については、NGINX のホワイト ペーパー ( PDF ) を参照してください。
- Can I use Web サイトには、 SPDYやHTTP/2を含む幅広いフロントエンド Web テクノロジーに対するブラウザー サポートが示されています。
- 2016 年 1 月現在、 6% を超える Web サイトがHTTP/2 を使用しています。
- テストの詳細については、nginx.conf 2015 のHTTP/2 プレゼンテーションを参照してください。
- NGINX には、主要な機能について説明し、実装に関するアドバイスを提供するウェビナー「HTTP/2 の新機能」があります。
- NGINX パフォーマンスのヒントの概要については、ブログ記事「アプリケーション パフォーマンスを 10 倍にする 10 のヒント」をご覧ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"