HTTP/3が正式に勧告、脱TCP時代の幕開けか を読んでの雑感
はじめに
HTTP/3がRFC 9114として勧告された、ということで日経クロステックの記事を読んだので個人用にメモします。
また、QUICを調べているとJANOG48の興味深いセッションもあったのでそちらの内容も紹介します。
HTTP/3はすでにインターネットの25%を占めているようで、Google検索だと、以下のサイトで使われているようです。
wikiにあるようにメジャーなブラウザも対応が完了しており、Safari以外はデフォルトで有効になっているようです。
それでは記事の概要です。
日経クロステック記事概要
IETFは2022年6月6日にHTTP/3をRFC 9114として勧告
最大の特徴は、トランスポートのプロトコルにQUICを採用した点
TCPではなくUDPを使用し、再送制御やTLS暗号化処理をQUICが実施する
HTTP/3では、複数のリクエストとレスポンスをまとめた仮想的なパイプラインで処理することで、コネクション確立やエラー処理などのオーバーヘッドを低減させて高速化を図る
HTTP/3はもともとGoogleが開発したQUICがベース
米Q-Successの調査によると、2022年6月時点で約25％のWebサイトが既にHTTP/3に対応しているという。
こういうネットワークを作る人には問題が
JANOG48にてNTTComの方のセッションにも分かりやすくまとまっていました。
こういうネットワークを作る人には頭の痛い問題があるようです。
ISPでの問題
UDPはコネクションの終了が分からないので能動的にNATセッションのマッピングを消すことができない
途中のルータは無通信時間を基にコネクション終了を判断するしかない
結果、
NATテーブルがあふれてしまう
最近Google検索とか、Youtube、FacebookやInstagramがつながりにくいという人は、プロバイダーでのNATテーブルがあふれている可能性があるかもしれません。
対策
そもそもNATのUDPタイムアウトは2分未満にはしてはならず5分以上が推奨とあるも、
RFC4787 (BCP)によるとUDPのタイムアウトを2分未満にしてはならず、 デフォルト値としては5分以上が推奨される
以下の問題がありなかなか簡単にはいかないようです。
短い時間でコネクションを終了するアプリケーションで マッピングが埋まるので、特定の宛先ポートのタイムアウトは短くして良い
➡ DNSのタイムアウトを短くする実装は多い
また、そもそもHTTP/3には以下のような推奨仕様もあり、ハンドシェイクのオーバーヘッドを減らすという目的から、実は一度つなぐとセッションはずっと保持されることになり、それがセッションテーブルを圧迫してしまうのではないかという疑惑もあります(完全な憶測)。
RFC9000 ではタイムアウトを防ぐために30秒ごとにパケットを送信することが 必要であると述べられている
実際のところは現場の方に聞かないと分かりませんが、HTTP/3への移行には、アプリやクライアント側だけではなく、既存のNW事業者側にも対応が必要となるようです。