Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

400 Часть V. Web-приложения

11.7.

Согласованность кэша

Исходный сервер определяет время актуальности кэшированного ответа. Кэш

же должен перед тем, как отправить запрашивающему клиенту кэшированный ре-

сурс,

убедиться, что он еще актуален. Согласованность кэша — хорошо изученная

проблема для всех форм кэширования на компьютерах. Первоначально согласован-

ность изучалась в связи с использованием многоуровневой памяти компьютера

—

кэшированная копия файла могла измениться на диске. Были предприняты попыт-

ки минимизировать объем затрат, требуемых для проверки актуальности, однако

цена поддержания согласованности менялась в зависимости от контекста. Для

Web-кэшей в последнее время были предложены различные алгоритмы поддержа-

ния согласованности. Согласованность кэша может зависеть от ресурсов и полити-

ки сохранения элементов в кэше. Кэши могут просто возвращать более старое кэ-

шированное значение с добавлением признака устаревания ресурса. Одна из при-

чин такого поведения — отключение исходного сервера или перегрузка кэша.

Заголовок Warning протокола НТТР/1.1 (обсужденный в главе 7, в разделе 7.12.2)

может использоваться для указания того, что возвращаемое кэшированное значе-

ние возможно уже устарело. Агент пользователя может сделать эту информацию

доступной пользователю.

В распределенных файловых системах проблема кэширования была также глу-

боко изучена. Web отличается от распределенных файловых систем по ряду при-

знаков. Обновление ресурса происходит только в одном месте

—

на исходном сер-

вере,

а в распределенных файловых системах это обновление может происходить

в различных местах. Однако в Web присутствие большого числа прокси-серверов и

возможность кэшировать части ответа меняют картину. Кроме того, в Web цена

проверки актуальности выше из-за необходимости установления соединения с ис-

ходным сервером.

Протокол НТТР/1.1 обеспечивает несколько путей для поддержания согласо-

вагнюсти кэша. Если исходный сервер задает определенное время истечения срока

годности ресурса, то прокси-сервер, обеспечивающий семантическую прозрачьюсть

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

нием может быть наличие в заголовке запроса клиента директивы Cache-Control:

only-if-cached, которая заставляет прокси-сервер возвратить кэшированный ответ

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

задает срок годности ресурса, то прокси-сервер может использовать эвристически

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

сти.

Наиболее общим подходом к проверке актуальности в Web является запрос

с методом Get или Head и заголовком If-Modified-Since (обсужденном в главе 6,

раздел 6.2.3). Этот заголовок включает время последней модификации ресурса, ко-

торый был указан исходным сервером. В некоторых случаях время создания ответа

может совпадать со временем последней модификации. Атрибуты содержимого

протокола НТТР/1.1 в совокупности с заголовком if-Match могут быть использо-

ваны для выполнения проверки актуальности для версий ресурсов (см. главу 7,

раздел 7.3.3). Исходный сервер может вернуть полную копию ресурса (вместе с от-

ветом 200 ОК) или ответ 304 Not Modified без тела ответа. Однако проверка акту-

альности требует полного цикла HTTP-обмена запросом и ответом.

Если кэширующий прокси-сервер посылает запрос для проверки актуальности

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

ванной. Если кэш использует эвристические процедуры для оценки сроков годно-

Глава 11. Кэширование 401

сти кэшированного ответа без взаимодействия с исходным сервером, то такая по-

литика называется слабо согласованной. В зависимости от вида кэша и типичного

набора кэшированных ответов может быть подходящей либо первая, либо вторая

политика. Эвристика, основанная на фиксированном времени хранения, а также

эвристики, основанные на времени жизни, относятся к слабо согласованным поли-

тикам. Эти слабо согласованные подходы отличаются тем, какой компонент берет

ответственность за определение периода актуальности ресурса:

Эвристика, основанная на фиксированном времени хранения. Кэш может

хранить ответ в течение фиксировагнюго интервала времени .без проверки ак-

