HTTP/2の導入方法
それでは次に、HTTP/2を導入する場合に開発者は何をすればよいのかを、具体的に説明しましょう。
ブラウザの対応状況
HTTP/2を使うには、サーバとクライアント（ブラウザ）がHTTP/2に対応している必要があります。まずはブラウザを見ていきましょう。
執筆時点での各ブラウザの対応状況は次のようになっています。
| ブラウザ | 対応状況 | 備考 |
|---|---|---|
| Chrome | 最新版（Chrome 42）で対応済み | TLS必須 |
| Firefox | 最新版（Firefox 38）で対応済み | TLS必須 |
|
Internet Explorer |
Windows 10上のInternet Explorer 11で対応 | 現時点でTLS必須 |
| Safari | iOS 9から対応 | 詳細不明 |
ここで重要なことは、ChromeとFirefoxはTLS上でのHTTP/2のみをサポートする[3]と宣言していることです。つまり、仕様上HTTP（平文）でのHTTP/2は可能ですが、実質的にはサーバのTLS対応が必須です。
[3] これは、Webのセキュア化を促進する取り組みの一貫であるようです。HTTP/2に限らず、ServiceWorkerなどの新しい機能は、HTTPSプロトコルでなければ使用できなくなっています。最近では、Mozilla.orgが「Deprecating Non-Secure HTTP」というブログ記事を公開し、話題になりました。
既存のWebサーバをHTTP/2対応させる
既存のWebサイト（Webアプリケーション）をHTTP/2に対応させるには、サーバもHTTP/2を喋るものを使う必要があります。朗報としては、配信するコンテンツ自体には一切変更を加える必要がありません。静的コンテンツはもちろん、動的コンテンツのために提供されるAPIも従来のHTTP/1.1以下と同じものが提供されるのが普通ですので、特にロジックを変更する必要がありません。
特に有名なサーバの対応状況は次のようになっています。
| サーバ | 対応状況 |
|---|---|
| Nginx | 2015年末までに対応予定（ブログ記事） |
| httpd | 対応済み（mod_h2） |
| Jetty | Jetty 9にて対応済み |
| Tomcat | Tomcat 9にて対応予定。時期未定。（pdf） |
| Wireshark | 対応済み（Wiki） |
その他のサーバはこちらにリストアップされています。
WebサーバをHTTP/2対応させるときに具体的に必要な作業は、次のようになるでしょう。
- HTTP/2に対応済のサーバ（前述）に乗り換える、またはバージョンアップする[4]
- 適切なサーバ証明書を用意する[5]
- 必要に応じて追加の設定をする（最大同時ストリーム数やウインドウサイズなど）
- 必要に応じてサーバプッシュ等のロジックを追加する
[4] 蛇足かもしれませんが、まともなサーバであればHTTP/1.1以下の実装も持ち合わせているため、HTTP/2に対応しないブラウザとはHTTP/1.1以下で通信を開始します。
[5] HTTP/2ではTLS1.2以上を使用し、暗号スイートはTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256が必須であることにも注意が必要です。その他いくつかの制限がありますので、詳しくはRFCを参照してください。
HTTP/1.1サーバへの対応方法
場合によっては、既存のアプリケーションサーバをHTTP/2に移行することが困難なケースがあるかもしれません。そのようなときには、次の図のように、リバースプロキシのみHTTP/2に対応する方法があります。こうすることで、すべてのアプリケーションサーバに手を入れることなく、バックエンドのHTTP/1.1サーバも高速化の恩恵を受けることができます。
また、一部のプロキシ実装（nghttpxなど）には、バックエンドのサーバがHTTP/1.1であってもサーバプッシュを実現する機能があります。
例えば、index.htmlに付随してstyle.cssをプッシュしたい場合、レスポンスヘッダに、
Link: </style.css>; rel=preload
と記述してリバースプロキシに渡すと、style.cssを代わりにプッシュしてくれます。
ブラウザでHTTP/2通信を確認する
WebサイトがHTTP/2に対応しているかを簡単に確認するには、「HTTP/2 and SPDY indicator」プラグイン（Chrome版 Firefox版）が便利です。
試しにGoogleにアクセスしてみましょう。図のように、HTTP/2に対応していれば青い稲妻マークが表示されます[6]。
Google Chromeの場合、chrome://net-internals/#spdyにアクセスすると[7]、現在のSPDYセッションの一覧が表示されます。「Protocol Negotiated」に「h2」という表示があれば、HTTP/2でアクセスできていることが分かります。
効果的な利用方法を考える
HTTP/2を導入するメリットは何といっても通信速度の向上です。特に1ページ中に大量の画像など多くのリソースを必要とするサイトは、多重化の恩恵を存分に受けることができます。例えば、Akamaiのデモページでは、HTTP/2に対応したブラウザ（後述）で実際に閲覧して試すことができます[8]。
しかし、導入すれば必ず速くなると確約できるわけでもありません。まず、元々リソースの少ないサイトでは上記の多重化によるメリットは得られません。さらに、メジャーなブラウザが平文TCP上のHTTP/2接続をサポートしないため、元々HTTPSでないサイトはTLS接続を開始するコストが上乗せされてしまいます。
HTTP/2では優先度やサーバプッシュなど複雑な仕様が加わっているため、ブラウザやサーバがこれらの機能を十分にサポートしているかも見るべきポイントです。具体的には、執筆時点でChromeは優先度制御のうち依存関係の指定に対応していませんし、ブラウザによって重み付けのパラメータも異なるようです。さらに、サーバ実装の中にはそもそもこれらの機能が省略されているものもあり、対応予定があるのかも確認する必要があります。
[8] ちなみに筆者の手元の環境（Windows 64bit、Chrome 32bit）では、HTTP/1.1が1.34秒、HTTP/2が0.64秒と、倍以上のスピードで画像が読み込まれました。
HTTP/2の今後
ここまで、HTTP/2のメリットや仕組みを説明してきましたが、すべての問題が解決したわけではありません。
多重化によってリクエスト単位のHoLブロッキングは解決しましたが、同じようなことはTCPでも起こっています。先頭のパケットの送信に失敗した際に、後続のパケットが再送信されるまでブロックされるのです。このままではTCP接続を1本にしたことが、かえってアダになってしまいます。
そこで、Googleが新たに仕様策定中の「QUIC」では、UDP上で各パケットを並行して送ることで、この問題を解決します。このQUICもIETFを通じた標準化を目指しており、目が離せません。
もちろんですが、HTTP/2は新しいプロトコルなので、十分な実績やノウハウがあるわけではありません。今後、HTTP/1.1時代のパフォーマンスチューニングを完全になくせるのか、あるいは一部が生き残るのかについて、これから検証が進むでしょう。
以上、HTTP/2の主要な仕様や周辺事情を説明してきました。本稿を通じて、HTTP/2がどのようなものなのか、少しでもイメージできるようになりましたら幸いです。
