Каким образом STUN выполняет проверку подключения ICE к кандидатским парам?

Question

Я прошел через RFC 5389 и RFC 5245 и более новый RFC 8445. Я понимаю, как работает STUN при возврате рефлексивного адреса сервера или ретранслируемого адреса. Запрос отправляется на сервер STUN.

Мой фундаментальный вопрос касается проверки подключения ICE с использованием STUN. RFC 8445 утверждает на странице 10:

"...At the end of
this process, each ICE agent has a complete list of both its
candidates and its peer's candidates.  It pairs them up, resulting in
candidate pairs.  To see which pairs work, each agent schedules a
series of connectivity checks.  Each check is a STUN request/response
transaction that the client will perform on a particular candidate
pair by sending a STUN request from the local candidate to the remote
candidate."

Для Проверки проверок возможности соединения на парах-кандидатах в сообщении STUN должно быть указано минимальное значение для целевого IP-адреса, Порт, Прото. Где описана эта структура сообщения STUN? Где я могу получить подробную информацию о том, как STUN выполняет эту проверку подключения?

Answer 1

Я понимаю сложность интерпретации RFC-описания процесса. Я пытаюсь упростить:-

Предположим, я получаю пары кандидатов на своем конце как:-

1. IP1,P1
2. RIP2,P2
3. TIP3,P3

Точно так же мой коллега имеет свой собственный набор как

1. (B)IP1,P4
2. (B)RIP2,P5
3. (B)TIP3,P6

Перенесемся в будущее, где у нас хороший медиапоток. Очевидно, что для направления медиа от A->B у нас есть два транспортных адреса. Поскольку для отправки мультимедиа используется UDP, сокет имеет адрес источника и адрес назначения. Назовем их SrcIP_A, SrcPort_A и SrcIP_B, SrcPort_B.

Должно быть ясно, что SrcIP_A, SrcPort_A является частью пар кандидатов A и SrcIP_B, SrcPort_B является частью пар кандидатов B.

Теперь, переходя к текущему времени, с точки зрения A, чтобы добиться плавного потока медиа от A->B, нам просто нужно заблокировать пару, которую мы в конечном итоге будем использовать из того набора, который у нас уже есть.

Вот где на сцену выходит STUN. Помните, что запрос STUN должен быть отправлен на определенный IP-адрес, порт. И ответ сообщает, какой внешний адрес с преобразованием в NAT, который STUN-сервер заметил в запросе.

Итак, A создает 9 пар, сопоставляя каждую запись в собственных парах кандидатов со своим партнером. Затем он отправляет запрос STUN из базы RFC 8445 пары из каждого своего собственного набора кандидатов каждой из пар удаленных кандидатов. Теперь удаленная сторона B ДОЛЖНА иметь логику сервера STUN, реализованную на ее собственной стороне, когда она получает любой трафик на своей паре кандидатов. Итак, в основном сокет при получении любых пакетов должен иметь возможность различать медиа-пакеты и пакеты STUN. В последнем случае он отправит ответ STUN с указанием того, откуда он получил запрос.

Предположим, что при повторении A находится в следующих комбинациях.

1. IP1,P1 против RIP2,P5 Здесь reuest может достигать B, поскольку рефлексивный адрес RIP2,P5 достигнет внутри NAT. Возвращенный наблюдаемый адрес будет отраженным адресом IP1,P1. На стороне A, когда получен ответ, он отбрасывает этот набор, поскольку содержащийся адрес не является IP1,P1.
2. RIP2,P2 против (B)IP1,P4 Это явно не сработает. Поскольку вы не можете отправлять на IP1, P4 является частным адресом.
3. RIP2,P2 против RIP2,P5 Здесь reuest может достигнуть B, поскольку рефлексивный адрес RIP2,P5 достигнет внутри NAT. Возвращаемый наблюдаемый адрес также будет RIP2,P2. Таким образом, это может быть отмечено как "действительная пара".

Надеюсь, я был ясен.

Answer 2

Вы найдете структуру сообщений STUN, описанную в RFC-5389, раздел 6. https://tools.ietf.org/html/rfc5389.

Известные части описания:

Сообщения STUN кодируются в двоичном формате с использованием сетевого ориентированного формата (в первую очередь старший байт или октет, также широко известный как старшие порядковые числа). Порядок передачи подробно описан в Приложении B RFC 791 [RFC0791]. Если не указано иное, числовые константы указываются в десятичном формате (основание 10).

Все сообщения STUN ДОЛЖНЫ начинаться с 20-байтового заголовка, за которым следует ноль или более атрибутов. Заголовок STUN содержит тип сообщения STUN, магический файл cookie, идентификатор транзакции и длину сообщения.

Старшие 2 бита каждого сообщения STUN ДОЛЖНЫ быть равны нулю. Это может использоваться для дифференциации пакетов STUN от других протоколов, когда STUN мультиплексируется с другими протоколами на том же порту.

Тип сообщения определяет класс сообщения (запрос, ответ об успешном выполнении, ответ об ошибке или указание) и метод сообщения (основная функция) сообщения STUN. Хотя существует четыре класса сообщений, в STUN есть только два типа транзакций: транзакции запроса / ответа (которые состоят из сообщения запроса и ответного сообщения) и транзакции индикации (которые состоят из одного сообщения индикации). Классы ответов разбиты на ответы об ошибках и успешных действиях, что позволяет быстро обрабатывать сообщения STUN.