1.STUN协议介绍：
STUN存在的目的就是进行NAT穿越。
STUN是典型的客户端/服务端模式。客户端发送请求，服务端进行响应。
2.RFC STUN规范
RFC3489/STUN
Simple Traversal of UDP Through NAT
RFC5389/STUN
Session Traversal Utilities for NAT
3.STUN协议：
3.1.包括20字节的STUN header
3.2.Body中可以有0个或多个Attribute
4.STUN header格式
1）最高的2位必须置零，这可以在当STUN和其他协议复用的时候，用来区分STUN包和其他数据包。
2）STUN Message Type 字段定义了消息的类型（请求/成功响应/失败响应/指示）和消息的主方法。
虽然我们有4个消息类别，但在STUN中只有两种类型的事务，即请求/响应类型和指示类型。响应类型分为成功和出错两种，用来帮助快速处理STUN信息。Message Type字段又可以进一步分解为如下结构：
其中显示的位为从最高有效位M11到最低有效位M0，M11到M0表示方法的12位编码。C1和C0两位提示消息是什么类型。
C0C1：
0b00:表式是一个请求 ； 0b01:表式是一个指示；0b10:表式是请求成功的响应；0b11:表式是请求失败的响应
例：
3）Message Length 字段存储了信息的长度，以字节为单位，不包括20字节的STUN头部。由于所有的STUN属性都是都是4字节对齐（填充）的，因此这个字段最后两位应该恒等于零，这也是辨别STUN包的一个方法之一。
4）Magic Cookie 字段包含固定值0x2112A442，这是为了前向兼容RFC3489，因为在classic STUN中，这一区域是事务ID的一部分。另外选择固定数值也是为了服务器判断客户端是否能识别特定的属性。还有一个作用就是在协议多路复用时候也可以将其作为判断标志之一
5）Transaction ID 字段是个96位的标识符，用来区分不同的STUN传输事务。对于request/response传输，事务ID由客户端选择，服务器收到后以同样的事务ID返回response；对于indication则由发送方自行选择。事务ID的主要功能是把request和response联系起来，同时也在防止攻击方面有一定作用。服务端也把事务ID当作一个Key来识别不同的STUN客户端，因此必须格式化且随机在0~2^(96-1)之间。重发同样的request请求时可以重用相同的事务ID，但是客户端进行新的传输时，必须选择一个新的事务ID。
4字节，32位，固定值0x2112A442。通过它可以判断客户端是否可以支持某些属性。
12字节，96位，标识同一个事务的请求和响应。
4.STUN Message Body
消息头后有0或多个属性
每个属性进行TLV编码： type, length,value
4.1.TLV格式：
RFC3489定义的属性：
Attribute的使用：