当前位置：首页 > news >正文

WebRTC学习七：WebRTC 中 STUN 协议详解

news 来源：原创 2025/9/15 22:27:07

系列文章目录

第一篇基于SRS 的 WebRTC 环境搭建
第二篇基于SRS 实现RTSP接入与WebRTC播放
第三篇 centos下基于ZLMediaKit 的WebRTC 环境搭建
第四篇 WebRTC学习一：获取音频和视频设备
第五篇 WebRTC学习二：WebRTC音视频数据采集
第六篇 WebRTC学习三：WebRTC音视频约束
第七篇 WebRTC学习四：WebRTC常规视觉滤镜
第八篇 WebRTC学习五：从视频中提取图片
第九篇 WebRTC学习六：MediaStream 常用API介绍
第十篇 WebRTC学习七：WebRTC 中 STUN 协议详解

文章目录

系列文章目录
前言
一、STUN 协议的作用
二、STUN 协议的交互过程
- 1.客户端与 STUN 服务器的交互
- - (1) 客户端发送请求：
  - (2) STUN 服务器处理请求：
  - (3) STUN 服务器返回响应：
  - (4) 客户端获取公网地址：
- 2.客户端之间的交互准备
三、STUN 协议报文格式详解
- STUN Message Header（RFC5389/RFC8489）
- STUN Message Body
四、zlmediakit 中STUN 协议抓包
- 在这里插入图片描述
总结

前言

最近在看zlmediakit源码，发现webrtc部分涉及到STUN和DTLS协议，为了更方便的看懂这部分代码，网上查了下STUN协议和DTLS协议，将STUN协议部分先做个记录，后面结合代码如果有更深入的理解，再来更新其中的内容。

在 WebRTC（Web Real - Time Communication）技术体系里，STUN（Session Traversal Utilities for NAT，NAT 会话穿越应用程序）协议发挥着关键作用。WebRTC 旨在实现浏览器之间的实时音视频通信，但由于网络中广泛存在的 NAT（网络地址转换）设备，会对直接通信造成阻碍，而 STUN 协议则是解决这一问题的重要工具。

一、STUN 协议的作用

STUN 协议主要用于帮助处于 NAT 设备之后的客户端发现自己的公网 IP 地址和端口，也就是确定自己在公网上的可达地址。这样，即使客户端处于私有网络中，也能让对端知道如何与自己建立直接的连接，从而实现 WebRTC 通信的端到端连接。

二、STUN 协议的交互过程

1.客户端与 STUN 服务器的交互

(1) 客户端发送请求：

处于 NAT 之后的客户端向 STUN 服务器发送一个 Binding Request（绑定请求）消息。这个请求消息中包含了客户端的一些信息，例如客户端希望服务器返回的信息类型等。

(2) STUN 服务器处理请求：

STUN 服务器接收到请求后，会记录下接收到该请求的源 IP 地址和端口，这就是客户端经过 NAT 转换后的公网地址和端口。

(3) STUN 服务器返回响应：

STUN 服务器将客户端的公网地址和端口信息封装在 Binding Response（绑定响应）消息中，发送回客户端。

(4) 客户端获取公网地址：

客户端接收到响应消息后，就可以从消息中提取出自己的公网地址和端口信息，并将这些信息用于后续的 WebRTC 通信。

2.客户端之间的交互准备

客户端获取到公网地址和端口后，会将这些信息通过信令服务器发送给对端客户端。对端客户端收到信息后，就可以尝试与该客户端建立直接的连接。

三、STUN 协议报文格式详解

RFC5389(Session Traversal Utilities for NAT)是在RFC3489（Simple Traversal of UDP Through NAT）的基础上增加了对TCP的支持，使其不仅适用于UDP，还适用于TCP协议，从而提供更全面的NAT穿越解决方案‌。具体来说，RFC5389将STUN描述为一系列穿越NAT的工具，而不仅仅是基于UDP的简单穿透方法‌。
相比之下，RFC8489是对RFC5389的进一步扩展和标准化，但它并没有引入新的功能或协议变化，而是对现有的STUN协议进行了标准化和规范化‌。

目前RFC3489已经废弃，更多的用的是RFC5389和RFC8489。
STUN协议包含20字节的STUN Message header和STUN Message Body部分，body中可以含有0或多个Attribute.

STUN Message Header（RFC5389/RFC8489）

在这里插入图片描述

STUN 报文的头部固定为 20 字节，其具体含义如下：

最前面的2bit 00：不同的协议复用同一端口时，用于与其它协议做区分。

STUN Message Type：STUN 消息类型，定义了消息 class 和消息 method，用于标识该消息是请求、响应还是错误消息等。STUN Message Type的结构如下
在这里插入图片描述
其中C0和C1合起来定义class，M0-M11 定义了method。class 四个值定义如下表：

C1C0的值	含义
0b00	request
0b01	indication
0b10	success response
0b11	error response

method只定义了一个方法，即Binding,0b000000000001(0x0001);
因此Binding的request的消息类型为0x0001,Binding的success response的消息类型为0x0101。

