今からレンタルサーバーを選ぶならHTTP/2対応がおすすめです

レンタルサーバーで普及しつつある、今年の特徴的な技術として「HTTP/2」があります。 すでに大手サイトでは採用されていますが、汎用的なレンタルサーバーで普及したのは今年になってからでしょう。

HTTP/2とは次世代のWebプロトコルであり、これまで利用されてきた(かなり古い)HTTP/1.1を置き換えるものです。 HTTP/1.1のボトルネックが大きく改善されており、多くのリソース(画像などのファイル)が扱われるコンテンツで大きな効果を得られます。 レンタルサーバー利用者に対するメリットは*「コンテンツの修正なしに表示が高速化される」*ことが挙げられます。

たまに勘違いしている方もいますが、HTTP/2とHTTPSとは関係ありません。 仕様的にはSSLに関係なく動作しますが、ほとんどのブラウザがHTTPSでのみ動作をサポートしているため、実質的にSSLが必須となっているだけです。

細かい説明は後回しにして、実際にHTTP/2の効果を確認してみましょう。

この様なサイトをHTTP/2対応レンタルサーバーに配備して測定します。 このグラフは全く同じコンテンツをHTTP/1.1とHTTP/2とで比較したものです。

多くの画像を配備したコンテンツの読み込みに要した時間の比較です。 画像が少ない場合はそれほどの差はありませんが、HTTP/1.1の場合、画像数(ファイル数)に比例して読み込み速度が大きく低下します。 HTTP/2の速度低下は緩やかであり、明確な差を確認できます。

勘違いしてはいけませんが、あくまでもこの条件(コンテンツ)ではこの結果になるだけであり、どのようなコンテンツでも確実に改善されるわけではありません。 よく「○倍速くなった」「○%改善された」のような記事を見かけますが、条件により大きく変動するため、あまり鵜呑みにしない方がよいでしょう。

HTTP vs HTTPS
toolbox.hostingstock.net

HTTP/2とは?

HTTP/1.1は一つの接続(コネクション)で一つのファイルを取得します。 取得し終えるまで次のファイルを取得することはできません。 これでは多くのファイルで構成されるコンテンツの表示に時間がかかります。

そこで、ほとんどのブラウザでは複数のコネクションを利用して、並列でダウンロードしています。 複数のコネクションを使うことで転送時間が短縮され、結果コンテンツの表示が速くなります。

この図では、2つのコネクションを例としていますが、ChromeやFirefoxは最大6本のコネクションを使用します。

メモ
「6本」は技術的な上限ではなく、サーバーへの負荷を考慮したものであり、ブラウザによっては変更できます。

複数のコネクションを使用しても、上限に達すれば取得待ち状態になることに変わりはありせん。 極端な例であれば、全てのコネクションが大きな画像のダウンロードに使われると、それらが終わるまで次のファイルを取得できません。

話は変わりますが、この上限は「一つのドメイン」に対するものです。 そのため、大手サイトではドメイン(サーバー)を分散させることで、この制限を回避しています。 つまり、複数のドメインにファイルを割り当てることで、ひとつのコンテンツに対する同時接続数を増やしています。

もちろん、個人で運用するサイトでも同様のことは可能ですが、管理の煩雑さやコスト的に厳しいものがあります。

HTTP/2の動作を確認する

100個の画像を置いてあるサイトへアクセスすると、HTTP/1.1の場合6つのコネクションが利用されていることが分かります。

メモ
下記画像はChromeのデベロッパーツールです。Firefoxなど、他のブラウザでも同様に確認できます。

同じサイトをHTTP/2でアクセスすると、一つのコネクションで全てのファイルを取得していることが分かります。

一つのコネクションで複数のファイルを取得できる理由は、「ストリーム」と呼ばれる独立した(仮想的な)転送経路の採用にあります。 HTTP/1.1では複数のコネクションで並列転送を実現していましたが、HTTP/2では一つのコネクション内で複数のストリームを管理することで実現しています。

仕様的にはストリーム数に制限がないため、HTTP/1.1のようなボトルネックがなくなります。 ただし、ネットワーク速度に依存することに変わりはありません。

