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

В этой статье представлен обзор основных понятий кэширования и того, как 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 от исходного сервера к точке присутствия (POP) сети доставки содержимого, Cache-Control по умолчанию учитывается всеми профилями Azure Content Delivery Network. Azure CDN также учитывает поведение кэширования для директив cache-Control в RFC 7234 — протокол гипертекстовой передачи (HTTP/1.1): кэширование (ietf.org).

Срок действия истекает:

• Устаревший заголовок, введённый в 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 Standard от Microsoft поддерживает только Last-Modified.

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-запросы HEAD и GET, а значения длины содержимого должны совпадать с любыми ответами HEAD и GET HTTP для ресурса. Для запроса HEAD сервер-источник должен поддерживать запрос HEAD и отвечать на те же заголовки, что и при получении запроса GET.

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

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

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

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

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

• Чтобы узнать, как настраивать и переопределять поведение кэширования по умолчанию в сети доставки содержимого с помощью правил кэширования, см. в статье "Управление поведением кэширования в Azure сети доставки содержимого с помощью правил кэширования".
• Чтобы узнать, как использовать строки запроса для управления поведением кэширования, см. статью "Управление поведением кэширования в сети доставки содержимого Azure с помощью строк запроса".