WebRTC 在 2026 年：開發者深度指南

我花了將近六年的時間在 WebRTC 上構建應用程序，我仍然認為它是最被低估的網路基礎設施之一。每次你進行 Google Meet 通話、在 Discord 中共享螢幕或通過瀏覽器進行遠距醫療預約時，WebRTC 都在做繁重的工作。但我交談過的大多數開發者都把它當作一個黑盒子。他們抓取一個庫，連接一些事件處理程序，然後寄希望於最好的結果。

這種方法適用於它起作用的時候。當它不起作用時——當電話在企業防火牆後面掉線、移動設備上的影片品質下降、你無法確定為什麼有兩秒延遲時——你真的需要了解底層發生的事情。所以讓我們打開這個東西。

目錄

How WebRTC Works in 2026: A Developer's Deep Dive

什麼是 WebRTC，真的？

WebRTC（Web 實時通訊）是一套開源協議、API 和標準，允許瀏覽器和移動應用程序實時交換音訊、視訊和任意數據。Google 最初在 2011 年發佈了該項目，W3C 在 2021 年將其標準化，到 2026 年，它已嵌入到本質上每個現代瀏覽器——Chrome、Firefox、Safari、Edge 及其移動對應版本。

WebRTC 背後的關鍵見解是點對點通訊。與其通過中央伺服器路由你的視訊通話（這會增加延遲並花費金錢），WebRTC 會嘗試在兩個設備之間建立直接連接。你的筆記型電腦直接與你同事的筆記型電腦通話。伺服器的角色是最小的——它只是幫助兩個對等方彼此發現。

當然，"嘗試"在那個句子中做了很多工作。NAT、防火牆和企業網路的現實意味著直接連接並不總是可能的。WebRTC 有一個完整的子系統專門用於解決該問題，我們稍後會談到。

但首先，讓我們看看構建模塊。

三個核心 API

WebRTC 公開三個主要的 JavaScript API。在你寫一行代碼之前，理解每個做什麼是必需的。

getUserMedia (MediaDevices API)

這是你如何訪問攝像頭和麥克風。它返回一個包含音訊和/或視訊軌道的 MediaStream 對象。

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  },
  audio: {
    echoCancellation: true,
    noiseSuppression: true,
    autoGainControl: true
  }
});

注意那些音訊限制。WebRTC 在瀏覽器級別處理回聲消除和降噪——對於基本用例，你不需要自帶音訊處理管道。在 2026 年，瀏覽器原生降噪已經變得非常好，儘管許多應用程序仍然在頂部分層 AI 驅動模型以獲得更好的結果。

你也可以使用 getDisplayMedia() 進行螢幕共享，它遵循相同的模式，但提示用戶選擇螢幕、視窗或標籤。

RTCPeerConnection

這是主力。RTCPeerConnection 代表你的本地設備和遠程對等方之間的連接。它處理：

  • 編碼器協商（雙方都能理解的格式）
  • ICE 候選收集（找出網路路徑）
  • DTLS 握手（加密）
  • SRTP 媒體傳輸（實際的音訊/視訊數據）
  • 頻寬估計和自適應
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:your-turn-server.com:443',
      username: 'user',
      credential: 'pass'
    }
  ]
});

// Add local tracks to the connection
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Handle incoming tracks from the remote peer
pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0];
};

一個 RTCPeerConnection 可以同時承載多個音訊和視訊軌道。你不需要為音訊和視訊分別建立連接。

RTCDataChannel

這個經常被忽視，但它非常有用。RTCDataChannel 讓你在對等方之間發送任意數據——文本消息、文件塊、遊戲狀態、感測器數據，無論你需要什麼。

const dataChannel = pc.createDataChannel('chat', {
  ordered: true,
  maxRetransmits: 3
});

dataChannel.onopen = () => {
  dataChannel.send(JSON.stringify({ type: 'message', text: 'Hello!' }));
};

dataChannel.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
};

數據通道使用 SCTP（流控制傳輸協議）超過 DTLS，你可以將其配置為有序或無序、可靠或不可靠。對於聊天功能之類的東西，你需要有序和可靠。對於實時遊戲狀態，你可能需要無序和不可靠以優先考慮新鮮度而不是完整性。

信令：WebRTC 未處理的部分

這是大多數開發者首次遇到 WebRTC 時被絆倒的地方：規範故意不定義對等方如何找到彼此。 WebRTC 處理兩個對等方知道彼此之後的所有內容，但初始發現（稱為信令）完全由你決定。