他にもストリームごとに優先順位を付けることができるため、コンテンツの表示に必要なファイルから効率的に転送することも可能となっています。 しかし、利用者がそれらを制御できる訳ではないため、あまり気にする必要はありません。 HTTP/2はHTTP/1.1の問題点を解決し、効率化されたものと知っておけば十分です。

魔法の道具ではない

HTTP/2対応のレンタルサーバーを利用すれば手軽に改善されますが、どのような条件でもということもありません。 最初のグラフを見れば分かりますが、ファイルの少ない、例えばシンプルなブログのように画像が少しだけのサイトであれば、大きな差は生じません。 また、効率的に転送できるようになったとは言え、転送されるデータ量は(それほど)変わらないため、結局のところネットワーク速度に依存します。

最も効果が大きいのは、(それほど大きくない)多くのファイル、例えば画像やアイコンの多いサイトでしょう。 他にもJavaScriptやCSSを大量に利用するサイトでも効果がありますが、その場合は、予め一つのファイルにまとめたほうがよいでしょう。

現在のサイト運営で速度的な問題がなければ、あえて他の対応サービスに移行する必要はありません。 標準的な規格であるため、しばらくすればどのレンタルサーバーでも対応するでしょう。

もし新規にレンタルサーバーを検討しているのであれば、すでにHTTP/2に対応しているサービスがおすすめです。 新しい規格にすぐに対応できるレンタルサーバーは、サービス品質も高い傾向にあります。

例えば、当サイトでも利用している XSERVER (エックスサーバー) もおすすめの一つです。

測定結果

画像数の異なる同じサイトにHTTP/1.1とHTTP/2とでアクセスした測定結果です。 HTTP/2の方が、画像数の増加に対する速度低下が緩やかであることが分かります。

メモ
一時的な異常値を省く的に棄却検定を適用しています。

HTTP/1.1

  HTTP/1.1 10個 HTTP/1.1 30個 HTTP/1.1 60個 HTTP/1.1 100個 HTTP/1.1 150個 HTTP/1.1 210個
測定数 719 714 714 713 712 688
有効数 680 674 693 683 686 671
除外数 39 (5.42%) 40 (5.6%) 21 (2.94%) 30 (4.21%) 26 (3.65%) 17 (2.47%)
異常値 1,729ms 1,826ms 2,728ms 2,634ms 4,306ms 5,517ms
棄却値 778ms 1,058ms 1,262ms 1,358ms 1,912ms 2,520ms
エラー 0 (0%) 0 (0%) 0 (0%) 0 (0%) 0 (0%) 0 (0%)
中央値 480ms 548ms 699ms 897ms 1,164ms 1,486ms
平均値 496ms 585ms 738ms 924ms 1,208ms 1,547ms
標準偏差 59ms 101ms 112ms 89ms 146ms 205ms
変動係数 12.0% 17.3% 15.2% 9.7% 12.1% 13.2%
初回 92ms 71ms 71ms 66ms 73ms 74ms

HTTP/2

  HTTP/2 10個 HTTP/2 30個 HTTP/2 60個 HTTP/2 100個 HTTP/2 150個 HTTP/2 210個
測定数 688 686 686 685 684 683
有効数 663 660 660 653 662 656
除外数 25 (3.63%) 26 (3.79%) 26 (3.79%) 32 (4.67%) 22 (3.22%) 27 (3.95%)
異常値 890ms 1,138ms 1,292ms 1,962ms 1,506ms 1,353ms
棄却値 635ms 678ms 702ms 795ms 867ms 904ms
エラー 0 (0%) 0 (0%) 0 (0%) 0 (0%) 0 (0%) 0 (0%)
中央値 448ms 475ms 487ms 519ms 564ms 632ms
平均値 453ms 479ms 493ms 532ms 578ms 643ms
標準偏差 36ms 41ms 44ms 55ms 59ms 54ms
変動係数 8.0% 8.5% 9.0% 10.3% 10.3% 8.3%
初回 112ms 106ms 108ms 112ms 110ms 114ms

関連記事

BLOG

UPDATE

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy