我一直在研究WebRTC的"内部结构"，到目前为止已经取得了重大进展。我的javascript客户端应用程序完美运行，我已经设置了STUN，TURN(s(，即使两者都位于对称NAT环境中，我的同行也能够连接。
当我阅读有关 ICE 和 NAT 遍历的 IETF 草案时，我假设非中继连接是可能的，当至少一个对等体位于非对称 NAT 环境中时，路由网关上可能会有 UDP 打孔。
在构建基于 WebRTC 的文件传输服务时，我意识到我需要在代码中检测传输是否被中继。我开始调查连接和传输属性，结果发现传输仍然是用candidate pair定义的，而不是给定类型的单个连接。
所以在接收者方面，我有：
Local candidate type: srflx
Remote candidate type: relay
我可能应该将其视为"当接收方正在发送数据时" - 使用 NAT 上的绑定端口 (srflx(，但当接收方将数据发送到发送方(远程端点(时 - 它被中继。
这是对配对配置的正确"读取"吗？但更重要的是，既然在选定的一对中有一个srflx候选者，为什么它仍然是一对，而不是一个双向连接插座？
WebRTC主要是UDP。 关于"连接"，请记住这一点。
所以在接收者方面，我有：
Local candidate type: srflx
Remote candidate type: relay
这意味着所有通信都通过远程对等方分配的 TURN 服务器地址进行。他们的TURN服务器正在转发到您的srflx地址 - 这是通过STUN/TURN获得的公共IP地址(和端口映射(。
因此，如果您尝试检测是否使用中继，请检查本地和远程。
它们被称为"候选对"，因为最终WebRTC/P2P连接将建立，您的一端有一个地址，另一端有一个地址。 您这边的每个候选地址都在尝试 ping 远程端的地址。 最终，双方会聚在一个"候选对"上作为最终路线。
这有帮助吗？