TCPのコネクション解放に関するネットワークスペシャリスト試験午後Ⅱ形式問題

 TCPのコネクション解放（FIN、ACK、TIME_WAIT、CLOSE_WAITなどの状態遷移）に関する、ネットワークスペシャリスト試験午後Ⅱ風の長文シナリオ＋設問を10問用意します。

問題文は**午後Ⅱ形式（シナリオ→設問→解答→解説）**にしています。

---

TCPコネクション解放 午後Ⅱ形式問題集（10問）

---

問題1

以下は、Webサーバ（192.168.1.10）とクライアント（192.168.1.20）の間で行われたTCPセッション解放時のパケットキャプチャの一部である。

時系列は簡略化されている。

1. クライアント → サーバ : FIN, ACK

2. サーバ → クライアント : ACK

3. サーバ → クライアント : FIN, ACK

4. クライアント → サーバ : ACK

設問

(1) この通信終了の手順は、TCPの4ウェイハンドシェイクにおけるどのような流れか。

(2) 上記の状態遷移における、サーバ側がFINを送信する直前の状態は何か。

解答例

(1) 正常なTCPコネクションの4ウェイハンドシェイクによる終了手順。

(2) CLOSE_WAIT 状態。

解説

クライアントからFINが送られると、サーバはACKを返してCLOSE_WAIT状態に入り、アプリケーションが終了処理を行った後にFINを送る。その後、クライアントはACKを返しTIME_WAIT状態に入る。

---

問題2

以下のキャプチャでは、クライアントからのFINに対しサーバがACKのみを返し、その後FINを送るまで約30秒間の遅延があった。

設問

(1) サーバがFINを送るまでの遅延の原因として考えられるアプリケーション側の要因は何か。

(2) この遅延中のサーバのTCP状態は何か。

解答例

(1) アプリケーションプロセスが終了処理（ファイル書き込みやセッション後処理）を行っている。

(2) CLOSE_WAIT。

解説

CLOSE_WAITは、受信側アプリケーションがまだ終了処理を行っている状態。TCPレベルでは接続を半分閉じた状態になる。

---

問題3

サーバ側から先にFINを送った場合、クライアントがACKを返すまでの状態は何と呼ばれるか。

解答例

FIN_WAIT_1。

解説

FIN送信直後はFIN_WAIT_1状態。ACKを受け取るとFIN_WAIT_2に遷移し、相手からFINが来るのを待つ。

---

問題4

TCPのTIME_WAIT状態が60秒間続いた。これはOSの設定によるが、TIME_WAITが存在する理由として正しい説明はどれか。

A. ネットワーク負荷を軽減するため

B. 遅延して到着するパケットを受け入れないための安全時間を確保するため

C. ウイルス対策のため

D. ポート番号を固定するため

正解

B

解説

TIME_WAITは、遅延パケットが再度同じポート番号で誤って受信されるのを防ぐために一定時間待機する。

---

問題5

RSTフラグを用いてコネクションを強制的に切断した場合、TIME_WAIT状態は発生するか。

解答例

通常は発生しない。

解説

RSTは即時切断のため、4ウェイハンドシェイクを行わずTIME_WAITを経由しない。ただし送信側が最後のACK送信者であればTIME_WAITに入るケースもある。

---

問題6

クライアントからFINが送られたが、サーバがFINを返さず長時間CLOSE_WAIT状態が続く現象を何と呼ぶか。

解答例

CLOSE_WAITリーク。

解説

アプリケーションが終了処理を行わないままソケットを開き続ける不具合。リソース枯渇の原因となる。

---

問題7

キャプチャで、FIN送信後すぐにRSTが返ってきた。この挙動の原因として考えられるのは何か。

解答例

終了処理中にアプリケーションが強制終了された、またはポートが閉じられた。

---

問題8

TIME_WAIT状態が多数発生しているサーバで、新規接続ができなくなることがある。この原因と対策は何か。

解答例

原因: 同一ポート番号が再利用できない時間が長すぎる。

対策: TIME_WAIT短縮設定（tcp_tw_reuse等）やポート範囲拡大。

---

問題9

サーバからFINを送った後、相手からのACKを受信できずに再送を繰り返す場合、状態は何か。

解答例

FIN_WAIT_1。

---

問題10

TCPコネクション解放の3ウェイハンドシェイクと4ウェイハンドシェイクの違いを説明せよ。

解答例

3ウェイ: 双方が同時にFINを送る場合で、FINとACKを同一パケットにまとめる。

4ウェイ: FINとACKを別々に送信する。

---

正常系パケットキャプチャ

異常系（例：CLOSE_WAITリーク、RST切断、SYN/FIN混在など）パケットキャプチャ

