HTTP/2の「静かなる断絶」：GOAWAYフレームが握るコネクション終了の真実と、現場のエンジニアが知るべき再接続の流儀
インターネットのインフラやWeb APIの設計に携わっていると、時として「なぜか突然、クライアントとサーバー間のコネクションがプツリと切れる」という現象に直面します。HTTP/1.1の時代であれば、`Connection: close` ヘッダーをやり取りして「じゃあ、これで！」と分かりやすくお別れできましたが、1本のTCPコネクション上で何十ものリクエストとレスポンスを同時に多重化（マルチプレクシング）するHTTP/2の世界では、そう単純にはいきません。
「今、まさに裏側で走っている重要な決済APIのストリームはどうなるんだ？」
「ロードバランサーがバックエンドをローリングアップデートした瞬間、クライアント側で謎のRST_STREAMエラーが頻発するのはなぜだ？」
今回は、HTTP/2におけるコネクションの優美にして厳格な終了メカニズム、「GOAWAYフレーム」の挙動について、現場のシニアエンジニアの視点から徹底的に紐解いていきましょう。教科書をなぞるだけでは見えてこない、パケットの裏側のリアルな挙動と、実践的なデバッグ・実装の作法を共有します。
—
1. なぜHTTP/2の終了には「GOAWAY」が必要なのか？
HTTP/1.1では、1つのTCPコネクションで同時にさばけるリクエストは原則として1つ（パイプライン化を除く）でした。そのため、接続を切りたいときは、送信側が「このリクエストを最後に閉じるよ」と伝えるだけで済みます。
しかし、HTTP/2の真骨頂はマルチプレクシングです。1本のTCPコネクションの中に、ID（奇数：クライアント発、偶数：サーバー発）で識別される無数の「ストリーム」が同時に同居しています。
ここで、サーバー側でメンテナンスやオートスケーリングによるスケールインが発生し、コネクションを閉じたいとします。もしTCPレベルでいきなり `FIN` パケットを送ってプツッと切断したらどうなるでしょうか？ クライアント側で「ちょうど今、レスポンスを待っている最中だったのに！」という未処理のストリームが路頭に迷い、アプリケーション層で致命的なエラー（データ不整合など）を引き起こします。
この悲劇を防ぐためにHTTP/2仕様（RFC 7540）が用意したのが、GOAWAYフレームです。
GOAWAYの核心：優雅なる「店じまいアナウンス」
GOAWAYフレームは、コネクションを強制切断するのではなく、「これ以降、新しいストリームの作成は禁止する。ただし、すでに受け付けた既存のストリームの処理は最後までやり遂げるから安心してくれ」という、サーバー（あるいはクライアント）からの極めて紳士的な「店じまい宣言」なのです。
—
2. GOAWAYフレームの内部構造と通信シーケンス
パケットアナライザー（Wiresharkや`nghttp2`のログなど）を覗くと、GOAWAYフレームには非常に重要な3つのパラメーターが含まれていることが分かります。
GOAWAYの主要パラメーター
1. Last-Stream-ID（最後のストリームID）:
これが最も重要です。このID以下のストリームはサーバー側で処理継続、あるいは処理済みとみなされますが、このIDより大きいストリームIDは、サーバー側では一切処理していない（無視された）と判断します。
2. Error Code（エラーコード）:
なぜコネクションを閉じるのかの理由です。
- `0x0 (NO_ERROR)`: 予定されたメンテナンスや負荷分散など、正常な終了。
- `0x1 (PROTOCOL_ERROR)`: プロトコル違反を検知した場合。
- `0x2 (INTERNAL_ERROR)`: サーバー側の予期せぬ内部エラーなど。
3. Additional Debug Data（追加デバッグデータ）:
人間が読めるエラーメッセージや、障害追跡用のバイナリデータ（オプション）。
正常終了時の通信シーケンス
[Client] [Server]
| |
|—- (Stream #1, #3) リクエスト送信 ————–>|
| |
| (メンテ開始検知)
|<--- GOAWAY (Last-Stream-ID: 3, Error: NO_ERROR) --|
| |
|---- (Stream #5) 新規リクエスト送信（※無視される）->|
| |
| (Stream #3の処理継続・完了)
|<--- (Stream #3) レスポンス返却 -------------------|
| |
|================== (コネクション切断) =============|
クライアントは、サーバーからGOAWAYを受信した瞬間、「Last-Stream-ID（この例では #3）」以下のストリームのレスポンスを待ちつつ、新規に発行するリクエストは「別の新しいTCPコネクション」を張ってそちらに流さなければならないというルールを遂行します。もし、このタイミングでLast-Stream-IDより大きい `#5` のようなストリームを同じコネクション上で送ろうものなら、サーバーはそれを処理できず、クライアント側で「あれ、レスポンスが返ってこないぞ」というタイムアウトの闇に突き落とされることになります。
—
3. 現場で泣かないための「クライアント再接続ロジック」実装
多くのモダンなHTTPクライアントライブラリやブラウザは、GOAWAYフレームの受信を裏側でハンドリングし、よしなに再接続を行ってくれます。しかし、独自にHTTP/2クライアントを実装している場合や、リバースプロキシ（EnvoyやNginx）とマイクロサービスの間の通信設計を行うアーキテクトは、このロジックを正確に理解しておく必要があります。
ここでは、実践的な視点として、PythonのHTTP/2ライブラリ（`h2`や`httpx`の挙動をイメージした概念コード）を用いて、GOAWAYを検知した際の正しい再接続とリトライの仕組みを見てみましょう。
実装例：GOAWAYハンドリングとセーフティリトライ（Python）
import h2.connection
import h2.events
import socket
import ssl
class RobustHTTP2Client:
def __init__(self, host: str, port: int):
self.host = host
self.port = port
self.sock = None
self.conn = None
self.init_connection()
def init_connection(self):
“””TCP接続を確立し、HTTP/2ハンドシェイクを行う”””
ctx = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
ctx.set_alpn_protocols([‘h2’])
raw_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.sock = ctx.wrap_socket(raw_sock, server_hostname=self.host)
self.sock.connect((self.host, self.port))
# h2ライブラリの初期化（クライアントモード）
self.conn = h2.connection.H2Connection()
self.conn.initiate_connection()
self.sock.sendall(self.conn.data_to_send())
def send_request(self, path: str):
“””リクエストを送信し、GOAWAYの影に怯えない堅牢な処理を行う”””
headers = [
(‘:method’, ‘GET’),
(‘:path’, path),
(‘:authority’, self.host),
(‘:scheme’, ‘https’),
]
# ストリームのオープンとヘッダー送信
stream_id = self.conn.get_next_available_stream_id()
self.conn.headers_sent(stream_id, headers)
self.sock.sendall(self.conn.data_to_send())
# サーバーからのイベントを監視
response_data = b””
goaway_received = False
while True:
data = self.sock.recv(65535)
if not data:
break
events = self.conn.receive_data(data)
for event in events:
if isinstance(event, h2.events.ResponseReceived):
# レスポンスヘッダーの受信
pass
elif isinstance(event, h2.events.DataReceived):
# レスポンスボディの受信
response_data += event.data
self.conn.increment_flow_control_window(event.flow_controlled_length, stream_id=event.stream_id)
elif isinstance(event, h2.events.StreamEnded):
# ストリームが正常終了
if not goaway_received:
return response_data
elif isinstance(event, h2.events.ConnectionTerminated):
# 【重要】サーバーからGOAWAYを受信した、またはコネクションが終了した
goaway_received = True
print(f”[WARN] サーバーからGOAWAYを受信しました。Last Stream ID: {event.last_stream_id}, Error Code: {event.error_code}”)
# 未処理（Last Stream IDより後）だった場合は、新しいコネクションでリトライが必要
if stream_id > event.last_stream_id:
print(“[INFO] このリクエストはサーバーに届いていません。再接続してリトライします。”)
self.init_connection()
return self.send_request(path) # 再帰的に再リクエスト
# 送信すべきデータがあれば送出
to_send = self.conn.data_to_send()
if to_send:
self.sock.sendall(to_send)
return response_data
— 実際の利用イメージ —
client = RobustHTTP2Client(“api.example.com”, 443)
data = client.send_request(“/v1/users/profile”)
このコードのポイントは、`ConnectionTerminated`（GOAWAY）イベントをキャッチした際に、自分が投げた `stream_id` とサーバーが最後に処理したと宣言した `last_stream_id` を比較している点です。もし自分のストリームIDの方が大きければ、「サーバーはそのリクエストを端から受けていない」ため、安全に新しいTCPコネクションを張り直してリクエストを再送（リトライ）することができます。
—
4. インフラ・SRE運用の現場で役立つ実践Tips
最後に、ロードバランサーやリバースプロキシ（Nginx、Envoy、ALBなど）を運用するインフラエンジニアに向けて、現場でありがちなトラブルと対策を共有します。
1. ローリングアップデート時の「急激な切断」を防ぐ
Kubernetes環境などでポッドのスケールインやアップデートを行う際、プロキシがバックエンドコンテナとのHTTP/2コネクションをいきなり切断すると、クライアント側で `RST_STREAM` が頻発します。
- 対策: アップデート前には、リバースプロキシ側から適切に `NO_ERROR` の GOAWAY フレームが送出されるよう、グレースフル・シャットダウン（Graceful Shutdown）のタイムアウト設定（例: Nginxの `worker_shutdown_timeout` や Envoyの `drain_timeout`）を十分に長くとりましょう。バックエンドが古いコネクション上で既存リクエストを処理し切る時間を確保するのがプロの作法です。
2. HTTP/2プッシュやロングポーリングでのGOAWAYの罠
HTTP/2のサーバープッシュや、Server-Sent Events (SSE) をHTTP/2上で長期間維持している場合、インフラのキープアライブ設定（アイドルタイムアウト）によって、突然サーバーからGOAWAYが飛んでくることがあります。
- 対策: クライアント側（特にフロントエンドのJavaScriptやモバイルアプリ）では、GOAWAYやコネクションロストを検知した際に、指数バックオフ（Exponential Backoff）アルゴリズムを用いたスマートな再接続ロジックを必ず組み込んでおきましょう。無駄な高頻度リトライは、障害中のサーバーにとどめを刺す「DDoS攻撃」になりかねません。
—
まとめ
HTTP/2のGOAWAYフレームは、単なる「エラー通知」ではありません。それは、マルチプレクシングという複雑な通信の森の中で、クライアントとサーバーが秩序を保ち、お互いの処理の整合性を守るための「洗練された合意形成のプロトコル」です。
インフラの裏側で何が起きているのか、パケットレベルの挙動とフレームの意図を正しく理解していれば、突発的なエラーログに慌てふためくこともなくなります。今日の知識が、あなたの設計するシステムの堅牢性を一段と引き上げる一助となれば幸いです。
コメント