綜合演習 — 以封包的視角解讀 TCP 的行為

立即的 refused 是 RST 回來的證據 — 已送達主機，卻沒有程式在那個連接埠等待（行程未啟動、連接埠號錯誤等）。沉默到底的逾時是沒有回應回來 — 路徑中斷、主機停機，或默默丟棄的防火牆。從 A 的存在可以縮小到「主機活著、問題在連接埠」「與 B 之間的路徑某處被阻斷」。有送達的拒絕，與沒送達的沉默 — 第 2 章切分的定式。

TIME_WAIT 是先送出 FIN 的一方，為了最後一個 ACK 的保險與舊區段的排毒而留下的正常狀態（第 2 章）。每秒建立又丟棄數百條短命連線，光是數十秒的滯留就會累積成數萬條。危害在於連線資源（連接埠等）的消耗，根本對策是不要每次重新建線而是重複使用。不是「消除異常狀態」，而是「修正讓正常狀態大量發生的設計」，這才是正解。

TCP 本身可以無限期維持閒置的連線（只要兩端的帳本還在就好 — 第 2 章）。但路徑上的防火牆或 NAT 持有以四元組為單位的狀態表，會把持續閒置的項目以逾時刪除。之後送達的區段就成了「所屬不明」，被丟棄或回以 RST。對策是用 TCP keep-alive 或應用層的定期存活確認，持續展示「還在使用中」。若是深夜的壅塞，應該會先看到遺失或重傳。

零視窗 + 視窗探測的組合，是「接收緩衝區已滿，所有人都在等應用程式用 recv 讀走」這個狀態的教科書級封包擷取（第 4 章）。網路只是正確地傳遞了煞車，犯人是接收端應用程式的處理堵塞（磁碟寫入太慢、GC、鎖等）。若是遺失或壅塞，應該會看到重傳或重複 ACK，是和視窗 0 不同的風景。

中途截斷（切割）與相連（合併）兩者都出現，是「1 recv = 1 訊息」前提的典型症狀（第 6 章）。TCP 完全守住了位元組序列與順序，網路與協定都沒有異常。重試只是重複錯誤的切法而已。邊界由應用程式建立 — 導入 framing 並修改為「攢著、切出、留到下次」的迴圈，是唯一的根治之道。

幾乎沒有重複 ACK + 沉默後的重傳，不是快速重傳而是 RTO 滿期型的重傳（第 3 章）。此時 TCP 判斷為重症，把 cwnd 退回 1 MSS，從慢啟動重新開始（第 5 章）。恢復要花好幾個 RTT，體感就是「卡住數秒後又慢吞吞地起步」的反覆。與重複 ACK 型（減半後繼續）症狀與嚴重度都不同 — 分辨重傳的型，是效能問題解讀的分水嶺。