Торент, почему его так не любят провайдеры

[pavlabor 1 914]

Торент делит провайдеров на две части,

первые его не любят, вторые не знают что они его не любят.

 

Так в чем же такая нелюбовь провайдеров к торенту?

 

Написать статью решил после прочтения некоторых коментов в свой адрес

http://local.com.ua/forum/topic/20281-mtorrent-kak-to-obhodit-pipe-freebsd/page__p__150468entry150468

Ну и все же открытого вопроса - "mtorrent как-то обходит pipe FreeBSD"

 

И так поехали.

 

Как работает пайп на потоке, что творится с трафиком перед пайпом и после него?

 

Пайп ограничивает трафик,

необходимость его установки и возникла потому как приходит трафика больше чем пропускная полоса оплаченая клиентом.

Работа пайпа направлена на стабилизацию потока, путем помещения избыточных пакетов в очередь и передаче их клиенту по мере разгрузки канала,

если же канал длительное время не разгружается, то пакет в очереди устаревает и дропается.

 

Специфика пайпа заключается в том что он формирует поток на абонента, но выполняет работу уже с потоком который пришол к нему на обработку.

И приходящий проток не обязательно должен быть именно таким какой пакет оплатил клиент,

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

Когда поток попал в лапы пайпа, тот чесно отработает свою задачу, защимит клиента к той полосе которую оплатил заказчик,

то есть к заказчику пойдет полоса уже четко нарезаная.

НО! Обратите внимание на то что если снимать статистику с правила пайпа, статистика будет гораздо больше той полосы которая реально уходит на клиента, потому что как написал выще, счетчик регистрирует количество пакетов которые пришли на обработку пайпа, а результат работы пайпа, то есть какая полоса идет на клиента, можно посмотреть если поставить счетчик после пайпа!

 

Если кто-то не понял,

Рисунок 1.

А - структура трафика до пайпа

В - пайп, его счетчик и его работа.

С - структура трафика после пайпа.

До пайпа идет нерегламентированный трафик "А",

он регистрируется счетчиком правила, точка "В1", он отражается в статистике,

тут же обжимается в значение пайпа, точка "В2", лишний трафик ставится в очередь и пропускается по мере освобождения полосы, если канал загружен полностю, пакет в очереди утаревает и дропается, при больших нагрузках и длительных закачках никакой очереди не хватит накапливать пакеты,

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

 

Теперь отступление, протокол TCP.

Его специфика, заключается в гарантированой доставке пакета,

пакет ушол, пока не прийдет подтверждение следующий пакет не отправляется,

то есть после передачи пакета происходит время бездействия канала,

которое равно времени на получение подтвержения что пакет получен в целости и сохранности,

после этого отправляется другой пакет.

Естественно что такая передача не позволяет ефективно использовать заказаную полосу, поетому было придуман принцип передачи "плавающее окно".

Суть его заключалась в том что сначала передавался один пакет, если он доходил без проблем,

то при следующей передачи передавалось сразу два пакета, если и они доходили без проблем,

при следующей передачи передается сразу три пакета и т.д.

Получается что передача одновременного количества пакетов постоянно нарастала,

естественно наступал момент когда какой то пакет бился или терялся.

После этого поток обрывался и вся процедура начиналась по новой, с передачи одного пакета.

 

Рисунок 2.

 

Пайп дропя излишние пакеты автоматически сбивает поток!

На практике получается что ефективная работа пайпа, происходит только благодаря специфике протокола TCP.

Конечно превышение входящей полосы над той которая отдается клиенту всеравно наблюдается,

но учитывя распределение по времени на нее можно не обращать внимания.

Обратите внимане что при передаче протоколом UDP, даже если пайп сбивает поток, сесия молотит как в чем небывало, даже если у клиента забит канал, входящий канал провайдера, грузится по мере технической возможности и никто этому восприпятствовать не может, но об этои позже.

 

Естественно при использовании протокола TCP, все равно возникала ситуация когда канал то нагружался, то проседал,

