Кэширование
В этой статье описаны принципы и основные механизмы кэширования, применяемые на Платформе NGENIX.
Распределенное кэширование данных является одной из основных технологий Платформы и во многом определяет ее эффективность. Чем больше данных размещено в кэше серверов доставки, тем быстрее они загружаются на устройства пользователей и тем меньше нагрузка на сервер оригинации.
Данные попадают в кэш при первом запросе пользователя к объекту следующим образом:
Пользователь обращается к данным.
Сервер доставки проверяет наличие объекта в кэше и его актуальность.
Если объект находится в кэше и актуален, то он отдается пользователю.
Если объекта нет в кэше или он не актуален, он загружается с сервера оригинации в кэш сервера доставки и отдается пользователю.
Серверы доставки NGENIX имеют независимый кэш. Это значит, что объект может находиться в кэше на одних серверах доставки и отсутствовать на других.
Вы можете управлять кэшированием, выставляя необходимые HTTP-заголовки на вашем сервере оригинации.
Управление кэшированием через HTTP-заголовки
Управление кэшированием через HTTP-заголовки возможно для сервисных конфигураций с архитектурой Проксирование/кэширование содержимого веб-ресурса. В остальных случаях правила кэширования задаются на стороне Платформы.
В соответствии со стандартом кэширования 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-ageHTTP-заголовка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, поведение зависит от параметра "Разрешать работу с Cookie":При включенном параметре такие объекты не будут сохранены в кэш;
При отключенном параметре объекты будут сохранятся в кэш, при этом заголовок
Set-Cookieбудет удален.
Перечисленные выше правила кэширования применяются по умолчанию. Некоторые из них можно изменить в настройках кэширования в личном кабинете клиентского портала NGENIX Multidesk.
Для удаления кэшированных файлов с серверов доставки воспользуйтесь механизмом на странице "Очистка кэша".
Как повысить эффективность кэширования?
Определите, какие данные можно сохранить в кэше. Чаще всего это файлы, которые одинаковы для всех пользователей, например изображения, CSS и JS. Задайте для этих данных время кэширования через директиву
max-ageHTTP-заголовкаCache-Control. Убедитесь, чтоCache-Controlне содержит директивno-cache,no-storeилиprivate.Используйте одинаковые URL для одного объекта. В противном случае данные каждый раз будут загружаться заново. Помните, что регистр букв в URL имеет значение.
Как дополнительно снять нагрузку с сервера оригинации?
Для снижения нагрузки на сервер оригинации необходимо подключить дополнительный слой кэширования - сервера промежуточного кэширования, располагающиеся между сервером оригинации и серверами доставки. Для этого необходимо подключить сервис Origin Shield.
Добавление дополнительного слоя кэширования увеличивает задержку для данных, запрашиваемых первый раз и еще не находящихся в кэш памяти, и уменьшает ее для ранее закэшированных данных.
Last updated