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

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

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

Хорошо фуикциоиирующий кэш должен подчипяться требованиям HTTP. Проект стандарта НТТР/1.1 определяет простые иравила того, какие ответы необходимо кэшировать; методы запросов, поля заголовков запросов, коды и заголовки ответов должпы указывать на то, что ответ Можно кэшировать. Несоответствие одному или нескольким из перечисленных требований не позволяет кэшировать ответ. Например, ответы на запросы с методами OPTIONS, PUT и DELETE (рассмотренные в главах 6 и 7) не кэшируюгся. Ответы на запросы с методом 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. Стандарт протокола не может дать оптимальное Решение для всех сторон, связанных с транзакцией. Однако разработчики протокола в основном уделяли внимание семантической прозрачности кэширования, предоставляя управление последней всем сторонам, вовлеченным транзакцию.

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

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

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

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

Многие кэши воздерживаются от сохранения ответов, сформированных сценариями, предполагая малую вероятность того, ч го те же значения параметров запросов будут повторно использованы. Решение о том, что ответ был сгенерирован как результат вызова сценария, основано на эвристике. Основное предположение, влияющее на решение о кэшировании ответа, заключается в том, что в дальнейшем будет генерироваться один и тог же ответ, а запрос на такой о гвет может поступить в ближайшее время. По сравнению с запросами на статические ресурсы, которые меияюгся не слишком часто, каждое выиолиепие сценария с высокой вероятностью приводит к отличному от предыдущего ответа результату. Однако присутствие в динамическом ответе такой информации о возможности кэширования, как заголовки Expires и Etag, может указать на целесообразность кэширования pecyp- ca. Например, рассмотрим CGI-сцеиарий, который возвращает п-ую цифру числа р. Ответ не будет изменяться до тех пор, пока передаваемый сценарию параметр равен n. Многие запросы часто приводят к одному и тому же ответу и некоторые кэши уже учитывают это. Данное соображение актуально для поисковых серверов, где очепь большое число запросов выполняется для малого числа ключевых слов, например, "mp3", "sex" и т.д. Если поисковый сервер обновляет результаты таких запросов, например, не чаше, чем раз в день, то запрос будет приводить к одному и тому же ответу. В общем случае не всегда возможно сказать, был или не был возвращенный ответ сгенерирован динамически.

Миф о том, что ответы на CGI-запросы и другие динамически генерируемые страницы не должиы кэшироваться, должен развеяться. Другой категорией ответов, которые могут выглядеть как пекэшируемые, являются ответы, включающие данные, подготовленные для определенного пользователя. Например, ответ, содержащий cookie, рассматривается прокси-сервером как пекэшируемый, т.к. ожидается, что оп будет разным для разных пользователей. Но некоторые сообщения с cookies могут все же кэшироваться, если Они возвращают один и тот же ответ для различных значений cookies [WM99]. Заметим, что некоторые типы содержания, которые обычно рассматриваются как кэшируемые (например, изображения в форматах GIF или JPEG), могут на самом деле включать нестандартную информацию, или вообще информация о необходимости их обновления может отсутствовать, что затрудняет принятие решения о кэшировании.

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

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100