HTTP2.0,3.0について調べたこと
目次
- ブラウザの速度改善はどうやって行うべきなのか調べていたところ...
- HTTP2.0 vs HTTP1.1
- HTTP3.0
- TCP と UDP の違い
- HTTP3.0 高速化の理由と注意点
- これらを学んで
- 参考文献
ブラウザの速度改善はどうやって行うべきなのか調べていたところ...
仕事で開発しているサービスのフロント側の速度改善ができないか調べていたところ、通信プロトコルの HTTP2.0 ってのがそういえばあったけどちゃんと理解してなかったなと思って深堀りしてみることにした。 HTTP3.0 もあったので同じく。寄り道である。
HTTP2.0 vs HTTP1.1
HTTP2.0 vs HTTP1.1という記事が図解されていて分かりやすかった。
大きな違いはデータのやり取りの方法。 html ファイルが、js ファイル、css ファイル, assets ファイルを読み込む。 HTTP1.1 では js,css,assets をサーバー側にリクエストする際、一つのリクエストが終えてから次のリクエストというように、分割して作業が行われる。 それに対し、HTTP2.0 ではそれぞれのリクエストをひとまとめにして一括でやり取りを行う。 これにより、描画速度の改善が見込める。 HTTP2.0 は 2015 年から正式仕様として承認されている(wiki より)
ただ、デメリットもあるらしい。
ファイルサイズが大きすぎると、逆に速度低下が起きてしまう可能性があるとのこと。
【ヘッドオブライン（HoL）ブロッキング問題】
10 個の画像があり、3 つめの画像が大容量だったりレスポンスが返却されるまでに時間がかかると、4 つめの画像ダウンロードに進まないといった現象のこと。
HTTP1.1 よりは改善されているが、HTTP2.0 も TCP 接続を行う関係上、途中でパケットが破棄された場合、再度ネゴシエーション(コンピュータで通信を行う際、デバイス同士が通信前にあらかじめ通信プロトコルなどの情報を交換し合うこと)をして回復を図ります。この回復している最中の時間は HTTP2.0 であっても手出しができない領域。 HTTP/3 の特徴 HTTP/2 と QUIC の違い
HTTP/2 では遅延や再送がない通信環境において HTTP1.1 で課題となっていたリクエストの並列化はできても、TCP で再送処理が発生してしまうと結局の所引きずられ HoL ブロッキングと同じ現象がおこってしまう問題が残っていた。
HTTP3.0
HTTP3.0 は 2018 年に登場。 上記 HTTP2.0 の課題であった TCP 接続がゆえのネゴシエーションの発生による速度低下を HTTP3.0 では UDP(User Datagram Protocol)という通信規格を用いることで解決した。
QUIC という google が開発した仕組みを導入した通信プロトコルが鍵。
【QUIC】
トランスポート層で利用される通信規格を TCP ではなく、UDP を使用することで高速な通信を実現
深ぼる前に、QUIC 内で使用されている UDP と、HTTP2.0 で課題となった TCP について。
TCP と UDP の違い
まず、HTTP と TCP,UDP は提供されるレイヤーが異なる。
HTTP はアプリケーション層、TCP ならびに UDP はトランスポート層での通信規格。
HTTP2.0 で利用されている TCP はコネクション型で 3-Way ハンドシェイクと呼ばれる方法で通信を行う。 データを受け取る相手がいることを確認した上で、1 つずつ順にデータの送信を行なうことが TCP の特徴と言えます。確実に相手へデータの送信が行えるため、セキュリティー面で信頼度が高いデータのやりとりができる点がメリットですが、接続のためのネゴシエーションにより通信速度は遅くなる。
HTTP3.0 で利用される UDP はコネクションレス型で、パケットの到達保証がないのが特徴。 通信相手の状況を確認せずにデータを送信することができるため、より高速にデータの送信が可能だが、セキュリティー面では TCP より劣る。そのため、動画や音楽のストリーミングなどに有効とされている。
HTTP3.0 高速化の理由と注意点
高速化の理由
- 接続確立時のハンドシェイク数の減少
【ハンドシェイク】
通信の接続を確立するためにサーバーと Web ブラウザの間で行われる一連の処理
TCP では、3-Way ハンドシェイクと言われるように通信を確立するために 1 往復半ハンドシェイクを行う必要があった。QUIC の技術では 1-RTT ハンドシェイク、すなわち 1 往復のみで通信を確立できる。
- ヘッドオブラインブロッキングの解消
上記は TCP の課題であった。UDP を使う際は、パケットロスが発生し、パケットを再送する場合でも最短で 0-RTT ハンドシェイクでパケットが受け取れたり、ロスパケットを受け取らずにデータを処理することもできるため高速化に繋がる。
- 優先度制御の再設計
【優先度制御】
パケットに優先度をつけて送信すること
HTTP2.0 では優先度制御にムラがあったが、QUIC の機能によって優先度制御を明確にし、ムラをなくなった。たとえば、ファーストビューの画像は先に表示して、他の画像は追って順番に表示することでユーザーの動きに合わせてスムーズにデータを表示していくことが可能になった。
導入時の注意点
- UDP 443 番ポートの確認
UDP443 番ポートが閉じていると HTTP/3 を導入できない
- コンテンツの常時 SSL 化
QUIC では TLS1.3 が利用されていることから、暗号化通信（SSL 証明書の利用）を前提としている。 よってコンテンツの常時 SSL 化が必要。
これらを学んで
フロント側の速度改善として、これまではフロント側をなんとかするという方法しか知らなかったが、今回のように通信プロトコルのバージョンアップで対応できる可能性もあるということが知れたのはかなり勉強になった。 バージョンアップによる後方互換性も担保されているみたいだし、特段理由がなければ http3.0 にしても問題ないのではないか？と今の段階では思っている。
