WebRTC 點對點特性帶來的複雜性

什麼是WebRTC

WebRTC(Web Real-Time Communication)是一種開源技術,允許瀏覽器和移動應用程序進行音頻、視頻和數據的實時通信。它能夠在瀏覽器內直接進行音頻和視頻通話,無需安裝任何插件或額外的軟件,這大大簡化了用戶的操作。支持多種平台,包括Web、Android、iOS、Windows、MacOS和Linux。其非常的低延遲,這對於需要即時反應的應用場景(如視頻會議、在線遊戲等)非常重要。

WebRTC的關鍵技術

參考資料:https://webrtc.github.io/webrtc-org/architecture/

WebRTC 的架構分為兩個主要層次,一層是針對瀏覽器開發者的 WebRTC C++ API,另一層是針對網絡應用開發者的 Web API。

WebRTC 支援的音訊與影像引擎具備多種功能,包括各種音訊編解碼器(如 iSAC、iLBC、Opus)、回音消除(AEC)、降噪(NR)、影像編解碼器(如 VP8)、影像抖動緩衝(Video Jitter Buffer)以及畫面增強等。除此之外,WebRTC 的傳輸與會話層包含 RTP 網路層、STUN/ICE 用於網路連線建立,以及抽象的會話管理層,讓應用開發者可自行選擇協議實作方式。

技術目標與限制

WebRTC 的目標是打造一個強大的端對端即時通訊平台,讓開發者能創建豐富的即時多媒體應用,並能夠在不同的網頁瀏覽器及平台上執行。

WebRTC 是一種支持瀏覽器間進行實時音視頻通信的技術,利用點對點(P2P)的 UDP 傳輸來實現低延遲的數據流傳輸。然而,由於網絡環境中的 NAT(Network Address Translation)和防火牆的存在,直接的 P2P 連接可能會受到限制。因此,WebRTC 使用了 ICE 框架來解決 NAT 穿透問題

WebRTC 的 NAT 穿透技術

WebRTC的NAT穿透技術是實現點對點(P2P)通信的關鍵。如果NAT穿透失敗,則無法建立直接的P2P連線,這會影響通信的品質和延遲。

WebRTC使用多種技術來實現NAT穿透,主要包括ICE(Interactive Connectivity Establishment)、STUN(Session Traversal Utilities for NAT)和TURN(Traversal Using Relays around NAT)。

  1. ICE(Interactive Connectivity Establishment)
    • ICE 是一個框架,整合了 STUN 和 TURN 技術,用於確保端點之間的連接
  2. STUN(Session Traversal Utilities for NAT)
    • STUN 用於獲取位於 NAT 後面的設備的公共 IP 地址,實現 UDP 打洞,以便建立直接的 P2P 連接
  3. TURN(Traversal Using Relays around NAT)
    • 當 STUN 失敗時,TURN 提供中繼服務器,用於轉發數據流,確保通信的可靠性

即使有了這些協議,WebRTC 在某些情況下仍無法達到 100% 的網絡穿透性,特別是在某些複雜的網絡環境中,而這會造成無法建立直接的P2P連線而無法播放串流,即使TURN伺服器能夠建立連接,由於數據需要通過中繼伺服器轉發,這會增加通信的延遲,影響用戶體驗。使用TURN伺服器會增加網路頻寬消耗,因為所有數據都需要通過中繼伺服器進行轉發,這對於高流量的應用來說是一個挑戰。

相比之下,基於 HTTP 的協議如 HLS 更具有普遍性和 CDN 支援,但延遲較高。

不適合以下情境

  • 大規模廣播:WebRTC 的點對點架構非常適合小規模的通訊,但當需要大規模的多人廣播或直播時,WebRTC 效率較低,因為它需要每個用戶單獨建立連線。這樣會消耗大量的網路帶寬和資源。
  • 資料存儲與回放:WebRTC 主要設計用於即時通訊,不適合用來處理錄製和回放功能。如果需要錄製通訊內容,還需結合其他伺服器端解決方案來存儲和管理這些資料。
  • 多媒體品質保證:WebRTC 的多媒體傳輸受限於網路環境,無法完全保證高品質的影像和音訊。若需要穩定且高畫質的多媒體傳輸,可能需要更專業的解決方案。

為何不適合大規模直播的場景

WebRTC 雖然適合小規模通信(1-4 名參與者),但在大規模應用時需要後端基礎設施的支持。

這是因為WebRTC主要設計用於點對點(P2P)通信,這意味著它在處理大規模直播時會遇到性能瓶頸。當用戶數量超過一定範圍時,WebRTC的效能會顯著下降,並且需要額外的媒體伺服器(如MCU或SFU)來中繼和分發流量。

這邊網頁有介紹如何利用中繼點來避免效能瓶頸問題

