[telematic]

телематик, ThreeDHead рассказывайте про кэш

пирапп слышал, предлагали, из того что я знаю на 2010г.

Минусы:

- плохо отдает криптованный торрент

- схема inline т.е. лишняя точка отказа

- ценник конский

 

PeerApp юзаю почти год. Штука неплохая, но Р2Р кеширует фигово, я эту фичу отключил. По поводу ценника - сказать конский он или нет можно только относительно цены аплинка. Тут другая проблема, о которой справедливо уже упоминал кто-то здесь на форуме. При резко растущем бизнесе и, соответственно, полосе аплинка, вы быстро достигните лимита пропускной способности девайса. А расширяется он только одним способом - покупкой ещё одного аналогичного. Так что при резком росте полосы вы будете всё сэкономленное тратить на апгрейд кэша.

 

oversi, общался с ними лично, очень интересная схема, но ценник тоже весьма бодрый

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

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

 

 

Оверси тестирую прямо сейчас, пока он у меня не взлетел, трафик закачки в кэш превышает трафик из кэша абонентам, т.е. пока эффективность устройства отрицательная. Жду, когда заполнится кэш. Да, и у меня только одна лицензия - на Р2Р. Видео нет.

[telematic]

поэтому кешируется только все что идет на 80 порт в инет, заворачивается PBR-ом;

 

О, а можно с этого места поподробнее? Я хотел через DPI заворачивать, но в SCE8080 эта фича не работает, а покупка другого DPI равна по стоимости апгрейду PeerApp.

[Картуччо]

PBR - policy based routing

роут мап на машрутизаторе матчащий по 80 порту и заворачивающий в нужный некст хоп.

[telematic]

PBR - policy based routing

роут мап на машрутизаторе

 

Это я знаю. Мне детали не совсем понятны. Вот взяли мы трафик по 80-му порту, завернули его на отдельный физический порт, с него на кэш. А дальше что? Как вернуть трафик с кэша обратно ко всему остальному?

[Картуччо]

Видимо речь идёт о прозрачном прокси, например, как это делается в WCCP.

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

Потом более менее наладили.

Как с точки зрения абонента, ну его нахер таких экономящих провайдеров.

[ThreeDHead]

О, а можно с этого места поподробнее? Я хотел через DPI заворачивать, но в SCE8080 эта фича не работает, а покупка другого DPI равна по стоимости апгрейду PeerApp.

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

 

Переделали так: Все что идет от абонентов в нелокал, на 80 порт - заворачиваем некстхом на параллельный линк балансера, в разрыв этого линка ставится PeerApp.

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

 

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

 

Что касается - "set ip next-hop 10.30.0.200", то этой строчки можно не писать, это обход багов длинка. В теории её быть не должно, но без неё весь "локал в локал на 80 порт" тоже летит в кэшелку, а это может "абонент к абоненту пошел на сайт". А так этот трафик улетает на соседний стэк и возвращается на 7210 уже не попадая в PBR, и уже идет своими обычными правилами и маршрутами.

 

Блок-схема (если расползется, я не виноват :)

[ абоненты ]---[ DES-7210 10.1.0.254 ]--non-http--------------[ 10.1.0.1 Balancer If1 ]- - -[ НАСы/шмасы/бордер :) ]- - -Интернет
            \[          10.0.0.254 ]----http----[ Cache ]---[ 10.0.0.1  Balancer If2 ]/
                         ||
             [ STACK-3627 10.30.0.200 ]

 

Конфиг:

!
ip access-list extended acl-www-local-to-any
10 permit tcp 10.0.0.0 0.255.255.255 any eq www 
!
ip access-list extended acl-www-local-to-local
10 permit tcp 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 eq www 
!
route-map WWW-VIA-LOCAL-OR-PEERAPP permit 10
match ip address acl-www-local-to-local
set ip next-hop 10.30.0.200
!
route-map WWW-VIA-LOCAL-OR-PEERAPP permit 20
match ip address acl-www-local-to-any
set ip next-hop 10.0.0.1
!
interface VLAN 101
ip policy route-map WWW-VIA-LOCAL-OR-PEERAPP
description On all subscribers ports same that
...
!

 

Из багов - после настройки PBR, на зеркалировании появились подбитые пакеты, а-ля "P 00:1b:11:97:79:46 ethertype Unknown (0x0002), length 68: ", но я грешу на очередные баги длинка. Сто раз пожалели что связались с ним в ядре.

 

