もしかしてPageSpeed Insightsの成績が上がるかな～ということも期待してHTTP/2に完全対応してみました。実はこのサイト、とある理由のためにブラウザによってはHTTP/2で通信されないことがあったですよね。
CentOS6系でnginxをパッケージインストールするとHTTP/2を使わないブラウザもある
何を隠そうGoogleChromeがそれです。というのも、GoogleChromeがHTTP/2を使って通信をするための条件としてALPNに対応している必要があるのですが、このALPNはOpenSSL1.0.2系以上が必要で、CentOS6系のパッケージではOpenSSL1.0.1系が使われる関係で対応していない状態となってしまいHTTP/2による通信ができない、という結論が得られます。ちなみに先にテストでチェックしておけばよかったのですが気がついたときには更新が完了して新しいnginxで動き始めていたのでもうどうしようもありません。もしチェックし直すのであればわざと古いバージョンに戻した上で、とやる必要があるのでまだ更新していない人は自分の環境をチェックしてみるといいと思います。
nginxを最新版にしてALPNに対応しているOpenSSLを連結することで使えるようにする
今回の作業はこれになります。それほど難しい方法ではないと思いますので簡略にやり方を書いていきます。
OpenSSL1.0.2系をインストールする
まずはOpenSSLとして1.0.2系以上をインストールします。今回は素直にOpenSSL1.0.2jをインストールしてみます。OpenSSL1.1.0系でもいいような気はしますが、実は前からこれに備えてバージョンを上げていたのでこちらにしたことにさせてください…。
OpenSSLはconfigureの処理として専用のスクリプトがあるのでそちらを使って設定します。あまりコンパイルオプションはほとんどないので元々インストールされているopenssl 対してコンパイルオプションを照会して同じように設定すればよいと思います。今回は/usr/local/src以下にopenssl1.0.2jで展開したとして書いてみます。照会を行った後でopenssldirをそろえるようにconfigを設定してコンパイルします。
# openssl version -a # ./config shared zlib --openssldir=/etc/pki/tls # make # make install
もしかするといくつかライブラリが不足しているかもしれません(zlib-develとかperlとか)のでその場合はyumでインストールしてください。ちなみにこの作業で書き換えた場合はパッケージ側のバージョンは元のままですので後でCentOSの標準パッケージが更新されたときにそのまま更新してしまうと上の更新情報が上書きされてしまいますので覚えておく必要があります。
最新版のnginxをインストールする
そして最新版のnginxをインストールします。コードを/usr/local/srcにダウンロードした後は展開してコンパイルとインストールを行えばOKです。以前にnginxをパッケージ経由でインストールした場合はnginxのコンパイルオプションを引き継ぐように設定して最後にopensslのソースコードディレクトリを指定することでCentOS側が標準で持っているライブラリではなく先ほど上の作業でコンパイルできたOpenSSLを使うことができます。この記事を書いている段階ではnginxの最新は1.11.7なのでそれをダウンロード、オプション照会、コンパイルの手順をそれぞれ書くと
# wget "https://nginx.org/download/nginx-1.11.7.tar.gz" # tar -xzf nginx-1.11.7.tar.gz # cd nginx-1.11.7 # nginx -V # ./configure --prefix=/etc/nginx … --with-openssl=../openssl-1.0.2j/ # make # make install
nginxのコンパイルオプションは省略していますが実際にはかなりずらずらと書かれています。今回はそれをすべてコピーしてコンパイルしました。環境によってはpcre-develが必要だったりしますのでその場合はyumで入れておきましょう。またこちらもnginxのパッケージが更新されると上書きされてしまうので要注意です。あとはnginxの再起動を行えばOKです。
フロントエンド側がHTTP/2に対応することで効果を発揮できるのか？
今回の更新でChromeでもHTTP/2でアクセスを行っていることは確認できましたし、バージョンも最新になったのでセキュリティ的にも少しよくなったかな、と考えています。ただnginx単体の環境であればこれで十分な力を発揮できるのですが今回nginxはフロントエンドでありバックエンドとしてApacheが動作しているので意味があるのか微妙に疑問だったりします。キャッシュにヒットした状態が続けば十分に意味はありそうですがキャッシュを用いないページでは結局バックエンド側にアクセスがかかるのであまり改善にならない、という可能性が大きいような気もします。比較実験が必要かもしれませんね。
ちなみに期待していたPageSpeed Insightsに結果が反映されたのか？については…ご想像にお任せします。まあ上に書いてあることでどうなったのかわかると思いますが…。