ну и чтобы восполнить провалы, появились много поточные качалки.

Суть их сводилась к тому что одновременно подымалось несколько сесий которые должны были работать паралельно,

срыв сесии распределялся в произвольном порядке, это позволяло более равномерно загрузить канал.

Рисунок 3.

 

Но если количество сесий увеличивать до бесконечности, получаем следующий еффект.

Например, хакаем винду и формируем 400 сесий.

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

Но на подходе следцющих 50 сесий с переполнением и т.д.

При таком подходе, из за чрезмерного количества сесий, входящий поток имеет постоянный подпор

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

Получаем следующую ситуацию, например есть клииент, безлим 1мегабит.

Входящий канал провайдера втягивает 1.2 мегабита на пользователя,

пайп дропит лишних 200кил и подправляет трафик на клиетна до 1мегабит.

Клиент оплачивает 1 мегабит провайдер 200к, а хто его просил дропать?

 

Но грабли не все.

У клиента стоит торент который собирает уже полученый файл,

торент показывает реальную скорость прокачки, и она аж никак не 1 мегабит, а гдето на уровне 800кил.

Почему?

Да потому что канал который после пайпа равен 1 мегабит,

забит служебкой на 400 сесий, вдобавок имеет 20% побитых сесий тем же пайпом!

Короче говоря, чем больше сесий тем больше бытой инфы, тем больше идет запросов на провторную передачу.

Тем меньше эффективность канала.

 

Но торенту оказалось этого мало, нужно было выжать с канала еще больше,

поэтому решили заюзать протокол UDP,

По UDP, вообще все печально, здесь полностю отсутствует механизм контроля,

в связи с этим получив единыждый запрос на передачу файла,

практически получаем дос атаку на клиента, ну и все железо которое стоит по дороге.

Валятся цыски, за всякий хлам вообще писать не стану.

И если почитать, какой основной параметр при выборе железа, это количество пакетов обрабатываемое в секунду.

Естественно что старые модемы не выдерживают таких нагрузок, падают вайфай точки, адсли и прочая лобуда.

Опять же проблемы не все, перегрузив канал, у торента валятся клиенты и возникают новые,

при 400 сесиях плавает порядка 200 новых сесий, при этом начинает досить ДНС сервера,

на предмет разрезолвливания обратной зоны.

Выйти в инет при работающем торенте, клиенту практически нереально.

И если при TCP протоколе, при активной скачке, наблюдается превышение а 20%,

то на UDP протоколе, превышение может достигать и 200%.

Этот эфект связан с гораздо позжей реакцией торент протоколов на срыв сесий,

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

Так же при большом превышении получаем больший процент дропания самих маркеров управления сесиями,

это дополнительный прирост неконтролируемых прокачек в никуда.

 

Если у првайдера таких пользователей 10%, можно сворачивать бизнес.

Потому что эти 10% ложат входящий канал на 200%, при этом получают свои 10%.

 

Ответ для Elisium - ISP "Crystal Telecom"

Если такие клиенты, абидятся и уйдут к вам, то многие провайдеры вам и свечку поставят.

Только это именно и есть ламерство, а не то что вы мне написали.

Как подтверждение, это реакция на бездонные каналы и 15%-ное ограничение трафика у крупных провайдеров.

 

Как с этим боротся?

Никто с этим боротся толком не может, шо то там цыска написала, но толку мало.

У нас стоит самописный скрипт, который мониторит загрузку канала на клиента,

как правило скайп, радио, видео имеет структуру трафика отнюдь не забивающий канал под завязку,

выгрызает полосу в нужных пределах.

Поетому не сложно выделить бешеного торент клиента по структуре нагрузки.

Как правило это загрузка существенно превышающая пайп.

После этого события клиент блокируется скриптом, и ему вываливается сообщение где написана причина блокировки и что нужно сделать.

Уменьшение количество сесий до 10 и отключение использование UDP потокола.

Поверьте, не один клиент не ушол к другому првайдеру по этой причине!

