HTTP/2とHTTP/3についてまとめてやんよ!!!

タグ：HTTP2 | HTTP3

HTTP/2とはどういうものか？

HTTP/2とは、通信を効率化することにより、データ受信を早くし、ページ表示の高速化にも貢献する、HTTP通信規格のバージョン２の事です。
従来のHTTPよりも安全な通信が行えるので通信情報の改ざんや漏洩などに対応できます

近年では通信速度と安全性の面でSEOにも重要な役割を果たし、ここをおろそかにしているサイトはGoogleの検索結果にも影響が出ます。
簡単な判断基準はURLがこの規格に対応しているか？（httpsになっているか？）ということです。

HTTPからHTTP/2の主な改善点

HTTP2自体は既にスタンダードな仕組みなので、HTTP/1.1からおおまかな改善点のまとめとしては

• 従来のマルチレベルハンドシェイク（1リクエスト＝1レスポンスのやりとりを時系列に行う）を1つのコネクション内で同時に並行して複数のリクエスト/レスポンスを処理(ストリーム)
• ストリームごとに「優先度」を設定することも可能なのでコンテンツ表示に必須データを優先して送信や並行してコンテンツをダウンロードが可能
• クライアント/サーバー間の通信がバイナリベースで行われる
• HTTPヘッダの送受信時には圧縮/展開が可能なので効率的なやり取りが可能
• リクエストされていないコンテンツをサーバーがクライアントに送信するサーバープッシュが可能
• デフォルトのポート番号も完全な互換性があり、httpの場合80、httpsの場合443
• TLS（Transport Layer Security）での暗号化ができるので安全な通信ができるようになった

HTTPに使われるプロトコルのTCP

• TCPは、パケットの送信が成功するまで送信を再開しません。
• 複数レベルのハンドシェイクにより接続を処理し、データパケットを時系列に送信する
• パケットの送信が成功するまで送信を再開されない
• 送信は、注文と配送の確認とテスト番号を意味するAcksによって保護されます
• 送信されるデータには、送信側プロセスが受信側のピアプロセスと接続するためのパラメータを含むヘッダが含まれています

HTTP/2非対応によるMixed contentの危険性

SSL化されたhttpsページ内にhttp（非暗号化通信）で読み込んでいるファイルが存在（混在）している状態のことで、混在状態にはパッシブとアクティブの２種類がある

パッシブ混合コンテンツ

• ページの他の部分と相互作用しないコンテンツ(画像、ビデオ、オーディオなど)が対象
• HTTPリクエストを傍受し、中間者攻撃(man-in-the-middle)の対象になる
• 主な攻撃手段
  • 保存ボタンと削除ボタンの画像を入れ替え
  • 偽造された作成された株価チャート画像に差し替え
  • 製品イメージを別商品やポルノコンテンツの画像に改ざん
• 攻撃者がコンテンツを変更しなくても、混合コンテンツ要求を介してブラウザがロードする画像やその他のリソースに基づいてユーザーを追跡して遷移を知ることができる

アクティブ混合コンテンツ

• ページ全体と相互作用するリソース(スクリプト、スタイルシート、iframeやブラウザがダウンロードして実行できるその他のコードなど)に攻撃者がページに対してほとんど何でもできるようになる
• 主な攻撃手段
  • ユーザーパスワードやその他のログイン資格情報の盗用
  • ユーザーセッションCookieの盗用
  • ユーザーの別のサイトへのリダイレクト

Chrome側の仕様について

2020年から順次ブロック対象とするコンテンツが追加されていってる

• Ver.80(2月リリース版)では音声と動画の混合コンテンツ
• Ver.81(3月リリース版)では画像の混合コンテンツ
• Ver.84(7月リリース版)ではダウンロード可能なコンテキストコンテンツ
• 現在最新の安定版(Ver.88)では上記対象の削除機能の実装が完了しているとのこと

