Протоколы кэширования web-трафика в локальных сетях

Протоколы кэширования web-трафика в локальных сетях

Рост объема услуг через Internet, приводит к росту соответствующего трафика информации. Это приводит, в свою очередь, к росту времени ответа на запросы к web-систем. Поэтому разрабатываются новые технологии доступа, которые обеспечивают уменьшение времени ответа. Одной из таких технологий является применение сетевого кэширования. Поэтому в этой статье приведены комплексное исследование четырех кэширующих веб-протоколов. Рассматриваются такие протоколы, как: Internet Cache Protocol (ICP), Cache Digest Protocol (CADP), Cache Array Resolution Protocol (CARP) и Web Cache Coordination Protocol (WCCP). Целью этой работы является анализ протоколов кэширования web-трафика и освещения преимуществ и недостатков каждого из них.

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

Протоколы веб-кэширования можно классифицировать на основе сообщений, на основе каталога, хеш-основе или маршрутизаторний основе. Примером протокола на основе сообщений является ICP. Протоколы на основе каталога содержат кэш-сборники. Примером является протокол CADP. К протоколам на хеш-основе можно отнести CARP. Примером протокола на маршрутизаторний основе является протокол координационного веб-кэширования WCCP.

ICP

Кэш, в котором отсутствует запрашиваемый объект, может проверить его наличие в другом кэше. Такой метод взаимодействия отличается от традиционного запроса ресурсов в исходного сервера. В этом случае кэше есть как источниками, так и получателями сообщений. Для этого необходим специальный протокол мижкешевои взаимодействия. Одним из первых протоколов для взаимодействия кэшей был ICP. Этот протокол является примером протокола запросов. Письмо, направленное клиентским кэшем, является запросом о наличии кэшированные копии определенного ответа, необходимой клиентском кэша. Популярность ICP основана на том, что он реализован в свободно распространяемого и широко используемому кэширующий прокси-сервере.

Протокол ICP оказался пригодным и для иерархических наборов кэшей, взаимодействующих на каждом уровне иерархии и имеют общего отца. При перемещении вверх по иерархии эта схема повторяется вплоть до центрального кэша, который может быть подключен к другому центрального кэша в другой локальной сети по такой же схеме. Центральный кэш может иметь как отца региональный кэш, а набор региональных кэшей может как отца иметь национальный кэш. Предположим, что некоторое кэш (назовем его выходным) не имеет запрашиваемого ресурса. Он посылает ICP-запрос (обычно это UDP-сообщения) ко всем своим соседям на этом уровне иерархии одновременно. Успешная ответ указывать на наличие необходимого ресурса в одном из кэшей этого уровня, и выходной кэш может запросить этот ресурс, используя протокол HTTP. Если в кэшах этого уровня иерархии отсутствует такой ресурс, то выходной кэш направит ICP-запрос родительскому кэшу. Возможен также вариант, когда ответы от кэшей этого уровня иерархии не поступят за определенный интервал времени. Это инициирует в исходном кэше событие, связанное с тайм-аутом. Родительский кэш повторяет указанную процедуру. Если от кэшей всех уровней не поступит ответа, то начальный кэш пригласит этот ресурс у соответствующего сервера. Предположение, что лежит в основе ICP-протокола заключается в том, что передача кэшами набора ICP-запросов столько раз, сколько уровней в иерархии, работают быстрее чем взаимодействие с соответствующим сервером. Кроме того, некоторая оптимизация помогает сократить общие расходы. Например, когда ответ возвращается от сервера или кэша в иерархии, то промежуточные кэши могут хранить ответ для будущего использования.

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

Структура ICP-запроса такова:

ICP-запрос состоит из двух разделов (табл. 1):

1. Заголовок (размер которого 20 октетов (пять 32-битных слов))

2. Данные (размер которых переменный, ограничен максимальным ICP-запроса в 16384 октетов, вместе с заголовком).

ICP заголовок состоит из семи полей, два из которых являются дополнительными (“Параметры” и “Вариант данных”) и необязательными.

Таблица 1

Структура  ICP-запроса

Bit смещения биты 0-7 биты 8-15 биты 16-31
0 код операции версия длина сообщения
32 номер запроса
96 вариант данных
128 отправитель адреса хоста
160+ данные

CADP

Протокол Cache Digest Protocol (CADP) является расширением протокола ICP.Основная его цель заключается в обмене дайджестами кэширования ресурсов.Дайджест – это краткое описание кэшированных ресурсов и определяет наличие набора ресурсов в кэше. Когда кэш имеет дайджесты всех других кэшей на этом уровне иерархии, то можно быстро проверить наличие искомого объекта. Если поиск в дайджесте оказывается успешным, то кэш становится кандидатом на получение запроса на искомый объект. Запрашиваемый кэш может даже выбрать из нескольких кэшей, для которых поиск оказался успешным. Если проверка по дайджестом возникает ошибка, взаимодействия с кэшем не происходит. В результате сокращается количество сообщений, рассылаемых кэшами одного иерархического уровня.

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

