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

  • Статья

В этой статье представлен обзор общих концепций кэширования и способа использования кэширования 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).

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-ModifiedETag проверяющие элементы по умолчанию, а 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.
  • Кэш проверяет файл с помощью 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-ageazure сеть доставки содержимого использует значение длительности, указанное заголовком.

Примечание.

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

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