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）。

ICE（Interactive Connectivity Establishment）：
- ICE 是一個框架，整合了 STUN 和 TURN 技術，用於確保端點之間的連接。
STUN（Session Traversal Utilities for NAT）：
- STUN 用於獲取位於 NAT 後面的設備的公共 IP 地址，實現 UDP 打洞，以便建立直接的 P2P 連接。
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 並沒有內建的自動重連機制，如果連線中斷，應用需要自己實現重連邏輯，這增加了實作的複雜性。