Yuki Ota's profile

[Daily Questions Challenge 10]
淺談 WebRTC

2026-06-04
[Daily Questions Challenge 10] 淺談 WebRTC
⬆

WebRTC（Real-Time Communication for Web） ​

WebRTC 是一種讓瀏覽器或 App 可以直接進行即時音訊、視訊、資料傳輸的技術。

最常見的例子有：

  • Google Meet / Zoom
  • 線上客服語音或視訊
  • 瀏覽器內的語音通話
  • 即時螢幕分享
  • P2P 檔案傳輸
  • 多人遊戲即時資料同步

WebRTC 解決什麼問題？ ​

傳統 HTTP API 的架構比較像這樣：

前端 → 後端 API → 前端

它適合查資料、送表單、更新狀態。

但如果是視訊通話，每秒都要傳大量音訊與影像資料，如果每一幀都透過後端 API 轉送，延遲會很高，成本也很高。

所以 WebRTC 的目標是：

建立低延遲、即時、雙向的資料傳輸通道。

架構如下：

WebRTC 架構示意圖

各自連線到 Server 確認彼此連線後，User A 和 User B 就可以直接傳送資料，不經過 Server。

WebRTC 的核心概念 ​

1. Media Capture and Streams API（媒體擷取與串流） ​

這是 WebRTC 的第一步，這組 API 是瀏覽器提供「取得資料」的標準方法。

開發者可以利用這個功能，擷取本地端的多媒體串流，並顯示在瀏覽器上，或進行進一步的處理與傳送。

2. Peer-to-Peer Connection（端對端連線 / RTCPeerConnection） ​

簡稱 P2P，即點對點連線，意指用戶端（Client）電腦之間能夠互相交換資料，無需透過主機端（Server）來處理各用戶端的資料傳輸。

但連線的「建立過程」仍需要 Signaling Server、STUN Server、TURN Server 等伺服器輔助。

WebRTC 架構中的常見角色 ​

1. Signaling Server ​

WebRTC 的最終目標是讓兩端（Client A 與 Client B）建立 P2P（Peer-to-Peer） 直接連線，以達到最低延遲。但在 P2P 連線建立之前，雙方必須先找到彼此，並交換連線參數（例如：IP 位址、Port、支援的影片編碼格式等）。

這個負責「居中牽線」的角色就是 Signaling Server，透過 WebSocket、HTTP、SSE 建立持續且雙向的連線。

流程如下：

A 瀏覽器 ── signaling ──> 後端 ── signaling ──> B 瀏覽器

交換完連線資訊後，A 和 B 才能建立 WebRTC 連線。

2. STUN Server ​

STUN Server 的用途是幫助使用者得知：

我在外網看起來的 IP / Port 是什麼？

因為大多數使用者都在 NAT 後面，例如家用 Wi-Fi 或公司網路。

瀏覽器 → STUN Server 取得自己的 public IP / port

STUN 的優點是極度輕量且低成本，它不需要幫忙轉發任何龐大的影音資料，因此非常節省伺服器資源和頻寬。世界上有非常多免費的公開 STUN Server，開發者通常可以直接取用，不需要自行架設。

但缺點是它對付不了「對稱型 NAT（Symmetric NAT）」，例如企業防火牆或 4G／5G 行動網路，會針對不同目的地分配不同的對外 Port，導致 STUN 測得的 Port 對其他對象無效。

3. TURN Server ​

在 WebRTC 架構中，當 P2P、STUN 無法正常連線時，可以切換到 TURN Server，找一個雙方都連得上的「第三方中繼站」來傳送資料。

A ──> TURN Server ──> B

由於是中繼站，並非走 P2P 架構，因此缺點為：極度消耗頻寬、延遲增加，以及消耗運算資源。

總結 ​

在 WebRTC 架構中，Signaling Server 負責連線建立前的參數交換，是讓雙方能夠找到彼此、協調通訊方式的第一步。雙方主要透過 Signaling Server 交換兩類資訊：

  • SDP（Session Description Protocol） — 用來描述各自支援的媒體格式、編碼、傳輸參數等能力
  • ICE Candidates — ICE 蒐集到的候選連線位址，可能包含本機位址、透過 STUN 取得的公開位址，以及透過 TURN 分配的中繼位址。

一旦連線建立後，實際的音訊、影像或資料通道內容，通常會直接在兩端之間傳輸；若 P2P 連線失敗，則會改由 TURN Server 中繼傳輸。這些媒體資料不會經過 Signaling Server。

至於實際採用哪一條連線路徑，則由 ICE（Interactive Connectivity Establishment） 機制統一管理。ICE 會蒐集多條候選路徑並進行連線檢查，通常會優先嘗試延遲較低的直接連線，例如 Host Candidate 或透過 STUN 協助建立的 P2P 路徑；當 NAT、防火牆或網路限制導致 P2P 無法建立時，才會 fallback 到 TURN 中繼。

簡單來說，STUN 幫助雙方嘗試建立 P2P 連線，TURN 則是在 P2P 無法成功時提供中繼備援，兩者搭配 ICE 機制，提高 WebRTC 在不同網路環境下成功連線的機率。

針對 WebRTC，其實可以透過一系列文章來說明完整的概念、架構與流程，難以用一篇文章涵蓋全部。這篇文章先針對基本概念做介紹，如果想要更深入了解 WebRTC，可以參考以下文章：

參考 ​