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

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

Курсовая

Содержание 8.Программное и аппаратное обеспечение кэширования 8.1.Программное обеспечение кэширования. Squid Traffic Inspector 8.2.Аппаратное обеспечение кэширования 8.3.Перехватывающие прокси-серверы и редиректоры 8.4.Комплексные аппаратные решения 10.Список источников информации 11.Приложение 1. Тест на тему кэширующие системы.

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

• Калининградский Государственный Технический университет Экономический факультет Кафедра, 305.66kb.
• Курсовая работа защищена с оценкой, 18.89kb.
• Конференция «Безопасность информационных систем предприятия», 59.58kb.
• Московская финансово-юридическая академия «Согласовано» «Утверждено на 2007 / 2008, 21.72kb.
• О защите конкуренции, 1152.72kb.
• Институт информационных технологий Кафедра информационных и коммуникационных технологий., 195.33kb.
• Институт информационных технологий Кафедра информационных и коммуникационных технологий, 207.89kb.
• Уголовный кодекс российской федерации, 3723.74kb.
• Титульный лист программы обучения по дисциплине Syllabus, 456.17kb.
• Принят Государственной Думой 8 декабря 1995 года     Глава I. Общие положения   статья, 545.05kb.

^

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

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

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

Squid является широко используемой кэширующей системой с открытым исход­ным кодом, которая работает на большом числе платформ, включая Unix, Solaris, Linux, FreeBSD, NetBSD, OS/2 и, с недавних пор, Windows NT.

Другими прокси-серверами с поддержкой кэширования являются:

1. ссылка скрыта - бесплатный локальный кэширующий прокси-сервер (Win) - кэширует HTTP-трафик, DNS, блокирует рекламу;
   
2. ссылка скрыта - учитывает входящий трафик, экономит бюджет на Интернет и обеспечивает информационную безопасность офиса;
   
3. ссылка скрыта - один из наиболее популярных прокси-серверов, позволяющий нескольким пользователям локальной сети получить доступ в Интернет;
   
4. ссылка скрыта.
   

Кроме HTTP, Squid способен работать и с другими протоколами (включая FTP, SSL, Gopher и WAIS). Он является настраиваемым кэшем: можно определить, по каким правилам должен обрабатываться кэшированный ответ (например, тип содержания, продол­жительность кэширования и т.д.). Для получения более полного представления о Squid можно ознакомиться с руководством пользователя Squid.

Как и для любого другого прокси-сервера, для Squid необходима настройка на стороне клиента. Браузеры должны быть настроены на использование прокси-сер­вера для любого протокола, поддерживаемого Squid. Например, номер порта для HTTP устанавливается равным 3128, по­скольку именно его Squid использует для взаимодействия с Web-клиентами по умолчанию.

Squid может общаться с другими кэшами на данном уровне иерархии по протоколу ICP. Взаимодействие с другими кэшами осуществляется по протоколу UDP через порт 3130 по умолчанию, хотя для взаимодействия может использоваться и HTTP.

Иерархические отношения между кэшами определяются с помощью конфигура­ционных файлов, иерархия может быть локальной, региональной, национальной и даже интернациональной. Условное кэширование может быть настроено через гра­ницы доменов. Например, один Squid может использоваться для кэширования ряда национальных доменов, таких как .ir и .ua. Для кэширования определенного сайта, прокси-серверы, расположенные вблизи от него, должны быть зарегистрированы в центральной базе данных.

Squid контактирует с набором кэшей на данном уровне иерархии, используя UDP и предполагая, что кэш, который первым сообщает о наличии ресурса, столь же быстро сможет выдать и ответ. Другими словами, Squid собирает информацию, касающуюся загрузки сети, основанную на времени ответа. Ответ, полученный от кэша на том же уровне иерархии не должен кэшироваться на запрашивающем кэше. Вместо этого запрашивающий кэш может просто позволить кэшу на том же уровне иерархии служить кэшем для этого объекта, если кэш находится в той же высокоскоростной сети с малым временен ожидания. Если кэшированной копии запрашиваемого ресурса нет ни на текущем уровне иерархии, ни в родительском кэше, то Squid направляет запрос исходному серверу. Ответ сервера может быть за­писан в кэш перед отправкой его клиенту.

Squid способен работать в кластере: множество кэшей в одном сетевом сегменте могут действовать как кэши одного уровня. Преимущество кластерного кэширова­ния заключается в высокой надежности и низкой цене, так как используются не­сколько дешевых компьютеров, а не мощный и дорогой сервер. DNS-сервер также участвует в схеме кластерного кэширования. Определение адреса кэширующего сервера выполняется таким образом, что браузер может обращаться к любому кэшу кластера.

Squid использует списки управления доступом (ACL - Access Control List) для определения клиентов, которые могут к нему обращаться как к прокси-серверу. Список IP-адресов используется для фильтрации входящих запросов. Различные адреса могут быть определены для различных протоколов. Например, группа кли­ентов может использовать Squid как кэш для HTTP-запросов, но не для FTP-запросов. Squid может быть настроен так, чтобы предотвратить доступ к некоторым Web-серверам; ACL в этом случае состоит из набора доменов. Например, рассмот­рим список управления доступом с меткой dumb, содержащий два домена notbridght.com и nitwit.com:

