とりあえず書いてみます

興味がある事や考えなどとりあえず記事にしてます。

HTTP/3までの歴史

先日京都ハンナリーズ 対 宇都宮ブレックスのGAME1に観戦行き声がガラガラになったオビーです。

 

HTTP/3までの歴史

最近積んでて読めてなかったソフトウェアデザインの本読んで行っています。

個人的に最近流行っている情報などはサイト見たりブログみたりするのですが

ソフトウェアデザインもお金払って読むということで定期的に情報を仕入れることができて購読しています。

その中でHTTP/3までの歴史的な記事があったので覚えながらメモ書きしたので勉強のために残しておきます。

iPad買ってから本読みながらメモ残すの楽になった気がします。

 

HTTP/0.9

  • リクエストとレスポンスはシンプルなものGETメソッド以外はなかった

HTTP/1.0

  • HTTPヘッダーフィールド
  • HTTPメソッド（HEAD、POST）
  • 課題
    • 1リクエスト1レスポンスのやり取りでTCPコネクションを閉じていた
    • リソースの数だけ3ウェイハンドシェイクが発生する

HTTP/1.1

  • Keep-Aliveが追加されTCPコネクションを使い回せるようになった
  • 同一ドメインに対するリクエストではTCPコネクションを使い回す挙動がデフォルトになった
  • 上記の理由でオーバーヘッドが解消
  • 課題
    • Webコンテンツがリッチになった事によりドキュメントに含まれるリソースが多くなったことでコンテンツの表示速度が問題となっていた
    • 1.1では順番にリクエストとレスポンスを処理されるため後続のレスポンス待ち時間が発生してしまっていた
    • 上記をHTTPレイヤでのHead-of-Line Blockingと呼ばれていた
    • 並列に処理をしようとTCPコネクションを分けた場合にサーバ側のリソースが食いつぶされてしまうため、主要ブラウザはTCPコネクションの接続本数を制限していた

HTTP/2.0

  • Googleによって開発されたSPDY（読み：Speedy）というプロトコルをもとに2015年に発行
  • HTTP/1.xとの互換性がなくなったため2とメジャーバージョンが上がった
  • 特徴
    • ストリームによる多重化
    • 優先度制御
    • フロー制御
    • 擬似ヘッダフィールド
    • HTTPヘッダフィールド圧縮
    • サーバプッシュ
  • ストリームによる多重化により1.1で発生していたHTTPレイヤでのHOL Blockingを解決できるようになった
  • 1ストリーム（1Req：1Res）となりストリームIDをもとに順不同で送ることができるように
  • ストリームに優先度をつけることで重要なリソースを先に送れるようにもなった
  • 課題
    • 実際に常に2％のパケットロスがある非常に低品質なネットワーク環境ではHTTP/1.1の方が性能的に優れているという報告もあった
    • プロトコル変更に基づいて正しく拡張されたフォーマットパケットであってもフォーマットに対応している場合は、異常とみなされる場合がありパケットが破棄されたり通信遮断されたりすることがある
    • 高速化する工夫がされたが優先度制御が難しくブラウザ実装にばらつきがあるといった問題があった
    • TCPレイヤでのHOL Blockingの問題は残っている
    • TCPレイヤのHOL BlockingとはTCPレイヤで、あるパケットの到着が遅れたり、パケットロスしてしまったり後続のパケットの処理待ち時間が発生してしまう問題
    • プロトコル硬直化という問題

HTTP/3

  • HTTP over QUICという名前で策定が進んでいる
  • QUIC（Quick UDP Internet Connection）とは
    • UDPを使用し、TCPより高速な接続を提供
    • パケットは暗号化されている
    • ユーザースペースでの実装になっている為短い頻度でバージョン更新される
  • 特徴
    • QPACKとはHTTP/3で使用される圧縮アルゴリズム
      • ヘッダー圧縮
      • ハフマン符号
      • インデックステーブル
      • リセット機能
    • Round Trip Timeとはデータが送信元から宛先に到達しそれが宛先から送信もとに返ってくるまでの時間を示す通常RTTはm秒単位で測定される
    • ストリームによる多重化やTCPが担っていたコネクションはQUICに任せるようになった
    • 優先度制御はHTTP/3が対応
    • TCP HoL Blockingが発生しない
    • 暗号化が必須
    • コネクションマイグレーションが可能
    • ヘッダ圧縮にQPACKを利用
    • O-RTT(Round Trip Time)もしくは1-RTTでハンドシェイクが完了
  • HTTP/3が有効なケース
    • コネクションのマイグレーションが必要になるケース
    • 電車や新幹線など頻繁にアクセスポイントが切り替わったりするような場合など
  • UDPになったことで機能が不足する部分についてはQUICで制御する
  • HTTP/3の暗号化必須部分についてはQUICに内包されるTLS1.3で担当される
  • 暗号化必須となった背景
    • TCPで担っていたトランスポート層における問題をTCPを改善するというアプローチではなくUDPとUDPで不足する部分をQUICで担当するように改善したことが理由
    • UDPを利用しないといけないというデメリットが生まれたがHoL  Blocking問題やハンドシェイクのオーバーヘッドがかさむ問題は解消された
  • パケットロス時の再送制御をQUICで行う
  • HTTP/3はUDPを利用するためUDP443ポートを解放する必要がある
  • コネクションマイグレーション
    • 通信相手のIPやポート番号が変化してもセッションを継続できる機能
  • 利用してもらえるために
    • alt-sec: h3=“:443”
    • Alt-SvcヘッダでHTTP/3で接続可能なことを追記
    • DNSのHTTPSリソースレコードにHTTP/3が利用できる旨記載する必要がある
  • 課題
    • UDPポートを解放することでUDP Flood攻撃に対して脆弱な面がある
  • メリット
    • オーバーヘッドの削減による接続開始時のパフォーマンス向上
    • パケットロス発生時のパフォーマンス低下の防止
    • QUICとTLS1.3の連携によるセキュリティの向上
  • デメリット
    • UDPを利用することによる新たなDoS攻撃リスク
    • UDPという新しい技術スタックを利用するリスク
    • 適切な設定をしなければクライアントがHTTP/3で接続してもらえない

 

本当にメモ書きです。書いていきながら覚えようと思ってまだ覚えれていないですが

自分のブログを自分の勉強用のためにアウトプットも兼ねて利用していこうと思います。

 

PS：

GAME2も京都かたおかアリーナに観に行くので楽しみです！勝って欲しい！！