WebRTC实时通信 （四）| STUN协议工作详情
STUN消息是如何形成的
STUN代理创建一个STUN消息。STUN消息类必须是“Request”或“Indication”，方法必须是“binding”或一些其他方法。对于没有auth的binding方法，不需要任何属性。
STUN代理发送请求或指示。STUN消息可以通过
- UDP
- TCP
- 基于TCP的TLS
STUN消息的发送方式
通过UDP协议发送请求
当通过UDP发送数据包时，数据包可能会被丢弃，因为UDP无法保证到达目的地没有故障通知，STUN请求的可靠性必须通过客户端自身重新传输请求消息来实现。
客户端可以从RTO（重传超时）间隔开始重传请求消息，并在每次重传后加倍。重传可以继续，直到接收到响应或者直到由于默认Rc请求是7而已经显示了总Rc请求。
通过TCP或TLS over IP协议发送请求
为了通过TCP传输STUN消息，客户端打开到服务器的TCP连接。
在一些使用情况下，STUN是作为TCP连接上的唯一协议发送的，在这些情况下，可以使用任何附加的成帧或复用来发送STUN。在其他使用情况下，发送STUN，STUN通过TCP连接与其他数据多路复用。
当STUN通过TCP连接与其他数据复用时，需要某种成帧协议，并且STUN在该成帧协议之上运行。该成帧协议允许接收STUN消息。
如果通过TCP运行STUN消息，则必须至少实现RCA密码，但也可以使用其他密码套件。正在接收的STUN消息的可靠性由TCP本身处理，不需要在STUN协议级别进行重传。
对于请求/响应事务，如果客户端无法通过TCP建立连接，或者如果TCP连接重置为失败，则认为请求/响应交易已失败。
客户端可以通过TCP发送多个请求，甚至在接收到响应之前也可以发送多个要求。客户端应保持连接打开，直到所有STUN请求都已通过连接发送。
没有计划使用通过STUN请求或中继地址（TURN）获得的任何其他资源，服务器应保持通信打开，并让客户端终止通信，除非通信超时。
收到STUN消息时如何处理这些消息
当STUN服务器接收到消息时，它会检查以下条件
- 前2位是0吗
- Magic cookie字段的值正确吗
- 消息长度合理吗
- 特定方法是否允许使用消息类
- 消息值是支持的方法吗
- 如果是成功响应或错误响应，则检查transactionID是否与正在处理的当前事务的transactionID相同
- 如果检测到错误，消息将被静默丢弃
- 如果使用了fingerprint 属性，则代理会检查fingerprint 属性是否存在以及是否正确
- 如果存在任何身份验证机制，STUN将检查身份验证
检查完之后开始处理请求
- 检查一个或多个未知的理解所需属性，如果存在，则发送带有代码403的错误响应，并在列出未知属性的响应中包括unknown-ATTRIBUTE响应。
- 进行该方法所需的任何额外检查，并制定成功响应。
制定成功或错误响应
发送成功或错误响应的方法与接收请求的方法相同。
成功响应将数据与成功代码200一起发送。
对于ERROR响应，服务器会在响应中添加一个错误代码属性。还向错误响应中添加了描述错误类型的短语。
