HTTP / 2を実装するための7つのヒント

最近、HTTP標準の新しいバージョンがリリースされました。 2015年5月、HTTP / 2が承認され、ブラウザとWebサーバー（NGINXおよびNGINX Plusを含む）に分散されました。 現在、 使用されているブラウザの60％以上が HTTP / 2をサポートしており、この数値は毎月増加し続けています。



HTTP / 2標準は、Googleが開発したSPDYプロトコルに基づいています。 Google Chromeでは、 2016年初頭まで SPDYサポートを利用できます。 NGINXは、SPDYプロトコルを実装した最初の企業の1つであり、現在HTTP / 2の推進において主導的な役割を果たしています。 SPDYと比較したHTTP / 2の詳細な説明を提供する記事が公開され、新しいプロトコルの実装プロセスが詳細に説明されました。



HTTP / 2の主な機能はSPDYに似ています：

• HTTP / 2はテキストプロトコルではなくバイナリであるため、よりコンパクトで効率的です。
• HTTP / 2では、単一のファイルを介して送信する複数の接続の代わりに、ホストへの1つの多重化接続のみが使用されます。
• HTTP / 2は、SPDYで使用されていたgzipの代わりに、特殊なHPACKプロトコルによるヘッダー圧縮を使用します。
• HTTP / 2は洗練された優先順位付けメカニズムを使用して、最初にブラウザーに最も必要なファイルを提供します（SPDYはより単純なアルゴリズムを使用しました）。

次に、新しいプロトコルの機能をさらに深く検討し、より詳細に検討する必要があります。 この記事は、HTTP / 2への切り替えを決定するのに役立つように書かれており、プロトコルを実装する際に可能な最適化についても考慮しています。



以下は、HTTP / 2を実装するための7つのヒントのリストです。

1. HTTP / 2を実装する必要性を評価する
2. HTTPの終了/ 2
3. SPDYを使い始める
4. HTTP / 1.x最適化の拒否
5. HTTP / 2またはSPDYをデプロイします
6. HTTP / 1.x最適化の改訂
7. フレンドリーなHTTP / 2シャーディングを表示

注：厳密に言えば、TLSはSPDYとHTTP / 2を使用する必要はありませんが、主な利点はSSL / TLSが有効になっていることです。したがって、ブラウザーはSSL / TLSが使用可能な場合にのみSPDYとHTTP / 2をサポートします。

HTTP / 2を実装する必要性を評価する

HTTP / 2の実装は簡単で、プロセスはここで詳細に説明されます 。 ただし、HTTP / 2は普遍的なソリューションではないことを理解する価値があります。一部のアプリケーションでは有用ですが、他のアプリケーションでは有用ではありません。



たとえば、高い確率で、HTTP / 2は既にSSL / TLSを使用しているサイト（以降、TLSの略語と呼びます）を高速化します。それ以外の場合は、HTTP / 2を有効にする前にTLSを有効にする必要があります。 TLSを使用すると、パフォーマンスが低下する可能性があることに注意してください。TLSを使用すると、HTTP / 2からの加速が無効になる場合があります。 したがって、最初にこのケースを確認する必要があります。



HTTP / 2を使用する5つの重要な潜在的な利点は次のとおりです。

1. 1つのファイルを送信する多くの接続の代わりに、サーバーへの1つの接続のみが使用されます。 つまり、接続数が削減されます。これは、TLSを使用する場合に特に便利です。
2. TLSの効果的な使用。 HTTP / 2は1つのTLSハンドシェイクのみを行い、多重化によりこの接続を効果的に使用できます。 HTTP / 2はヘッダーデータも圧縮し、HTTP / 1.xの最適化（ファイルの連結など）を排除することで、キャッシングアルゴリズムをより効率的に機能させることができます。
3. Webアプリケーションを簡素化します。 HTTP / 2を使用する場合、HTTP / 1.xの最適化を取り除くことができます。これにより、開発者の不便さもなくなります。
4. 複雑なWebページに最適です。 HTTP / 2は、HTML、CSS、JavaScript、写真、ビデオを同時に使用するWebページに最適です。 ブラウザは、ページの最も必要な部分が最初に送信されるように、ファイル要求に優先順位を付けることができます。
5. 接続セキュリティ。 HTTP / 2を使用すると、TLSを使用するためにパフォーマンスが低下する可能性がありますが、同時に、TLSはWebアプリケーションをユーザーにとってより安全にします。