Для обмена дайджестом между кэшами может использоваться схема, принятая в ICP и основана на протоколе UDP. Однако для надежности обмен дайджестами осуществляется посредством HTTP-сообщений поверх TCP. Дайджесты могут рассматриваться как обычные ресурсы, к которым для проверки актуальности применима технология обновления ресурсов HTTP (посредством заголовков Expire и If-Modified-Since).

CARP

Протокол Cache Array Resolution Protocol (CARP) определяет механизм, посредством которого группа кэширующих прокси-серверов может функционировать как единый логический кэш. Набор ответов, который коллективно кэшируется группой прокси-серверов, трактуется как один большой кэш. Специальные хеш-функции используются для кодирования URL ресурсов, хранящихся в разных кэшах. Клиент, который пытается найти кэшированных ресурс, может запросить соответствующего кэша, кодированный с помощью этой функции. Хэш-функция превращает запрошенный URL и код нужного прокси-сервера, создавая специальный путь выполнения запроса. По сравнению с ICP протокол CARP имеет строго определенный путь решения запроса, благодаря чему не требуется дополнительное отправки запросов. По сравнению с ICP в CARP используется гораздо меньше повторных запросов. CARP использует как HTTP, так и вызов удаленных процедур для взаимодействия прокси-серверов. CARP связывает прокси-сервер с коэффициентом нагрузки, что может быть принят во внимание тому, как запрос будет отправлен этом прокси-сервера. CARP реализован основными производителями программных продуктов.

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

WCCP

В отличие от высокоуровневых протоколов типа ICP и CARP, протокол Web Cache Coordination Protocol (WCCP) является координационным механизмом, который связан с сетевым уровнем. Назначению WCCP является перехват HTTP-запросов и переадресации их кэша. Поскольку запрос может оказаться отброшенным (если кэш через некоторое причину будет недоступен), то необходим координационный механизм. Задача координатора заключается в выравнивании нагрузки между множеством кэшей. Периодически проверяя работоспособность кэша, эта технология гарантирует, что пакеты не будут посланы неработоспособном кэша.

Такой координационный механизм заложен в ядро ​​протокола WCCP, который реализован как часть технологии Cisco Cache Engine. Этот механизм настроен на получение Web-запросов, перенаправленных ему маршрутизатором. Маршрутизатор, поддерживающий протокол WCCP, способен проанализировать все IP-заголовки и ТСР-пакеты, поступающие на 80-й порт (стандартный порт HTTP), и перенаправить с их кэширующего сервера. Кроме того, WCCP-маршрутизатор периодически связывается с кэширующий сервер, чтобы убедиться в его доступности.

Сегодня есть две версии протокола:

Версия 1.

  • Только один роутер обслуживает группу устройств.
  • Поддерживает только HTTP перенаправление трафика.
  • Использует протокол GRE, чтобы предотвратить модификации пакетов.
  • Роутеры и устройства хранения кэша соединяются друг с другом по протоколу UDP.

Версия 2.

  • Позволяет использовать до 32 роутеров (серверов WCCP).
  • Поддерживает до 32 устройств / ускорителей (клиентов WCCP).
  • Поддерживает любые IP и TCP протоколы.
  • Поддерживает до 256 сервис-групп (групп обслуживания).
  • Добавлен шифрования с использованием хеша MD5.

К основным функциям WCCP относятся:

1. Регистрация.

2. Назначения.

3. Редирект от роутера к устройству хранения кэша.

4. Возврат от устройства хранения кэша до роутера.

Таблица 2

Сравнительная оценка кэш-протоколов

Название протокола ICP CADP CARP WCCP
Механизм работы протокола На основе сообщений На основе дайджестов На основе хеш-функций На основе координационного механизма
Дополнительные протоколы и технологии, использующей кэш-протокол UDP, HTTP UDP.

Технология обновления ресурсов HTTP (посредством заголовков Expire и If-Modified-Since),

URL ресурсы

HTTP.

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

HTTP.

Технологии Cisco Cache Engine, IP-заголовки и ТСР-пакеты

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

Рассмотрены распространенные протоколы кэширования web-трафика в локальных сетях. Описаны основные свойства, преимущества и недостатки. Анализ параметров приведенных протоколов позволяет утверждать, что каждый протокол надо использовать там, где он будет наиболее целесообразным, то есть не будет избыточности в использовании (это особенно связано с WCCP протоколом) и удовлетворять поставленные требования.

Добавить комментарий

Ваш адрес email не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.