WebRTC建立流程详解 - 基于WHEP协议
目录
WebRTC建立流程概述
整体流程
WHEP（WebRTC-HTTP Egress Protocol）是WebRTC的HTTP出口协议，主要用于从服务器向客户端推送媒体流。整个建立流程可以分为以下几个阶段：
1. 初始协商 (HTTP信令)
↓
2. ICE候选收集和交换
↓
3. ICE连接建立
↓
4. DTLS握手
↓
5. 媒体流传输
详细建立流程
阶段1：初始协商
-
客户端发起请求
- 客户端向服务器发送HTTP POST请求到WHEP端点
- 请求中包含SDP offer（会话描述协议）
-
服务器响应
- 服务器处理SDP offer
- 生成SDP answer
- 返回包含SDP answer的HTTP响应
阶段2：ICE候选收集和交换
-
ICE候选收集开始
- ICE在SDP交换完成后立即发起
- 客户端和服务器同时开始收集ICE候选
- 这是整个流程中最关键的部分
-
STUN服务器交互
- STUN在ICE候选收集阶段发生
- 客户端向STUN服务器发送Binding Request
- STUN服务器返回客户端的公网IP和端口
- 用于发现NAT后的网络地址
-
TURN服务器交互（如果需要）
- TURN在STUN无法建立连接时发生
- 当客户端在对称NAT后面时，STUN可能失败
- 客户端向TURN服务器请求中继候选
- TURN服务器提供中继地址和端口
阶段3：ICE连接建立
-
ICE候选交换
- 客户端和服务器通过信令通道交换ICE候选
- 候选包括：主机候选、服务器反射候选、中继候选
-
ICE连接检查
- 双方开始ICE连接检查
- 按优先级顺序尝试连接
- 找到可用的连接对
-
DTLS握手
- ICE连接建立后，开始DTLS握手
- 建立安全的媒体传输通道
ICE、STUN、TURN的时机
关键时机总结
| 阶段 | 时机 | 说明 |
|---|---|---|
| ICE发起 | SDP交换完成后 | 立即开始收集网络候选 |
| STUN发生 | ICE候选收集阶段 | 用于发现公网地址 |
| TURN发生 | STUN失败时 | 作为中继备选方案 |
ICE和STUN的关系
重要理解：STUN是ICE的一部分！
- ICE（Interactive Connectivity Establishment）：是一个完整的框架，用于建立网络连接
- STUN（Session Traversal Utilities for NAT）：是ICE框架中使用的工具之一
ICE候选收集过程
ICE候选收集过程
↓
┌─────────────────────────────────┐
│ 1. 收集主机候选 (Host Candidates) │
│ - 本地网络接口地址 │
│ - 不需要STUN │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. 收集服务器反射候选 │
│ (Server Reflexive Candidates) │
│ - 使用STUN服务器 │
│ - 发现NAT后的公网地址 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 3. 收集中继候选 (Relay Candidates)│
│ - 使用TURN服务器 │
│ - 当STUN失败时使用 │
└─────────────────────────────────┘
WHEP协议中的NAT穿透需求
重要澄清：WHEP协议虽然使用HTTP进行信令交换，但媒体流传输仍然需要点对点的UDP连接！
WHEP协议的两个阶段：
┌─────────────────────────────────┐
│ 1. 信令阶段 (HTTP) │
│ - SDP交换 │
│ - ICE候选交换 │
│ - 服务器可访问，无需NAT穿透 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. 媒体传输阶段 (UDP) │
│ - RTP/RTCP媒体流 │
│ - 需要点对点连接 │
│ - 仍然需要NAT穿透 │
└─────────────────────────────────┘
WHEP协议详解
WHEP协议特点
- HTTP-based：使用标准HTTP协议，易于部署
- 单向流：主要用于服务器向客户端推送媒体
- 简化信令：相比传统WebRTC，信令更简单
- 服务器控制：服务器控制媒体流的开始和结束
WHEP协议中的ICE候选交换
HTTP请求中的ICE候选
POST /whep/endpoint HTTP/1.1
Content-Type: application/sdp
v=0
o=- 1234567890 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:4Zc8
a=ice-pwd:2/1muCWoOi3JmS5+5vY7Q
a=ice-options:trickle
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:00:BC:1F:8A:0B:3C:19:27:1D:4C:9A:5F:16:17:1E:2A:2B:2C:2D
a=setup:actpass
a=mid:0
a=sctp-port:5000
a=max-message-size:262144
# ICE候选信息
a=candidate:1 1 UDP 2113667326 192.168.1.100 5000 typ host
a=candidate:2 1 UDP 1694498814 203.0.113.1 5000 typ srflx raddr 192.168.1.100 rport 5000
a=candidate:3 1 UDP 16777215 203.0.113.2 3478 typ relay raddr 203.0.113.1 rport 5000
ICE候选交换机制
ICE候选的定义
**ICE候选（ICE Candidate）**是WebRTC中用于建立网络连接的网络地址信息，包含了：
- IP地址
- 端口号
- 协议类型
- 候选类型
- 优先级
ICE候选的类型
ICE候选类型：
┌─────────────────────────────────┐
│ 1. 主机候选 (Host Candidate) │
│ - 本地网络接口地址 │
│ - 例：192.168.1.100:5000 │
│ - 优先级：最高 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. 服务器反射候选 │
│ (Server Reflexive Candidate) │
│ - 通过STUN发现的公网地址 │
│ - 例：203.0.113.1:5000 │
│ - 优先级：中等 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 3. 中继候选 (Relay Candidate) │
│ - 通过TURN服务器中继 │
│ - 例：203.0.113.2:3478 │
│ - 优先级：最低 │
└─────────────────────────────────┘
ICE候选的格式
a=candidate:<foundation> <component> <protocol> <priority> <ip> <port> typ <type> [raddr <raddr>] [rport <rport>]
字段说明：
foundation: 候选的基础标识符component: 组件ID (1=RTP, 2=RTCP)protocol: 协议类型 (UDP/TCP)priority: 优先级 (数值越大优先级越高)ip: IP地址port: 端口号typ: 候选类型 (host/srflx/relay)raddr: 相关地址 (可选)rport: 相关端口 (可选)
连接建立和数据交换
STUN服务器的工作原理
重要理解：STUN服务器本身不知道客户端要进行WebRTC通信！
STUN服务器的工作：
┌─────────────────────────────────┐
│ 1. 接收Binding Request │
│ 2. 返回客户端的公网IP和端口 │
│ 3. 不关心客户端要做什么 │
└─────────────────────────────────┘
ICE连接检查阶段
ICE连接检查的工作原理
ICE连接检查过程：
┌─────────────────────────────────┐
│ 1. 双方都有候选列表 │
│ - 主机候选 │
│ - 服务器反射候选 │
│ - 中继候选 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. 按优先级尝试连接 │
│ - 尝试所有候选组合 │
│ - 发送STUN Binding Request │
│ - 等待STUN Binding Response │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 3. 找到可用连接对 │
│ - 双方都能收到对方的消息 │
│ - 建立双向连接 │
└─────────────────────────────────┘
ICE连接状态管理
ICE连接状态：
┌─────────────────────────────────┐
│ 1. ICE Gathering │
│ - 收集候选阶段 │
│ - 状态：gathering │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. ICE Checking │
│ - 连接检查阶段 │
│ - 状态：checking │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 3. ICE Connected │
│ - 连接建立成功 │
│ - 状态：connected │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 4. ICE Completed │
│ - 连接完成 │
│ - 状态：completed │
└─────────────────────────────────┘
数据交换开始
ICE连接建立后：
┌─────────────────────────────────┐
│ 1. 开始DTLS握手 │
│ - 建立安全通道 │
│ - 交换证书和密钥 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. DTLS握手完成 │
│ - 安全通道建立 │
│ - 可以开始媒体传输 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 3. 开始RTP/RTCP传输 │
│ - 音频/视频数据 │
│ - 控制信息 │
└─────────────────────────────────┘
协议规范和标准
ICE协议标准
**ICE（Interactive Connectivity Establishment）**有明确的RFC标准：
ICE协议标准：
┌─────────────────────────────────┐
│ RFC 5245: ICE │
│ - 交互式连接建立协议 │
│ - 2008年发布 │
│ - 定义了完整的ICE流程 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ RFC 8445: ICE 2.0 │
│ - ICE协议的第二版 │
│ - 2018年发布 │
│ - 简化了ICE流程 │
└─────────────────────────────────┘
ICE协议的核心组件
ICE协议包含：
┌─────────────────────────────────┐
│ 1. STUN (RFC 5389) │
│ - 会话遍历工具 │
│ - 用于NAT穿透 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 2. TURN (RFC 5766) │
│ - 中继遍历工具 │
│ - 用于对称NAT穿透 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 3. ICE连接检查 │
│ - 候选对检查 │
│ - 连接建立确认 │
└─────────────────────────────────┘
协议层次关系
协议层次结构：
┌─────────────────────────────────┐
│ 应用层：WHEP协议 │
│ - HTTP请求/响应 │
│ - SDP格式 │
│ - ICE候选交换 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 信令层：SDP协议 │
│ - 会话描述协议 │
│ - 媒体信息交换 │
│ - ICE候选信息 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 连接层：ICE协议 │
│ - RFC 5245标准 │
│ - 连接建立机制 │
│ - 候选收集和检查 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 传输层：STUN/TURN协议 │
│ - RFC 5389 (STUN) │
│ - RFC 5766 (TURN) │
│ - NAT穿透机制 │
└─────────────────────────────────┘
总结
关键理解点
- WHEP协议使用HTTP进行信令交换，但媒体流传输仍然需要UDP点对点连接
- STUN是ICE的一部分，用于发现NAT后的网络地址
- ICE有明确的RFC 5245协议标准，WHEP协议规定了如何通过HTTP和SDP交换ICE候选信息
- 连接建立需要双向确认，双方都要能收到对方的消息
- 整个流程有明确的状态管理，从候选收集到连接建立再到媒体传输
实际应用场景
WHEP常用于：
- 直播流推送
- 监控视频流
- 远程桌面共享
- 任何需要服务器向客户端推送实时媒体的场景
这个流程确保了WebRTC连接能够在各种网络环境下稳定建立，通过ICE、STUN和TURN的组合，解决了NAT穿透和网络连接的问题。
文档创建时间：2024年
基于WebRTC WHEP协议和ICE连接建立机制
扫一扫
5119
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
