networking - Webrtc PeerConnection 在哪些条件下以及如何在没有 TURN 服务器的情况下工作？

Question

阅读有关 Webrtc 的信息，我感觉“它将显着降低服务器带宽的使用”，除了“一些角落的企业防火墙案例”，其中需要一个 TURN 服务器来中继对等方之间的整个流量。

例如，虽然与 webrtc 无关，但想法相似，Chatroulette 的维基百科文章声明:该网站使用 Adob​​e Flash 显示视频并访问用户的网络摄像头。 Flash 的点对点网络功能(通过 RTMFP)允许几乎所有视频和音频流直接在用户计算机之间传输，而无需使用服务器带宽。但是，某些路由器组合将不允许 UDP 流量在它们之间流动，因此有必要回退到 RTMP。

Webrtc 上的类似文章也侧重于“是的，防火墙可能存在问题，因此您需要一个 TURN 服务器，但忽略这一点，看看我很棒的 PeerConnection javascript 代码”。

我不明白的是:

两个对等点之间的连接需要打开一个服务器套接字，以便对等点可以连接到它。甚至 UDP 也需要 udp 服务器套接字的概念。由于几乎所有非服务器互联网连接的对等点都位于某种路由器后面。例如。每部智能手机都使用 wifi 路由器，台式电脑使用服务提供商的路由器，...
应该无法连接到智能手机上托管的服务器套接字(浏览器 webrtc 服务器套接字)或路由器/防火墙的桌面原因。

因此，我的理解是实际上没有两个需要通过互联网发送流量的对等方能够使用直接 P2P 连接，对吗？
所以使用 Webrtc 的唯一有用案例是在类似 LAN 的环境中，对吧？
此外，对于像基于 webrtc 的 chatroulette 这样的视频聊天服务，需要使用一堆 TURN 服务器来中继几乎所有的流量。这使得 Webrtc 在服务器带宽方面同样昂贵，比如托管我自己的解决方案。

所以我的问题是:我说的对吗？如果不是，允许 PeerConnection 在没有 TURN 服务器的情况下使用但用于由 Internet 分隔的两个节点的技术细节是什么？ TCP/UDP 传输层第 4 层如何建立连接？它是否使用 UDP 并且所有 wifi 路由器都允许托管 UDP 服务器套接字等？这对 NAT 和安全性没有多大意义。

更新 1:
进一步挖掘，我发现了“对称 nat”的含义以及它与企业的关系:在大多数企业中，连接到互联网的设备似乎已经实现了对称 nat。这意味着将内部“internal-ip:internal-port”元组映射到“internet-ip:internet-port”的路由表也存储“destination-ip:destination-port”。因此，此类路由/nats 为每个(tcp？)连接存储一个表，该表具有 6 列“internal-ip:internal-port:internet-ip:internet-port:destination-ip:destination-port”。这意味着除了目标之外没有其他人可以与 internal-ip:internal-port 通信。
而非企业路由器似乎只存储“internal-ip:internal-port:internet-ip:internet-port”组合。这也是“在防火墙上戳一个洞”的意思。

Answer 1

你不对。所有对等点都有 IP 地址以便进行通信，并且可以通过相同的地址访问，前提是防火墙允许。
NAT 往往只针对客户端发起的客户端-服务器流量进行优化。这通常意味着它们最初仅允许出站流量，并且仅在出站流量发生后才允许同一线路上的入站流量。非常适合服务器。见 this WebRTCHacks article有关问题的介绍。
这就是 ICE 尝试从内部(客户端)在防火墙中戳洞的地方，以便在两个对等方之间直接建立一条通信线路，而不需要任何“服务器”套接字，无论这意味着什么。
ICE 的工作原理相当复杂，在 RFC 中有详细说明。 .
但从广义上讲，它分几个步骤起作用:

每个对等点(例如浏览器)都有一个收集候选人的“ICE 代理”。候选者是可以到达此对等点的地址(IP:端口号)，包括:

主持人候选人:例如机器的即时 LAN/wifi/VPN IP。

服务器自反候选:机器的公共(public)(NAT 外)地址，通过从互联网上的镜像(STUN)服务器反弹请求获得。

中继候选:如果所有其他方法都失败，则将地址发送到共享 TURN 服务器以转发数据。

一旦发现，候选者被插入到本地 SDP 中，并通过信号 channel 传送到另一个对等点，在那里它们被插入到它的远程描述中，另一个代理可以看到它们。

一旦 ICE 代理同时拥有本地和远程候选者，它就会开始配对本地和远程候选者，并通过向它们发送 STUN 请求来检查它们的连接性(有效地尝试到达对等点)。

成功的配对是两个 ICE 代理都得到响应的配对(如果你愿意，可以进行 4 次握手)。

如果有不止一对成功的配对，它们会按某些指标进行排序，然后选择最佳配对。

然后使用选定的对来发送媒体。 (视频或音频)媒体的每个轨道都需要一对。

如果稍后找到更好的对，则所选对可能会更改，从而影响发送的地址媒体。

只有在两个客户端都在对称 NAT 之后，或者 UDP 流量被完全阻止的情况下才需要 TURN。