webrtc - 为什么 WebRTC 使用候选对而不是一个 IP + 端口对进行双向通信

Question

我一直在研究 WebRTC 的“内部结构”，到目前为止已经取得了重大进展。我的 javascript 客户端应用程序运行完美，我设置了 STUN、TURN(s)，即使两者都位于对称 NAT 环境中，我的同伴也能够连接。

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

在构建基于 WebRTC 的文件传输服务时，我意识到我需要在代码中检测传输是否被中继。我开始调查连接和传输属性，结果发现传输仍然是用 candidate pair 定义的。 ，而不是给定类型的单个连接。

所以在接收者方面，我有:
Local candidate type: srflx
Remote candidate type: relay
我可能应该将其视为“当接收器发送数据时” - 使用 NAT 上的绑定(bind)端口(srflx)，但是当接收器向发送器(远程端点)发送数据时 - 它被中继。

这是对配置的正确“阅读”吗？但更重要的是，鉴于在选定的对中有一个 srflx 候选，为什么它仍然是一对，而不是一个双向连接套接字？

Answer 1

WebRTC 主要是 UDP。关于“连接”，请记住这一点。

So on receiver's side, I have:

Local candidate type: srflx
Remote candidate type: relay

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

因此，如果您尝试检测是否使用中继，请检查本地和远程。

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

这有帮助吗？