総合演習 — TCP の動きをパケットの気持ちで読み解く

即座の refused は RST が返った証拠 — ホストには届いているのに、そのポートで誰も待ち受けていない（プロセス未起動、ポート番号違いなど）。沈黙の末のタイムアウトは応答が返ってこない — 経路断、ホスト停止、または黙って捨てるファイアウォールです。A の存在から「ホストは生きていてポートに問題」「B との経路のどこかで遮断」まで絞れます。届いた上での拒否と、届かない沈黙 — 第 2 章の切り分けの型です。

TIME_WAIT は先に FIN を送った側が、最後の ACK の保険と古いセグメントの毒抜きのために残る正常な状態です（第 2 章）。短命接続を秒間数百件も張り捨てれば、数十秒の滞留だけで数万件になります。害はコネクション資源（ポートなど）の消費で、根本対策は接続を毎回張り直さず使い回すこと。「異常な状態を消す」のではなく「正常な状態が大量発生する設計を直す」と読むのが正解です。

TCP 自体はアイドルのコネクションを無期限に維持できます（両端の帳簿が残っていればよい — 第 2 章）。しかし経路上のファイアウォールや NAT は 4 つ組ごとの状態表を持っており、アイドルが続いた項目をタイムアウトで消します。その後に届いたセグメントは「所属不明」となり、破棄や RST になります。対策は TCP キープアライブやアプリ層の定期的な生存確認で「使っている」と見せ続けることです。深夜の混雑ならロスや再送が先に見えるはずです。

ゼロウィンドウ + ウィンドウプローブの組は「受信バッファが満杯で、アプリが recv で読み出すのを全員が待っている」という状態の教科書的なキャプチャです（第 4 章）。ネットワークは正しくブレーキを伝えているだけで、犯人は受信側アプリの処理詰まり（ディスク書き込みの遅さ、GC、ロックなど）。ロスや輻輳なら再送や重複 ACK が見えるはずで、ウィンドウ 0 とは別の景色になります。

途中で切れる（分割）と連結（結合）が両方出ているのは、「1 recv = 1 メッセージ」前提の典型症状です（第 6 章）。TCP はバイト列と順序を完全に守っており、ネットワークにもプロトコルにも異常はありません。リトライは壊れた切り出しを繰り返すだけです。境界はアプリが作る — フレーミングの導入と「貯めて・切り出して・持ち越す」ループへの修正が唯一の根治です。

重複 ACK がほぼ無い + 沈黙の後の再送は、高速再転送ではなくRTO 満了型の再送です（第 3 章）。このとき TCP は重症と判断し、cwnd を 1 MSS に戻してスロースタートからやり直します（第 5 章）。回復に何 RTT もかかるため、体感は「数秒固まってはノロノロ走り出す」の繰り返しに。重複 ACK 型（半減で続行）とは症状も深刻度も違う — 再送の型を見分けることが、性能問題の読みの分かれ目です。