※この記事ははてなブログから引っ越しました
この記事の目的
今更ながら HTTP/2 がどのようなものかを調べたくなったので、その結果をまとめた記事になります。
あくまで概要をまとめたもので、今はたくさんの良記事があるので、詳細が知りたい場合は最後の参考文献のリンク先を見ると参考になると思います。
HTTP/2 の特徴
- ストリームという概念を導入したことで HTTP/1.1 に比べて効率的に通信できます
- ヘッダー圧縮を行うことで HTTP/1.1 より通信量を減らすことができます
- サーバープッシュによりリクエストされる前にサーバーからリソースを送信することで HTTP/1.1 よりラウンドトリップ回数を減らすことができます
- HTTP/1.1 と互換性があります
- 事実上
TLSによる暗号化が必須になります - モダンブラウザは対応済です (最新の対応状況は Can I Use で確認してください)
ストリームとは？
HTTP/1.1 の欠点
HTTP/1.1 では、１回目のリクエスト→１回目のレスポンス→２回目のリクエスト→・・・というように、一度リクエストをするとそのレスポンスを受け取ってから次のリクエストを行う必要があります。
大量の画像やファイルで構成されているページを表示する際には、この制約が大きなネックになります。そのため、モダンブラウザでは複数のコネクションを同時に使用することで高速化を図っているそうです。
また、HTTP/1.1 では HTTP パイプラインという高速化手法もありますが、問題があることから、ほとんどのブラウザでは既定で無効になっています。
ストリームを導入することでどう変わるか？
ストリームとは、１つのコネクションの中に独立した複数の仮想的なコネクションのようなものがあり、リクエストとレスポンスを並列で行えるようになるため、１つのコネクションで効率的に通信が行えるようになります。
ヘッダー圧縮とは？
HTTP/1.1 は数百バイト〜数KBあるヘッダーを非圧縮かつ全てのヘッダーを毎回送受信する必要があります。
HTTP/2 では HPACK という圧縮方式を使用し、データ自体を圧縮するとともに、ヘッダーのキャッシュを行うことで差分のみを送受信することが可能になり、ヘッダーを効率よくやり取りできます。
サーバープッシュとは？
HTTP/1.1 では、通常最初に HTML ファイルを受け取ってから、再度描画に必要なリソースをリクエストする、という形になっています。
HTTP/2 では、リクエストに対し（クライアントからのリクエスト無しに）予めサーバーから必要と思われるリソースを送信することが可能になっています。
これにより、ラウンドトリップ回数を減らし、リソースの読み込みまでの時間を短縮することができます。
HTTP/1.1 との互換性
HTTP/2 通信を開始する際は、最初に従来どおりの HTTP リクエストの中に、以下のヘッダー情報を加えて送信し、サーバーから 101 Switching Protocols のレスポンスを受け取ってから HTTP/2 の通信を開始することで、互換性を保っています。
Connection: Upgrade, HTTP2-SettingsUpgrade: h2c
HTTP/2 を使うメリット
HTTP/2 はここまでの説明の通り、様々な手法で効率よく通信を行えるようになるため、 HTTP/1.1 よりページの読み込み時間が短縮されることが、最大のメリットだと思います。
また HTTP/1.1 との互換性があるため、HTTP/2 非対応のブラウザであってもアクセス可能であるため、導入が容易であることもメリットであると思います。
HTTP/2 を使うデメリット
全てのサイトで高速化されるわけではないことだと思います。例えば、もともと必要なソースが少なく、リクエスト数が少ない場合はあまり恩恵が受けられないと思います。
ただ、遅くなるわけではないので、デメリットという程でもないかと思います。
あとは HTTP/2 に対応する作業コストといったところかと思いますので、実質デメリットはないかな、と思いました。
調べてみた感想
HTTP というプロトコルはステートレスでシンプルなプロトコルが最大の特徴だと個人的には思っているのですが、HTTP/2 は結構複雑だな、という印象です。ヘッダーの圧縮とか、ステートレスな点もありますし。
ただそれも、HTTP が世界で圧倒的に普及した結果、僅かな高速化でも大きな影響があるため、あらゆる手法を取り入れていこうとした結果なのだろうな、とも思います。
デメリットもほぼないと言っても良さそうなので、利用できる時は積極的に使っていくべき技術だと感じました。