https://medium.com/agora-io/webrtc-architectures-advantages-limitations-7016b666e1ae

WebRTC 的點對點特性帶來的複雜性

1. NAT 穿透(NAT Traversal)

  • NAT(Network Address Translation,網絡地址轉換) 是大多數家庭路由器或公司防火牆使用的技術,用來讓多個設備共享一個公共 IP 地址,並同時保護內網免受外部未經授權的訪問。
  • WebRTC 是點對點的協議,這意味著兩個終端需要直接互相通信。然而,當設備位於 NAT 後面時,直接的連線會變得困難,因為內網中的設備沒有公共 IP,無法直接被外部訪問。

NAT 穿透技術:

為了解決 NAT 穿透問題,WebRTC 使用了一些技術:

  • STUN(Session Traversal Utilities for NAT):STUN 伺服器幫助客戶端找到自己的公共 IP 和端口。當一個 WebRTC 用戶端連接到 STUN 伺服器時,伺服器會回傳用戶端的公共 IP 和端口,這些信息可以用來嘗試與另一個用戶端進行點對點連線。
  • TURN(Traversal Using Relays around NAT):如果 STUN 無法成功穿透 NAT(例如某些嚴格的 NAT 或防火牆阻止了連線),TURN 伺服器會作為中繼來幫助兩個用戶端進行連接。TURN 伺服器實際上會中繼點對點之間的數據,但這會增加延遲和成本,因為流量需要通過伺服器轉發。
  • ICE(Interactive Connectivity Establishment):ICE 是 WebRTC 中用來協調和選擇最佳連線方式的協議。它會嘗試使用 STUN 獲得公共 IP,並且如果 STUN 失敗,則會回退到使用 TURN 中繼伺服器來建立連接。ICE 的工作原理是嘗試多種連接路徑(直接連線、STUN、TURN),然後選擇最有效的路徑。

複雜性:

  • NAT 類型差異:不同類型的 NAT(如對稱 NAT 和全錐形 NAT)在處理穿透時行為不同,這會導致有時候需要 TURN 伺服器來中繼,即便兩個用戶端可能在理論上能夠直接通信。
  • STUN 和 TURN 伺服器部署:如果你在應用中使用 WebRTC,你需要設置和維護 STUN 和(可能的)TURN 伺服器,這增加了基礎架構的複雜性。

2. 信令伺服器(Signaling Server)

  • WebRTC 需要在兩個用戶端之間交換連線信息,例如 ICE 候選者、SDP(Session Description Protocol,用於交換媒體能力的協議),以協調和建立點對點的連線。這些交換的連線信息需要透過一個中心伺服器進行,這個伺服器稱為 信令伺服器
  • 信令本身不屬於 WebRTC 的範疇,這意味著開發者需要自行選擇或實現信令系統。信令系統可以使用任何協議,如 WebSocket、HTTP 或 WebRTC DataChannel。

信令的功能:

  • 交換 SDP 和 ICE 信息:信令伺服器的主要作用是幫助兩個用戶端交換 SDP 和 ICE 信息,以便雙方可以建立連線。
  • 管理連線建立與斷開:信令伺服器還負責管理連線的建立和斷開,例如用來處理 WebRTC 呼叫的邀請、接受、取消和斷開等控制訊息。

複雜性:

  • 不標準化:WebRTC 並沒有標準的信令協議,這意味著開發者需要選擇或設計一個合適的信令系統。常見的做法是使用 WebSocket 來實現實時的雙向信令通信。
  • 額外伺服器需求:信令伺服器必須在應用中持續運行,以支持每個連線的初始設置,這增加了額外的伺服器和開發成本。

3. 連線穩定性(Connection Stability)

由於 WebRTC 依賴點對點連線,網絡條件的波動會直接影響連線的穩定性。特別是在移動設備或網絡不穩定的情況下,WebRTC 連線可能會中斷或劣化。

挑戰:

  • 網絡切換:如果使用者在 Wi-Fi 和行動數據網絡之間切換,WebRTC 連線可能會中斷,因為 IP 地址和路由會發生變化。
  • 封包丟失與延遲:在不穩定的網絡環境中(如高延遲或丟包率高的網絡),WebRTC 連線的質量會受到很大影響,導致視頻或音頻卡頓、延遲增加,甚至連線斷開。
  • 重連機制:WebRTC 並沒有內建的自動重連機制,如果連線中斷,應用需要自己實現重連邏輯,這增加了實作的複雜性。

17年資歷女工程師,專精於動畫、影像辨識以及即時串流程式開發。經常組織活動,邀請優秀的女性分享她們的技術專長,並在眾多場合分享自己的技術知識,也活躍於非營利組織,辦理活動來支持特殊兒及其家庭。期待用技術改變世界。