【テクニカル・上級編】HTTP/2におけるコネクションレベルのエラー(CONNECTION_ERROR) – HTTPプロトコル・通信規格実践ガイド

パケットが語る死の宣告：HTTP/2 `CONNECTION_ERROR` の深淵

Webの高速化と効率化の旗手としてHTTP/2がデファクトスタンダードとなって久しいが、現場のインフラエンジニアやSREにとって、このプロトコルは時として「黒魔術」のような挙動を見せる。HTTP/1.1のテキストベースのやり取りから、バイナリフレーミング層をベースにしたストリーム多重化へとパラダイムシフトした結果、私たちはパフォーマンスの飛躍的向上を手に入れた代わりに、エラーハンドリングの複雑さと厳格さに直面することになった。

特に、HTTP/2の命運を握る「コネクションレベルのエラー（`CONNECTION_ERROR`）」は、ひとたび発生すれば、そのTCPセッション上で並行して流れていた数十、数百のストリームを一網打尽にする。あたかも一粒の毒がワイングラス全体を腐らせるように、ひとつのプロトコル違反が単一のコネクションを即座に死に至らしめるのだ。

本稿では、この `CONNECTION_ERROR` がパケットレベルでどのような絶望を生み出し、どのようなメカニズムでコネクションの切断とリカバリーを引き起こすのか、LinuxカーネルやTLSのレイヤーまで掘り下げて徹底的に解剖していく。

—

1. バイナリの厳格さ：なぜ `CONNECTION_ERROR` は発生するのか

HTTP/1.1では、クライアントとサーバーの間で多少のパースの不整合や仕様の逸脱があっても、コネクションが即座に切断されることは稀だった。Connectionヘッダーの解釈に揺らぎがあっても、コネクションを維持しながらHTTPレスポンスを返し続けることが可能だったからだ。

しかし、HTTP/2の世界では話が全く異なる。すべての通信は「フレーム（Frame）」というバイナリの単位にカプセル화され、厳格なステートマシンに従って処理される。この厳格さゆえに、RFC 7540が定義するルールから僅かでも外れた挙動を検知した場合、受信側は「これ以上の対話は不可能である」と判断し、`RST_STREAM` による部分的な破棄ではなく、コネクション全体を強制終了させる `GOAWAY` フレームの送信、あるいは即座のTCP切断（RSTパケットの送出）を選択する。

コネクションエラーを引き起こす主要なトリガー

1. 不正なフレーム長（FRAME_SIZE_ERROR）:
サーバー側が許可した最大フレームサイズ（`SETTINGS_MAX_FRAME_SIZE`）を超えるフレームを受信した場合。
2. フローコントロールの破綻（FLOW_CONTROL_ERROR）:
受信側のウィンドウサイズを超過したデータ（`DATA` フレーム）が送りつけられた場合。HTTP/2はエンドツーエンドのフローコントロールを強制するため、これを計算ミスやバグで誤ると即座に死刑宣告が下される。
3. 不正なストリーム識別子（PROTOCOL_ERROR）:
すでに閉じられたストリームや、未初期化の奇数/偶数ルールに違反したStream IDに対してフレームが送信された場合。
4. HPACKコンテキストの破壊（COMPRESSION_ERROR）:
ヘッダー圧縮の文脈（Dynamic Table）が同期不整合を起こし、デコードに失敗した場合。

これらは単なる「不親切な仕様」ではない。HTTP/2は単一のTCPコネクション上で多重化を行うため、ひとつのストリームがプロトコル違反を起こした際、それを放置すると他の安全なストリームのデータ構造やメモリ空間まで破壊するリスク（ヘッドオブラインブロッキングやメモリリーク）を孕んでいる。そのため、全体の安全性を担保するための「断固たる措置」として `CONNECTION_ERROR` が設計されているのだ。

—

2. パケット解析：`GOAWAY` フレームと死に至るプロセス

実際にパケットキャプチャ（Wireshark等）を覗いてみると、`CONNECTION_ERROR` が発生した瞬間のドラマチックな（そして冷酷な）挙動が手に取るようにわかる。

サーバーがプロコル違反を検知した瞬間、アプリケーション層から下位レイヤーに向けて以下のシーケンスが実行される。

[Client] [Server]
│ │
│─── DATA (Invalid Flow Control) ──────────>│ <-- 違反検知！ │ │ │<── GOAWAY (Last-Stream-ID: 5, ERROR_CODE) ─│ <-- 接続切断の通告 │ │ │ (TCP FIN or RST 処理へ移行) │ │──────────────────────────────────────────>│

