CodeZine(コードジン)

特集ページ一覧

「HTTP/2」がついに登場! 開発者が知っておきたい通信の仕組み・新機能・導入方法

Webアプリ開発技術の新潮流スタディーズ 第3回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

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サーバも高速化の恩恵を受けることができます。

リバースプロキシのみHTTP/2に対応する
リバースプロキシのみHTTP/2に対応する

 

 また、一部のプロキシ実装(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]

HTTP/2 and SPDY indicatorによるHTTP/2接続の確認
HTTP/2 and SPDY indicatorによるHTTP/2接続の確認

 

 Google Chromeの場合、chrome://net-internals/#spdyにアクセスすると[7]、現在のSPDYセッションの一覧が表示されます。「Protocol Negotiated」に「h2」という表示があれば、HTTP/2でアクセスできていることが分かります。

chrome://net-internals/#spdy

 

[6] SPDYは緑で表示されます。執筆時点で、GoogleやTwitterではHTTP/2、FacebookはSPDY/3.1に対応しています。

[7] プラグインの稲妻をクリックすることでも可。

 

効果的な利用方法を考える

 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がどのようなものなのか、少しでもイメージできるようになりましたら幸いです。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:Webアプリケーション開発技術の新潮流スタディーズ

著者プロフィール

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5