Люди довольно вменяемые и к рекомендациям прислушиваются.

 

Вот пример клиента 2 мегабита анлим, у которго стит бешенный торент и реакция системы.

"A" и "C" попытки использования хакнутого торента на мир,

"В" попытка использования хакнутого торента на точку обмена трафиком.

 

Естественно стакими клиентами удерживать расценки на серфинг невозможно,

один клиент выступает аналогией 30-40 пользователей, не самых спокойных.

Поетому и вводится ограничение на количество трафика практически во всем мире.

обычно нигде на сайте этого ненайти, но в договоре, мелким шрифтом такая фраза присутствует часто.

Ограничиывется в районе 15-25% общей загрузки канала.

Но если у провайдера пожар, UDP, торент рубануть конечно проще всего.

 

А, ну да, вывод - UDP протоколу побарабану ваши пайпы!

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

Практика показывает что при общей, текущей структуре трафика, на пайпах сжигается порядка 40% входящего трафика,

что приводит к необходимости покупать внешнюю полосу на 40% больше.

Обидно что за эти 40% приходится платить реальные деньги, но никто этого трафика так и не получает, он сгорает на шейпах.

[trinity0333 11]

за что таких юзеров любить.. получает 4мбит в обе стороны.. ночью двойная скорость по тарифы.. прыжки выше внутрисетка..

 

 

оно то конечно, юзер всегда прав,и мы идём навстречу.. но мне интересно винты у юзеров какого размера если в частности этот клиент вот уже 4 месяца каждый день такая картина почти.. %) перешел к нам такой "подарок" от телекома.. выдать ему тариф 8Мбит днём 16ночью отказались

[pavlabor 1 914]

за что таких юзеров любить.. получает 4мбит в обе стороны.. ночью двойная скорость по тарифы.. прыжки выше внутрисетка..

 

 

оно то конечно, юзер всегда прав,и мы идём навстречу.. но мне интересно винты у юзеров какого размера если в частности этот клиент вот уже 4 месяца каждый день такая картина почти.. %) перешел к нам такой "подарок" от телекома.. выдать ему тариф 8Мбит днём 16ночью отказались

 

Продай Elisium - ISP "Crystal Telecom"

Давай сразу сотку баксов в придачу, а то передумает!

 

ps. я бы отдал 8/16,

два момента,

первый входящий трафик, на самом деле клиент получает свои 4 мегобита, более того наверно жалуется что реально прокачка идет не больше 3.5,

то что по графику это реальная нагрузка генерируемая клиентом в разрезе вашего внешнего канала,

больше он не потянет, но хоть денег будет больше платить.

второй исходящий, пайп фиксирует скорость и рубает на отдачу, реально в мир уходит не больше 4.

То есть, толкотня воды в ступе, пользы никто не получает больше чем выставлен пайп,

а вот железу достается по полной программе, проще говоря, софт клиента формирует дос атаку на ваше железо.

[alex_o 1 194]

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

Шейпер на основе ipfw (dummynet) очень даже успешно режет поток не зависимо от того, что там идет - TCP/UDP или какой другой тип пакетов. Потому как сам принцип построения шейпера - очередь, в которую помещается ЛЮБОЙ пакет.

Если уважаемый павлабор боится, что UDP-поток от юзера задосит его оборудование, то мне искренне жаль его абонентов! Им бы лучше поискать оператора, который обладает достаточными знаниями и финансовыми возможностями, чтобы не бояться предоставлять своим абонентам услуги в полном объеме и соответствующем качестве.

 

Сама по себе поднятая тема - бред сивой кобылы. Провайдер - это прежде всего поставщик услуг связи. Если он не любит поставлять эти услуги (в частности - транспортировать торрент-трафик), или не умеет это делать, то нехрен тогда вообще со своим ограниченным пионэрским мировоззрением лезть в этот бизнес.

"Провайдеры против торрентов" - ИМХО, тоже самое, что и "Нефтетрейдеры против автопрома".

