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

[pavlabor 1 950]

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

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

 

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

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

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

нв кадый ип организовывается счетчик,

например, раз в одну минуту снимается статистика.

Если объем трафика превышает пороговое значение, исполняется скрип реакции.

Сегодня у нас рубится UDP протокол, полность кроме 53 порта.

для рубки имеется таблица в ipfw.

То есть скрип имеет две секции,

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

2. динамическое внесение ип в таблицу бана.

Раньше динамически вводили ограничение по количеству сесси,

но в таком случае у клиента валилось все,

при отключении UDP, клиент может зайти в билинг и посмотреть чем вызвано ограничение.

 

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

Через час, ип с бана выводится,

если ситуация повторяется, банится на сутки.

На третий раз банится пока клиент не обратится в службу поддержки.

 

Разруливается на софтовом роутере, фря.

 

В самой первой статье приведен скрин клиента и реакция системы,

Ниже окаунт другого качальщика, но чел качает как бы по правилах,

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

[Гайджин 574]

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

Не сильно ли это накладно? - О какой объеме трафика и PPS вообще идет речь?

[pavlabor 1 950]

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

Не сильно ли это накладно? - О какой объеме трафика и PPS вообще идет речь?

 

Нет не накладно.

 

PPS

На графике клиенту показывается текущее количество пакетов в секунду,

на базе анализа соотношения трафика и количество пакетов, раньше определялась дос атака от клиента,

позже эту опцию отбросили.

Сейчас осталась сигнализация ДОС атаки, на базе разницы количества отпавленых и принятых пакетов,

коректируется средним коеффициентом по системе, на графике рисуется красным.

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

Делить на протоколы накладно.

 

Но это сложный комплекс.

Для скрипта анализа торент-подобного трафика, много ресурсов не требуется,

в текущий момент сам трафик не анализируется

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

Задержка реакции сейчас у нас 10-15 минут потому как проверка идет с периодичностю в 5 минут,

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

 

С цыской не смог реализовать, там действительно нужно было много ресурсов.

 

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

Собственно что и вызвало бурный хохот.

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

Немного удивлен реакцией nightfly, потому как человек вроде сам пишет билинг и на мой взгляд неплохой.

[KaYot 3 711]

А у меня кроме PPS еще и загрузка внешних каналов прыгнула. Вход едва заметно, а исход процентов на 40 поднялся. Я в шоке, циска на бордере тоже

Фильтрация волшебной последовательности по советам НАГа вроде помогает, трафик упал.

[Гайджин 574]

А у меня кроме PPS еще и загрузка внешних каналов прыгнула. Вход едва заметно, а исход процентов на 40 поднялся. Я в шоке, циска на бордере тоже

Фильтрация волшебной последовательности по советам НАГа вроде помогает, трафик упал.

Да - тоже самое имеем... Где то на 20% возрос восходящий поток. - STUN работает...

[ВедхийТип 0]

2 pavlabor Как бы являюсь клиентом укртелекома, но там такая тех.поддержка, которая редко отвечает на вопросы и разъяснительной деятельностью не занимается. Скажите, а разве стоит откидывать тот момент, что при использовании UDP становится 100% не возможным передача больших объемов данных изза отсутствия подтверждения доставки? Вы ведь просто откидываете тот факт, что этот протокол не предназначен и uTorrent к примеру берет на себя функции TCP отвечающую за подтверждение доставки. Получается что вы рассмотрели крайний момент - начало сеанса передачи данных по UDP, а дальнейшие действия клиента по обеспечению целостности вас уже не интересуют.

 

Возможно вы что-то знаете. Не поделитесь? Мне как пользователю оч интересно.

[pavlabor 1 950]

