Как работает ICE протокол и зачем он нужен для FAF

Как работает ICE протокол и зачем он нужен для FAF

ICE: создание интерактивного соединения

 


Протокол создания интерактивного соединения (Interactive Connectivity Establishment – ICE) используется для обхода NAT. ICE использует комбинацию методов, включая Утилиту обхода сеанса для NAT (STUN) и Обход посредством ретрансляции NAT (TURN). Наличие транслятора сетевых адресов (NAT) является одной из известных проблем для реализации Передачи голоса по IP (VoIP) и WebRTC.

 

ICE Примеры

Рассмотрим пример использования протокола инициации сеанса (Session Initiation Protocol – SIP), когда устройство SIP с пользователем Петей находится за NAT / Firewall и хочет зарегистрировать свое нахождение у регистратора SIP, находящегося в общедоступном Интернете. Устройство SIP имеет не маршрутизируемый частный IP-адрес 192.168.0.10. Устройство SIP регистрирует свое нахождение у регистратора как sip:petya@192.168.0.10:5060. Это сообщает регистратору, что с Петей можно связаться по IP-адресу 192.168.0.10 через порт 5060 (порт SIP по умолчанию). Этот частный IP-адрес не имеет смысла для устройства в общедоступном Интернете, и регистратор не знает, как связаться с Петей.

Второй пример связан с проблемами при отправке мультимедиа в реальном времени (RTP). Аня звонит Пете, а приглашение Ани содержит протокол описания сеанса (SDP) со своим локальным IP-адресом 10.1.1.10 и медиа-портом 1234. Петя принимает приглашение Ани со своим SDP, содержащим его локальный IP-адрес 192.168.0.10 и медиа-порт 1234. Оба этих IP-адреса адреса не имеют смысла вне области частной локальной сети каждого человека, и ни одна из сторон не получит пакеты RTP другой стороны.

На рисунке 1 показано типичное развертывание ICE с двумя Пользовательскими агентами (далее ПА (User Agent) – под пользовательским агентом подразумевается устройство либо программное обеспечение для передачи сообщений), связывающимися посредством SIP (или другой сигнальный протокол, который выполняет обмен предложение/ответ для сообщений в формате протокола SDP). ICE использует SIP, что означает, что прохождение SIP через NAT должно обеспечиваться другим механизмом. ICE позволяет ПА, которые изначально не знают своих топологий, узнавать достаточно информации о топологии для поиска путей связи.

Два ПА находятся за NAT с неизвестными свойствами. Они способны обмениваться сообщениями SDP через обмен предложение/ответ, используемый для настройки медиа-сеансов между ПА через SIP-сервер. В дополнение ICE использует сервер(ы) STUN / TURN, каждый ПА может иметь свой собственный либо они используют один тот же сервер STUN / TURN. Оба ПА имеют список транспортных адресов, которые могут использоваться для связи с другим агентом. ICE используется для обнаружения адресов которые могут соединяться друг с другом, а также методов используемых для их соединения через NAT.

Для выполнения ICE соединения каждому ПА необходимо идентифицировать все адреса-кандидаты, транспортные адреса. Транспортные адреса представляют собой комбинацию IP-адреса и порта для определенного транспортного протокола. Есть три типа кандидатов:

Host Candidate – транспортный адрес, связанный с локальным интерфейсом ПА
Relayed Candidate – транспортный адрес, связанный с сервером TURN (может быть получен только от сервера TURN)
Server Reflexive Candidate – преобразованный адрес на общедоступной стороне NAT (полученный от сервера STUN или сервера TURN)

На рисунке 2 показана связь этих кандидатов с ПА.

После того как ПА1 собрал всех своих кандидатов, он упорядочивает их в порядке приоритета от высшего к низшему и отправляет их ПА2 в атрибутах в сообщении предложения SDP. ПА2 выполняет тот же сбор кандидатов и отправляет ответ SDP со своим списком кандидатов. Каждый ПА берет два списка кандидатов и попарно создает из них пары-кандидаты. Каждый ПА собирает их в контрольные списки и планирует проверки соединения, транзакции в виде запрос/ответ STUN, чтобы узнать какие пары-кандидаты работают. На рисунке 3 показаны компоненты пар-кандидатов, которые составляют контрольный список ПА.