ここで特筆すべきは、`GOAWAY` フレームの存在意義だ。`GOAWAY` は、単に「切断する」という暴力を振るうのではなく、「どのストリーム番号（Last-Stream-ID）までをサーバー側が処理したか」をクライアントに伝えるための優しさと合理性を持っている。

`GOAWAY` のバイナリ構造を紐解くと、エラーコード（32bit）が含まれている。
代表的なエラーコードをいくつか挙げておこう：

もしあなたがNginxや Envoy、あるいはGo言語の `net/http` で独自のHTTP/2サーバーを実装しているなら、ログに突如として `http2: server: error reading frame: …` や `INTERNAL_ERROR` が吐き出される現象に悩まされたことがあるはずだ。その多くは、クライアント側の不穏な挙動（あるいはプロキシ層でのバグ）による `CONNECTION_ERROR` の誘発に起因している。

—

3. HPACKの呪縛と `COMPRESSION_ERROR`

HTTP/2のパフォーマンスを語る上で欠かせないのが、ヘッダー圧縮アルゴリズム「HPACK」だ。毎回数キロバイトに及ぶUser-AgentやCookie、Authorizationヘッダーを、静的テーブルと動的テーブル（Dynamic Table）を用いて数バイトに圧縮するこの仕組みは、回線帯域の節約において神がかった働きをする。

しかし、このHPACKこそが `CONNECTION_ERROR` の最大の温床でもある。

HPACKは、クライアントとサーバーの双方が「まったく同一の動的テーブルの状態を維持していること」を絶対の前提としている。
例えば、サーバー側が最大動的テーブルサイズ（`SETTINGS_HEADER_TABLE_SIZE`）を動的に変更した際、その反映タイミングやインデックスの解釈にわずかなズレが生じるとどうなるか。

1. クライアントはインデックス番号 `62` を送る（サーバー側のテーブルでは古いエントリを指している）。
2. サーバー側では、すでにそのエントリがパージされているか、全く別の文字列に書き換わっている。
3. デコーダーがパニックを起こし、`COMPRESSION_ERROR` をスローする。
4. コネクション即座に切断。

この問題の厄介なところは、暗号化（TLS）のレイヤーのさらに内側（アプリケーションレイヤーの圧縮コンテキスト）で発生するため、中継するリバースプロキシやWAF（Web Application Firewall）がパケットを適切にインスペクションできない場合、原因不明の「突然のコネクションリセット」として観測されてしまう点にある。

—

4. 現場の防衛策：Linuxカーネルチューニングとプロキシの要塞化

では、こうした `CONNECTION_ERROR` の嵐から私たちのシステムを守り、極限のパフォーマンスを引き出すためには、どのようなインフラ設計とチューニングが必要なのだろうか。

単にアプリケーションコードを修正するだけでは不十分だ。TCPのトランスポート層、TLSハンドシェイク、そしてプロキシのバッファリング戦略までを統合的に最適化する必要がある。

① TCPバッファとウィンドウサイズの最適化（Linux sysctl）

HTTP/2は単一コネクション上で多重化を行うため、TCPのウィンドウサイズやバッファチューニングがスループットに直結する。特にBDP（Bandwidth-Delay Product）が大きい環境では、カーネルのバッファ枯渇がフローコントロールの破綻、ひいては `FLOW_CONTROL_ERROR` を誘発する遠因になり得る。

`/etc/sysctl.conf` に以下の設定を施し、TCPウィンドウのスケーリングとメモリ割り当てを最適化する。

TCP送受信バッファのデフォルト値と最大値を拡張 (単位: バイト)
高速回線やレイテンシの高い環境におけるパイプラインの目詰まりを防ぐ
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

ウィンドウスケーリングを有効化 (RFC 1323)
net.ipv4.tcp_window_scaling = 1

TIME_WAIT ソケットの再利用を許可し、高トラフィック時の枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1

② TLS 1.3とALPNによるハンドシェイクの極限最適化

HTTP/2は、事実上TLS（HTTPS）の上でしか動作しない（H2Cは実運用ではほぼ使われない）。ハンドシェイクのオーバーヘッドを極限まで削るため、TLS 1.3とALPN（Application-Layer Protocol Negotiation）の組み合わせが必須となる。