2 pavlabor Как бы являюсь клиентом укртелекома, но там такая тех.поддержка, которая редко отвечает на вопросы и разъяснительной деятельностью не занимается. Скажите, а разве стоит откидывать тот момент, что при использовании UDP становится 100% не возможным передача больших объемов данных изза отсутствия подтверждения доставки? Вы ведь просто откидываете тот факт, что этот протокол не предназначен и uTorrent к примеру берет на себя функции TCP отвечающую за подтверждение доставки. Получается что вы рассмотрели крайний момент - начало сеанса передачи данных по UDP, а дальнейшие действия клиента по обеспечению целостности вас уже не интересуют.

 

Возможно вы что-то знаете. Не поделитесь? Мне как пользователю оч интересно.

 

На самом деле все там довольно просто,

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

 

Чистый UDP не может применятся в транспорте,

самый яркий пример как работает UDP, это DNS.

если выполнить запрос

avtoluks# dig google.com

 

; <<>> DiG 9.4.2-P2 <<>> google.com

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15995

;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 0

 

;; QUESTION SECTION:

;google.com. IN A

 

;; ANSWER SECTION:

google.com. 300 IN A 74.125.87.99

google.com. 300 IN A 74.125.87.105

google.com. 300 IN A 74.125.87.106

google.com. 300 IN A 74.125.87.104

google.com. 300 IN A 74.125.87.103

google.com. 300 IN A 74.125.87.147

 

;; AUTHORITY SECTION:

google.com. 172080 IN NS ns3.google.com.

google.com. 172080 IN NS ns2.google.com.

google.com. 172080 IN NS ns4.google.com.

google.com. 172080 IN NS ns1.google.com.

 

;; Query time: 59 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Thu Feb 25 12:46:20 2010

;; MSG SIZE rcvd: 196

 

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

и первым мы видим ответ

google.com. 300 IN A 74.125.87.99

 

так вот UDP запрос ушол ко всем DNS серверам,

тот кто ответил первым отдал ип 74.125.87.99

клиент уйдет на кластер 74.125.87.99.

 

Если повторить запрос

avtoluks# dig google.com

 

; <<>> DiG 9.4.2-P2 <<>> google.com

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9897

;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 0

 

;; QUESTION SECTION:

;google.com. IN A

 

;; ANSWER SECTION:

google.com. 292 IN A 74.125.87.147

google.com. 292 IN A 74.125.87.99

google.com. 292 IN A 74.125.87.105

google.com. 292 IN A 74.125.87.106

google.com. 292 IN A 74.125.87.104

google.com. 292 IN A 74.125.87.103

 

;; AUTHORITY SECTION:

google.com. 172072 IN NS ns4.google.com.

google.com. 172072 IN NS ns1.google.com.

google.com. 172072 IN NS ns2.google.com.

google.com. 172072 IN NS ns3.google.com.

 

;; Query time: 1 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Thu Feb 25 12:46:28 2010

;; MSG SIZE rcvd: 196

 

При повторном запрсе мы получили первый ответ

google.com. 292 IN A 74.125.87.147

клиент уходит на кластер 74.125.87.147.

 

Почему мы имеем два ип 74.125.87.99 и 74.125.87.147.

Потому что гугль мало того что кластеризирует свою систему,

он еще и произвольно балансирует клиентский трафик между датацентрами.

 

Это возможно только благодаря протоколу UDP ну и особеностями реализации DNS.

UDP, не гарантированая доставка пакета, и ответ принимается тот кто быстрее пришол,

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

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

запрос, ответ, кто не ответил, проблем нет потому как их ответ уже никому не нужен.

Это все на что способен чистый UDP.

 

 

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

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

а трафик будет поступать и померать на порту.

Более того, в этом случае, передатчики работают по мере саоей технической возможности,

забивая входящий канал провайдеру под завязку,

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

А у провайдера выжрет 10, 50 да и 100 уйдет за глаза.

 

Поетому торент использует модификацию протокола RTP.

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

а потом идет серия пакетов по протоколу UDP.

 

Тем самым достигается гарантирование доставки и целосности блока данных.

 

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

этот вопрос в текущее время обсуждается во всем мире.

 

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

Они посчитали что,

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

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

Логично, что при потере пакета 150, повторно нужно закачивть меньше.

