読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

HTTP/2まとめ

HTTP/2の仕様が決まったけど、全然内容をキャッチアップできてなかった。
Webエンジニアなので、最低限の知識は持っておきたいのでまとめました。

HTTP/2誕生まで

HTTP/1.1の問題点

リソースの取得の限界

HTTP/1.1では1接続で最大6つのコネクションを持てる。
当初は1つだけだったけど、Webが発達するに連れてリソース量が増えて来た。
それに対応するために同時に取得できるリソースが増えた。
しかし、7つ目移行のリソースからは新規にコネクションを確立する必要が有るため、表示速度の低下の回避が出来ないという問題が発生していた。 3ウェイハンドシェイクが、リソース量の増大とともに同じドメインに対して何回も必要になるため、遅くなるのは必然です。

HTTP/2の登場背景

上記、HTTP/1.1の問題はいろいろな解決方法で対応されましたが、どれも泥臭い対応になりました。
それを重大な課題だと認識したのが、Googleです。
そして、HTTP/2の原型となるSPDYを作り出します。

HTTP/2

HTTP/2の概要

HTTP/2の特徴

メッセージのやり取りをするのは変わりは無いが、その伝え方が変わる。
大きな変化は以下の2つ。

  • 効率化のための「ストリーム」
  • メッセージの新しい枠組み「フレーム」

改善点

まずは大きな変更以外のちょっとした改善内容から

  • ヘッダの圧縮*1
  • 優先処理*2
  • フロー制御*3
  • サーバプッシュ*4
  • 最終メッセージ通知*5

ストリーム

通信を管理する単位。
HTTP/1.1のHTTPリクエスト/レスポンスのセットが1ストリームのイメージ。
処理を待ったり、数による制限はない。
再利用出来ないが、TCPコネクションの切断が不要になる。
TCPが確立していれば再利用する。

フレーム

メッセージの形式。バイナリ形式。
HEADERSとDATAフレームにより表現される。

所感

HTTPの内容がバイナリになるので、転送速度は上がるものの、可読性は落ちると思った。
バイナリ読むためのツールが必要になるので、ビジネスチャンスが増えるなぁ~とは思った。 既存のやり方の拡張されるだけなので、さほど理解に苦はなかった。
ベースさえしっかり覚えているならすんなり覚えられる。
問題はどう付き合っていくか。モニタリングなどは考えなおさせば、ね。

*1:HPACKの仕組みを使用してヘッダ圧縮

*2:リクエストに優先度を設定できる

*3:受信側が受け取れる以上のデータを送信しない仕組みのこと

*4:サーバが先行してレスポンスを遅れる。

*5:コネクション切断理由、最後のメッセージの通知を相手に遅れる。