Возможности веб кэширования брандмауэра ISA

Published on Февраль 16, 2009 by   ·   Комментариев нет

Введение

ISA может работать в качестве брандмауэра, в качестве брандмауэра и сервера веб кэширования (лучший вариант), или в качестве выделенного сервера веб кэширования. Можно установить сервер ISA в качестве сервера прямого кэширования (forward caching server) или сервера обратного кэширования (reverse caching server). Веб прокси фильтр является механизмом, который ISA использует для применения функции кэширования.

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

ISA поддерживает прямое кэширование (для исходящих запросов) и обратное кэширование (для входящих запросов). Брандмауэр ISA также может одновременно выполнять прямое и обратное кэширование.

При прямом кэшировании брандмауэр ISA располагается между внутренним клиентом и веб серверами интернета. Когда внутренний клиент отправляет запрос на веб объект (веб страницу, графику или другой веб файл), он должен пройти через брандмауэр ISA. Вместо того, чтобы направить запрос на интернет веб сервер, брандмауэр ISA проверяет свой кэш, чтобы определить, существует ли там копия требуемого объекта (поскольку кто-то во внутренней сети уже запрашивал такой объект с интернет веб сервера).

Если объект имеется в КЭШе, брандмауэр ISA отправляет этот объект из КЭШа, в результате чего отсутствует необходимость отправлять трафик в интернет. Получение объекта из КЭШа брандмауэра ISA по локальной сети происходит быстрее, чем его загрузка с интернет веб сервера, поэтому внутренние пользователи видят повышение производительности.

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

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

В любом случае, кэш представляет собой область на жестком диске брандмауэра ISA, которая используется для хранения запрашиваемых веб объектов. Можно контролировать объем места на диске, выделяемого под кэш (и тем самым максимальный размер КЭШа). Можно также контролировать максимальный размер объектов, записываемых в кэш, не позволяя тем самым двум объектам больших размеров заполнить весь кэш.

Кэширование также использует системную память. Объекты записываются в RAM, так же, как и на диск. Объекты, записанные в RAM, можно получить быстрее, чем те, которые записаны на диск. ISA позволяет определять, какой процент оперативной памяти можно использовать для кэширования (по умолчанию ISA использует 10% памяти RAM, а остальные объекты записывает в кэш на диске). Можно установить процент использования памяти в пределах от 1до 100%. Выделение оперативной памяти задается, когда запускается служба брандмауэра. Если вы хотите изменить объем используемой оперативной памяти, вам нужно остановить и перезапустить службу брандмауэра.

Такая возможность контролировать объем памяти, выделенной под кэширование не позволяет потреблять все ресурсы компьютера ISA Server на кэширование.

Заметка: Уделяя особое внимание безопасности и функциям брандмауэра, кэширование не включено по умолчанию, когда вы устанавливаете брандмауэр ISA. Необходимо включить его, прежде чем можно будет воспользоваться этой функцией.

Использование функции кэширования

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

  • Раздел под кэш должен быть локальным диском. Нельзя настроить сетевой диск на содержание КЭШа.
  • Диск КЭШа должен располагаться в разделе с файловой системой NTFS. Нельзя использовать разделы FAT или FAT32 для диска КЭШа.
  • Лучше (но не обязательно) не использовать тот же диск, на котором установлена ОС и/или приложение ISA Server. Производительность будет лучше, если содержать кэш на отдельном диске. На самом деле, для наилучшей производительности кэш нужно разместить не просто на отдельном диске, а на отдельном I/O канале (то есть, диск КЭШа не должен быть подключен на один канал в качестве слейва (slaved) с диском, на котором содержатся файл страниц, OС или программные файлы ISA). Более того, если производительность брандмауэра имеет для вас значение, запись логов MSDE потребляет больше ресурсов, чем запись текстовых логов. Поэтому если используется запись логов MSDE, привод КЭШа также должен быть на другом диске, а не на том, на котором расположены базы данных MSDE.

Заметка: Можно использовать утилиту convert.exe для преобразования FAT или FAT32 раздела в NTFS без потери данных.

Файл, в котором хранятся объекты КЭШа, называется dir1.cdat. Он располагается в папке urlcache на диске, который вы настроили для кэширования. Этот файл обычно называется файлом содержимого КЭШа (cache content file). Если файл достигает своего максимального размера, более старые объекты удаляются из КЭШа для освобождения места новым объектам.

