傳輸層協定 (TCP vs UDP)
特性比較
| 特性 | TCP | UDP |
|---|---|---|
| 連線方式 | 面向連線（三次握手） | 無連線 |
| 可靠性 | 保證交付 | 盡力而為（可能丟包） |
| 順序 | 維護順序 | 不保證 |
| 流量控制 | ✅ | ❌ |
| 壅塞控制 | ✅ | ❌ |
| 標頭大小 | 20–60 bytes | 8 bytes |
| 速度 | 因額外開銷較慢 | 快 |
| 典型場景 | 幾乎所有應用 | 串流、遊戲、VoIP |
TCP：網際網路的主力
TCP 提供可靠的、有序的、有錯誤檢查的資料交付。
連線建立（三次握手）
C ──SYN──► S
C ◄─SYN-ACK── S
C ──ACK──► S
資料傳輸（保證確認）
C ──Data──► S
C ◄──ACK──── S ← 未收到 ACK 則重傳
連線中的流叫「串流（stream）」——有序、有狀態
面試預設
預設使用 TCP，大多數面試官假設你用 TCP，不需要特別說明。
UDP：快速但不可靠
UDP 在 IP 之上幾乎沒有額外功能。「向前衝、聽天命」。
應用程式收到 UDP 封包時，只知道來源/目的 IP 和 port，其餘是 binary blob。
適合 UDP 的條件（需同時滿足）：
- 低延遲至關重要
- 可以容忍偶爾丟包
- 不需要支援瀏覽器（或有瀏覽器替代方案）
瀏覽器的 UDP 限制
瀏覽器目前只能透過 WebRTC 使用 UDP，無法直接使用原生 UDP。
設計方案若依賴 UDP 但需要支援瀏覽器用戶，必須提供替代路徑（如批次 HTTP 串流）。
QUIC：現代化的 TCP
QUIC 是建立在 UDP 之上的新協定（HTTP/3 使用），目標是結合 TCP 的可靠性和 UDP 的效能。
- 解決 TCP 的線頭阻塞問題
- 內建加密（TLS 1.3）
- 連線遷移（換網路不需重新握手）
面試策略
QUIC 和 HTTP/3 的了解能讓注重效能的面試官印象深刻，但大多數情況不需要主動提出。把 QUIC 視為「更好版本的 TCP」即可。
決策流程
需要使用哪個協定？
│
▼
低延遲至關重要 + 可容忍丟包 + 無需瀏覽器支援？
│
No ──► TCP（預設）
│
Yes
│
▼
需要瀏覽器支援？
│
Yes ──► WebRTC（唯一可用的瀏覽器 UDP）
│
No ──► 原生 UDP
Related Notes
- 01-Networking/01-Network-Layers-and-Requests — TCP 在完整請求流程中的角色
- 01-Networking/05-Realtime-Protocols — WebRTC（基於 UDP）
- 01-Networking/06-Load-Balancing — L4 LB 維護持久 TCP 連線
- 01-Networking/Practice-Networking