Да, забыл - через DPI разворачивать HTTP на кэшелку - плохая идея. Там TCP-Handshake невозможно будет классифицировать, что за ним будет HTTP. Соответственно SYN/ACK на кэшелку не уйдут, а она без этого не сможет нормально отработать.

[telematic]

Переделали так:

Т.е. у вас с бордера весь трафик идёт на "балансер", а с "балансера" PBR-ом выделяется трафик по 80-у порту и в кэш. А линк с "балансера" и второй линк с неhttp трафиком втыкаются в коммутатор ядра.

Так?

[ThreeDHead]

Переделали так:

Т.е. у вас с бордера весь трафик идёт на "балансер", а с "балансера" PBR-ом выделяется трафик по 80-у порту и в кэш. А линк с "балансера" и второй линк с неhttp трафиком втыкаются в коммутатор ядра.

Так?

Я не понял вас :)

 

Схема вообще такая: абонент терминируется на коммутаторе ядра, через балансер уходит на НАС (один из пула НАСов), а там уже через бордер - в мир.

 

Сейчас, между коммутатором ядра и балансером ДВА параллельных линка - через первый "ходит" NON-HTTP, через второй HTTP. В разрез второго мы и ставим кэшелку.

[telematic]

Сейчас, между коммутатором ядра и балансером ДВА параллельных линка - через первый "ходит" NON-HTTP, через второй HTTP. В разрез второго мы и ставим кэшелку.

 

Да, я это и имел в виду. Спасибо за информацию! В понедельник покажу инженерам, может можно будет сделать PBR прямо на бордере.

[ThreeDHead]

может можно будет сделать PBR прямо на бордере.

А вот это может быть и не правильно? ;)

 

Сперва надо определиться с позицией кэшелки в пищевой цепочке в системе.

Вариантов два: а) до НАСа; б) после НАСа

 

В первом варианте - _генерация_ трафика будет уходить к абоненту на скорости доступа!

Во втором - абонент не получит больше, чем положено в тарифном плане.

 

Мы пошли первым вариантом, почему?

Во первых - QoE. Сейчас средняя отдача трафика на кэшелке 12Мбит/с на абонента, и это при тарифах 2/5/10 Мбит/с.

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

В третьих - кэшелке (т.е. её OS) не придется "бороться" с шейпером, когда она будет отдавать трафик, а это значит увеличение производительности.

[telematic]

может можно будет сделать PBR прямо на бордере.

А вот это может быть и не правильно? ;)

 

Просто у меня схема сложнее. У меня с одного бордера трафик расходится по трём потребителям, у каждого из которых свой BRAS и биллинг.

[ThreeDHead]

Просто у меня схема сложнее. У меня с одного бордера трафик расходится по трём потребителям, у каждого из которых свой BRAS и биллинг.

Понятно :)

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

 

Вот это, к стати, уже нарушение теории "сетевого нейтралитета" ;)

[snark]

Различие между радио и фиксой в том, что у радио ресурс последней милей ограничен объективным фактором, который так и называется - "частотный ресурс"

А в фиксе есть такой "объективный фактор"©, как цена и, повторюсь, именно цена прежде всего заставляет людей ставить системы кеширования, DPI и прочая, прочая, прочая.

 

в Мегафоне так таких планов и не ввели

Смотрим "особенности" тарифа "БИТ Android" и видим:

В рамках услуги «БИТ Android» недоступны протоколы передачи данных: eDonkey; DirectConnect (DC++) и BitTorrent.

DPI in action ;)

 

Как вернуть трафик с кэша обратно ко всему остальному?

Вы все тот же "кондовый телефонист"(с)Ваш )))

PBR для 80-го порта (включение на кошках WCCP делает то же самое, только еще и следит за тем чтобы кеш живой был) - это обычная схема прозрачного проксирования:

Как можно видеть - трафик сам пойдет куда надо.

[ThreeDHead]

это обычная схема прозрачного проксирования

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

[Voicemaster]

В топике нет мнения Leiden и слов PCRF/PCEF. Жаль..

[snark]

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

Я про одно, а Вы про другое. Я про принип работы, а Вы про размеры сети.

Раз уж на то пошло, то скажите, пожалуйста, в Вашем случае - в чем великая разница в механизме работы прозрачного проксирования и Вашей системой кеширования (этаким прокси сервером на стероидах), если последняя у Вас работает по тому же принципу, что и обычная прокся, т.е. через заворачивание НТТР трафика?

 

Если смотреть издалека, то получается, что Вы как раз и занимаетесь тем самым прозрачным проксированием - из чего, с Ваших слов, можно сделать 2 вывода:

1. У Вас маленькая сеть

2. Вы корпорат

)))

[vIv]

Смотрим "особенности" тарифа "БИТ Android" и видим:

В рамках услуги «БИТ Android» недоступны протоколы передачи данных: eDonkey; DirectConnect (DC++) и BitTorrent.

...

Для абонентов всех тарифных планов 200 руб./в месяц

DPI in action ;)

Вот уж воистину! 8-D

http://rostov.megafon.ru/internet/frommobile/services/unlim_for_telefon.html

Опция «Интернет для телефона» обеспечит вам круглосуточный доступ в Глобальную сеть без ограничения скорости (до достижения объёма трафика 30 Мб за сутки).

 

Максимальная скорость передачи данных по опции – 7,2 Мбит/сек. Услуга работает через точку доступа internet.

Ежемесячная плата 169 руб./в месяц

Траффик, прошедший через DPI, почти на четверть дороже получается. Существенно дешевле покупать "просто трубу" без лишней обработки.

[kapa]

Траффик, прошедший через DPI, почти на четверть дороже получается. Существенно дешевле покупать "просто трубу" без лишней обработки.

Там 30 против 50 Мбайт в сутки.

 

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

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

[vIv]

Траффик, прошедший через DPI, почти на четверть дороже получается. Существенно дешевле покупать "просто трубу" без лишней обработки.

Там 30 против 50 Мбайт в сутки.

Но после лимита остаётся 64Kbps, что более, чем достаточно для "проверить почту". Мой ведроид жрёть около 15 мегабайт корпоративной почты в сутки плюс около пяти мегабайт на свои ведроидные нужды и погоду.

[kapa]

Траффик, прошедший через DPI, почти на четверть дороже получается. Существенно дешевле покупать "просто трубу" без лишней обработки.

Там 30 против 50 Мбайт в сутки.

Но после лимита остаётся 64Kbps, что более, чем достаточно для "проверить почту". Мой ведроид жрёть около 15 мегабайт корпоративной почты в сутки плюс около пяти мегабайт на свои ведроидные нужды и погоду.

Я на своём не замерял расход, но у многих там path, instagram, foursquare, соц. сети с фотками, навигация...

[ThreeDHead]

Раз уж на то пошло, то скажите, пожалуйста, в Вашем случае - в чем великая разница в механизме работы прозрачного проксирования и Вашей системой кеширования (этаким прокси сервером на стероидах), если последняя у Вас работает по тому же принципу, что и обычная прокся, т.е. через заворачивание НТТР трафика?

Совсем разный принцип обработки запросов.

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

_Для всех_, и для сервера, и для клиента, соединение было абсолютно прозрачным.

[snark]

_Для всех_, и для сервера, и для клиента, соединение было абсолютно прозрачным.

А в случае с прозрачным проксированием оно ну совершенно не прозрачно, за исключением пары заголовков?

Решите упомянуть про разницу в IP адресах, то это уже давно не проблема.

[Ivan_83]

Кто-то использует железки, кто-то пишет netgraph ноды, но всеравно все сводится к одному - разруливанию трафика в угоду своим низменным, напрочь корыстным интересам. )))

Я себе так нигде и не поставил ноду - нет необходимости.

 

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

Я выше писал, что для осчасливливания 99% юзеров хватит просто приоритезации хттп, и доп приоритезации хттп+дст ип, потом сваливания в средний приоритет всех остальных известных протоколов, и выставления низкого приоретут всему не классифицированному, куда попадут все (почти) p2p.

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

 

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

На граффиках было чётко видно: хттп+торренты, остальное мелочи.

Хттп от торрентов легко отделяется и без дпи.

 

Чистим!

Оно вам надо за такие деньги? )

 

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

Это любой вменяемый биллинг может.

[applx]

биллинг на безлимит? есть только фаир юсадж по теме резанья трафика

[ThreeDHead]

_Для всех_, и для сервера, и для клиента, соединение было абсолютно прозрачным.

А в случае с прозрачным проксированием оно ну совершенно не прозрачно, за исключением пары заголовков?

Решите упомянуть про разницу в IP адресах, то это уже давно не проблема.

Проксирование (сквид и прочие) = установить соединение, получать пакеты, модифицировать заголовки, самому отдавать трафик клиенту. Я одной командой вычислю сижу ли я за прокси. И наплевать, используется при этом TPROXY или нет ;)

У PeerApp _не проксирование_ - нету установки соединения с удаленной стороной, нету модификации заголовков, только отдача кэшируемых данных клиенту.