當你用 Google Meet 開會、跟朋友打 Discord 語音、或是用 Messenger 視訊通話時，你和對方的畫面幾乎是同步發生的。
你說一句話，對方立刻聽到；他點個頭，你馬上看到。
這種「像在旁邊講話一樣即時」的體驗，背後靠的是一套叫做 WebRTC 的技術。
這篇文章會帶你從零搞懂 WebRTC 是什麼、它為什麼能做到這麼低的延遲、跟 RTMP 和 HLS 有什麼差別，以及它在哪些場景會派上用場。
看完這篇，你就能理解為什麼視訊會議可以做到「半秒內的延遲」，而同樣是網路直播的 YouTube Live 卻要延遲十幾秒。
📖 系列文導讀：這是直播串流系列文的第三篇，也是最後一篇。
第一篇介紹了 RTMP 協定——負責直播「第一哩」的老字號；第二篇介紹了 HLS 協定——負責大規模分發的主流技術。
這篇要講的 WebRTC，則是一個專門為「即時互動」設計的新世代協定，跟前兩位不太一樣。
WebRTC 是什麼？Google 推動的即時通訊標準
WebRTC 的全名是 Web Real-Time Communication，中文可以翻成「網頁即時通訊」。
它是 Google 在 2011 年公開原始碼並推動的一套技術標準，目的是讓瀏覽器之間可以直接互相傳送影音資料，不需要安裝任何外掛（像以前的 Flash）或其他應用程式。
WebRTC 由 W3C 和 IETF 共同維護
WebRTC 推出後，Google 並沒有把它當成自家的專屬技術，而是交給兩個國際標準組織共同維護：
- W3C（全球資訊網協會）：負責定義網頁端的 API 規格，也就是開發者寫 JavaScript 時呼叫的那些函式
- IETF（網際網路工程任務組）：負責底層網路協定的標準
這種「規格公開、標準共管」的模式，跟第二篇提到的 HLS 很像，都是靠開放性才普及起來的。
WebRTC 跟 RTMP、HLS 的定位差異
前兩篇介紹的 RTMP 和 HLS，都是為了單向直播設計的——主播一個人講，大量觀眾看。
WebRTC 完全不同：它從一開始就是為雙向即時溝通設計的，典型場景是「你跟我講話、我跟你回話」，兩邊都是發送方也都是接收方。
這個根本上的差異，也影響了它整套技術的設計方向——接下來就要講這個。
理解 WebRTC 前的兩組網路概念：UDP vs TCP、P2P vs 中繼架構
WebRTC 比 RTMP、HLS 延遲低很多（具體數字等等會比較），關鍵在於它用了兩個跟它們不同的技術：UDP 和 P2P。
這兩個技術解決的是不同層次的問題：
- UDP 決定資料「怎麼送」——要不要等對方確認、要不要保證順序
- P2P 決定資料「走哪條路」——直接到對方手上、還是先經過伺服器
不過在看 WebRTC 怎麼用它們之前，得先搞懂這兩個概念本身——畢竟 UDP 和 P2P 都不是 WebRTC 獨有的發明，而是廣泛的網路通訊概念。
UDP 和 TCP：兩種傳輸方式的比較
在網路上傳送資料時，有兩種主流的方式：一種叫 TCP，一種叫 UDP。
兩者最大的差別在於「要不要確認對方收到了」。
TCP：每個封包都要確認，確保資料完整
TCP（Transmission Control Protocol，傳輸控制協定） 的特色是可靠傳輸。
它的運作方式是：發送方每送出一個封包，就會等接收方回傳「收到了」的確認訊號；如果在一段時間內沒收到確認，發送方會自動把這個封包再傳一次。
此外 TCP 還會確保所有封包按照「原本的順序」重新組合起來，避免資料錯亂。
這個設計的好處是資料不會遺失、不會錯位，但代價就是慢——每個封包都要等對方確認，遺失的還要重傳。
UDP：送出去就不管，追求速度優先
UDP（User Datagram Protocol，使用者資料包協定） 的設計相反：快速、不囉唆。
UDP 的運作方式很單純：發送方把封包送出去之後，就不再管它了——不等對方確認、不檢查有沒有送達、遺失了也不會重傳。
封包抵達的順序也不保證跟送出時一樣，重組的工作要由接收端自行處理。
這聽起來很不可靠，但在某些場景下正是需要的特性。
TCP 和 UDP 解決的是「資料怎麼送」的問題，接下來要看的是另一個層次：資料走哪條路。
中繼架構 vs P2P：兩種資料路徑
網路上要讓兩台電腦互傳資料，還有另一個設計選擇：資料要不要經過中間伺服器。
中繼架構：資料經過伺服器轉發
最常見的做法是透過伺服器中繼。
例如第二篇講的 HLS 直播架構，主播的畫面要經過編碼器、媒體伺服器、CDN 才能送到觀眾手上，中間經過了三到四個中繼點。
這種架構的好處是容易管理、容易擴展（可以搭配 CDN 服務全世界），代價是每經過一個節點就多一點延遲，加總起來可能就是好幾秒。
P2P：兩台電腦直接連線
P2P（Peer-to-Peer，對等連線） 是另一種做法：兩台電腦之間直接建立連線，不經過任何中間伺服器。
P2P 的好處很明顯：資料走最短路徑，延遲大幅降低。
但它也有明顯的缺點，後面會細講。
WebRTC 如何用 UDP + P2P 壓到半秒延遲
認識完兩個基礎概念後，回頭看 WebRTC 的設計就會很清楚。
先看三個協定的延遲差距：
WebRTC 之所以能做到這麼快，不是因為它的工程師特別厲害，而是它在兩個設計上「走了跟 RTMP、HLS 不同的路」：
- 傳輸層走 UDP，而不是 RTMP、HLS 用的 TCP
- 資料流走 P2P 直連，不繞路經過伺服器
下面分別看這兩個決定背後的邏輯。
WebRTC 為什麼選 UDP 而不是 TCP？
這是 WebRTC 最特別的設計決定之一。
大部分網路服務都選 TCP——包括 RTMP 和 HLS 在內，因為它的資料保證讓人安心。但 WebRTC 偏偏選了看似不可靠的 UDP。
要理解這個反常的決定，得先看看為什麼業界主流都選 TCP。
為什麼大部分服務都選 TCP？
以 RTMP 和 HLS 為例，它們選 TCP 主要有三個理由。
第一，主播推流是「源頭」，源頭的資料不能有瑕疵。
RTMP 負責主播把畫面送到伺服器這段，如果這段路上封包遺失、畫面損壞，後面送給全世界觀眾的版本都會跟著壞。
這種情況下，寧可讓主播端多等幾秒把封包重傳完整，也不能讓瑕疵向下擴散給所有觀眾。
第二，觀眾在傳統直播中是單方面觀賞，不是雙向互動。
想像你在看一場演唱會直播，如果偶爾畫面鬼畜一下、聲音跳針，體驗反而比多等 10 秒還差——反正你本來就只是在看別人表演，晚幾秒沒人介意，但畫面破掉會非常出戲。
第三，TCP 的網路相容性更廣。
UDP 流量經常被企業防火牆或公共 Wi-Fi 擋住，TCP 則幾乎可以暢行無阻。
直播服務需要觸及各種網路環境的觀眾（辦公室、學校、咖啡廳、行動網路），走 TCP 更能確保觀眾「連得上」。
總結來說，這些場景裡「資料完整性 + 相容性」的價值遠高於「極致低延遲」。
WebRTC 面對的是完全不同的場景
但 WebRTC 服務的是另一種情境：視訊通話、線上遊戲這類雙向即時互動。
用一個具體情境來理解：你跟朋友視訊時，突然因為網路抖動，有一秒鐘的聲音沒傳到。
系統有兩個選擇可以處理這種情況：
- 選項 A（TCP 作風）：暫停對話、等那一秒的聲音重傳回來，確保完整
- 選項 B（UDP 作風）：那一秒的聲音就當作沒了，繼續往下進行
如果選 A，你會覺得對話「整個卡住」；選 B 雖然會聽到一瞬間的雜音或跳過，但對話本身不會中斷。
對於即時互動場景，選項 B 顯然是對的——流暢比完整重要。
這就是為什麼 WebRTC 選擇 UDP：即時互動的本質，就是「慢一秒不如直接跳過」。
換句話說——協定沒有絕對的好壞，只有適不適合。
WebRTC 為什麼選 P2P 而不是中繼架構？
原因一樣直觀：少了中繼點，延遲就少了。
回到前面介紹的兩種架構：HLS 的中繼架構讓資料經過三到四個節點才到觀眾面前，每一跳都會累積延遲。
WebRTC 的 P2P 架構讓兩台電腦之間直接連線，沒有中繼伺服器負責轉發內容，資料走最短的路徑到對方手上，少了兩三跳的網路延遲，速度自然快很多。
P2P 架構的代價
不過 P2P 不是萬能的，它有兩個明顯的代價：
- 難以做大規模廣播：1 個主播對 1 百萬觀眾時，P2P 等於要建立 1 百萬條連線，家用網路根本撐不住
- 連線建立比較複雜：兩台電腦要「找到彼此」並不簡單（下一章會細講這個挑戰）
這也是為什麼 YouTube Live 不用 WebRTC 做大規模直播，而繼續用 HLS——每個工具有它適合的戰場。
不過 P2P 聽起來很單純，實際上要讓兩台電腦直接連線並不容易——下一章就要講這個挑戰。
WebRTC 連線建立需要的三個角色
前一節講到「WebRTC 不經過中繼伺服器」，這裡要特別澄清：指的是「傳輸資料」不經過中繼伺服器，不代表「完全不用任何伺服器」。
實際上，WebRTC 在建立連線的階段還是需要一些輔助伺服器幫忙。
這些輔助伺服器不會碰你的影音資料，它們只負責讓兩台電腦找到彼此、對上訊號。
WebRTC 涉及三個關鍵角色，每個角色解決一個不同的問題：
- STUN 伺服器：幫你找出「對外世界看到的你是什麼 IP 和 Port」
- 訊令伺服器：讓兩端互相交換連線資訊（名片）
- TURN 伺服器：P2P 連不上時的中繼備案
不過在介紹這三個角色之前，要先搞懂一件事：為什麼 P2P 連線會這麼困難？
先搞懂 NAT：為什麼 P2P 連線這麼困難
P2P 連線的第一個難題是：兩台電腦要怎麼互相找到對方？
這聽起來很簡單，但現實中非常困難，因為幾乎沒有任何一台電腦有「公開的 IP 位址」。
根本原因在於一個叫 NAT 的網路機制。
NAT（Network Address Translation，網路位址轉換） 是一套讓「很多台電腦共用一個對外 IP」的機制。
用你家的 Wi-Fi 當例子：
家裡可能有手機、筆電、平板、智慧電視好幾台裝置，但對外的世界只看到一個 IP 位址（你家路由器的 IP）。
外部伺服器回應你手機的請求時，也只會把資料送到那個共用 IP，再由路由器分配給家裡對的裝置。
這個設計的好處是節省 IP 資源、提升安全性，但對 P2P 來說是個麻煩：
如果我是在星巴克用手機的使用者 A，你是在家裡用筆電的使用者 B，我的手機要怎麼直接找到你的筆電？
接下來的三個角色，就是在各自解決這個「找到彼此、對上訊號」的難題。
STUN 伺服器：找出「對外世界看到的你」
STUN 伺服器的工作是：告訴你「外部的人要連到你時，該使用哪一組 IP 和 Port」。
為什麼你自己不知道對外的 IP？
你的電腦只知道自己的內部 IP（例如家裡路由器分配給你的 192.168.1.5 這種編號），但別人要從外部網路連到你，需要的是「路由器的公開 IP + 特定的 Port」這組資訊——而這組資訊，你自己並不知道。
STUN 怎麼查到你的對外位址？
STUN 伺服器是一台架設在公開網路上的伺服器。
你的電腦會送一個簡短的查詢封包給它。這個封包內容本身不重要，關鍵在於它的來源位址會在路上被改寫。
封包從你家送出去時，會經過家裡的路由器（NAT）。
路由器會把封包的「來源位址」從你的內部 IP（192.168.1.5）換成「家裡對外的公開 IP + 一個 Port」——這本來就是 NAT 每次幫你對外通訊時的工作。
所以當 STUN 伺服器收到這個封包時，它看到的來源位址已經是 NAT 改寫過的公開版本了。
STUN 伺服器只要把它觀察到的這個位址原封不動回傳給你：「我從外面看到的你的來源是 xxx.xxx.xxx.xxx:yyyy」。
拿到這個位址，你就能告訴想連到你的人「用這個位址找我」。
訊令伺服器（Signaling Server）：負責交換連線名片
就算兩台電腦知道了對方的 IP，還不夠——它們還需要互相交換更多資訊才能開始通訊。
兩端需要交換哪些連線資訊？
具體要交換的資訊包括：
- 彼此支援的影音編碼格式（H.264？VP8？Opus？）
- 彼此的公開加密金鑰（之後傳資料時要加密）
- 彼此的網路位址和 Port（也就是 STUN 幫忙查到的那些）
這些資訊就像「網路名片」——交換名片之後，才能正式開始對話。
訊令伺服器如何轉發名片？
問題是：兩台電腦都還沒建立連線，要透過誰去交換這些名片？
答案是 訊令伺服器（Signaling Server）。
訊令伺服器是一台使用者 A 和使用者 B 都能各自連上的公開伺服器。
使用者 A 先把自己的連線資訊送到訊令伺服器，訊令伺服器再把這份資訊轉發給使用者 B；使用者 B 也用同樣的方式，把自己的資訊透過訊令伺服器送給 A。
兩邊交換完資訊後，A 和 B 就掌握了對方的連線細節，可以直接建立 P2P 連線。接下來真正的影音資料會在 A 和 B 之間直接傳輸。
換句話說，訊令伺服器只負責一開始的牽線工作，不經手後續的影音資料。
具體例子：你加入 Google Meet 會議時，瀏覽器會先連到 Google 的訊令伺服器「報到」，跟會議中其他人交換名片，然後才正式開始視訊。
訊令伺服器規格不是 WebRTC 的一部分
有趣的是，WebRTC 標準沒有規定訊令伺服器要怎麼做。
開發者可以用任何方式實作——用 WebSocket、用 HTTP 輪詢、甚至用 Email 都行。
這給了應用程式很大的彈性，每家視訊服務都能依照自己的需求設計。
TURN 伺服器：P2P 直連失敗時的中繼備案
理想情況下，兩台電腦交換完名片後就能直接 P2P 連線。
什麼情況下會需要 TURN？
但現實中有些網路環境硬是不給你連，常見原因包括：
- 公司或學校的防火牆設定很嚴格，完全擋住 UDP 流量
- 某些特殊的 NAT 類型讓 STUN 沒輒
- 兩端的路由器對彼此來說剛好是「不可連」的組合
這時候 WebRTC 不會直接放棄，而是啟動備案：透過 TURN 伺服器轉發資料。
中繼模式的路徑長這樣：
使用者 A → TURN 伺服器 → 使用者 B這時候就不是純 P2P 了，資料會先經過中繼伺服器再轉發給對方。
TURN 中繼的代價：延遲和成本
好處是至少連得上，代價是：
- 延遲比純 P2P 高（多了一跳轉發）
- 維運成本高（TURN 伺服器要負擔所有使用者的流量）
這也是為什麼企業級的視訊會議服務（像 Zoom、Google Meet）都需要佈署大量的 TURN 伺服器——它們要確保即使在最嚴格的企業內網環境，使用者也能正常通話。
ICE：三個角色如何串成一次完整連線
前面介紹的 STUN、訊令伺服器、TURN，加上接下來要講的連線嘗試邏輯，合起來有一個統稱叫做 ICE（Interactive Connectivity Establishment，互動式連線建立）。
ICE 不是單一技術，而是 WebRTC 把三個角色組合運用的整體策略。整個連線過程可以分成兩大階段：交換名片 和 實際連線。
階段一：交換名片
假設使用者 A 想跟使用者 B 開始視訊通話：
- A 和 B 分別連上訊令伺服器「報到」
- A 和 B 各自透過 STUN 伺服器查出自己對外的 IP 和 Port
- A 把自己的完整名片（編碼格式、加密金鑰、對外 IP 和 Port 等）透過訊令伺服器送給 B
- B 做同樣的事，回傳自己的名片給 A
這個階段結束時，雙方都掌握了對方的連線細節，準備進入下一階段。
階段二：連線嘗試
有了名片之後，WebRTC 會同時嘗試多種連線方式，優先順序大致是：
- 直接 P2P：如果兩端都在同一個網路、或 NAT 剛好容易穿透，就直接連
- STUN 協助的 P2P：跨 NAT 但能穿透的情境，靠 STUN 查到的對外位址建立連線
- 透過 TURN 中繼：前面兩種都失敗時的保底選項
這三個選項會同時嘗試，WebRTC 會選擇最快成功的那一個當作正式連線，其他的就放棄。
使用者完全感覺不到這一切
對使用者來說，上面整套複雜流程是完全透明的。
你只會看到兩種結果：
- 連上了：通話順利開始，畫面和聲音都出來
- 連不上：通常是很極端的網路環境（完全擋 UDP 而且 TURN 也被擋掉）
所有「該試哪個位址」「失敗後要 fallback 到哪個方案」的判斷，都在瀏覽器或 App 背景自動完成。
這也是 WebRTC 設計的厲害之處：把極度複雜的網路穿透邏輯封裝起來，讓開發者和使用者都不用操心。
講完 WebRTC 的技術原理後，接下來要從「實務決策」的角度來看：WebRTC 跟 RTMP、HLS 到底怎麼分工？它的限制在哪裡？實際用在哪些場景？
WebRTC vs RTMP vs HLS：三個協定完整對比
讀完整個系列的三篇文章，是時候把三個協定並列在一起比較了。
RTMP、HLS、WebRTC 的核心特性對比表
這三個協定是合作關係，不是競爭關係
看完對比表，容易誤以為這三個協定互相在搶地盤。
但實際上，很多現代直播系統會同時用到三個協定：
- 用 RTMP 負責主播推流到伺服器（低延遲、適合單點對單點）
- 用 HLS 負責把影音分發給大量觀眾（可搭配 CDN、規模化）
- 用 WebRTC 負責互動層（主播跟觀眾的即時聊天、禮物、連麥）
它們分別解決不同的問題，組合起來才能打造完整的直播體驗。
什麼情境用什麼？一個簡單的決策指南
遇到不同需求時，可以用這個快速判斷：
- 一個主播對大量觀眾的傳統直播（例如賽事轉播、演唱會直播）→ RTMP + HLS
- 多人視訊會議或語音通話（例如遠端會議、線上課程）→ WebRTC
- 需要超低延遲的直播（例如線上拍賣、雲端遊戲、互動式電商）→ WebRTC
- 錄製好的點播影片（例如 YouTube 影片、Netflix 電影）→ HLS
不過 WebRTC 再強，也不是萬能——下一節就來看它有哪些明確的限制。
WebRTC 的兩個使用限制：防火牆、網路穩定性
除了前面提到的「P2P 架構難以做大規模廣播」這個先天限制之外，WebRTC 在實際部署時還有兩個明確的使用限制要認識。
企業防火牆可能擋住 WebRTC 的 UDP 流量
企業內網的防火牆常常是 WebRTC 的敵人。
很多公司會預設阻擋 UDP 流量（因為早期 UDP 常被拿來做攻擊或 P2P 檔案傳輸），這時候 WebRTC 的 P2P 連線就連不上。
解決方案是依賴 TURN 中繼伺服器，走 TCP 協定穿透防火牆，但這會：
- 增加延遲（從半秒內可能拉到一秒以上）
- 增加流量成本（企業視訊服務要負擔所有流量費用）
這也是為什麼免費的視訊服務通常在企業內網表現很差，而付費的企業級服務（像 Zoom、Google Workspace）會砸錢佈署全球 TURN 伺服器。
WebRTC 對網路品質敏感，不穩時體驗明顯變差
UDP 允許丟封包，但「丟一點」跟「丟很多」是兩回事。
當網路不穩、封包遺失率超過 5–10% 時，WebRTC 的體驗會明顯變糟：
- 聲音斷斷續續
- 畫面出現馬賽克或凍結
- 嚴重時直接斷線
相比之下，HLS 因為可以預先緩衝好幾秒的影片，短暫的網路抖動不會影響觀看體驗。
這也是為什麼高鐵、地鐵這種網路容易抖動的場景，看 YouTube 比視訊會議穩多了。
認識了 WebRTC 的能力和限制之後，最後來看它在實際生活中被用在哪些地方。
WebRTC 的應用場景有哪些？
理解了 WebRTC 的技術特性後，就能推論出它適合哪些場景。凡是需要「即時雙向互動」的情境，WebRTC 幾乎都是首選。
視訊通話與會議：WebRTC 最核心的戰場
Google Meet、Microsoft Teams、Zoom、Discord、LINE、Facebook Messenger、WhatsApp 幾乎所有主流通訊服務都靠 WebRTC。共同需求是一樣的：兩端以上的使用者需要即時對話，誰講話誰聽都是動態發生的。
雲端遊戲：對延遲最敏感的應用
GeForce Now、Xbox Cloud Gaming 把遠端伺服器運行的遊戲畫面即時串流到玩家裝置。雲端遊戲對延遲的要求非常嚴苛——你按下按鍵，角色必須「立刻」反應。這種場景 HLS（延遲 10 秒以上）完全做不到，只能靠 WebRTC 的超低延遲。
低延遲直播：線上拍賣、直播帶貨、遠距醫療、線上教學
這類場景以前都用 RTMP + HLS，但因為延遲太高，近年越來越多平台改用 WebRTC——線上拍賣要即時喊價、直播帶貨要即時互動問答、遠距醫療醫生和病人要即時對話、線上教學老師要即時回答學生問題。共通點是：人跟人的即時溝通是服務的核心價值，延遲會直接影響體驗品質。
WebRTC 規模化廣播：跨足大規模直播的新興方向
近年有個有趣的趨勢：LinkedIn Live、Facebook Live 的低延遲模式開始用 WebRTC 做「大規模直播」，透過伺服器群集（SFU，Selective Forwarding Unit）把 WebRTC 規模化——犧牲一點延遲（從 300ms 變成 800ms）換取能服務上萬甚至上百萬觀眾。這算是 WebRTC 在嘗試跨足 HLS 的地盤，但還沒到能完全取代的階段。
以上就是 WebRTC 從技術原理到實務應用的完整介紹。
WebRTC 重點整理
看到這裡，你應該對 WebRTC 有完整的認識了。
快速整理一下剛剛學到的重點：
- WebRTC 的全名是 Web Real-Time Communication，Google 在 2011 年推動的開放標準，現在由 W3C 和 IETF 共同維護
- 它的最大特色是延遲極低（500 毫秒以下），遠低於 RTMP（3–5 秒）和 HLS（10 秒以上）
- 延遲低的秘密在兩個設計決定：走 UDP（犧牲資料完整性換速度）和走 P2P（兩端直連省去中繼延遲）
- 雖然資料走 P2P，但連線建立需要訊令伺服器當牽線人、STUN 伺服器幫忙 NAT 穿透、必要時還需要 TURN 中繼伺服器當備案
- 適合的場景包括：視訊會議、雲端遊戲、線上拍賣、互動直播、遠距醫療——凡是需要即時雙向互動的應用
- 不適合的情況包括：大規模單向廣播、企業內網封鎖嚴格的環境、網路品質很差的場景
- WebRTC、RTMP、HLS 三者不是競爭關係，而是在直播生態系中各自負責不同的工作，經常搭配使用
直播串流的完整生態系：RTMP、HLS、WebRTC 三者分工
看完這三篇，你已經理解了直播串流的完整生態系：
- RTMP（第一篇）：負責主播把畫面推到伺服器的「第一哩」
- HLS（第二篇）：負責把影音從伺服器分發給全世界觀眾的「第二哩」
- WebRTC（第三篇）：負責即時互動，讓人與人之間的溝通幾乎沒有延遲
下次再聽到「RTMP 推流」「HLS 播放」「WebRTC 視訊」這些詞彙時，你就能立刻知道它們各自在做什麼事、為什麼這樣設計、什麼情境該用哪一個。
從 2000 年代的 Flash 時代到今天的 HTML5、從單向直播到雙向互動，直播技術的進化從沒停過。
下一個浪潮會是什麼？也許是更低延遲的 QUIC、或是 AI 驅動的新協定——但這些故事就留到未來再說了。