Как выполняется кэширование
Внимание
Azure CDN standard от Корпорации Майкрософт (классическая версия) будет прекращена 30 сентября 2027 г. Чтобы избежать нарушений работы службы, важно перенести профили Azure CDN уровня "Стандартный" от Майкрософт (классический) на уровень Azure Front Door standard или Premium к 30 сентября 2027 года. Дополнительные сведения см. в статье Azure CDN Standard от майкрософт (классическая версия).
Azure CDN из Эдгио будет прекращено 4 ноября 2025 г. Перед этой датой необходимо перенести рабочую нагрузку в Azure Front Door. Дополнительные сведения см. в статье Azure CDN из Edgio для выхода на пенсию.
В этой статье представлен обзор общих концепций кэширования и способа использования кэширования azure сеть доставки содержимого для повышения производительности. Если вы хотите узнать, как настроить поведение кэширования в конечной точке сети доставки содержимого, см. статью "Управление поведением кэширования Azure сеть доставки содержимого с помощью правил кэширования и управления поведением кэширования Azure сеть доставки содержимого с помощью строк запроса".
Общие сведения о кэшировании
Кэширование — это процесс сохранения данных локально, который позволяет быстрее получить к ним доступ при будущих запросах. В самом распространенном типе кэширования, кэшировании веб-браузера, веб-браузер хранит копии статических данных на локальном жестком диске. Используя кеширование, веб-браузер может избежать многократных циклов приема-передачи на сервер и вместо этого получать доступ к тем же данным локально, что экономит время и ресурсы. Кэширование хорошо подходит для локального управления небольшим объемом статических данных, таких как статические изображения, файлы CSS и JavaScript.
Аналогичным образом, кеширование используется CDN на пограничных серверах, близких к пользователю, чтобы избежать запросов, возвращающихся в исходное состояние и сокращающих задержки пользователей. В отличие от кэша веб-браузера, который используется только для одного пользователя, сеть доставки содержимого имеет общий кэш. В общем кэше сети доставки содержимого запрос файла пользователя может использоваться другим пользователем, что значительно уменьшает количество запросов к исходному серверу.
Динамические ресурсы, которые часто изменяются или являются уникальными для отдельного пользователя, нельзя кэшировать. Однако эти типы ресурсов могут воспользоваться преимуществами оптимизации динамического ускорения сайта (DSA) в сети доставки содержимого Azure для улучшения производительности.
Кэширование может происходить на нескольких уровнях между сервером-источником и пользователем:
- веб-сервер: использует общий кэш (для нескольких пользователей);
- сеть доставки содержимого: использует общий кэш (для нескольких пользователей);
- поставщик интернет-услуг (ISP): использует общий кэш (для нескольких пользователей);
- веб-браузер: использует частный кэш (для одного пользователя).
Каждый кэш обычно самостоятельно управляет обновлением ресурса и выполняет проверку, если файл устарел. Такое поведение определено в спецификации кэширования HTTP RFC 7234.
Актуальность ресурса
Так как кэшированный ресурс может быть устаревшим или устаревшим (по сравнению с соответствующим ресурсом на исходном сервере), важно управлять тем, когда содержимое получает обновление. Для экономии времени и пропускной способности кэшированный ресурс не сравнивается с версией на сервере-источнике при каждом доступе. Вместо этого, пока кэшированный ресурс считается актуальным, предполагается, что это самая последняя версия и отправляется непосредственно клиенту. Кэшированный ресурс считается актуальным, когда его возраст меньше возраста или периода, определенного параметром кэша. Например, когда браузер перезагружает веб-страницу, он проверяет актуальность каждого кэшированного ресурса на вашем жестком диске и загружает его. Если ресурс не является свежим (устаревшим), с сервера загружается актуальная копия.
Проверка
Если ресурс считается устаревшим, сервер-источник получает запрос на проверку, чтобы определить, совпадают ли данные в кэше с тем, что находится на исходном сервере. Если файл был изменен на сервере-источнике, кэш обновляет его версию ресурса. В противном случае, если ресурс актуальный, данные доставляются непосредственно из кэша, без изначальной проверки.
Кэширование сети доставки содержимого
Кэширование является неотъемлемой частью способа работы сети доставки содержимого для ускорения доставки и уменьшения нагрузки источника для статических ресурсов, таких как изображения, шрифты и видео. При кэшировании сети доставки содержимого статические ресурсы выборочно хранятся на стратегически размещенных серверах, которые являются более локальными для пользователя и предлагают следующие преимущества:
Так как большинство веб-трафика является статическим (например, изображениями, шрифтами и видео), кэширование сети доставки содержимого уменьшает задержку в сети путем перемещения содержимого ближе к пользователю, что снижает расстояние, которое передает данные.
Выгрузив работу в сеть доставки содержимого, кэширование может снизить сетевой трафик и нагрузку на сервер-источник. Это уменьшает затраты и требования к ресурсам приложения даже при наличии большого числа пользователей.
Аналогично тому, как кэширование реализовано в веб-браузере, вы можете управлять тем, как кэширование выполняется в сети доставки содержимого, отправляя заголовки директив кэша. Заголовки директив кэша — это заголовки HTTP, которые обычно добавляются на сервер-источник. Хотя большинство этих заголовков изначально были разработаны для устранения кэширования в клиентских браузерах, они теперь также используются всеми промежуточными кэшами, такими как сети доставки содержимого.
Для определения актуальности кэша можно использовать два заголовка: Cache-Control
и Expires
. Cache-Control
— более поздний и имеет приоритет над Expires
, если они оба существуют. Для проверки также используются два вида заголовков (которые называются проверяющими элементами управления): ETag
и Last-Modified
. ETag
— более поздний и имеет приоритет над Last-Modified
, если они оба определены.
Заголовки директив кэша
Внимание
По умолчанию конечная точка Azure сеть доставки содержимого, оптимизированная для DSA, игнорирует заголовки директив кэша и пропускает кэширование. Для Azure CDN уровня "Стандартный" из профилей Edgio можно настроить способ обработки этих заголовков в конечной точке Azure сеть доставки содержимого с помощью правил кэширования сети доставки содержимого для включения кэширования. Только для Azure CDN Premium из профилей Edgio используйте обработчик правил для включения кэширования.
Azure сеть доставки содержимого поддерживает следующие заголовки директивы кэша HTTP, определяющие длительность кэша и общий доступ к кэшу.
Cache-Control:
- Представлен в HTTP 1.1, чтобы дать веб-издателям больше возможностей управления своим содержимым и устранить ограничения заголовка
Expires
. - Переопределяет заголовок
Expires
, если определен этот заголовок и заголовокCache-Control
. - При использовании в HTTP-запросе от клиента к сети доставки содержимого POP по
Cache-Control
умолчанию игнорируется всеми профилями Azure сеть доставки содержимого. - При использовании в ответе HTTP с исходного сервера на сеть доставки содержимого POP:
- Azure CDN уровня "Стандартный" или "Премиум" из Эдгио и Azure CDN уровня "Стандартный" от Майкрософт поддерживают все
Cache-Control
директивы. - Azure CDN уровня "Стандартный" или "Премиум" из Edgio и Azure CDN уровня "Стандартный" от Майкрософт учитывает поведение кэширования для директив управления кэшем в RFC 7234 — протокол гипертекстовой передачи (HTTP/1.1): кэширование (ietf.org).
- Azure CDN уровня "Стандартный" или "Премиум" из Эдгио и Azure CDN уровня "Стандартный" от Майкрософт поддерживают все
Expires:
- Устаревший заголовок, представленный в HTTP 1.0; поддерживается для обратной совместимости.
- Использует дату окончания срока действия со вторым уровнем точности.
- Аналогично
Cache-Control: max-age
. - Используется, если
Cache-Control
нет.
Pragma:
- По умолчанию не учитывается Azure сеть доставки содержимого.
- Устаревший заголовок, представленный в HTTP 1.0; поддерживается для обратной совместимости.
- Используется в качестве заголовка запроса клиента со следующей директивой:
no-cache
. Эта директива предписывает серверу предоставить новую версию ресурса. Pragma: no-cache
эквивалентнаCache-Control: no-cache
.
Проверяющие элементы управления
При необходимости обновления кэша проверяющие элементы управления кэша HTTP используются для сравнения кэшированной версии файла с версией на сервере-источнике. Azure CDN уровня "Стандартный" или "Премиум" из Edgio поддерживает и Last-Modified
ETag
проверяющие элементы по умолчанию, а Azure CDN standard от Майкрософт поддерживает только Last-Modified
.
ETag:
- Azure CDN уровня "Стандартный" или "Премиум" из Edgio поддерживается
ETag
по умолчанию, в то время как Azure CDN уровня "Стандартный" от Майкрософт не поддерживается. ETag
определяет уникальную строку для каждого файла и версии файла. Например,ETag: "17f0ddd99ed5bbe4edffdd6496d7131f"
.- Впервые появился в HTTP 1.1 и является более поздним, чем
Last-Modified
. Полезен, когда трудно определить дату последнего изменения. - Поддерживает как сильную проверку, так и слабую проверку; Однако azure сеть доставки содержимого поддерживает только надежную проверку. При строгой проверке два представления ресурсов должны полностью совпадать.
- Кэш проверяет файл, который использует
ETag
, отправляя заголовокIf-None-Match
с одним или несколькими проверяющими элементами управленияETag
в запросе. Например,If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f"
. Если версия сервера соответствует проверятелюETag
в списке, он отправляет код состояния 304 (не изменено) в ответе. Если версия отличается, сервер отвечает кодом состояния 200 (OK) и обновленным ресурсом.
Last-Modified:
- Только для Azure CDN уровня "Стандартный" или "Премиум" из Edgio используется только в том случае,
Last-Modified
еслиETag
ответ HTTP не является частью. - Указывает дату и время, которую сервер-источник определил как время последнего изменения ресурса. Например,
Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT
. - Для содержимого размером более 8 МБ серверные серверы источника должны поддерживать согласованные
Last-Modified
метки времени для каждого ресурса. Возврат несогласованногоLast-Modified
времени с внутренних серверов приведет к ошибкам несоответствия проверяющего элемента и приведет к сбоям HTTP 5XXX. служба хранилища Azure может не поддерживать согласованныеLast-Modified
метки времени между репликами, что может привести к аналогичным ошибкам несоответствия проверяющего элемента. - Кэш проверяет файл с помощью
Last-Modified
путем отправки заголовкаIf-Modified-Since
с датой и временем в запросе. Исходный сервер сравнивает эту дату с заголовкомLast-Modified
последнего ресурса. Если ресурс не был изменен с указанного времени, сервер возвращает код состояния 304 (не изменено) в ответе. Если ресурс был изменен, сервер возвращает код состояния 200 (OK) и обновленный ресурс.
Определение файлов для кэширования
Не все ресурсы могут кэшироваться. В следующей таблице показано, какие ресурсы можно кэшировать, исходя из типа ответа HTTP. Ресурсы, доставленные с помощью HTTP-ответов, которые не соответствуют всем этим условиям, нельзя кэшировать. Только для Azure CDN Premium из Edgio можно использовать обработчик правил для настройки некоторых из этих условий.
Azure сеть доставки содержимого от Майкрософт | Azure сеть доставки содержимого из Эдгио | |
---|---|---|
Коды состояния HTTP | 200, 203, 206, 300, 301, 410, 416 | 200 |
Методы HTTP | GET, HEAD | GET |
Ограничения размера файла | 300 ГБ | 300 ГБ |
Чтобы в профиле Azure CDN уровня "Стандартный" от Майкрософт кэширование работало для ресурса, сервер-источник должен поддерживать все HTTP-запросы HEAD и GET, а значения content-length для этого ресурса должны быть одинаковы в HTTP-ответах HEAD и GET. Для запроса HEAD сервер-источник должен поддерживать запрос HEAD и отвечать на те же заголовки, что и при получении запроса GET.
Примечание.
Запросы, включающие заголовок авторизации, не будут кэшироваться.
Поведение кэширования по умолчанию
В следующей таблице описано поведение кэширования по умолчанию для продуктов Azure сеть доставки содержимого и их оптимизации.
Майкрософт: общая веб-доставка | Эдгио: общая веб-доставка | Эдгио: DSA | |
---|---|---|---|
Учет источника | Да | Да | Нет |
Длительность кэша сети доставки содержимого | Два дня | Семь дней | нет |
Значение происхождения: указывает, следует ли учитывать поддерживаемые заголовки директив кэша, если они существуют в ответе HTTP на исходном сервере.
Длительность кэша CDN. Указывает время, в течение которого ресурс кэшируется в сети доставки содержимого Azure. Однако если источник Honor имеет значение "Да", а ответ HTTP с исходного сервера включает заголовок Expires
директивы кэша или Cache-Control: max-age
azure сеть доставки содержимого использует значение длительности, указанное заголовком.
Примечание.
Azure сеть доставки содержимого не гарантирует минимальное время хранения объекта в кэше. Кэшированное содержимое может быть удалено из кэша сети доставки содержимого до истечения срока их действия, если содержимое не запрашивается как часто, чтобы освободить место для более часто запрашиваемого содержимого.
Следующие шаги
- Сведения о настройке и переопределении поведения кэширования по умолчанию в сети доставки содержимого с помощью правил кэширования см. в статье "Управление поведением кэширования Azure сеть доставки содержимого с помощью правил кэширования".
- Сведения об использовании строк запроса для управления поведением кэширования см. в статье "Управление поведением кэширования Azure сеть доставки содержимого с помощью строк запроса".