Управление кэшированием

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

Данные попадают в кэш при первом запросе пользователя к объекту следующим образом:

  1. Пользователь обращается к данным.

  2. Сервер доставки проверяет наличие объекта в кэше и его актуальность.

  3. Если объект находится в кэше и актуален, то он отдается пользователю.

  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 действуют следующие правила кэширования:

  • Для каждой сервисной конфигурации используется отдельная область кэширования.

  • Если к сохраненным в кэше данным в течении трех суток не было ни одного запроса, данные удаляются из кэша, несмотря на значение директивы 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.

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

Для удаления кэшированных файлов с сервером доставки воспользуйтесь сервисом Cache Purge.

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

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

  2. Используйте одинаковые URL для одного объекта. В противном случае данные каждый раз будут загружаться заново. Помните, что регистр букв в URL имеет значение.