WebRTC 协议簇：ICE、STUN/TURN、DTLS、SRTP
WebRTC 协议簇：ICE、STUN/TURN、DTLS、SRTP
WebRTC 建立在多个协议之上，这些协议共同完成了网络穿透、安全传输等功能。本章将详细介绍这些核心协议的工作原理和报文结构。
1. 协议栈概览
1.1 协议层次关系
flowchart TB
subgraph 应用层
A[WebRTC API]
end
subgraph 会话层
C[ICE - 连接建立]
end
subgraph 安全层
D[DTLS - 密钥交换]
end
subgraph 传输层
E[SRTP - 媒体传输]
F[SCTP - 数据通道]
end
subgraph 网络层
G[UDP]
end
A --> C
C --> D
D --> E
D --> F
E --> G
F --> G
1.2 各协议职责
| 协议 | 所在层次 | 主要职责 |
|---|---|---|
| ICE | 会话层 | 协调 NAT 穿透，选择最佳路径 |
| STUN | 网络辅助 | 发现公网映射地址 |
| TURN | 网络辅助 | 提供中继转发服务 |
| DTLS | 安全层 | 密钥交换、身份验证 |
| SRTP | 传输层 | 加密媒体传输 |
2. ICE（Interactive Connectivity Establishment）
2.1 ICE 是什么
ICE 是一个综合框架，由 RFC 8445 定义，用于在复杂的网络环境中建立连接。它不是单一协议，而是整合了多种穿透技术的协调机制。
ICE 解决的核心问题：
- 如何在 NAT 后发现可达地址
- 如何验证两个端点之间的连通性
- 如何在多条可选路径中选择最优路径
2.2 ICE Candidate 类型
| 类型 | 缩写 | 来源 | 优先级 | 说明 |
|---|---|---|---|---|
| Host | host | 本地网卡 | 最高 | 直接可用的本地地址 |
| Server Reflexive | srflx | STUN 服务器 | 高 | 通过 STUN 发现的公网地址 |
| Peer Reflexive | prflx | 对端观察 | 中 | 连接检查中发现的地址 |
| Relay | relay | TURN 服务器 | 最低 | TURN 服务器分配的中继地址 |
flowchart TB
subgraph 客户端
A[Host Candidate<br>192.168.1.100:5000]
end
subgraph NAT
B[NAT 映射<br>203.0.113.1:12345]
end
subgraph STUN服务器
C[协助发现 SRFLX]
end
subgraph TURN服务器
D[Relay Candidate<br>198.51.100.1:50000]
end
A --> B
A --> C
C --> B
B --> |srflx| C
A --> D
2.3 Candidate 格式详解
ICE Candidate 在 SDP 中的表示格式：
a=candidate:<foundation> <component-id> <transport> <priority> <connection-address> <port> <candidate-type> [<rel-addr> <rel-port>]
| 字段 | 说明 |
|---|---|
| foundation | 候选标识符，相同 foundation 的候选共享相同的基础传输 |
| component-id | 组件 ID：1=RTP，2=RTCP（rtcp-mux 后只用 1） |
| transport | 传输协议：udp 或 tcp |
| priority | 优先级（32位整数），决定检查顺序 |
| connection-address | 候选地址 |
| port | 端口号 |
| candidate-type | 类型：host/srflx/prflx/relay |
| rel-addr | 相关地址（srflx/relay 时的原始地址） |
| rel-port | 相关端口 |
2.4 优先级计算
优先级由以下公式计算：
priority = (2^24) * (type preference) + (2^8) * (local preference) + (256 - component ID)
| 类型 | type preference |
|---|---|
| Host | 126 |
| Peer Reflexive | 110 |
| Server Reflexive | 100 |
| Relay | 0 |
设计原理：优先使用直连路径（Host），其次是通过 NAT 映射的路径，最后才使用中继。
2.5 ICE 连通性检查流程
sequenceDiagram
participant A as 端点A (控制方)
participant B as 端点B (受控方)
Note over A,B: 阶段1: 收集候选
A->>A: 收集 Host/SRFLX/Relay
B->>B: 收集 Host/SRFLX/Relay
Note over A,B: 阶段2: 交换候选
A->>B: 发送候选列表
B->>A: 发送候选列表
Note over A,B: 阶段3: 连通性检查
A->>B: STUN Binding Request (从 host)
B->>A: STUN Binding Response
A->>B: STUN Binding Request (从 srflx)
B->>A: STUN Binding Response
B->>A: STUN Binding Request (从 host)
A->>B: STUN Binding Response
Note over A,B: 阶段4: 选择有效对
A->>A: 选择最高优先级有效对
B->>B: 确认选择
2.6 ICE 状态机
| 状态 | 说明 |
|---|---|
| new | 初始状态，ICE Agent 已创建 |
| gathering | 正在收集候选地址 |
| checking | 正在进行连通性检查 |
| connected | 至少一个组件检查成功 |
| completed | 所有组件检查完成，找到最佳路径 |
| failed | 所有检查都失败 |
| disconnected | 连接断开（可能临时） |
| closed | ICE Agent 已关闭 |
stateDiagram-v2
[*] --> new: 创建连接
new --> gathering: 开始收集
gathering --> checking: 收集完成
checking --> connected: 检查成功
checking --> failed: 全部失败
connected --> completed: 检查完成
connected --> disconnected: 连接丢失
completed --> disconnected: 连接丢失
disconnected --> connected: 恢复连接
disconnected --> failed: 恢复失败
failed --> closed: 关闭
completed --> closed: 关闭
2.7 ICE Restart
当连接断开需要重新建立时，触发 ICE Restart：
- 生成新的 ice-ufrag 和 ice-pwd
- 重新收集所有候选
- 重新进行连通性检查
3. STUN（Session Traversal Utilities for NAT）
3.1 STUN 是什么
STUN 由 RFC 5389 定义，是一个轻量级协议，主要用于：
- 发现 NAT 映射后的公网地址
- 检测 NAT 类型
- 作为 ICE 连通性检查的载体
3.2 STUN 消息头结构
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 字段 | 位数 | 说明 |
|---|---|---|
| 前两位 | 2 | 必须为 00，用于区分其他协议 |
| Message Type | 14 | 消息类型 |
| Message Length | 16 | 消息体长度（不含 20 字节头） |
| Magic Cookie | 32 | 固定值 0x2112A442，用于识别 STUN |
| Transaction ID | 96 | 事务标识，用于请求响应对应 |
3.3 STUN 消息类型
消息类型由类别和方法组成：
类别（Class）：
| 类别 | 值 | 说明 |
|——|—–|——|
| Request | 0x000 | 请求消息 |
| Indication | 0x010 | 指示消息（无响应） |
| Success Response | 0x100 | 成功响应 |
| Error Response | 0x110 | 错误响应 |
常用方法（Method）：
| 方法 | 值 | 说明 |
|——|—–|——|
| Binding | 0x001 | 地址绑定 |
| Allocate | 0x003 | TURN 分配 |
| Refresh | 0x004 | TURN 刷新 |
组合后的消息类型：
| 类型 | 值 | 说明 |
|——|—–|——|
| Binding Request | 0x0001 | 请求映射地址 |
| Binding Success Response | 0x0101 | 返回映射地址 |
| Binding Error Response | 0x0111 | 绑定错误 |
| Binding Indication | 0x0011 | 指示消息（保活） |
3.4 STUN 属性格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 字段 | 说明 |
|---|---|
| Type | 属性类型（16位） |
| Length | 值长度（16位） |
| Value | 属性值（变长，4 字节对齐） |
3.5 常用 STUN 属性
| 属性 | 类型值 | 说明 |
|---|---|---|
| MAPPED-ADDRESS | 0x0001 | NAT 映射后的地址 |
| XOR-MAPPED-ADDRESS | 0x0020 | 异或后的映射地址（推荐） |
| RESPONSE-ORIGIN | 0x802B | 响应来源地址 |
| OTHER-ADDRESS | 0x802C | 其他服务器地址 |
| ERROR-CODE | 0x0009 | 错误代码 |
| SOFTWARE | 0x8022 | 软件标识 |
| FINGERPRINT | 0x8028 | 消息指纹（完整性校验） |
| MESSAGE-INTEGRITY | 0x0008 | 消息完整性（HMAC-SHA1） |
3.6 XOR-MAPPED-ADDRESS 结构
使用异或编码防止 NAT 设备修改地址：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (IPv4 / IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Family: 0x01=IPv4, 0x02=IPv6
- X-Port: 端口异或 Magic Cookie 高 16 位
- X-Address: 地址异或 Magic Cookie（IPv4）或 Magic Cookie + Transaction ID（IPv6）
3.7 STUN 工作流程
sequenceDiagram
participant C as 客户端
participant N as NAT
participant S as STUN 服务器
C->>N: Binding Request<br>源: 192.168.1.100:5000
N->>S: 转发<br>源: 203.0.113.1:12345
S->>S: 记录来源地址
S->>N: Binding Success Response<br>XOR-MAPPED-ADDRESS: 203.0.113.1:12345
N->>C: 转发
C->>C: 得知公网地址
4. TURN（Traversal Using Relays around NAT）
4.1 TURN 是什么
TURN 由 RFC 8656 定义，当 P2P 连接无法建立时（如对称 NAT、防火墙限制），TURN 服务器充当中继转发所有流量。
TURN 的特点：
- 作为最后的穿透手段
- 服务器转发所有流量
- 需要用户认证
- 支持多种传输方式（UDP/TCP/TLS）
4.2 TURN 分配流程
sequenceDiagram
participant C as 客户端
participant T as TURN 服务器
C->>T: Allocate Request
T->>T: 验证认证信息
T->>C: Allocate Success Response<br>返回中继地址
Note over C: 获得中继地址<br>例如: 198.51.100.1:50000
C->>T: CreatePermission Request<br>指定对端地址
T->>C: CreatePermission Success
C->>T: ChannelBind Request<br>绑定通道号
T->>C: ChannelBind Success
Note over C,T: 可以通过通道发送数据
4.3 TURN 消息类型
| 类型 | 值 | 说明 |
|---|---|---|
| ALLOCATE | 0x0003 | 请求分配中继地址 |
| REFRESH | 0x0004 | 刷新分配 |
| SEND | 0x0006 | 发送数据 |
| DATA | 0x0007 | 接收数据指示 |
| CREATE-PERMISSION | 0x0008 | 创建权限 |
| CHANNEL-BIND | 0x0009 | 绑定通道 |
4.4 TURN 属性
| 属性 | 类型值 | 说明 |
|---|---|---|
| REQUESTED-TRANSPORT | 0x0019 | 请求的传输协议 |
| LIFETIME | 0x000D | 分配有效期 |
| XOR-RELAYED-ADDRESS | 0x0016 | 中继地址 |
| XOR-PEER-ADDRESS | 0x0012 | 对端地址 |
| DATA | 0x0013 | 数据内容 |
| CHANNEL-NUMBER | 0x000C | 通道号 |
4.5 两种数据发送方式
Send/Data 方式：
- 每次发送都需要指定目标地址
- 消息较大，效率较低
Channel 方式：
- 预先绑定通道号和对端地址
- 使用更紧凑的消息格式
- 推荐用于频繁通信
ChannelData 消息格式:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.6 TURN 中继通信流程
sequenceDiagram
participant A as 客户端A
participant T as TURN服务器
participant B as 客户端B
A->>T: Allocate
T->>A: 中继地址: R1
A->>T: ChannelBind (目标: B)
T->>A: 通道号: 0x4000
B->>T: Allocate
T->>B: 中继地址: R2
Note over A,B: 通过 TURN 中继通信
A->>T: ChannelData [0x4000] + 数据
T->>T: 查找通道绑定的目标
T->>B: Data (来源: R1)
B->>T: Send (目标: R1)
T->>A: Data (来源: R2)
4.7 TURN vs STUN 对比
| 特性 | STUN | TURN |
|---|---|---|
| 用途 | 发现公网地址 | 中继转发流量 |
| 协议基础 | STUN | STUN 扩展 |
| 连接成功率 | ~80% | ~100% |
| 服务器负载 | 极低 | 高（转发所有流量） |
| 带宽成本 | 无 | 高 |
| 延迟 | 低（P2P 直连） | 较高（经过中继） |
| 部署成本 | 低 | 高 |
5. DTLS（Datagram Transport Layer Security）
5.1 DTLS 是什么
DTLS 是 TLS 的 UDP 版本，由 RFC 6347 定义。WebRTC 使用 DTLS 进行：
- 密钥交换
- 身份验证
- 建立加密上下文
为什么 WebRTC 不直接用 TLS？
- TLS 基于 TCP，需要可靠传输
- WebRTC 使用 UDP 实现低延迟
- DTLS 在 UDP 上实现了 TLS 的安全特性
5.2 DTLS 与 TLS 的区别
| 特性 | TLS | DTLS |
|---|---|---|
| 传输协议 | TCP | UDP |
| 消息顺序 | 保证 | 不保证 |
| 消息可靠性 | 保证 | 需自行处理 |
| 分片 | 不需要 | 需要处理 MTU |
| 重传 | TCP 处理 | DTLS 自己实现 |
5.3 DTLS 记录层
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
| 字段 | 说明 |
|---|---|
| type | 内容类型（握手/告警/应用数据等） |
| version | 协议版本 |
| epoch | 加密周期，密钥更新后递增 |
| sequence_number | 序列号，用于重放检测 |
| length | 片段长度 |
| fragment | 实际内容 |
5.4 DTLS 握手流程
sequenceDiagram
participant C as 客户端
participant S as 服务器
C->>S: ClientHello<br>支持的加密套件、随机数
S->>C: HelloVerifyRequest<br>Cookie（防 DoS）
C->>S: ClientHello + Cookie
S->>C: ServerHello<br>选中的加密套件、随机数
S->>C: Certificate<br>服务器证书
S->>C: ServerKeyExchange<br>密钥交换参数
S->>C: CertificateRequest（可选）
S->>C: ServerHelloDone
C->>S: Certificate（可选）
C->>S: ClientKeyExchange<br>密钥材料
C->>S: CertificateVerify（可选）
C->>S: ChangeCipherSpec
C->>S: Finished（加密）
S->>C: ChangeCipherSpec
S->>C: Finished（加密）
Note over C,S: 加密通信开始
5.5 DTLS 1.3 vs DTLS 1.2
| 特性 | DTLS 1.2 | DTLS 1.3 |
|---|---|---|
| 握手延迟 | 2 RTT | 1 RTT |
| 加密握手消息 | 部分 | 全部（除必要明文） |
| 0-RTT 数据 | 不支持 | 支持 |
| 密钥派生 | PRF | HKDF |
5.6 DTLS 与 SRTP 的密钥关系
flowchart LR
A[DTLS 握手] --> B[协商主密钥]
B --> C[密钥派生]
C --> D[SRTP 密钥]
C --> E[SRTCP 密钥]
D --> F[SRTP 加密]
E --> G[SRTCP 加密]
DTLS 握手完成后，使用 exporter 接口导出 SRTP 所需的密钥材料：
- 加密密钥（用于 AES 等算法）
- 盐值（Salt）
- 认证密钥（用于 HMAC）
5.7 证书指纹
SDP 中的 fingerprint 属性包含 DTLS 证书的哈希值：
a=fingerprint:sha-256 26:FC:29:E8:56:49:3D:ED:4F:A7:2F:A9:7B:7E:4C:2B:...
作用：
- 通过信令通道传递证书指纹
- 验证 DTLS 握手对端身份
- 防止中间人攻击
6. SRTP（Secure Real-time Transport Protocol）
6.1 SRTP 是什么
SRTP 由 RFC 3711 定义，是 RTP 的安全扩展，提供：
- 机密性保护：加密媒体数据
- 消息认证：防止篡改
- 重放保护：防止重放攻击
6.2 SRTP 包结构
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Extension (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 部分 | 说明 |
|---|---|
| RTP Header | 12 字节固定头部 |
| CSRC | 贡献源列表（可选） |
| Extension | 扩展头部（可选） |
| Payload | 加密后的媒体数据 |
| Auth Tag | 认证标签 |
6.3 SRTP 加密流程
flowchart LR
A[原始 RTP<br>Header + Payload] --> B[加密 Payload]
B --> C[计算 Auth Tag<br>覆盖 Header + 加密 Payload]
C --> D[SRTP 包<br>Header + Encrypted + Auth Tag]
关键点：
- RTP 头部不加密（路由需要）
- 仅加密 Payload
- 认证覆盖整个包（除 Auth Tag）
6.4 加密算法
| 加密套件 | 加密算法 | 认证算法 | Auth Tag 长度 |
|---|---|---|---|
| AES_CM_128_HMAC_SHA1_80 | AES-128 Counter Mode | HMAC-SHA1 | 80 bits |
| AES_CM_128_HMAC_SHA1_32 | AES-128 Counter Mode | HMAC-SHA1 | 32 bits |
| AEAD_AES_128_GCM | AES-128 GCM | GCM | 128 bits |
| AEAD_AES_256_GCM | AES-256 GCM | GCM | 128 bits |
6.5 序列号与重放保护
SRTP 使用滑动窗口机制防止重放：
滑动窗口
+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
+---+---+---+---+---+---+---+---+---+
^
当前最高序列号
- 收到包的序列号 < 窗口最小值：丢弃（可能的重放）
- 序列号在窗口内且已收到：丢弃（重复）
- 序列号 > 当前最高：滑动窗口
6.6 密钥派生
SRTP 从主密钥派生多个密钥：
flowchart TB
A[主密钥 Master Key] --> B[加密密钥]
A --> C[盐值 Salt]
A --> D[认证密钥]
E[主盐值 Master Salt] --> C
每个加密上下文包含：
- 加密密钥（16/32 字节）
- 盐值（14 字节）
- 认证密钥（20/32 字节）
7. SRTCP（Secure RTCP）
7.1 SRTCP 结构
SRTCP 在 RTCP 基础上添加安全字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTCP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRTCP Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRTCP Index 是一个 31 位的计数器，用于加密和重放保护。
8. 协议协作流程
8.1 完整连接建立流程
sequenceDiagram
participant A as 用户A
participant S as 信令服务器
participant ST as STUN/TURN
participant B as 用户B
Note over A,B: 1. 媒体协商（通过信令）
A->>S: Offer SDP
S->>B: 转发
B->>S: Answer SDP
S->>A: 转发
Note over A,B: 2. ICE 候选收集
A->>ST: STUN Binding Request
ST->>A: 公网地址
A->>A: 收集 Host/SRFLX/Relay
A->>S: ICE Candidates
S->>B: 转发
B->>ST: STUN Binding Request
ST->>B: 公网地址
B->>B: 收集 Host/SRFLX/Relay
B->>S: ICE Candidates
S->>A: 转发
Note over A,B: 3. ICE 连通性检查
A->>B: STUN Connectivity Check
B->>A: STUN Response
B->>A: STUN Connectivity Check
A->>B: STUN Response
Note over A,B: 选定路径
Note over A,B: 4. DTLS 握手
A->>B: DTLS ClientHello
B->>A: DTLS ServerHello + Certificate
A->>B: DTLS KeyExchange + Finished
B->>A: DTLS Finished
Note over A,B: 密钥协商完成
Note over A,B: 5. SRTP 媒体传输
A->>B: SRTP 加密媒体
B->>A: SRTP 加密媒体
8.2 数据包层次关系
flowchart TB
subgraph 应用数据
A1[视频/音频帧]
end
subgraph RTP层
B1[RTP Header]
B2[Payload]
end
subgraph SRTP层
C1[加密后的 Payload]
C2[Auth Tag]
end
subgraph UDP层
D1[UDP Header]
D2[UDP Data]
end
A1 --> B2
B1 --> C1
B2 --> C1
C1 --> D2
C2 --> D2
8.3 时间关系
| 阶段 | 典型时间 |
|---|---|
| ICE 收集 | 100-500ms |
| 连通性检查 | 50-200ms |
| DTLS 握手 | 50-100ms |
| 首帧显示 | 总计 200-1000ms |
9. 安全性考虑
9.1 多层安全防护
| 层次 | 协议 | 保护目标 |
|---|---|---|
| 网络层 | ICE | 防止 IP 欺骗 |
| 传输层 | DTLS | 密钥安全、身份验证 |
| 媒体层 | SRTP | 数据加密、完整性 |
9.2 常见安全威胁与防护
| 威胁 | 说明 | 防护措施 |
|---|---|---|
| 中间人攻击 | 攻击者冒充对端 | 证书指纹验证 |
| 重放攻击 | 重放历史数据包 | SRTP 序列号窗口 |
| 数据篡改 | 修改传输内容 | Auth Tag 验证 |
| DoS 攻击 | 耗尽服务器资源 | STUN Cookie 机制 |
10. 总结
| 协议 | 作用 | 关键点 |
|---|---|---|
| ICE | 连接协调 | 候选收集、连通性检查、路径选择 |
| STUN | 地址发现 | 轻量级、高成功率 |
| TURN | 中继转发 | 最后手段、100% 成功 |
| DTLS | 安全握手 | UDP 版 TLS、密钥协商 |
| SRTP | 媒体加密 | 低开销、重放保护 |
关键点：
- ICE 框架：整合 STUN/TURN，自动化 NAT 穿透
- STUN 轻量：只发现地址，不中继流量
- TURN 兜底：当 P2P 不通时保证连接
- DTLS 密钥：在 UDP 上实现安全握手
- SRTP 加密：保护媒体数据，认证防篡改
下一章将介绍视频编码技术。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 青羽川！
wechat- alipay
相关推荐
评论