ナカヤン.jpをHTTP/2に対応させた

今のWebサイトを見ている仕様は、1999年に標準化されたHTTP/1.1だ。　そこから16年経った今年、新しいWebアクセスの仕様がHTTP/2として登場した。

HTTP/2とは何か？

大きな違いはテキストベースでのやりとりだった1.1と違い、バイナリベースでデータ送受信を行うようになったことだ。　その恩恵もあって、テキストベースでは制御できなかったような効率的なデータ送受信が可能になった。

つまり、Webの閲覧速度を速める効果が見込める、そう言うことだ。

もちろん万能ではないので、複数サイトに分散したデータの取り扱いだとか、SSL必須だとか、色々と課題も残っているそうなのだが、せっかくWebをSSL対応にしたのだから導入してみない手は無いじゃない！

HTTP/2が何かについては、Webに色々と記事が転がっているので読んでみて。

• 「HTTP/2」がついに登場！ 開発者が知っておきたい通信の仕組み・新機能・導入方法
• Nginx HTTP/2 protocol to succeed Google SPDY
• HTTP/2でも初めてみます？ from Kento Kawakami

まず、今のNginxにHTTP/2対応のモジュールは組み込まれているのか？を確認する。　ウチのNginxはyumでインストールしているけど、mainline（1.9.x）からインストールするように変更しているのでちゃんと–with-http_v2_moduleが入っているね。

$ nginx -V

nginx version: nginx/1.9.5
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments:
--prefix=/etc/nginx
--sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp
--user=nginx
--group=nginx
--with-http_ssl_module
--with-http_realip_module
--with-http_addition_module
--with-http_sub_module
--with-http_dav_module
--with-http_flv_module
--with-http_mp4_module
--with-http_gunzip_module
--with-http_gzip_static_module
--with-http_random_index_module
--with-http_secure_link_module
--with-http_stub_status_module
--with-http_auth_request_module
--with-threads
--with-stream
--with-stream_ssl_module
--with-mail
--with-mail_ssl_module
--with-file-aio
--with-ipv6
--with-http_v2_module
--with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'

ちなみに、標準の状態でインストールされるNginx（1.8.x）では、現時点ではこのモジュールは入っていないのであしからず。

サーバが対応していたとしても、HTTP/2を使うにはSSLが必須になっている。　本来のHTTP/2はSSL無しでも良いのだが、その開発経緯からSSLが必須になっている。　逆の言い方をすれば、既にSSL化してあるサイトであれば、下記設定を追加するだけで完了するというお手軽設定。

server {
listen 80;
listen 443 default_server ssl http2;
server_name nakayan.jp;

自分のサイトが本当にHTTP/2に対応したのかは、Web用の開発ツールを使えばすぐにわかるらしいけど、FirefoxかChromeであれば下記のアドオンをいれると良い。

HTTP/2 and SPDY indicator

• HTTP/2 and SPDY indicator :: Add-ons for Firefox
• HTTP/2 and SPDY indicator – Chrome ウェブストア – Google

このアドオンを入れると、HTTP/2でのアクセスではURLの右側に稲妻マークが表示される。　青色は完全HTTP/2、緑色がSPDY、灰色が一部対応を示し、マウスポインタを乗せると説明が表示される。

よし、ばっちり対応できているじゃないか。

たとえば、Facebookだと下記のようにSPDY3.1対応って表示されている。

設定は公式サイトのドキュメントによれば下記。　ところが、見るサイトによっては項目やら文言やら異なる記述もあって、本当に確かなのかはわからんちん。　設定してもエラーが出ないから、たぶんこれが正しいんだろうけども。

- http2_recv_buffer_size (http)
      specifies the size of input buffer per worker
      (256k by default).

- http2_max_concurrent_streams (http, server)
      sets the maximum number of concurrent HTTP/2 streams
      in a single connection (128 by default).

- http2_streams_index_size (http, server)
      configures the size of the HTTP/2 stream ID index;
      must be a power of 2 (default is 32).

- http2_recv_timeout (http, server)
      defines the timeout when expecting more data from
      the client (default is 30s).

- http2_idle_timeout (http, server)
      sets the inactivity timeout after which the connection
      is closed (default is 3m).

- http2_chunk_size (http, server, location)
      defines the default DATA frames size for response body
      (default is 8k).

- http2_max_field_size (http, server)
      limits the maximum size of a request header field
      (default is 4k).

- http2_max_header_size (http, server)
      limits the maximum size of headers in a request
      (default is 16k).

探してみたら、下記で詳しく説明してくれている。　ありがとうございます。

Nginx 1.9.4 HTTP/2 のconf パラメータ設定項目（あすのかぜ）

チューニングのためにはパフォーマンスの測定ツールが必要だ。　ブラウザのプラグインを探しても良かったけど、下記でHTMLを1枚置くだけのお手軽テストツールを配布してくれている。

ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話（Kazuho’s Weblog）

さっそく、このツールを使ってパフォーマンスを測定してみよう。

まず、トップページの描画時間を比較してみる。　何回かやってみて、おおむね出現率の高いあたりで比較してみるテスト。

HTTP/1.1の場合はこれ。

unload: 288 msec
head-parsed: 406 msec
DOMContentLoaded: 429 msec
load: 800 msec

HTTP/2だと少し変わるかな、どうかな？という状態だ。

unload: 295 msec
head-parsed: 393 msec
DOMContentLoaded: 438 msec
load: 778 msec

ぶっちゃけ、あんまり変わらない（笑

では、転送効率が上がるというHTTP/2向けのデータ量の多いページということで、画像の多いキャンプのページで試してみる。　まずはHTTP/1.1の場合。

unload: 454 msec
head-parsed: 1082 msec
DOMContentLoaded: 1161 msec
load: 1832 msec

このページでは大きな差が出た。

unload: 487 msec
head-parsed: 646 msec
DOMContentLoaded: 756 msec
load: 1343 msec

なんと3割近く改善されている。　もちろんその時々の負荷によって変動はするものの、何度も試したが出現率の高い値には大きな違いがあった。

これがHTTP/2の効果なのか。

もっと精密なテストをしないと結論めいたことは書けないけど、今度ゆっくりと時間をとって、パラメータを変えたりしながらその性能を試してみよう。

と言うことで、今日はここまで。

さて、プールにでも行ってくるか。