Но данный подход привел к чрезмерномц скачку количества пакетов, так как,

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

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

 

То что масово начали сыпатся роутеры, это превышение количества пакетов в секунду.

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

[JMan 1]

Более подробное описание протокола вроде вот ПРОТОКОЛ эмулирует полный поток с гарантированием доставки и прочими функциями ТСП.

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

Тут захотели кроме потери пакета ( и при потере уменьшают окно в 0.78 если ТСП в 0.5) учитывает еще и время в дороге что бы держать такое окно где это время минимально (там я так понял за 2 минуты минимальное помнится и стремится к нему уменьшать и доп задержка что бы не превышала 100 ms), это дает то что как только протокол чувствует что пакет придержали (на шейпе или буфере отправки) больше чем (там формулы есть) то оно понимает что надо уменьшить окно.

Про размер пакета, там мало написано, лишь что минимум 150 байт, и что оно подбирается в зависимости от скорости что бы минимизировать задержки. Как я понимаю типа если не удается уменьшит задержку размером окна отправки то начинаем уменьшать размер пакета. Что на небольших скоростях дает отзывчивость. Но тут грабля когда много таких потоков то даже большого канала начнет не хватать и все потоки начнут снижать размер пакетов что бы держать задержку в нужных диапазонах. Вот такая петрушка. Мое мнение что идея гуд и супер только вот с уменьшением пакета тут лажа, а остальное даже супер. Кстати на тему лавины пакетов перд шейпом как раз спасет ибо будет стараться контролировать эту лавину в размере не больше чем 10% от шейпа, если говорим о настройке в 100 ms окна задержки.

Вот такие мои размышления.

О загрузке Пакетов в секунду подтверждаю было буквально недавно ну максимум до 700 тыс сейчас спокойно под 1 миллион вечерами подбирается. Количество трафика если и вросло то не сильно по графикам это можно считать ошибкой измерения.

[pavlabor 1 950]

Кстати на тему лавины пакетов перд шейпом как раз спасет ибо будет стараться контролировать эту лавину в размере не больше чем 10% от шейпа, если говорим о настройке в 100 ms окна задержки.

 

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

 

Раскажи кто прокачивает оте 10% трафика(которые больше шейпа), за чей счет и кому в итоге те 10% достаются.

 

От себя добавлю что 10% это хотелка, реально может прокачиватся и 200%.

[JMan 1]

Кстати на тему лавины пакетов перд шейпом как раз спасет ибо будет стараться контролировать эту лавину в размере не больше чем 10% от шейпа, если говорим о настройке в 100 ms окна задержки.

 

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

 

Раскажи кто прокачивает оте 10% трафика(которые больше шейпа), за чей счет и кому в итоге те 10% достаются.

 

От себя добавлю что 10% это хотелка, реально может прокачиватся и 200%.

Ну если посмотреть но саму техническую реализацию шейпа и работы ТСП то могу сказать так. Что конечно переюз будет но не такой большой, да прыжки могут быть до 200% если уж очень много сессий будет и если шейп в малоскоростной при мегабитах такого точно не будет.

Тут зависимость от скорости на шейпе и его глубины (размера буфера), ТСП же работает как - увеличивает окно или до максимума или пока не дропнется тогда резко уменьшает его в 2 раза. Если буфер не очень большой (по отношению к скорости) в шейпе то тсп быстрее догадывается что опа надо снизить размер окна передачи. По этому тут главное это размер буфера в шейпе. Конечно играет и количество сессий сколько валит на юзера, ибо тут все сесии ростят окно а потом у большей части появляется в толпе дроп и все резко бах и уменьшили окно. Там чехарда получается одни ростят у других уменьшилось и опять растят. Но до 200% это только возможно на очень низких скоростях (тогда пинг больше 1 секунды у юзера будет). И то это будет скачкообразно максимум спад ибо все сесии снизили окна как начался дроп, хотя может у вас буфер шейпа большой и может 4 сек запомнить тогда 400% прыжки будут. Вернемся теперь к протоколу что в торенте, он не будет ждать дропа от переполнения буфера шейпа, а уже когда увидит что задержка выросла больше чем на 100 мс начнет предпринимать действия с торможения (кстати тогда и до дропа не дойдет, меньше ретрансферов будет). Правда вот этот прикол что с уменьшением скорости общей потока, он начинает уменьшать пакет, то это бьет по маршрутизаторам уже.