[kvirtu 315]

Я тоже против заурядных качальщиков, которые качают 25 часов в сутки. Я от таких отказываюсь.

[pavlabor 1 914]

Я тоже против заурядных качальщиков, которые качают 25 часов в сутки. Я от таких отказываюсь.

 

Сейчас тебе alex_o напишет что не провайдер ты..., да и безграмотный чукча - в сутках мол 24 часа...

И не в домек ему что, эти люди из сказок, на час раньше встают...!

[XNeo 0]

Шейпер на основе ipfw (dummynet) очень даже успешно режет поток не зависимо от того, что там идет - TCP/UDP или какой другой тип пакетов. Потому как сам принцип построения шейпера - очередь, в которую помещается ЛЮБОЙ пакет.

Ого, какой интерестный шейпер

1. Это ж какие объёмы ОЗУ нужны для таких очередей ?

2. И что же он потом будет делать с очередью которую насобирал ? На внешнем канале в 100мбит соберёт в очередь 50Мбайт пакетов и потом 1,5 часа будет неспеша лить их юзеру чтобы ниодного пакета не потерять ?

 

P.S.: У любого шейпера размер очереди ограничен. Время удержания пакета в очереди ограничено и равно обычно максимум секунд 5. А дальше идут дропы

[prototip 284]

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

Единственное замечание с моей стороны - думинет стар как дед мороз тупая разрезка скорости на фре при отличной производительности - именно то лекарство , что доктор прописал . Ну а ежели автор хочет побороться с торент трафиком и определить приоритет для данного трафа , то думаю все же стоит обратить внимание к iptables and HTB , также вам помогут разрулить вашу ситуацию переход с fifo на pcq очереди . Вся эта эта петрушка разруливается за часик второй на Mikrotik , если у вас конечно не мега роутер с погоней за pps . Просто наверное стоит правильно построить в голове что происходит у вас с вашим трафиком , а вышестоящему провайдеру поверьте абсолютно по... торенты у вас или что то иное в потоке , для него вообще не стоит вопрос кол-ва ваших сессий и нарезки трафика , в противном это не пров., а любитель ...

[prototip 284]

P.S.: У любого шейпера размер очереди ограничен. Время удержания пакета в очереди ограничено и равно обычно максимум секунд 5. А дальше идут дропы

Ничего себе 5 секунд ... Ну время жизни пакета знаете не мной придумано и если мне не изменяет память более 1500 мс никак для єзера (1,5 сек ). Сами понимаете если пакет уйдет и в течении 1,5 сек от него ни привета ни ответа , то ... А размер очереди для fifo (стандартный тип очереди на эзере) 50 пакетов , для энтузиастов его можно увеличить . Просто следует задуматься в разделе торентов , что тип fifo - первый пришел , первый ушел и тут по все видимости у вас и возникает проблема , поскольку для критичных приложений с небольшим размером пакета , но чувствительным к задержкам возникает трабла (Voip). Решение этой проблемы может быть всеже PCQ , хотя и это не панацея , одной из проблем является кушание вашей оперативы под эти самые очереди .

[hex@set 1 423]

Это

[prototip 284]

мля сегодня же воскресенье - как говориться ляг поспи и все пройдет , и это то же ...

[pavlabor 1 914]

P.S.: У любого шейпера размер очереди ограничен. Время удержания пакета в очереди ограничено и равно обычно максимум секунд 5. А дальше идут дропы

Ничего себе 5 секунд ... Ну время жизни пакета знаете не мной придумано и если мне не изменяет память более 1500 мс никак для єзера (1,5 сек ). Сами понимаете если пакет уйдет и в течении 1,5 сек от него ни привета ни ответа , то ... А размер очереди для fifo (стандартный тип очереди на эзере) 50 пакетов , для энтузиастов его можно увеличить . Просто следует задуматься в разделе торентов , что тип fifo - первый пришел , первый ушел и тут по все видимости у вас и возникает проблема , поскольку для критичных приложений с небольшим размером пакета , но чувствительным к задержкам возникает трабла (Voip). Решение этой проблемы может быть всеже PCQ , хотя и это не панацея , одной из проблем является кушание вашей оперативы под эти самые очереди .

 

