为什么WebRTC使用候选对而不是一个IP+；用于双向通信的端口对

我一直在调查WebRTC的“内部”问题，到目前为止已经取得了重大进展。我的javascript客户端应用程序工作完美，我已经设置了STUN、TURN和我的对等程序，即使它们都位于对称NAT环境中，也可以连接

当我阅读IETF关于ICE和NAT遍历的草案时，我假设当至少一个对等方位于非对称NAT环境中时，非中继连接是可能的，其中UDP打孔可以在路由网关上进行

在构建基于WebRTC的文件传输服务时，我意识到我需要在代码中检测传输是否被中继。我开始研究连接和传输属性，结果发现传输仍然是用

候选对定义的，而不是给定类型的单个连接

所以在接受者方面，我有：

本地候选类型：srflx
远程候选类型：中继

我可能认为它是“当一个接收者正在发送数据”时，在NAT上使用一个绑定端口（SRFLX），但是当接收方将数据发送给发送者（远程端点）时，它被中继。
这是对配置的正确“读数”吗？但更重要的是，既然选定的一对中有一个srflx候选，为什么它仍然是一对，而不是一个双向连接套接字
 WebRTC主要是UDP。关于“连接”，请记住这一点

所以在接受者方面，我有：

这意味着所有通信都是通过远程对等方分配的TURN服务器地址进行的。和他们的TURN服务器正在转发到您的srflx地址-这是通过STUN/TURN获得的公共IP地址（和端口映射）

因此，如果您试图检测是否使用继电器，请检查本地和远程

它们被称为“候选对”，因为最终WebRTC/P2P连接将使用您一端的一个地址和另一端的一个地址建立。您一侧的每个候选地址都试图ping远程一侧的地址。最终双方会聚在一个“候选对”上作为最终路线

这有用吗？
是的，确实有用。因此，如果该对中的任何当前候选是中继类型，则意味着通信量将通过中继。这对搭档背后的逻辑现在已经很清楚了，非常感谢。
Local candidate type: srflx
Remote candidate type: relay