こんにちは！技術メディア編集長の私です。
日々のWeb開発やインフラ構築、本当にお疲れ様です。ブラウザを開いて「パッと」ページが表示される裏側で、ブラウザとサーバーがどれだけ息の合った連携をしているか、考えたことはありますか？
特に今のWebの主役である「HTTP/2」の世界では、1本の太いパイプ（TCPコネクション）の中で、たくさんの荷物（データ）が同時に行ったり来たりしています。HTTP/1.1の時代のように「1つお願いして、返事が返ってくるまで待つ」なんてまどろっこしいことはせず、マルチプレクシング（多重化）という技術で、それはもう軽やかに通信が行われているんです。
でも、ちょっと待ってください。
「この通信、そろそろ終わりますね」 とか 「サーバーのメンテナンスだから、いったんお開きにしましょう」 というとき、このたくさんの荷物が飛び交うパイプを、どうやって安全に、きれいに片付ければいいのでしょうか？
今回は、HTTP/2の裏方としてめちゃくちゃ重要な役割を持つ「GOAWAY（ゴーアウェイ）フレーム」について、パケットの細かい暗号のような話はいったん置いておいて、身近な例えを交えながら優しく紐解いていきましょう！一歩ずつ理解していけば全然難しくありませんよ。それでは、出発進行です！
—
1. 郵便配達で例える「コネクションの終了」
まずはイメージを膨らませるために、現実世界に置き換えてみましょう。
あなたとお友達の間で、専用の「特急パイプライン（郵便シュート）」が1本だけ通っているとします。HTTP/2の世界では、このパイプラインを「コネクション」と呼びます。この1本のパイプの中に、手紙や荷物を入れる小さなカゴ（これが「ストリーム」です）をいくつもぶら下げて、同時に往復させています。
ある日、郵便局（サーバー）の営業時間が終わろうとしています。
ここで、もし郵便局がいきなり「シャッターをバーン！」と閉めたらどうなりますか？
- 「今まさに届くはずだった大事な荷物が床に落ちて壊れた！」
- 「まだ返事を書き途中だったのに、シュートが消えちゃった！」
これでは困りますよね。ネットワークの世界でも一緒です。サーバーが突然プツッと接続を切ってしまうと、クライアント側（ブラウザ）は「あれ？電波切れた？それともエラー？」と混乱してしまいます。
そこで登場するのが、「GOAWAYフレーム」という名の「丁寧なお断り・お片付けアナウンス」なんです。
—
2. GOAWAYフレームって、一体なにをしているの？
GOAWAYフレームは、サーバーからクライアントへ向かってこっそり流される、特別なコントロール信号（パケット）です。
サーバーは、コネクションを完全に切断する直前に、このGOAWAYを使ってクライアントにこう伝えます。
> 「お疲れ様です！このコネクションはそろそろ閉じますね。ここまで（例えばストリームID: 5まで）に受け付けた荷物は最後まで责任を持って処理しますが、これより新しい新しい荷物（ID: 7以降）をこのパイプに流すのはもうストップしてくださいね！」
この「どこまでの荷物を最後まで面倒見るか」を伝える境界線のことを、専門用語で「最後に見届けるID（Last-Stream-ID）」と言ったりします。
これにより、以下のような素晴らしいメリットが生まれます。
1. パニックが起きない: クライアントは「ああ、サーバーくん、今日は店じまいなんだな」と納得できる。
2. データの取りこぼしがない: 処理中のデータが途中でプツッと途切れるのを防ぎ、最後まで綺麗にやり取りを終えられる。
3. 無駄な労力を減らす: 「もうすぐ閉まるなら、新しいリクエストをこのパイプに流すのはやめておこう」と判断できる。
—
3. クライアント側の優しい「再接続（リトライ）」ロジック
さて、GOAWAYを受け取ったクライアント側はどう動くのでしょうか？
ただ「切断されたぁ、終わり！」と絶望するわけではありません。プロトコルは非常にスマートにできています。
サーバーから「このパイプはもう閉じるよ（GOAWAY）」と言われたクライアントの頭の中（プログラムの動き）を覗いてみましょう。
- 今処理中のもの: サーバーが「最後まで付き合うよ」と言ってくれているので、その結果が返ってくるのを大人しく待ちます。
- これから送りたかった新しいリクエスト: 「じゃあ、新しく別のパイプ（新しいTCPコネクション）を作り直して、そっちから送り直そう！」と判断します。
この「新しくコネクションを作り直してリクエストを送り出す仕組み」が、フロントエンドやバックエンドのHTTPクライアントライブラリ（例えば、Go言語の`net/http`や、Node.jsの各種クライアントなど）には標準で備わっています。
実際にコード（イメージ）で見てみよう
インフラやバックエンドでHTTP/2を扱う際、クライアント側のライブラリは、内部で次のようなロジックをこっそり動かしてGOAWAYに対応しています（※Go言語風の疑似コード）。
// クライアントがHTTP/2のレスポンスやイベントを監視しているループのイメージ
func handleHTTP2Connection(conn http2.ClientConn) {
for {
// サーバーからのメッセージを待ち受ける
frame := conn.ReadFrame()
switch f := frame.(type) {
case http2.GoAwayFrame:
// サーバーから「お片付けするよ（GOAWAY）」の通知を受け取った！
fmt.Printf(“サーバーからGOAWAYを受信しました。Last Stream ID: %d\n”, f.LastStreamID)
// 1. このコネクションに対する「新しいリクエストの追加」を即座に禁止する
conn.DisableNewStreams()
// 2. まだ完了していないストリーム（IDがLastStreamID以下のもの）の終了を待つ
// 3. 送り損ねた新規リクエストは、新しく張った別のコネクションへ自動で振り分ける（再接続）
go triggerReconnection()
return
case http2.DataFrame:
// 通常のデータ処理
processData(f)
}
}
}
このように、コードの裏側ではGOAWAYフレームをキャッチした瞬間に「新規受付停止 ＆ 別ルート（新コネクション）の準備」という優しくも素早いバトンタッチが行われているのです。
—
4. なぜこれがインフラエンジニアにとって重要なのか？
「へえ、裏でそんな挨拶をしてるんだ」で終わらせないのが、現場のエンジニアの面白いところです。このGOAWAYの挙動を知っていると、次のようなリアルな現場のトラブルでめちゃくちゃ役に立ちます。
事例：ロードバランサー（LB）の後ろでアプリサーバーをアップデートするとき
例えば、KubernetesのPodや、AWSのALB（Application Load Balancer）の後ろにあるWebサーバーをローリングアップデート（入れ替え）するシーンを想像してください。
古いバージョンのサーバーをパッと停止させたとき、もしそこにHTTP/2のコネクションが繋がしっぱなしだったら……？
雑にコンテナを落としてしまうと、クライアント側で「あれ、通信が急にエラーになった（RSTパケットによる強制切断）」という不吉なエラーログ（`RST_STREAM` や `GOAWAY` 不足による接続断エラー）がユーザーの画面に出てしまいます。
現代の優れたロードバランサーやプロキシ（Nginx, Envoy, ALBなど）は、サーバーを落とす前に「グレースフル・シャットダウン（優雅な終了）」として、必ずこのGOAWAYフレームをクライアントに送信してくれます。
- 「今すぐじゃなくていいから、今受けてるリクエストが終わったら静かに切ろうね」
- 「新しい接続は別の元気なサーバーに逃がそう」
この仕組みがあるおかげで、私たちはユーザーにエラー画面を見せることなく、シームレスにシステムの裏側をアップデートできるというわけです。インフラの裏側は、こうした「お互いの思いやり（プロトコル）」で満ちているんですね。
—
まとめ
いかがでしたでしょうか？今回はHTTP/2のコネクション終了を司る「GOAWAYフレーム」について紐解いてみました。
- GOAWAYフレームとは： 突然の断絶ではなく、「そろそろ店じまいするから、新しい注文はストップで、今受けてる分だけキレイに終わらせようね」というサーバーからの丁寧な事前アナウンス。
- クライアントの動き： 丁寧なアナウンスを受け取って、未処理の分を待ちつつ、次の用事は新しいパイプライン（再接続）でスマートに片付ける。
- 実務での価値： サーバーのアップデートや負荷分散（ロードバランシング）の際、ユーザーにエラーを意識させないための「グレースフル・シャットダウン」の要となっている。
ネットワークの世界も人間関係と同じで、「お互いに合図を送り合って、きれいにお別れする」というマナーがとっても大切なんですね。
次にブラウザでサクサクとWebページを見るときや、インフラのログで「GOAWAY」の文字を見かけたときは、「あ、今サーバーとクライアントが丁寧なお辞儀を交わしているんだな」と、パケットたちのドラマに思いを馳せてみてください。
それでは、また次回の技術解説でお会いしましょう！あなたのインフラ・開発ライフが、今日も快適なパケットで満たされますように。
コメント