WebTransport 指南：串流、資料報、HTTP/3 與適用場景

WebTransport 是一個基於 HTTP/3 的瀏覽器 API，用於用戶端和伺服器之間的雙向通訊。它在同一個連線裡提供兩類傳輸方式：可靠串流和不可靠資料報。

這讓它適合低延遲應用，但它不是 WebSocket 或 WebRTC 的萬用替代品。判斷是否該用 WebTransport，最好從你的應用資料模式開始。

WebTransport 是什麼

WebTransport 允許瀏覽器連線到 HTTP/3 伺服器，並透過兩種方式交換資料：

可靠串流：有序位元組流，適合必須正確到達的資料。
不可靠資料報：盡力而為的訊息，適合低延遲優先、允許遺失的資料。

它運行在安全上下文中，實際使用時應按 HTTPS 處理。它還依賴瀏覽器、伺服器、網路路徑、CDN 和代理層對 HTTP/3 的支援。

參考文件：

核心模型

可以把 WebTransport 連線理解成一個工作階段，裡面可以承載多個獨立通道。

瀏覽器
  WebTransport 工作階段
    可靠串流：聊天訊息、檔案分塊、控制命令
    可靠串流：另一個獨立操作
    資料報：玩家位置、感測器更新、即時游標
HTTP/3 伺服器

關鍵點是：不同資料可以使用不同傳輸規則。付款確認不應該像遊戲位置更新一樣傳送；遊戲位置更新也不應該被大檔案傳輸堵住。

串流與資料報

特性	串流	資料報
傳輸可靠性	可靠	盡力而為
順序	單個串流內有序	不保證順序
適合內容	檔案、命令、聊天、交易	遊戲狀態、遙測、即時游標
遺失處理	傳輸層負責可靠性	應用必須能容忍遺失
資料形態	位元組塊	獨立訊息

正確性重要時用串流。最新值比舊值更重要時，用資料報。

WebTransport 與 WebSocket

WebSocket 仍然是很多應用更簡單的預設選擇。它部署廣、代理友好、生态成熟。

WebTransport 更適合這些需求：

一個工作階段裡有多個獨立串流。
需要低延遲的不可靠訊息。
希望減少無關資料流之間的隊頭阻塞。
想使用基於 HTTP/3 的現代用戶端-伺服器傳輸。

這些情況繼續用 WebSocket：

只需要一個可靠、有序的訊息流。
希望最大化相容現有基礎設施。
伺服器、CDN 或公司網路不能穩定處理 HTTP/3。
希望維運路徑盡可能簡單。

不要因為 WebTransport 更新就遷移一個已經穩定工作的 WebSocket 應用。只有當你的資料模式真正受益於串流、資料報或 HTTP/3 特性時，遷移才有意義。

WebTransport 與 WebRTC Data Channel

WebRTC Data Channel 更偏向點對點或媒體相關即時系統。WebTransport 是用戶端到伺服器。

適合 WebRTC 的情況：

瀏覽器需要點對點通訊。
應用本來就包含音視訊協商。
需要 WebRTC 基礎設施處理 NAT 穿透。

適合 WebTransport 的情況：

瀏覽器主要和你的伺服器通訊，而不是直接和另一個瀏覽器通訊。
希望使用更接近 Web 平台的 Streams API。
不需要完整 WebRTC 技術棧。

如果你已經有穩定的 WebRTC 架構，WebTransport 未必能帶來足夠收益來支撐重寫。

基礎用戶端寫法

使用前一定要做功能偵測。

async function connectWebTransport(url) {
  if (!("WebTransport" in globalThis)) {
    throw new Error("WebTransport is not available in this browser.");
  }

  const transport = new WebTransport(url);

  transport.closed
    .then(() => {
      console.log("WebTransport closed normally.");
    })
    .catch((error) => {
      console.error("WebTransport closed unexpectedly:", error);
    });

  await transport.ready;
  return transport;
}

const transport = await connectWebTransport("https://example.com:4433/wt");

生產環境要把這段封裝到降級邏輯裡。如果 WebTransport 不可用或連線失敗，根據功能切換到 WebSocket、Server-Sent Events 或普通 HTTP。

傳送資料報

資料報適合頻繁狀態更新，尤其是舊訊息很快失去價值的場景。

const writer = transport.datagrams.writable.getWriter();
const encoder = new TextEncoder();

await writer.write(encoder.encode(JSON.stringify({
  type: "cursor",
  x: 240,
  y: 180,
  t: Date.now()
})));

設計資料報時，每條訊息都應該能獨立理解，不要依賴前面的每一條資料報都被收到。

適合資料報的內容：

目前玩家位置。
最新游標位置。
感測器讀數。
輸入狀態或線上心跳。
即時預覽狀態。

不適合資料報的內容：

付款操作。
帳戶變更。
需要嚴格順序的文件編輯。
任何必須稽核的操作。

使用可靠串流

如果接收方必須按順序拿到所有位元組，就用串流。

const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
const reader = stream.readable.getReader();
const encoder = new TextEncoder();
const decoder = new TextDecoder();

await writer.write(encoder.encode("hello"));

const { value } = await reader.read();
if (value) {
  console.log(decoder.decode(value));
}

await writer.close();

互不相關的操作應該放到不同串流裡。這樣大檔案傳輸不會阻塞小的控制訊息。

上線前檢查清單

上線 WebTransport 前，要檢查整條鏈路：

目標使用者的瀏覽器支援情況。
伺服器是否支援 HTTP/3。
TLS 憑證和安全上下文設定。
UDP 和 QUIC 在防火牆、公司網路中的表現。
CDN 或反向代理是否支援。
長連線工作階段下的負載平衡行為。
連線失敗率、重試率和降級使用率監控。
串流的背壓處理。
資料報訊息大小限制。
工作階段建立時的驗證和授權。

最難的部分往往不是瀏覽器 API，而是網路和伺服器部署。

降級策略

一個實用的降級策略可以是：

優先嘗試 WebTransport
  如果不可用或連線失敗：
    用 WebSocket 承接雙向可靠訊息
  如果不需要雙向：
    用 Server-Sent Events 做伺服器推送
  如果即時性不是必須：
    用 fetch 輪詢

即使傳輸方式變化，產品體驗也要保持可預期。例如儀表板可以在降級後變成較慢的輪詢；即時遊戲則可能需要停用對應房間。

適合使用 WebTransport 的場景

當應用同時有可靠資料和低延遲盡力而為資料時，WebTransport 值得評估：

多人遊戲狀態加可靠比賽事件。
協同編輯游標加可靠文件操作。
高频遙測加可靠控制命令的即時儀表板。
遠端設備控制中的狀態更新和命令流。
需要伺服器即時資料通道的媒體相關應用。

共同特徵是混合流量：有些資料必須到達，有些資料必須新鮮。

不適合使用的場景

這些情況應避免使用 WebTransport：

普通 REST 或 fetch API 已經夠用。
一個 WebSocket 訊息流就能乾淨解決問題。
需要相容較舊瀏覽器。
部署鏈路不能穩定支援 HTTP/3。
需要瀏覽器點對點通訊。
團隊不想維護傳輸層降級邏輯。

新的傳輸技術只有在解決真實產品痛點時才有價值。

總結

WebTransport 給瀏覽器應用提供了基於 HTTP/3 的現代用戶端-伺服器傳輸，支援可靠串流和不可靠資料報。它的價值不是「全面替代 WebSocket」，而是讓一個工作階段能承載不同即時資料，並按不同可靠性要求傳輸。

如果你的應用真的需要這種彈性，就搭配功能偵測、降級方案和生產監控一起上線。