NGINXやEnvoyの設定において、ALPNの設定が漏れていると、クライアントはHTTP/2でのネゴシエーションに失敗し、予期せぬプロトコルフォールバックや切断を引き起こす。

以下は、Envoy Proxyにおける堅牢なHTTP/2およびTLS設定の断片である。

static_resources:
listeners:

name: https_listener

address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:

transport_socket:

name: envoy.transport_sockets.tls
typed_config:
“@type”: type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
common_tls_context:
tls_certificates:

certificate_chain: { filename: “/etc/ssl/certs/server.crt” }

private_key: { filename: “/etc/ssl/private/server.key” }
# ALPNで明示的に h2 (HTTP/2) と http/1.1 をサポートし、ネゴシエーションのミスを防ぐ
alpn_protocols: [“h2”, “http/1.1”]
filters:

name: envoy.filters.network.http_connection_manager

typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
http2_protocol_options:
# クライアントからの過剰な同時ストリーム数を制限し、メモリ枯渇やDDoSを防ぐ
max_concurrent_streams: 100
# 初期ウィンドウサイズを適切に設定し、フローコントロールエラーを抑制
initial_stream_window_size: 65536 # 64KB
initial_connection_window_size: 1048576 # 1MB
route_config:
name: local_route
virtual_hosts:

name: backend

domains: [“”]
routes:

match: { prefix: “/” }

route: { cluster: backend_service }
http_filters:

name: envoy.filters.http.router

typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

clusters:

name: backend_service

connect_timeout: 0.25s
type: LOGICAL_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: backend_service
endpoints:

lb_endpoints:
endpoint:

address:
socket_address: { address: 127.0.0.1, port_value: 8080 }

この設定において、`max_concurrent_streams` や `initial_stream_window_size` のチューニングは、`CONNECTION_ERROR`（特に `FLOW_CONTROL_ERROR` やリソース枯渇起因のエラー）を防ぐための防壁として機能する。クライアントが暴走しても、プロキシ側が適切な制限を設けていれば、システム全体が共倒れになるのを回避できる。

—

5. リカバリープロセスとクライアント側の実装哲学

サーバー側で `CONNECTION_ERROR` が発生し、`GOAWAY` が飛んできたとき、クライアント側（ブラウザやAPIクライアント、マイクロサービスのgRPCクライアントなど）はどのように振る舞うべきだろうか。

プロトコル仕様上、クライアントは以下のリカバリープロセスを踏む必要がある：

1. 新規ストリームの停止: `GOAWAY` の `Last-Stream-ID` より大きいIDを持つストリームはサーバーに処理されていないため、安全に再試行（リトライ）のキューに入れる。
2. 既存ストリームの継続処理: `Last-Stream-ID` 以下のストリームについては、サーバーからのレスポンスを待ち続けることができる（ただし、サーバーがすでにTCP RSTを送っていれば強制終了する）。
3. コネクションの再確立（Reconnection）: 新しいリクエストを発行するためには、新しいTCP/TLSコネクションを張り直す必要がある。

ここで注意すべきは、「無限リトライの罠（Thundering Herd）」だ。ネットワークの一時的な瞬断や、サーバー側の過負荷によって `CONNECTION_ERROR` が発生した際、クライアント群が一斉にコネクションを張り直してリクエストを再送すると、サーバーにさらなる負荷をかけ、再びエラーを引き起こすという悪循環（デス・スパイラル）に陥る。

そのため、クライアント側の実装においては、「ジッター（Jitter）を伴う指数バックオフ（Exponential Backoff）」を用いたリトライアルゴリズムが絶対条件となる。

—

結びに代えて

HTTP/2の `CONNECTION_ERROR` は、一見すると「冷徹で気難しいエラー」に見えるかもしれない。しかし、その背後にあるのは、バイナリの秩序を守り、単一コネクションの多重化という高密度な通信を安全に維持するための、極めて合理的で美しい設計思想にほかならない。

パケットが流れる瞬間のバイナリ構造、HPACKが紡ぐ動的テーブルの繊細な同期、そしてLinuxカーネルのバッファに至るまで、ネットワークの全層を俯瞰する視点を持つこと――それこそが、現代のインフラエンジニアやアーキテクトに求められる真の武器である。

プロトコルが発する微かなエラーコードの叫びに耳を傾け、パケットの往来を脳内で可視化できた時、あなたのネットワークは、どんな高負荷なトラフィックをも優雅にいなす要塞へと生まれ変わるはずだ。