WebTransport 揭秘：超越 WebSocket 的新一代傳輸技術
在實時通訊的領域中，WebSocket 已經統治了超過十年。然而，隨著網路應用對效能的要求越來越極致（如雲端遊戲、VR/AR、高頻交易），傳統基於 TCP 的 WebSocket 開始顯露其局限性。
WebTransport 的出現，正是為了打破這些限制，帶領 Web 進入 HTTP/3 的新紀元。
一、 WebSocket 的痛點：被困在 TCP 中
WebSocket 是建立在 TCP 之上的。TCP 雖然可靠，但在不穩定的網路環境下會遇到關鍵挑戰。
1. 隊頭阻塞 (Head-of-Line Blocking)
TCP 保證數據包必須按順序到達。如果中間丟了一個包，後面的包即使已經到達，也必須在記憶體中等待，直到那個丟失的包重傳成功。
2. 繁瑣的握手
TCP 需要 3 次握手，TLS 又需要額外握手。對於需要頻繁建立短連線的場景，延遲開銷巨大。
二、 WebTransport 的救星：QUIC (HTTP/3)
WebTransport 基於 QUIC 協議，其核心優勢在於：
- UDP 底層：避開了 TCP 的順序性束縛。
- 內建安全性：TLS 1.3 直接整合在握手流程中。
- 獨立數據流 (Multiplexed Streams)：一個連線中可並發多個「流」。流 A 的丟包不會影響流 B。
三、 技術矩陣對比
| 特性 | WebSocket | WebRTC | WebTransport |
|---|---|---|---|
| 傳輸協議 | TCP | UDP (SCTP) | UDP (QUIC) |
| 握手延遲 | 中 (HTTP Upgrade) | 高 (ICE/DTLS) | 極低 (0-RTT) |
| HOL 阻塞 | 有 | 無 | 無 |
總結
WebTransport 不僅是 WebSocket 的升級，它透過 QUIC 協議從底層重新定義了 Web 上的高效能通訊。
下一章，我們將深度剖析 WebTransport 的兩種核心傳輸方式：Datagrams vs Streams。
️ 進階挑戰
如果一個網頁聊天室需要「訊息不可丟失」但「語音通話可以有些微雜訊」，WebTransport 該如何同時滿足這兩種需求？（提示：混合使用 Streams 與 Datagrams）。
延伸閱讀與資源
- web.dev：WebTransport explainer
- QUIC Working Group：RFC 9000