Меню

Кеш в настройках прокси



Кэширование и правила кэширования

Логика и принципы работы кэширования прокси-сервера подробно описаны в разделе Особенности реализации кэширования в п. Прокси-сервер, настройки и возможности.

Настройка основных параметров кэширования осуществляется на вкладке HTTP кэш окна свойств прокси-сервера (подробнее см. в п. Основные настройки прокси-сервера).

В рамках управления кэшем прокси-сервера в Traffic Inspector реализованы следующие возможности:

  • управление кэшем;
  • операции по управлению правилами кэширования.

В рамках управления кэшем в Traffic Inspector реализованы следующие операции, которые выполняются с помощью специального мастера:

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

Для переноса файла кэша выполните следующие действия.

  1. Запустите мастер настройки кэша. Сделать это можно из блока Прокси-сервер в разделах Сервисы или Сервисы -> Прокси-сервер консоли администратора.
  2. На вкладке Выберите действие выберите желаемое действие – Перенос файла кэша .
  3. На вкладке Опции переноса выберите способ переноса:
    • С проверкой – при выборе этого способа создается новый файл кэша, куда пообъектно переносятся данные, начиная с самых последних (поздних). Если размер нового файла кэша меньше размера данных в старом, то будут отброшены самые старые данные. Если данные были повреждены (например, антивирусом), они также будут отброшены. Полный отчет об операции заносится в журнал системных событий. Старый файл кэша удаляется только в самом конце операции. Поэтому если операция была прервана (например, выгрузкой сервиса), данные не потеряются. Следует учесть, что для этой операции на диске требуется дополнительное свободное место – для старого и нового файла кэша одновременно. Выполнение операции может занять длительное время.
    • С очисткой данных – при выборе данного способа создается новый пустой файл кэша, а старый удаляется. Также выполняется очистка индексной таблицы. Операция осуществляется быстро, но при этом вся информация из кэша теряется.
  4. В ходе переноса файла кэша можно изменить его размер. Для этого на вкладке Размер файла кэша укажите новое значение.
  5. На вкладке Размещение файла введите местоположение нового файла кэша.
  6. Запустите операцию и дождитесь ее завершения.

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

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

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

При всех операциях обслуживания кэша база данных индекса кэша создается заново – это наилучший способ решения различных проблем с ней (повреждения файла и т.д.). Если данные в индексе повреждены не до конца, то они по возможности будут сохранены.

До и после операций настоятельно рекомендуется произвести дефрагментацию файловой системы.

Операции по управлению правилами кэширования

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

В рамках управления правилами кэширования в Traffic Inspector реализованы следующие операции:

  • создание/изменение правила кэширования;
  • удаление правила кэширования.

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

  1. Откройте окно свойств нового или существующего правила кэширования. Сделать это можно с помощью контекстного меню в разделе Сервисы -> Прокси-сервер -> Правила кэширования консоли администратора.
  2. На вкладке Правило введите уникальное наименование правила кэширования и, при необходимости, произвольные примечания. Здесь же можно временно отключить правило, не удаляя его из системы.
  3. На вкладке Применение задайте условия для отбора пользователей, на которых будет распространяться данное правило кэширования. По умолчанию оно работает для всех пользователей. При необходимости можно указать, на какие группы пользователей распространяется правило, а также при каком состоянии счета пользователя оно будет работать (например, только для пользователей из определенной группы, работающих в кредит).
  4. На вкладке Проверка IP укажите IP-адреса получателей, для которых будет работать данное правило кэширования. Для этого введите конкретный IP-адрес или диапазон IP-адресов или укажите предварительно созданную IP-сеть (подробнее про IP-сети см. в п. IP-сети). Здесь же можно указать сетевой порт, при соединении по которому будет срабатывать правило кэширования (по умолчанию 80).
  5. На вкладке Проверка URL задайте параметры отбора сайтов, для которых будет действовать данное правило кэширование на основе их URL-адресов. Здесь может быть три варианта.
    • Не проверять – условия к URL-адресам не предъявляются. Это значит, что правило будет действовать для всех сайтов при соблюдении условий по IP-адресам получателей, типу контента и расписанию.
    • URL запрос или строка в формате регулярных выражений – конкретный URL-адрес или регулярное выражение, которое задает ряд определенных URL-адресов. При выборе этого варианта правило кэширование будет действовать только для сайтов, адрес которой соответствуют заданной строке.
    • Список – предварительно созданный в системе URL-список (подробнее про URL-списки см. в п. URL-списки). При выборе этого варианта можно прямо с данной вкладки перейти непосредственно к редактированию выбранного или созданию нового URL-списка.
