WebRTC基础STUN的⼯作过程和原理
参考⽂档：
【我们这⾥只讨论过程，协议细节请参考 】
我们都知道ipv4中的地址数量是有限，这个限制导致了⼤量的计算机是位于防⽕墙或NAT后⾯的，他们所持有的仅仅是⼀个内⽹IP地址。通常，内⽹的计算机与外部公⽹上的计算机交互是没有问题的，但是当你想让2台在不同内⽹中的计算通信时，问题就来了。 这种通信我们称之为p2p通信，在通信之前我们需要检测他们之间能否进⾏p2p通信以及如何通信。 这就涉及到了NAT穿透的问题了（NAT Traversal）
最常见的NAT穿透是基于UDP的，例如我们将要研究的STUN。
STUN（Simple Traversal of UDP Through NAT）是⼀个完整的NAT穿透解决⽅案，参考
在最新的中，STUN被定位成穿透NAT的⼯具，⽽不再是⼀个解决⽅案，Session Traversal Utilities for NAT.
STUN的⼯作过程
我们先研究STUN是怎样⼀步步实现的NAT穿透的，获得⼀个对STUN的整体的认识。
要研究这个过程，我们先对我们的环境进⾏⼀些假设，这样⽅便进⾏描述：
手机屏幕维修
图1
如图1所⽰，我的客户端位于NAT后⾯， STUN Server位于公⽹中。 具体的IP和端⼝如下：
Client的IP地址和端⼝号为： IP_C 和 Port_C
NAT的映射后的IP和端⼝号为：IP_N 和 Port_N
STUN的IP地址和端⼝为： IP_S1 IP_S2 和 Port_S1 Port_S2
骂街
STEP1：验证客户端是否在NAT后⾯
从客户端发送⼀个UDP包到 IP_S1 + Port_S1， STUN收到后会把 IP_N+Port_N 保存到UDP包中作为对客户端请求的响应。然后把这个响应发送到 IP_N+Port_N。
⽆论客户端前⾯的NAT是什么，客户端都应该能够收到这个响应。 如果没有收到，要么是STUN Server不存在（或者你写错了地址或端⼝）， 要么是你的NAT拒绝⼀切UDP包从外部进⼊。
纣王叫什么当客户端收到响应数据时，我们就能从中得到 IP_N+Port_N， 也就是说我们从这⼀步能够得到NAT的外⽹地址和端⼝号。
拿到NAT的外⽹地址和端⼝号后，⽤其IP和client⾃⾝的IP地址进⾏⽐较：
如果相同，说明client具有公⽹地址，它没有在NAT后⾯。
卤牛肉的制作方法
如果不同，说明client在NAT后⾯，我们还要进⾏更多验证。
STEP2：验证我们的NAT是不是 Full Cone NAT
离别的诗
35英语从客户端发送⼀个UDP包到 IP_S1 + Port_S1，请求Stun Server使⽤ IP_S2 + Port_S2 对我们的请求进⾏响应。
如果能收到响应数据： 说明NAT是 Full Cone NAT， 因为NAT来者不拒，不对数据进⾏任何过滤。睡前歌曲
如果未收到响应数据： 我还需要进⼀步验证NAT的类型
STEP3：验证我们的NAT是对称NAT还是Cone NAT
从客户端发送⼀个UDP包到 IP_S2 + Port_S2, STUN收到后会把 IP_N+Port_N 保存到UDP包中作为对客户端请求的响应。然后把这个响应发送到 IP_N+Port_N。
这个测试中，我们关⼼的是UPD包中的数据， 如果包中的 Port_N 与 STEP1中的 Port_N是相同的，那么我们就可以肯定，这是个⼀个Cone NAT，如果不同那么就说明是个对称NAT，Stun Server⽆法解决这类NAT穿透问题~~
STEP4：区分 Restict Cone NAT 和 Port Restrict Cone NAT
从客户端发送⼀个UDP包到 IP_S1 + Port_S1, 要求 Stun Server ⽤ IP_S1 + Port_S2 返回响应给client。
爱开头的四字成语
如果client能收到：说明是 Restrict Cone NAT
如果收不到： 说明时 Port Restrict Cone NAT
到此，整个过程就结束了，除了对称NAT外，我们都能得到NAT的外⽹IP和端⼝，以及NAT的类型。
对称NAT的穿透⽅法将在下⼀篇中研究-----TURN