Вот такое могу сказать. Так что от части вы правы особенно на небольших сокростях. А по поводу больших провайдеров то там коэффициент мультиплексирования больше чем у маленьких соответственно такие всплески не так видны будут.

[Elisium 10]

Запрещай UDP,

add 6 skipto 10 udp from any to any 53 in via vlan130

add 6 deny udp from any to any in via vlan130

и будет тебе счасте.

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

 

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

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

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

 

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

Собственно что и вызвало бурный хохот.

 

Аяяй .. сколько дискуссий изза слегка уменьшенного ЧСВ.

Судя по вышеприведенным цитатам, крокодилы у вас таки летают, но "нызенько-нызенько" ?

Тоесть, вы все таки не рубите шашкой с плеча весь удп, как писАли РАНЕЕ, а все таки выборочно ??

И есть у Вас такая очень хорошая "защита", а топикстартеру в ТОЙ теме пишете невесть что.

А вдруг послушает и сделает ? А с Вас взятки гладки - у вас "защита, основаная на"

 

К чему тогда такая обида? )) Правда, я уже даже рад за этот мелкий пинок в Вашу сторону.

Изза ВАШЕГО же, скажем так, не в меру "адекватного" ответа и моей возмущенной шпильки вышло много слов о восстановлении справедливости ))

 

п.с. Правда, статья получилась занятная, с дебатами, и так как она посвящалась мне, то я ее оценил ))

Чесное слово ))

 

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

п.п.п.с. да, и в догонку: не поверите, БОЛЬШИНСТВО клиентов от других операторов/провайдеров активно перебегает к нам.

мы чтото неправильно делаем ?

[pavlabor 1 950]

Кстати на тему лавины пакетов перд шейпом как раз спасет ибо будет стараться контролировать эту лавину в размере не больше чем 10% от шейпа, если говорим о настройке в 100 ms окна задержки.

 

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

 

Раскажи кто прокачивает оте 10% трафика(которые больше шейпа), за чей счет и кому в итоге те 10% достаются.

 

От себя добавлю что 10% это хотелка, реально может прокачиватся и 200%.

Ну если посмотреть но саму техническую реализацию шейпа и работы ТСП то могу сказать так. Что конечно переюз будет но не такой большой, да прыжки могут быть до 200% если уж очень много сессий будет и если шейп в малоскоростной при мегабитах такого точно не будет.

Тут зависимость от скорости на шейпе и его глубины (размера буфера), ТСП же работает как - увеличивает окно или до максимума или пока не дропнется тогда резко уменьшает его в 2 раза. Если буфер не очень большой (по отношению к скорости) в шейпе то тсп быстрее догадывается что опа надо снизить размер окна передачи. По этому тут главное это размер буфера в шейпе. Конечно играет и количество сессий сколько валит на юзера, ибо тут все сесии ростят окно а потом у большей части появляется в толпе дроп и все резко бах и уменьшили окно. Там чехарда получается одни ростят у других уменьшилось и опять растят. Но до 200% это только возможно на очень низких скоростях (тогда пинг больше 1 секунды у юзера будет). И то это будет скачкообразно максимум спад ибо все сесии снизили окна как начался дроп, хотя может у вас буфер шейпа большой и может 4 сек запомнить тогда 400% прыжки будут. Вернемся теперь к протоколу что в торенте, он не будет ждать дропа от переполнения буфера шейпа, а уже когда увидит что задержка выросла больше чем на 100 мс начнет предпринимать действия с торможения (кстати тогда и до дропа не дойдет, меньше ретрансферов будет). Правда вот этот прикол что с уменьшением скорости общей потока, он начинает уменьшать пакет, то это бьет по маршрутизаторам уже.