発生する可能性のある5つの対応する欠点：

1. 1つの接続に高いコスト。 HPACKデータ圧縮アルゴリズムでは、両端で変換テーブルのサポートが必要です。 また、1つの接続により多くのメモリが必要です。
2. おそらく、TLSの使用は冗長です。 送信された情報を保護する必要がないか、DRM（またはその他の暗号化）を使用してすでに保護されている場合、TLSは有用ではありません。
3. 追加の作業であるHTTP / 2のパフォーマンスを向上させるには、既存のHTTP / 1.x最適化を見つけて削除する必要があります。
4. 大きなファイルをダウンロードする場合、利点はありません。 Webアプリケーションが主に大きなファイルまたはビデオストリーミングをダウンロードするように設計されている場合、TLSの使用は間違っている可能性が高く、多重化によるメリットはありません。
5. セキュリティは重要ではありません。 訪問者は、サイトで共有するシール付きのビデオが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ミリ秒で、一方の海岸からもう一方の海岸までは約70ミリ秒（約3,000マイル）です。 東京とロンドン間の最短ルートの1つで、RTTは約240ミリ秒です。
• 高いRTT（300ミリ秒以上）：HTTP / 1.xはHTTP / 2よりも高速で、HTTP / 2はHTTPSよりも高速です。

この図は、レンダリングの開始前の時間、つまり、ユーザーがWebページの最初のコンテンツを見る瞬間までの時間を示しています。 この時間は、ユーザーがWebサイトの応答性を認識するために重要であると見なされることがよくあります。



テストプロセスと結果の詳細については、nginx.conf 2015カンファレンスのプレゼンテーションをご覧ください。



ただし、すべてのWebページとユーザーセッションは互いに異なります。 たとえば、ビデオストリーミングまたは大量のダウンロードがある場合、結果は異なる場合があります。



肝心なのは、HTTP / 2を使用する場合、まず考えられるコストと最大のメリットを理解する必要があるということです。 その後、アプリケーションのパフォーマンスをテストしてから、選択する価値があります。

HTTPの終了/ 2

終了とは、クライアントが指定されたプロトコル（HTTP / 2など）を介してプロキシサーバーに接続でき、プロキシサーバーがサーバーアプリケーション、データベースなどに接続できることを意味します。 完全に異なるプロトコルを使用します（下の画像を参照）。





別々のサーバーを使用する場合、マルチサーバーアーキテクチャに切り替えることが可能になります。 サーバーを物理的、仮想的に共有することも、 AWSなどのクラウド環境を使用することもできます。 これは、単一サーバーソリューションまたはサーバー+データベースの組み合わせと比較してアーキテクチャを複雑にしますが、多くの利点を提供し、負荷の高いサイトには必要です。



物理サーバーまたは仮想サーバーを既存のシステムの前にインストールすると、追加機能が利用可能になります。 新しいサーバーは、クライアントメッセージの処理から他のサーバーをオフロードします。 さらに、ロードバランシング、静的ファイルキャッシング、およびその他の目的にも使用できます。 必要に応じて、サーバーアプリケーションや他のサーバーを追加および交換することがはるかに簡単になっています。



NGINXおよびNGINX Plusは、これらすべての目的（TLSおよびHTTP / 2終了、負荷分散など）によく使用されます。 既存の環境では、ユーザーがNGINXサーバーと対話する部分を除いて、変更は必要ありません。