Файл содержимого КЭШа не может быть больше 64ГБ (конечно, можно задавать меньший размер). Если вы хотите использовать более 64ГБ для КЭШа, вам необходимо настроить несколько дисков для кэширования и распределить кэш на несколько файлов.

Никогда нельзя пытаться редактировать или удалять файл содержимого КЭШа.

Правила кэширования брандмауэра ISA

ISA использует правила кэширования, позволяющие вам настраивать, какие типы контента будут храниться в КЭШе, а также что будет происходить с этим содержимым, когда поступает запрос на объект, хранящийся в КЭШе.

Можно создавать правила для управления сроком, в течение которого кэшированные объекты будут считаться действительными (не позволяя хранящимся в КЭШе объектам безнадежно устареть), вы также можете настроить, что будет происходить с кэшированными объектами по истечении срока годности.

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

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

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

  • Динамическое содержимое (Dynamic content). Это содержимое, которое часто меняется, и поэтому обозначено, как неподлежащее кэшированию. Если выбрать кэширование динамического содержимого, полученные объекты будут кэшироваться, даже несмотря на то, что они отмечены, как неподлежащие кэшированию.
  • Содержимое для просмотра в автономном режиме. Чтобы пользователи могли осуществлять просмотр в автономном режиме (когда они отключены от интернета), все содержимое должно храниться в КЭШе. Таким образом, когда вы выбираете эту опцию, ISA будет записывать все содержимое, включая ‘некэшируемое’, в кэш.
  • Содержимое, требующее для получения аутентификации пользователя. Некоторые сайты требуют, чтобы пользователи аутентифицировались, чтобы получить доступ к содержимому. Если выбрать эту опцию, ISA будет кэшировать контент, требующий аутентификации пользователя.

Можно также задать Максимальный размер объекта. Используя эту опцию, можно определять пределы размера веб объектов, которые будут кэшироваться по определенному правилу.

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

Помимо управления типом содержимого и размерами объектов, правило кэширования контролирует, как ISA будут работать с получением и обслуживанием объектов из КЭШа. Это относится к действительности объектов. Действительность объекта определяется тем, вышел ли срок его действия (Time to Live — TTL). Истечение сроков определяется свойствами кэширования HTTP или FTP, либо свойствами объекта. Здесь включены следующие опции:

  • Настройка ISA на получение только действительных объектов из КЭШа (тех, срок действия которых не истек). Если срок объекта истек, брандмауэр ISA отправит запрос на веб сервер, на котором хранится объект, и получит его оттуда.
  • Настройка ISA на получение запрошенных объектов из КЭШа, даже если они недействительны. Другими словами, если объект существует в КЭШе, ISA получит и доставит его оттуда, даже если истек его срок. Если в КЭШе отсутствует версия объекта, ISA отправит запрос на веб сервер и получит его оттуда.
  • Настройка ISA, чтобы он не маршрутизировал запросы. В этом случае ISA полагается исключительно на кэш для получения объектов. Объекты будут возвращаться из КЭШа независимо от того действительны они или нет. Если версия объекта отсутствует в КЭШе, ISA вернет отчет об ошибке. Он не будет отправлять запрос на веб сервер.
  • Настройка ISA, чтобы он никогда не сохранял объекты в КЭШе. Если вы настроите правила так, то запрашиваемые объекты никогда не будут сохраняться в КЭШе.

Заметка: Стандартное TTL для FTP объектов составляет один день. TTL пределы для кэшированных HTTP объектов (которые задаются в правиле кэширования) состоят из процента возраста содержимого, основываясь на том, когда оно было создано или в последний раз изменено.

Можно контролировать, будет ли HTTP и FTP содержимое кэшироваться в специальном месте назначения, а также задавать политики истечения срока для HTTP и FTP объектов. Можно также контролировать включение и отключение кэширования для SSL контента.

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

Если у вас есть несколько правил кэширования, они будут представлены в порядке от первого к последнему, при этом стандартное правило будет обрабатываться после всех пользовательских. Стандартное правило создается автоматически во время установки ISA. Оно настроено на получение только действительных объектов из КЭШа, и на получение объектов из интернета, если в КЭШе отсутствуют запрашиваемые объекты.