TCP状態遷移図

午後Ⅱ形式の設問

比較問題

を1つの長文問題としてまとめます。

実際の試験のように説明→キャプチャ→図→設問の流れにします。

---

TCPコネクション解放 午後Ⅱ形式 総合問題

---

〔シナリオ〕

あるシステム管理者は、Webサーバ（192.168.10.10）とクライアント（192.168.10.20）の通信において、TCPコネクション解放に関するトラブルを調査している。

調査にはパケットキャプチャツールを用い、正常系と異常系の2種類のキャプチャを取得した。

また、TCP状態遷移図を参照して状態を確認した。

---

〔図1: TCP状態遷移図（抜粋）〕

ESTABLISHED

        |   FIN送信

        v

   FIN_WAIT_1 ------ ACK受信 ------> FIN_WAIT_2

        |                                    |

  FIN+ACK受信                               FIN受信

        |                                    |

        v                                    v

    CLOSING                               TIME_WAIT

        |

  ACK受信

        v

   TIME_WAIT

※ LISTEN, SYN_SENT 等の確立フェーズは省略

---

〔表1: 正常系キャプチャ（4ウェイハンドシェイク）〕

No 時刻 送信元IP 宛先IP フラグ 説明

1 0.000000 192.168.10.20 192.168.10.10 FIN, ACK クライアント→サーバ 接続終了要求

2 0.000120 192.168.10.10 192.168.10.20 ACK サーバ→クライアント 確認応答

3 0.050450 192.168.10.10 192.168.10.20 FIN, ACK サーバ→クライアント 終了要求

4 0.050580 192.168.10.20 192.168.10.10 ACK クライアント→サーバ 確認応答

---

〔表2: 異常系キャプチャ（CLOSE_WAITリーク）〕

No 時刻 送信元IP 宛先IP フラグ 説明

1 0.000000 192.168.10.20 192.168.10.10 FIN, ACK クライアント→サーバ 接続終了要求

2 0.000110 192.168.10.10 192.168.10.20 ACK サーバ→クライアント 確認応答

3 30.000000 （送信なし） （送信なし） ― サーバからFINが送られずCLOSE_WAIT継続

---

〔図2: 正常系と異常系の比較（状態遷移）〕

正常系:       ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED

異常系:       ESTABLISHED → CLOSE_WAIT （長時間停止） → （解放されず）

---

〔設問〕

設問1

表1に示す正常系のシーケンスは、TCPコネクション解放の何という手順で行われるか。

設問2

表2に示す異常系では、サーバがCLOSE_WAIT状態のまま長時間停止している。主な原因として考えられるアプリケーション側の問題を1つ挙げよ。

設問3

正常系で、クライアントが最後にACKを送信した後にTIME_WAIT状態に入る理由を説明せよ。

設問4

異常系のCLOSE_WAITリークが多発すると、サーバにどのような影響が生じるか。2つ挙げよ。

設問5

TCPのコネクション解放において、4ウェイハンドシェイクではFINとACKを別々に送る理由を説明せよ。

---

〔解答例と解説〕

解答1

4ウェイハンドシェイクによる正常なTCP接続終了手順。

解説

FINとACKを4回に分けて送受信し、双方がデータ送信を終了したことを確認する。

---

解答2

アプリケーションがソケットを閉じないままプロセスを維持している（終了処理が未実行）。

解説

TCPレベルでは接続終了要求を受け取っても、アプリケーションがclose()を呼ばない限りFINを送信できない。

---

解答3

遅延パケットが誤って次の接続に混入しないよう、一定時間待機するため。

解説

TIME_WAITは2×最大セグメント寿命(MSL)の時間だけ待機することで、古いパケットの混入を防ぐ。

---

解答4

ソケット数の枯渇

メモリリソース不足による新規接続拒否

解説

CLOSE_WAITリークは未解放ソケットを増やし、リソースを圧迫する。

---

解答5

一方向ずつ終了を確認するため。

解説

FINを送った側は、相手がまだデータ送信中かもしれないため、ACKとFINを同時送信せずに別パケットで送る。

---

TCPコネクション解放 午後Ⅱ形式 総合問題（完成版）

---

〔シナリオ〕

システム管理者は、Webサーバ（192.168.10.10）とクライアント（192.168.10.20）の通信終了時に発生する不具合を調査している。

調査ではパケットキャプチャを行い、正常系と3種類の異常系を取得した。

また、TCP状態遷移図を参照して解析を行った。

---

〔図1: TCP状態遷移図（解放フェーズ）〕

