Comments 15
UFO just landed and posted this here
Используется, особенно в небольших.
Блокировка — отдельная интересная тема. Действительно, в связи с последними инициативами наших законодателей провайдерам приходится что-то предпринимать. Те, у кого бюджет позволяет — ставят «промышленные» решения DPI. Те, что поменьше, часто поступают так — берут тот самый список Роскомнадзора, трафик на запрещенные IP заворачивают в сторону (как правило, не с помощью access-lists, а с помощью средств динамической маршрутизации), потом по WCCP перенаправляют на внешний кэш, и там уже разбирают по URL.
Блокировка — отдельная интересная тема. Действительно, в связи с последними инициативами наших законодателей провайдерам приходится что-то предпринимать. Те, у кого бюджет позволяет — ставят «промышленные» решения DPI. Те, что поменьше, часто поступают так — берут тот самый список Роскомнадзора, трафик на запрещенные IP заворачивают в сторону (как правило, не с помощью access-lists, а с помощью средств динамической маршрутизации), потом по WCCP перенаправляют на внешний кэш, и там уже разбирают по URL.
Блокировку, по крайней мере в России, проще делать модулем iptables. Проскакивал где-то специальный модуль, который даже списки сам обновляет.
А iptables умеет искать строку не в одном отдельно взятом пакете, а в сессии? В принципе, он вроде бы имеет некоторые stateful-фичи, так что может и уметь. Исследую вопрос при случае, спасибо за наводку.
Повторюсь — там специальный модуль, именно для России. Разработчик — какая-то русская компания.
К сожалению, найти сейчас не смог — щелкнул когда-то баннер на nag-е, прочитал из интереса, но я не в России :).
К сожалению, найти сейчас не смог — щелкнул когда-то баннер на nag-е, прочитал из интереса, но я не в России :).
ответил в ЛС
Вот случайно увидел на nag-е баннер, открыл — может будет интересно:
www.carbonsoft.ru/products/reductor/carbon-reductor-4.0.2/?utm_source=naga&utm_medium=banner&utm_campaign=reductor
www.carbonsoft.ru/products/reductor/carbon-reductor-4.0.2/?utm_source=naga&utm_medium=banner&utm_campaign=reductor
Используется разве что в некоторых регионах, где это выгодно.
Обычно дешевле докупить канал, чем кешировать. Оно даёт максимум 1-2 процента экономии.
Обычно дешевле докупить канал, чем кешировать. Оно даёт максимум 1-2 процента экономии.
И какова эффективность всего этого дела? Хоть на 3% удалось снизить веб-трафик во внешнем канале? Затраты окупаются?
Затрат здесь немного — сервер и труды. Оборудование обычно уже есть. Проект у нас пока в стадии опытной эксплуатации, число процентов назвать не готов. Но уже видно, какой трафик хорошо кэшируется — это прежде всего Windows Update.
Если это организация, где есть AD и возможность выделить Win сервер под WSUS, то лучше так и сделать.
Это — провайдер не в России (в СНГ), с нешироким каналом за границу. Типичный его абонент — индивидуальный пользователь или небольшой офис с парой-тройкой компьютеров под Windows. О WSUS, соответственно, у абонентов понятия никакого нет.
Мы пробовали подсунуть WSUS Windows-машинам прозрачным образом (вместо штатного сервера Windows Update), но наши эксперименты успехом не завершились, к сожалению. А решение с прокси вроде бы работает.
Мы пробовали подсунуть WSUS Windows-машинам прозрачным образом (вместо штатного сервера Windows Update), но наши эксперименты успехом не завершились, к сожалению. А решение с прокси вроде бы работает.
Просто ~10 лет назад я «провайдил» интернет для своей студенческой общаги, для чего поднял роутер на линукс-боксе со сквидом. При том что в общаге была очень ровная социальная группа (умные молодые люди 17-23 лет), было тесное социальное общение, работал мессажник (vypress messanger), по которому разлетались по внутренней сети бродкастом ссылки на лулзы, был посещаемый внешний портал с курсачами и т.п., а оплата внешнего канала шла по трафику — по факту сквид давал всего порядка 2% экономии.
Если прикинуть, что сервер с дисками для сквида стоит $2k при эффективности сквида 2%, ежегодные расходы на внешний трафик должны обходиться минимум в $100k. Это, наверное, работает для Тикси и Нерюнгри, где интернет только спутниковый, но в нормальных сетях — вряд ли. Не представляю себе таких сумм за внешний интернет-канал в современном мире.
И торрентов с ютубами, кстати, тогда не было.
Если прикинуть, что сервер с дисками для сквида стоит $2k при эффективности сквида 2%, ежегодные расходы на внешний трафик должны обходиться минимум в $100k. Это, наверное, работает для Тикси и Нерюнгри, где интернет только спутниковый, но в нормальных сетях — вряд ли. Не представляю себе таких сумм за внешний интернет-канал в современном мире.
И торрентов с ютубами, кстати, тогда не было.
Странно это. В 2000-2004 годах крутил squid. Сначала в провайдерской сети, а затем в сети офиса. В провайдерской сети был выигрыш в районе 30 процентов. В пользовательской в районе 40 процентов. Правда я и в том и в другом случае этот squid реально крутил. Смотрел логи, генерировал отчеты и настраивал. На мой взгляд прокси тогда был очень оправдан, сейчас, если оплата за канал (а не за трафик) не стоит и заморачиваться.
Sign up to leave a comment.
Еще одна статья о кэшировании веб-трафика