概要
若者の間でも、SPDYに対応するためのノウハウが共有されていないことは有名である。
そこで、中規模サイトでSSL化、SPDY対応という観点で個人的に考えていることを書き出してみる。
HTTP2は暗号化の議論や、アップグレード、ヘッダ圧縮など細部が違うため別途考慮する必要があるが、今回の話も概ね適応できるだろう。
今回主に考える構成としては、以下の様に前段にリバースプロキシを置く構成である。
幾つかSPDY対応しているソフトウェアがあるが、現状NGINXが無難だと考えているので、NGINX前提で話を進める。
（SPDY対応のロードバランサ製品の導入も出来るだろうが、今回は考慮しない）
SSL化とSPDY対応
SDPYではSSL化が必須である。これは、SSLハンドシェイク時にHTTPSとSPDYのどちらで通信を行うかネゴシエーションしているためである（TLS上でのプロトコルネゴシエーションの仕組み、NPNとALPN）。
そこで、SSL化対応とSPDY対応ということで、ざっくり以下について書き出してみる
- リバースプロキシの対応
- Webアプリケーションの対応
- ドメイン整理
- 中間装置の確認
- 測定
リバースプロキシの対応
- サーバにSPDY moduleを有効にしたNGINXをインストールする必要がある（デフォルトでは有効でないので自分でビルドする必要がある）
- SSL証明書をセットし、リバースプロキシとしての設定を行う。バックエンドにアクセスする際は暗号をほどいてHTTPでアクセスするので、それを示すヘッダを付加するようにする。（また、バックエンドにアクセスした際、バックエンドサーバのログにSPDYをほどいてHTTPでアクセスしたことが分かるようにヘッダを付加したいところである。）
- もしNGINXを操作するツールなど使用していれば動作確認をする
SSL化に伴い少なからずCPU負荷は上昇するが大きくはなさそうである。
ただ、接続開始時のSSLハンドシェイクは数往復の通信が必要になる。「SSL False Start」や「abbreviatedハンドシェイク」を使用することを検討したい。
（また、アクティブスタンバイ構成では、切り替わった直後に再接続を試みた全てのクライアントとのFullハンドシェイクが発生するので気をつけたい）
Webアプリケーションの対応
ドメイン整理
SPDYの接続単位(コネクション)はドメイン毎になる。
もしくは、ワイルドカード証明書を用いることで別ドメインでも(IPが同一であれば)使用することが出来る。そのため、ドメインを整理し対応範囲を決め、できる限り接続を再利用出きる様にする。
中間装置(NAT, FireWall, L4 LoadBalancer)対応
中間装置がある場合、SPDYになるとlong-livedな接続になるためNATなどのタイムアウト設定に引っかかる可能性が出てくる。
また、L4のロードバランサのアルゴリズムによっては負荷が均一に分散されない可能性がある。
そういった設定を見直す必要がある。
また無いとは思うが、HTTPS通信だと判断し特殊な処理をするものがある場合は対応を考える必要がある。
測定
測定ツールはいくつかある
- Benchmarking Extension：Chromeのエクステンションで、実際の通信で測定できる
- Spdycat ：CUIで使えるSPDYクライアント。-aオプションで、そのページに有るリソースもダウンロードするので便利。
tcコマンドなどで、帯域・欠損率などを複数試してみたい
その他考える事
パラメータに関すること
NGINXに実装されてないものも有り、SPDY通信の細かいパラメータのチューニングの議論を出来る段階にはなっていないが
- サーバプッシュや、中間装置でのキャッシュについて
- プライオリティへの対応
- メモリなどの割き方
- 並列数
- etc...
また、各カーネルレベルのチューニングについてもHTTPとは異なる事が想定できる
- long-lived接続へのパラメータチューニング
その他解決したいこと、確認したいこと
- ログの出力方法：SPDY通信のログ出力、成形方法を解決する必要がある。現状だと、NGINXのログはフレームタイプが表示される程度のログだったかと思う。
- 古いブラウザ：初期の頃にSPDY対応したブラウザが問題なく通信できることを確認したい。(Chrome10やFirefox11)
- 負荷テスト：負荷をかけるとどういう挙動になるか、どういうエラーが出うるのか確認したい。
最後に
未確認事項も多々あるので、是非色々な議論の種になりますように...
