TCPコネクション切断（4-Way Close）

📌

4ウェイクローズとは

4ウェイクローズは、TCP接続を安全に終了するための4パケット交換プロセスです。FIN（終了通知）とACK（確認応答）を双方向でやり取りし、データの取りこぼしなく接続を閉じます。電話を切る場面に例えてみましょう。もし一方的にガチャ切りしたら、相手は「まだ話の途中だったのに」と困りますよね？ だからお互いに確認し合ってから電話を切る必要があります。

なぜ4パケットも必要なのでしょうか？ TCPは全二重通信（Full-Duplex）、つまりクライアント→サーバー方向とサーバー→クライアント方向の2つの通信路が同時に存在します。各方向を独立して閉じる必要があるため、送信側の終了通知（FIN）と受信側の確認応答（ACK）が2セット、合計4パケットが必要になります。もし2パケットで済ませてしまうと、片方がまだ送りたいデータを持っている場合にデータが失われてしまいます。Webブラウザでタブを閉じたとき、裏側ではこの4パケット交換が行われています。Nginxのようなwebサーバーのアクセスログでは、1秒間に何千回もの4ウェイクローズが実行されています。普段は意識しませんが、インターネット通信の信頼性を支える重要な仕組みです。上のツールで「通常切断（4ウェイ）」シナリオを再生すると、FIN→ACK→FIN→ACKの流れが確認できます。特にクライアントとサーバーの状態（FIN_WAIT_1、CLOSE_WAIT等）がステップごとに変わる点に注目してください。

📌

特徴

• 🔄双方向独立終了：送信側と受信側を個別に閉じるため、片方だけ閉じて残りのデータを受信する「半クローズ（Half-Close）」が可能です。たとえば、クライアントがHTTPリクエストを送り終えた後（FIN送信）、サーバーからの大量のレスポンスデータを引き続き受信できます。データベースのクエリ結果が巨大な場合や、ファイルダウンロード時にこのパターンが使われます。上のツールで「半クローズ」シナリオを選択すると、FIN送信後もサーバーがデータを送り続ける様子が確認できます。
• ⏳TIME_WAIT安全策：最後のACK送信後、2MSL（Maximum Segment Lifetime × 2、通常60秒〜120秒）の間待機します。なぜこの待機が必要かというと、最後のACKがネットワーク上で消失した場合、サーバーがFINを再送する必要があるからです。もしクライアントがすぐにCLOSEDになっていたら、サーバーのFIN再送に応答できません。また、古い接続の遅れたパケットが新しい接続に誤って届くことを防ぐ役割もあります。
• ⚡RST即座切断：異常時にはRST（Reset）パケット1つで即座に接続を切断できます。4パケット交換もTIME_WAIT待機も不要です。ただし、未送信データは即座に破棄されるため、データロスの可能性があります。プロセスのクラッシュ、存在しないポートへの接続、ファイアウォールによる接続拒否などで発生します。上のツールで「RST強制切断」シナリオを選択すると、わずか1パケットで接続が終了する様子が確認できます。
• 📊状態遷移管理：クライアントはESTABLISHED→FIN_WAIT_1→FIN_WAIT_2→TIME_WAIT→CLOSEDと遷移し、サーバーはESTABLISHED→CLOSE_WAIT→LAST_ACK→CLOSEDと遷移します。各状態で受け付けるパケットが厳密に決まっており、不正なパケットは無視されます。netstat コマンドで netstat -an | grep TIME_WAIT と実行すると、実際にTIME_WAIT状態の接続を確認できます。

📌

ユースケース

📌

用語解説

📌

切断の手順

TCP接続の切断に必要な4つのステップを追いかけます。

📌

TIME_WAITとRST

TIME_WAITの理由

通常切断 vs RST強制切断