туальности. Однако сервер обещает уведомить кэш в случае изменения ресур-

са в течение периода хранения. После истечения этого периода, кэш может

проверить ресурс на актуальность. Данный подход, описанный в [LC97J, пе-

реносит накладные расходы по проверке актуальности ресурсов на сервер, ко-

торый теперь должен взаимодействовать со всеми кэширующими прокси-сер-

верами, которым он обещал сообщить об обновлениях ресурсов. Если исход-

ный сервер должен уведомить большое число прокси-серверов, то этот способ

не слишком подходит. Отметим, что при этом требуется взаимодействие для

того,

чтобы сервер мог уведомить кэши об истечении времени хранения. Ал-

горитмы, основанные на фиксированном времени хранения, широко обсужда-

ются в литературе, но они еще не реализованы в популярных кэширующих

прокси-серверах. Одна из причин заключается в том, что они требуют совме-

стных действий, сервера и кэша.

Подход, основанный на времени жизни (TTL

—

Time То Live). С каждым от-

ветом связано время истечения срока его годности. Когда этот интервал вре-

мени заканчивается, ответ рассматривается как устаревший. В течение срока

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

можгюсть того, что будет использован устаревший ответ. Значение TTL мо-

жет изменяться в зависимости от ресурса и основано на следующих факторах:

Время истечения срока годности определено в поле заголовка ответа. Кэш

может его использовать непосредственно или модифицировать на основе

своей политики. Если время годности ресурса не указано, то кэш может

назначить определенное значение TTL для ресурсов данного вида.

Частота запросов кэшированного ресурса. Ресурсам, запрашиваемым чаще,

можно назначить большее TTL.

Мобильная среда. Непостоянное подключение и низкая скорость соедине-

ния пользователей мобильных устройств [HL96] может привести к зада-

нию специальных значений TTL для ответов, запрашиваемых такими

пользователями.

Время последней модификации ресурса. Адаптивный алгоритм может

предположить, что недавно модифицированный ресурс может снова изме-

ниться [Cat92]. Следовательно, кэш может назначить меньшее значение

TTL для недавно измененного ресурса. Кэшированному ответу может

быть назначено большее TTL, если на исходном сервере ресурс не изме-

нялся в течение длительного времени. Информация о времени изменения

берется из заголовка ответа Last Modified.

Подходы, основанные на TTL, являются достаточно популярными.

Поддержание согласованности может оказать существенное влияние на время от-

вета кэша, т.к. каждый запрос для проверки актуальности требует установления со-

402 Часть V. Web-приложения

единения с исходным сервером [Joh99]. Высокая цена установления соединения

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

новление. Как было отмечено в главе 10 (раздел 10.3.2) и в ряде исследований

[AFJ99, KW97], ответ 304 Not Modified составляет значительную долю (от 10 до 30

процентов) всех ответов. В главе 13 (раздел 13.1) будут обсуждены некоторые мето-

ды сокращения числа ответов 304 Not Modified. Такие методы снижают число от-

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

пользования «подсказок» исходного сервера, указывающих, когда ресурс изменился.

11.8.

Скорость изменения ресурсов

Скорость, с которой меняются различные ресурсы в Web, варьируется очень

сильно. Некоторые ресурсы, будучи однажды созданы, уже никогда не меняются.

Другие меняются при каждом запросе. Скорость изменения ресурсов определяет

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

• Какие ответы необходимо кэшировать?

• Имеется ли корреляция между скоростью изменения ресурса и частотой обра-

щения к нему?

• Как долго хранить ответ в кэше?

Обнаружение изменений в ресурсах на уровне файлов достаточно легко выпол-

нимо. Однако кэширующий прокси-сервер не может быть осведомлен, как часто

динамически изменяемый ресурс меняется на исходном сервере. Сервер может по-

лучить некоторую информацию об этом из анализа URL ресурса. Например, если

в тексте URL содержится подстрока "cgi" или знак вопроса "?", то можно предпо-

ложить, что ответ создается динамически. Однако это может оказаться не всегда

верным. Точно также, некоторые ресурсы, не содержащие ни подстроки "cgi", ни

знака вопроса "?", могут, тем не менее, изменяться динамически. Динамически соз-

данные ресурсы могут возвращать одинаковое содержимое для каждого запроса, а

некоторые ресурсы, которые могут рассматриваться как статические, могут на са-

мом деле изменяться довольно часто. Например, сайт www.cnn.com регулярно об-

новляет свои страницы путем добавления новостного Web-содержания. Некоторые

страницы изменяются при каждом доступе к ним, например, на странице может

оказаться счетчик доступа к ней. Таким образом, знание скорости изменение набо-

ра ресурсов может помочь в принятия решения о необходимости и длительности

кэширования.

Влияние скорости изменения ресурсов на кэширование может определяться ка-

тегорией ресурса и следующими факторами:

• Тип. Изображения меняются гораздо реже, чем текстовые ресурсы, и, таким

образом, могут дольше не обновляться.

• Частота и периодичность изменений. Если известно, что ресурс меняется

только раз в день (например, комикс на сайте www.dilbert.com), то и кэширо-

вать его надо тоже только в течение суток. Для такого ресурса нет необходи-

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

времени он меняться не будет.

• Размер ресурса. Если небольшие ресурсы имеют тенденцию часто меняться,

то для решения вопроса о времени кэширования этот фактор может быть уч-

тен вместе с частотой обращения к таким ресурсам.

Глава 11. Кэширование 403

Если ресурс имеет время истечения срока годности, тогда нет необходимости

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

ких-либо определенных сроков годности ресурса. Одной из причин такого поведе-

ния может оказаться, что сервер сам не знает точного времени изменения ресурса,

другой причиной является то, что указание сроков годности сокращает график от

кэширующих прокси-серверов. Это в свою очередь уменьшает число обращений

к исходному серверу, от которого зависит плата за размещаемую рекламу.

11.9.

Протоколы кэширования

в зависимости от своей организации в группы кэши могут посылать и прини-

мать информацию о ресурсах, в которых они заинтересованы. Такое взаимодейст-

вие является внешним и отделяется от сообщений, содержащих запросы и ответы,

передаваемые между клиентом и сервером. Межкэшевый обмен может использо-

вать протокол HTTP. Однако обычно используется специальный облегченный

протокол. Если кэши имеют иерархическую организацию, то на одном уровне ие-

рархии кэш может контактировать с другим для запроса хранящегося в нем о объ-

екта. На запрос об отсутствующем ресурсе может ответить один или несколько

серверов, имеющих такой ресурс. Получить копию ресурса из локального кэша вы-

годнее, чем от исходного сервера. Однако ожидание ответа от всех прокси-серверов

данного уровня иерархии может увеличить время ожидания ответа пользователем.

Далее будет рассмотрено несколько известных решений для сокращения стоимости

межкэшевых взаимодействий.

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

своими возможностями и применением. Основной целью создания этих протоко-

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

с другом. Будут обсуждены четыре протокола: Internet Cache Protocol (ICP), Cache

Array Resolution Protocol (CARP), Cache Digest Protocol (CADP) и Web Cache

Coordination Protocol (WCCP).

11.9.1.

Протокол Internet Cache Protocol (ICP)

Кэш, в котором отсутствует запрашиваемый объект, может проверить его нали-

чие в другом кэше. Такой метод взаимодействия отличается от традиционного за-

проса ресурсов у исходного сервера. В этом случае кэши являются как источника-

ми,

так и получателями сообщений. Для этого необходим специальный протокол

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

ствия кэшей и был разработан Internet Cache Protocol (ICP) [WC97b, WC97aJ.

Этот протокол является примером протокола запросов — сообщение, посланное

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

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

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

рующем прокси-сервере Squid [WC98].

Протокол ICP оказался подходящим и для иерархических наборов кэшей, взаи-

модействующих па каждом уровне иерархии и имеющих общего родителя. При пе-

ремещении вверх по иерархии эта схема повторяется, соответствуя перемещению

к центральному кэшу, который может быть подключен к другому центральному

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

в качестве родителя региональный кэш, а набор региональных кэшей может в каче-

404 Часть V. Web-приложения

стве родителя иметь национальный кэш. Предположим, что некоторый кэш (назо-

вем его исходным) не имеет запрашиваемого ресурса. Он посылает 1СР-запрос

(обычно это UDP-сообщеиие) ко всем своим соседям на данном уровне иерархии

одновременно. Успешный ответ будет указывать о наличии требуемого ресурса

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

используя протокол HTTP. Если в кэшах данного уровня иерархии отсутствует

данный ресурс, то исходный кэш пошлет 1СР-запрос родительскому кэшу. Возмо-

жен также вариант, что ответа от кэшей данного уровня иерархии не поступит за

определенный интервал времени, что инициирует в исходном кэше событие, свя-

занное с таймаутом. Родительский кэш повторяет указанную процедуру. Если от

кэшей не поступит ответа, то исходный кэш запросит данный ресурс у исходного

сервера. Предположение, лежащее в основе 1СР-протокола, заключается в том, что

передача кэшам набора 1СР-запросов столько раз, сколько имеется уровней в ие-

рархии, выполняется быстрее, чем взаимодействие с исходным сервером. Кроме

того,

некоторая оптимизация помогает сократить общие издержки. Например, ко-

гда ответ возвращается от исходного сервера или кэша в иерархии, то промежуточ-

ные кэши могут сохранять ответ для будущего использования. Не ответившие со-

седние кэши сообщают о возможности своего взаимодействия с исходным кэшем.

Хотя региональные и национальные прокси могут сократить расстояние, кото-

рое проходят извлекаемые ресурсы для большого числа пользователей, по перехо-

ды между уровнями иерархии могут снижать производительность. Если на теку-

щем уровне иерархии ресурс не найден, то это дает дополнительный вклад в об-

щую задержку. Даже если ресурс будет обнаружен в национальном прокси-сервере,

то это все рав1ю обусловит задержку, связанную с передачей ресурса клиенту, сде-

лавшему запрос.

И.9,2,

Cache Array Resolution Protocol (CARP)

Протокол Cache Array Resolution Protocol (CARP) [CAR] определяет механизм,

с помощью которого группа кэширующих прокси-серверов может функциониро-

вать как единый логический кэш. Набор ответов, который коллективно кэширует-

ся группой прокси-серверов трактуется как один большой кэш. Специальные

хэш-функции используются для кодирования URL ресурсов, хранящихся в раз-

личных кэшах. Клиент, пытающийся найти кэшированный ресурс, может напра-

вить запрос соответствующему кэшу, кодированный с помощью этой функции.

Хэш-функция преобразует запрошенный URL и идентификатор требуемого про-

кси-сервера создавая специальный путь разрешения запроса. По сравнению с ICP

протокол CARP имеет строго определенный путь разрешения запроса, что исключа-

ет необходимость посылок дополнительных запросов. По сравнению с ICP в CARP

используется гораздо меньше повторных запросов. CARP использует как HTTP, так

и вызов удаленных процедур для взаимодействия прокси-серверов друг с другом.

CARP связывает прокси-сервер с коэффициентом нагрузки, который может быть

принят во внимание до того, как запрос будет направлен данному прокси-серверу.

CARP [CAR] реализован основными производителями программных продуктов.

Когда конфигурация кэширующей системы изменяется путем удаления или до-

бавления прокси-сервера, то кэшированные URL должны быть реорганизованы.

При замене содержимого кэша хэшированные значения должны быть вычислены

снова. URL не могут быть представлены в нескольких кэширующих прокси-серве-

рах, и, следовательно, выравнивание нагрузки прокси-серверов затруднено. Высо-

кая популярность некоторых ресурсов приводит к тому, что лишь небольшое под-

Глава 11. Кэширование 405

множество кэшей получает основную часть запросов. Если поиск кэшироваиного

ответа оказывается неудачным, то на некоторое время прокси-сервер должен счи-

таться неактивным.

11.9.3.

Cache Digest Protocol (CADP)

Протокол Cache Digest Protocol [HRW98J является расширением протокола

ICP.

Основная его цель заключается в обмене дайджестами кэшированных ресур-

сов.

Дайджест представляет собой сжатое описания кэшированных ресурсов и оп-

ределяет наличие набора ресурсов в кэше. Когда кэш имеет дайджесты всех других

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

объекта. Если поиск в дайджесте оказывается успешным, то кэш становится канди-

датом на получение запроса на искомый объект. Запрашивающий кэш может даже

выбрать из нескольких кэшей, для которых поиск в оказался успешным. Если про-

верка по дайджесту оказалась неудачной, то взаимодействие с кэшем не осуществ-

ляется. В результате сокращается число сообщений, рассылаемых кэшам одного

иерархического уровня.

Одной из очевидных проблем данного протокола является старение дайджестов

и пересылка ошибочных данных. Объект может быть удален из кэша уже после

создания дайджеста. Другой проблемой является размер набора дайджестов и об-

мен дайджестами на данном уровне иерархии кэшей. При наличии большого числа

кэшей размер набора дайджестов становится очень большим. Проведенные иссле-

дования позволили уменьшить размеры дайджестов [Р'САВЭЗ].

Для обмена дайджестами между кэшами может использоваться схема, принятая

в ICP и основанная на протоколе UDP. Однако для надежности обмен дайджеста-

ми осуществляется с помощью HTTP-сообщений поверх TCP. Дайджесты могут

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

менима технология обновления ресурсов HTTP (с помощью заголовков Expire и

If-Modified-Since).

11.9.4.

Web Cache Coordination Protocol (WCCP)

в отличие от высокоуровневых протоколов типа ICP и CARP протокол Web

Cache Coordination Protocol (WCCP) [WCC99] является координационным меха-

низмом, который связан с сетевым уровнем. Назначением WCCP является пере-

хват HTTP-запросов и переадресации их кэшу. Поскольку запрос может оказаться

отвергнутым (если кэш по какой-либо причине будет недоступен), то необходим

координационный механизм. Задача координатора заключается в выравнивании

нагрузки между множеством кэшей. Периодически проверяя работоспособность

кэша, данная технология гарантирует, что пакеты не будут посланы неработоспо-

собному кэшу.

Такой координационный механизм заложен в ядро протокола WCCP, который

реализован как часть технологии Cisco Cache Engine. Этот механизм настроен на

получение Web-запросов, перенаправленных ему маршрутизатором. Маршрутиза-

тор,

поддерживающий протокол WCCP, способен проанализировать все IP-заго-

ловки и ТСР-пакеты, поступающие на 80-й порт (стандартный порт HTTP), и пе-

ренаправить их кэширующему серверу. Кроме того, WCCP-маршрутизатор перио-

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

406 Часть V. Web-приложения

11.10.

программное и аппаратное обеспечение

кэширования

Кэширование, как это было рассмотрено в главе 3, может быть обеспечено с по-

мощью прокси-серверов. Это решение требует добавления прокси-серверу некото-

рой функциональности. Кроме того, кэширование может выполняться с помощью

специально предназначенного для этого оборудования. В первой части этого разде-

ла в качестве примера будет рассмотрено программное решение — Squid — про-

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

смотрены различные аппаратные решения, требующие установки и настройки но-

вых устройств.

11.10.1.

программное обеспечение кэширования. Squid

Squid является широко используемой кэширующей системой с открытым исход-

ным кодом, которая работает на большом числе платформ, включая Unix, Solans,

Linux, FreeBSD, NetBSD и OS/2. Другими популярными кэширующими системами

являются NetApp [NetaJ, Inktomi [Ink] и Novell Bordermanager [Nov]. Кроме HTTP,

Squid способен работать и с другими протоколами (включая FTP, SSL, Gopher и

WAIS). Он является настраиваемым кэшем: мож1Ю определить, но каким правилам

должен обрабатываться кэшированный ответ (например, тип содержания, продол-

жителыюсть кэширования и т.д.). Для получения более полного представления о

Squid можно ознакомиться с руководством пользователя Squid [Pea97J.

Как и для любого другого прокси-сервера, для Squid необходима настройка на

стороне клиента. Браузеры должны быть настроены на использование прокси-сер-

вера для любого протокола, поддерживаемого Squid (как это обсуждалось в главе 2,

раздел 2.4.2). Например, номер порта для HTTP устанавливается равным 3128, по-

скольку именно его Squid использует для взаимодействия с Web-клиентами но

умолчанию.

Squid может общаться с другими кэшами на данном уровне иерархии но протоколу

ICP.

Взаимодействие с другими кэшами осуществляется по протоколу UDP через

порт 3130 по умолчанию, хотя для взаимодействия может использоваться и HTTP.

Иерархические отношения между кэшами определяются с помощью конфигура-

ционных файлов, иерархия может быть локальной, региональной, национальной и

даже интернациональной. Условное кэширование может быть настроено через гра-

ницы доменов. Например, один Squid может использоваться для кэширования ряда

национальных доменов, таких как .fr и .аи. Для кэширования определенного сайта,

прокси-серверы, расположенные вблизи от него, должны быть зарегистрированы

в центральной базе данных.

Squid контактирует с набором кэшей на данном уровне иерархии, используя

UDP и предполагая, что кэш, который первым сообщает о наличии ресурса, столь

же быстро сможет выдать и ответ. Другими словами, Squid собирает информацию,

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

кэша на том же уровне иерархии не должен кэшироваться на запрашивающем

кэше. Вместо этого запрашивающий кэш может просто позволить кэшу на том же

уровне иерархии служить кэшем для этого объекта, если кэш находится в той же

высокоскоростной сети с малым временен ожидания. Если кэшированной копии

запрашиваемого ресурса нет ни на текущем уровне иерархии, ни в родительском

Глава 11. Кэширование • 407

кэше, то Sqid направляет запрос исходному серверу. Ответ сервера может быть за-

писан в кэш перед отправкой его клиенту.

Squid способен работать в кластере: множество кэшей в одном сетевом сегменте

могут действовать как кэши одного уровня. Преимущество кластерного кэширова-

ния заключается в высокой надежности и низкой цене, так как используются не-

сколько дешевых компьютеров, а не мощный и дорогой сервер. DNS-сервер также

участвует в схеме кластерного кэширования. Определение адреса кэширующего

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

кластера.

Squid использует списки управления доступом (ACL

—

Access Control List) для

определения клиентов, которые могут к нему обращаться как к прокси-серверу.

Список IP-адресов используется для фильтрации входящих запросов. Различные

адреса могут быть определены для различных протоколов. Например, rpyinia кли-

ентов может использовать Squid как кэш для HTTP-запросов, но не для FTP-за-

просов. Squid может быть настроен так, чтобы предотвратить доступ к некоторым

Web-серверам; ACL в этом случае состоит из набора доменов. Например, рассмот-

рим список управления доступом с меткой dumb, содержащий два домена

notbridght.com и nitwit.com:

ас1 dumb dstdomain notbright.com nitwit.com

http^access deny dumb

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

ходящихся позади Squid.

Squid также может функционировать как акселератор для Web-сервера: он мо-

жет быть расположен перед одним или несколькими исходными серверами и обра-

батывать входящие запросы. Для этого Squid должен работать на стандартном для

протокола HTTP восьмидесятом порту. После этого Squid можно настроить для

обработки запросов к одному или более исходным серверам и в случае необходи-

мости переадресовывать входящие запросы на исходные серверы, находящиеся за

Squid. Squid может обрабатывать заголовок Host протокола НТТР/1.1 (см. главу 7,

раздел 7.8) для определения, какой исходный сервер должен получить запрос.

Squid может обеспечивать более высокую производительность, чем исходный сер-

вер.

Когда он настроен как акселератор, то может взять на себя заботу об обновле-

нии ресурсов при изменении их на исходном сервере. Акселератор на основе Squid

работает как зеркало и способен отслеживать изменения на исходном сервере.

Squid не обязан обрабатывать все запросы. Имеется интересная возможность разде-

лить ресурсы сервера на кэшируемые и некэшируемые. Squid обрабатывает запросы

на кэшируемые ресурсы, а Web-сервер, запущенный на хюрту, отличном от стандарт-

ного,

обрабатывает запросы на некэшируемые ресурсы. Например, Squid может на-

правлять все CGI-запросы исходному серверу. Если для внешней сети сделать види-

мым только Squid, то можно предотвратить атаку на исходный сервер, расположен-

ный позади Squid. Например, следующая настройка, сделанная на Squid

acl safe dstdomain safe1.com safe2.com

http^access deny Isafe

позволяет сделать доступными только серверы safel.com и safe2.com. Кэширую-

щий прокси-сервер будет выдавать отказ при запросе любого другого домена.

Подобно многим другим кэширующим прокси-серверам, Squid при записи ре-

сурса в кэш использует модель истечения срока годности. Последние версии Squid

используют различные модели, основанные на частотах обновления ресурсов. Вме-

сто ожидания истечения срока годности ресурса актуальность объекта проверяется

408 Часть V. Weh-приложения

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

мя запроса, если объект устаревает, то он обновляется с исходного сервера. При не-

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

поддерживает заголовки Cache-Control и Expires, которые могут присутствовать

в заголовках запросов и ответов. Предпочтение отдается заголовку клиентского за-

проса (например, Cache-Control: max-age), а не заголовку Expires ответа сервера.

Можно настроить Squid так, что он будет изменять срок годности, указанный в за-

головке Expires ответа.

Последние версии Squid также поддерживают дайджесты кэшей. Новая версия

способна использовать особенности HTTP/1.1, включая долговременные соедине-

ния и аутентификацию прокси-сервера. Squid поддерживает многопоточное испол-

нение, если его поддерживает операционная система. В случае перехватывающих

прокси-серверов пакеты, полученные на один порт, перенаправляются на другой, а

Squid действует как получатель перенаправленных пакетов. Squid также поддержи-

вает протокол WCCP (обсужденный с разделе 11.9.4).

11.10.2.

Аппаратное обеспечение кэширования

Кэширование может быть выполнено также с помощью специального аппарат-

1ЮГ0 обеспечения. При использовании кэширующих прокси-серверов имеет место

несколько проблем:

• браузеры пользователей должны быть настроены для взаимодействия с кэши-

рующим прокси-сервером;

• при наличии нескольких кэшей, необходима организация взаимодействия ме-

жду кэшами для предотвращения дублирования данных;

• если прокси-сервер в какой-то момент недоступен, то придется перенастроить

браузеры пользователей.

Альтернативным способом решения проблем кэширования является размеще-

ние специфической аппаратуры в сети. Такое решение связано с перехватом тра-

фика на различных уровнях (сетевом, транспортном и прикладном). Перехвачен-

ный трафик направляется к одному или более устройствам, выполняющим функ-

ции кэширующего прокси-сервера. Аппаратное решение для кэширования может

быть отнесено к одной из двух категорий: редиректору и комплексному решению.

Редиректор может быть либо маршрутизатором, либо коммутатором, перехваты-

вающим запросы. Комплексное решение кроме функций перенаправления осуще-

ствляет и кэширование.

ПЕРЕХВАТЫВАЮЩИЕ ПРОКСИ-СЕРВЕРЫ И РЕДИРЕКТОРЫ

Функционирование редиректора основано на перехвате трафика между запра-

шивающим клиентом и исходным сервером. Аппаратный кэш может использовать

инфраструктуру сети для перехвата трафика. Такие устройства обычно размещают

па границе сети провайдера, они способны просматривать все пакеты, проходящие

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

настраивать браузер на взаимодействие с прокси-сервером. Во время перехвата

проверяется как Web-, так и локальный трафик, обусловливая тем самым задерж-

ки при передаче локального трафика.

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

вером. Как было отмечено в разделе 11.4, пользователь не ощущает присутствия

перехватывающего прокси-сервера. Пользователь, принимая ответ от перехваты-

Глава 11. Кэширование 409

вающего прокси-сервера, полагает, что он пришел от исходного сервера. Предполо-

жим, что кэш перехватывающего прокси-сервера функционирует некорректно и от-

сылаемый им ответ будет либо устаревшим, либо не соответствовать протоколу

HTTP. У пользователя нет способа узнать причину и место возникновения пробле-

мы.

Перехватывающий прокси-сервер обусловливает проблемы в области безопас-

ности, так как пользователи не знают о возможной угрозе своей безопасности со

стороны перехватывающего прокси-сервера.

Перехватывающие прокси-серверы используются достаточно широко. Перехват

или перенаправление могут быть осуществлены с помощью маршрутизатора или

коммутатора. Маршрутизатор может иметь специальную политику для проверки

одного или более портов (порт 80 для протокола HTTP) и перенаправления этого

трафика. Это можно рассматривать как коммутатор уровней L3/L4, т.е. на треть-

ем

—

сетевом и четвертом

—

транспортном уровнях. Коммутатор L4 может прове-

рить ТСР-пакет SYN и решить, необходимо ли перенаправлять запрос.

Реализованная Cisco политика маршрутизации позволяет перехватывать весь

сетевой трафик на 80-ом порту. Однако слепое перенаправление трафика на другой

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

не должны кэшироваться. Например, нельзя кэшировать динамически созданные

сообщения. Web-коммутатор — это сетевое устройство, имеющее программное

обеспечение для перехвата и перенаправления трафика на один или более про-

кси-сервер. Коммутатор обычно работает на транспортном уровне (L4) и только

перехватывает пакеты TCP/IP на 80-м порту. В результате трафик, не относящий-

ся к Web, не изменяется. Коммутатор L4 может быть также расположен па границе

сети. Коммутатор является более простым, более дешевым и имеющим меньше

функциональных возможностей устройством, чем маршрутизатор.

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

Интеллектуальные коммутаторы могут анализировать часть заголовков на приклад-

пом уровне. Анализ содержания требует затрат, т.к. перехватывающий прокси-сервер

должен работать с заголовками HTTP. Далее коммутатор может принимать эвристи-

ческие решения о необходимости кэширования Web-содержания. Если Web-содер-

жание не кэшируется, то коммутатор передает запрос непосредственно исходному

серверу без переадресации его кэшу. Кроме проверки типа содержания, коммутатор

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

фильтрацию возвращаемого содержания. Коммутатор, проверяющий содержание,

является примером коммутатора уровня 4+ (уровень 5 или 7).

Проверка заголовков па прикладном уровне (в данном случае заголовков

HTTP) может помочь в принятии решений о необходимости кэширования. Для

принятия соответствующего решения может быть проанализирован ряд HTTP-за-

головков (номер версии протокола, Cache-Control, Cookie и т.д.). Например, если

присутствует заголовок Cache-Control: no-cache, то нет смысла переадресовывать

запрос кэшу. Однако для слежения за заголовками прикладного уровня, коммута-

тор L5 неизбежно должен прекращать соединение на транспортном уровне (TCP).

Для выравнивания нагрузки можно выполнить распределение запросов по различ-

ным кэшам с помощью хэш-функций, основываясь на URL.

Проверка заголовков прикладного уровня до обработки запроса в общем случае

весьма проблематична. Откладывание операции до момента проверки заголовков

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

отсутствие заголовков, помогающих принять решение. Далее, как было сказано ра-

нее,

URL не является достаточно хорошим индикатором необходимости кэширова-

ния. Решение, основанное на том, что URL содержит 1юдстроку cgi, может оказать-