HTTP/2時代のドメインシャーディングを考える
うちのサイトは、記事やサイドバーなどに画像が多いということもあり、サイト高速化のためにドメインシャーディングという手法を使っていますが、今後、HTTP/2対応を考えたとき、これをどうしてゆけば良いのか、少し考えてみました。
ドメインシャーディングというのは、HTML や画像、JavaScript などを複数ドメインから配信する高速化手法です。HTTP/1.x では、ブラウザが1ドメインに同時に張れるセッション数が少ないため、コンテンツを複数ドメインに分散配置することでダウンロードの並列度を上げ、高速化しよう。というテクニックになります。というわけで、うちの場合、3ドメインから分割配信している状況です。
しかし、HTTP/2 になると、このあたりの事情が大きく変わります。というのは、HTTP/2 では、1つのTCPセッション内で複数リソースを並列ダウンロードできるようになるからです。
つまり、HTTP/2 でドメインシャーディングを行っても、TCP セッション数がむやみに増えるだけで、高速化の効果は得られない、という事になります。
では、HTTP/2 対応の時点でドメインシャーディングをやめてしまえば良いか、というとそういうワケではありません。HTTP/2 非対応ブラウザからの閲覧時の高速化、という観点からは、依然として必要性はあるわけです。
じゃあどうするか。ブラウザの種類によって、ドメインシャーディング済みのHTMLとそうでないものを出し分けるのか？という案も考えられるわけですが、サーバーサイドのページキャッシュが強力に効いているうちの場合、これはできればやりたくない。
という事で、色々と調べてみると、nginx の公式サイトが面白い記事を載せていました。
この TIP 7 の「Smart Sharding」が解決策になりそうです。
詳しくは、HTTP/2 に関する RFC7540 の Connection Reuse の項を参照すると良いわけですが、HTTP/2 かつTLS接続を使う場合、ワイルドカード証明書やマルチドメイン証明書に記述される利用ドメインが全て同一IPアドレスに名前解決される場合に限り、同一TLSセッションがドメインをまたいで再利用される。という仕様があるとのこと。
これを使えば、HTTP/1.x と HTTP/2 の両方で高速なサイトを実現できるよ。というのが、nginx の提案なわけ。
具体的には、出力する HTML はドメインシャーディングしたままにしておく。で、シャーディング対象のドメインリストを含む一枚の証明書でTLSを確立する。すると、HTTP/1.x では今までどおり複数ドメインからの配信となり、HTTP/2 では複数TLSセッションを張る必要がなくなる。というカラクリ。
もちろん、ドメイン名が多くなる分、名前解決のコストは増えてしまいますが、そこはまぁ、移行期の問題ということで無視する前提であれば、こういう解決策はあるよね。ということです。
実環境で検証していないのでなんともですが、Let’s Encrypt でも将来的にはワイルドカード証明書にも対応する。という話もありますし、うろ覚えですが、Subject Alternative Name の利用も可能、ということで、現状でもマルチドメイン証明書の取得も出来た気がしますので、証明書絡みの金銭的なハードルは、一般の人でもかなり低い気はします。
ということで、HTTP/2 時代のドメインシャーディングはこんな形にしたらいいんじゃないの？という考察でした。
Wordrpress サイトの HTTP/2 対応を考えるとき、他にも、HTTP/2 Server Push への対応や、HTTPS + GZIP 絡みのセキュリティイシューへの配慮、そして、HTTP/1.x との共存など、かなり細かな部分まで考え尽くす必要があるかと思いますが、とりあえず、ひとつづつ解決していきたいと思います。