acl dumb dstdomain notbright.com nitwit.com http_access deny dumb

Это будет предотвращать запросы к любому из этих двух доменов от клиентов, на­ходящихся позади 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 используют различные модели, основанные на частотах обновления ресурсов. Вме­сто ожидания истечения срока годности ресурса актуальность объекта проверяется только при необходимости. Истечение срока годности ресурса проверяется во вре­мя запроса, если объект устаревает, то он обновляется с исходного сервера. При не­обходимости в результате обновления записывается новая версия ресурса. Squid поддерживает заголовки Cache-Control и Expires, которые могут присутствовать в заголовках запросов и ответов. Предпочтение отдается заголовку клиентского за­проса (например, Cache-Control: max-age), а не заголовку Expires ответа сервера. Можно настроить Squid так, что он будет изменять срок годности, указанный в за­головке Expires ответа.

Последние версии Squid также поддерживают дайджесты кэшей. Новая версия способна использовать особенности НТТР/1.1, включая долговременные соедине­ния и аутентификацию прокси-сервера. Squid поддерживает многопоточное испол­нение, если его поддерживает операционная система. В случае перехватывающих прокси-серверов пакеты, полученные на один порт, перенаправляются на другой, а Squid действует как получатель перенаправленных пакетов. Squid также поддержи­вает протокол WCCP.
^

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

Кэширование может быть выполнено также с помощью специального аппарат­ного обеспечения. При использовании кэширующих прокси-серверов имеет место несколько проблем:

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

Альтернативным способом решения проблем кэширования является размеще­ние специфической аппаратуры в сети. Такое решение связано с перехватом тра­фика на различных уровнях (сетевом, транспортном и прикладном). Перехвачен­ный трафик направляется к одному или более устройствам, выполняющим функ­ции кэширующего прокси-сервера. Аппаратное решение для кэширования может быть отнесено к одной из двух категорий: редиректору и комплексному решению. Редиректор может быть либо маршрутизатором, либо коммутатором, перехваты­вающим запросы. Комплексное решение кроме функций перенаправления осуще­ствляет и кэширование.
^

8.3.Перехватывающие прокси-серверы и редиректоры

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

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

Перехватывающие прокси-серверы используются достаточно широко. Перехват или перенаправление могут быть осуществлены с помощью маршрутизатора или коммутатора. Маршрутизатор может иметь специальную политику для проверки одного или более портов (порт 80 для протокола HTTP) и перенаправления этого трафика. Это можно рассматривать как коммутатор уровней L3/L4, т.е. на треть­ем - сетевом и четвертом - транспортном уровнях. Коммутатор L4 может прове­рить TCP-пакет 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 содержит подстроку CGI, может оказать­ся необоснованным. Независимо от того, полезным или нет оказался анализ заго­ловков и URL, соединение на транспортном уровне уже разорвано и необходимо устанавливать новое соединение с сервером, находящимся на пути к клиенту.

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

Поскольку перехватывающий прокси-сервер располагается на пути всего трафи­ка между клиентом и сетью, то при выходе из строя прокси-сервера клиент будет от­ключен от Internet. Способом предотвращения таких отказов является отслеживание работы перехватывающего прокси-сервера и отключение механизма перехвата в слу­чае его отказа, что позволяет передать клиентский запрос непосредственно исходно­му серверу. Более устойчивый механизм повторяют запрос исходному серверу, если кэш не обнаруживает соответствующих пакетов TCP SYN/ACK для SYN.
^

8.4.Комплексные аппаратные решения

Некоторые провайдеры предпочитают приобретать устройства, позволяющие решить все проблемы кэширования. Преимущество таких устройств заключается в сокращении затрат на администрирование по сравнению с редиректорами. Ис­пользуемая в соответствующей операционной системе модель кэширования объе­диняется со специфической аппаратной платформой. Обычно такое оборудование монтируется в стойку.

Имеются две категории таких комплексных решений: устройства первой катего­рии требуют отдельного редиректора, в устройствах второй категории имеется внутренний редиректор. Современные тины устройств не требуют отдельных ком­мутаторов L4/L5. Гибридная версия устройств включает модули, которые осущест­вляют коммутацию на четвертом уровне. При обнаружении отказа кэша устройст­во может посылать запрос непосредственно исходному серверу.

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

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

9.Заключение

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

10.Список источников информации

1. ссылка скрыта
   
2. ссылка скрыта
   
3. ссылка скрыта
   
4. ссылка скрыта
   
5. ссылка скрыта
   
6. ссылка скрыта
   
7. ссылка скрыта
   
8. Б. Кришнамурти, Дж. Рексфорд, Web-протоколы. Теория и практика. — М.: ЗАО «Издательство БИНОМ», 2002 г. - 592 с : ил.
   
9. ссылка скрыта
   
10. ссылка скрыта
    

^

11.Приложение 1. Тест на тему кэширующие системы.

12.Приложение 2. Презентация