Где а статье написано что шейпы как то, вдруг, не работают?

 

В статье написано что изначально приходит большое количество трафика, и шейп производит стабилизацию потока.

Все правильно, стабилизация проходит, при колебании трафика на 0.0001%, за счет запихивания пакетов в очередь, формирования задержки,

но не больше времени жини пакета в очереди.

 

То что произвольно формируется превышение входящего трафика,

процедура работы пайпа, в статье не расматривается, читайте другие источники.

 

По поводу раставления правил, это самообман,

Можно на входе поставить пайп, на выходе счетчик, и все будет кучерявенько.

Но от этого размер входящего трафика не уменьшится.

 

В статье расмотрен механизм возникновения превышения трафика, что и как на это влияет.

 

То что хто то не понял, это уже не мои проблемы, курите маны.

[nightfly 1 221]

Если у првайдера таких пользователей 10%, можно сворачивать бизнес.

У меня таких этак 50% - с закачками в потолок 24/7, все нормально, ДОСов не наблюдаю, дамминет шуршит... Из чего проистекает два закономерных вопроса:

 

- что я делаю не так?

- когда уже сворачивать бизнес?

 

Кстати да - перестаньте теоретизировать на тему построения очереди. Просто поставьте закачку и снимите трафик с интерфейса - разниться он будет далеко не на 200% и даже не на 5%. Пакеты попадают в queue одинаково в независимости от клиентского ПО. Топик "mtorrent как-то обходит pipe FreeBSD" на который вы ссылаетесь вообще носит маразматический характер по причине:

1. отсутствия обратного пайпа

2. заворачивания в него только tcp траффика

 

То что хто то не понял, это уже не мои проблемы, курите маны.

Ознакомьтесь сами чтоли.

http://nuclight.livejournal.com/124348.html

[adeep 212]

я поясню почему провайдеры не любят торренты (даже до появления udp протокола).

все потому что доснижались цен на абонентский интернет и не подумали что людям скорости нужны чтобы качать, а не для того чтобы новости читать.

В итоге покупая за 200грн 1 мбит продаем 16 и жалуемся, что вот такие нехорошие абоненты, загрузили весь канал.

 

После этого события клиент блокируется скриптом, и ему вываливается сообщение где написана причина блокировки и что нужно сделать.

Уменьшение количество сесий до 10 и отключение использование UDP потокола.

Поверьте, не один клиент не ушол к другому првайдеру по этой причине!

Люди довольно вменяемые и к рекомендациям прислушиваются.

......

Но если у провайдера пожар, UDP, торент рубануть конечно проще всего.

ограничивать скорость - можно.

блокировать пакеты, протоколы, куски интернета - нельзя.

к сожалению, об этом многие забывают и позволяют себе это делать.

 

 

Про UDP протокол в целом верно. Забывается только одно маленькое НО. Все протоколы передачи данных требуют для себя подтверждение приема, иначе передача данных не имеет смысла.

Как в icq, так и в торрентах есть подтверждение приема переданных данных и это подтверждение будет реагировать на шейпы точно так же как и окна в tcp траффике

Відредаговано 2010-02-21 22:41:39 adeep

[Ajar 90]

Не знаю как у других , физику не обманешь ... С UDP думаю не смысла писать , не зря доссеры раньше использовал UDP/80 ...

Автор написал мысли и в кое-чем прав (если откинуть ряд тех. глупостей ) , но TCP довольно легко шейпится(ограничивается) , даже обычный буфер fifo

чудесно выделит полосу , при этом входящая полоса (до ограничения ) максимум отличается на 10%(кратковременно) ... Для мега-гига качальшиков механизм

RED на потоках >10мбит/с в зубы , отрежет всё

 

