Что такое кандидаты ICE и как между ними выбирается одноранговое соединение?
Я недавно написал простое приложение для чата, но я не очень понимал предысторию ICE Candidates.
Когда одноранговый узел создает соединение, он получает кандидатов ICE, обменивает их и, наконец, устанавливает равноправное соединение.
Итак, мой вопрос: откуда берутся кандидаты ICE и как они используются и действительно ли они используются?
Я заметил, что у моего коллеги меньше кандидатов, когда он выполняет заявку на своем компьютере, что может быть причиной для различного количества кандидатов?
2 ответа
Ответ @Ichigo правильный, но он немного крупнее. Каждый ICE содержит "узел" вашей сети, пока он не достиг внешней стороны. Этим вы отправляете эти ICE другим партнерам, чтобы они знали, через какие точки соединения они могут связаться с вами. Рассматривайте его как большое здание: один находится в здании и должен сказать другому (кто не знаком), как пройти через него. То же самое и здесь, если у меня много сетевых устройств, входящее соединение каким-то образом должно найти правильный путь к моему компьютеру. Предоставляя все узлы, RTC-соединение само находит кратчайший маршрут. Поэтому, когда вы подключаетесь к компьютеру, который находится рядом с вами, который подключен к тому же маршрутизатору / коммутатору / другому устройству, он использует все ICE и определяет самый короткий, и это напрямую через эту точку. То, что у вашего коллеги меньше кандидатов на ICE, связано с количеством устройств, через которые он должен пройти. Обратите внимание, что каждый сетевой адаптер на вашем компьютере, имеющий IP-адрес (у меня есть коммутатор vEthernet от hyper-v), также создает для него ICE.
ICE расшифровывается как Интерактивное установление соединения, его методы используются в NAT(преобразователь сетевых адресов) для establishing communication for VOIP, peer-peer, instant-messaging, and other kind of interactive media.
Обычно лед-кандидат предоставляет информацию о IP-адресе и порте, откуда данные будут обмениваться.
Это формат примерно так
a= кандидат: 1 1 UDP 2130706431 192.168.1.102 1816 тип хоста
Вот UDP указывает протокол, который будет использоваться, typ host указывает, к какому типу кандидатов на лед это относится, хост означает, что кандидаты генерируются в брандмауэре. Если вы используете wireshark чтобы отслеживать трафик, вы можете видеть, что порты, используемые для передачи данных, такие же, как порты-кандидаты в лед.
Другой тип relay Это означает, что эти кандидаты могут быть использованы, когда связь должна осуществляться за пределами брандмауэра.
Он может содержать больше информации в зависимости от браузера, который вы используете. Много раз я видел, как 8-12 ледовых кандидатов генерируются браузером.
У Ичиго есть хороший ответ, но он не подчеркивает, как используется каждый кандидат. Я думаю, что ответ MarijnS95 совершенно неверен:
Каждый ICE содержит "узел" вашей сети, пока не достигнет внешнего
Предоставляя все узлы, RTC-соединение само находит кратчайший маршрут.
Во-первых, он имеет в виду кандидата ICE, но с этой частью все в порядке. Возможно, я неправильно его истолковываю, но, говоря "пока он не достигнет внешнего", он создает впечатление, что клиент (инициирующий партнер) является самым внутренним слоем луковицы, и предлагает кандидат ICE помогает вам очистить слои пока вы не доберетесь до "Интернета", где сможете добраться до отвечающего узла, возможно, очистив еще одну луковицу, чтобы добраться до нее. Это неправда. Если инициирующий одноранговый узел не может связаться с отвечающим одноранговым узлом через транспортный адрес, он отбрасывает этого кандидата и пробует другого кандидата. Он не хранит никаких узлов в кандидате. Кандидаты ICE генерируются до любой связи с отвечающим партнером. Ледяной кандидат не поможет вам очистить пресловутый лук NAT. Кроме того, что касается второй цитаты, которую я сделал из его ответа, он создает впечатление, что ICE используется в алгоритме кратчайшего пути, где "самый короткий" вообще не отображается в ICE RFC.
Из списка терминологии RFC8445:
ICE позволяет агентам обнаруживать достаточно информации о своих топологиях, чтобы потенциально найти один или несколько путей, по которым они могут установить сеанс данных.
Цель ICE - определить, какие пары адресов будут работать. ICE делает это систематически, пробуя все возможные пары (в тщательно отсортированном порядке), пока не найдет одну или несколько, которые работают.
Кандидат, информация о кандидате: транспортный адрес, который является потенциальным местом контакта для получения данных. У кандидатов также есть свойства - их тип (рефлексивный сервер, ретрансляция или хост), приоритет, основание и основание.
Транспортный адрес: сочетание IP-адреса и порта транспортного протокола (например, UDP или TCP).
Итак, у вас есть (ICE) кандидат был определен (IP-адрес и порт, которые потенциально могут быть адресом, который получает данные, которые могут не работать), и был объяснен процесс выбора (первая пара транспортных адресов, которая работает). Обратите внимание, это не список узлов или луковой шелухи.
У разных пользователей могут быть разные ледовые кандидаты из-за процесса "сбора кандидатов". Существуют разные типы кандидатов, и некоторые из них получаются из локального интерфейса. Если у вас есть дополнительный виртуальный интерфейс на вашем устройстве, то будет сгенерирован дополнительный ICE (я не тестировал это!). Если вы хотите узнать, как "собираются" кандидаты ICE, прочтите 2.1. Сбор кандидатов
Я надеюсь, что рассечение мифа о луке не заставило вас плакать. Не замораживайте лук. Нарежьте их кубиками.