【入門編】 TCPのコネクション切断プロセス(FINとRST) – ネットワーク基礎とWebセキュリティ実践ガイド

通信の終わらせ方を知る：TCPの「正常なバイバイ」と「強制切断」の裏側

こんにちは！ネットワークの世界へようこそ。

インフラエンジニアの現場で「通信が繋がらない」というトラブルが発生したとき、多くのエンジニアはまず ping を打ち、次に telnet や curl でポートの状態を確認しますよね。

でも、意外と見落とされがちなのが「通信をどう終わらせるか」というプロセスです。実は、Webページが正しく表示される裏側では、通信の始まりと同じくらい、「終わりの儀式」が非常に重要なんです。

今日は、TCPにおける「正常な終了（FIN）」と「強制的な切断（RST）」について、身近な例えを交えながらじっくり紐解いていきましょう。

—

1. 正常な終了：4ウェイ・ハンドシェイク（お互いの合意）

TCPの接続を終了するときは、いきなり電源をブチッと切るようなことはしません。お互いに「もう用事は済んだよね？」「ああ、私も終わったよ」と確認し合う、丁寧な4ウェイ・ハンドシェイクという手順を踏みます。

これは、「手紙のやり取り」に例えると分かりやすいですよ。

1. FIN（クライアント→サーバー）： 「もう送るものはないよ。これで終わりにしようか」
2. ACK（サーバー→クライアント）： 「了解。終了の合図は受け取ったよ」
3. FIN（サーバー→クライアント）： 「私も送るものは全部送ったから、これで接続を切るね」
4. ACK（クライアント→サーバー）： 「分かった、それじゃあお疲れ様！」

この4段階を経て、ようやくコネクションは綺麗に閉じられます。双方が「もう通信は発生しない」ということを合意してから切断するので、データが取り残されるリスクがない、非常に安全な方法なんです。

—

2. 強制的な切断：RST（「そんなの関係ない！」の合図）

一方で、何らかのトラブルが発生したときや、サーバーが許容量を超えてパンクしたときには、そんな悠長なことは言っていられません。そこで登場するのが RST （リセット）フラグです。

RST は、いわば「接続の即時破棄」です。

例えば、深夜のコールセンターに例えてみましょう。

正常な終了： 「長々とお付き合いいただきありがとうございました。それでは失礼します」と互いに挨拶して電話を切る。
RSTでの切断： 回線が切れたり、あまりに理不尽な要求で電話機を叩きつけるようにガチャ切りするイメージです。

RST が送られてくると、受け取った側は理由を問わず「あ、今は会話を継続できないんだな」と判断して、その場でセッションを強制終了させます。

現場でよく見るRSTのシーン

ポートが閉まっている： 存在しないポートにアクセスすると、サーバーは「そんな店は開いていないよ！」と RST を返してきます。
ファイアウォールの遮断： セキュリティポリシーによって通信が拒否されたとき、境界防御機器が「この通信は許可しない」と強制切断することがあります。

—

3. 実務で「パケット」を観察してみよう

現場で「通信が途中で切れる」というトラブルに遭遇した際、我々エンジニアは tcpdump というツールを使って、パケットのやり取りを直接覗き見ることがあります。

例えば、Linux環境で特定のサーバーへの通信をキャプチャしてみるコマンド例をご紹介します。

# eth0インターフェースで、80番ポートの通信をキャプチャする
# -n: 名前解決をしない（IPで表示する）
# -v: 詳細情報を出力する
sudo tcpdump -i eth0 port 80 -n -v

もし、ターミナル上に Flags [F] と表示されていれば、それは正常な終了（FIN）を意味します。しかし、もし Flags [R] が頻発しているなら、どこかで「強制切断」が起きているという立派なサインです。

—

4. 初学者が知っておくべき「RST」の教訓

初心者のうちは、RST が返ってくると「サーバーが壊れた！」と焦ってしまうかもしれません。でも、実はそうとは限りません。

タイムアウト： 通信が長すぎて、途中のルーターが「もうこのセッションは古いから切っちゃおう」と判断しただけかもしれません。
ロードバランサーの調整： 負荷分散装置が、サーバーの過負荷を防ぐために「一旦接続を切りなさい」と命令しただけかもしれません。

ネットワークは「生き物」です。パケットが届かないとき、RST は「なぜ断られたのか」を教えてくれる重要なヒントになります。

まとめ：一歩ずつ理解しよう！

1. FIN は「お互いの合意のもとで、綺麗に片付ける」ためのもの。
2. RST は「事態を即座に収拾し、リセットする」ための荒療治。

まずは「正常な流れ」を知り、その上で「異常な流れ（RST）」を観察できるようになると、トラブルシューティングの景色が全く違って見えてきます。

焦る必要はありません。まずは curl -v を使って、自分のブラウザとWebサーバーがどんなやり取りをしているのか、手元の環境から覗いてみることから始めてみてくださいね！

それでは、また次のネットワークの深淵でお会いしましょう。