Блокирование сервисов - к добру не приводит ... только гуманными способами ограничивать ...

[pavlabor 1 914]

Не знаю как у других , физику не обманешь ... С UDP думаю не смысла писать , не зря доссеры раньше использовал UDP/80 ...

Автор написал мысли и в кое-чем прав (если откинуть ряд тех. глупостей ) , но TCP довольно легко шейпится(ограничивается) , даже обычный буфер fifo

чудесно выделит полосу , при этом входящая полоса (до ограничения ) максимум отличается на 10%(кратковременно) ... Для мега-гига качальшиков механизм

RED на потоках >10мбит/с в зубы , отрежет всё

 

Блокирование сервисов - к добру не приводит ... только гуманными способами ограничивать ...

 

В статье не говорится что шейп не режит, режит и вот выдержка из стати где показано как он режет!

=================8<---------------------

Если кто-то не понял,

Рисунок 1.

А - структура трафика до пайпа

В - пайп, его счетчик и его работа.

С - структура трафика после пайпа.

До пайпа идет нерегламентированный трафик "А",

он регистрируется счетчиком правила, точка "В1", он отражается в статистике,

тут же обжимается в значение пайпа, точка "В2", лишний трафик ставится в очередь и пропускается по мере освобождения полосы, если канал загружен полностю, пакет в очереди утаревает и дропается, при больших нагрузках и длительных закачках никакой очереди не хватит накапливать пакеты,

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

=================8<---------------------

 

Цель статьи обратить внимание на трафик "А",

именно на ту часть что клиент использует входящую полосу провайдера гораздо больше, чем оплатил (трафик "С")

Расписан как с помощю торента, фходящуюю полосу можно поднять в несколько раз, тем самим забить входящий канал провайдера.

Для одного клиента покупающего 1 мегобит и забивающего входящий канал на 2 мегабита это не смертельно,

Но если таких клиентов много то провайдер вынужден расширять входящий канал существенно,

у некоторых провайдеров, полоса уходящяя в никуда составляет до 40%.

Это означает, что при покупке 100мегабит внешнего трафика, 60 мегабит разбирается клиентами, а 40 сжигается пайпами.

Крутые?

Можете позволить и больше?

Да на здоровье, статья написана для оптимизации внешнего канала, нормальными провайдерами!

 

И блокировка сервисов, если он а выходит из под контроля, есть у любых нормалных провайдеров,

например по Воле буквально неделю назад человек наисал что провайдер блокировал вирус по рассылке спама, включил комп, через десять минут бан, и звонок по телефону.

А стоило бы им печалиться, с 20 гигами внешних каналов?

Просто нормальный подход, не то что у Телекома!

 

Не нужно путать предоставление услуги и бардак,

провайдер регламентирует свою работу согласно закона о телекомуникациях,

должен отвечать на письма при дос атаках на всякие структуры,

предоставлять отчеты правоохранительным органам по запросам саязаных с пользованием интернетом.

И правило хорошего тона, предупреждать клиента о возсожных посдедствиях.

 

Более того, я даю 100% гарантию что у все 100% провайдеров присутствует полоса мертвого трафика которая сжигвется в шейпах,

и можете ставать в позу и раставлять пальцы, покупать дополнительную полосу.

А можете сделать выводы как повлиять на ситуацию.

 

Один провайдер не понимал проблемы пока каналы и железо вытягивало потоки,

но когда ресурсы исчерпались и стал вопрос выложить 20ка зелени на реструктуризацию,

почемуто сразу все понял. Потому как не может полторы тысячи абонентов потреблять 200мегабит трафика!

 

Поетому всему свое время!

 

В целом, немного удивлен, довольно широким непониманием ситуации!

Ожидал более конструктивное обсуждение вопроса.

[adeep 212]

В статье не говорится что шейп не режит, режит и вот выдержка из стати где показано как он режет!

 

Цель статьи обратить внимание на трафик "А",

