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 信道上建立加密的数据通道
相关推荐
数据知道20 小时前
指纹浏览器:DNS 泄漏防范与 WebRTC 本地 IP 屏蔽的底层实现
爬虫·网络协议·tcp/ip·安全·webrtc·数据采集·指纹浏览器
换个昵称都难2 天前
webrtc源码解析概要介绍
webrtc
换个昵称都难2 天前
WebRTC 完整调用流程(前端纯 JS 实现,最简可运行)
webrtc
换个昵称都难3 天前
webrtc 拥塞控制GCC 和PCC
webrtc
Cxiaomu3 天前
React接入WebRTC实时视频实践
react.js·音视频·webrtc
AndyHuang19763 天前
WebRTC 强制 Relay 模式下 TCP 重连失败深度排查与优化实战
webrtc
换个昵称都难3 天前
webrtc pacing 平滑发包模块
webrtc
换个昵称都难3 天前
webrtc 音频混音介绍
音视频·webrtc
换个昵称都难3 天前
webrtc QOS-RemoteBitrateEstimator接收端带宽估计(1)
webrtc
换个昵称都难3 天前
webrtc QOS-RemoteBitrateEstimator接收端带宽估计-四个实例(2)
webrtc