こんにちは！ネットワークの世界へようこそ。インフラ・プロトコルスペシャリストの私と一緒に、今日も熱い技術の話を紐解いていきましょう。
皆さんは普段、何気なくスマホやパソコンでウェブサイトを見ていると思いますが、その裏側ではブラウザとサーバーがものすごい勢いで会話を交わしています。その共通言語が「HTTP」ですよね。
現代の主流である「HTTP/2」は、1本の太いパイプライン（TCPコネクション）の中で、複数の荷物を同時に効率よくやり取りする「マルチプレクシング」という魔法のような技術を持っています。昔のHTTP/1.1に比べて圧倒的にスピードが上がった立役者ですが、この「超高速道路」であるがゆえの、ちょっとシビアなルールが存在します。
それが今回テーマにする「コネクションレベルのエラー（CONNECTION_ERROR）」です。
「エラー」と聞くと難しそうに聞こえますが、一歩ずつ、私たちの身近な例えから優しく紐解いていきましょう！
—
1. 郵便配達で例える「コネクションエラー」の世界
HTTP/2の通信を、よくある「郵便配達システム」に例えてみましょう。
HTTP/2のコネクション（接続）は、あなたのお家と郵便局を結ぶ「たった1本の専用道路」のようなものです。この道路を行き交う荷物（データ）は、すべて小さな箱（ストリーム）に入れられ、整理番号が振られています。
通常、配達員同士やあなたと郵便局の間には「ルールブック」があります。
- 「荷物は必ず指定されたサイズの箱に入れてね」
- 「赤い荷物を送るときは、事前にこういう手続きをしてね」
もし、あなたがこのルールを完全に無視して、「ルールブックに載っていない巨大すぎる謎の箱」をいきなり郵便局の窓口にドカンと置いたとしたらどうなるでしょうか？
郵便局の窓口の人は、「おいおい、このルール違反の荷物を置かれたら、他のまじめな人たちの仕分け業務が全部ストップしてしまうぞ！危険だ！」と判断しますよね。そして、あなたとの信頼関係を完全に破棄し、こう叫ぶはずです。
「もうあなたとの取引は一切禁止！この専用道路の契約を今すぐブチッと切断します！」
これが、HTTP/2におけるコネクションレベルのエラー（`CONNECTION_ERROR`）の正体です。
—
2. なぜ「コネクション」ごと切断されてしまうのか？
HTTP/2の前身であるHTTP/1.1では、もし1つのリクエストでおかしなことが起きても、そのやり取りをしているタブや接続だけが影響を受けることがほとんどでした。
しかし、HTTP/2は「1本のコネクションを、みんなでシェアして超高速に使う」というアプローチをとっています。
ここで一人のユーザー（またはプログラムのバグ）が、プロトコル違反の不正なデータ（フレーム）を送り込んできたらどうでしょう？
シェアしている道路全体が汚染され、後ろを走る他の正しいデータたちの安全や秩序まで脅かされてしまいます。そのため、HTTP/2の設計者たちはこう考えました。
> 「一部を救おうとして全体が崩壊するくらいなら、ルールの外れた奴とは即座に縁を切って（コネクションを切断して）、全体の安全を守ろう」
これが、ストリーム単位の細かいケンカ（単なるリクエスト失敗）ではなく、コネクションそのものを強制終了させる大ナタが振るわれる理由です。
—
3. どんな時に「CONNECTION_ERROR」が起きるの？
現場のエンジニアがデバッグをしていると、次のようなシチュエーションでこのエラーに遭遇しがちです。一歩ずつ見ていきましょう！
① 不正なフレームの受信（PROTOCOL_ERROR）
HTTP/2の世界では、データは「フレーム」というカプセルに入れられて流れます。このフレームには厳しい順番やルールがあります。例えば、「まだコネクションが確立していないのに、いきなりデータを送りつける」といったルールの逸脱があると、サーバーは `PROTOCOL_ERROR` という罪状でコネクションを断ち切ります。
② 圧縮ルールの崩壊（COMPRESSION_ERROR）
HTTP/2には、ヘッダーの情報を小さく圧縮して送る「HPACK（エスパック）」という技術があります。これは、送信側と受信側で「辞書」を共有しながら会話する高度な仕組みです。
もし、送信側が勝手に「うちの辞書にはない単語番号」を使ってヘッダーを圧縮し、受信側が「そんな単語、私の辞書には載ってないよ！意味が分からない！」となった場合、会話が成り立たなくなるため、容赦なく `COMPRESSION_ERROR` が発生してコネクションがプツリと切れます。
—
4. 実際にパケットの中で何が起きているのか？
エラーが発生したとき、サーバーは黙ってプップと回線を切るわけではありません。ちゃんと「お別れの挨拶（GOAWAYフレーム）」を送信してくれます。
実際のネットワーク上（パケット解析ソフトなど）では、以下のようなやり取りが起きています。
[クライアント] —————————— (不正なフレーム送信) —————————–> [サーバー]
[クライアント] <----------------------------- (GOAWAYフレーム送信) ------------------------------ [サーバー] ※エラーコード: PROTOCOL_ERROR (0x1) ※「これ以上あなたとは通信できません。このコネクションを閉じます」 ここで、サーバーから送られてくる `GOAWAY` フレームの中身を、実務でよく見る設定やログの形式っぽく覗いてみましょう。 { "frame_type": "GOAWAY", "last_stream_id": 5, // 最後に正常に処理できた（あるいは処理しようとした）ストリーム番号 "error_code": 0x1, // PROTOCOL_ERROR（プロトコル違反を示すエラーコード） "debug_data": "Invalid magic string or frame sequence detected." // 開発者向けの泣けるメッセージ } このように、サーバーは「どのストリームまでがセーフで、どこからアウトだったのか」をきちんと記録（`last_stream_id`）した上で、コネクションの幕引きを行います。 ---
5. 現場でこのエラーに出くわしたときのリカバリープロセス
もしあなたが開発やインフラの運用中で、「なんだか急に通信が切れるぞ」「ログに `CONNECTION_ERROR` が出ているぞ」となったときは、どうリカバリーすればよいでしょうか？
あわてず騒らず、次のステップで原因を特定していきましょう！
1. クライアント側のライブラリやプロキシを疑う
自作のクライアントプログラムや、古くてアップデートしていないHTTP/2ライブラリを使っていませんか？ 意外と「ライブラリのバグで不正なフレームを生成してしまっていた」というケースが現場ではよくあります。
2. パケットキャプチャ（Wireshark等）で「最後の会話」を見る
Wiresharkなどで通信をキャプチャし、切断される直前にどんなフレーム（SETTINGS、HEADERSなど）が流れていたかを追跡します。サーバーが「ここがルール違反だよ」と教えてくれているエラーコード（HEX値）を確認するのが一番の近道です。
3. プロキシやロードバランサーの設定を見直す
間に挟まっているNginxやEnvoy、AWSのALBなどのタイムアウト設定や、HTTP/2の最大同時ストリーム数の制限などが原因で、お互いの意思疎通がズレてしまっていないかも確認ポイントです。
—
おわりに
いかがでしたでしょうか？
HTTP/2のコネクションレベルのエラー（`CONNECTION_ERROR`）は、一見すると冷徹で乱暴な切断に見えますが、実は「全体の安全と秩序を守るための、プロトコルとしての賢い防衛策」なのです。
郵便配達の例えを思い出せば、「ルールを破る荷物は、全体の麻痺を防ぐために即座にお断りする」という設計思想がとても自然に感じられるのではないでしょうか。
ネットワークやプロトコルの世界は、こうした「お互いの信頼とルール」の積み重ねで美しく動いています。次にエラーログで見かけたときは、「おっ、ルール違反を未然に防いでシステムを守ってくれているんだな」と、ちょっとだけ優しく見守ってあげてくださいね。
それでは、また次回の技術解説でお会いしましょう！インフラストライカーの私でした。
コメント