Практический обход NAT для надежных сетевых подключений

Question

Я видел и читал много похожих вопросов и соответствующих статей в Википедии ( Обход NAT , STUN , TURN , TCP дырокол ), но огромное количество информации не очень помогает мне в моей очень простой задаче:

Я пишу приложение P2P и хочу, чтобы два пользователя моего приложения за NAT могли соединяться друг с другом. Соединение должно быть надежным (сопоставимым с надежностью TCP), поэтому я не могу просто переключиться на UDP. Решение должно работать на современных распространенных системах без перенастройки. Если это помогает, решение может включать подключаемое стороннее устройство, если ему не нужно передавать все данные через прокси (например, для получения внешних (WAN) IP-адресов одноранговых узлов).

Насколько я знаю, мой единственный вариант - использовать библиотеку "надежного UDP" + Пробивание UDP-дырок . Для этого есть библиотека (C / C ++)? Я нашел enet в связанном вопросе , но он заботится только о первой половине решения.

Что-нибудь еще? Вещи, на которые я смотрел:

1. Teredo tunneling - требуется поддержка операционной системы и / или пользовательской конфигурации
2. UPnP переадресация портов - UPnP отсутствует / включена везде
3. Пробивание отверстий по протоколу TCP представляется экспериментальным и работает только при определенных обстоятельствах
4. SCTP поддерживается даже меньше, чем IPv6. SCTP через UDP - это просто надежный UDP (см. Выше)
5. RUDP - основная поддержка почти отсутствует
6. Из того, что я мог понять о STUN, STUNT, TURN и ICE, никто из них мне здесь не поможет.

Answer 1

ICE собирает список потенциальных IP-адресов / портов назначения, к которым необходимо подключиться.Каждый пир собирает их, а затем каждый запускает проверку соединения для каждого из кандидатов по порядку, пока либо проверка не пройдет, либо проверка не пройдет.

Когда Алиса пытается соединиться с Бобом, она каким-то образом получает списоквозможные пути - определенные Бобом - она ​​может соединиться с Бобом.ICE называет этих кандидатов.Боб мог бы сказать, например: «мой локальный сокет 192.168.1.1:1024/udp, моя внешняя привязка NAT (найденная через STUN) - 196.25.1.1:4454/udp, и вы можете вызвать медиасервер (промежуточное окно) на уровне 1.2.3.4: 6675 / УДП».Боб помещает это в пакет SDP (описание этих различных кандидатов) и каким-то образом отправляет это Алисе.(В SIP, исходном сценарии использования для ICE, SDP переносятся при обмене SIP INVITE / 200 / ACK, устанавливая сеанс SIP.)

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

Недостатком ICE является то, что ваши коллеги обмениваются описаниями SDP , которые вы можете или можете использоватьне как.Другая причина заключается в том, что поддержка TCP все еще находится в черновой форме 1016 *, что может быть или не быть проблемой для вас.[ОБНОВЛЕНИЕ: ICE теперь официально RFC 6544 .]

Игры часто используют UDP, потому что старые данные бесполезны.(Вот почему RTP обычно работает по протоколу UDP.) Некоторые приложения P2P часто используют промежуточные или сети промежуточных ячеек.

IRC использует сеть промежуточных ящиков: серверы IRC образуют сети, а клиенты подключаются к ближайшему серверу.Сообщения от одного клиента другому могут проходить через сеть серверов.

Если все это не удастся, вы можете взглянуть на архитектуру BitTorrent и посмотреть, как они решают проблему NAT.Как указывает CodeShadow в комментариях ниже, BitTorrent полагается на достижимые одноранговые узлы в сети: в некотором смысле некоторые одноранговые узлы образуют сеть промежуточных ящиков.Если эти промежуточные блоки могут выступать в роли реле, у вас будет IRC-подобная архитектура, но настроенная динамически.

Answer 2

Я рекомендую libjingle , так как он используется некоторыми крупными компаниями, производящими видеоигры, которые в значительной степени полагаются на сетевую связь P2P. (Вы слышали о Steam? Vavle также использует libjingle , см. Сеанс «Одноранговая сеть» на странице: https://partner.steamgames.com/documentation/api)

Однако, всегда работающее решение будет использовать сервер ретрансляции. Поскольку не существует «стандартного» способа прохождения через NAT, вы должны использовать эту опцию сервера ретрансляции в качестве запасной стратегии, если необходимо всегда устанавливать соединение между любыми узлами.