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

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

Курсовая

Содержание 5.Что кэшировать? 5.1.Требования, определяемые протоколом 5.2.Соображения, определяемые Web-содержанием

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

• Калининградский Государственный Технический университет Экономический факультет Кафедра, 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.

^

5.Что кэшировать?

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

5.1.Требования, определяемые протоколом

Хорошо функционирующий кэш должен подчиняться требованиям HTTP. Про­ект стандарта НТТР/1.1 определяет простые правила того, какие ответы необходимо кэшировать; методы запросов, поля заголовков запросов, коды и заголовки ответов должны указывать на то, что ответ можно кэшировать. Несоответствие одному или нескольким из перечисленных требований не позволяет кэшировать ответ. Напри­мер, ответы на запросы с методами OPTIONS, PUT и DELETE не кэшируются. Ответы на запросы с методом POST не кэшируется, если не содержат заголовков Cache-Control и Expires. Если кэш не поддерживает за­головков Range, то ответ с кодом 206 Partial Content не может кэшироваться.

Некоторые ответы включают зависящую от ресурса информацию от исходного сервера, которая может препятствовать кэшированию сообщений. Такая информа­ция бывает двух видов: информация о возможности кэширования и директивы управления кэшированием. Если ответ включает информацию о возможности кэ­ширования, то решение о кэшировании должно определяться ею. Например, сервер может дать явное указание, когда следует обновить ресурс в кэше с помощью заго­ловка Expires. Если время, указанное в Expire, близко ко времени прибытия сооб­щения, то ресурс кэшировать нельзя. Директивы управления кэшированием могут предотвращать кэширование некоторых ответов. Например, директива Cache-Control: Private указывает, что прокси-сервер, совместно используемый несколь­кими клиентами, не может кэшировать данный ответ. Ответное сообщение, вклю­чающее директиву управления кэшированием

Cache-Control: no-store

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

Cache-Control: no-cache

уменьшает вероятность того, что кэш будет сохранять ответ, поскольку перед тем, как отправить клиенту кэшированную копию, будет осуществлена проверка ее ак­туальности. Директивы не обязательно должны быть директивами в ответе, пере­данном исходным сервером. Они могут быть директивами запроса, определенными запрашивающим клиентом. Например, Cache-Control: no-store может появляться как в запросе, так и в ответе. Протокол использует эти директивы для обеспечения конфиденциальности ответа, а также указывает, что данные ресурсы могут быть изменены после их отправки. Кэш должен внимательно отслеживать такие дирек­тивы и, если они приходят, обеспечивать семантически прозрачное кэширование.

Присутствие в запросе заголовка Authorization или заголовка Vary в ответе снижает шанс того, что ресурс будет кэширован. Заголовок запроса Authorization указывает на то, что запрашиваемый ресурс доступен не для всех. Это уменьшает вероятность, что ответ используется многими пользователями. Аналогично, при­сутствие заголовка Vary указывает на то, что сохраняемый кэшем ответ будет огра­ничен версией, указанной в заголовке Vary.

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

5.2.Соображения, определяемые Web-содержанием

У кэша может быть набор своих собственных правил, не связанных с требова­ниями протокола, для решения вопроса о необходимости кэширования ответа. Другими словами, возможность кэширования ответа не означает, что он будет обя­зательно кэширован. Сообщение может оказаться слишком большим, динамически генерируемым или включать в себя cookies, что может оказать влияние на кэширо­вание. Политика кэширования может руководствоваться другими соображениями, отличными от требований протокола, например, атрибутами сообщений. Напри­мер, частота, с которой кэш проверяет актуальность ресурсов на исходном сервере, может диктоваться политикой продолжительности кэширования ресурсов. С дру­гой стороны, если обладателю кэша платят за объем данных, доставляемых пользо­вателям, то он может принять решение игнорировать дату последней модификации и посылать полный ответ вместо передачи 304 Not Modified. Совместно используе­мый кэш может не кэшировать ответы на запросы, содержащие внедренную в них личную информацию (например, cookies). Страницы ASP и запросы на документы, требующие аутентификации, являются, вероятно, не лучшими кандидатами на кэ­ширование.

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

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

Многие кэши воздерживаются от сохранения ответов, сформированных сцена­риями, предполагая малую вероятность того, что те же значения параметров запро­сов будут повторно использованы. Решение о том, что ответ был сгенерирован как результат вызова сценария, основано на эвристике. Основное предположение, влияющее на решение о кэшировании ответа, заключается в том, что в дальнейшем будет генерироваться один и тот же ответ, а запрос на такой ответ может поступить в ближайшее время. По сравнению с запросами на статические ресурсы, которые меняются не слишком часто, каждое выполнение сценария с высокой вероятно­стью приводит к отличному от предыдущего ответа результату. Многие запросы часто приводят к одному и тому же ответу и некоторые кэши уже учитывают это. Данное соображение актуально для поисковых серверов, где очень большое число запросов выполняется для малого числа ключевых слов, например, "mpЗ", "sex" и т.д. Если поисковый сервер обновляет результаты таких запросов, например, не чаше, чем раз в день, то запрос будет приводить к одному и тому же ответу. В общем случае не всегда возможно сказать, был или не был воз­вращенный ответ сгенерирован динамически.

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