ESTABLISHED

        |  FIN送信

        v

   FIN_WAIT_1 ------ ACK受信 ------> FIN_WAIT_2

        |                                    |

  FIN+ACK受信                               FIN受信

        |                                    |

        v                                    v

    CLOSING                               TIME_WAIT

        |

  ACK受信

        v

   TIME_WAIT

異常例:

- CLOSE_WAIT長時間残留

- 同時FIN送信

- RSTによる強制切断

---

〔表1: 正常系（4ウェイハンドシェイク）キャプチャ〕

No 時刻 送信元IP 宛先IP フラグ 説明

1 0.000000 192.168.10.20 192.168.10.10 FIN, ACK クライアント→サーバ 接続終了要求

2 0.000120 192.168.10.10 192.168.10.20 ACK サーバ→クライアント 確認応答

3 0.050450 192.168.10.10 192.168.10.20 FIN, ACK サーバ→クライアント 終了要求

4 0.050580 192.168.10.20 192.168.10.10 ACK クライアント→サーバ 確認応答

---

〔表2: 異常系① CLOSE_WAITリーク〕

No 時刻 送信元IP 宛先IP フラグ 説明

1 0.000000 192.168.10.20 192.168.10.10 FIN, ACK クライアント→サーバ 終了要求

2 0.000110 192.168.10.10 192.168.10.20 ACK サーバ→クライアント 確認応答

3 30.000000 （送信なし） （送信なし） ― サーバからFINが送られずCLOSE_WAIT継続

---

〔表3: 異常系② 同時FIN送信（Simultaneous Close）〕

No 時刻 送信元IP 宛先IP フラグ 説明

1 0.000000 192.168.10.20 192.168.10.10 FIN, ACK クライアント→サーバ 終了要求

2 0.000005 192.168.10.10 192.168.10.20 FIN, ACK サーバ→クライアント 同時終了要求

3 0.000120 192.168.10.20 192.168.10.10 ACK クライアント→サーバ 確認応答

4 0.000125 192.168.10.10 192.168.10.20 ACK サーバ→クライアント 確認応答

---

〔表4: 異常系③ RSTによる強制切断〕

No 時刻 送信元IP 宛先IP フラグ 説明

1 0.000000 192.168.10.20 192.168.10.10 FIN, ACK クライアント→サーバ 終了要求

2 0.000050 192.168.10.10 192.168.10.20 RST, ACK サーバ→クライアント 強制切断

3 0.000060 （接続なし） （接続なし） ― コネクション消滅

---

〔比較図（正常系と異常系の状態遷移）〕

正常系:    ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED

CLOSE_WAIT: ESTABLISHED → CLOSE_WAIT （長時間停止）

同時FIN:   ESTABLISHED → CLOSING → TIME_WAIT → CLOSED

RST:       ESTABLISHED → CLOSED （即時）

---

〔設問〕

1. 表1の正常系で用いられる終了手順を何と呼ぶか。

2. 表2のCLOSE_WAITリークの原因となるアプリケーション動作の不備を説明せよ。

3. 表3の同時FIN送信では、状態遷移図上でどの状態を経由するか。

4. 表4のRSTによる切断は、どのような場合に用いられることが多いか。

5. TIME_WAIT状態を設ける理由を説明せよ。

6. CLOSE_WAITが多数発生すると、サーバにどのような影響があるか2つ挙げよ。

7. 同時FINと通常の4ウェイハンドシェイクとの違いを説明せよ。

8. RST切断が発生した場合、アプリケーション層のデータは必ず送信し終えるか。理由も述べよ。

9. CLOSE_WAITリークを解消するための運用・設計上の対策を2つ挙げよ。

10. 各異常系を検知するための監視指標（メトリクス）を3つ挙げよ。

---

〔解答例と解説〕

1. 4ウェイハンドシェイク

→ FINとACKを4回に分けて送信する接続終了手順。

2. アプリケーションがclose()を呼ばずソケットを閉じない。

→ TCPレベルではFINを送れない。

3. CLOSING状態。

→ 双方がほぼ同時にFINを送信するとCLOSINGを経由。

4. エラーや異常検知時の強制切断。

→ 不正パケットやアプリケーション異常時に多用される。

5. 古いパケット混入防止。

→ 2×MSL待機。

6. ソケット資源枯渇、新規接続不能。

7. 同時FINはCLOSING経由、通常はFIN_WAIT_1→2→TIME_WAIT。

8. 送信し終えない可能性がある。

→ RSTは即座に切断するためバッファ内データが失われる。

9.

アプリケーションの終了処理改善

ソケットタイムアウト設定

10.

netstatでの状態数監視

TIME_WAIT/CLOSE_WAIT比率

TCP接続数