вам тут пытаются объяснить, что траффик "A" существует пренебрежительно малое время до устаканивания скорости. А скорость регулируется автоматически механизмами TCP протокола, либо (в случае UDP) протокола едущего поверх UDP (исключаем случаи вредительства и DOS аттак).

 

И блокировка сервисов, если он а выходит из под контроля, есть у любых нормалных провайдеров,

например по Воле буквально неделю назад человек наисал что провайдер блокировал вирус по рассылке спама, включил комп, через десять минут бан, и звонок по телефону.

ключевые фразы в вашем примере: вирус, бан, и звонок по телефону.

если найдете там слова "торрент", "заблокировать вообще траффик", "закрыть UDP" выдам вам премию.

 

провайдер регламентирует свою работу согласно закона о телекомуникациях,

должен отвечать на письма при дос атаках на всякие структуры,

предоставлять отчеты правоохранительным органам по запросам саязаных с пользованием интернетом.

И правило хорошего тона, предупреждать клиента о возсожных посдедствиях.

и еще раз, где тут слова про торренты и про то что можно блокировать траффик?

в нашей стране траффик можно блокировать по решению суда, относящегося к недавнопринятому закону "404"

 

Потому как не может полторы тысячи абонентов потреблять 200мегабит трафика!

это если тарифы по 64кбита на абонента, тогда да.

А при уровне мультиплексирования 10, тарифе 2мбит/с на человека, 1000 человек онлайн получаем:

1000 * 2 / 10 = 200мбит траффика.

[Maxxx 442]

А у вас наблюдается резкое увеличение pps ?

Тут народ волнуется.

http://forum.nag.ru/forum/index.php?showtopic=55025

[andryas 1 058]

Да

[adeep 212]

да, наблюдается. и там даже уже нашли пояснение.

Как раз четко дающее ответ на вопрос, поднятый в этом топике: в udp протоколе торрента суммарный траффик (емкость канала) не меняется. Меняется структура траффика - появляется больше мелких пакетов, что для провайдера на самом деле более опасно чем рост траффика.

[pavlabor 1 914]

да, наблюдается. и там даже уже нашли пояснение.

Как раз четко дающее ответ на вопрос, поднятый в этом топике: в udp протоколе торрента суммарный траффик (емкость канала) не меняется. Меняется структура траффика - появляется больше мелких пакетов, что для провайдера на самом деле более опасно чем рост траффика.

 

Емкость канала до шейпа увеличивается.

Занимаюсь этой проблемой не с средины февраля, а несколько лет.

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

Проблему с выходом новой версии торента, не связывал.

 

Вот реакция

========8<--------

Согласен, я просто рубанул всех кто качал по протоколу uTP, и загрузка упала мгновенно, дальше начала потихоньку расти, пока сильно не выросла, а вот ближе к вечеру все должны вернуться к работе по TCP и увеличить загрузку канала. Это будет уже результат.

Я не говорю что нашел способ экономии полосы, я всего лишь пытаюсь ограничить работу протокола uTP, и как следствие уменьшить нагрузку в PPS

========8<--------

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

Даю 100% гарантию, больше двух месяцев не продержится даже самый крутой провайдер, UDP будет зарезан.

 

Новая версия торента, применяет технологию уменьшения пакета до 150, именно для увеличения ширины шейпа и при этом уменьшения дропнутых пакетов.

То есть получения с канала КПД больше 100%.

 

Плевки в мою сторону, не провоцыруют меня расписывать проблему боле детально.

 

ps.

Или провайдеры имеющие 1-2тысяч абонентов, готовте техническую базу такую, какая какая была у провайдеров 10-15 тысяч абонентов.

В противном случае нагрузку не выдержать ни внешние канали, ни железо.

[Гайджин 574]

даю 100% гарантию, больше двух месяцев не продержится даже самый крутой провайдер, UDP будет зарезан.

На НАГе эту тему побнял мой товарищ, а я в это время как раз разбирался что происходит и как "лечить".

На текущий момент ничего лучшего, как увеличить процессорные мощности и количество BRASов раза в полтора и срезать по сигнатуре uTP я не вижу.

