HTTP/2・HTTP/3プロトコル仕様とWeb高速化アーキテクチャ

1. 概要と本質：なぜWeb通信はTCPからUDP（QUIC）へ進化したのか

1990年代に誕生したHTTP/1.0および1999年のHTTP/1.1は、テキストベースのシンプルなリクエスト／レスポンスモデルにより、インターネットの爆発的普及を支えました。 しかし、現代のWebサイトは1ページあたり100個以上の画像、JavaScript、CSS、APIリクエストを読み込むことが当たり前となり、従来の仕組みでは「表示速度の低下（高レイテンシ）」が深刻な課題となりました。

これを解決すべく2015年に標準化された 「HTTP/2」 は、単一のTCP接続上で複数のリクエストを並行処理する「ストリーム多重化」を実現しました。 しかし、HTTP/2はトランスポート層に TCP を使用していたため、「パケットが1つでも欠落すると、無関係な全ストリームの通信が停止する（TCP層のHead-of-Lineブロッキング）」という根本的限界に直面しました。

このTCPの呪縛を断ち切るために誕生したのが、2022年にRFC 9114として標準化された 「HTTP/3」 です。 HTTP/3は、トランスポート層をTCPから UDP へと刷新し、その上に新開発の高信頼トランスポートプロトコル 「QUIC（RFC 9000）」 を実装しました。

ネットワークスペシャリスト（NW）午後・科目B試験では、「HTTP/1.1の課題とドメインシャーディング」「HTTP/2のバイナリフレーミングとHPACK」「TCPとHTTP/2のHoLブロッキングの違い」「HTTP/3におけるQUICの0-RTTハンドシェイクとコネクションマイグレーション」が近年の最重要トピックとして出題されます。本稿ではその動作原理と試験のツボを網羅します。

2. HTTP/1.1の限界と旧来のWeb高速化ハック

HTTP/1.1は「1つのリクエストを送信したら、そのレスポンスが返ってくるまで同一コネクション上で次のリクエストを送れない」という制約がありました。

図のデータを表示できません。

2.1 HTTP/1.1時代の苦肉の策（高速化ハック）

1. ブラウザの同時接続数制限（1ドメインあたり最大6本）:

- 複数コネクションを無理やり張るため、サーバに膨大なTCP・TLSハンドシェイクの負荷がかかる。

1. ドメインシャーディング（Domain Sharding）:

- img1.example.com, img2.example.com のように複数のサブドメインを用意し、ブラウザの6本制限を回避する（DNS問合せとハンドシェイクが激増）。

1. リソースの結合（スプライト画像、JSバンドル）:

- 多数のアイコン画像を1枚の巨大画像にまとめたり、JSファイルを1つに結合してリクエスト数を減らす（キャッシュ効率が極端に悪化）。

2.1 HTTPプロトコルの世代別比較マトリクス

3. HTTP/2のアーキテクチャ：ストリーム多重化とHPACK

HTTP/2（RFC 7540 / RFC 9113）は、HTTPのセマンティクス（GET, POST, ステータスコード等）を維持したまま、データ転送の仕組みを「バイナリフレーミングレイヤ」に置き換えました。

図のデータを表示できません。

3.1 HTTP/2の中核機能

1. ストリームの多重化（Multiplexing）:

- 1本のTCPコネクション内に複数の仮想的な論理通信路（ストリーム）を確立。 - レスポンスの生成が完了した順に細切れのフレーム（Frame）をインターリーブ（交互に挟み込んで）送信できるため、アプリケーション層でのHoLブロッキングを完全解消。

1. HPACKによるヘッダ圧縮:

- 頻出するHTTPヘッダ（User-Agent, Cookie等）を「静的テーブル（規格定義）」と「動的テーブル（セッション中に学習）」でインデックス化し、重複する巨大ヘッダを数バイトのインデックス番号に圧縮。

1. ストリームの優先度制御（Priority）:

- レンダリングをブロックするCSSやJSを、優先度を上げて画像より先に送信するようクライアントが指示可能。

4. HTTP/2の致命的弱点：TCP層でのHead-of-Lineブロッキング

HTTP/2によりアプリケーション層での並行処理は実現しましたが、「トランスポート層がTCPであること」に起因する壁が残りました。