信令涉及交換兩種類型的信息：

  1. 會話描述 (SDP)：這些描述每個對等方支持的媒體格式、編碼器和功能。
  2. ICE 候選：這些是連接可能使用的潛在網路路徑。

交換遵循提議/答案模型：

// Peer A creates an offer
const offer = await pcA.createOffer();
await pcA.setLocalDescription(offer);
// Send offer to Peer B through your signaling server

// Peer B receives the offer and creates an answer
await pcB.setRemoteDescription(offer);
const answer = await pcB.createAnswer();
await pcB.setLocalDescription(answer);
// Send answer back to Peer A

// Peer A receives the answer
await pcA.setRemoteDescription(answer);

你可以使用 WebSockets、Server-Sent Events、HTTP 輪詢、Firebase 實時數據庫——任何可以在兩個客戶端之間傳遞消息的東西來實現你的信令伺服器。我見過使用從 Socket.io 到普通 REST API 的輪詢的生產系統。

SDP 格式本身是……好吧，說實話，它很醜。它是一個看起來像這樣的數十年前的文本格式：

v=0
o=- 4611731400430051336 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 49170 RTP/SAVPF 111 103 104
a=rtpmap:111 opus/48000/2

你很少需要手動解析 SDP，但理解它承載編碼器偏好、加密參數和 ICE 憑據有助於在調試連接問題時顯著幫助。

How WebRTC Works in 2026: A Developer's Deep Dive - architecture

連接舞蹈：ICE、STUN 和 TURN

這是 WebRTC 變得真正聰明和真正複雜的地方。問題：互聯網上大多數設備都位於 NAT（網路地址轉譯）後面。你的筆記型電腦沒有公共 IP 地址。你的手機也沒有。那麼兩個不同 NAT 後面的設備如何直接相互通話？

WebRTC 使用一個稱為 ICE（互動式連接建立）的框架來解決這個問題。

STUN：發現你的公共地址

STUN（NAT 會話遍歷實用程序）伺服器是輕量級的。你的瀏覽器向它發送請求，STUN 伺服器用你的公共 IP 地址和端口進行回應——從外部看到的地址。當你在建築物內時，可以把它想象成問街上某人"我的地址是什麼？"。

STUN 伺服器便宜且易於運行，Google 提供免費的伺服器（如 stun.l.google.com:19302）。他們不中繼任何媒體——他們只是告訴你你的公開面向地址是什麼。

TURN：中繼回退

有時直接點對點連接根本不可能。對稱 NAT、企業防火牆和某些移動運營商配置會阻止直接連接。當發生這種情況時，你需要一個 TURN（使用 NAT 周圍的中繼進行遍歷）伺服器。

TURN 伺服器實際上在對等方之間中繼所有媒體流量。這意味著：

  • 更高的延遲（流量通過中繼而不是直接流動）
  • 更高的頻寬成本（你為所有視訊流量付費）
  • 但當其他方法都不起作用時它起作用

在生產中，大約 10-20% 的連接需要 TURN 中繼，取決於你的用戶群。企業用戶位於企業防火牆後面的比率要高得多——有時是 40-60%。如果你想在生產中獲得可靠的 WebRTC，你必須運行 TURN 伺服器。 我無法強調這一點。我見過啟動時沒有 TURN 的初創公司，然後想知道為什麼四分之一的用戶無法連接。

ICE 候選收集過程

當你創建 RTCPeerConnection 時，ICE 開始收集候選——潛在的網路路線。它收集三種類型：

候選類型 源 延遲 成本
Host（主機） 本地網路介面 最低（僅限 LAN） 免費
Server Reflexive (srflx) 通過 STUN 發現 低 最小（STUN 便宜）
Relay（中繼） 在 TURN 伺服器上分配 更高 顯著（頻寬成本）

ICE 然後按優先順序測試這些候選，首先嘗試最快的選項。如果主機候選起作用（兩個對等方在同一 LAN 上），太好了。如果不是，它會嘗試 STUN 發現的地址。如果這些失敗，它會回退到 TURN 中繼。

這一切都自動發生，但你可以監視它：

pc.onicecandidate = (event) => {
  if (event.candidate) {
    console.log('New ICE candidate:', event.candidate.type);
    // Send this candidate to the remote peer via signaling
  }
};

pc.oniceconnectionstatechange = () => {
  console.log('ICE state:', pc.iceConnectionState);
  // States: new -> checking -> connected -> completed
  // Or: new -> checking -> failed (uh oh)
};

