WebRTC 连接建立流程

[第一阶段:信令与 ICE 候选地址交换](#第一阶段:信令与 ICE 候选地址交换)

[第二阶段:ICE 连通性检查(建立原始通道)](#第二阶段:ICE 连通性检查(建立原始通道))

[第三阶段:DTLS 握手(在 ICE 建立的通道上)](#第三阶段:DTLS 握手(在 ICE 建立的通道上))

[第四阶段:SRTP 密钥导出与媒体传输](#第四阶段:SRTP 密钥导出与媒体传输)

完整流程的时间线总结


!!!别的不说,先上图!!!

流程图对应的plantUML代码:

复制代码
sequenceDiagram
    participant A as Peer A
    participant Sig as 信令服务器
    participant B as Peer B
    participant STUN as STUN/TURN 服务器

    Note over A, B: 第一阶段:本地准备与信令交换
    A->>A: 1. 创建PeerConnection<br>收集ICE候选地址
    A->>Sig: 2. 发送SDP Offer<br>(含ICE候选地址)
    Sig->>B: 转发Offer
    B->>B: 3. 收集自己的ICE候选地址
    B->>Sig: 4. 发送SDP Answer<br>(含ICE候选地址)
    Sig->>A: 转发Answer

    Note over A, B: 第二阶段:ICE连接性检查
    A->>B: STUN请求 (测试路径1)
    B->>A: STUN响应 (路径通的确认)
    Note over A,B: 建立双向连接通道<br>但还不能传媒体

    Note over A, B: 第三阶段:DTLS握手(在ICE选定的通道上)
    rect rgb(240, 255, 240)
        A->>B: ClientHello
        B->>A: ServerHello, Certificate, ServerKeyExchange,<br>ServerHelloDone
        A->>B: ClientKeyExchange, ChangeCipherSpec, Finished
        B->>A: ChangeCipherSpec, Finished
    end
    Note over A, B: DTLS握手完成<br>双方获得主密钥

    Note over A, B: 第四阶段:SRTP密钥导出与媒体流传输
    rect rgb(240, 248, 255)
        A->>A: 5. 从DTLS主密钥导出<br>SRTP加密密钥
        B->>B: 从相同的DTLS主密钥导出<br>SRTP解密密钥
        A->>B: 6. 开始传输加密的SRTP媒体流
        B->>A: 传输加密的SRTP媒体流
    end

第一阶段:信令与 ICE 候选地址交换

这部分与之前描述一致:

  1. Peer A 创建 RTCPeerConnection,收集 ICE 候选地址(主机、反射、中继)

  2. Peer A 通过信令服务器发送 SDP Offer(包含 ICE 候选地址和媒体信息)

  3. Peer B 收到 Offer 后,收集自己的 ICE 候选地址

  4. Peer B 通过信令服务器发送 SDP Answer(包含自己的 ICE 候选地址)

第二阶段:ICE 连通性检查(建立原始通道)

这是 DTLS 的前提

  1. 双方使用 STUN 协议测试所有候选地址对

  2. 找到可通行的最佳路径(可能是 P2P 直连或通过 TURN 中继)

  3. 重要 :此时建立的是一个原始的数据传输通道,但还没有加密,不能传输敏感媒体数据

第三阶段:DTLS 握手(在 ICE 建立的通道上)

这是安全性的核心。一旦 ICE 完成,两端立即在已建立的通道上启动 DTLS 握手:

什么是 DTLS?

  • DTLS = Datagram Transport Layer Security(数据包传输层安全)

  • 它是 TLS(HTTPS 使用的协议)的 UDP 版本

  • 专门为无连接、不可靠的 UDP 通道设计,能处理丢包、乱序等问题

DTLS 握手步骤:

  1. ClientHello: Peer A(作为 DTLS 客户端)向 Peer B 发送 ClientHello 消息

  2. ServerHello + Certificate

    • Peer B(作为 DTLS 服务器)回复 ServerHello

    • 关键 :Peer B 发送自己的 DTLS 证书(浏览器自动生成的临时证书)

  3. 密钥交换:双方交换密钥交换参数(如 ECDHE)

  4. Finished:双方交换 Finished 消息,验证握手完整性

重要规则

  • SDP 中的 a=fingerprint 属性:在 Offer/Answer 交换时,每个对等端都包含了自己证书的指纹(哈希值)

  • 证书验证:DTLS 握手时,对端会验证收到的证书是否与 SDP 中声明的指纹匹配,防止中间人攻击

  • 角色确定 :通常,发送 Offer 的一方作为 DTLS 客户端,发送 Answer 的一方作为 DTLS 服务器

握手结果

  • 双方协商出一个共享的主密钥

  • 建立了加密的 DTLS 信道

  • DTLS 信道不直接传输媒体,而是用来派生媒体加密密钥

第四阶段:SRTP 密钥导出与媒体传输

从 DTLS 到 SRTP:

  1. 密钥导出函数 :双方使用 DTLS 握手生成的主密钥 ,通过标准的密钥导出函数(如 TLS 的 PRF)计算出一对 SRTP 密钥材料

  2. 生成两对密钥

    • SRTP 加密密钥/盐(用于发送媒体)

    • SRTP 解密密钥/盐(用于接收媒体)

  3. 密钥同步:因为双方有相同的主密钥,所以导出的 SRTP 密钥也是匹配的

开始媒体传输:

  1. SRTP 封装 :音频/视频数据被封装成 SRTP 包(Secure RTP)

  2. 加密传输:使用导出的 SRTP 密钥对媒体进行加密和认证

  3. 完整保护:提供:

    • 机密性:媒体内容加密

    • 完整性:防止数据篡改

    • 重放保护:防止攻击者重放旧数据包

完整流程的时间线总结

复制代码
1. 信令交换:SDP Offer/Answer + ICE 候选地址交换
   ↓
2. ICE 连接检查:建立原始 UDP 通道
   ↓
3. DTLS 握手:在建立的 UDP 通道上进行加密握手
   ↓
4. SRTP 密钥导出:从 DTLS 主密钥生成媒体加密密钥
   ↓
5. SRTP 媒体流:开始传输加密的音视频数据
   ↓
6. (可选) SCTP/DataChannel:在 DTLS 信道上建立加密的数据通道
相关推荐
kkk_皮蛋3 小时前
WebRTC 安全机制 (DTLS、SRTP、ICE、权限管理)
安全·webrtc
kkk_皮蛋2 天前
在移动端使用 WebRTC (Android/iOS)
android·ios·webrtc
Yuer20252 天前
WebRTC 实时语音交互如何支持“可中断”?为什么状态机(FSM)是绕不开的方案
算法·rust·webrtc·fsm
web前端进阶者5 天前
webRTC指定设备加自定义用户头像
音视频·webrtc
kkk_皮蛋5 天前
WebRTC 视频编码基础 (VP8/VP9/H.264/AV1)
音视频·webrtc·vp8
Smile_2542204186 天前
vlc的使用
网络·webrtc·实时音视频
kkk_皮蛋7 天前
带宽估计 BWE (WebRTC 的智能网络优化核心)
网络·webrtc
txp玩Linux8 天前
rk3568上webrtc处理稳态噪声实践
算法·webrtc
好游科技11 天前
IM即时通讯系统:安全可控、功能全面的社交解决方案全解析
安全·音视频·webrtc·im即时通讯·私有化部署im即时通讯·社交app