Вот такое могу сказать. Так что от части вы правы особенно на небольших сокростях. А по поводу больших провайдеров то там коэффициент мультиплексирования больше чем у маленьких соответственно такие всплески не так видны будут.

 

Расчеты вы приводите правильные.

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

Где то читал за автомобили, иследования показали, что увеличение проезжой части на 10 сантиметров,

приводит к увеличениию средней скоросто автомобилей на 10 км в час.

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

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

приводит к превышении входящего объема трафика до шейпа до 20%.

Но если использовать UDP, входящий объем трафика может увеличиватся до 200 и даже 400%.

Эти данные видно если снимать статистику каждую секунду,

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

 

Связываю эту проблему с возможным дропанием управляющих TCP пакетов торент протокола.

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

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

Такое подобие микро-дос атак в общем объеме закачки.

 

Новый протокол конечно хорош,

в той части что определяет скорость задержки,

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

то ему цены не будет.

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

[pavlabor 1 950]

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

 

Вам видней, но всеравно спасибо.

 

И я тоже извинился, потому как понял что у чела проблема,

а то что эту проблему, оперативно получается решить только так как я написал,

описано много раз здесь http://forum.nag.ru/forum/index.php?showtopic=55025

 

И еще раз напишу развитие,

где то в начале февраля обнаружил повышение активности,

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

порекомендовал что нужно сделать, реакция такая же как и здесь - нельзя отрубать UDP!

но 15, ситуация стала критической у людей реально падало ядро,

попробовали отрубить и все нормализовывалось,

клиенты начали получать инет.

 

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

говорю времени нет, но распишу и на локале выложу.

Он опять пишет - ну где же статья?

 

Пришлось все отложить написать статью, 21.02 выложил на локале.

22.02 аналогичный вопрос поднялся на наге.

 

К чему это я?

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

Не вникая в ее корни я дал ответ - что делать.

 

Подвожу итоги, считаю что тема с торентом раскрыта.

Проблемы связаные с торентом две:

- Повышеная нагрузка на железо.

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

Как кто будет на это реагировать, сугубо личное дело, зависит от желания и финансов.

 

Удачи.

 

ps.

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

http://forum.nag.ru/forum/index.php?showtopic=55025&view=findpost&p=479035

 

pss.

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

говорит только одно, архитектура вашей сети позволяет переаботать на ПОРЯДОК больше абонентов чем у вас есть сейчас.

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

Но паралельно могут возникнуть вопросы от ваших инвесторов.

- на какую емкость абонентов расчитана сесть, и почему это вдруг, она снизилась до 20%.

если компания не нова, и железо закопано давно,

то ребята вы всадили инвестора, перестраховались и вместо ядра стоимостю 200к зелени закопали 600.

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

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

[_WesT_ 1 016]

Дык, ребята!!!!!! Как собственно боротся с этим? А то както жаба давит, гонять впустую десятки Мегабит.

Может посоображаем все вместе и прийдем к какомуто решению?

Что скажете?

[Sergek 123]

На наге описано че и как и почему с выводами и лекраствами

[adeep 212]

Дык, ребята!!!!!! Как собственно боротся с этим? А то както жаба давит, гонять впустую десятки Мегабит.

Может посоображаем все вместе и прийдем к какомуто решению?

Что скажете?

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

 

За последний месяц объем траффика не изменился, изменилась только структура траффика - больше пакетов стало.

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

[pavlabor 1 950]

Дык, ребята!!!!!! Как собственно боротся с этим? А то както жаба давит, гонять впустую десятки Мегабит.

Может посоображаем все вместе и прийдем к какомуто решению?

Что скажете?

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

 

За последний месяц объем траффика не изменился, изменилась только структура траффика - больше пакетов стало.

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

 

Может и так.

http://www.msk-ix.ru/eng/traffic.html

