TCP/IP 深度解析：
從握手到揮手的旅程
為什麼網路傳輸需要這麼繁雜的步驟？深入探討可靠傳輸背後的設計哲學，掌握擁塞控制與視窗機制。
網路的契約：可靠性的保證
如果說 IP (Internet Protocol) 是將信件送到地址的快遞員，那麼 TCP (Transmission Control Protocol) 就是確保對方真的收到信、且信件順序沒亂掉的「掛號機制」。
TCP 的四大核心特點
面向連接 (Connection-Oriented)
資料傳輸前，雙方必須先建立一條虛擬的雙向通道。
可靠傳輸 (Reliable Delivery)
丟包重傳、重複包過濾、損壞包檢測。
流量控制 (Flow Control)
防止發送者發得太快，導致接收者處理不過來。
擁塞控制 (Congestion Control)
根據網路塞車情況，動態調整發送速度。
一、三向交握 (3-way Handshake)
這是 TCP 建立連線的過程。為什麼非得要「三向」不可？因為這能保證雙方的「發送」與「接收」能力都是正常的。
CLIENT
SERVER
SYN (Synchronize)
"聽得到嗎？我想跟你連線。"
SYN-ACK
"聽到了！我也想跟你連線。"
ACK (Acknowledge)
"OK！那我們開始吧。"
為什麼不能兩次交握？
想像 Client 發送了第一個 SYN 但網路太塞沒及時到，Client 又發了第二個 SYN。過了一陣子 Server 收到了遲到的第一個 SYN 並回覆 ACK。 如果是兩次交握，Server 此時就會開啟資源等資料。但 Client 可能早就無視第一個 SYN 了。三向交握是為了防止「已失效的連線請求」突然又傳到 Server 造成資源浪費。
二、四次揮手 (4-way Handshake)
連線容易，分手難。釋放連線需要四個步驟，因為 TCP 是「全雙工」，雙方都必須獨立關閉自己的發送通道。
TIME_WAIT：最後的溫柔
Client 在送出最後一個 ACK 後，不會立刻消失，而是會等 2MSL (約 4 分鐘)。 這是為了確保 Server 真的收到了最後那個 ACK。如果沒收到，Server 會重發 FIN，Client 還能補送 ACK。
三、流量控制：滑動視窗 (Sliding Window)
如果發送端是一台超級電腦，接收端是一台舊手機，發送端如果不控制速度，手機的 Buffer 會瞬間爆掉。 TCP 使用 Window Size 來動態告知對方：「我目前還有多少空間可以收資料」。
零視窗 (Zero Window)
當接收端 Buffer 滿了，會回傳 Window=0，這時發送端會停止傳送，並定期詢問「有空位了嗎？」。
視窗縮放 (Scaling)
在高速網路下，傳統 16-bit 的 Window Size 太小，現代 TCP 會使用 Scaling Option 來擴展到 GB 等級。
四、擁塞控制：網路塞車怎麼辦？
流量控制是為了「對手」，擁塞控制則是為了「整個網路環境」。
慢啟動 (Slow Start)
一開始只傳 1 個包，沒事就加倍 (1->2->4->8)，直到觸發門檻。
擁塞避免 (Congestion Avoidance)
達到門檻後，改為線性增加 (+1)，謹慎測試網路極限。
快重傳 (Fast Retransmit)
當收到 3 個重複的 ACK，不等計時器到，直接重傳遺失的包。
總結：致敬精妙的底層設計
TCP/IP 協議族設計於數十年前，卻依然支撐著現代龐大的網際網路。它優雅地平衡了可靠性與效率，處理了無數種複雜的網路狀況。作為軟體工程師，理解這些底層邏輯，能幫你在 Debug 網路逾時、最佳化 API 效能時，擁有更廣闊的視野。