Читайте также:  Новый проект настройки sony vegas

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

  1. На вкладке Анализ контента определите типы контента, которые будут кэшироваться согласно данному правилу кэширования. По умолчанию правило работает для всех типов. При необходимости можно указать конкретные типы из числа возможных.
  2. На вкладке Расписание настройте расписание действия правила кэширования. Работа на вкладке аналогична работе на вкладке Расписание в окне свойств пользователя ( подробнее о работе на вкладке см. в п. Общие настройки пользователей ).
  3. На вкладке Действия настройте правила кэширования для ресурсов, удовлетворяющих заданным ранее условиям. Для этого включите принудительную проверку «свежести» всех объектов или задайте условия выполнения такой проверки, включите или выключит кэширование динамических объектов и игнорирование HTTP-атрибутов кэширования, полученных с веб-сервера (эти настройки аналогичны общим настройкам кэширования, подробнее см. описание вкладки HTTP кэш окна свойств кэша прокси-сервера в п. Основные настройки прокси-сервера).
  4. Сохраните внесенные изменения.

Удаление правил кэширования осуществляется с помощью контекстного меню в разделе Сервисы -> Прокси-сервер -> Правила кэширования консоли администратора.

Источник

Небольшой Блог Системного Администратора

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

1. Для начал устанавливаем squid (для Debian 6)

2. Файл с настройка squid.conf лежит в /etc/squid3/. Содержит он около 5,5 тысяч строк. Но не все так страшно, основная масса этого файла — это подробные комментарии к настройкам. Как удобнее внести изменения в файл выбирать Вам. Можно избавиться от всего лишнего в файле таким способом

и получить «голый» файл с настройка, следующего содеражания

Останется внести лишь необходимые изменения в строках. Второй вариант — это редактировать весь файл без его чистки. Что тоже довольно просто если уметь пользоваться поиском в редакторе vi. В этом случае у Вас в помощь останутся много полезных комментариев к настройкам.

Для поиска текста в редакторе vi нажимаем клавишу «/». Если Вы находитесь в режиме редактирования, нужно выйти из него для передачи команд редактору нажатием на «Esc». Получаем такую последовательность действий: «/» > «вводим поисковое слово» > «Enter».

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

Читайте также:  Пределы настройки пкн и пкв

3. Обеспечиваем кэширование запросов

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

После завершения всех настроек, стоит проверить анонимность запросов на страничке http://checker.samair.ru Если все сделано правильно, то результатом будет надпись «Resume: You are using high-anonymous (elite) proxy».

На этом внесение изменений в файл закончены. В конечном итоге squid.conf должен выглядеть так

Для применения настроек останавливаем squid

Подготавливаем директорию кэша squid

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

5. Остается лишь настроить прозрачность прокси. Это обеспечивает незаметную для пользователей локальной сети работу через прокси, т.е. нет необходимости настраивать пользователям программы для работы с прокси. Прозрачность обеспечивается простым перенаправлением http запросов с 80 порта на порт прокси сервера посредством фаервола iptables и включением режима прозрачного прокси в самом squid. Изменения в настройках squid мы сделали выше. Добавляем к правилам iptables еще одну строку:

Обязательно в параметре указывайте нужный интерфейс на котором будет работать прокси: -i eth0. Это избавит Вас от проблем с доступом к web серверу из интернета при наличии более одного активного интерфейса, если таковой будет в будущем на этом сервере. А так же ради безопасности прокси.

Источник

Bog BOS: HTTP proxy/кеш

HTTP proxy (посредник) — программа, выполняющая HTTP-запросы от имени клиентской программы. Используется при необходимости доступа к Интернет из-за firewall. Кеш — средство ускорения доступа за счет локального хранения часто используемых данных. Локальный HTTP кеш встраивается в броузер. Кеширующий HTTP proxy — программа, позволяющая ускорить доступ к WWW и FTP сайтам за счет кеширования данных, запрошенных различными клиентами в одном месте; для общения с броузером использует протокол, предназначенный для proxy. Может также использоваться для прокси без кеширования.

Используется для:

  • уменьшения времени доступа к сайтам (среднее время доступа при попадании в кеш — 0.04 сек.; при промахе — 1.7 сек.)
  • уменьшения нагрузки на канал связи (удешевления доступа: HTTP-пакеты составляют 70-80% трафика и кешируются процентов на 20)
  • выхода за firewall
  • уменьшения нагрузки на http-сервер (при работе в обратном режиме)

Иерархия кеш-серверов. Клиент может обращаться не к одному кешу, а к нескольким серверам, образующим целую иерархию. Связи в иерархии: сосед и родитель. Если документа нет в кеше, он может запросить о наличии у соседей (через ICP, запрос делается в параллель через UDP, кто раньше ответит, тот считается самым быстрым, данный алгоритм обеспечивает автомадический поиск и балансировку загрузки). Если ни у кого из соседей нет, то выдается запрос к родительскому кешу. При запросах могут использоваться URL-шаблоны для выбора предпочтительного пути или некешируемых документов.

  • RFC 2187 Application of Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997
  • RFC 2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997
  • Squid, freeware, развитие Harvest, используется в большинстве случаев
  • apache имеет встроенный модуль кеш-сервера, freeware, не так эффективен как специализированная система
  • OOPS
  • IETF-RD: harvest 1.4pl3, закрыт в 1996, freeware, эффективен
  • Harvest 2, коммерческое развитие
  • W3C: CERN proxy/server, поддерживаемые протоколы: HTTP, FTP, gopher, WAIS, не развивается с 1996, не эффективен, freeware
  • W3C: Jigsaw (на Java), freeware
  • Spinner
