NAT Traversal — вероятность успеха при использовании STUN

Я разрабатываю приложение P2P, и мне нужно использовать STUN и/или TURN для обхода NAT. Я изучил проблемы, возникающие при использовании только STUN (в основном это не всегда будет работать, потому что он основан на UDP, и некоторым брандмауэрам это не понравится - причина не так интересна, как мой вопрос), и я продолжаю видеть рекомендации по использованию STUN и TURN для отката (схема ICE).

Но куда бы я ни посмотрел, я просто вижу, что люди STUN «вряд ли всегда будут работать». Я ищу некоторые конкретные цифры / статистику. Я мог бы попытаться сгенерировать их самостоятельно, но у меня недостаточно клиентов для значительной выборки.

Поэтому мне было интересно, может ли кто-нибудь пролить свет на статистику успеха использования STUN для обхода NAT. Сколько одноранговых узлов не смогут подключиться, если я не использую TURN в качестве запасного варианта?


nat p2p turn stun voip
person orcaman    schedule 14.05.2014    source источник

Ответы (1)


arrow_upward
7
arrow_downward

В зависимости от того, кто ваши клиенты, где они находятся и какие устройства они используют (ПК или мобильные), результаты могут различаться.

На практике (исходя из моего опыта) подключение ICE только к STUN примерно на 85% успешно для настольных ПК и ноутбуков. Но если он сработает один раз для конкретной пары конечных точек, то будет еще более вероятным для последующих подключений к этим же хостам (при условии, что топологии сети не изменились). С мобильными устройствами дела обстоят немного иначе.

Вот некоторые факторы, влияющие на получение успешного «соединения» (на основе UDP или TCP) для P2P.

  1. Тип НАТ. Если обе конечные точки находятся за хорошо себя зарекомендовавшим NAT с ограничением портов или лучше, то шансы на успех STUN высоки. Это обычный случай для домашних NAT с хорошим интернет-провайдером, например, в США. Но операторы мобильной связи и корпоративные брандмауэры обычно реализуют «симметричный NAT» в результате наличия нескольких уровней NAT и сетевых конфигураций. В основном это означает, что сопоставления портов не согласованы, и алгоритму P2P, такому как ICE, сложнее установить соединение.

  2. Брандмауэры или корпоративные конфигурации. Даже если брандмауэр разрешает исходящие UDP-пакеты и принимает обратно, часто это симметричная конфигурация NAT.

  3. Мобильные операторы. Часто (но не всегда) используются симметричные типы NAT.

person selbie    schedule 18.05.2014