Кафедра Информационных Систем и Технологий. Сдана на проверку Допустить к защите 2007 г. 2008 г. Защищена с оценкой 2008 г курсовая

Вид материала

Содержание

7.3.Протоколы кэширования
7.3.1.Протокол Internet Cache Protocol (ICP)
7.3.2.Cache Array Resolution Protocol (CARP)
7.3.3.Cache Digest Protocol (CADP)
7.3.4.Web Cache Coordination Protocol (WCCP)

Подобный материал:

1 2 3 4 5 6 7 8 9 10 11

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

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

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

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

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

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

7.3.2.Cache Array Resolution Protocol (CARP)

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

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

7.3.3.Cache Digest Protocol (CADP)

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

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

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

7.3.4.Web Cache Coordination Protocol (WCCP)

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

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