WebRTC

WebRTC（全稱：Web Real-Time Communication）是一套由W3C與IETF聯合標準化的開放技術框架，包含一組JavaScript API及底層通信協議，支持瀏覽器與移動應用在不依賴插件的情況下實現點對點實時音視頻通話與數據傳輸。 該框架於2021年1月被W3C正式採納為Recommendation，同時其協議棧被IETF確立為互聯網標準，標誌着WebRTC成為Web平台原生實時通信的基礎性技術。

歷史

WebRTC的技術根基可追溯至1990年代末成立的瑞典公司Global IP Solutions（GIPS），該公司專注於開發高魯棒性的實時音視頻編解碼與網絡傳輸引擎，其技術曾應用於Skype等早期VoIP產品。 2010年，Google以約6820萬美元收購GIPS，同時收購了擁有VP8視頻編解碼技術的On2 Technologies。

2011年5月，Google將相關代碼開源並正式提出WebRTC項目，同年IETF成立rtcweb工作組，W3C成立WebRTC工作組，兩個標準化機構開始了長達十年的協同標準化工作。 2013年，首個跨瀏覽器WebRTC視頻通話演示成功。2021年1月26日，W3C與IETF聯合宣布WebRTC成為正式標準，使其成為繼插件時代終結後唯一 survived 的瀏覽器原生媒體傳輸標準。

技術架構

核心API

WebRTC在瀏覽器端通過三個核心JavaScript API暴露其功能。MediaStream API（又稱getUserMedia）負責訪問本地攝像頭、麥克風及屏幕捕獲設備，輸出MediaStream對象供後續處理。 RTCPeerConnection API管理點對點連接的完整生命周期，包括編解碼協商、帶寬自適應、丟包恢復、回聲消除及加密握手等。 RTCDataChannel API則提供雙向、低延遲的任意數據傳輸通道，支持可靠與不可靠兩種傳輸模式，適用於實時遊戲狀態同步、文件傳輸及即時消息等場景。

協議棧

WebRTC的底層協議棧由IETF標準化。會話描述協議（SDP）用於在通信雙方間交換媒體能力、編解碼偏好及傳輸參數，遵循offer/answer模型。 交互式連接建立（ICE）框架負責在複雜網絡環境下發現最優通信路徑，其通過STUN伺服器協助對等端發現公網IP位址與端口，並在直接連接不可行時藉助TURN伺服器中繼媒體流量。 所有媒體流均強制採用DTLS-SRTP進行端到端加密，其中DTLS用於密鑰交換與身份驗證，SRTP用於加密RTP媒體包，該加密機制為規範強制要求而非可選配置。

信令機制

WebRTC規範本身不定義信令協議，開發者可自行選擇WebSocket、HTTP或SIP等傳輸方式完成初始握手。信令階段需交換三類信息：會話控制消息、網絡地址（ICE候選）及媒體元數據（SDP offer/answer）。 一旦ICE完成路徑選擇並建立安全通道，媒體與數據即可直接在peer間傳輸，信令伺服器不再參與實際通信。

安全性

WebRTC從設計之初即將安全性作為核心原則。所有媒體流強制啟用端到端加密，無法通過API禁用或降級。 瀏覽器在訪問攝像頭與麥克風前必須獲得用戶明確授權。此外，ICE候選收集過程可能暴露用戶本地IP位址，引發私隱關切，現代瀏覽器已逐步採用mDNS候選替代私有IP位址以緩解該問題。

與VoIP的比較

WebRTC與傳統VoIP技術存在顯著差異。WebRTC為瀏覽器原生技術，無需安裝插件或專用客戶端，而傳統VoIP通常依賴桌面應用或硬件終端。 WebRTC基於開放標準且無授權費用，傳統VoIP生態則常涉及SIP伺服器、媒體網關及編解碼許可等成本。 在架構上，WebRTC優先採用點對點直連以降低延遲與伺服器負載，傳統VoIP多採用集中式伺服器架構。

應用領域

WebRTC已成為現代實時通信的基礎設施。在視頻會議領域，Google Meet、Microsoft Teams及Zoom的Web客戶端均基於WebRTC構建。 在協作工具中，它支持文檔協同編輯與屏幕共享。在物聯網與遠程醫療場景中，WebRTC為設備遠程監控與實時健康數據傳輸提供低延遲通道。 此外，在線多人遊戲、P2P文件傳輸、直播流媒體及客戶支持嵌入式音視頻通話等場景亦廣泛採用該技術。

擴展架構

純點對點WebRTC在多方會議場景中存在帶寬瓶頸——每增加一個參與者，各端的上行帶寬需求線性增長。為此，生產級應用通常引入媒體伺服器擴展架構。 選擇性轉發單元（SFU）接收各參與者的媒體流後選擇性轉發給其他 peer，顯著降低客戶端帶寬壓力，支持數十至數百人規模的會議。 多點控制單元（MCU）則將所有輸入流混合為單一輸出流，適用於傳統視頻會議終端兼容場景，但伺服器計算開銷較高。