Функция загрузки контента

Функция загрузки содержимого используется для планирования ISA на загрузку нового содержимого из интернета в предустановленное время, чтобы, когда веб прокси клиенты запрашивают эти объекты, их обновленные версии находились в КЭШе. Это повышает производительность и позволяет клиентам получать самое свежее содержимое быстрее.

Можно производить мониторинг доступа в интернет и его использования для определения того, какие сайты пользователи посещают наиболее часто, чтобы знать, какое содержимое будет запрашиваться в будущем. Затем можно настроить задачи планировщика загрузки содержимого соответствующим образом. Задачу загрузки контента можно настроить на периодическую загрузку одной страницы (URL), нескольких страниц или всего сайта. Можно также указывать, по скольким ссылкам нужно перейти при загрузке сайта. Можно настроить ISA на кэширование даже тех объектов, которые помечены в качестве не подлежащих кэшированию в заголовках управления КЭШем. Однако задачи планировщика загрузки контента не будут выполняться, если веб сервер, на котором хранится объект, требует клиентской аутентификации.

Чтобы воспользоваться этой функцией, необходимо включить группу конфигурации системной политики для задач запланированной загрузки контента (Scheduled Content Download Jobs), а затем настроить задачу загрузки содержимого.

Когда вы включаете группу конфигурации системной политики для Schedule Content Download Jobs, это заставляет ISA блокировать неаутентифицированный HTTP трафик с локального хоста (сервера ISA) ‘ даже если у вас настроено другое правило, позволяющее такой трафик. Есть прием, позволяющий разрешить такой трафик и в то же время использовать задачи загрузки контента. Он включает создание правила для разрешения HTTP доступа для Всех сетей и позволяет быть уверенным в том, что другое правило, имеющее более высокий приоритет, настроено на разрешение HTTP доступа с локального узла.

Управление кэшированием посредством HTTP заголовков

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

Мета теги представляют собой команды в HTML коде документа, указывающие истечение срока HTTP или статус невозможности кэширования, но они обрабатываются только КЭШами обозревателей, а не прокси КЭШами. Однако HTTP заголовки обрабатываются прокси КЭШами и КЭШами обозревателей. Они не вписываются в HTML код; они настраиваются на веб сервере и отправляются веб сервером до того, как отправляется содержимое HTML.

HTTP 1.1 поддерживает категорию заголовков под названием заголовки ответов управления КЭШем. Используя эти заголовки, веб разработчики могут управлять такими вещами как:

  • Максимальный возраст (максимальное количество времени, в течение которого объект считается действительным, основываясь на времени запроса)
  • Возможность кэширования
  • Требования возобновления статуса действительности (Revalidation requirements)

ETags и Last-Modified заголовки генерируются веб сервером и используются для подтверждения того, является ли объект свежим.

В службе Microsoft Internet Information Services заголовки ответов управления КЭШем настраиваются во вкладке HTTP Headers страниц свойств веб сайтов или веб страниц.

ISA не кэширует ответы на запросы, содержащие определенные HTTP заголовки. Сюда входят:

  • Cache-control: no-cache response header (кэш-контроль: заголовок ответа без КЭШа)
  • Cache-control: private response header (кэш-контроль: заголовок частного ответа)
  • Pragma: no-cache response header
  • www-authenticate response header (заголовок ответа аутентификации)
  • Set-cookie response header (заголовок ответа установки кукисов)
  • Cache-control: no-store request header (кэш-контроль: заголовок ответа с невозможностью хранения)
  • Заголовок ответа авторизации — Authorization request header (за исключением случая, когда веб сервер также отправляет cache-control: public response header (кэш-контроль: заголовок публичного ответа))

Заключение

В этой статье мы рассмотрели часть брандмауэра ISA, о которой не много сказано ‘ функция веб кэширования в брандмауэре. Можно использовать брандмауэр ISA как совместное устройство веб кэширования и брандмауэр, или даже использовать брандмауэр исключительно в качестве устройства веб кэширования. Независимо от того, как вы решите устанавливать брандмауэр, ваш брандмауэр ISA может кэшировать веб содержимое для увеличения и ускорения производительности интернета для ваших конечных пользователей.

www.isaserver.org


Смотрите также:

Tags: , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]