我试图了解WebRTC的工作原理，而无法理解STUN的作用。
根据我在各种网页（例如rfc5389或观看Google's 2013 presentation on WebRTC）上阅读有关STUN的理解，STUN似乎唯一要做的就是告诉客户它的公共IP地址/端口是
但是，研究一下如何实现一台STUN服务器，这表明他们参与了很多工作，并且似乎包括对UDP，TCP和TLS-TCP的故障回复支持以及客户端和服务器之间的握手等内容。报告他们期望自己的IP地址是什么，并对照对方所说的IP地址进行验证。例如，jselbi's stunserver project拥有50多个C ++文件。
另外，对于我来说，为什么WebRTC客户端甚至需要知道其自己的公共IP地址，这对我来说没有任何意义。在Google's presentation video (at time 19:46)中显示了两个要从NAT后面互相对话的对等点，并且每个对等点还正在与信令服务器通信。该图表明每个信令服务器都不知道对等方的公共IP地址/端口。但是此图一定是错误的：它显示了对等方直接与信令服务器对话，但通过NAT间接与STUN服务器对话。实际上，对等方也将通过NAT与信令服务器通信，因此，信令服务器将已经知道对等方的公共IP地址/端口。
由此，我遇到的麻烦是：
从客户端到信令服务器的任何请求都将在请求的IP标头中包含该客户端的公共IP地址/端口。当客户端与STUN服务器对话时，情况也是如此，这就是为什么STUN服务器可以使用公共IP地址/端口进行响应的原因。
在我看来，两个对等方可以彼此交谈的方式是劫持对等方和STUN服务器之间的开放连接：对等方打开与STUN服务器的连接。 STUN服务器通过说明已为此请求设置了哪个IP地址/端口来进行答复。然后将该IP地址/端口转发到远程对等方，远程对等方开始在最初为STUN服务器打开的连接上发送消息...这是正确的吗？
...还是我完全误解了发生了什么？
答案 0 :(得分：3)
STUN服务器仅具有非常简单的作用，即将收到的UDP数据包返回给客户端返回公共ip和端口。您正在看的是一个同时实现TURN的服务器（在https://tools.ietf.org/html/rfc5766中进行了介绍），这是一个STUN扩展，允许客户端打开服务器上的udp端口并中继数据。
与信令服务器的连接是使用TCP完成的，并且不受NAT的影响。信令服务器看到一个传入的TCP连接，但是该数据对于从外部建立连接没有用。
是的。好吧，几乎，媒体路径使用UDP，因此没有连接。大多数NAT都将转发到公用ip /端口的任何内容转发给发起方。对称NAT并非如此，这就是需要TURN的原因。整个过程称为“ udp打孔”或更正式地称为ICE（在https://tools.ietf.org/html/rfc5245中进行了描述）
不，您拥有“劫持”部分，这是正确的核心思想之一。但是NAT比您预期的更坏;-）