SPDYを使い始める

SPDYはHTTP / 2の先駆けであり、そのパフォーマンスはHTTP / 2に匹敵します。 SPDYは数年前から存在しているため、比較的最近登場したHTTP / 2とは異なり、すべての一般的なブラウザーでサポートされてい ます 。 ただし、執筆時点では、ギャップは縮小しており、ブラウザの60％以上が既にHTTP / 2をサポートしていますが、SPDYは80％以上をサポートしています。



新しいトランスポートプロトコルを実装する緊急の必要性があり、ユーザー間で最大限のサポートを備えたプロトコルを使用する場合は、SPDYから開始する必要があります。 その後、2016年の初めに、SPDYサポートが削除されるときに、HTTP / 2に切り替えます。 この時点で、より多くのユーザーがHTTP / 2をサポートするブラウザーを使用するため、この移行はほとんどのユーザーの観点から最適な場合があります。

HTTP / 1.x最適化の拒否

HTTP / 2を実装する前に、HTTP / 1.xの最適化を識別する必要があります。 次の4種類の最適化を検討する価値があります。

1. シャーディング。 ブラウザへの並列転送のために、異なるドメインにファイルを配置します。 コンテンツ配信ネットワーク（CDN）はこれを自動的に行います。 このような最適化により、HTTP / 2のパフォーマンスが損なわれる可能性があります。 HTTP / 1.xユーザーに対してHTTP / 2フレンドリーシャーディングを使用できます（HTTP / 2フレンドリーシャーディングを参照）。
2. スプライトを使用します。 スプライトは、単一のファイルとして送信される画像のコレクションです。 その後、クライアント側で、必要に応じてコレクションから写真が取得されます。 HTTP / 2を使用する場合、この最適化はあまり効率的ではありませんが、依然として有用です。
3. ファイルのマージ。 スプライトのように、通常別々に保存されているファイルの一部は、1つにマージされます。 その後、ブラウザは必要に応じて接着されたファイル内でコードを見つけて実行します。
4. ファイルの埋め込み。 CSS、JavaScript、さらには画像もHTMLファイルに直接挿入されます。これにより、ソースHTMLファイルが増加するため、転送されるファイルの数が減少します。

小さなファイルを大きなファイルに結合し、新しい接続を減らし、追加の接続を初期化するための最後の3種類の最適化は、TLSを使用する場合に特に重要です。



最初の最適化であるシャーディングは異なる動作をします-追加のドメインを使用してより多くの接続を開くように強制します。 同時に、これらの一見矛盾する方法は、HTTP / 1.xサイトのパフォーマンスを改善するのに非常に効果的です。 ただし、彼らはすべて、作業の開発、実装、管理、および保守に時間、労力、およびリソースを費やしています。



HTTP / 2を実装する前に、これらの最適化を見つけ、それらが現在アプリケーションの設計とワークフローにどのように影響するかを調べる必要があります。 これは、HTTP / 2に移行した後にこれらの最適化を変更またはキャンセルできるようにするために実行する必要があります。

HTTP / 2またはSPDYをデプロイします

実際、HTTP / 2またはSPDYへの切り替えは非常に簡単です。 NGINXユーザーの場合、 ここで例としてHTTP / 2を使用して説明するように、NGINX構成でプロトコルを「有効にする」必要があります。 その後、サーバーはHTTP / 2またはSPDYを使用する可能性についてクライアントブラウザに通知します。



サーバーでHTTP / 2を有効にすると、ブラウザーがHTTP / 2をサポートするユーザーは、HTTP / 2を介してWebアプリケーションに接続して作業します。 ブラウザーの古いバージョンを使用しているユーザーは、HTTP / 1.xを使用する必要があります（下図を参照）。 負荷の高いサイトにHTTP / 2またはSPDYを実装する場合、パフォーマンスの前後を測定し、悪影響が生じた場合は変更をロールバックする必要があります。







