如果你正在建造一個 JavaScript 副項目 如果你需要視訊通話，難免會有些疑慮：我該使用純 WebRTC，還是像 Agora、Twilio、Mux 或 Zegocloud 這樣的 SDK，又或者直接在 React Native 中使用 RN-WebRTC？壞消息是，並沒有唯一的解決方案。好消息是，你了解即時 JavaScript，這讓你能夠做出明智的選擇，避免架構出現問題。
接下來，您將逐步看到它的工作原理。 WebRTC 內部Agora（以及其他類似服務提供者）扮演什麼角色？搭建自己的基礎架構（STUN/TURN、訊號、SFU、媒體伺服器…）意味著什麼？視訊通話和即時串流媒體的成本、複雜性和可擴展性之間真正的權衡是什麼？
什麼是 WebRTC？為什麼它是所有技術的基礎？
WebRTC（Web即時通訊） 它是一套開源標準、API 和協議，無需插件或外部應用程序，即可直接從瀏覽器或原生應用程式實現即時音訊、視訊和資料流傳輸。它由 W3C 和 IETF 制定標準，並受到所有現代瀏覽器的支持，包括 Chrome、Firefox、Safari、Edge、Opera 以及許多行動瀏覽器。
他們的理念很明確：促進溝通 點對點（P2P） 使用者之間延遲極低，所有繁瑣的網路問題——編解碼器、抖動、迴聲、丟包、加密等等——都在後台自動處理。這涵蓋了從一對一視訊通話到整個系統的所有應用場景。 互動串流媒體 如果配上合適的基建設施，可以吸引數百名觀眾。
WebRTC 的關鍵 API：getUserMedia、RTCPeerConnection 和 RTCDataChannel
無論您是建立自己的解決方案還是使用像 Agora 這樣的 SDK，WebRTC 都依賴三個主要的瀏覽器端 API，您肯定會使用它們：
- MediaStream / 取得用戶媒體：用於擷取視訊和音訊（攝影機、麥克風，甚至螢幕或標籤頁）。
- RTCP 對等連接：在對等節點之間協商和傳輸音訊和視訊串流。
- RTC數據通道：在客戶端之間以低延遲發送任意資料（文字、二進位、檔案）。
同 獲取用戶媒體 您可以請求瀏覽器存取攝影機和麥克風，並獲得 MediaStream 然後將其與一個元素關聯起來 <video> 同 video.srcObject = stream。您可以申請 限制條件 （解析度、幀速率、前置/後置相機等），如果這些參數不符合要求，您將收到以下錯誤訊息： OverconstrainedError您必須設法提供替代方案（例如，將解析度從 1080p 降低到 720p 並進行相應調整）。 改善麥克風音訊).
的API RTCP 對等連接 它是通話的核心：它處理 SDP（offer/sponse）協商、ICE（stun/turn）候選集收集、連接建立以及透過 SRTP 進行安全傳輸。在您的程式碼中，您只需建立連接、新增媒體軌道並對事件做出反應，例如： onicecandidate u ontrack 你負責標牌。
最後， RTC數據通道 它允許您設定類似於 WebSocket 的資料通道，但它是點對點的，並且可以對可靠性和順序進行精細控制。它適用於視訊聊天、文件共享、遊戲狀態同步或即時協作。語法也很熟悉： dataChannel.send() y onmessage 在接收器中。
訊號：WebRTC 未定義的“黏合劑”
一個典型的誤解：WebRTC 不包括標牌RTCPeerConnection 需要交換訊息，但它並不規定交換方式。你需要自行定義交換方式，或者可以使用第三方 SDK 為你實現抽象化。
這些資訊對透過信令發送：
- 會話控制訊息：開始通話，掛斷，出現錯誤。
- 網絡信息：ICE候選位址（已發現的IP位址/連接埠）。
- 媒體元數據SDP 提供和回應，包括編解碼器、解析度等。
這種標識通常採用以下方式實施： WebSockets的Socket.IO、HTTP（輪詢/長輪詢）、MQTT 或其他雙向機制。一個非常典型的模式是使用 Node.js 伺服器。 套接字IO 管理“房間”並轉發訊息 文字/JSON 類型 客戶之間：
伺服器：收到 create or join如果房間不存在，它會創建一個房間；支援最多兩個客戶端（用於基本視訊通話）；並轉發訊息。 message 連接到房間內的其他插座。您有責任確保使用者數量不超過最大限制，或自行設計房間邏輯。
顧客當頁面載入時，它會要求輸入房間名稱（或從 URL 推斷），並發出以下資訊： create or join收聽類似這樣的活動 created, joined, full, ready 並與對方協商發起或拒絕通話。
這種圖案非常適合 原型或副業項目它提供了一個輕量級的信令伺服器，如有需要，可以使用叢集和負載平衡器進行擴充。
STUN、TURN、ICE：如何在不崩潰的情況下突破NAT和防火牆
理想情況下，兩個用戶始終處於可存取的網路上並直接連接。但在現實世界中，情況並非如此。 NAT、防火牆、CGNAT 來自網路服務供應商和疑神疑鬼的企業網路。這就是ICE的用武之地，它結合了STUN和TURN技術。
- 特技 （NAT會話穿越實用程式）允許客戶端查找其 公網 IP 和連接埠STUN 伺服器只會回傳這些資訊。
- 轉動 （使用 NAT 周圍的中繼進行穿越）充當 中繼伺服器 當無法建立直接的P2P頻道時，媒體傳輸就會受到影響。音訊/視訊流量會透過它傳輸，因此會消耗伺服器頻寬並產生費用。
- ICE （互動式連線建立）負責測試所有可能的候選位址（本地位址，由 STUN、TURN 中繼反映），直到找到可行的路由。
實際上，在你的 RTCPeerConnection 設定物件中，你需要新增一個陣列 冰服務器 使用 STUN/TURN URI，瀏覽器會完成剩下的工作。如果您自行建造基礎設施，則需要部署和維護 STUN/TURN 伺服器；如果您使用 Agora、Twilio 或 Zegocloud 等 SDK，它們已經為您準備好了這一切，可以用於生產環境。
低延遲即時串流：WebRTC 與 HLS/DASH 的比較
當我們談論 直播 目前有兩個截然不同的世界：基於 HTTP 的協定（HLS、DASH）和 WebRTC。 HLS/DASH 的工作原理是從客戶端下載並播放視訊片段；這種方式非常適合透過 CDN 實現可擴展性，但它也引入了… 延遲數秒 （輕鬆耗時 5-30 秒）。
另一方面，WebRTC 使用 UDP + RTP 並以「推送」模式將影片從來源端傳輸到播放器，啟動時間極短，典型延遲低於 500毫秒 如果網路狀況良好，回應時間通常約為 250 毫秒。其實作原理如下：
- 擁塞控制 整合了根據丟包、抖動或 RTT 即時調整位元率和解析度的功能。
- 使用高效率的編解碼器（VP8、VP9、H.264；以及日益普及的AV1） 硬體加速 可用時。
- 可以使用 SVC（可縮放視訊編碼），以便接收器只接收其網路/裝置可以支援的層。
這就是為什麼 WebRTC 自然而然地成為首選的原因。 即時拍賣即時體育博彩、交易、互動遊戲、遠端支援、遠距醫療、參與式虛擬教室或財務儀表板等，都無法承受幾秒鐘的延遲。
問題在於，純 P2P WebRTC 無法很好地擴展到數千名觀眾；為此，你需要 SFU、媒體伺服器或混合平台而這正是 Flussonic、Agora 或類似解決方案的用武之地。
超越 P2P 的擴展：SFU、媒體伺服器和混合架構
在一對一視訊通話中，WebRTC 的表現完美無瑕。但如果使用者數量增加到 10、20 甚至 100，情況就會改變：每個客戶端都需要發送/接收多個資料流，導致 CPU 過熱，最終造成網路崩潰。這裡會出現三種典型的問題：
- MCU（多點控制單元）伺服器接收所有資料流，將它們混合，然後向每個客戶端發送單獨的資料流。優點：客戶端資源消耗低。缺點：伺服器負載高，個體品質控制較差。
- SFU（選擇性轉送單元）伺服器接收資料流並選擇性地轉發，不進行混合。每個觀眾都能收到他們需要的資料流，品質可能有所不同。這是目前最常用的模式。 多人視訊會議 以及可擴展的互動式串流媒體。
- 混合架構 WebRTC + HLS/DASHWebRTC 用於內容攝取和交互，而 HLS/DASH 則用於向不需要即時交互的大量受眾分發內容。這是一種平衡。 超低延遲 對於「參與者」而言，它具有巨大的可擴展性；對於「觀眾」而言，它具有巨大的可擴展性。
媒體伺服器 Flussonic 其他用戶端則提供必要的後端支援：它們接收 WebRTC 串流，根據需要進行轉碼，透過 WebRTC 將其轉發給其他用戶端，或將其轉換為 HLS 等協定以進行大規模分發。正是這種基礎設施，使得在無需重複造輪子的情況下，實現超越一對一通話的功能成為可能。
典型應用場景：視訊通話、串流媒體、物聯網等等
WebRTC 已經無所不在，你可能每天都在不知不覺中使用它。它尤其適用於以下一些場景… 視訊通話和視訊會議:
- 視訊通話和視訊會議Google Meet、Jitsi、Slack、Microsoft Teams 和許多其他工具都依賴 WebRTC（部分或全部）進行視訊、音訊和螢幕分享。
- 即時串流服務Twitch、Meta Live、Vimeo Livestream 等平台或 Streamyard 等工具結合了 WebRTC 用於內容採集和其他技術用於大規模分發。
- 聊天和訊息傳遞，以及文件共享透過 RTCDataChannel，您可以實現即時聊天、檔案共享、狀態同步等功能，而無需中央媒體伺服器。
- 雲端遊戲和多人遊戲GeForce NOW 或 Xbox 雲端遊戲等服務利用類似的技術實現互動影片；許多 P2P 遊戲使用 WebRTC 來同步遊戲畫面。
- 物聯網和監控智慧攝影機、嬰兒監視器、可視門鈴或無人機可以發送 即時視訊 適用於使用 WebRTC 的行動裝置和瀏覽器。
- 教育和遠距醫療：配備白板、測驗和雙向視訊的虛擬教室，或對延遲和安全性要求極高的線上醫療諮詢。
WebRTC 安全性：加密、權限和最佳實踐
WebRTC 的安全性不是額外的功能，而是內建的。 從設計中融入所有媒體元件均已加密，API 僅可從安全來源（HTTPS 或 localhost）運行，但建議保持警惕。 透過視訊通話進行的詐騙.
- 數字傳輸系統 （資料封包傳輸層安全協定）對傳輸中的資料進行加密。
- SRTP （安全即時傳輸協定）可保護音頻和視頻，使其不易被篡改或攔截。
- 訪問 攝影機和麥克風 它需要用戶明確許可，並有可見的視覺指示（圖標、彩色圓點等）。
- 由於無需安裝任何插件，因此風險為： 惡意軟件 偽裝在第三方擴充功能或二進位檔案中。
即便如此，你也必須照顧好自己的圖層：使用 全程使用 HTTPS檢查您要求的權限，保持瀏覽器和庫的更新，並且不要忽視信令伺服器或 REST API 的安全性。
WebRTC 與其他技術（例如 VoIP、WebSocket 和專有平台）的比較
如果您之前使用過傳統 VoIP，那麼您一定熟悉 SIP、PBX、軟體電話和昂貴的伺服器。 WebRTC 改變了這種模式：您無需要求使用者提供任何資訊。 桌面客戶端 無需特定硬體；瀏覽器和相對簡單的信令伺服器就足夠了。
相對 傳統 VoIPWebRTC 減輕了核心基礎設施的負擔，並為直接整合到 Web 中的應用程式打開了大門。在許多情況下，您可以透過將訊號轉換為 WebRTC 的閘道來重複使用您的 SIP 後端。
關於 WebSockets的它們應該被視為互補關係：它們非常適合通知、輕量級聊天或狀態更新，但不適合高強度媒體播放。 WebRTC 針對高強度媒體播放進行了最佳化。 即時音訊/視訊透過擁塞控制、編解碼器、抖動緩衝等技術，實際上，許多專案使用 WebSocket 進行訊號傳輸，使用 WebRTC 進行媒體傳輸。
如果你將它們與類似平台進行比較，例如 Zoom、GoToMeeting 或 WebEx區別在於模式：那些工具是封閉式解決方案，通常需要強制安裝桌面應用程式並使用專有後端。而 WebRTC 則是基礎技術；您可以基於它建立自己的“迷你版 Meet”，或與已經使用 WebRTC 的服務（例如 Google Meet 或 Microsoft Teams）整合。
使用 WebRTC 進行開發：真正的複雜性和常見陷阱
雖然 API 看起來很簡單，但從頭開始實作 WebRTC 卻要複雜得多。您需要處理以下問題：
- 客製化標牌：設計訊息、房間、管理重新連線、重試、錯誤。
- ICE/STUN/TURN 管理部署伺服器，監控 TURN 使用情況（消耗頻寬），調整逾時時間。
- 服務品質（QoS）：調整比特率，處理不穩定的網絡，協商編解碼器，檢測連接何時下降並做出反應。
- 縮放的從簡單的 P2P 過渡到群組，再到數百個用戶，引入 SFU 或媒體伺服器，而不破壞原始設計。
- 導航者之間的相容性雖然情況不錯，但你仍然會發現一些細微差別。使用 adapter.js 仍然強烈推薦。
在一個小型業餘專案中，建立一個帶有 Socket.IO 和公共 STUN 的 Node 伺服器可能足以滿足一對一通話或小規模群組通話的需求。但如果你的想法發展壯大，需要更多功能，那就另當別論了。 大批人群無論是精細的品質控制、錄音、分析、轉錄還是盈利，您很快就需要考慮或採用… 自有媒體伺服器或轉而選擇專業服務提供者。
提供 SDK 的即時 CDN：Agora、Twilio、Mux、ZEGOCLOUD…
服務如 Agora、Twilio、Mux、ZEGOCLOUD 或者類似的技術在 WebRTC 之上建立了一個價值層，可以為您節省數月的工作時間和無數的麻煩：
- 他們為您提供 全球媒體網絡 SFU分佈在全球各地，針對低延遲進行了最佳化。
- 抽象的 眩暈/轉向、訊號、重試重新連接和複雜的網路管理。
- 它們包括維護良好的SDK，用於 Web、iOS、Android、React Native 以及其他框架。
- 他們也提供一些額外服務，例如 錄製，廣播至 RTMP/HLS審核、即時統計、品質控制、使用者角色（主持人、觀眾、發言者）等。
正如你可能已經猜到的，成本是主要問題：即使你只有一點點錢 幾分鐘的視頻 或者，如果並髮用戶數量過多，費用就會飆升。此外，你也會依賴他們的平台，而平台的價格或API變更也會帶來許多風險。
就您的具體情況而言，擁有豐富的經驗 即時 JavaScript一個明智的選擇是先使用SDK來加速開發、驗證產品，並了解其房間模型、角色、流生命週期和狀態管理。之後，如果專案進展順利，成本成為問題，您可以逐步將解決方案的部分內容遷移到更強大的平台。 專有 WebRTC 基礎設施 或依靠 Flussonic 類型的媒體伺服器來控制分發層。
WebRTC調試的最佳實踐和工具
為了避免陷入 WebRTC 的複雜機制中，建議使用瀏覽器和生態系統中已有的工具：
- chrome：// webrtc-internals (o 關於：webrtc （在 Firefox 中）：顯示連接數、位元率、丟包率、活動編解碼器等詳細統計資料的面板。
- adapter.js：社群維護的 shim，用於消除瀏覽器和版本之間的差異。
- test.webrtc.org：檢查機器的攝影機、麥克風、網路和一般相容性。
- 官方樣品 在 webrtc.github.io/samples 上：約束、對等連接、資料通道、螢幕共用等範例，對於複製模式非常有用。
透過清晰地劃分程式碼結構來組織程式碼也是一個好主意。 訊號層 （套接字、房間、訊息）層的 純 WebRTC （連線建立、串流管理、事件處理程序）。這樣，您就可以替換訊號後端或媒體伺服器，而無需重寫所有用戶端邏輯。
綜上所述，對於一個剛起步且你非常重視的副業計畫來說， 開發時間 如 中期成本最平衡的策略通常是從基於 WebRTC 的即時 SDK 入手，這樣你就可以在 React/React Native 中快速迭代，深入了解它們如何處理角色、會話、流生命週期和即時狀態，同時「按皮」深入研究 WebRTC（getUserMedia、RTCPeerConnection、RTCDataChannel、使用 IONode+Socket.進行訊號、STUN/TURN、SFU），這樣就不會永遠被束縛在單一平台上，並且能夠在產品需要時過渡到更客製化的解決方案。