Add new comment

Кеширование на уровне клиента или прокси сервера

Основные причины использования кеша

  1. Уменьшение времени ожидания — данные берутся от клиента,следовательно это самый короткий путь получения данных
  2. Снижение сетевого трафика — повторное использование контента снижает объем данных,в комментариях не нуждается.

Виды веб-кэшей

Кэш браузера (Browser cache)

Данный кеш проверяет кеш один раз за сессию в текущем сеансе браузера.
Данные хранятся на жестком диске. Настройки кеша задаются в браузере

Он просто проверяет являются ли данные “свежими”, обычно один раз за сессию (то есть, один раз в текущем сеансе браузера).
Пример страница которую вы только что просмотрели,либо страница открытая при клике на кнопку назад.

Прокси-кэш (Proxy cache)

Прокси-кэш работает также но в больших маштабах.

Прокси сервер это третий агент между сервером и клиентом, для кеширования нужно использовать переадресацию на его.

Способы настройки прокси кеша

Первый способ - настроить браузер для указания куда переадресовывать запросы.
Второй способ — использование перехвата (interception proxy). Прокси обрабатывает запросы направленные из сети.
Прокси-кэши работает как кэш-память (shared cache)

Кэш-шлюз (Gateway Cache)

Также известные как “реверсивные прокси-кэши” (reverse proxy cache) или “суррогаты” (surrogate cache).

Запросы могут быть перенаправлены на шлюзы несколькими методами,обычно используют балансировщик нагрузки.
content delivery networks, CDN - Сеть доставки контента использует шлюзы для доставки кешированного контента сайтам

Правила работы веб кеша.

  1. Если заголовки ответа сообщают кэшу не сохранять их, он не сохранит.
  2. Если запрос авторизованный (authorized) или безопасный (то есть, HTTPS), он не будет закэширован.
  3. Кэшированный контент считается “свежим”, если: у его установлено время истечения и оно не истекло, либо есть подобный заголовок
    Если кэш проверял контент но тот был модифицирован давно.
  4. Свежий контент берется из кэша, без проверки с сервера.
  5. Если контент устарел, серверу будет предложено провалидировать его или сообщить кэшу, является ли копия актуальной.
  6. В некоторых случаях — например, когда клиент отключен от сети — кэш может сохранять устаревшие ответы без проверки с исходного сервера.

Если в ответе нет валидатора
(ETag или Last-Modified заголовок),
и нет информации о свежести, контент, обычно (но не всегда) считается некэшируемым.

Существует два критерия проверки контента

Свежесть -- Контент будет доступен мгновенно из кэша
Валидность - Содержимое избежит повторной отправки всех пакетов при отсутствии изменений


Как управлять кешем?

Мета теги - Не рекомендуется,неэффективно - большинство браузеров не обрабатывает.
HTTP-заголовки - отправляются сервером прежде HTML и рассматриваются браузером и любым промежуточным кэшем.


Типичный заголовок

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


HTTP-заголовки Pragma (и почему они не работают)

Четких указаний на работу этого заголовка в спецификациях нет - некоторые браузеры его игнорируют ,используйте другие методы.

HTTP-заголовок Expires

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

Заголовки ответов Expires определяются двумя методами
1. Метод определения даты последнего запроса контента (last access time)
2. Метод определения даты последнего изменения документа на сервере (last modification time)

Заголовки Expires хороши для кэширования статических изображений и элементов которые не изменяются часто.

Также полезно для обновления элементов которые изменяются регулярно.
Только HTTP-дата является валидным значением HTTP-заголовка Expires.
Время в HTTP-дате трактуется по Гринвичу (GMT), не в соответствии с местным часовым поясом.

Например:
Expires: Fri, 30 Oct 1998 14:19:41 GMT

Ограничения данного заголовка

1. Часы веб-сервера и кэша должны быть синхронизированы
2. Сложно отслеживать время которое задано в заголовке.
Если вы не обновите время в Expires, прежде чем оно придет, каждый запрос будет обращаться к серверу, увеличивая нагрузку и время ожидания.

Для проверки синхронизации времени используйте
Сетевой протокол для синхронизации внутренних часов компьютера (Network Time Protocol, NTP);

HTTP-заголовки Cache-Control

HTTP/1.1 ввел новый класс заголовков, заголовки ответа Cache-Control

Заголовки ответов Cache-Control включают:

max-age=[секунды] — описывает максимальный период времени, в течение которого контент остается свежим. Аналогично Expires, эта директива указывает время, относительное моменту запроса, а не абсолютную величину. [секунды] — количество секунд от момента запроса, в течение которых вы хотите, чтобы контент трактовался как свежий.
s-maxage=[секунды] — подобен max-age, отличаясь тем, что применяется только к общему кэша (т.е. прокси).
public — помечает авторизованные запросы, как кэшируемые; это нормально, если требуется HTTP-аутентификация, ответы автоматически становятся приватными.
private — позволяет кэшу, который действует для определенного пользователя (т.е. в браузере) хранить ответ; общему кэшу (т.е. прокси) — нет.
no-cache — принуждает кэш отправлять запрос на исходный сервер каждый раз для валидации, прежде чем выдать кэшированную копию. Это полезно, когда необходимо гарантировать, что аутентификация принята во внимание (в сочетании с public) или для поддержания жесткой свежести без потери преимуществ кэширования.
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.
If-Modified-Since(если изменен с момента) -Запрос используется для опроса сервера чтобы узнать изменялся ли контент

HTTP/1.1 ввел новый вид валидатора, названный ETag.
ETag — это уникальные идентификаторы, которые генерируются сервером и изменяются каждый раз, когда запрашивается контент.

  1. If-Modified-Since(если изменен с момента)
  2. If-None-Match - Если нет совпадения

Поскольку сервер управляет тем, как сгенерированы ETag, кэш может быть уверен в том, что, если ETag совпадают по результатам запроса If-None-Match, контент действительно совпадает.

Правила кеширования

  1. Используйте URL-адреса последовательно — это золотое правило кэширования. Если вы храните некоторый контент на разных страницах, для разных пользователей или на разных сайтах, он должен использовать один и тот же URL-адрес. Это самый простой и самый эффективный способ сделать ваш сайт дружественным кэшу. Например, если вы однажды используете “/index.html” в качестве эталона, используйте его таким образом всегда.
  2. Используйте общую библиотеку изображений и других элементов и обращайтесь к ним из разных мест.
  3. Храните в кэше изображения и страницы, которые редко изменяются, с помощью указания заголовка Cache-Control: max-age с большими значениями max-age.
  4. Дайте кэшу возможность распознавать страницы, которые обновляются регулярно, указав соответствующий max-age или время истечения (expiration time).
  5. Если ресурс (особенно скачиваемый файл) изменяется, измените его имя. Таким образом, вы можете установить время его истечения далеко в будущем и при этом гарантировать, что все еще храните актуальную версию; страница, которая хранит ссылку на него, — единственное, что потребует короткого времени истечения.
  6. Не изменяйте файлы без необходимости. Если вы так поступаете, всё будет иметь обманчиво недавнюю дату в Last-Modified.
  7. Используйте куки только когда необходимо — куки сложно кэшировать и они, в большинстве ситуаций, не нужны. Если вам необходимо их использовать, ограничьте сферу их применения динамическими страницами.
  8. Минимизируйте использование SSL — потому как шифрованные страницы не хранятся в общем кэше; пользуйтесь ими только при необходимости и бережно относитесь к взаимодействию через SSL с изображениями.
  9. Проверьте свои страницы с помощью REDbot — он поможет вам применить многие идеи из этого учебного пособия.

Если скрипт производит некий вывод, который является воспроизводимым тем же запросом позднее (неважно, через минуты или дни), он должен быть закэширован

Если контент на выходе скрипта изменяется в зависимости от того, что в URL-адресе, он кэшируется;
если вывод зависит от куков, информации об аутентификации или от какого-то другого внешнего фактора, вероятно кэширования не происходит.


Советы

  1. Не используйте POST, если это не является целесообразным. Ответы POST-методом не хранятся большинством кэшей; если вы отправляете информацию в строке запроса (через GET), кэш может хранить эту информацию на будущее.
  2. Не вставляйте информацию, специфичную для пользователя, в URL-адрес, если сгенерированный контент не является полностью уникальным для этого пользователя.
  3. Не рассчитывайте на все запросы пользователя, приходящие с одного хоста, потому что кэши часто работают вместе.
  4. Генерируйте Content-Length заголовки ответа. Это легко сделать и позволит ответу от вашего скрипта использоваться в постоянном соединении (persistent connection). Это позволяет клиентам запрашивать несколько экземпляров контента через одно TCP/IP соединение, вместе установки соединения на каждый запрос. Это делает ваш сайт, кажется, намного быстрее.
Категория: 
The code has been tested and works

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.