Результатом тестирования обоих агентов является четырехстороннее рукопожатие на тех же самых портах, которые будут использоваться для передачи медиа. На рисунке 4 показана базовая проверка подключения.

ICE назначает одного из агентов в качестве «Контролирующего агента», а другого – в качестве «Контролируемого агента». Контролирующий агент использует действительные пары кандидатов для назначения пары, по которой будет осуществляться передача медиа. Есть два метода назначения, которые можно использовать:

Regular Nomination Постоянное назначение – проверки продолжаются до тех пор, пока не найдется хотя бы одна действительная пара кандидатов. Контролирующий агент выбирает из допустимых пар и отправляет второй запрос STUN для этой пары с флагом сообщающем партнеру, что это тот, который назначен для использования.
Aggressive Nomination Агрессивное назначение – флаг назначения отправляется с каждым запросом STUN, как только первая проверка успешно завершена, обработка ICE для этого медиапотока считается завершенной, и второй запрос STUN не требуется.

На рисунке 5 показан пример обоих вариантов назначения.

Каждая пара кандидатов в контрольном списке имеет связанное с ней состояние. Состояние присваивается агентом ПА после расчета контрольного списка. Есть пять возможных состояний:

Frozen (Заморожено) – Эту пару можно проверить только после перевода в состояние ожидания. Чтобы войти в состояние ожидания, сначала должна пройти другая проверка
Waiting (Ожидание) – Как только это пара с наивысшим приоритетом в контрольном списке, будет выполнена проверка
In-Progress (Выполняется) – Проверка была отправлена для этой пары, и транзакция в процессе выполнения
Succeeded (Успешно) – Успешный результат проверки пары
Failed (Провалено) – Неудачный результат проверки пары

На рисунке 6 показана диаграмма состояний для пар-кандидатов.

На рисунке 7 показана упрощенная топология, которую мы будем использовать в примере коммуникационного потока ICE. Оба ПА используют ICE и агрессивное назначение, если они контролеры. Оба случая просто используют один и тот же сервер STUN (который не требуется, но показан в этом примере для простоты), который прослушивает запросы привязки STUN. ПА1 находится за NAT, который имеет свойство отображения, независимое от конечной точки, и свойство фильтрации, зависящее от адреса.

На рисунке 8 показан поток для этого примера коммуникационного потока ICE. После получения хоста-кандидата с его локального IP-адреса ПА1 отправляет запрос привязки STUN для получения рефлексивного кандидата (сообщения с 1 по 4). NAT создает привязку для запроса, который становится рефлексивным кандидатом сервера для RTP. Используя сервер рефлексивный кандидат ПА1 отправляет сообщение-предложение на ПА2 (сообщение 5). ПА2 приступает к получению рефлексивного сервер-кандидата (сообщения 6 и 7), который идентичен хосту-кандидату, поскольку он не находится за NAT. Избыточный кандидат отбрасывается, оставляя только хост-кандидат. Поскольку ПА1 начал коммуникацию, он считается контролирующим, а ПА2 – контролируемым. ПА2 пытается проверить подключение, но поскольку он контролируется, он не имеет надлежащих атрибутов для достижения ПА1 через NAT, поэтому запрос отбрасывается (сообщение 9). ПА1, являясь контролирующей стороной, имеет атрибут для прохождения через устройство NAT с его агрессивной проверкой подключения STUN для назначения (сообщения с 10 по 13). После получения запроса привязки STUN с агрессивным назначением, ПА2 выполняет проверку соответствия, используя атрибут из запроса привязки STUN ПА1 для проверки соединения (сообщения с 14 по 16). На этом этапе оба ПА удостоверяются, что соединение является действующим, и оно было назначено для использования в этом медиапотоке. Оба ПА теперь могут отправлять медиа через это соединение.

Итак, ознакомившись с протоколом ICE более подробно можно посмотреть, каким образом клиент FAF использует данный протокол, чтобы обеспечивать игроков наиболее стабильным соединением и создавать комфортные условия для игры.
Это можно увидеть в окне, которое открывается в момент начала игры и служит для отладочных целей. Поэтому здесь достаточно много информации для иллюстрации работы ICE:

 

 

Автор: MikZZ

Редактор:  Vast

Источник:

ICE: Interactive Connectivity Establishment

Related posts

Leave a Comment