媒體實際上如何流動

一旦 ICE 建立路徑，媒體就會通過 RTP（實時傳輸協議）流動，特別是 SRTP（安全 RTP），因為 WebRTC 強制加密。

簡化的流程如下：

  1. 攝像頭捕獲一幀
  2. 編碼器使用協商的編碼器（VP8、VP9、H.264 或 AV1）對其進行壓縮
  3. 壓縮幀被分成 RTP 封包
  4. 每個封包都使用 SRTP 加密
  5. 封包通過 UDP（通常）發送到遠程對等方
  6. 遠程對等方解密、重組和解碼幀
  7. 幀在 <video> 元素中呈現

對於視訊，這每秒發生 30 次。對於音訊（通常是 Opus 編碼器），它更接近每秒 50 個封包。

WebRTC 對媒體傳輸使用 UDP 而不是 TCP。TCP 通過重新傳輸丟失的封包來保證傳遞，這聽起來不錯，直到你意識到從 500ms 前重新傳輸的視訊幀比無用更糟——它實際上有害，因為它延遲了更新的幀。UDP 讓 WebRTC 優先考慮及時性而不是完整性，這正是你對實時媒體想要的。

RTCP：反饋迴路

與 RTP 一起，WebRTC 使用 RTCP（RTP 控制協議）在對等方之間交換統計信息。每一方報告：

  • 封包丟失率
  • Jitter（封包到達時間的變化）
  • 往返時間
  • 可用頻寬估計

此反饋驅動自適應比特率系統，我們接下來會涵蓋。

編碼器和 2026 年的自適應比特率

WebRTC 支持多個編碼器，在過去幾年中格局已經發生了有意義的變化。

視訊編碼器

編碼器 瀏覽器支持 (2026) 壓縮效率 CPU 使用 備註
VP8 通用 基線 低 舊版，但仍然是強制實現的編碼器
VP9 通用 比 VP8 提高 ~30% 中等 大多數用例的良好平衡
H.264 通用 與 VP8 相似 低（硬體加速） 歷史上 Safari 互操作性所需
AV1 Chrome、Firefox、Safari 18+ 比 VP9 提高 ~30% 高（不斷改進） 未來，但移動設備上 CPU 成本仍然重要

AV1 採用在 2026 年加速了。較新設備上的硬體編碼支持（Apple M4、最近的高通 Snapdragon 芯片）解決了最大的抱怨——CPU 使用。對於新項目，我默認使用 VP9，當兩個對等方都支持它時，AV1 作為首選選項。

音訊編碼器

Opus 是王者。它自 WebRTC 開始以來就是強制的音訊編碼器，有充分的理由——它處理從窄帶語音到全帶寬音樂的所有內容，適應不斷變化的網路條件，並具有出色的錯誤隱蔽。你很少需要考慮音訊編碼器。

自適應比特率

這是 WebRTC 最好的功能之一，它自動發生。發送者通過 RTCP 反饋持續監視網路狀況，並實時調整編碼比特率。

當頻寬下降（比如你走進一部帶著手機的電梯），WebRTC 會：

  1. 降低視訊解析度
  2. 降低幀速率
  3. 增加壓縮（降低品質）

當條件改善時，它會縮放回上去。Google 的壅塞控制算法 (GCC) 處理此問題，在 2026 年，它已被精煉到在幾秒內對網路變化做出反應的程度。你不需要自己實現任何這些——它內置在瀏覽器的 WebRTC 棧中。

安全模型：預設加密

WebRTC 設計有強制加密。沒有辦法禁用它。每個 WebRTC 連接使用：

  • DTLS（數據報傳輸層安全）：處理密鑰交換。把它想象成 TLS，但用於 UDP。
  • SRTP（安全實時傳輸協議）：使用從 DTLS 握手導出的密鑰加密實際媒體封包。

對於數據通道，加密是 DTLS 超過 SCTP。

這意味著即使有人攔截封包（如你的 ISP 或同一 Wi-Fi 網路上的某人），他們也無法解碼音訊或視訊內容。加密是對等方之間的端到端——帶有一個重要警告。

如果你使用 TURN 中繼伺服器，TURN 伺服器可以看到加密的封包但無法解密它們。加密在對等方處終止，而不是中繼。但是，如果你對群組通話使用 SFU（選擇性轉發單位）——大多數生產系統都這樣做——SFU 傳統上需要解密和重新加密媒體。這是 Insertable Streams（現在在 2026 年對所有主要瀏覽器可用）變得重要的地方，允許即使通過 SFU 的端到端加密，允許你添加 SFU 無法剝離的額外加密層。

