はじめに：FINとRSTの「美学」と「暴力」
おい、最近Web APIのタイムアウトや、リバースプロキシのログで見慣れないエラーに頭を抱えていないか？ 「突然コネクションがリセットされました」「原因不明の接続断が頻発する」――そんな夜、お前はパケットキャプチャを開き、流れるデータの波を見つめることになる。
ネットワークの世界において、通信の「始まり（3ウェイ・ハンドシェイク）」は誰もが教科書で学ぶ。だが、「終わり」の美学と暴力をどれだけ深く理解しているかが、プロのインフラエンジニアと素人を分ける分水嶺だ。
今回は、TCPのコネクション切断における二つの顔、すなわち紳士的な合意形成である「FIN（正常切断）」と、問答無用でケーブルを引き抜くような「RST（異常切断）」について、現場のリアルな挙動を交えて徹底的に紐解いていこう。API設計やインフラチューニングで明日から使える実践的な知見を叩き込むから、心して聞いてくれ。
—
1. 正常終了のシナリオ：FINフラグによる4ウェイ・ハンドシェイク
まずは、お互いが「もう送るデータはないね、きれいにお片付けしようか」と握手を交わす正常な切断プロセス、いわゆる4ウェイ・ハンドシェイクの軌跡を追う。
パケットが織りなす「美しき4ステップ」
WebブラウザがAPIサーバーからデータをすべて受け取り、ブラウザ側（あるいはサーバー側）から切断を開始するときのシーケンスはこうだ。
1. 第1ステップ (FIN): 「こっちはもう送信データがないよ」と伝えるため、クライアントが FIN フラグを立てたパケットを送信する。
2. 第2ステップ (ACK): サーバーは「FINを受け取ったよ、ちょっと待ってね」と ACK を返す。（この瞬間、クライアントからサーバーへの方向の通信だけが閉じる「ハーフクローズ状態」が生まれる）。
3. 第3ステップ (FIN): サーバー側も送信すべきレスポンスの残りがなければ、「こっちからも切断するね」と FIN フラグを立てたパケットをクライアントに送る。
4. 第4ステップ (ACK): クライアントが「了解、お疲れ！」と最後の ACK を返し、コネクションの墓石（TIME_WAIT状態）が立つ。
[Client] [Server]
| |
|---- [FIN, ACK] seq=X, ack=Y ----------------------->| 1. クライアントから切断要求
|<--- [ACK] seq=Y, ack=X+1 ----------------------| 2. サーバーが受領応答
| |
|<--- [FIN, ACK] seq=Y, ack=X+1 ----------------------| 3. サーバーから切断要求
|---- [ACK] seq=X+1, ack=Y+1 -------------------->| 4. クライアントが受領応答
| |
(TIME_WAIT状態へ) (即座に解放)現場の落とし穴：TIME_WAIT地獄とソケット枯渇
ここでシニアとして一つ、現場の苦い教訓を教えておこう。4ウェイ・ハンドシェイクの最後に、切断を主導した側（通常はクライアント、あるいはHTTP/1.1のKeeAlive切断時はサーバー側）には TIME_WAIT というステータスが残る。
これは、最後の ACK がロストしたときに備えて、一定時間（通常OSデフォルトで60秒など）ポートを占有し続ける仕組みだ。だが、高負荷なWeb APIサーバーでこれを放置するとどうなるか？ 瞬く間に利用可能なローカルポートが枯渇し、新しいコネクションが張れなくなる Cannot assign requested address という悪夢のパニックを引き起こす。
これを回避するため、インフラエンジニアはカーネルパラメータを調整する。例えばLinuxであれば、/etc/sysctl.conf に以下のような設定を施すのが定石だ。
# TIME_WAITソケットの再利用を有効化（安全性が担保できる環境下で）
net.ipv4.tcp_tw_reuse = 1
# 孤立したソケットの最大保持数を定義し、メモリ枯渇を防ぐ
net.ipv4.tcp_max_tw_buckets = 5000—
2. 異常終了のシナリオ：RSTフラグによる即時切断
次に、理不尽で容赦ない「RST（Reset）」の世界だ。4ウェイ・ハンドシェイクのようなお上品な手続きは一切踏まない。パケットに RST フラグが立った瞬間、コネクションは問答無用で強制切断され、ソケットは即座に消去される。
なぜRSTが飛んでくるのか？（代表的な3つの原因）
現場で Connection reset by peer というエラーに直面したとき、背後では大体以下のいずれかが起きている。
1. 存在しないポートへのアクセス: ファイアウォールの向こう側などで、誰もリスニングしていないポートにSYNパケットやデータパケットを送りつけた場合。OSは即座にRSTを返す。
2. 異常な切断（アボート）: アプリケーションがクラッシュしたり、プロセスが強制終了されたりして、OSがソケットを保持できなくなったとき。
3. ファイアウォールやLBによる強制切断: ステートフルインスペクションを行うロードバランサー（Nginx, AWS ALBなど）やセキュリティアプライアンスが、タイムアウトやポリシー違反を検知して、双方の通信の間に割って入り、両端にRSTをブッ放すケース。
特に3つ目はWeb API開発者泣かせだ。例えば、クライアントとバックエンドAPIの間に挟まったNginxの proxy_read_timeout が切れた瞬間、Nginxはバックエンドとクライアントの双方にRST（またはFINからの強制切断）を送りつける。この挙動を理解していないと、「フロントエンドからは504 Gateway Time-outに見えるが、パケットレベルでは何が起きたのか」の本質を見誤る。
—
3. 実務で役立つ！コードとデバッグ手法
机上の空論はここまでにして、実際に手を動かしてこれらの挙動を観測・制御する方法を見ていこう。
PythonによるRST検知とソケット切断のシミュレーション
Pythonの socket ライブラリを使い、あえて行儀の悪い切断（RSTの誘発）をコードで表現してみる。L4レベルの挙動を掴むのに最適だ。
import socket
import sys
def simulate_tcp_connection(host, port):
try:
# ソケットを作成
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 【Tips】SO_LINGERを設定し、close()時にFINではなくRSTを飛ばす暴力的な設定
# l_onoff = 1, l_linger = 0 にすると、残存データ破棄してRSTで即死させる
s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, b'\x01\x00\x00\x00\x00\x00\x00\x00')
print(f"Connecting to {host}:{port}...")
s.connect((host, port))
# 接続直後に容赦なく切断（RSTが送出される）
s.close()
print("Connection aborted with RST successfully.")
except Exception as e:
print(f"Error occurred: {e}", file=sys.stderr)
if __name__ == "__main__":
# ローカルの適当なポートを指定してテストしてみよう
simulate_tcp_connection("127.0.0.1", 8080)curlとtcpdumpを用いたパケットキャプチャの実践
インフラの現場で障害シューティングをする際、言葉よりも雄弁に語るのは tcpdump と Wireshark だ。
例えば、特定のAPIエンドポイントに対して、どのようにFIN/RSTがやり取りされているかをCLIで覗き見るには、以下のように tcpdump を仕掛ける。
# 8080番ポートで行われている通信のパケットヘッダ（フラグ含む）をリアルタイムでキャプチャ
sudo tcpdump -nnvvS -i any port 8080この状態で、別のターミナルから curl でリクエストを投げ、あえてタイムアウトや切断を起こしてみる。出力結果の中に [F]（FIN）や [R]（RST）というフラグの頭文字が見つかるはずだ。
# タイムアウトを極端に短くしてAPI叩き、ロードバランサー等からの切断を誘発する例
curl -m 0.001 https://api.example.com/heavy-process運が良ければ（あるいは悪ければ）、クライアント側で curl: (28) Operation timed out after 1 milliseconds with 0 out of 0 bytes received と共に、裏でOSがRSTを受け取っている様子が想像できるだろう。
—
4. シニアからの実践的Tips：API設計とインフラ構築への落とし込み
最後に、このTCPの切断プロセスを理解しているエンジニアが、実際のシステム設計でどう立ち回るべきかの極意を授けよう。
1. Keep-Aliveのタイムアウト値は「フロント < バックエンド」にせよ:
Nginxなどのリバースプロキシと、その後ろにあるアプリケーションサーバー（Node.js, Unicorn, Gunicornなど）の間でKeep-Aliveのタイムアウト設定が逆転していると、アプリ側が先にコネクションをFINで閉じているにもかかわらず、プロキシ側がそれに気づかずに古いコネクションへリクエストを投げ、結果としてサーバーから RST を食らうという悲劇（Connection reset by peer の頻発）が起きる。プロキシ側のタイムアウトを常に短く（厳しく）設定するのが鉄則だ。
2. クライアント側のコネクションプールを適切に管理せよ:
フロントエンドのJS（Fetch APIやAxios）やマイクロサービス間のHTTPクライアントで、リクエストごとにコネクションを切断（Connection: close）していると、毎回3ウェイ・ハンドシェイクと4ウェイ・ハンドシェイク（TIME_WAITの発生）のオーバーヘッドが乗る。コネクションプーリングを有効にし、適切なアイドルタイムアウトを設定して、FINの嵐を防ぐことがスケーラビリティの鍵となる。
おわりに
ネットワークのパケットは嘘をつかない。アプリケーション層でどれだけ美しいJSONをやり取りしていようとも、その足元を支えているのは、こうした泥臭いフラグの旗揚げ合戦、そしてコネクションの生生しい生成と消滅だ。
「なぜこのエラーが出るのか？」と迷ったときは、コードの表面だけでなく、レイヤーを一つ下げてTCPのセッションがどう終わったのか――FINで綺麗に散ったのか、RSTで無慈悲に引き剥がされたのかを想像してほしい。その視点を持てたとき、お前はもう一段上のエンジニアになっているはずだ。さあ、ログとパケットに向き合いに行こうか。
コメント