HTTP/2のパフォーマンスを高速化する7つのヒント

NGINX | 2015年10月26日

HTTP/2の詳細については、好評を博したウェビナーの録画をご覧ください。HTTP/2の新機能

長年にわたり利用されてきたHyperText Transfer Protocol、すなわちHTTPの標準が、このたび更新されました。HTTP/2標準は2015年5月に承認され、現在、ブラウザーやWebサーバー（NGINX PlusおよびNGINX Open Sourceを含む）への実装が進んでいます。現在、使用されている全Webブラウザーの約3分の2がHTTP/2をサポートしており、その割合は毎月数ポイントずつ増加しています。

HTTP/2はGoogleのSPDYプロトコルを基盤としており、Google ChromeブラウザでのSPDYサポートが終了する2016年初頭までは、SPDYも引き続き選択肢の1つです。NGINXはSPDYを先駆けてサポートしてきましたが、現在はHTTP/2でも同様の役割を果たしています。包括的なホワイトペーパー「Webアプリケーション開発者向けHTTP/2」（PDF）では、HTTP/2の概要、SPDYをどのように発展させたものか、実装方法について説明しています。

HTTP/2の主な機能はSPDYと同じです。

HTTP/2はテキストではなくバイナリ形式のプロトコルであるため、よりコンパクトで効率的です
ファイルごとに複数の接続を使用するのではなく、ドメインごとに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の最適化を見直す
Smart Shardingを実装

注：厳密には、SPDYもHTTP/2もTLSを必須としていませんが、どちらも主にSSL/TLSと併用することでメリットが得られます。また、ブラウザがSPDYまたはHTTP/2をサポートするのは、SSL/TLSを使用している場合に限られます。

ヒント1 – 今すぐHTTP/2が必要かどうかを判断する

ホワイトペーパー「Webアプリケーション開発者向けHTTP/2」（PDF）で説明しているように、HTTP/2は簡単に実装できます。ただし、HTTP/2は万能ではありません。効果が高いWebアプリケーションもあれば、そうでないものもあります。

SSL/TLS（以下、TLS）を使用している場合、HTTP/2を使用するとWebサイトのパフォーマンスが向上する可能性があります。一方、TLSを使用していない場合は、HTTP/2を使用する前にTLS対応を追加する必要があります。その場合、TLSの使用によるパフォーマンス低下は、HTTP/2の使用によるパフォーマンス向上でおおむね相殺されると考えられます。ただし、実装を決定する前に、実際にお使いのサイトでそうなるかをテストしてください。

HTTP/2には、主に次の5つのメリットが期待できます。

サーバーごとに単一の接続を使用 – HTTP/2では、ファイルリクエストごとに接続するのではなく、サーバーごとに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ページで特に効果を発揮します。ブラウザーはファイルリクエストに優先順位を付けることで、ページの主要部分を優先的かつ迅速に表示できます。
セキュリティの強化をサポート – HTTP/2は、TLSによるパフォーマンス低下を抑えることで、より多くのWebアプリケーションでTLSを利用できるようにし、ユーザーのセキュリティを強化します。

一方で、次の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 ms） – HTTP/1.x、HTTP/2、HTTPSの間に実質的な差はありません。
一般的なインターネットのRTT（30～250 ms） – HTTP/2はHTTP/1.xより高速で、どちらもHTTPSより高速です。米国内の近隣都市間ではRTTは約30 ms、東海岸から西海岸まで（約3,000マイル）では約70 msです。東京とロンドンを結ぶ最短経路では、RTTは約240 msです。
高いRTT（300 ms以上） – HTTP/1.xはHTTP/2より高速で、HTTP/2はHTTPSより高速です。

この図は、初回描画までの時間、つまりユーザーが画面上にWebページのコンテンツが表示されたことを初めて確認するまでの時間を示しています。この測定値は、Webサイトの応答性に対するユーザーの印象を左右する重要な指標とみなされることがよくあります。

テストの詳細については、nginx.conf 2015での私のプレゼンテーション「NGINXのHTTP/2モジュール」をご覧ください。

しかし、Webページはそれぞれ異なり、ユーザーセッションも一つひとつ異なります。ストリーミングメディアやサイズの大きいダウンロードファイルがある場合、あるいはHTTP/1.xの最適化を科学の力で、ええと、徹底的に突き詰めている場合（オデッセイには申し訳ありませんが）、結果が異なることや、正反対になることさえあります。

要するに、コストとメリットのトレードオフが明確でない場合もあります。その場合は、できる限り情報を収集し、ご自身のコンテンツでパフォーマンステストを実施したうえで判断してください。（詳しくは、F5のウェビナー「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は数年前から存在しているため、SPDYをサポートするWebブラウザの方が、HTTP/2をサポートするWebブラウザよりも多くなっています。ただし、執筆時点ではその差は縮まりつつあり、HTTP/2をサポートするWebブラウザは約3分の2、SPDYをサポートするWebブラウザは約5分の4です。

新しい方式のWeb転送プロトコルを早急に導入し、現時点でできるだけ多くのユーザーに対応したい場合は、まずSPDYを提供できます。その後、SPDYのサポートが廃止され始める2016年初頭に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を使用している場合は、NGINXの設定でプロトコルを「有効化」するだけです。HTTP/2については、ホワイトペーパー「Webアプリケーション開発者向けHTTP/2」（PDF）で詳しく説明しています。その後、ブラウザとサーバーが使用するプロトコルをネゴシエーションし、ブラウザもHTTP/2をサポートしていれば、HTTP/2が選択されます（TLSを使用している場合）。

サーバーレベルでHTTP/2を実装すると、HTTP/2をサポートするバージョンのブラウザーを使用しているユーザーは、WebアプリとのセッションがHTTP/2で実行されます。古いバージョンのブラウザーを使用しているユーザーのセッションは、図に示すようにHTTP/1.xで実行されます。アクセスの多いサイトにHTTP/2またはSPDYを実装する場合は、実装前後のパフォーマンスを測定し、重大な悪影響が生じた場合に変更を元に戻せるプロセスを整備しておくことを推奨します。

注：HTTP/2では単一の接続を使用するため、NGINX設定の一部の詳細がより重要になります。特に、output_buffers、proxy_buffers、ssl_buffer_sizeなどのディレクティブ設定の調整とテストに注意して、NGINX設定を確認してください。一般的な設定手順については、NGINX Plus管理者ガイドの「NGINX SSL/TLS Termination」を参照してください。より具体的なヒントについては、F5のブログ「SSL Offloading, Encryption, and Certificates with NGINX」および「How to Improve SEO with HTTPS and NGINX」をご覧ください。ホワイトペーパー「NGINX SSL Performance」では、サーバー鍵のサイズ、鍵共有方式、一括暗号方式の選択がパフォーマンスに与える影響について解説しています。

注：HTTP/2で使用する暗号には、特に注意が必要な場合があります。HTTP/2のRFCには、使用を避けるべき暗号スイートが多数記載されているため、暗号リストを独自に設定することもできます。NGINXおよびNGINX Plusでは、ssl_ciphersディレクティブの調整とssl_prefer_server_ciphersの有効化を検討し、一般的なブラウザの各バージョンで設定をテストしてください。Qualys SSL Server Testでは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では単一の接続を使用するため、通常、ドメインシャーディングによるメリットは得られません。）

HTTP/2に適したシャーディングを実現するには、次の2つを行います。