Новая версия торента, применяет технологию уменьшения пакета до 150, именно для увеличения ширины шейпа и при этом уаеньшения дропнутых пакетов.

Намерения у них были может быть и не те о которых ты говоришь, но следствия однозначно те.

Плевки в мою сторону, не провоцыруют меня расписывать проблему боле детально.

Я прочитал то что ты написал - на 90% согласен с выводам. Более того, имею реальные подтверждения твоим словам.

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

А посему предлагаю развивать данную тему, тем более что повод имеется.

Или провайдеры имеющие 1-2тысяч абонентов, готовте техническую базу такую, какая какая была у провайдеров 10-15 тысяч абонентов.

В противном случае нагрузку не выдержать ни внешние канали, ни железо.

Внешние каналы пока как раз справляются, да и резервы есть. А вот то, что за одну неделю на 30-50% увеличилось количество PPSов - это не порадовало.

Т.е. существующие процессорные мощности могли потянуть еще 3-4К абонентов, но не потянули, потому что появился uTP и весь это запас ущел на обеспечение его нужд.

А выкинуть несколько $К только из за того что у кого то были благие намерения как то не хочется.

[pavlabor 1 914]

На текущий момент ничего лучшего, как увеличить процессорные мощности и количество BRASов раза в полтора и срезать по сигнатуре uTP я не вижу.

 

Контроль по сигнатуре слабо помогает и ненадолго.

 

Ноги у торента растут с 1997 года,

тогда вышел VAMPIRE, который позволял качать в десять сесий,

гдето в 2000 году, столкнулся с проблемой как на диалап канал выжимали 200%,

Афигел.

Ответ оказался прост, в контора на 50 компах, работали Вампиры.

Статистика на интерфейсе клиента была согласно заявленой, а на стороне провайдера подскакивала до 200%.

 

В 2002 году торент подобные проги уже стали становится популярными

и гдето в это время обнаружил что это аморфная прога,

не позволяющяя себя контролировать.

Сигнатуры могли менятся как угодно и когда угодно.

Даже цыска со своими анонсами решений, не давала ефекта.

В 2004 году, к билингу был написан скрипт который стряхивал качальщиков,

анализируя структуру нагрузки.

 

За время его работы, не одно решение было придумано и провалилось,

анализ по структуре трафика, до сих пор работает как часы.

 

Анализ торента наводит на мысль что это не чесный сервис,

а пиратский подход к пользованию инетом.

Цель - анонимность источников, уход от контроля на уровне маршрутизации,

то есть тотальный подход выведение сервиса с под какого либо контроля в том числе и с под ограничений шейпа.

Не исключаю что в будущем, торент подобный софт, будет запрещен, силовиками как класс.

[Гайджин 574]

В 2004 году, к билингу был написан скрипт который стряхивал качальщиков,

анализируя структуру нагрузки.

За время его работы, не одно решение было придумано и провалилось,

анализ по структуре трафика, до сих пор работает как часы.

А более подробно можно? - Как ты "в лет" анализируеш структура трафика?

Интересуют принципы и на каком железе это выполнено?

 

Анализ торента наводит на мысль что это не чесный сервис,

а пиратский подход к пользованию инетом.

Цель - анонимность источников, уход от контроля на уровне маршрутизации,

то есть тотальный подход выведение сервиса с под какого либо контроля в том числе и с под ограничений шейпа.

Не исключаю что в будущем, торент подобный софт, будет запрещен, силовиками как класс.

Ну мысль это пессимистичная... - Очень похоже что ребята пытались и правда сделать хорошее дело, да вот только не смогли...

[nightfly 1 221]

Или провайдеры имеющие 1-2тысяч абонентов, готовте техническую базу такую, какая какая была у провайдеров 10-15 тысяч абонентов.

Ну чуть больше и что?

Вы так и не ответили на вопросы - "когда уже сворачивать бизнес"? и "что я делаю не так?"