図のデータを表示できません。

[!WARNING] TCP Head-of-Lineブロッキングの本質 モバイル回線やWi-Fiなど、パケットロス率が数％存在する劣悪な電波環境下では、HTTP/2はHTTP/1.1よりも表示速度が遅くなるという逆転現象が発生します。 （HTTP/1.1は複数コネクションを張っているため、1本がロスしても他の5本は進むが、HTTP/2は1本のTCP接続に全ストリームを相乗りさせているため全滅する）。

5. HTTP/3とQUICプロトコル：完全なる独立性の獲得

HTTP/3は、TCPを捨てて UDP を採用し、UDPの上に暗号化と高信頼トランスポートを統合した 「QUIC」 を構築しました。

図のデータを表示できません。

5.1 QUICの中核機能と優位性

① ストリームごとの完全独立（TCP HoLブロッキングの根絶）

QUICでは、パケットの欠落検知と再送制御を「ストリーム単位」で行います。 Stream 3のパケットがロスしても、正常に届いたStream 1やStream 5のデータは即座にブラウザへ引き渡されます。パケットロス発生時の遅延影響が他の通信へ波及しません。

② 高速な接続確立（1-RTT / 0-RTT ハンドシェイク）

TCP＋TLSでは「TCPの3ウェイハンドシェイク（1-RTT）」＋「TLSハンドシェイク（1〜2-RTT）」の計2〜3-RTTが必要でした。 QUICはトランスポートとTLS 1.3の暗号化ネゴシエーションを単一のハンドシェイクに統合しており、初回到達は1-RTT、過去に接続実績があるサーバへは0-RTT（最初のパケットにHTTPリクエストを同乗させて送信）で通信を開始できます。

図のデータを表示できません。

③ コネクションマイグレーション（Connection Migration）

スマートフォンでWeb動画を視聴しながら地下鉄から屋外へ出て、「駅のWi-Fiから携帯4G/5G回線へ切り替わった」場合、端末のIPアドレスは瞬時に変化します。

• TCP（HTTP/1.1・HTTP/2）: 通信は「送信元IP、宛先IP、送信元ポート、宛先ポート」の4つ組で識別されるため、IPが変わった瞬間にTCP接続は破棄（RST）され、セッション切断・再接続が必要。

• QUIC（HTTP/3）: 通信の識別にIPアドレスではなく、パケットヘッダ内の 「コネクションID（Connection ID: CID）」 を使用。IPアドレスやポート番号が変化しても、CIDが一致していれば既存セッションを切断することなく通信をシームレスに継続できます。

6. 運用・移行の落とし穴：UDP 443遮断とAlt-Svc

企業内LANや公衆Wi-Fiでは、セキュリティポリシー（侵入検知やWebプロキシの制約）により、「外部宛てのUDP通信（DNSの53番等を除く）を全遮断」しているネットワークが多数存在します。

図のデータを表示できません。

ブラウザは初回アクセス時にHTTPレスポンスの `Alt-Svc`（Alternative Services）ヘッダ を受け取ることでHTTP/3対応を認識し、次回からQUICを試行します。もしUDPが遮断されていても、透過的にHTTP/2へフォールバックする設計となっているため、Webサイトが閲覧不能になることはありません。

7. 午後・科目B形式 実戦演習

【問題シナリオ】

大手物流サービスのR社は、全国数万台の配送トラックに搭載されたIoT車載端末から、走行位置・配送状況・車載カメラ画像をクラウド上のWebAPIサーバへ送信する新システムを設計している。 車載端末は4G/5Gセルラー回線を経由してHTTPS通信を行うが、山間部やトンネル走行時の電波減衰、および基地局ハンドオーバー（セル切り替え）に伴うパケットロスや瞬断が課題となっている。

図のデータを表示できません。

プロトコル選定にあたり、システム設計チームは以下の2つの案を比較検討した。

• 案A: 従来のHTTP/2（over TCP）を採用。

• 案B: 最新のHTTP/3（over QUIC/UDP）を採用。