Читайте также:  Holdem manager 2 настройка hud для pokerstars
  1. на подходящий (доступный клиентам напрямую) web-сервер положить PAC файл (Proxy Auto-configuration file), который описывает настройки прокси сервера на языке типа JavaScript (имя сервера должно быть «wpad», имя файла — «/wpad.dat»; некоторые клиенты пытаются получать файл «/WPAD.DAT»)
  2. определить в описании DNS домена по умолчанию адрес или CNAME для имени wpad; некоторые клиенты (Windows-Update-Agent) получают IP адрес из имени и используют этот IP адрес в качестве имени сервера
  3. настроить браузер на автоматическое определение настроек прокси (возможно, что придётся что-нибудь перезапустить или перезагрузить, чтобы очистить кеш):
    • Firefox 2.0: настройки, дополнительно, сеть, соединение, автоматически
    • Firefox 1.5: правка, настройки, основные, параметры соединения, автоматическое определение настроек
    • IE 6.0: сервис, свойства, подключениея, настройка LAN, автоматическое определение параметров

Пример PAC файла:

  • проект TERENA «WWW Cache services in Europe» (1998)
    • российская часть проекта (очень старое)
  • HENSA 1996: 6 SGI R4400 170 Mhz, 128MB RAM, 2×6 GB дисковой памяти каждая, более миллиона обращений в день (до 100 в секунду), 15% принципиально некешируемы, 55% удачных попаданий, 30% неудачных.
  • NZGate 1996: 128MB RAM, 10GB hard, 100000 обращений в день, 15% удачных.
  • NLARN 1996 (National Laboratory for Advanced Networking Research, USA): 128MB RAM, 10GB hard. Потрясающей открытости сайт вплоть до файлов с конфигурацией и журналов.
  • NLARN 1999: 512MB RAM, 16-32GB hard, реально используется не более 200 MB RAM и 10ГБ HD при миллионе запросов в день и от 25% до 68% успешных попаданий, 2 миллиона объектов, из них 2000 в VM (средний размер — 15 КБ), 500 fd
  • SingNet — 650000 запросов в день, 53% успешных.
  • Увы! Эффективность кеширования падает с каждым годом. Данные за начало марта 2001: кеш — 7 ГБ; ОП — 120 МБ; 4 запроса/секунду; 22 КБ/секунду; вероятность попадания в кеш — 38%; экономия трафика — 16%.
  • 700 MB на диске, 8 МБ лимит оперативной памяти (реально занимал 40МБ), 2-месячный тестовый прогон, настройки почти стандартные, никаких соседей, процедуры обработки статистики еще неправленные (увы):
  • 3.5ГБ на диске, 14МБ лимит ОП (реально 55МБ), максимальный размер объекта — 4МБ, реальная загрузка (в среднем 40 одновременно работающих клиентов совершенно непредсказуемыми запросами — 5000 хостов в день — верхние 100 обеспечивают 40% трафика; 3 обращения в секунду; 10% CPU P100), настройки почти стандартные, никаких соседей, процедуры сбора статистик переориентированы на подсчет трафика:
    1. к моменту заполнения кеша (неделя) за сутки получалась следующая картина: таким образом экономия — 350MB/сутки (грубо прикидывая стоимость 1МБ в 4 цента- $420/месяц)
    2. в устоявшемся режиме (статистика за месяц), почти то же самое:
  • Web caching on Janet, 1996 (UK education network)
  • Моделирование поведения прокси-кеш в зависимости от нагрузки и размера кеша (апр 1997, replay журнала реальной нагрузки).

Некоторые выводы:

  • Идеальный размер кеша — от 2 до 10 ГБ в зависимости от числа клиентов. Приблизительно 1 ГБ кеша на каждые 100 тысяч запросов/день.
  • Исследования на минимальный размер кеша. При размере кеша 100 МБ трешинг начинался при 100 тысячах запросов в день.
  • При 100 тысячах запросов в день заполненная часть кеша не превышает 15 GB (остальное вымывается).
  • Для 300 000 запросов/день и 8ГБ д.б. hit rate = 52% (при 20ГБ — 60%) В реальности 38%. Что это — разница в методике? в контингенте пользователей? или у некоторых клиентов стоит свой прокси-кеш и наш частично выступает как кеш 3го уровня? времена настолько изменились? byte hit/rate д.б. 33% (для 10 ГБ — 35%), в реальности 16%

Источник

Adblock
detector