Skip to content

MS_HTTP3

nishi_74322014 edited this page Aug 3, 2026 · 1 revision

HTTP/3について調べてみた。

概要

  • HTTP/2 に続く HTTP の 3 つ目のメジャーバージョン

  • RFC ドラフト「Hypertext Transfer Protocol (HTTP) over QUIC」がベース

  • QUIC も Google によって初めに開発された実験的なトランスポート層プロトコル

  • サポート

    • 2019 年 9 月 26 日に、Cloudflare、Google Chrome で HTTP/3 のサポートが追加
    • 次期 Windows Server で QUIC(HTTP/3 や SMB で利用)を搭載予定

補足(最新化): 執筆時点では「RFC ドラフト」「搭載予定」であったが、 いずれも実現している。

  • RFC 9000(QUIC)、RFC 9114(HTTP/3)として 2021〜2022 年に標準化
  • Windows Server 2022http.sys / IIS が HTTP/3 に対応 (TLS 1.3 必須)
  • SMB over QUIC も Windows Server 2022 Datacenter Azure Edition で提供
  • .NET 6 以降で HTTP/3 に対応(MsQuic が前提)
  • 主要ブラウザは既定で有効

詳細

移行メモ: 元ページの「詳細」節は空であったため、 HTTP/2について調べてみた。 との差分を中心に補った。

なぜQUIC(UDP)なのか

HTTP/2 はストリーム多重化により HTTP レイヤの HoL ブロッキングを解消したが、 TCP 上で動作するため TCP レベルの HoL ブロッキングが残っていた。 パケットが 1 つ失われると、 そのコネクションに相乗りする全ストリームが再送を待たされる。

QUIC は UDP 上に独自のトランスポートを実装することで、 ストリームごとに独立した再送制御を行い、この問題を解消している。

主な特徴

特徴 内容
ストリーム独立 1 ストリームのパケット ロスが他のストリームを止めない
接続確立の高速化 トランスポートと TLS 1.3 のハンドシェイクを統合し 1-RTT(再訪問時は 0-RTT)で確立
TLS 1.3 が必須 暗号化は選択肢ではなく前提。ヘッダの大部分も暗号化される
コネクション ID IP アドレスが変わっても接続を維持できる(コネクション マイグレーション
ヘッダ圧縮 HPACK ではなく QPACK(順序保証が無い前提の設計)
ユーザ空間で実装 OS の TCP スタックに依存せず、改良を展開しやすい

補足: コネクション マイグレーションは実用上の効果が大きい。 スマートフォンが Wi-Fi からモバイル回線に切り替わっても、 TCP のように接続が切れず、通信が継続する。

運用上の注意

補足: HTTP/3 の導入で問題になりやすいのは ネットワーク機器側である。

  • UDP/443 が閉じている環境が珍しくない。 企業のファイアウォールでは UDP を落とす設定が多い。
  • このため HTTP/3 は Alt-Svc ヘッダによるアップグレードを前提としており、 最初は HTTP/2 や HTTP/1.1 で接続してから切り替わる。 UDP が通らなければ自動的に TCP のままになる(フォールバック)。
  • パケット キャプチャでの解析が難しい。 ヘッダの大部分が暗号化されているため、 Wireshark(MS_WiresharkUsage.md)で中身を見るには鍵が要る。

IISでの有効化

Windows Server 2022 以降で、次の条件を満たすと HTTP/3 が使える。

  • TLS 1.3 が有効であること
  • レジストリで http.sys の HTTP/3 を有効化すること
  • サイトのレスポンスに Alt-Svc ヘッダを付与すること

参考


Tags: IT国際標準, 通信技術, IIS, .NET開発, .NET Core, ASP.NET, ASP.NET MVC

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally