Это информационный документ. Несмотря на технический характер, он пытается сделать концепции понятными и применимыми в реальных ситуациях. Из-за этого некоторые аспекты материала упрощаются или опущены для ясности. Если вы заинтересованы в более детальном изучении вопров кэширования, ознакомьтесь с рекомендациями и дополнительной информацией в конце.
Кэширование
- Что такое веб-кеш? Почему люди используют их?
- Виды веб-кэшей
- Кэширование браузера
- Ключи прокси
- Разве веб-кэши плохо для меня? Почему я должен им помогать?
- Как работает веб-кеш
- Как (и как не) управлять кэшами
- HTML-метатеги и HTTP-заголовки
- Pragma HTTP Headers (и почему они не работают)
- Управление свежестью с заголовком HTTP истекает
- HTTP-заголовки Cache-Control
- Валидаторы и валидация
- Советы по созданию кэширующего сайта
- Написание скриптов с кэшем
- Часто задаваемые вопросы
- Замечания по внедрению - веб-серверы
- Замечания по реализации - Скрипты на стороне сервера
- Ссылки и дополнительная информация
- Об этом документе
Веб-кэш находится между одним или несколькими веб-серверами (серверами происхождения ) и клиентом или многими клиентами. Он проверяет входящие запросы и сохраняет у себя копии ответов - HTML-страниц, изображений и файлов (известных под общим названием представлений ). Затем, если есть другой запрос для того же URL-адреса, он может использовать ответ, который у него есть, вместо того, чтобы снова запросить исходный сервер.
Существуют две основные причины использования веб-кэшей:
- Чтобы уменьшить задержку - поскольку запрос выполняется из кеша (который ближе к клиенту) вместо исходного сервера, для получения представления и отображения его требуется меньше времени. Это делает Web более отзывчивым.
- Чтобы уменьшить сетевой трафик - поскольку представления используются повторно, это уменьшает пропускную способность, используемую клиентом. Это экономит деньги, если клиент платит за трафик, и снижает требования к пропускной способности и более управляемым.
Если вы изучите диалог настроек любого современного веб-браузера (например, Internet Explorer, Safari или Mozilla), вероятно, вы заметите настройку «кеш». Она позволяет выделить раздел жесткого диска вашего компьютера для хранения представлений, которые вы просматривали ранее. Кэш браузера работает в соответствии с довольно простыми правилами. Он будет проверять, чтобы представления были свежими, обычно после сеанса (т.е. один раз в текущем вызове браузера).
Этот кеш особенно полезен, когда пользователи нажимают кнопку «назад» или нажимают ссылку, чтобы увидеть страницу, на которую они только что посмотрели. Кроме того, если вы используете одни и те же навигационные изображения на своем сайте, они будут храниться в кэше браузеров почти мгновенно.
Веб-прокси-кэши работают по одному и тому же принципу, но гораздо большему масштабу. Прокси-серверы обслуживают сотни или тысячи пользователей таким же образом; крупные корпорации и интернет-провайдеры часто устанавливают их на своих брандмауэрах или как автономные устройства (также известные как посредники).
Поскольку прокси-кэши не является частью клиента или исходного сервера, но вместо этого они смотрят в сеть, запросы должны быть переданы им каким-либо образом. Один из способов сделать это - использовать настройку прокси-сервера вашего браузера, чтобы вручную указать, какой прокси использовать; другой использует перехват. Прокси-серверы перехвата имеют веб-запросы, перенаправленные им самой базовой сетью, поэтому клиентам не нужно настраивать их или даже знать о них.
Кэш-память прокси - это тип общего кэша; вместо того, чтобы просто использовать одного человека, у них обычно есть большое количество пользователей, и из-за этого они очень хорошо подходят для снижения латентности и сетевого трафика. Это потому, что популярные представления повторно используются несколько раз.
Также известные как «обратные прокси-кэши» или «суррогатные кэши», шлюзы также являются посредниками, но вместо того, чтобы развертывать сетевые администраторы для экономии полосы пропускания, они обычно развертываются самими веб-мастерами, чтобы сделать их сайты более масштабируемыми, надежными и более эффективная работа.
Запросы могут быть перенаправлены в кешированные шлюзы несколькими способами, но обычно используется некоторая форма балансировки нагрузки, чтобы один или несколько из них выглядели как сервер происхождения для клиентов.
Сети доставки контента (CDN) распространяют кеширование через Интернет (или часть его) и продают кеширование заинтересованным веб-сайтам. Speedera и Akamai являются примерами CDN.
В этом учебном пособии основное внимание уделяется кэшированию браузера и прокси-сервера, хотя часть информации подходит для тех, кто интересуется кэшами шлюзов.
Веб-кеширование - одна из самых непонятных технологий в Интернете. В частности, веб-мастера боятся потерять контроль над своим сайтом, поскольку кэш-прокси может «скрыть» своих пользователей от них, что затрудняет просмотр того, кто используется этот сайт.
К сожалению для них, даже если веб-кеши не существует, в Интернете слишком много переменных, чтобы убедиться, что они смогут получить точную картину того, как пользователи видят свой сайт. Если это вас очень волнует, этот учебник научит вас, как получить статистику, которая вам нужна, не делая ваш сайт недружественным.
Еще одна проблема заключается в том, что кеши могут обслуживать контент, устаревший или устаревший . Тем не менее, этот учебник может показать вам, как настроить сервер для управления кэшированием содержимого.
CDN - интересная разработка, потому что, в отличие от многих прокси-кэшей, их кэширование шлюзов согласовывается с интересами кэшируемого веб-сайта, так что эти проблемы не видны. Однако, даже если вы используете CDN, вы все равно должны учитывать, что будут прокси-серверы и кеширование браузера.
С другой стороны, если вы хорошо планируете свой сайт, кеши могут быстрее загружать ваш веб-сайт и сохранять нагрузку на ваш сервер и ссылку на Интернет. Разница может быть драматичной; сайт, который трудно кэшировать, может занять несколько секунд, а тот, который использует кеширование, может казаться мгновенным в сравнении. Пользователи оценят сайт быстрой загрузки и будут чаще посещать.
Подумайте об этом таким образом; многие крупные интернет-компании тратят миллионы долларов на создание ферм серверов по всему миру для тиражирования их контента, чтобы сделать его максимально быстрым для доступа для своих пользователей. Кэши делают то же самое для вас, и они еще ближе к конечному пользователю. Лучше всего, вам не нужно платить за них.
Дело в том, что кэш прокси и браузера будет использоваться, нравится вам это или нет. Если вы не настроите свой сайт на кеширование правильно, он будет кэшироваться с использованием любых настроек по умолчанию, которые установит администратор кэша.
У всех кешей есть набор правил, которые они используют, чтобы определить, когда подавать представление из кеша, если оно доступно. Некоторые из этих правил устанавливаются в протоколах (HTTP 1.0 и 1.1), а некоторые устанавливаются администратором кеша (либо пользователем кеша браузера, либо администратором прокси).
Вообще говоря, это наиболее распространенные правила, которые соблюдаются (не беспокойтесь, если вы не понимаете детали, это будет объяснено ниже):
- Если заголовки ответа указывают кешу не сохранять его, это не будет.
- Если запрос аутентифицирован или защищен (т.е. HTTPS), он не будет кэшироваться совместно используемыми кэшами.
- Кэш-представление считается новым (то есть может быть отправлено клиенту без проверки с сервером происхождения), если:
- он имеет время истечения срока действия или другой набор заголовков, регулирующих возраст, и все еще находится в пределах нового периода или
- если кэш недавно видел представление, и он был изменен относительно давно.
Свежие представления подаются непосредственно из кеша, не проверяя исходный сервер.
- Если представление устарело, серверу происхождения будет предложено проверить его или указать кешу, сохраняется ли его копия.
- При определенных обстоятельствах - например, когда он отключен от сети - кэш может обслуживать устаревшие ответы, не проверяя исходный сервер.
Если в ответе нет валидатора (ETagили Last-Modifiedзаголовка), и он не имеет явной информации о свежести, он, как правило, - но не всегда - считается неприкасаемым.
Вместе свежесть и проверка являются наиболее важными способами работы кеша с контентом. Свежее представление будет доступно мгновенно из кеша, в то время как проверенное представление будет избегать отправки всего представления заново, если оно не изменилось.
Существует несколько инструментов, которые веб-дизайнеры и веб-мастера могут использовать для точной настройки того, как кэши будут обрабатывать свои сайты. Это может потребовать, чтобы ваши руки немного грязные с конфигурацией вашего сервера, но результаты того стоят. Подробнее о том, как использовать эти инструменты с вашим сервером, см. Ниже в разделах « Реализация».
Авторы HTML могут размещать теги в разделе <HEAD> документа, описывающего его атрибуты. Эти метатеги часто используются в убеждении, что они могут пометить документ как нечитаемый или истечь его в определенное время.
Мета-теги просты в использовании, но не очень эффективны. Это связано с тем, что их выполняют только несколько кэшей браузера, а не прокси-кеши (которые почти никогда не читают HTML в документе). Хотя может возникнуть соблазн поставить метатег Pragma: no-cache на веб-страницу, он не обязательно заставит его оставаться свежим.
Если ваш сайт размещен в ISP или хостинговой ферме, и они не дают вам возможности устанавливать произвольные заголовки HTTP (например, ExpiresиCache-Control), громко жалуются; это инструменты, необходимые для выполнения вашей работы.
С другой стороны, истинные заголовки HTTP дают вам большой контроль над тем, как браузеры и прокси-серверы обрабатывают ваши представления. Они не могут быть замечены в HTML и обычно автоматически генерируются веб-сервером. Тем не менее, вы можете контролировать их в определенной степени, в зависимости от используемого вами сервера. В следующих разделах вы увидите, какие заголовки HTTP интересны и как их применять на вашем сайте.
Заголовки HTTP отправляются сервером перед HTML и просматриваются только браузером и любыми промежуточными кэшами. Типичные заголовки ответов HTTP 1.1 могут выглядеть так:
| HTTP/1.1 200 OK |
| Date: Fri, 30 Oct 1998 13:19:41 GMT |
| Server: Apache/1.3.3 (Unix) |
| Cache-Control: max-age=3600, must-revalidate |
| Expires: Fri, 30 Oct 1998 14:19:41 GMT |
| Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT |
| ETag: "3e86-410-3596fbbc" |
| Content-Length: 1040 |
| Content-Type: text/html |
HTML будет следовать за этими заголовками, разделенными пустой строкой. Сведения о настройке заголовков HTTP см. В разделах « Реализация».
Многие считают, что назначение Pragma: no-cache заголовка HTTP для представления сделает его несовместимым. Это не обязательно правда; спецификация HTTP не устанавливает никаких рекомендаций для заголовков ответов Pragma; вместо этого обсуждаются заголовки запросов Pragma (заголовки, отправляемые браузером на сервер). Хотя несколько кешей могут почтить этот заголовок, большинство не будет, и это не будет иметь никакого эффекта. Вместо этого используйте заголовки внизу.
ExpiresЗаголовка HTTP является основным средством управления кэшем; он сообщает всем кешам, сколько времени связано с соответствующим представлением. После этого тайники всегда будут проверять сервер происхождения, чтобы увидеть, изменился ли документ. Expiresзаголовки поддерживаются практически каждым кешем.
Большинство веб-серверов позволяют устанавливать Expiresзаголовки ответов несколькими способами. Как правило, они позволят установить абсолютное время истечения, время, основанное на последнем времени, когда клиент получил представление (время последнего доступа ) или время, основанное на последнем изменении документа на сервере (время последней модификации).
Expiresзаголовки особенно хороши для создания кеширования статических изображений (например, навигационных панелей и кнопок). Поскольку они не сильно меняются, вы можете установить на них чрезвычайно длительный срок действия, что делает ваш сайт более восприимчивым к вашим пользователям. Они также полезны для управления кэшированием страницы, которая регулярно изменяется. Например, если вы обновляете страницу новостей один раз в день в 6 утра, вы можете установить время истечения срока действия, поэтому кэши будут знать, когда нужно получить новую копию, без необходимости «перезагрузки» пользователей.
Единственным валидным значением Expiresзаголовка является действительная дата HTTP; любое другое значение, скорее всего, будет интерпретироваться как «в прошлом», так что представление является непонятным. Кроме того, помните, что время в дате HTTP - это среднее время по Гринвичу (GMT), а не местное время.
Например:
| Expires: Fri, 30 Oct 1998 14:19:41 GMT |
Важно, чтобы часы вашего веб-сервера были точными, если вы используете Expiresзаголовок. Один из способов сделать это - использовать протокол сетевого времени (NTP); поговорите с местным системным администратором, чтобы узнать больше.
Хотя Expiresзаголовок полезен, он имеет некоторые ограничения. Во-первых, поскольку есть дата, часы на веб-сервере и кеше должны быть синхронизированы; если у них есть другое представление о времени, ожидаемые результаты не будут достигнуты, и кеши могут ошибочно считать устаревший контент свежее.
Другая проблема Expiresзаключается в том, что легко забыть о том, что срок истечения определенного контента истекает в определенное время. Если вы не обновляете Expires время до его передачи, каждый запрос возвращается на ваш веб-сервер, увеличивая нагрузку и задержку.
HTTP 1.1 представил новый класс заголовков, заголовков Cache-Controlответов, чтобы дать веб-издателям больше контроля над своим контентом и устранить ограничения Expires.
Полезные Cache-Controlзаголовки ответов включают:
max-age=[seconds] - указывает максимальный период времени, когда представление будет считаться свежим. Аналогично Expires, эта директива относится к времени запроса, а не к абсолютной. [seconds] - количество секунд с момента запроса, для которого представление должно быть свежим.s-maxage=[seconds] - аналогично max-age, за исключением того, что он применяется только к общим кэшам (например, прокси).public- маркирует аутентифицированные ответы как кэшируемые; Обычно, если требуется проверка подлинности HTTP, ответы автоматически закрыты.private- позволяет кэши, специфичные для одного пользователя (например, в браузере) для хранения ответа; общие кэши (например, в прокси) не могут.no-cache- заставляет тайники отправлять запрос исходному серверу для проверки перед выпуском кешированной копии каждый раз. Это полезно для обеспечения того, чтобы аутентификация соблюдалась (в сочетании с публикацией) или поддерживала жесткую свежесть, не жертвуя всеми преимуществами кеширования.no-store - инструктирует кеши не сохранять копию представления при любых условиях.must-revalidate- сообщает кешам, что они должны подчиняться любой информации о свежести, которую вы даете им о представлении. HTTP позволяет кешам обслуживать устаревшие представления в особых условиях; указав этот заголовок, вы сообщаете кешу, что хотите, чтобы он строго соответствовал вашим правилам.proxy-revalidate- аналогично must-revalidate, за исключением того, что он применяется только к кэшам прокси.
Например:
Cache-Control: max-age=3600, must-revalidate
Когда оба Cache-Controlи Expiresприсутствуют, Cache-Controlимеет приоритет. Если вы планируете использоватьCache-Controlзаголовки, вы должны взглянуть на отличную документацию в HTTP 1.1; см. Ссылки и дополнительную информацию.
В разделе «Как работает веб-кеш» мы сказали, что проверка используется серверами и кэшами для связи при изменении представления. Используя его, кеши избегают загружать все представление, когда у них уже есть локальная копия, но они не уверены, что они все еще свежи.
Валидаторы очень важны; если его нет, и нет информации о свежести ( Expiresили Cache-Control), кеши не будут хранить представление вообще.
Наиболее распространенным валидатором является время последнего изменения документа, передаваемого в Last-Modifiedзаголовке. Когда кэш имеет представление, которое содержит Last-Modifiedзаголовок, оно может использовать его, чтобы спросить у сервера, изменилось ли представление с момента последнего его просмотра, с If-Modified-Sinceзапросом.
HTTP 1.1 представил новый тип валидатора, называемый ETag . ETags - это уникальные идентификаторы, которые генерируются сервером и изменяются каждый раз, когда это делает представление. Поскольку сервер управляет генерированием ETag, кеши могут быть уверены, что если ETag будет соответствовать, когда они сделают If-None-Matchзапрос, представление действительно будет таким же.
Почти все кеши используют Last-Modified раз как валидаторы; Валидация ETag также распространена.
Большинство современных веб-серверов будут генерировать оба ETagи Last-Modified заголовки для использования в качестве валидаторов для статического контента (т. Е. Файлов) автоматически; вам не придется ничего делать. Однако они не знают достаточно о динамическом контенте (например, CGI, ASP или сайтах базы данных) для их создания; см. « Запись сценариев кэширования» .
Помимо использования информации о свежести и проверки, существует ряд других вещей, которые вы можете сделать, чтобы сделать ваш сайт более удобным для кеша.
- Используйте URL-адреса последовательно - это золотое правило кэширования. Если вы используете один и тот же контент на разных страницах, для разных пользователей или с разных сайтов, он должен использовать один и тот же URL-адрес. Это самый простой и эффективный способ сделать ваш сайт кэшем. Например, если вы используете «/index.html» в своем HTML как ссылку один раз, всегда используйте его таким образом.
- Используйте общую библиотеку изображений и других элементов и обращайтесь к ним из разных мест.
- Сделайте кеши хранят изображения и страницы, которые не меняются часто , используя
Cache-Control: max-ageзаголовок с большим значением.
- Чтобы кэши распознавали регулярно обновляемые страницы , указав соответствующий максимальный возраст или срок действия.
- Если ресурс (особенно загружаемый файл) изменяется, измените его имя. Таким образом, вы можете сделать это в будущем и, тем не менее, гарантировать правильную версию; страница, которая ссылается на нее, является единственной, для которой потребуется короткое время истечения срока действия.
- Не меняйте файлы без необходимости. Если да, то все будет иметь ложно молодую
Last-Modifiedдату. Например, при обновлении сайта не копируйте весь сайт; просто переместите файлы, которые вы изменили.
- Используйте файлы cookie только там, где это необходимо - файлы cookie трудно кэшировать и не нужны в большинстве ситуаций. Если вы должны использовать файл cookie, ограничьте его использование для динамических страниц.
- Проверьте свои страницы с помощью REDbot - это поможет вам применить многие концепции в этом учебнике.
По умолчанию большинство сценариев не возвращают валидатор ( заголовок Last-Modified или ETagответ) или информацию о свежести ( Expiresили Cache-Control). Хотя некоторые сценарии действительно являются динамическими (это означает, что они возвращают другой ответ для каждого запроса), многие (например, поисковые системы и базы данных, управляемые сайтами) могут извлечь выгоду из того, что они не совместимы с кешем.
Вообще говоря, если сценарий создает выходные данные, которые воспроизводятся с тем же запросом в более позднее время (будь то минуты или дни позже), он должен быть кэшируемым. Если содержимое скрипта изменяется только в зависимости от того, что находится в URL-адресе, оно кэшируется; если выход зависит от файла cookie, информации аутентификации или других внешних критериев, это, вероятно, не так.
- Лучший способ сделать кеш-дружественный сценарий (а также работать лучше) - это сбрасывать его содержимое на простой файл всякий раз, когда он изменяется. Затем веб-сервер может рассматривать его как любую другую веб-страницу, генерировать и использовать валидаторы, что облегчает вашу жизнь. Не забывайте записывать только файлы, которые были изменены, поэтому
Last-Modifiedвремя сохраняется.
- Другой способ сделать сценарий, кэшируемый ограниченным образом, - установить возрастной заголовок как можно дальше в будущем. Хотя это можно сделать, с
Expiresним, вероятно, проще всего это сделать Cache-Control: max-age, что сделает запрос свежим в течение некоторого времени после запроса.
- Если вы не можете этого сделать, вам нужно заставить скрипт генерировать валидатор, а затем отвечать на запросы
If-Modified-Sinceи / или If-None-Matchзапросы. Это можно сделать, проанализировав заголовки HTTP, а затем отвечая, 304 Not Modifiedкогда это необходимо. К сожалению, это не трезвая задача.
Некоторые другие советы;
- Не используйте POST, если это не подходит. Ответы на метод POST не сохраняются большинством кэшей; если вы отправляете информацию в пути или запросе (через GET), кеши могут хранить эту информацию в будущем.
- Не вставляйте информацию о пользователе в URL-адрес, если только созданный контент не является уникальным для этого пользователя.
- Не рассчитывайте на все запросы от пользователя, поступающего с одного и того же хоста , потому что кеши часто работают вместе.
- Генерировать
Content-Lengthзаголовки ответов. Это легко сделать, и это позволит использовать ваш сценарий впостоянном соединении . Это позволяет клиентам запрашивать несколько представлений на одном TCP / IP-соединении, а не настраивать соединение для каждого запроса. Это делает ваш сайт намного быстрее.
Каковы наиболее важные вещи для кеширования?
Хорошей стратегией является выявление наиболее популярных, крупнейших представлений (особенно изображений) и работа с ними в первую очередь.
Как я могу сделать мои страницы как можно быстрее с помощью кешей?
Наиболее кэшируемое представление - это такое, у которого установлено длительное время свежести. Валидация помогает сократить время, необходимое для просмотра представления, но кэш по-прежнему должен связаться с сервером происхождения, чтобы убедиться, что он свежий. Если кеш уже знает, что он свежий, он будет обслуживаться напрямую.
Я понимаю, что кэширование - это хорошо, но мне нужно следить за тем, сколько людей посещает мою страницу!
Если вы должны знать каждый раз, когда страница доступна, выберите ОДИН маленький предмет на странице (или самой странице) и сделайте ее необработанной, предоставив ей подходящие заголовки. Например, вы можете ссылаться на прозрачное прозрачное изображение 1x1 с каждой страницы. RefererЗаголовок будет содержать информацию о том, что страница называется его.
Имейте в виду, что даже это не даст действительно точной статистики о ваших пользователях и недружелюбно относится к Интернету и вашим пользователям; он генерирует ненужный трафик и заставляет людей ждать, пока этот загруженный элемент не будет загружен. Дополнительные сведения об этом см. В разделе «Интерпретация статистики доступа» в ссылках .
Как я могу увидеть HTTP-заголовки представления?
Многие веб-браузеры позволяют видеть Expiresи Last-Modifiedзаголовки в «странице информации» или аналогичном интерфейсе. Если доступно, это даст вам меню страницы и любые связанные с ней изображения (например, изображения) вместе с их деталями.
Чтобы просмотреть полные заголовки представления, вы можете вручную подключиться к веб-серверу с помощью клиента Telnet.
Для этого вам может потребоваться ввести порт (по умолчанию, 80) в отдельное поле, или вам может потребоваться подключение www.example.com:80или www.example.com 80 (обратите внимание на пробел). Обратитесь к документации клиента Telnet.
После того как вы открыли соединение с сайтом, введите запрос для представления. Например, если вы хотите видеть заголовки http://www.example.com/foo.html, подключаться к www.example.comпортам 80и их тип:
| GET /foo.html HTTP/1.1 [return] |
| Host: www.example.com [return][return] |
Нажимайте клавишу «Return» каждый раз, когда видите [return]; не забудьте дважды нажать его в конце. Это напечатает заголовки, а затем полное представление. Чтобы увидеть только заголовки, замените HEAD для GET.
Мои страницы защищены паролем; как к ним относятся прокси-кэши?
По умолчанию страницы, защищенные с помощью HTTP-аутентификации, считаются закрытыми; они не будут храниться в общих кэшах. Тем не менее, вы можете публиковать открытые страницы с открытым заголовком Cache-Control: public; HTTP-совместимые кеши будут затем кэшироваться.
Если вы хотите, чтобы такие страницы были кэшируемыми, но все же аутентифицированы для каждого пользователя, объедините их Cache-Control: publicи no-cacheзаголовки. Это указывает кэшу, что перед отправкой представления из кеша он должен отправить информацию аутентификации нового клиента на исходный сервер. Это будет выглядеть так:
Cache-Control: public, no-cache
Независимо от того, сделано это или нет, лучше всего минимизировать использование аутентификации; например, если ваши изображения не чувствительны, поместите их в отдельный каталог и настройте сервер, чтобы он не принудительно выполнял аутентификацию. Таким образом, эти изображения будут естественно кэшируемыми.
Должен ли я беспокоиться о безопасности, если люди обращаются к моему сайту через кеш?
https://страницы не кэшируются (или дешифрованы) кэшами прокси, поэтому вам не нужно беспокоиться об этом. Однако, поскольку кэши хранят http://ответы и URL-адреса, полученные через них, вы должны быть осведомлены о незащищенных сайтах; недобросовестный администратор мог бы собирать информацию об их пользователях, особенно в URL-адресе.
Фактически, любой администратор в сети между вашим сервером и вашими клиентами мог бы собирать этот тип информации. Одна из особых проблем заключается в том, когда скрипты CGI ставят имена пользователей и пароли в самом URL-адресе; это делает тривиальным для других, чтобы найти и использовать их логин.
Если вы знаете о проблемах, связанных с безопасностью Web в целом, у вас не должно быть никаких сюрпризов из кэшей прокси.
Я ищу интегрированное решение для публикации в Интернете. Какие из них относятся к кешу?
Различается. Вообще говоря, чем сложнее решение, тем сложнее кэшировать. Хуже всего те, которые динамически генерируют весь контент и не предоставляют валидаторы; они не могут быть кэшируемыми вообще. Обратитесь к техническому персоналу вашего поставщика за дополнительной информацией и см. Примечания к внедрению ниже.
Мои изображения истекают через месяц, но теперь мне нужно изменить их в кешках!
Заголовок Expires нельзя обойти; если кеш (браузер или прокси) не исчерпывается и должен удалять представления, кешированная копия будет использоваться до тех пор.
Наиболее эффективным решением является изменение любых ссылок на них; Таким образом, совершенно новые представления будут загружены с исходного сервера. Помните, что любая страница, которая ссылается на эти представления, также будет кэшироваться. Из-за этого лучше всего сделать статические изображения и аналогичные представления очень кэшируемыми, сохраняя при этом страницы HTML, которые относятся к ним на жесткой привязи.
Если вы хотите перезагрузить представление из определенного кеша, вы можете либо принудительно перезагрузить (в Firefox, удерживая нажатой shift, нажав «reload», сделав это, выпустив Pragma: no-cacheзаголовок запроса), используя кеш. Кроме того, администратор кеша может удалить представление через свой интерфейс.
Я запустил веб-хостинг. Как я могу позволить своим пользователям публиковать страницы, облегчающие кеширование?
Если вы используете Apache, подумайте над тем, чтобы разрешить им использовать файлы .htaccess и предоставить соответствующую документацию.
В противном случае вы можете установить заранее определенные области для различных атрибутов кеширования на каждом виртуальном сервере. Например, вы можете указать каталог / cache-1m, который будет кэшироваться в течение одного месяца после доступа, и область / no-cache, которая будет обслуживаться с заголовками, инструктирующими кэшировать, чтобы они не хранили их.
Независимо от того, что вы можете сделать, лучше всего работать с вашими крупнейшими клиентами в первую очередь при кешировании. Большая часть сбережений (в полосе пропускания и в нагрузке на ваших серверах) будет реализована на сайтах большого объема.
Я пометил свои страницы как кешируемые, но мой браузер продолжает запрашивать их по каждому запросу. Как заставить кеш хранить их представления?
Кэши не обязаны хранить представление и повторно использовать его; они должны только не хранить или использовать их при некоторых условиях. Все кеши принимают решения о том, какие представления следует хранить в зависимости от их размера, типа (например, изображения против html) или от того, сколько места у них осталось для хранения локальных копий. Считается, что ваше мнение не стоит стоять вокруг, по сравнению с более популярными или более крупными изображениями.
Некоторые кеши позволяют своим администраторам устанавливать приоритеты в отношении того, какие представления сохраняются, а некоторые позволяют представлять «привязку» представлений в кеше, чтобы они всегда были доступны.
Вообще говоря, лучше всего использовать последнюю версию любого веб-сервера, который вы выбрали для развертывания. Мало того, что они, скорее всего, содержат больше возможностей для кэширования, новые версии также обычно имеют важные улучшения в области безопасности и производительности.
HTTP-сервер Apache
Apache использует дополнительные модули для включения заголовков, включая как Expires, так и Cache-Control. Оба модуля доступны в дистрибутиве 1,2 или более.
Модули должны быть встроены в Apache; хотя они включены в дистрибутив, они не включаются по умолчанию. Чтобы узнать, включены ли модули на вашем сервере, найдите двоичный файл httpd и запустите httpd -l; это должно печатать список доступных модулей (обратите внимание, что это только списки скомпилированных модулей, а в более поздних версиях Apache - httpd -M для включения динамически загружаемых модулей). Модули, которые мы ищем, - expires_module и headers_module.
- Если они недоступны, и у вас есть доступ к администратору, вы можете перекомпилировать Apache для их включения. Это можно сделать либо путем раскомментирования соответствующих строк в файле конфигурации, либо с помощью аргументов
-enable-module=expiresи -enable-module=headersаргументов для настройки (1,3 или более). Обратитесь к файлу INSTALL, найденному в дистрибутиве Apache.
Когда у вас есть Apache с соответствующими модулями, вы можете использовать mod_expires, чтобы указать, когда истечения срока действия истечения, либо в файлах .htaccess, либо в файле access.conf сервера. Вы можете указать срок действия либо времени доступа, либо изменения, и применить его к типу файла или по умолчанию. Дополнительную информацию см. В документации по модулю и поговорите с вашим местным гуру Apache, если у вас есть проблемы.
Чтобы применить Cache-Controlзаголовки, вам понадобится модуль mod_headers, который позволяет указать произвольные заголовки HTTP для ресурса. См. Документацию mod_headers .
Вот пример файла .htaccess, который демонстрирует использование некоторых заголовков.
- Файлы .htaccess позволяют веб-издателям использовать команды, обычно доступные только в файлах конфигурации. Они влияют на содержимое каталога, в котором они находятся, и их подкаталогов. Поговорите с администратором вашего сервера, чтобы узнать, включены ли они.
| ### activate mod_expires |
| ExpiresActive On |
| ### Expire .gif's 1 month from when they're accessed |
| ExpiresByType image/gif A2592000 |
| ### Expire everything else 1 day from when it's last modified |
| ### (this uses the Alternative syntax) |
| ExpiresDefault "modification plus 1 day" |
| ### Apply a Cache-Control header to index.html |
| <Files index.html> |
| Header append Cache-Control "public, must-revalidate"
</ Files> |
- Обратите внимание, что mod_expires автоматически вычисляет и вставляет
Cache-Control:max-ageзаголовок по мере необходимости.
Конфигурация Apache 2 очень похожа на конфигурацию версии 1.3; более подробную информацию см. в документации по модулю 2.2 mod_expires и mod_headers .
Microsoft IIS
Информационный сервер Microsoft Internet Server очень упрощает настройку заголовков несколько гибким способом. Обратите внимание, что это возможно только в версии 4 сервера, которая будет работать только на сервере NT.
Чтобы указать заголовки для области сайта, выберите его в Administration Toolsинтерфейсе и вызовите его свойства. После выбора HTTP Headersвкладки вы увидите две интересные области; Enable Content Expirationи Custom HTTP headers. Первый должен быть понятным, а второй - для использования заголовков Cache-Control.
См. Раздел ASP ниже для получения информации о настройке заголовков на страницах Active Server. Также возможно установить заголовки из модулей ISAPI; обратитесь к MSDN за подробной информацией.
Сервер Netscape / iPlanet Enterprise Server
Начиная с версии 3.6, Enterprise Server не предоставляет очевидного способа установки заголовков Expires. Тем не менее, он поддерживает функции HTTP 1.1 с версии 3.0. Это означает, что кеши HTTP 1.1 (прокси и браузер) смогут воспользоваться настройками Cache-Control, которые вы делаете.
Чтобы использовать заголовки Cache-Control, выберите Content Management | Cache Control Directivesсервер администрирования. Затем, используя средство выбора ресурсов, выберите каталог, в который вы хотите установить заголовки. После установки заголовков нажмите «ОК». Для получения дополнительной информации см. Руководствопо РЭШ .
Следует иметь в виду, что может быть проще настроить HTTP-заголовки на веб-сервере, а не на языке сценариев. Попробуйте оба.
Поскольку акцент на серверных сценариях на динамическом контенте, он не делает для очень кэшируемых страниц, даже когда содержимое может быть кэшировано. Если ваш контент изменяется часто, но не на каждом попадании страницы, рассмотрите настройку заголовка Cache-Control: max-age; большинство пользователей снова получают доступ к страницам за относительно короткий период времени. Например, когда пользователи нажимают кнопку «назад», если нет никакой информации о валидаторе или свежести, им придется подождать, пока страница не будет повторно загружена с сервера, чтобы увидеть ее.
CGI
Скрипты CGI - один из самых популярных способов создания контента. Вы можете легко добавлять заголовки HTTP-ответов, добавляя их перед отправкой тела; Большинство реализаций CGI уже требуют, чтобы вы делали это для Content-Typeзаголовка. Например, в Perl;
| #!/usr/bin/perl |
| print "Content-type: text/html\n"; |
| print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n"; |
| print "\n"; |
| ### the content body follows... |
Поскольку это весь текст, вы можете легко генерировать Expiresи другие связанные с датой заголовки со встроенными функциями. Это еще проще, если вы используете Cache-Control: max-age;
print "Cache-Control: max-age=600\n";
Это заставит скрипт кэшироваться в течение 10 минут после запроса, так что, если пользователь нажимает кнопку «назад», они не будут повторно отправлять запрос.
Спецификация CGI также делает заголовки запросов, которые клиент отправляет, доступными в среде сценария; каждый заголовок имеет «HTTP_», добавленный к его имени. Таким образом, если клиент делает If-Modified-Sinceзапрос, он будет отображаться как HTTP_IF_MODIFIED_SINCE.
Серверная сторона включает
SSI (часто используется с расширением .shtml) является одним из первых способов, которым веб-издателям удалось получить динамический контент на страницах. Используя специальные теги на страницах, была доступна ограниченная форма скриптов в HTML.
Большинство реализаций SSI не устанавливают валидаторы и, как таковые, не кэшируемы. Тем не менее, реализация Apache позволяет пользователям указывать, какие файлы SSI можно кэшировать, установив разрешения на выполнение группы в соответствующих файлах в сочетании с XbitHack fullдирективой. Для получения дополнительной информации см. Документацию mod_include .
PHP
PHP - это язык сценариев на стороне сервера, который, будучи встроенным в сервер, может использоваться для встраивания скриптов внутри HTML-страницы страницы, подобно SSI, но с гораздо большим количеством параметров. PHP можно использовать как скрипт CGI на любом веб-сервере (Unix или Windows) или в качестве модуля Apache.
По умолчанию представления, обработанные PHP, не назначаются валидаторами и поэтому недоступны. Однако разработчики могут устанавливать HTTP-заголовки с помощью Header()функции.
Например, это создаст заголовок Cache-Control, а также заголовок Expires через три дня в будущем:
| <?php |
| Header("Cache-Control: must-revalidate"); |
|
|
| $offset = 60 * 60 * 24 * 3; |
| $ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT"; |
| Header($ExpStr); |
| ?> |
Помните, что Header()функция ДОЛЖНА прийти перед любым другим выходом.
Как вы можете видеть, вам нужно будет создать дату HTTP для Expiresзаголовка вручную; PHP не предоставляет функции, чтобы сделать это для вас (хотя последние версии упростили, см . Документацию по дате PHP ). Конечно, легко установить a Cache-Control: max-age header, что так же хорошо для большинства ситуаций.
Холодный синтез
Cold Fusion от Macromedia - это коммерческий серверный скриптовый движок, поддерживающий несколько веб-серверов в Windows, Linux и несколько разновидностей Unix.
Cold Fusion упрощает настройку произвольных HTTP-заголовков с помощью CFHEADER тега. К сожалению, их пример настройки Expiresзаголовка, как показано ниже, немного вводит в заблуждение.
<CFHEADER NAME="Expires" VALUE="#Now()#">
Это не работает, как вы могли бы подумать, потому что время (в этом случае, когда запрос выполнен) не преобразуется в действительную дату HTTP; вместо этого он просто печатается как представление объекта Date / Time Cold Fusion. Большинство клиентов либо игнорируют такое значение, либо преобразуют его в значение по умолчанию, например, 1 января 1970 года.
Однако Cold Fusion предоставляет функцию форматирования даты, которая будет выполнять эту работу; GetHttpTimeString, В сочетании с ними легко установить даты истечения срока действия; здесь мы устанавливаем заголовок, чтобы объявить, что представления страницы истекают через один месяц; DateAdd
| <cfheader name="Expires" |
| value="#GetHttpTimeString(DateAdd('m', 1, Now()))#"> |
Вы также можете использовать CFHEADERтег для установки Cache-Control: max-ageи другие заголовки.
Помните, что заголовки веб-серверов проходят через некоторые развертывания Cold Fusion (например, CGI); проверьте, можете ли вы использовать это в своих интересах, установив заголовки на сервере, а не в Cold Fusion.
ASP и ASP.NET
При настройке заголовков HTTP из ASP убедитесь, что вы либо помещаете вызовы метода Response перед любым генерированием HTML, либо используете Response.Bufferдля буферизации вывода. Также обратите внимание, что некоторые версии IIS Cache-Control: privateпо умолчанию устанавливают заголовок на ASP и должны быть объявлены общедоступными для кэширования совместно используемыми кэшами.
Активные серверные страницы, встроенные в IIS, а также доступные для других веб-серверов, также позволяют устанавливать заголовки HTTP. Например, чтобы установить время истечения срока действия, вы можете использовать свойства Responseобъекта;
<% Response.Expires=1440 %>
указывая количество минут от запроса, чтобы истечь представление. Cache-Controlзаголовки могут быть добавлены следующим образом:
<% Response.CacheControl="public" %>
В ASP.NET Response.Expiresустарела; правильный способ установки заголовков, связанных с кешем, с Response.Cache;
| Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ; |
| Response.Cache.SetCacheability ( HttpCacheability.Public ) ; |
Спецификация HTTP 1.1 имеет множество расширений для обеспечения кэширования страниц и является авторитетным руководством по реализации протокола. См. Разделы 13, 14.9, 14.21 и 14.25.
Отличное введение в концепции кэширования, со ссылками на другие онлайн-ресурсы.
Информационный рассказ Джеффа Голдберга о том, почему вы не должны полагаться на статистику доступа и набирать счетчики.
Изучает ресурсы HTTP, чтобы определить, как они будут взаимодействовать с веб-кэшами, и обычно, насколько хорошо они используют протокол.
Все товарные знаки являются собственностью соответствующих владельцев.
Хотя автор считает, что содержание должно быть точным на момент публикации, для них не требуется никакой ответственности, их применения или каких-либо последствий. Если обнаружены какие-либо искажения, ошибки или другая потребность в разъяснении, немедленно обратитесь к автору.