WebRTC vs. WebTransport vs. 傳統 VoIP

我經常被問到這個問題，所以讓我們把它講清楚。

功能 WebRTC WebTransport 傳統 VoIP (SIP)
傳輸 UDP（主要） QUIC (HTTP/3) UDP/TCP
點對點 是 否（客戶端-伺服器） 是（理論上）
瀏覽器原生 是 是 否（需要軟電話/插件）
媒體處理 內置 DIY 內置
加密 強制（DTLS/SRTP） 強制（TLS 1.3） 可選（如果配置 SRTP）
數據通道 是（SCTP） 是（QUIC 流） 否
NAT 遍歷 ICE/STUN/TURN 不需要（基於伺服器） STUN/TURN 或 SBC
延遲 亞秒級 亞秒級 亞秒級
最適合 P2P 通話、會議 單向流、遊戲 企業電話

WebTransport 基於 QUIC/HTTP/3，在 2026 年因特定用例而增加了採用——特別是單向直播流，你不需要完整的點對點機制。它不是替代 WebRTC；它是互補的。如果你構建雙向視訊通話，WebRTC 仍然是正確的選擇。如果你構建一個一個源流向數千個的廣播平台，WebTransport（或建立在其之上的 Media over QUIC）值得評估。

傳統的基於 SIP 的 VoIP 也不會消失，特別是在具有現有 PBX 基礎設施的企業中。2026 年許多生產系統運行 WebRTC-to-SIP 網關以將基於瀏覽器的客戶端與傳統電話系統橋接。

2026 年的變化

2026 年的 WebRTC 與 2023 年的 WebRTC 沒有根本不同，但幾個進展很重要：

AI 整合已成為主流

實時 AI 功能現在直接在 WebRTC 流上運行：

  • 超出瀏覽器本身提供的背景噪聲抑制（Krisp 等工具或 Google Meet 內置模型）
  • 通話期間的實時轉錄和翻譯
  • 作為對等方參與 WebRTC 通話的 AI 語音代理，處理客戶服務或會議摘要
  • 音訊流的情感分析，用於呼叫中心應用程序

WebRTC 提供的低延遲傳輸正是這些 AI 模型所需要的。你無法在延遲兩秒的流上運行實時轉錄。

AV1 硬體編碼是真實的

我在編碼器部分提到了這一點，但值得重複。AV1 硬體編碼器對較新芯片的支持使其對實時使用變得實用。你獲得 VP9 級別的 CPU 使用，但壓縮提高 30%。對於頻寬受限的場景（移動、發展中市場），這是個大事件。

WebCodecs API 成熟度

WebCodecs API 讓你訪問瀏覽器的內置編碼器/解碼器，而無需通過完整的 WebRTC 棧。當你需要低級控制時，這很有用——自訂視訊處理管道、在流式傳輸時編碼用於錄製或將幀提供給 ML 模型。它與 WebRTC 的 Insertable Streams 配合得很好，用於自訂處理。

改進的瀏覽器奇偶校驗

Safari 在歷史上一直是 WebRTC 的問題兒童。在 2026 年，Safari 18+ 已消除大多數差距——模擬廣播運作正確，Insertable Streams 受支持，AV1 解碼可用。你仍然需要跨瀏覽器進行測試，但編寫 Safari 特定解決方案的日子已基本消逝。

使用 WebRTC 構建：實際考慮

如果你構建使用 WebRTC 的產品，以下是我要考慮的事項：

不要自己開發 SFU（可能）

對於 1:1 通話，直接點對點很好。對於超過 3-4 個參與者的群組通話，你需要一個選擇性轉發單位。從頭構建一個是一項認真的工作。考慮開源選項，如 mediasoup、Janus 或 Pion（Go 基礎），或託管服務，如 Twilio、Daily.co、LiveKit 或 Agora。

為 TURN 伺服器編預算

使用 coturn（開源）或託管 TURN 服務。在 443/TCP 端口上運行 TURN 作為回退——某些企業防火牆阻止除 HTTP/HTTPS 端口外的所有內容。預算 $200-500/月用於適度部署；視訊中繼頻寬會迅速增加。

在真實網路上測試

