[Negator]

Да придумать можно многое

Только эффект от разработки оного может превысить всю экономию

[Abram]

Ну самый простой вариант - перенаправлять запросы к ютубу на transparent proxy, кот. будет отдавать контент из своего кэша.

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

хм.... а такое возможно?Или щас начнете говорить "КОнечно возможно, садитесь пишите...пишите...и еще раз пишите (скрипты, проги и т.д. и т.п.)" ))) или такой вариант уже существует?

У Oversi Networks есть решение по кешированию популярного контента (flash video, torrents): www.oversi.com

Даже работает, насколько мне известно :)

Ценник известен?

[Sincha]

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

[secandr]

А вот такая штука не поможет кешировать ютьюб?

 

http://www.cisco.com/en/US/docs/ios/ipapp/configuration/guide/ipapp_wccp.html

[Ivan_83]

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

Реально, но может поломать p2p протоколы, которые будут думать об одних адресах, а по факту ходить через другие.

[dignity]

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

udp во вторую очередь, чтобы геймеры были счастливы (тут можно умнее поступать)

tcp: 80, 443 в третью очередь

остальное в 4ю

 

Вроде все счастливы... Правда мы проблему ограничения трафа не решаем... Раньше решали с помощью Squid прозрачный прокси, если есть cisco, то можно Squid+WCCP

[vurd]

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

udp во вторую очередь, чтобы геймеры были счастливы (тут можно умнее поступать)

Вроде все счастливы...

 

Кроме абонентов, потому как uTP забрало всю вторую по приоритету полосу, в силу того, что протокол основан на транспорте UDP.

[dignity]

ну мы держим потребление на уровне 80% от канала - это 1

это правила per-user и каждый приоритет отдельно шейпится в рамках тарифа... Все счастливы. Если абонент съест себя удп - это его проблема.

 

мне кажется, что на каждого такого оптимизатора торрентов найдется конкурент без оптимизаций торрентов и пользователь проголосует ногами... Как известно, кроилово ведет к попадалову) хотя wccp + squid все же имеет право на жизнь, с точки зрения повышения сервиса, а не экономии.

[iconnect]

Если дешево и эффективно - то мы несколько раз применяли методику нарезания полосы зеброй при проблемах с одним из аплинков. Если среднее пользовательское потребление в одном из направлений за 5 минут составляет более 6 Мбит, на следующие 5(10) минут скорость этого направления шейпится до 4(или 1) МБит, после чего скорость восстанавливается до скорости тарифа.

Это хорошо работает если основные тарифы больше 15 Мбит.

 

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

И не нужно никакой SCE:-)

 

Дальше, они либо успеют скачать нужный файл, за те 5 минут что им дали работать на полной скорости (а это несколько гигабайт), либо скачают его на следующий цикл. Обычные абоненты под эти правила просто не попадут.

 

В любом случае жесткий rate-limit от аплинка с потерями пакетов будет более чувствительным, причем для всех абонентов, чем периодический шейп ограниченного числа абонентов. В нашем случае это было до 5-10%. Большая часть из которых этого просто не замечала, но такой механизм позволял организовывать нормальную работу остальных 90% абонентской базы при аварийных ситуациях.

 

Цифры можно подбирать опытным путем. У нас мы доходили до 2 Гбит ужимания по внешнему каналу без особых претензий со стороны пользователей.

 

Как вариант алгоритма, отлично показал себя такой цикл для качальщика:

5 мин полная скорость - если превысил лимит по полосе, то след 5 минут урезанная до 2 мегабит - если опять выел 90% от выданных 2 мегабита полосы, то след 5 минут подняли до 7 - 10 - если съел 90% - опять 2 - если полоса освободилась, полная скорость по тарифу.

 

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

 

Здравствуйте. Поделитесь чем и как вы разгружаете магистральный интернет-канал? понимаю что у некоторых их несколько. Но думаю многие сталкивались с таким же вопросом...

 

Жду советов...

[denis_vid]

Если дешево и эффективно - то мы несколько раз применяли методику нарезания полосы зеброй при проблемах с одним из аплинков. Если среднее пользовательское потребление в одном из направлений за 5 минут составляет более 6 Мбит, на следующие 5(10) минут скорость этого направления шейпится до 4(или 1) МБит, после чего скорость восстанавливается до скорости тарифа.

Это хорошо работает если основные тарифы больше 15 Мбит.

 

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

И не нужно никакой SCE:-)

 

Дальше, они либо успеют скачать нужный файл, за те 5 минут что им дали работать на полной скорости (а это несколько гигабайт), либо скачают его на следующий цикл. Обычные абоненты под эти правила просто не попадут.

 

В любом случае жесткий rate-limit от аплинка с потерями пакетов будет более чувствительным, причем для всех абонентов, чем периодический шейп ограниченного числа абонентов. В нашем случае это было до 5-10%. Большая часть из которых этого просто не замечала, но такой механизм позволял организовывать нормальную работу остальных 90% абонентской базы при аварийных ситуациях.

 

Цифры можно подбирать опытным путем. У нас мы доходили до 2 Гбит ужимания по внешнему каналу без особых претензий со стороны пользователей.

 

Как вариант алгоритма, отлично показал себя такой цикл для качальщика:

5 мин полная скорость - если превысил лимит по полосе, то след 5 минут урезанная до 2 мегабит - если опять выел 90% от выданных 2 мегабита полосы, то след 5 минут подняли до 7 - 10 - если съел 90% - опять 2 - если полоса освободилась, полная скорость по тарифу.

 

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

 

Немало качальщиков вполне в состоянии принтскринить график скорости мюторрента и выползти в локальный чат/форум с текстом "че..за..на..". Когда это увидят остальные вас в общении между собой обвинят в недоливе/разводняке. Пиринги и Qos - правильное решение

Изменено 10 декабря, 2011 пользователем denis_vid