За год объем трафика вырос больше чем в 4 раза.

Навряд ли кто то может похвастатся ростом клиентской базы в таком же темпе.

 

А на подходе вот такие сервисы

http://korrespondent.net/business/mmedia_and_adv/1051584

все безплатно, немного будут напрягать рекламой!

 

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

на подходе взрослые дядьки

http://internet.beeline.ua/rus/tariffs/rates.wbp

[morfey 82]

Может и так.

http://www.msk-ix.ru/eng/traffic.html

За год объем трафика вырос больше чем в 4 раза.

Навряд ли кто то может похвастатся ростом клиентской базы в таком же темпе.

 

Это к чему? Траффик будет расти всегда, чуть ли не в геометрической прогрессии

 

А на подходе вот такие сервисы

http://korrespondent.net/business/mmedia_and_adv/1051584

все безплатно, немного будут напрягать рекламой!

Таких сервисов, хоть и нелегальных но как г****.

 

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

на подходе взрослые дядьки

http://internet.beeline.ua/rus/tariffs/rates.wbp

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

[mr.Dream 164]

Может и так.

http://www.msk-ix.ru/eng/traffic.html

За год объем трафика вырос больше чем в 4 раза.

Навряд ли кто то может похвастатся ростом клиентской базы в таком же темпе.

Ничего общего с клиентской базой этот коэфициент не имеет. Трафик вырос в связи с техническим прогрессом. А помните, за каким компом вы работали лет 6 назад? Тогда и "диалап" у кого канал вытягивал 56кбит/с было за счастье ) Я лично сидел на 12-24 кбит с обрывами. Других вариантов на тот час небыло. И то шо через пару лет к абоненту будет идти волокно 10 Гб/с понимающих динамику развития технологий людей пугать не должно.

А на подходе вот такие сервисы

http://korrespondent...and_adv/1051584

все безплатно, немного будут напрягать рекламой!

Вот к этому надо готовится А не оралть "ой мля шо будет..."

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

на подходе взрослые дядьки

http://internet.beel...riffs/rates.wbp

Взрослые дядьки тоже не дураки, по этому:

"...предоставляется скорость 100Мбит/с первые 100ГБ трафика в месяц. После исчерпания скорость уменьшается до: 5Мбит/с для download и 0,512 Мбит/с. для upload..."

Это во первых. Во вторых ни один халявный сервер не даст такую скорость. Три - это максимально возможная, а не гарантированная (возможно с жестким лимитом сессий, и еще какими то секретами) - это всего лишь маркетинговий ход. Четыре - скорость не единственный показатель качества (жаль, пользователей "тупых" в последнее время развелось...)

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

 

Правду сказать, я сам заядлый борец с торрентами. Ибо есть оборудование, которое может переварить х-мегабит трафика и у-пакетов в единицу времени. И если количество пакетов достигнет порога, то при мелких пакетах оно может работать на половину полосы пропускания. Я думаю, все об этом знают. И знают об этом разработчки "микро-юдипи", и нас*ать им на оборудование провайдеров.

[alex_o 1 194]

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

на подходе взрослые дядьки

http://internet.beeline.ua/rus/tariffs/rates.wbp

Пионерский подход и должен вымирать как класс. Это закон эволюции . Выживают только те, кто в состоянии осознать себя НЕпионером и изменить подход к бизнесу.

По поводу серъезных дядек, которых вы так боитесь. Тут совсем недавно на наге в одном из топиков админ харьковского билайна засветил график загрузки их канала Харьков-Киев (если кто не в курсе, то этот канал представляет собой транк из двух 1Гб-линков - они где-то в новостях об этом хвастались). Так вот на этом графике у них полка начинается в 10 утра и заканчивается в 4 ночи. Отгадайте с одного раза - какой процент абонентов при этом получает свои обещанные 100М безлимита? Вам никто не мешает поступить точно также - результат будет аналогичный.

[adeep 212]

Может и так.

http://www.msk-ix.ru/eng/traffic.html