WebRTC 在本地主機上運作得漂亮。它在擁擠的 Wi-Fi、移動網路和企業代理後面以有趣的方式崩潰。Chrome 的 chrome://webrtc-internals 是你最好的調試朋友——它實時顯示 ICE 候選收集、編碼器協商、頻寬估計和封包丟失。

考慮你的前端架構

如果你構建包含 WebRTC 功能的網路應用程序，前端框架很重要。我們在 Next.js 應用程序中構建了實時協作功能，其中 WebRTC 數據通道為實時游標和共享狀態提供支持。對於內容豐富偶爾具有實時功能的網站，Astro 島嶼架構讓你僅在需要時加載 WebRTC 代碼，保持初始包精簡。

如果你需要一個與 headless CMS 集成的自訂 WebRTC 解決方案——比如，對於遠距醫療平台或直播商務網站——這是從一開始就把架構正確的項目，節省幾個月的痛苦。如果你想談談你的特定設置，歡迎聯繫我們。

常見問題

WebRTC 完全無需伺服器就能運作嗎？ 不完全是。你總是需要一個信令伺服器來幫助對等方交換連接信息（SDP 提議/答案和 ICE 候選）。你至少還需要一個 STUN 伺服器用於 NAT 遍歷，現實上需要一個 TURN 伺服器用於可靠性。但實際媒體可以不接觸你的伺服器而點對點流動。

為什麼 WebRTC 連接有時在企業防火牆後面失敗？ 企業防火牆經常阻止 UDP 流量並限制出站連接僅到 80 和 443 端口。由於 WebRTC 主要在動態端口上使用 UDP，這可能會阻止直接連接，甚至阻止 STUN。修復是在 443 端口使用 TCP 運行 TURN 伺服器，這對防火牆看起來像常規 HTTPS 流量。這是為什麼 TURN 基礎設施對企業部署不可協商的原因。

WebRTC 如何處理糟糕或波動的網路狀況？ WebRTC 使用自適應比特率編碼。它通過 RTCP 反饋持續監視封包丟失、jitter 和可用頻寬，並實時調整編碼品質。在糟糕的連接上，你會看到更低的解析度和幀速率，而不是凍結視訊。Google 的壅塞控制算法 (GCC) 自動管理此——你不需要自己實現它。

WebRTC 能否擴展到數百或數千個觀眾？ 不能使用純點對點——每個參與者需要與其他每個參與者建立直接連接。對於大群組（超過約 4 人），你需要一個選擇性轉發單位 (SFU)，它接收每個參與者的流並將其轉發給所有人。對於廣播給數千人，你將 WebRTC 攝取與 CDN 配對或使用處理扇出的基於 WebRTC 的流平台。

WebRTC 是否加密？我的 ISP 能看到我的視訊通話嗎？ 是的，所有 WebRTC 媒體都使用 DTLS 進行密鑰交換和 SRTP 進行媒體傳輸進行加密。此加密是強制的——你根本無法禁用它。你的 ISP 可以看到你進行 WebRTC 連接以及有多少數據流動，但他們無法解碼實際的音訊或視訊內容。

WebRTC 和 WebSockets 對實時功能之間的區別是什麼？ WebSockets 是基於 TCP 的，專為可靠、有序的消息傳遞而設計——非常適合聊天、通知和信令。WebRTC 對媒體傳輸使用 UDP，優先考慮低延遲而不是保證傳遞，並支持點對點連接。使用 WebSockets 用於信令伺服器和基於文本的實時功能；當你需要音訊、視訊或低延遲數據通道時，使用 WebRTC。

我應該為我 2026 年的流式傳輸項目使用 WebRTC 還是 WebTransport？ 這取決於通訊方向。對於雙向互動流式傳輸（視訊通話、遠距醫療、帶有觀眾互動的直播商務），WebRTC 是明確的選擇。對於一對多廣播流式傳輸，其中亞秒級延遲重要但互動性有限，WebTransport（和新興的 Media over QUIC 標準）值得評估。許多平台同時使用兩者——WebRTC 用於攝取和互動，WebTransport 或 HLS/DASH 用於大規模分發。

我需要多少硬體/頻寬用於 WebRTC 視訊通話？ 對於 720p 視訊通話，預期每個參與者大約 1.5-2 Mbps 上傳和下載。1080p 將其推至 2.5-4 Mbps。任何現代設備（過去 5 年的筆記型電腦、手機、平板電腦）都有足夠的 CPU 用於 WebRTC。瓶頸幾乎總是網路品質——特別是上傳頻寬和網路穩定性——而不是處理能力。