Поделиться через

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

  • Статья

Внимание

Azure CDN standard от Корпорации Майкрософт (классическая версия) будет прекращена 30 сентября 2027 г. Чтобы избежать нарушений работы служб, важно перенести профили Azure CDN уровня "Стандартный" от Майкрософт (классический) на уровень Azure Front Door standard или Premium к 30 сентября 2027 г. Дополнительные сведения см. в статье Azure CDN Standard от майкрософт (классическая версия).

Azure CDN из Эдгио был прекращен 15 января 2025 г. Дополнительные сведения см. в статье 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 сеть доставки содержимого поддерживает следующие заголовки директивы кэша HTTP, определяющие длительность кэша и общий доступ к кэшу.

Cache-Control:

  • Представлен в HTTP 1.1, чтобы дать веб-издателям больше возможностей управления своим содержимым и устранить ограничения заголовка Expires.
  • Переопределяет заголовок Expires, если определен этот заголовок и заголовок Cache-Control.
  • При использовании в HTTP-запросе от клиента к сети доставки содержимого POP по Cache-Control умолчанию игнорируется всеми профилями Azure сеть доставки содержимого.
  • При использовании в ответе HTTP от исходного сервера к сети Cache-Control доставки содержимого POP по умолчанию учитывается всеми профилями Azure сеть доставки содержимого. Azure CDN также учитывает поведение кэширования для директив cache-Control в RFC 7234 — протокол гипертекстовой передачи (HTTP/1.1): кэширование (ietf.org).

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 уровня "Стандартный" от Майкрософт поддерживает только Last-Modified.

Примечание.

Azure CDN от Майкрософт (классическая версия) не поддерживает ETag.

Last-Modified:

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

Условия Значение
Коды состояния HTTP 200, 203, 206, 300, 301, 410, 416
Методы HTTP GET, HEAD
Ограничения размера файла 300 ГБ

Чтобы кэширование работало с ресурсом, сервер-источник должен поддерживать все HTTP-запросы HEAD и GET, а значения длины содержимого должны совпадать с любыми ответами HEAD и GET HTTP для ресурса. Для запроса HEAD сервер-источник должен поддерживать запрос HEAD и отвечать на те же заголовки, что и при получении запроса GET.

Примечание.

Запросы, включающие заголовок авторизации, не будут кэшироваться.

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

Поведение кэширования по умолчанию для Azure CDN — " Почитать источник " и кэшировать содержимое в течение двух дней.

Происхождение чести: этот параметр указывает, следует ли учитывать заголовки директив кэша (Cache-Control или Expires), если они присутствуют в ответе HTTP на исходном сервере.

Длительность кэша CDN. Этот параметр указывает длительность кэширования ресурса в Azure CDN. Если источник Honor включен, а http-ответ от исходного сервера включает Cache-Control: max-age или Expires заголовок, Azure CDN будет использовать длительность, указанную этими заголовками, а не двухдневный период по умолчанию.

Примечание.

Azure CDN не дает никаких гарантий относительно минимального времени, в течение которого объект будет храниться в кэше. Кэшированное содержимое может быть удалено из кэша сети доставки содержимого до истечения срока их действия, если содержимое не запрашивается как часто, чтобы освободить место для более часто запрашиваемого содержимого.

Следующие шаги