WebRTC：它是什么，架构及工作原理

什么是WebRTC

WebRTC（Web Real-Time Communication）是一个开源项目，由Google于2011年发起，并由W3C（JavaScript API）和IETF（协议）标准化。主要任务是在浏览器和应用之间提供低延迟通信，无需安装插件或第三方软件。

与传统解决方案（RTMP、HLS）不同，在传统方案中视频通过服务器传输，而WebRTC使用点对点架构：数据直接在参与者之间传输。这提供了200-500毫秒的延迟，而HLS为3-10秒——对于语音和视频通话、游戏流媒体和远程手术来说，这是关键区别。

根据Google WebRTC Team（2025）的数据，该技术被用于总安装量超过50亿的应用中：Google Meet、WhatsApp、Discord、Telegram、Zoom（部分）。超过85%的远程医疗和教育科技领域的风险投资初创公司选择WebRTC作为主要的实时传输方式。

移动开发在2013年随着libjingle_peerconnection的发布获得了完全功能的WebRTC——这是Android和iOS的原生实现。目前两个平台都拥有稳定的SDK，支持H.264和VP8的硬件编码、摄像头、麦克风和设备的扬声器。

WebRTC架构和协议

WebRTC架构由三个层次组成。上层——JavaScript API（或移动平台的原生API），中层——传输协议，下层——编解码器和安全性。每层解决自己的任务，但所有层都是建立连接所必需的。

WebRTC主要API

MediaStream（getUserMedia）——从设备的麦克风和摄像头捕获音频和视频。RTCPeerConnection——管理P2P连接：编码、传输、比特率自适应。RTCDataChannel——通过同一通道传输任意数据（文本、文件、二进制消息）。

// JavaScript API WebRTC（浏览器示例）
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

实时协议

WebRTC使用SRTP（安全实时传输协议）用于音频和视频——具有AES-128加密的RTP安全版本。会话管理通过SCTP（流控制传输协议）经由DTLS进行。每个数据流都必须加密：WebRTC中没有不安全模式。

• SRTP/SRTCP——加密的媒体流传输，防止重放攻击
• DTLS-SRTP——通过UDP上的Datagram TLS建立加密密钥
• SCTP——为DataChannel提供可靠或部分可靠的数据传送
• ICE（交互式连接建立）——用于在对等体之间寻找网络路径的框架
• Trickle ICE——ICE的增量版本，候选者在发现时即被发送，加速连接建立

NAT穿越：ICE、STUN和TURN

WebRTC的主要技术难点是在位于NAT（网络地址转换）后面的设备之间建立P2P连接。没有特殊机制，设备无法直接相互访问，因为它们的本地IP地址在互联网上不可见。

STUN——确定公网地址

STUN（NAT会话穿越工具）——回答“我的公网IP和端口是什么？”问题的服务器。客户端向STUN服务器发送请求，服务器看到其公网地址并返回给客户端。Google公开维护STUN服务器stun:stun.l.google.com:19302。

// iOS上的WebRTC——配置ICE服务器
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN——中继连接

TURN（使用中继绕过NAT）——用于STUN无法帮助的情况的转发服务器（对称NAT或企业防火墙）。在此模式下，所有数据通过TURN服务器传输——这降低了速度并增加了延迟，但保证了99%情况下的连接。

TURN是WebRTC基础设施中最昂贵的组件，因为服务器需要转发所有媒体流量。根据Coturn Project（2025），一个典型的具有8个vCPU和16GB RAM的TURN服务器可处理约200个同时音频通话或40个HD质量的视频通话。

ICE过程

ICE收集所有可能的候选者（本地IP、通过STUN获取的公网IP、通过TURN获取的中继），并按照优先级尝试建立连接。只要至少一对候选者（本地-远程）通过连通性检查connectivity check，连接即被视为已建立。

• Host candidates——设备在子网中的本地IP地址（最快，但在NAT后面无法工作）
• Server Reflexive candidates——通过STUN服务器获取的公网IP
• Relay candidates——进行转发的TURN服务器地址（最慢，最可靠）

移动应用中的WebRTC

对于移动开发，Google维护libWebRTC——适用于Android（AAR）和iOS（XCFramework）的原生库。该库包含完整的协议栈、编解码器（VP8、VP9、H.264、AV1）和硬件编码/解码加速。

Android上的WebRTC

Android SDK提供PeerConnectionFactory、PeerConnection、MediaStream类。应用程序创建工厂，配置视频编解码器，通过VideoCapturer捕获摄像头流，并通过SDP offer/answer建立点对点连接。

// Android WebRTC——初始化
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

iOS上的WebRTC

iOS SDK使用带有RTCPeerConnectionFactory、RTCCameraVideoCapturer、RTCVideoTrack包装器的Objective-C API。H.264的硬件编码通过VideoToolbox可用。视频显示使用RTCMTLVideoView（Metal）或RTCVideoRenderer。

// iOS WebRTC——从摄像头捕获视频
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// 选择摄像头（前/后）
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// 以最大FPS启动捕获
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

对于生产环境中的视频通话，移动应用通常使用基于libWebRTC的SDK包装器：Twilio Video、Agora、Daily.co。这些SDK简化了信令、房间管理，并提供了用于显示参与者视频网格的现成UI组件。

信令与建立连接

WebRTC不指定信令协议——对等体之间的SDP（会话描述协议）消息交换。开发者自己选择信令的传输方式：WebSocket、MQTT、SIP、XMPP或REST API。信令将offer、answer和ICE候选者从一个对等体传送到另一个对等体。

SDP Offer/Answer交换

过程从创建offer开始（发起者描述其媒体能力），通过信令传输给第二个对等体，第二个对等体以answer响应。交换SDP后，每个对等体启动ICE并开始DTLS-SRTP以加密流。

// Android——创建和发送offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // 将sdp.description发送到信令服务器
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

信令协议

在移动应用中，最流行的是通过WebSocket进行信令——一种通过TCP的双向通道，与服务器保持持久连接。信令服务器通常是一个独立的微服务（Node.js、Golang、Elixir），在房间参与者之间路由消息。

• WebSocket——持久的双向连接，最小开销，信令的标准选择
• SIP over WebSocket——标准的VoIP协议，与现有电话基础设施集成
• MQTT——适用于物联网和弱网络的轻量级发布/订阅协议，但延迟较大
• Matrix / XMPP——适用于有隐私要求的应用的去中心化协议

ICE和DTLS-SRTP完成后，信令不再参与数据传输——所有媒体流量直接点对点（或通过TURN中继）进行。信令服务器可以在不中断活跃通话的情况下关闭。这是WebRTC去中心化架构的关键优势。