Chromeは現在、画像のみに限定してブロック対象となった混合コンテンツを含むアセットがHTTPS経由で利用可能（Ver.86の10月リリース版で実装）であるが、HTTPとしてハードコードされている場合、ブラウザーはHTTPSバージョンをロードする。
要は自動でhttps経由を探しに行ってくれるが、その分の再レンダリングの負荷にもなる

Chrome評価ツールのLighthouseでも計測をするとドメインがhttpsに対応していてもサーバーからダウンロードする画像ファイルなどがHTTTP/1プロトコル経由でダウンロードされた一覧がわかる。
サードパーティのコードがページ読み込みのパフォーマンスに与える影響が大きすぎる場合に警告が表示され、サードパーティによるメインスレッドのブロッキング時間の合計が250msを超えた場合に失敗する。

Mixed content（HTTP/2に非対応）が招くもの

• サイトが安全な通信を行っていても内部コンテンツの取得方が安全じゃないプロトコル通信で行われると、そこがセキュリティホールになってしまう
• その尻拭いをChromeなどのブラウザが行ってくれているが、その負荷分がSEOなどの評価に繋がり、メンテを行っていないサイトはどんどんページランクが下がっていくという負の連鎖の図式ができあがる

進化系のHTTP/3はどういうもの？

上記の理由により、通信を早く安全に対応させなければならない事がわかりました。
そしてHTTP2で一見通信としては完成形に見えるけえど・・・じゃあ何故、現在HTTP/3の規格が進んでいるのか？

TCPはルールが厳格で信頼性が高く、UDPはより柔軟に仕様を決められるようになっているため、効率を重視した通信が可能になっています。 HTTP/3は絶対的な速度向上というより、速度を上げるための工夫を行い、通信をより効率化した「新しいルール」と言えます。

Webサイトの表示速度をさらに高速化！「HTTP/3」とは？ \| さくらのSSL

リクエスト＆レスポンスの決まり事はHTTP/2でほぼほぼ完成形になったけど、その規格を利用して「もっと早くデータのやりとりできるように工夫してこう」がテーマとなっている

HTTP / 3はまだ開発中ですが、Google Chrome、Microsoft Edge、Firefox、および2020年4月以降はSafariでもすでにサポートされています。

HTTP/3に使われるQUICとは？

UDPは、TCPと異なり「挨拶なし」でいきなりデータのやり取りを開始することが出来ます。 この「挨拶」を交わさないUDPでも信頼性の高いやり取りをできるように実現したのが、2013年からGoogleが開発を続けてきたQUIC（クイック）というルールです。

Webサイトの表示速度をさらに高速化！「HTTP/3」とは？ \| さくらのSSL

つまり通信のたびに受信元と送信先の認証が必要な信頼性を重視のTCP(Transmission Control Protocol) ではなく、認証のやり取りを行わない高速性を重視するUDP (User Datagram Protocol) を使った新しい規格。

• TCPと比較して遅延を減らす新しいトランスポート
• ゼロラウンドトリップ接続の確立
  • ラウンドトリップ・・・安全な接続を確立するため、通信相手に信号やデータを発信して応答が帰ってくるまでのやりとりが必要
• クライアントが以前に特定のサーバーと通信したことがある場合、ラウンドトリップなしでデータの送信を開始できるように設計

HTTP/3の課題

• TCPとTLSからUDPとQUICに切り替える課題をプロバイダー側が抱える
• UDPはできるだけ多くのパケットを迅速に配信することを目的としているため、プロバイダーはTLS認証がないためにデータトラフィックが完全に検査されなくなる

ユーザー側にとってはメリットだらけだが、httpサーバー(プロバイダ側)の負担や責任が大きくなって今後より一層技術投資できるサービスとの格差が開きそうでまだまだ普及は難しそうだが、Google様の機嫌を損なわない様にちゃんと対応はしていかないとなりませんね。