Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Учитывая, что сейчас чаше распространён безлимит, просто повысят тарифы и всё.
Непонятно, как это соотносится с федеральными программами по «социальному интернету», чтобы он был дешёвым с любой дыре.
Непонятно, как это соотносится с федеральными программами по «социальному интернету», чтобы он был дешёвым с любой дыре.
Я вот одной вещи не пойму. Провайдеру (т.е. оборудованию провайдера) в принципе пофиг, какой через него трафик идет. Хоть фотки с котятами, хоть торренты, хоть скайп. За канал пользователь платит в любом случае, по тарифам, которые, очевидно, покрывают расходы на обеспечение этого канала. Так какого же, извиняюсь, хрена они хотят брать дополнительные деньги за один вид трафика? Или это просто вопрос вида «такое бабло идет мимо нас, непорядок»?
Или это просто вопрос вида «такое бабло идет мимо нас, непорядок»?Думаю, что именно это.
Оверселлинг же. Чтобы обеспечивать заявленные 50-100 МБит для сотен тысяч абонентов потребуется огого какой канал. В итоге вся надежда на то, что пользователи не будут использовать канал полностью одновременно. В случае мобильных операторов ситуация осложняется тем, что воздушный канал весьма ограничен, а делится между всеми абонентами. Чтобы улучшить ситуацию надо делать больше базовых станций, чтобы в одной соте оказывалось одновременно меньше абонентов, а это на каком-то этапе становится не выгодно.
С другой стороны это всё личные проблемы операторов и не должны волновать конечных пользователей. Не можете гарантировать канал? Пишите в тарифах «от Х МБит», а не «до».
С другой стороны это всё личные проблемы операторов и не должны волновать конечных пользователей. Не можете гарантировать канал? Пишите в тарифах «от Х МБит», а не «до».
Если мне память не изменяет, голосовой трафик скайпа — это что-то около десятков килобайт/с (и он еще умеет адаптивно им рулить, в зависимости от качества/ширины канала и передаваемых данных). Не думаю, что он прямо ложит напрочь все коммуникации провайдера, или хоть как-то сильно заметно на них влияет.
Подтверждаю, умудряюсь нормально звонить при ограничении в 64kbps
Если у вас глобальный айпишник, запущенный клиент скайпа может стать супернодом и зарутить через себя солидный трафик от других абонентов.
Это всё лапша! Не грузит голосовой трафик сеть. Есть более серьезные типы трафика, которые уж точно создают нагрузку — видео и торренты. Но мобильные операторы ведь итак ограничивают трафик с помощью лимитов, так что довод о нагрузке совершенно несостоятелен. Это элементарная попытка отжать денег на ровном месте…
Помнится, в терминах данной области «гарантированный битрейт» и «максимальный битрейт» — разные вещи, и на уровне протоколов они явно специфицируются отдельно друг от друга. С технической точки зрения, гарантированный битрейт — величина известная для оператора. А вот всякие маркетологи берут то, что побольше, и не утруждаются объяснять, что за величину они рекламируют.
> «такое бабло идет мимо нас, непорядок»
У нас не бывает иначе.
У нас не бывает иначе.
Не знаю как в остальных странах, но у нас в Беларуси все просто: «Ребята, ничего личного, просто государству очень нужны деньги до выборов». «Золотую курицу» (Парк Высоких Технологий) тоже ведь пытаются зарезать (поднять налоги и отчисления) по той же самой причине — а там, после выборов, хоть трава не расти.
У операторов бомбит от того, что при таком большом распространении интернет-телефонии и IM все их тарифы на мобильную связь и смс идут лесом, т.к. юзер может позвонить хоть на другой конец света по скайпу и туда же отправить сообщение через hang out просто за цену интернет-доступа.
А если Беларусы начнут шифровать трафик, как они тогда собираются плату взымать?
Да и созваниваться можно уже напрямую через WebRTC. Ещё есть Tox. И много других вещей, которые для них будут сюрпризом.
Да и созваниваться можно уже напрямую через WebRTC. Ещё есть Tox. И много других вещей, которые для них будут сюрпризом.
Думаю, что все-таки будут использовать DPI. Поскольку, например, тот же вайбер или скайп и так используют p2p для звонков, их voip траффик просто так не вычислишь по IP адресу.
На счёт Viber не скажу, но Skype уже давно не использует p2p. После покупки Microsoft, весь трафик идёт через их сервера.
Сомневаюсь. Установка соединения между клиентами — да, но гонять весь траффик через сервера избыточно (и из-за задержек сигнала и вообще), так что уверен более чем, что и у скайпа voip идет напрямую от клиента к клиенту.
Можно взять сниффер и посмотреть (увы, у меня нет скайпа).
Но сейчас прямые соединения абонентов это статистическая погрешность, чтобы их серьёзно рассматривать. Все мобильные абоненты сидят за NAT-ом опсоса, на котором не могут выделить себе слушающий порт. Поскольку что в доме 2-4 устройства, выходящих в интернет, домашние абоненты чаще поднимают соединение на роутере, а не как во времена dial-up/adsl с компьютера. Если «и так всё работает», никто не будет настраивать на роутере NAT для скайпа.
Но сейчас прямые соединения абонентов это статистическая погрешность, чтобы их серьёзно рассматривать. Все мобильные абоненты сидят за NAT-ом опсоса, на котором не могут выделить себе слушающий порт. Поскольку что в доме 2-4 устройства, выходящих в интернет, домашние абоненты чаще поднимают соединение на роутере, а не как во времена dial-up/adsl с компьютера. Если «и так всё работает», никто не будет настраивать на роутере NAT для скайпа.
сидят за NAT-ом опсоса, на котором не могут выделить себе слушающий порт. Поскольку что в доме 2-4 устройства, выходящих в интернет, домашние абоненты чаще поднимают соединение на роутере, а не как во времена dial-up/adsl с компьютера. Если «и так всё работает», никто не будет настраивать на роутере NAT для скайпа.Ну, так а зачем это всё настраивать, если есть UDP hole punching?
Ненадёжно. Это всё баги и они потихоньку закрываются.
Причина появления этих дыр — экономия памяти на таблице трансляций в древних маломощных роутерах.
А причина, по которой закрывают эти дыры — NAT сможет держать более 64Ki трансляций одновременно.
С дырявым натом один абонент с каким-нибудь dc++ DHT может отжать сразу 5000 портов на один свой IP, а если порты закончатся, другим абонентам что делать?
Например, для Symmetric NAT порт 12345 и хост 93.158.134.3 можно отдать одному клиенту, а тот же порт 12345 но на адрес 217.69.139.202 можно отдать другому клиенту. Все довольны, портов на всех хватает, но hole punching не работает.
Я проверял NAT-ы на ipfw у FreeBSD и в RouterOS (основан на линуксе). Там эти дыры не работают.
В-общем, это удел бытовых роутеров и всё равно оттуда эти дыры постепенно уходят, т.к. памяти ставят больше.
Причина появления этих дыр — экономия памяти на таблице трансляций в древних маломощных роутерах.
А причина, по которой закрывают эти дыры — NAT сможет держать более 64Ki трансляций одновременно.
С дырявым натом один абонент с каким-нибудь dc++ DHT может отжать сразу 5000 портов на один свой IP, а если порты закончатся, другим абонентам что делать?
Например, для Symmetric NAT порт 12345 и хост 93.158.134.3 можно отдать одному клиенту, а тот же порт 12345 но на адрес 217.69.139.202 можно отдать другому клиенту. Все довольны, портов на всех хватает, но hole punching не работает.
Я проверял NAT-ы на ipfw у FreeBSD и в RouterOS (основан на линуксе). Там эти дыры не работают.
В-общем, это удел бытовых роутеров и всё равно оттуда эти дыры постепенно уходят, т.к. памяти ставят больше.
А в домашних-то зачем это закрывать? Зачем может дома требоваться >64к трансляций?
Потому что с самописных наколенных решений переходят на linux или другие «большие» решения, в которые simmetric nat считается фичей.
Я безуспешно попытался нагуглить актуальный список роутеров, поддерживающих udp hole punching, нашёл только что D-LINK DIR-524 умел, а DIR-655 уже нет.
Я безуспешно попытался нагуглить актуальный список роутеров, поддерживающих udp hole punching, нашёл только что D-LINK DIR-524 умел, а DIR-655 уже нет.
Это печально. Может, с IPv6 получше будет с p2p…
Похоже, возможность p2p невыгодна ни правительству, ни крупному бизнесу. Ведь это дает населению независимость. Если IPv6 вообще когда-нибудь взлетит (учитывая изобретения вроде Symmetric NAT для экономии портов, этот момент еще более откладывается) — то операторы могут установить принудительные файрволы для частных клиентов, не позволяющие входящих соединений. И будут это мотивировать заботой о безопасности.
решения, в которые simmetric nat считается фичей.
«считается фичей» — это что значит?
Выше писал — держит больше активных трансляций, нет лимита на 64Ki, который легко выжрать.
Лимит был реальной проблемой. Вот представьте, сидит dc++ клиент за nat-ом. С хаба получает запрос: поищи файл *.mp3, кинь 10 результатов поиска на UDP 88.147.33.44:12345. Клиенту-то что: нашёл, кинул, а в нате появляется трансляция, на случай если пир будет отвечать.
Лимит был реальной проблемой. Вот представьте, сидит dc++ клиент за nat-ом. С хаба получает запрос: поищи файл *.mp3, кинь 10 результатов поиска на UDP 88.147.33.44:12345. Клиенту-то что: нашёл, кинул, а в нате появляется трансляция, на случай если пир будет отвечать.
Но если такой NAT при всех его преимуществах ухудшает возможности связи между абонентами еще сильнее, чем «обычный» NAT — то пусть это «считается фичей», но уж никак не преимуществом для всех случаев. И так множество протоколов Internet отвалилось из-за существования NAT, а Symmetric NAT только усугубляет эту ситуацию.
Это всё баги и они потихоньку закрываются.
Почему же баги?
Интернет вообще изначально разрабатывался исходя из возможности прямого соединения между любыми абонентами. Это потом уже появились NAT, которые позволяли как-то имитировать прямое соединение, но не обеспечивали его полноценно. Symmetric NAT — решение, еще больше урезающее возможности установления связи между абонентами, еще дальше уходящее от стандартов Internet. И как это у вас язык поворачивается называть все, кроме Sym. NAT — багами?
При разработке NAT никто не думал о Hole Punching, это эффект от упрощённой реализации трансляции. Ведь по таблице в 64K можно сделать прямой lookup, а по ключу в 48 бит (IPv4+port) уже нельзя — надо извращаться с хешами.
Люди нашли дыру и некоторое время пользовались.
Люди нашли дыру и некоторое время пользовались.
При разработке NAT никто не думал о Hole Punching
А о чем думали? О том, чтобы под чистую блокировать все входящие соединения? Или, может быть, о том, чтобы обеспечить хоть какую-то связь при отсутствии предписанного стандартом IP-адреса?
Люди нашли дыру и некоторое время пользовались.
Это можно назвать «дырой» только в том случае, если задача NAT — блокировать входящие соединения.
Но NAT и Firewall — разные вещи. Блокировать входящие можно и без NAT. Мне довелось работать в конторе, раздающей каждому компьютеру реальные IP-адреса, однако входящие UDP и TCP-соединения были заблокированы. В частности, не работало никакое hole punching. Ответ на STUN-запрос приходил только в том случае, если он был отправлен с того же IP и порта, куда направлялся запрос.
В задачу же NAT блокировка входящих соединений не входит, поэтому возможность организации таких соединений через NAT нельзя называть «дырой».
Добавлю. Сам факт того, что в RFC стандартизирован протокол STUN и методики организации p2p связи вроде ICE, специальные средства протокола SIP вроде RPORT, говорит о том, что цель блокировки входящих соединений для NAT никогда не ставилась.
По сути NAT — это костыль для преодоления отсутствия IP-адресов, а протоколы STUN и т.д. — методика ходьбы на таких костылях. Кому-то нравится Symmetric NAT как более «малогабаритный» костыль, однако и ходить на таком костыле тяжелее.
По сути NAT — это костыль для преодоления отсутствия IP-адресов, а протоколы STUN и т.д. — методика ходьбы на таких костылях. Кому-то нравится Symmetric NAT как более «малогабаритный» костыль, однако и ходить на таком костыле тяжелее.
А о чем думали? О том, чтобы под чистую блокировать все входящие соединения?
Думали, как поднять прокси-сервер не переписывая приложения. Фактически, nat — супер-прозрачный прокси.
В задачу же NAT блокировка входящих соединений не входит
Равно как и не входит обеспечение возможности принимать соединения
поэтому возможность организации таких соединений через NAT нельзя называть «дырой».
Можно назвать дырой, потому что неавторизиванный хост может грубо вмешаться в установленное между клиентами соединение. И если в обработчике протокола есть ошибка, связанная например с переполнением буфера, причём не обязательно на стадии авторизации, которая публично доступна, а где-то в середине диалога, дырявый NAT снижает безопасность.
Думали, как поднять прокси-сервер не переписывая приложения.
А что входит, по-вашему, в задачи прокси-сервера?
Равно как и не входит обеспечение возможности принимать соединения
А как рассматривать с этой точки зрения обмен данными по UDP, не предполагающий установление виртуальных соединений?
И в любом случае, если не ставилась задача блокировать входящие соединения — то не может считаться багом или дырой возможность таких соединений.
Можно назвать дырой, потому что неавторизиванный хост может грубо вмешаться в установленное между клиентами соединение.
Нельзя назвать дырой. NAT — это не файрвол. Имея открытый IP-адрес, вы тоже можете столкнуться с «грубым вмешательством» неавторизованного хоста. Это неизбежный риск жизни в открытом интернете.
Ваши рассуждения об «ошибках с переполнениями буфера, которые снижают безопасность» — это ошибочное приписывание NAT функций файрвола. NAT и Firewall — разные вещи. Первый обеспечивает какие-то возможности связи, второй — заботится о безопасности, чтобы ни у кого там буфера не переполнялись.
Разрушение сетевого нейтралитета всё ближе подбирается к России.
А ведь порнозвезды же на пальцах объяснили, чем это грозит!
«Fuck for Net Neutrality!»
А ведь порнозвезды же на пальцах объяснили, чем это грозит!
«Fuck for Net Neutrality!»
Страницы выбора тарифов интернет-провайдеров будущего
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В Беларуси собрались взимать оплату за использование VoIP-сервисов