在 OSI 七層模型中，傳輸層（Transport Layer） 承擔著在兩台主機的應用進程之間建立端到端（End-to-End）通訊的重任。
長久以來，傳輸層形成了涇渭分明的兩大陣營：
- TCP（傳輸控制協定）：面向連線、保證可靠、順序交付、自帶流量與擁塞控制；
- UDP（用戶資料報協定）：無連線、不可靠、無狀態、追求極致速度與低延遲。
然而，隨著行動網際網路與高併發串流媒體的爆發，TCP 刻在內核裡的頑疾（隊頭阻塞、握手延遲、連線僵死）愈發凸顯。為了打破僵局，Google 提出了基於 UDP 的新一代協定 QUIC（RFC 9000），並成為 HTTP/3 的官方傳輸標準。
本文將深度對比 TCP、UDP 與 QUIC 的底層架構，並拆解擁塞控制演算法（CUBIC vs. BBR）的演進歷程。
1. 三大傳輸層協定核心特性全景矩陣
| 評估維度 | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) | QUIC / HTTP/3 (Quick UDP Internet Connections) |
|---|---|---|---|
| 連線狀態 | 面向連線（三次交握） | 無連線（發送即忘） | 面向連線（應用層維護連線狀態） |
| 可靠性保證 | 100% 可靠（ACK + 逾時重傳） | 不保證（允許丟包、亂序） | 100% 可靠（獨立 Stream 級別 ACK 重傳） |
| 連線建立延遲 | 1-RTT（TCP）+ 1-RTT（TLS 1.3）= 2-RTT | 0-RTT | 0-RTT ~ 1-RTT（傳輸與 TLS 1.3 深度融合） |
| 隊頭阻塞 (HOL) | 存在（單一封包遺失阻塞整條連線） | 不存在 | 完全消除（單一 Stream 丟包不影響其他 Stream） |
| 連線遷移能力 | 無（綁定四元組：Src IP/Port + Dst IP/Port） | 無狀態 | 支援（基於 64-bit Connection ID，WiFi 切 5G 不斷線） |
| 協定層級 | 作業系統內核（Kernel Space） | 作業系統內核 | 使用者空間（User Space，快速迭代發布） |
2. 深入理解隊頭阻塞（Head-of-Line Blocking, HOL）
什麼是隊頭阻塞？為什麼 HTTP/2 解決了應用層阻塞，卻在 TCP 層栽了跟頭？
QUIC 如何徹底根除隊頭阻塞？
QUIC 底層運行於無狀態的 UDP 之上，但在應用層為每個 Stream 分配獨立的流 ID：
- 若 Stream A 的封包遺失，只有 Stream A 進入等待重傳狀態；
- Stream B 和 Stream C 的封包到達後立即向上交付處理，各 Stream 間互不干擾！
3. QUIC 連線遷移（Connection Migration）的魔法
在行動場景下，用戶走出家門時手機會自動從「家用 WiFi」切換為「行動 5G 網絡」：
- 傳統 TCP 的痛苦：用戶的手機 IP 地址發生了改變。TCP 連線由
(Src IP, Src Port, Dst IP, Dst Port)四元組唯一確定，一旦 IP 改變，原有 TCP 連線立即中斷失效，必須重新發起三次握手與 TLS 協商。 - QUIC 的優雅解法：QUIC 連線使用隨機生成的 64 位元 Connection ID（CID） 標識連線。無論手機切換到哪個網路、IP 如何變換，只要資料包攜帶相同的 CID，伺服器就能無縫認出客戶端，連線零中斷、影片播放零卡頓！
4. 擁塞控制演算法演進：從 CUBIC 到 Google BBR
擁塞控制決定了伺服器發送資料的節奏，直接影響頻寬吞吐與網路延遲。
- CUBIC（傳統內核預設）：將「封包遺失（Packet Loss）」誤判為網路擁塞信號。在長肥管道（BDP 大）或淺緩衝區網絡中，會頻繁誤減速。
- BBR（Bottleneck Bandwidth and RTT）：不再盲信丟包，而是即時測量「最大頻寬」與「最小 RTT」，將注入網路的封包精確維持在最佳運作點，大幅降低長尾延遲（P99）並提升 20%~50% 的跨國傳輸吞吐量。
5. 總結與技術選型建議
- 網頁瀏覽與現代 API 互動：全面擁抱 QUIC / HTTP/3，享受 0-RTT 握手、無隊頭阻塞與連線遷移紅利。
- 內部低延遲微服務 RPC：可繼續採用成熟穩定的 gRPC (HTTP/2 over TCP) 或在極致性能場景採用 RDMA / eBPF。
- 即時多人音訊/視訊會議與電競遊戲：採用 UDP / WebRTC，寧可丟幀也不等待重傳，確保小於 100ms 的極致即時互動。