我新写了一个简单的聊天应用程序,但我并不真正了解ICE候选人的背景。
当对等方创建连接时,他们会获得ICE Candidates并交换它们并进行设置 他们终于到了对等连接。
所以我的问题是,ICE候选人来自哪里,他们是如何使用的,他们是否真的被使用过?
我注意到我的同事在他的机器上执行申请时得到的候选人较少,这可能是导致候选人数量不同的原因?
答案 0 :(得分:71)
答案 1 :(得分:65)
ICE 代表交互式连接建立,它是establishing communication for VOIP, peer-peer, instant-messaging, and other kind of interactive media.
通常,ice候选者提供有关数据交换位置的ipaddress和端口的信息。
它的格式如下
a =候选人:1 1 UDP 2130706431 192.168.1.102 1816 典型主机
此处UDP
指定要使用的协议,typ host
指定它是哪种类型的候选冰,主机意味着候选者是在防火墙内生成的。
如果您使用wireshark
来监控流量,那么您可以看到用于数据传输的端口与冰候选者中存在的端口相同。
另一种类型是relay
,表示在防火墙外进行通信时可以使用此候选项。
根据您使用的浏览器,它可能包含更多信息。 很多时候我见过8-12个冰候选者是由浏览器生成的。
答案 2 :(得分:2)
Ichigo 有一个很好的答案,但是没有强调每个候选人的使用方式。我认为 MarijnS95 的答案是完全错误的:
每个ICE都包含您网络的“节点”,直到它到达外部为止。
通过提供所有节点,RTC连接自身会找到最短的路由。
首先,他指的是ICE候选人,但是那部分还不错。也许我是在误解他,但是他说“直到它到达外面”,他才使客户(发起交易的同伴)看起来像是洋葱的最内层,并建议ICE候选人帮助您剥开洋葱皮。直到您到达“互联网”为止,在这里可以到达响应的对等方,也许还可以剥另一个洋葱去。 这是不正确的。如果启动对等方未能通过传输地址到达响应对等方,它将丢弃该候选对象并将尝试其他候选对象。它不会在候选位置中的任何位置存储任何节点。 ICE候选者在与响应对等方进行任何通信之前生成。候选冰块不会帮助您剥落众所周知的NAT洋葱。关于我从他的答案中得到的第二个引号,他使ICE似乎在最短路径算法中使用,而ICE RFC中根本没有出现“最短”算法。
从RFC8445术语列表中:
ICE允许代理发现足够的信息 有关其拓扑的信息,以潜在地找到一条或多条路径 他们可以建立数据会话。
ICE的目的是发现可以使用的地址对。 ICE进行此操作的方法是系统地尝试所有可能的配对(以仔细排序的顺序),直到找到一个或多个可行配对为止。
候选人,候选人信息:运输地址 接收数据的潜在联系点。候选人也 具有属性-它们的类型(服务器自反,中继或 主机),优先级,基础和基础。
运输地址: IP地址和 传输协议(例如UDP或TCP)端口。
如此,您已经定义了(ICE)候选对象(一个IP地址和端口,该地址和端口可能是接收数据的地址,可能不起作用),并说明了选择过程(第一个有效的传输地址对)。请注意,它不是节点或洋葱皮的列表。
由于“收集候选者”的过程,不同的用户可能具有不同的候选冰块。有不同类型的候选,有些是从本地接口获得的。如果您的设备上有一个额外的虚拟接口,则会生成一个额外的ICE(我没有对此进行测试!)。如果您想知道如何“收集” ICE候选人,请阅读2.1. Gathering Candidates
我希望切开洋葱神话不要让你哭泣。不要冰洋葱。 骰子它们。