Если хочется, чтобы два компьютера, потенциально оба за всякими NAT, говорили друг с другом. Я в курсе про UDP hole punching, когда третий сервер пробивает дырки в NAT-е и позволяет двум общаться. Хочется понять ограничения этой технологии. В каких случаях она не будет работать (ну кроме очевидного — UDP тупо закрыт фаерволом), как часто эти случаи встречаются у домашних пользователей и у корпоративных пользователей.
Здравствуйте, vsb, Вы писали:
vsb>Если хочется, чтобы два компьютера, потенциально оба за всякими NAT, говорили друг с другом. Я в курсе про UDP hole punching, когда третий сервер пробивает дырки в NAT-е и позволяет двум общаться. Хочется понять ограничения этой технологии. В каких случаях она не будет работать (ну кроме очевидного — UDP тупо закрыт фаерволом), как часто эти случаи встречаются у домашних пользователей и у корпоративных пользователей.
Если делать все правильно, то для двух случайно выбранных компьютеров вероятность успешно установить между ними прямое соединение — процентое 95-97.
а что такое вероятность успеха ?
соотношение всего числа компьютеров подключенных к интернету во всем мире
к числу этих компьютеров которые смогли соединится между собой по udp hp ?
если да
тогда подскажите где именно вы взяли эту статистику ?
Здравствуйте, reversecode, Вы писали:
R>а что такое вероятность успеха ? R>соотношение всего числа компьютеров подключенных к интернету во всем мире R>к числу этих компьютеров которые смогли соединится между собой по udp hp ?
Нет, соотношение числа компьютеров, которые смогли напрямую соединиться, к числу компьютеров, которые пытались это сделать.
R>если да R>тогда подскажите где именно вы взяли эту статистику ?
Алекс Панкратов проболтался, который автор Hamachi.
Мой личный опыт показывает, что правильно сделанный UDP hole punching почти всегда работает, но у меня нет миллионной статистики, как у Панкратова.
Речь, конечно, идет о софтварии, ориентированном на массового пользователя. Если целиться на компьютеры, работающие внутри больших корпораций, там все будет много хуже. В больших корпорациях часто не работает ничего, кроме HTTP на выход; нередко с фильтром запрещенных сайтов.
Здравствуйте, Pzz, Вы писали:
R>>если да R>>тогда подскажите где именно вы взяли эту статистику ?
Pzz>Алекс Панкратов проболтался, который автор Hamachi.
А есть ссылка, если это публичная информация? И про то, как его делать правильно.
Здравствуйте, vsb, Вы писали:
Pzz>>Алекс Панкратов проболтался, который автор Hamachi.
vsb>А есть ссылка, если это публичная информация? И про то, как его делать правильно.
Это было в форуме, сейчас уже не найдешь. Про то, как делать, информация тоже, разумеется, не публичная.
мне подробно объяснять не надо
я овер 10+ лет в нетворкинге и сисадмином и кодером
но udp hp через upnp это не честный udp hp
хамачи тоже самое
а вообще как писали те кто раньше пробовали
After a lot more testing this doesn't seem to work at all for me unless I enable UPnP. So a lot of the things I wrote here you may find useful but many people don't have UPnP enabled (because it is a security risk) so it will not work for them.
более честную статистику можете поискать среди тех кто сейчас интегрирует webrtc для конф
и вот они очень любят turn сервера
надеюсь объяснять почему, не надо
Здравствуйте, reversecode, Вы писали:
R>но udp hp через upnp это не честный udp hp R>хамачи тоже самое
Ну вообще-то, хамачи не использует upnp. Я тоже не использовал: возни много, а дополнительный выхлоп очень маленький.
R>более честную статистику можете поискать среди тех кто сейчас интегрирует webrtc для конф R>и вот они очень любят turn сервера R>надеюсь объяснять почему, не надо
WEBRTC использует в чистом виде TURN + ICE. Совершенно буквально, как в RFC написано. Такая конструкция переполняет conntrack'овые таблицы роутеров, что в некоторых случаях приводит к их зависанию, совсем не работает с симметричными NAT'ами, не работает с NAT'ами, которые закрывают дырку, получив ICMP destination unreachable, и добивается успеха процентах в 70-и попыток, не больше.
Я уж не говорю о том, что в TURN'е полно тестов типа "послать пакет туда-то, если нет ответа в течении 10 секунд, повторить, если ответа все равно нет, то A, иначе — B". Этот поиск разницы между A и B занимает кучу времени, не принося никакой полезной информации для пробивания дырок.
Здравствуйте, vsb, Вы писали:
vsb>Если хочется, чтобы два компьютера, потенциально оба за всякими NAT, говорили друг с другом. Я в курсе про UDP hole punching, когда третий сервер пробивает дырки в NAT-е и позволяет двум общаться. Хочется понять ограничения этой технологии. В каких случаях она не будет работать (ну кроме очевидного — UDP тупо закрыт фаерволом), как часто эти случаи встречаются у домашних пользователей и у корпоративных пользователей.
В общем случае — гарантий нет (симметричный NAT не допускает такого поведения в принципе, разве что пытаться экспуатировать нюансы реализации конкретных NAT).
Второй нюанс — согласны ли Вы ждать несколько часов пока карты лягут должным образом, если хост имеет плавающий график нагрузки.
Здравствуйте, Mr.Delphist, Вы писали:
MD>В общем случае — гарантий нет (симметричный NAT не допускает такого поведения в принципе, разве что пытаться экспуатировать нюансы реализации конкретных NAT).
Очень многие симметричные НАТы выделяют порты по порядку (N, N+1, N+2, ...), и выделение порта можно предугадать. Кроме того, поскольку наивные реализации P2P в той или иной мере набирают популярность (тот же WEBRTC...) , симметричные НАТы постепенно вымирают в массовом сегменте.
MD>Второй нюанс — согласны ли Вы ждать несколько часов пока карты лягут должным образом, если хост имеет плавающий график нагрузки.
Здравствуйте, Pzz, Вы писали:
MD>>Второй нюанс — согласны ли Вы ждать несколько часов пока карты лягут должным образом, если хост имеет плавающий график нагрузки.
Pzz>Чего? Зачем?
Всё очень классно работает на окружении разработчика, когда там никого кроме него нету. В реальной сети маршрутизатор обслуживает много запросов — процесс угадывания может затянуться, не правда ли? Даже в квартирной сетке: ноут жены обновляет вкладочки в браузере, телефоны всех домочадцев тоже не лежат без дела, сюда же до кучи робо-пылесосы, умные чайники и прочий домашний скарб — что-то куда-то шлют.
Здравствуйте, Mr.Delphist, Вы писали:
Pzz>>Чего? Зачем?
MD>Всё очень классно работает на окружении разработчика, когда там никого кроме него нету. В реальной сети маршрутизатор обслуживает много запросов — процесс угадывания может затянуться, не правда ли? Даже в квартирной сетке: ноут жены обновляет вкладочки в браузере, телефоны всех домочадцев тоже не лежат без дела, сюда же до кучи робо-пылесосы, умные чайники и прочий домашний скарб — что-то куда-то шлют.
Обычно можно за полсекунды продолбиться. Пиковая загрузка очень редко бывает такой, чтобы пакеты массово терялись. Специальным исключением является какая-нибудь битторрент-качалка, эта вон может выжрать всю полосу на неделю вперед. Но их обычно и ограничивают, чтобы не мешали котиков в интернете смотреть.
Здравствуйте, vsb, Вы писали:
vsb>Если хочется, чтобы два компьютера, потенциально оба за всякими NAT, говорили друг с другом. Я в курсе про UDP hole punching, когда третий сервер пробивает дырки в NAT-е и позволяет двум общаться. Хочется понять ограничения этой технологии. В каких случаях она не будет работать (ну кроме
очевидного — UDP тупо закрыт фаерволом), как часто эти случаи встречаются у домашних пользователей и у корпоративных пользователей.
Hole punching скорей невозможен с т.н. full cone NAT. Так как третий сервер не пробьёт при всём желании дырку для второго.
Пробить всё равно можно, но нужно перебрать 65536 портов в пербом приближении. Долго и муторно. На хабре кто-то занимался,
наверное сможешь найти по ключевым словам.
Здравствуйте, fk0, Вы писали:
fk0>очевидного — UDP тупо закрыт фаерволом), как часто эти случаи встречаются у домашних пользователей и у корпоративных пользователей.
Бывает. Но по мере продвижения гуглевкого QUIC, UDP становится более открытым. Хотя в корпоративных сетях, особенно в больших корпорациях, нередко встречается политика, разрешающая только исходящий HTTP.
fk0> Hole punching скорей невозможен с т.н. full cone NAT. Так как третий сервер не пробьёт при всём желании дырку для второго.
Очень многие симметричные NAT'ы выделяют порты по порядку (N, N+1, N+2, ...). Так что с неплохой вероятностью можно предугадать, какой порт получит твое соединение, и предложить другой стороне долбиться прямо в него (и еще в парочку следующих, для надежности).
fk0>Пробить всё равно можно, но нужно перебрать 65536 портов в пербом приближении. Долго и муторно. На хабре кто-то занимался,
Это — очень плохая идея. В процессе такого перебирания насоздается куча лишних записей в таблице известных NAT'у соединений. Роутеры, которые при переполнении этой таблицы просто тупо виснут не являются редкостью, особенно в массовом сегменте.
