Управление кэшированием
Распределенное кэширование данных является одной из основных технологий Платформы и во многом определяет ее эффективность. Чем больше данных размещено в кэше серверов доставки, тем быстрее они загружаются на устройства пользователей и тем меньше нагрузка на сервер оригинации.
Данные попадают в кэш при первом запросе пользователя к объекту следующим образом:
  1. 1.
    Пользователь обращается к данным.
  2. 2.
    Сервер доставки проверяет наличие объекта в кэше и его актуальность.
  3. 3.
    Если объект находится в кэше и актуален, то он отдается пользователю.
  4. 4.
    Если объекта нет в кэше или он не актуален, он загружается с сервера оригинации в кэш сервера доставки и отдается пользователю.
Серверы доставки NGENIX имеют независимый кэш. Это значит, что объект может находиться в кэше на одних серверах доставки и отсутствовать на других.
Вы можете управлять кэшированием, выставляя необходимые HTTP-заголовки на вашем сервере оригинации.

Управление кэшированием через HTTP-заголовки

Управление кэшированием через HTTP-заголовки возможно для сервисных конфигураций с базовым сервисом High-Performance Web или Website Acceleration. В остальных случаях правила кэширования задаются на стороне Платформы.
В соответствии со стандартом кэширования RFC 7234 для управления кэшированием используется HTTP-заголовок Cache-Conrol. Этот HTTP-заголовок определяет на какое время можно кэшировать данные. Заголовок Cache-Control указан в спецификации HTTP/1.1 и имеет приоритет над другими HTTP-заголовками, которые использовались раньше для задания правил кэширования (например, Expires). Заголовок Cache-Control поддерживают все современные браузеры.
Заголовок Cache-Control состоит из набора директив, определяющих правила кэширования данных. Самые распространенные директивы:
  • max-age. Указывает период актуальности кэша в секундах. Отсчет времени начинается с момента запроса. Например, max-age=86400 означает, что данные в кэше будут актуальны 24 часа.
  • public. Если в ответе содержится директива public, его можно кэшировать, даже если с запрашиваемыми данными связана HTTP-аутентификация и код статуса ответа отличается от 2xx. Например, можно кэшировать данные с кодом статуса ответа 404. Эта директива требуется редко, поскольку для данных с кодом статуса ответа 2хх достаточно директивы max-age .
  • private. Используется для приватных данных, которые можно сохранить в кэше браузера, но нельзя сохранять в промежуточных кэшах, таких как серверы доставки, прокси-серверы.
  • no-store. Запрещает браузеру и всем промежуточным кэшам сохранять данные. Эта директива используется, например, если данные содержат личную или банковскую информацию. Каждый раз, когда пользователь хочет получить эти данные, они загружаются заново с сервера оригинации.
  • no-cache. Означает, что при повторном запросе к тому же URL сохраненные в кэше данные используются только после проверки, изменились ли они на сервере оригинации. Если данные на сервере оригинации изменились, они будут полностью загружены заново. Если нет – будут отданы из кэша.

Правила кэширования по умолчанию

Помимо следования директивам HTTP-заголовка Cache-Control, на серверах доставки NGENIX действуют следующие правила кэширования:
  • Для каждой сервисной конфигурации используется отдельная область кэширования.
  • Кэшируются только ответы, которые были инициированы запросами с HTTP-методами GET или HEAD.
  • Если к сохраненным в кэше данным в течении трех суток не было ни одного запроса, данные удаляются из кэша, несмотря на значение директивы max-age HTTP-заголовка Cache-Control или HTTP-заголовка Expires.
  • Если HTTP-заголовки Cache-Control и Expires не заданы, а код статуса ответа 200, серверы доставки сохранят в кэше запрошенный файл на один час.
  • Содержимое HTTP-заголовка Vary не учитывается при кэшировании.
  • Кэширование URL происходит с учетом аргументов запроса. То есть, URL вида https://www.example.com/css/style.css?version=1 и https://www.example.com/css/style.css?version=2 будут разными объектами с точки зрения кэша.
  • Кэширование URL происходит без учета доменного имени. То есть, URL вида https://www.example.com/index.html и https://example.com/index.html будут одним и тем же объектом с точки зрения кэша.
  • Серверы доставки могут отдать пользователю неактуальные данные из кэша, если по каким-то причинам не могут получить новые данные с сервера оригинации (таймаут соединения и т.п.).
  • Если в ответе от вашего сервера оригинации есть HTTP-заголовок Set-Cookie, то данные:
    • не будут сохранены в кэш для сервисных конфигураций с базовым сервисом Website Acceleration;
    • будут сохранены в кэш для сервисных конфигураций с базовым сервисом High-Performance Web, при этом заголовок Set-Cookie будет удален.
Данные правила кэширования применяются по умолчанию и могут быть изменены службой сопровождения клиентских сервисов в целях оптимизации работы Платформы и веб-ресурсов.
Для удаления кэшированных файлов с сервером доставки воспользуйтесь сервисом Cache Purge.

Как повысить эффективность кэширования?

  1. 1.
    Определите, какие данные можно сохранить в кэше. Чаще всего это файлы, которые одинаковы для всех пользователей, например изображения, CSS и JS. Задайте для этих данных время кэширования через директиву max-age HTTP-заголовка Cache-Control. Убедитесь, что Cache-Control не содержит директив no-cache, no-storeили private.
  2. 2.
    Используйте одинаковые URL для одного объекта. В противном случае данные каждый раз будут загружаться заново. Помните, что регистр букв в URL имеет значение.
Last modified 6mo ago