За год объем трафика вырос больше чем в 4 раза.

Навряд ли кто то может похвастатся ростом клиентской базы в таком же темпе.

не путайте общий рост траффика (причем на точке обмена траффика, что не так показательно)

с ростом траффика локальным из-за конкретной причины - перехода utorrent на UDP протокол.

Ежегодный рост вполне прогнозируемый (основная причина - расширение тарифов).

 

А на подходе вот такие сервисы

http://korrespondent.net/business/mmedia_and_adv/1051584

все безплатно, немного будут напрягать рекламой!

ну и что?

для онлайн-стриминга хватает от 1мбита до 5

(700мбайт фильм на 80 минут дают около 1,5мбит/с потока)

тем более что они не ави будут показывает и не в таком качестве.

 

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

на подходе взрослые дядьки

http://internet.beeline.ua/rus/tariffs/rates.wbp

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

И да, читайте примечания со звездочкой

[pavlabor 1 950]

Может и так.

http://www.msk-ix.ru/eng/traffic.html

За год объем трафика вырос больше чем в 4 раза.

Навряд ли кто то может похвастатся ростом клиентской базы в таком же темпе.

 

Прогресс это конечно хорошо, только вот оплачивает этот прогресс клиент.

А на фоне подешевления пакетов, тендеции загрузки пользовательских пакетов,

которые практически ВЫНУЖДАЮТ подавать магистральную полосу по не соответствующей стоимости,

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

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

Потому что, то что крутило 150ка абонентов, при таких темпах, через год, нужно ставить на 15ка абонентов.

И если раньше за 100грн. продавалась полоса 1мегабит, а теперь за 100грн продавать 100, то 150ка, вообще превращаются 1.5ка!

Эти клиенты формируют потенциальные финансовые поступления, на которые и строится прогресс.

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

Разработчики торента не ожидали такого развития ситуации,

а разработчики железа и подавно не ожидали что какойто один сервис вырежет 70% общемирового трафика,

как в байтовом, так ив ппс ном выражении.

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

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

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

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

 

Так что, не растопыривайте пальцы...!!!

 

А на подходе вот такие сервисы

http://korrespondent.net/business/mmedia_and_adv/1051584

все безплатно, немного будут напрягать рекламой!

 

То что "такого" как "г-а" есть, это как сказать,

99% пользователей в упор не понимают как его взять!

А то что выше приведеный сервис отдает контент безплатно,

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

В ближайшее время инет заполонят банеры, типа

"Аватар" - хочеш посмотреть в онлайн?

После этого остается только кликнуть,

и ломонутся туда как раз оте 99% пользователей которые не знали как его качнуть с шарового сервака.

Расказывать как скакнет нагрузка?

Расказать сколько на сапорт пойдет звонков - "у меня кино лагает!"

Ну ребята, мы же грамотные пацаны!

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

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

 

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

на подходе взрослые дядьки

http://internet.beeline.ua/rus/tariffs/rates.wbp

 

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

При таких тарифах, их разберет 70%, и чтобы дожить до звездочки, нужно иметь - ой какие не кислые каналы!

И как замечено выше, два гига это абсолютно нечего.

 

Нам, к сожелению, такое не под силу.

[pavlabor 1 950]

ну и что?

для онлайн-стриминга хватает от 1мбита до 5

(700мбайт фильм на 80 минут дают около 1,5мбит/с потока)

тем более что они не ави будут показывает и не в таком качестве.

 

Хватает.

А IGMP протокол придумали, потому что было нечего делать.

[adeep 212]

Прогресс это конечно хорошо, только вот оплачивает этот прогресс клиент.

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

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

Стоимость траффика с 2004 года упала более чем в 1000 раз.

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

Но при этом увеличился стартовая сумма для занятия операторством/провайдингом. Кто успел - тот может модернезироваться, кто не успел, тот думает как обмануть клиента.

 

 

Хватает.

А IGMP протокол придумали, потому что было нечего делать.

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

[pavlabor 1 950]

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

 

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