HTTP/3のエラーコードが語る真実：QUICレイヤーで交錯するパケットの深淵
TCPの呪縛からインターネットを解放するために生み出されたHTTP/3、そしてその下を支えるQUICトランスポート。パケットキャプチャを開けば、そこにはTCP時代の「パケットロスによる全ストリームの停止（Head-of-Line Blocking）」という悪夢が嘘のように消え去り、UDPの海原を軽快に突き進むUDPデータグラムの群れがある。
しかし、美しい抽象化の裏側で、プロトコルスタックの複雑さは爆発的に増している。トランスポート層のQUICが提供する信頼性と、その上で息づくHTTP/3のセマンティクス。この2つのレイヤーが絡み合うとき、何が起きているのか。
今回は、インフラアーキテクトやテックリードが深夜の障害対応で必ず直面する「HTTP/3のエラーコード」に焦点を当てる。`HTTP_NO_ERROR`の静けさから、`H3_GENERAL_PROTOCOL_ERROR`が引き起こすコネクション切断の絶望まで、パケットの挙動とカーネル内部の視点から紐解いていこう。
—
1. QUICとHTTP/3におけるエラーの二面性
まず大前提として押さえておかなければならないのは、HTTP/3におけるエラー管理は「2層構造」になっているという点だ。
TCPベースのHTTP/2では、エラー（RST_STREAMやGOAWAYなど）はすべて単一のTLS/TCPコネクションの上で完結していた。しかし、HTTP/3はUDP上で独自のトランスポート層（QUIC）を実装している。そのため、エラーは以下の2つに大別される。
1. QUICトランスポート層のエラー: 暗号化ハンドシェイクの失敗、パケット番号の空間異常、アイドルタイムアウトなど。これらはコネクション全体（Connection-Level）を即座に死に至らしめる。
2. HTTP/3（QPACK/ストリーム）層のエラー: ヘッダーのデコード失敗、存在しないストリームへのアクセス、不正なフレーム構造など。これらは特定のストリームを殺すだけで済む場合もあれば、コネクション全体を巻き込む場合もある。
この分離構造を理解していないと、Wiresharkでパケットを眺めたときに「なぜこのエラーでコネクションが丸ごとリセットされたのか」を見誤ることになる。
—
2. 主要なHTTP/3エラーコードの解剖学
RFC 9114（HTTP/3）およびRFC 9000（QUIC）で定義されているエラーコードのうち、現場のエンジニアが血眼になってログから探す主要なプレイヤーたちを見ていこう。
`HTTP_NO_ERROR` (0x0100 または 0x00)
「エラーがないのにエラーコード？」と思われるかもしれないが、これが非常に重要だ。
正常なシャットダウン、あるいはアイドル状態になったストリームを優雅に閉じる際、あるいはサーバーがメンテナンスのために既存の接続を穏便に切り上げる（Graceful Shutdown）際に使用される。
HTTP/2の `NO_ERROR` と同様だが、QUICのストリーム終了フレーム（`RESET_STREAM` や `STOP_SENDING`）にこのコードが含まれている場合、それは「意図的な正常終了」を意味する。
`H3_GENERAL_PROTOCOL_ERROR` (0x01)
インフラエンジニアの頭痛の種ナンバーワン。
これは「何かしらの規格違反だが、専用の細かいエラーコードを割り当てるほどでもない」という、いわば万能のゴミ箱エラーである。
多くの場合、リバースプロキシ（Nginx, Envoy, Cloudflare quicheなど）とクライアント側のブラウザやカスタムHTTP/3クライアントとの間での、厳格すぎる（あるいは緩すぎる）RFC解釈の不一致によって発生する。
`H3_INTERNAL_ERROR` (0x02)
サーバー側の実装バグ、あるいはリソース枯渇（バックエンドのデータベース接続断など）に起因する。
HTTP/3サーバーのプロセスがパニックを起こす直前や、例外をキャッチした際に、クライアントへ「すまない、こっちは内部で盛大にコケた」と伝えるために送出される。
`H3_STREAM_CREATION_ERROR` (0x03)
クライアントが新しくリクエスト用ストリームを開こうとしたが、サーバー側が設定した最大同時ストリーム数（Settingsフレームの `SETTINGS_MAX_FIELD_SECTION_SIZE` やストリームIDの制限）を超過した場合や、サーバーがリソース制限によりこれ以上ストリームを受け付けない場合に発生する。
`H3_FRAME_UNEXPECTED` / `H3_FRAME_ERROR` (0x04 / 0x05)
HTTP/3のフレーム構造（HEADERS, DATA, SETTINGSなど）の順序やペイロードが間違っている場合に発動する。
例えば、SETTINGSフレームが最初に来るべきなのに、いきなりDATAフレームが送られてきた場合などだ。これはプロトコル違反として即座にコネクションエラー（Connection Close）に繋がりやすい。
`H3_QPACK_DECOMPRESSION_FAILED` (0x0230 / QPACK関連エラー)
HTTP/3の肝であるヘッダー圧縮「QPACK」特有のエラー。
HPACKとは異なり、QPACKはパケットロスによる順序逆転を許容するため、「動的テーブル（Dynamic Table）」の参照状態を同期するための制御ストリームを持っている。この同期が崩れ、存在しないエフェメラルなインデックスを参照してしまった瞬間、このエラーが発生してコネクションが切断される。
—
3. パケットレベルの挙動：エラー発生から切断までのライフサイクル
実際に `H3_GENERAL_PROTOCOL_ERROR` や `H3_FRAME_UNEXPECTED` が発生したとき、ネットワーク上では何が起きているのか。パケットのタイムラインを追ってみよう。
Client Server/Proxy
| |
|— [QUIC Packet: HEADERS (Invalid Frame)] ————–>|
| | [パケット解析]
| | [エラー検知: H3_FRAME_UNEXPECTED]
| |
|<-- [QUIC Packet: CONNECTION_CLOSE (HTTP/3 Layer)] -------|
| |
| [状態遷移: draining / closed] |
| [UDPソケットは維持されるが、再接続が必要] |
ここで重要なのは、HTTP/3のエラーはQUICの `CONNECTION_CLOSE` フレーム（または `RESET_STREAM`）によって運ばれるという点だ。
TCPであれば、RSTパケットを送りつけることでレイヤーに関係なく強制切断できたが、QUICはUDPである。相手に確実にエラーを伝えるために、QUIC層は暗号化されたパケットの中にエラーコードを内包して送り出す。
Linuxカーネル（eBPF / XDP）およびユーザー空間実装の視点
現代の高性能HTTP/3サーバー（EnvoyやCloudflareのquiche、Metaのmvfstなど）の多くは、Linuxのカーネル空間ではなくユーザー空間（User-space networking）でQUICを実装している。
そのため、OSのUDPソケットバッファ（`net.core.rmem_max` など）からデータを効率的に引き上げ、各ストリームのステートマシンをユーザーランドで処理する。
もしアプリケーションが頻繁に `H3_GENERAL_PROTOCOL_ERROR` を吐いている場合、それはCPUキャッシュ効率やカーネルのソケットバッファチューニングの問題ではなく、アプリ層のバグ、あるいはTLSセッションチケット/証明書の不整合に起因するプロトコル違反である可能性が極めて高い。
—
4. 実務で役立つトラブルシューティングとデバッグ手法
現場でHTTP/3のエラーに直面した際、勘や推測でデバッグするのは時間の無駄だ。以下の手順で確実な証拠を掴む。
1. WiresharkでのQUIC・HTTP/3復号とエラーコードの特定
単にWiresharkでパケットをキャプチャしても、QUICのペイロードはTLS 1.3ベースで暗号化されているため中身は見えない。
環境変数に以下を設定し、ブラウザ（Chromeなど）からSSL/TLSのマスターシークレットをファイルに出力させる。
環境変数を設定してブラウザを起動（例: Linux/macOS）
export SSLKEYLOGFILE=/path/to/ssl_key_log.txt
google-chrome –enable-quic –origin-to-force-quic-on=example.com:443
Wiresharkの「Preferences -> Protocols -> TLS」の項目で、`(Pre)-Master-Secret log filename` にこのファイルを指定する。
これでパケットが復号され、HTTP/3のフレームツリーを展開すると、`Error Code: 0x01 (H3_GENERAL_PROTOCOL_ERROR)` のような生データがハッキリと目視できるようになる。
2. Envoy ProxyでのHTTP/3エラーログ監視
プロダクション環境でEnvoyをエッジプロキシとして運用している場合、アクセスログフォーマットにHTTP/3特有のストリームエラーやQUICのエラーを組み込んでおくことが不可欠である。
Envoyのアクセスカログ設定例（JSON形式でHTTP/3エラーを出力）
access_log:
- name: envoy.access_loggers.stdout
typed_config:
“@type”: type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
log_format:
json_format:
start_time: “%START_TIME%”
method: “%REQ(:METHOD)%”
path: “%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%”
response_code: “%RESPONSE_CODE%”
response_flags: “%RESPONSE_FLAGS%” # ここにUH（UDP Health error）や各種フラグが出力される
upstream_transport_failure_reason: “%UPSTREAM_TRANSPORT_FAILURE_REASON%”
quic_error_code: “%DYNAMIC_METADATA(envoy.communication_logger:quic_error)% ”
`RESPONSE_FLAGS` に `UH`（Upstream Hardware/Connection Failure）や `UO`（Stream Creation Overflow）などが記録されている場合、それは単なるネットワークのパケットロスではなく、HTTP/3プロトコル層での致命的なコンフリクトが発生している動かぬ証拠となる。
—
5. 極限のパフォーマンスとセキュリティのバランス
HTTP/3のエラーコード、特にQPACKやフレームバリデーションに起因するエラーは、時として「DoS攻撃のベクトル」になり得る。
悪意あるクライアントが、意図的に破損したQPACKの動的テーブル参照を含むHEADERSフレームを大量に送りつけ、サーバー側に過剰なデコードCPUコストを支払わせる（あるいは `H3_GENERAL_PROTOCOL_ERROR` を多発させてリソースを枯渇させる）攻撃手法が存在する。
これを回避するため、インフラストラクチャ層では以下の防御策を講じる必要がある。
- QPACKテーブルサイズの制限: サーバー側の設定（SETTINGS）で、動的テーブルの最大容量（`SETTINGS_QPACK_MAX_TABLE_CAPACITY`）を小さく、あるいはゼロ（静的テーブルのみの使用）に制限する。これによりメモリ枯渇とデコード起因のCPUスパイクを防ぐ。
- レートリミッティングの適用: UDPベースのQUICはAmplification Attack（増幅攻撃）の標的になりやすいため、Cisco/Juniper等のルーターや、iptables/nftables、eBPFプログラムレベルで、不審なレートのUDPパケットや不正なハンドシェイクを早期にドロップする。
- カーネルパラメータの最適化（UDPバッファ）:
大量のHTTP/3コネクションをさばくLinuxサーバーでは、UDP受信バッファの枯渇がエラーの引き金になることがある。`/etc/sysctl.conf` に以下のチューニングを施し、パケットドロップを防ぐ。
UDP受信/送信バッファの最大値を拡張し、バッファ溢れによるパケットロスを防ぐ
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 10000
—
結びにかえて
HTTP/3のエラーコードは、単なる「バグの通知表」ではない。それは、UDPという信頼性のない荒野の上で、信頼性と極限のパフォーマンスを両立させようともがくプロトコルスタックの「生きた叫び声」である。
`H3_GENERAL_PROTOCOL_ERROR` の背後にあるクライアントとサーバーの解釈のズレを見抜き、Wiresharkの暗号復号とカーネルバッファのチューニングを駆使して真の原因にたどり着くこと。それこそが、現代のネットワークアーキテクトに求められる真の技量なのだ。
パケットの旅路に思いを馳せながら、今日もターミナルを開き、ログの海を泳ぎ続けよう。
コメント