WebRTC 即時通訊實戰 2026：對等連線、SFU 與生產級模式

WebRTC 為什麼仍是即時通訊的基石

在視訊會議、線上教育、直播連麥、雲端遊戲和 IoT 遠端控制的背後，WebRTC 依然是瀏覽器原生、低延遲、端到端加密的事實標準。2026 年，隨著統一 Plan B 被標準棄用、Unified Plan 全面落地，以及 insertable streams（可插入媒體流）帶來的端到端加密自訂能力，WebRTC 在生產環境更加成熟。

能力	WebRTC	傳統 RTMP/HLS 直播
延遲	100ms ~ 500ms	2s ~ 30s
加密	預設 DTLS-SRTP	需額外配置
瀏覽器原生	✅ 無需外掛	❌ 需播放器
雙向通訊	✅ 天然支援	❌ 單向為主

核心概念一覽

Signaling（信令）：交換 SDP 與 ICE 候選的通道，WebRTC 本身不規定，通常用 WebSocket。
SDP：描述媒體能力（編解碼、解析度、傳輸位址）的會話描述。
ICE / STUN / TURN：負責尋找可達的網路路徑，穿透 NAT。
PeerConnection：整個通訊的核心物件，管理音視訊軌與資料傳輸。

第一步：建立一條對等連線

以下是一個最小可用的 1:1 通話骨架（信令服務用 WebSocket）。

// 客戶端 A
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" },
    { urls: "turn:turn.example.com:3478", username: "user", credential: "pass" }
  ]
});

// 採集本地音視訊
const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
localStream.getTracks().forEach(track => pc.addTrack(track, localStream));

// 遠端軌到達時渲染
pc.ontrack = (e) => {
  remoteVideo.srcObject = e.streams[0];
};

// 產生 Offer 並發往信令伺服器
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signaling.send(JSON.stringify({ type: "offer", sdp: pc.localDescription }));

信令伺服器端（Node + ws）只負責轉發，不參與媒體：

import { WebSocketServer } from "ws";
const wss = new WebSocketServer({ port: 8080 });
const peers = new Map();

wss.on("connection", (ws) => {
  ws.on("message", (msg) => {
    const data = JSON.parse(msg);
    // 簡單房間轉發：把 offer/answer/candidate 轉給房間內另一個人
    const target = peers.get(data.room)?.find(p => p !== ws);
    target?.send(msg);
  });
});

NAT 穿透：STUN 與 TURN 的分工

很多連線失敗，根因都在 NAT。理解三類場景：

場景	解決方式	說明
雙方均在公網/錐形 NAT	STUN	發現公網映射位址即可直連
對稱型 NAT	TURN	必須 relay 中轉
企業防火牆嚴格限制	TURN + TLS	走 443 埠中繼

// 優先直連（p2p），失敗自動回退 TURN 中繼
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.example.com" },
    { urls: "turn:turn.example.com:3478?transport=tcp", username: "u", credential: "c" }
  ]
});

pc.oniceconnectionstatechange = () => {
  if (pc.iceConnectionState === "disconnected") {
    // 觸發重連或提示使用者網路異常
    console.warn("ICE 斷開，嘗試重連…");
  }
};

排查連線問題時，可先用 URL 解析工具核對信令/ TURN 位址格式，再用 HTTP 狀態碼對照信令服務的健康度。

拓撲選型：Mesh / SFU / MCU

拓撲	原理	優點	缺點	適用
Mesh	每兩人直連	無中轉伺服器成本	頻寬隨人數平方成長	≤4 人小房間
SFU	伺服器轉發不轉碼	客戶端只上一路、下多路	伺服器頻寬大	視訊會議主流
MCU	伺服器混流	客戶端只收一路	伺服器 CPU 高、延遲大	弱網/電話接入

2026 年絕大多數視訊會議採用 SFU。客戶端上行一路（Simulcast 多檔），下行訂閱其他人的多路流。

// 聯播：同一路影片同時發 3 個檔位，SFU 按訂閱者網路選檔
const sender = pc.getSenders().find(s => s.track.kind === "video");
await sender.setParameters({
  encodings: [
    { rid: "low", maxBitrate: 150_000, scaleResolutionDownBy: 4 },
    { rid: "mid", maxBitrate: 500_000, scaleResolutionDownBy: 2 },
    { rid: "high", maxBitrate: 1_500_000 }
  ]
});

資料通道：不止音視訊

WebRTC 的 RTCDataChannel 提供低延遲、有序/無序可選的點對點資料傳輸，適合遊戲狀態同步、檔案傳輸、白板協作。

const dc = pc.createDataChannel("whiteboard", { ordered: false, maxRetransmits: 0 });
dc.onopen = () => dc.send(JSON.stringify({ type: "stroke", points: [...] }));
dc.onmessage = (e) => renderStroke(JSON.parse(e.data));

傳輸結構化訊息時，建議先用 JSON 格式化工具校驗負載，避免解析異常導致資料通道崩潰。

安全：預設加密也要守邊界

WebRTC 媒體預設走 DTLS-SRTP 端到端加密，但這不意味著「安全無憂」：

信令通道必須 HTTPS/WSS，否則 SDP 會被中間人竄改。
媒體伺服器需鑑權：SFU 應在 track 接入時校驗 room token。
E2EE 自訂：使用 insertable streams（RTCRtpScriptTransform）把應用層金鑰注入，實現伺服器也看不到明文的真·端到端加密。

// 媒體包子流加密（簡示）
const encoder = new RTCRtpScriptTransform(pc, "https://cdn/encrypt-worker.js");
sender.transform = encoder;

生產級擴展模式

級聯 SFU（Cascading SFU）

跨地域大型會議把多個 SFU 級聯，就近接入、內部轉發，降低跨國延遲。

頻寬估計與擁塞控制

WebRTC 內建 GCC（Google Congestion Control）擁塞控制，但你需要配合：

監聽 pc.getStats() 中的 googAvailableSendBandwidth，動態降檔；
弱網下關閉非必要資料通道；
用 adaptivePtime 調整音訊打包時長。

自動訂閱管理

只訂閱「正在說話/正在聚焦」的遠端流，減少下行頻寬。

function subscribeTo(userId, quality) {
  signaling.send(JSON.stringify({ type: "subscribe", userId, quality }));
}

常見問題 FAQ

Q1：為什麼經常卡在「連線中」？

90% 是 NAT/防火牆導致 ICE 失敗。檢查 TURN 是否可用，並確認信令伺服器正常轉發 candidate。

Q2：Mesh 和 SFU 怎麼選？

4 人以內小房間可用 Mesh 省成本；超過 4 人或要錄製/混流，必須用 SFU。

Q3：行動端切後台會斷流嗎？

會。iOS/Android 切後台會凍結 getUserMedia，需監聽 visibilitychange 並做重連或暫停發布。

Q4：WebRTC 能做直播嗎？

適合低延遲互動直播（連麥）。若單向大規模分發，應把 SFU 輸出轉封裝為 HLS/CMAF 下發。

Q5：Simulcast 一定要開嗎？

多檔聯播能顯著提升弱網體驗，但會增加上行頻寬約 10%-20%，按場景權衡。

工具推薦

在 WebRTC 開發與排障中，以下工具庫能幫上忙：

URL 解析 — 核對 STUN/TURN/信令位址格式
HTTP 狀態碼 — 對照信令服務與 TURN REST API 回傳
JSON 格式化 — 校驗信令 SDP 包裝與資料通道負載

WebRTC 的門檻在「連線建立」與「NAT 穿透」，跨過這兩道坎，你就能在瀏覽器裡建構毫秒級延遲的即時世界。