検証実験において、パケットロス率が3%発生する無線環境をシミュレートしたところ、案A（HTTP/2）では特定の画像データのパケットが1つ消失した際に、同時に送信していた緊急のGPS位置情報パケットのAPI受信が数百ミリ秒間フリーズする現象が観測された。一方、案B（HTTP/3）ではこの遅延波及は一切観測されなかった。

【設問1】

案A（HTTP/2）において、画像データのパケット消失によって、それとは独立した別ストリームのGPS位置情報データの受信までフリーズした技術的理由について、トランスポート層プロトコルの動作に着目して35字以内で述べよ。

解答への思考プロセス

• 現象の分析:

- HTTP/2はアプリケーション層で複数ストリームを多重化しているが、トランスポート層は単一のTCP接続である。 - TCPはすべてのパケットに対して「バイトストリームの順序通りの到着（順序保証）」を義務付けている。 - 先行パケット（画像データ）がロスすると、TCP受信バッファは後続パケット（GPSデータ）が正常に届いていても、欠落パケットの再送・到着が完了するまでアプリケーション（Webサーバ）への引き渡しを停止（ブロック）する。 - これが「TCP層でのHead-of-Lineブロッキング」。

• 設問要求の確認:

- 「トランスポート層プロトコルの動作」＝TCPの順序保証 - 35字以内でまとめる。

• 文章作成:

- 欠落パケットが再送されるまでTCPが後続パケットの引渡しを止めるため。（36字 → 圧縮） - TCPが順序保証のために欠落パケットの再送完了まで受信を待機させるため。（36字） - TCPの順序保証により欠落パケット再送まで後続データが渡されないため。（35字）

模範解答

TCPの順序保証により欠落パケット再送まで後続データが渡されないため。（35字）

減点・失点分析

• ×「HTTP/2のストリーム多重化が失敗したため。」（HTTP/2の層ではなく下位のTCP層の問題であるため0点）

• △「パケットロスにより回線帯域が狭まったため。」（帯域の問題ではなくTCPの受信待機バッファの仕組みに触れていないため不十分）

【設問2】

車載端末が走行中に基地局を切り替え、端末のIPアドレスが変更された際、案B（HTTP/3）が接続を切断させることなく通信をシームレスに継続できる理由について、パケットの識別方法に着目して35字以内で述べよ。

解答への思考プロセス

• 技術要素の特定:

- QUICの「コネクションマイグレーション（Connection Migration）」。 - TCPは「送信元IP、送信元ポート、宛先IP、宛先ポート」の4つ組でコネクションを識別するため、IPアドレスが変わると接続が切れる。 - 一方、QUICパケットのヘッダには 「コネクションID（Connection ID）」 が含まれており、IPアドレスやポート番号が変わっても、同一のコネクションIDを持つパケットとして同一セッションとして識別・継続処理できる。

• 制限字数（35字以内）への整形:

- 「IPアドレスではなくパケット内のコネクションIDで接続を識別するため。」（35字）

模範解答

IPアドレスではなくパケット内のコネクションIDで接続を識別するため。（35字）

減点・失点分析

• ×「UDPなのでセッション管理自体が存在しないから。」（UDPの上にQUICが存在し、QUICが高度なセッション管理を行っているため誤り。0点）

• △「TLS 1.3のセッション再開機能を使っているから。」（セッション再開ではなく接続そのものを切断せずに継続するコネクションIDの働きに言及していないため減点）

8. まとめと次ステップ

Webプロトコルの進化は、ネットワーク層・トランスポート層の制約を克服する歴史そのものです。

• HTTP/1.1: 接続ごとに順序待ちが発生（HoLブロッキング）。

• HTTP/2: 1つのTCP上でストリーム多重化を実現するも、TCP層のHoLブロッキングが残存。

• HTTP/3: トランスポートをUDP+QUICへ刷新し、ストリームの完全独立、0-RTT接続、コネクションマイグレーションを達成。

• UDP遮断環境では Alt-Svc によるHTTP/2フォールバックが安全弁として機能。

次稿 NWP-09（IPsec-VPN（IKEv2・NAT-T）の拠点間トンネル設計と暗号化） では、公衆網を安全な企業プライベート網へと変貌させるIPsecプロトコルスイート、IKEv2の高速鍵交換、およびNAT越え（NAT-T）のメカニズムを徹底解説します。