網路程式設計核心模型：客戶端/伺服器範式與 TCP/UDP 通訊本質

客戶端/伺服器 (C/S) 範式核心定義

軟體劃分為兩類角色：

• 客戶端：主動發起連線/請求，發送需求，消費服務。
• 伺服端：被動監聽特定埠口，接受連線，處理請求，提供服務。

在特定時刻，雙方角色嚴格區分，不可同時為客戶端（否則無伺服端處理請求）。雖存在 P2P 等對等模型，但 C/S 因簡單、符合直覺、工具鏈成熟，仍是主流網路程式設計模型。

TCP 環境下的 C/S 交互流程

1. 伺服端 bind() 綁定 IP:Port → listen() 監聽 → accept() 阻塞等待。
2. 客戶端 connect() 主動發起三次交握建立連線。
3. 連線建立後，雙方透過 send()/recv()（或 Java OutputStream/InputStream）進行全雙工位元組流交換。
4. 任一方發起 close() 四次揮手斷開連線。

UDP 環境下的差異

• 無連線建立過程，客戶端直接 sendto() 發送資料報至伺服端 IP:Port。
• 伺服端 bind() 後直接 recvfrom() 接收，可從同一 Socket 收發多客戶端資料。
• 應用層需自行處理：封包丟失重傳、亂序重組、流控、連線狀態維護。

網路客戶端關鍵特徵

• 生命週期通常較短，隨用戶操作啟動/結束。
• 掌握協議主動權：決定何時連線、發送何種請求、如何處理回應。
• 需知曉伺服端協議規範（命令格式、回應碼、錯誤處理）與端口號（HTTP 80、HTTPS 443、自定義協議協商端口）。

網路伺服端關鍵特徵

• 長期運行（Daemon/Service），系統啟動即啟動，持續監聽。
• 綁定 Well-known Port（<1024 需權限）或註冊端口（>1024）。
• 併發處理模型演進：
  單執行緒循環 → 多進程 → 多執行緒 → 線程池 → NIO Reactor → 多 Reactor + 業務線程池（現代高併發標準）。
• 協議合規性：嚴格遵循 RFC 標準，對非法請求回應錯誤碼而非崩潰。

端口號與協議綁定

客戶端透過「IP + Port」定位伺服端；伺服端透過「本地 Port」識別服務實例。同一台機器可運行多個服務，靠端口區分。

TCP 可靠傳輸機制核心（自動化、透明化）

1. 錯誤控制：檢查和驗證 + 確認應答 (ACK) + 超時重傳。程式設計師無需手動處理封包丟失。
2. 排序保證：序列號 (Sequence Number) + 接收端緩衝重組。位元組流呈現給應用層時已有序。
3. 流控：滑動視窗機制，動態調整發送速率匹配接收能力。
4. 擁塞控制：慢啟動、擁塞避免、快速重傳/恢復，保護網路基礎設施。

這些機制在作業系統核心協議棧實現，Java 開發者透過 Socket 獲得類檔案 I/O 體驗（InputStream/OutputStream），極大降低認知負擔。

總結

C/S 範式定義了網路軟體的角色邊界；TCP 提供了可靠位元組流抽象，屏蔽了封包傳輸複雜性；端口號實現了多服務共存與定位。理解這三者協作關係，是網路程式設計的「第一性原理」。