Message Length(2 字节）:：消息长度，表示整个消息除去头部的长度，单位为字节。
Magic Cookie（4 字节）：固定值 0x2112A442，用于快速识别 STUN 消息。
Transaction ID（96bit, 12 字节）：用于唯一标识一个事务，客户端和服务器通过这个 ID 来匹配请求和响应。

STUN Message Body

20字节的STUN消息头之后是0个或者多个属性。每个属性进行TLV编码，每个属性的长度不固定，但都是 4 字节的整数倍。
属性的结构如下

在这里插入图片描述
Type(2 字节）:：16字节属性类型。
Length（4 字节）：属性长度，Value的长度，单位是字节，必须是4字节的整数倍。
Value：属性的数据。

属性定义表

Type	属性名	含义	备注
0x0001	MAPPED-ADDRESS	表示服务器观察到的客户端经NAT转换后的外网地址和端口，主要用于兼容遵循RFC 3489的旧版STUN客户端。
0x0002	RESPONSE - ADDRESS	客户端通过此属性告知服务器将响应消息发送到指定的地址和端口，即客户端期望接收响应的目标地址。
0x0003	CHANGE - REQUEST	客户端使用该属性请求服务器在发送响应时变更IP地址、端口或两者都变更，用于检测NAT的行为。
0x0004	SOURCE - ADDRESS	服务器发送响应消息时所使用的源地址和端口，客户端可以通过该属性了解服务器的实际发送地址。
0x0005	CHANGED - ADDRESS	服务器告知客户端，如果客户端发送CHANGE - REQUEST请求，服务器将使用此地址和端口发送响应，是服务器的备用响应地址。
0x0006	USERNAME	用于消息完整性检查和认证过程，标识消息完整性验证中使用的用户名，该值为可变长度的UTF - 8编码序列，且需经过SASLprep处理。
0x0007	PASSWORD	与认证相关，通常与USERNAME属性配合使用，用于验证客户端身份，但在RFC 5389中较少直接使用，更多结合其他认证机制。
0x0008	MESSAGE-INTEGRITY	该属性包含STUN消息的HMAC - SHA1哈希值（20字节），用于确保消息在传输过程中未被篡改，保证消息的完整性和真实性。
0x0009	ERROR-CODE	用于错误响应消息，包含一个300到699范围内的数字错误代码，以及一个UTF - 8编码的文本短语，用于描述错误的具体信息。
0x000A	UNKNOWN-ATTRIBUTES	当服务器收到包含其不识别属性的STUN消息时，会在错误码为420的错误响应中使用该属性列出这些未知属性的类型。
0x000C	REFLECTED - FROM	指示STUN消息是从哪个地址反射过来的，通常用于记录消息的传输路径信息。
0x0014	REALM	可出现在请求和响应消息中，包含符合特定语法的文本，用于长期凭据认证。它是一个UTF - 8编码序列，长度少于128个字符，且经过SASLprep处理，出现该字段表示使用长期凭据认证方式。
0x0015	NONCE	由服务器生成的一个可变长度的不透明值，用于防止重放攻击。客户端在后续请求中需要包含相同的NONCE值，服务器通过检查NONCE值确保消息的新鲜性和唯一性。	需UTF - 8编码且经SASLprep处理
0x001C	MESSAGE-INTEGRITY-SHA256	与MESSAGE - INTEGRITY类似，但使用SHA256算法计算消息的HMAC哈希值，提供更高的安全性，用于保证消息的完整性。
0x001D	PASSWORD-ALGORITHM	用于指定认证过程中所使用的密码算法，告知对端采用何种加密算法对密码进行处理和验证。
0x001E	USERHASH	对用户名进行哈希处理后的值，用于在不直接传输明文用户名的情况下进行用户标识和认证，增强了用户信息的安全性。
0x0020	XOR - MAPPED - ADDRESS	是MAPPED - ADDRESS的改进版本，使用XOR运算对地址和端口进行加密处理，提高了地址信息在传输过程中的安全性，避免地址信息被轻易截取和分析。	格式见后面
0x0024	PRIORITY	在ICE（交互式连接建立）过程中，用于指示候选地址的优先级。客户端会收集多个候选地址，每个地址都有对应的优先级，服务器或对端可根据该优先级决定优先使用哪个候选地址建立连接。	RFC 8445 ICE 扩展定义
0x0025	USE-CANDIDATE	用于通知对端立即使用指定的ICE候选地址对进行连接，跳过部分候选地址筛选和验证过程，加速连接的建立。	RFC 8445 ICE 扩展定义
0x8002	PASSWORD-ALGORITHMS	列出服务器支持的所有密码算法，客户端可以根据这些信息选择合适的算法进行认证。
0x8003	ALTERNATE-DOMAIN	提供一个备用的域名，用于在主域名不可用时作为替代，可能用于引导客户端到备用的服务或资源。
0x8022	SOFTWARE	携带生成该STUN消息的软件或设备的相关信息，如软件名称、版本号等，有助于网络故障排查和统计分析。
0x8023	ALTERNATE - SERVER	提供备用的STUN或TURN服务器地址，当主服务器不可用时，客户端可以尝试连接这些备用服务器。
0x8028	FINGERPRINT	对消息计算的CRC - 32值，用于快速验证消息完整性。接收方重新计算CRC - 32值并与该属性值比较，若一致则消息未被篡改。
0x8029	ICE-CONTROLLED	在ICE连接建立过程中，标识一个端点处于受控（Controlled）角色，该端点需遵循控制者端点的决策来建立连接。	RFC 8445 ICE 扩展定义
0x802A	ICE-CONTROLLING	在ICE连接建立过程中，标识一个端点处于控制（Controlling）角色，该端点负责协调和决定使用哪个候选地址对来建立连接。	RFC 8445 ICE 扩展定义

四、zlmediakit 中STUN 协议抓包

总结

STUN 协议在 WebRTC 通信中是实现端到端连接的重要基础。通过客户端与 STUN 服务器的交互，客户端能够发现自己的公网地址和端口，为后续的直接通信提供了可能。了解 STUN 协议的交互过程和报文格式，对于深入研究 WebRTC 技术具有重要意义。