Почему WebRTC нужен протокол ICE?

Question

Насколько я понимаю, протокол ICE используется для обнаружения узлов/устройств от конечного пользователя до «снаружи».

Я не понимаю, почему это необходимо. Не является ли маршрутизация пакетов ответственностью сетевых устройств, таких как маршрутизаторы и коммутаторы? Они должны найти кратчайший путь от шлюза до конечного пользователя (на самом деле, маршрутизаторы помнят те маршруты, которые они ранее обнаружили).

Кроме того, протокол NAT используется для преобразования из «внутреннего ip» в «внешний ip» и наоборот.

Итак,
Почему другой пользователь должен быть знаком с моей внутренней настройкой сети?

Answer 1

Брандмауэры. Они, как правило, настроены на откат любого нежелательного трафика из всемирной сети. Они только одобряют, что вы инициируете контакт с сервером, который только тогда разрешен для обратного трафика для вас, и это в значительной степени это. Если ваши друзья не имеют собственных статических IP-адресов (это мало кто может оправдать), это враждебная среда для одноранговой связи.

ICE пытается решить эту проблему, перечисляя адреса и порты, на которых может быть достигнута другая сторона, и пытается подключиться к этим адресам, инициируя исходящие запросы на обоих концах или если все остальное не работает, возвращается к общению через сервер TURN, если это указано.

См. Это WebRTCHacks article для получения дополнительной информации о проблеме.

Почему другой пользователь должен быть знаком с моей внутренней сетевой настройкой?

Потому что другой пользователь иногда находится в вашей внутренней сети. например LAN игры.

Answer 2

NAT - это kludge, поставленный на место, чтобы попытаться сохранить IPv4-адреса до тех пор, пока IPv6 не станет повсеместным, и он разрушит сквозную связь, которая является обещанием IP. Из-за этого некоторые вещи не работают должным образом через NAT. Существуют различные kludges для работы с NAT kludge, и ICE является частью этого. Это объясняется в RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols:

1. Введение

RFC 3264 [RFC3264] определяет двухфазный обмен Session Описание протокола (СДП) сообщения [RFC4566] для целей создания мультимедийные сеансы. Этот механизм предложения/ответа используется протоколами , такими как протокол инициации сеанса (SIP) [RFC3261].

Протоколы, использующие предложение/ответ, с трудом работают через сеть Адресные переводчики (NAT). Поскольку их целью является установление потока пакетов мультимедиа, они, как правило, несут IP-адреса и порты источников и приемников медиа в своих сообщениях, что, как известно, является проблемой через NAT [RFC3235]. Протоколы также направлены на создание потока медиа-потока непосредственно между участниками, так что между ними не существует промежуточного посредника прикладного уровня . Это делается для уменьшения латентности среды, уменьшения потерь пакетов и снижения эксплуатационных расходов развертывания приложения. Однако это трудно сделать через NAT. Полное объяснение причин этого - выходит за рамки данной спецификации.

Многочисленные решения были определены для разрешения этих протоколов через NAT. К ним относятся шлюзами Application Layer (ALG) протокол управления Middlebox [RFC3303], оригинальный простой Обход UDP через NAT (STUN) [RFC3489] спецификация и Realm Specific IP [RFC3102] [RFC3103] вместе с описанием сессии , необходимые для их работы, такие как описание сеанса Protocol (SDP) [RFC4566] атрибут для протокола управления в реальном времени (RTCP) [RFC3605]. К сожалению, у этих методов есть плюсы и минусы, которые делают каждый из них оптимальным в некоторых топологиях сети, но в других - плохой выбор.В результате администраторы и разработчики делают предположения относительно топологий сетей , в которых их решения будут развернуты. Это вводит в систему сложность и хрупкость . Нужно только одно решение , достаточно гибкое, чтобы хорошо работать во всех ситуациях .

Эта спецификация определяет Интерактивная Связь Создание (ДВС) в качестве метода для обхода NAT для UDP-носителей на основе потоков (хотя ДВС может быть расширена, чтобы обрабатывать другие транспортные протоколы, такие , как TCP [ICE-TCP]), установленных предложение/ответ модель. ICE является расширением моделью предложения/ответа и работает, включая множество адресов IP-адресов и портов в SDP-предложениях и ответах , которые затем тестируются на подключение по одноранговой связи . IP-адреса и порты, входящие в состав SDP, и проверки подключений выполняются с использованием пересмотренной спецификации STUN [RFC5389], которая теперь переименована в Утилиты трассировки сеанса для NAT. Новое имя и новая спецификация отражают его новую роль в качестве инструмента, который является , который используется с другими методами обхода NAT (а именно ICE), а не автономным решением обхода NAT , поскольку исходная спецификация STUN была. ICE также использует Traversal, используя реле вокруг NAT (TURN) [RFC5766], расширение для STUN. Поскольку ICE обмены множественность из IP-адресов и портов для каждого мультимедийного потока, она также позволяет выбора адреса для многосетевых и хостов стеки двух-, и по этой причине он осуждает RFC 4091 [RFC4091] и [RFC4092].