WebRTC STUN简介(WebRTC网络基础知识)

STUN（NAT 会话传输实用程序）是一种用来配合 NAT 使用的协议。这是 WebRTC（和 ICE！）之前的另一项技术。它由RFC 8489定义，该文件还定义了 STUN 数据包结构。STUN 协议也在 ICE/TURN 中被使用。

STUN 很有用，因为它允许以编程方式创建 NAT 映射。在 STUN 之前，我们能够创建 NAT 映射，但是我们不知道映射的 IP 和端口是什么！STUN 不仅使你能够创建映射，还可以让你获取映射的详细信息，你可以他人分享这些详细信息，然后他们便可以通过你刚刚创建的映射向你传回数据。

让我们从对 STUN 的基本描述开始。稍后，我们再将话题扩展到 TURN 和 ICE 的用法。现在，我们只打算描述请求 / 响应流程来创建映射。然后，我们将讨论如何获取该映射的详细信息以便与他人共享。当你在 ICE URLs 中有一个用于 WebRTC PeerConnection 的 stun: 服务器时，此过程就会发生。简而言之，STUN 向 NAT 外部的 STUN 服务器发送请求，服务器返回其在请求中观察到的内容，STUN 根据这些内容来帮助 NAT 后面的端点找出已创建的映射。

STUN协议结构

每个 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)                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STUN 消息类型

每个 STUN 数据包都有一个类型。目前，我们仅关心以下几种：

Binding Request – 0x0001
Binding Response – 0x0101

为了创建一个 NAT 映射，我们发出一个 Binding Request。然后服务器回应一个 Binding Response。

消息长度

这就是 Data 段的长度。这一段中包含由消息类型所定义的任意数据。

指的是固定值 0x2112A442，以网络字节顺序发送。这个值有助于将 STUN 流量与其他协议区分开。

交互（Transaction）ID

一个 96-bit 的标识符，用于唯一标识一个请求 / 响应对。这可以帮助你配对请求和响应。

数据

数据将包含一个 STUN 属性的列表。一个 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)                ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STUN Binding Request 不使用任何属性。这意味着一个 STUN Binding Request 仅包含 header。

STUN Binding Response 使用一个 XOR-MAPPED-ADDRESS (0x0020)。此属性包含一个 IP 和一个端口。这正是所创建的 NAT 映射的 IP 和端口！

创建 NAT 映射

使用 STUN 创建 NAT 映射只需要发送一个请求！你向 STUN 服务器发送一个 STUN Binding Request。然后，STUN 服务器回应一个 STUN Binding Response。该 STUN Binding Response 将包含映射地址。映射地址是 STUN 服务器看到你的方式，也是你的 NAT 映射。如果你希望某人向你发送数据包，那么你应该共享该映射地址。

人们还会将映射地址称为公网 IP 或 Server Reflexive Candidate。

确定 NAT 类型

不幸的是，映射地址可能并非在所有情况下都可用。如果是地址相关的映射，则只有 STUN 服务器才能将流量发送回给你。如果你共享它，那么另一个 peer 尝试向该地址发送的消息将被丢弃。这使得该 peer 无法与别的 peer 交流。如果 STUN 服务器还可以为你将数据包转发给对端 peer，你可能会发现地址相关的映射问题实际上是可以解决的！这也就是下面将要说到的 TURN 解决方案。

RFC 5780定义了一种方法，可以运行一个测试来确定你的 NAT 类型。这很有用，因为你可能会提前知道是否可以进行直接连接。