注：HTTP / 2は単一の接続を使用するため、NGINXの一部の構成設定はより重要になります。 output_buffers、proxy_buffers、ssl_buffer_sizeなどのディレクティブのパラメーターの設定とテストに特に注意してNGINX構成を確認することをお勧めします。 一般的な設定に関する注意事項 、特定のTLSのヒント（ こことここ ）、およびTLSを使用する場合のNGINXのパフォーマンスに関する記事に注意する必要があります。



注：HTTP / 2で暗号を使用する場合、次のことに注意する必要があります。HTTP/ 2のRFCには、回避すべき暗号の長いリストがあります。 暗号のリストを自分で構成する場合、この場合、 ssl_ciphersを設定し、 ssl_prefer_server_ciphersを有効にすることを検討してから、ブラウザのすべての一般的なバージョンで適切な暗号をテストすることをお勧めします。 人気のあるQualysのSSLサーバーテストブラウザーのインジケーター（2015年11月現在） は、HTTP / 2ハンドシェイクのカウントには信頼性がないと考えられています 。

HTTP / 1.x最適化の改訂

これは驚くことではありませんが、HTTP / 1.xの最適化を削除または変更することは、HTTP / 2を実装する上で最も創造的な部分です。 考慮すべきいくつかの問題があります。



変更を行う前に、影響を受ける可能性のある古いブラウザのユーザーを考慮する必要があります。 これを念頭に置いて、HTTP / 1.xの最適化をキャンセルまたは修正するための3つの主な戦略があります。

• すべて準備完了です。 アプリケーションがHTTP / 1.x向けに最適化されていない場合、またはマイナーな変更が行われている場合、すべてがHTTP / 2を使用する準備ができています。
• 混合アプローチ。 データの連結を減らすことはできますが、完全に排除することはできません。 たとえば、HTMLに埋め込まれたデータを削除すると同時に、一部の画像スプライトが残る場合があります。
• HTTP / 1.x最適化の完全な拒否（ただし、フレンドリーなHTTP / 2シャーディングとメモを参照）。 最適化を完全に取り除くことができます。

キャッシングにはいくつかの機能があります。 理論的には、キャッシングは多くの小さなファイルに適用されると効果的に機能します。 ただし、この場合、多数のI / O操作が実行されます。 したがって、関連ファイルを結合すると、ワークフローとアプリケーションのパフォーマンスの両方に役立ちます。

フレンドリーなHTTP / 2シャーディングを表示

シャーディングはおそらく最も困難であると同時に、おそらく最も成功したHTTP / 1.x最適化戦略です。 シャーディングはHTTP / 1.xのパフォーマンスを改善するために使用できますが、HTTP / 2（1つの接続のみを使用する）の場合、ほとんど無視されます。



HTTP / 2と組み合わせたシャーディングを使用するには、次の2つのことを行う必要があります。

• シャーディングリソースのドメイン名を同じIPアドレスに解決します。
• ワイルドカード証明書が使用されていることを確認してください-この場合、シャーディングで使用されるすべてのドメイン名に対して有効です。 または、適切なマルチドメイン証明書があることを確認してください。

詳細な情報はこちらをご覧ください 。



これらの条件下では、HTTP / 1.xでシャーディングが発生します-ドメインが異なるため、ブラウザーは追加の接続セットを作成できます-個々のドメインは1つと見なされ、接続にアクセスできるため、HTTP / 2では発生しませんそれらのいずれかに。

おわりに

おそらく、TLSを使用したHTTP / 2は、サイトのパフォーマンスを向上させ、ユーザーが接続が安全であることを確認できるようにします。 さらに、HTTP / 2サポートの導入は、多くの場合、多くの労力を必要としません。



上記のヒントは、最小限の労力で最高のHTTP / 2パフォーマンスを達成するのに役立ち、残りの時間を高速で効率的で安全なアプリケーションの構築に充てることができます。