Кэшировании с помощью Azure Front Door

Внимание

Azure Front Door (классическая версия) будет прекращена 31 марта 2027 г. Чтобы избежать нарушений работы служб, важно перенести профили Azure Front Door (классический) на уровень Azure Front Door standard или Premium к марту 2027 года. Дополнительные сведения см. в статье azure Front Door (классическая версия) для выхода на пенсию.

Azure Front Door — это современная сеть доставки содержимого (CDN), с динамическим ускорением сайта и возможностями балансировки нагрузки. При настройке кэширования на маршруте пограничный сайт, получающий каждый запрос, проверка кэш для допустимого ответа. Кэширование помогает уменьшить объем трафика, отправляемого на сервер-источник. Если кэшированный ответ недоступен, запрос пересылается в источник.

Каждый пограничный сайт Front Door управляет собственным кэшем, и запросы могут обслуживаться различными пограничными сайтами. В результате некоторый трафик может по-прежнему отображаться в источнике, даже если вы обслуживали кэшированные ответы.

Кэширование может значительно уменьшить задержку и снизить нагрузку на серверы-источники. Однако не все типы трафика могут воспользоваться кэшированием. Статические ресурсы, такие как изображения, CSS и файлы JavaScript, идеально подходят для кэширования. Хотя динамические ресурсы, такие как конечные точки API с проверкой подлинности, не следует кэшировать, чтобы предотвратить утечку персональных данных. Рекомендуется использовать отдельные маршруты для статических и динамических ресурсов, при этом кэширование отключено для последнего.

Предупреждение

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

Методы запроса

Кэшируются только запросы, использующие GET метод запроса. Все остальные методы запроса всегда передаются через сеть.

Доставка больших файлов

Azure Front Door доставляет большие файлы без ограничения по размеру. Если кэширование включено, Front Door использует метод, называемый блокированием объектов. При запросе большого файла Front Door получает небольшие фрагменты этого файла из сервера-источника. После того как Front Door получает полный запрос файла или запрос файла диапазона байтов, среда Front Door запрашивает файл из источника в блоках 8 МБ.

После того как блок поступает в среду Azure Front Door, он кэширован и немедленно обслуживается пользователю. Front Door затем предварительно получает следующий блок параллельно. Эта предварительная загрузка гарантирует, что всегда будет загружен следующий фрагмент содержимого (по сравнению с тем фрагментом, который просматривает пользователь), что позволяет снизить задержку. Этот процесс продолжается, пока не будет загружен весь файл (если был такой запрос) или клиент не закроет соединение. Дополнительные сведения о запросе диапазона байтов см. в разделе RFC 7233.

Front Door кэширует все фрагменты по мере их получения, поэтому не требуется сохранять весь файл в кэш Front Door. Последующие запросы файла или диапазонов байтов обслуживаются из кэша. Если блоки не все кэшируются, предварительная выборка используется для запроса блоков из источника.

Такая оптимизация строится на том, что сервер-источник принимает запросы на диапазоны байтов. Если источник не поддерживает запросы диапазона байтов или если он не обрабатывает запросы диапазона правильно, эта оптимизация не эффективна.

Когда источник отвечает на запрос с заголовком Range , он должен отвечать одним из следующих способов:

• Возвращает диапазонный ответ. Ответ должен использовать код состояния HTTP 206. Кроме того, Content-Range заголовок ответа должен присутствовать и должен соответствовать фактической длине содержимого, возвращаемого источником. Если источник не отправляет правильные заголовки ответа с допустимыми значениями, Azure Front Door не кэширует ответ, и может возникнуть несогласованная реакция.

  Совет

  Если источник сжимает ответ, убедитесь, что Content-Range значение заголовка соответствует фактической длине сжатого ответа.

• Возвращает неохатрированный ответ. Если источник не может обрабатывать запросы диапазона, он может игнорировать Range заголовок и возвращать неупорядоченный ответ. Убедитесь, что источник возвращает код состояния ответа, отличный от 206. Например, источник может возвращать ответ 200 OK.

Если в источнике используется кодировка передачи фрагментированных данных (CTE) для отправки данных в azure Front Door POP, размеры ответов больше 8 МБ не поддерживаются.

Сжатие файлов

См. дополнительные сведения о повышении производительности за счет сжатия файлов в Azure Front Door.

Azure Front Door (классическая модель) может динамически сжимать содержимое в пограничной среде, что позволяет сократить время и размер ответов, отправляемых клиентам. Сжатие поддерживается только для файлов MIME, если включено кэширование. Сейчас в Front Door (классическая модель) запрещено изменение этого списка. Текущий список приведен ниже.

• "application/eot"
• "application/font"
• "application/font-sfnt"
• "application/javascript"
• "application/json"
• "application/opentype"
• "application/otf"
• "application/pkcs7-mime"
• "application/truetype"
• "application/ttf",
• "application/vnd.ms-fontobject"
• "application/xhtml+xml"
• "application/xml"
• "application/xml+rss"
• "application/x-font-opentype"
• "application/x-font-truetype"
• "application/x-font-ttf"
• "application/x-httpd-cgi"
• "application/x-mpegurl"
• "application/x-opentype"
• "application/x-otf"
• "application/x-perl"
• "application/x-ttf"
• "application/x-javascript"
• "font/eot"
• "font/ttf"
• "font/otf"
• "font/opentype"
• "image/svg+xml"
• "text/css"
• "text/csv"
• "text/html"
• "text/javascript"
• "text/js", "text/plain"
• "text/richtext"
• "text/tab-separated-values"
• "text/xml"
• "text/x-script"
• "text/x-component"
• "text/x-java-source"

Кроме того, размер файла должен составлять от 1 КБ до 8 МБ включительно.

Эти профили поддерживают следующие алгоритмы сжатия:

• Gzip (ZIP-файл GNU)
• Brotli

Если запрос поддерживает сжатие gzip и Brotli, предпочтение отдается Brotli.

Если запрос ресурса указывает сжатие, а запрос приводит к пропуску кэша, Azure Front Door (классическая) выполняет сжатие ресурса непосредственно на POP-сервере. После этого сжатый файл используется из кэша. Полученный элемент возвращается с заголовком Transfer-Encoding: chunked ответа.

Если в источнике используется кодировка передачи фрагментированных данных (CTE) для отправки данных в azure Front Door POP, сжатие не поддерживается.

Примечание.

Запросы диапазонов можно сжимать до разных размеров. Azure Front Door требует, чтобы значения длины содержимого были одинаковыми для любого HTTP-запроса GET. Если клиенты отправляют запросы диапазона байтов с заголовком Accept-Encoding, который приведет к ответу источника с другой длиной содержимого, то Azure Front Door выдаст ошибку 503. Можно либо отключить сжатие в источнике, либо создать правило обработчика правил, чтобы удалить Accept-Encoding заголовок из запроса на запросы диапазона байтов.

Поведение строк запросов

С помощью Azure Front Door можно управлять способом кэширования файлов для веб-запроса, который содержит строку запроса.

В веб-запросе со строкой запроса строка запроса — это часть запроса, которая возникает после вопроса (?). Строка запроса может содержать одну или несколько пар "ключ-значение", в которых имя поля и его значение разделены знаком равенства (=). Каждая пара "ключ-значение" разделяется знаком амперсанда (&).

Например, URL-адрес http://www.contoso.com/content.mov?field1=value1&field2=value2 содержит две строки запроса:

• field1, со значением value1.
• field2, со значением value2.

Если в строке запроса есть несколько пар "ключ-значение", их порядок не имеет значения.

При настройке кэширования вы указываете, как кэш должен обрабатывать строки запроса. Поддерживаются следующие действия:

• Игнорировать строку запроса. В этом режиме Azure Front Door передает строки запроса от клиента к источнику в первом запросе и кэширует ресурс. Будущие запросы к ресурсу, обслуживаемого из среды Front Door, игнорируют строки запроса до истечения срока действия кэшированного ресурса.

• Используйте строку запроса: в этом режиме каждый запрос с уникальным URL-адресом, включая строку запроса, рассматривается как уникальный ресурс с собственным кэшем. Например, ответ сервера-источника для запроса к www.example.ashx?q=test1 сохраняется в кэше в среде Front Door и возвращается для последующих кэшей с этой же строкой запроса. Запрос к www.example.ashx?q=test2 будет кэшироваться как отдельный ресурс с собственным сроком существования.

  Порядок параметров строки запроса не имеет значения. Например, если среда Azure Front Door содержит кэшированный ответ для URL-адреса www.example.ashx?q=test1&r=test2, то запрос www.example.ashx?r=test2&q=test1 также обслуживается из кэша.

• Игнорировать указанные строки запроса и включать указанные строки запроса. В этом режиме можно настроить Azure Front Door для включения или исключения указанных параметров при создании ключа кэша.

  Например, предположим, что ключ кэша по умолчанию имеет значение /foo/image/asset.html, и запрос выполняется по URL-адресу https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Если существует правило обработчика правил для исключения userid параметра строки запроса, то ключ кэша строки запроса будет /foo/image/asset.html?language=EN&sessionid=200.

Настройте поведение строки запроса в маршруте Front Door.

Очистка кэша

Дополнительные сведения о настройке очистки кэша см. в статье Очистка кэша в Azure Front Door.

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

Лучший способ убедиться, что пользователи всегда получают последнюю версию ресурсов — изменять версию ресурсов при каждом обновлении и публиковать их в виде нового URL-адреса. Front Door будет незамедлительно получать ресурсы для следующих клиентских запросов. Иногда может потребоваться очистить кэшированное содержимое со всех пограничных узлов и сделать так, чтобы узлы получили новые обновленные ресурсы. Это необходимо, например, для обновления веб-приложения или быстрого обновления ресурсов, которые содержат неверные сведения.

Выберите, какие ресурсы нужно удалить из граничных узлов. Чтобы удалить все ресурсы, выберите Очистить все. Или укажите в параметре Путь путь к каждому ресурсу, который необходимо удалить.

В списках путей для очистки можно использовать следующие форматы.

• Очистка одного пути. Удаление отдельных ресурсов путем указания полного пути (без протокола и домена) с расширением файла, например /pictures/strasbourg.png.
• Очистка по подстановочным знакам. В качестве подстановочного знака можно использовать звездочку (*). Можно очистить все папки, вложенные папки и файлы на конечной точке, если добавить /* в конце пути к ней. Также можно очистить все вложенные папки и файлы в определенной папке, указав /* в конце пути к папке, например /pictures/*.
• Очистка корневого домена. Очищает содержимое в корне конечной точки, в пути которой есть знак "/".

Примечание.

Очистка доменов с подстановочными знаками. Указание кэшированных путей для очистки, как описано в этом разделе, не применяется к доменам с подстановочными знаками, которые связаны с Front Door. В настоящее время прямая очистка доменов с подстановочными знаками не поддерживается. Можно удалить ресурс конкретного поддомена, указав такой поддомен и путь очистки. Например, если в Front Door есть домен *.contoso.com, можно очистить ресурсы в поддомене foo.contoso.com, указав путь foo.contoso.com/path/*. В настоящее время в качестве имен узлов в пути очистки содержимого можно указывать только поддомены доменов с подстановочными знаками, если это применимо.

При очистке кэша во Front Door не учитывается регистр. Кроме того, они не зависят от строки запроса, что означает, что очистка URL-адреса очищает все варианты строки запроса.

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

Следующий порядок заголовков используется для определения времени хранения элемента в нашем кэше:

1. Cache-Control: s-maxage=<seconds>
2. Cache-Control: max-age=<seconds>
3. Expires: <http-date>

Некоторые Cache-Control значения заголовка ответа указывают на то, что ответ не является кэшируемым. К этим значениям относятся private, no-cacheи no-store. Front Door учитывает эти значения заголовков и не кэширует ответы, даже если вы переопределяете поведение кэширования с помощью обработчика правил.

Cache-Control Если заголовок не присутствует в ответе от источника, по умолчанию Front Door случайным образом определяет длительность кэша от одного до трех дней.

Примечание.

Срок действия кэша не может превышать 366 дней.

Вы можете увидеть REVALIDATED_HIT в заголовке Cache-Control ответа. Это означает, что кэшированное содержимое в Azure Front Door было обновлено с сервером-источником перед отправкой клиенту. Это может произойти, когда истек срок действия кэшированного содержимого, но сервер-источник указывает, что содержимое не изменилось. В этом случае кэшированное содержимое обслуживается клиенту, а срок действия кэша сбрасывается.

Заголовки запросов

Следующие заголовки запросов не перенаправляются в источник при включении кэширования:

• Content-Length
• Transfer-Encoding
• Accept
• Accept-Charset
• Accept-Language

Заголовки ответа

Если ответ источника кэшируется, Set-Cookie заголовок удаляется до отправки ответа клиенту. Если ответ источника не является кэшируемым, Front Door не удаляет заголовок. Например, если ответ источника содержит Cache-Control заголовок со max-age значением, указывающим Front Door, что ответ кэшируется, а Set-Cookie заголовок отрезается.

Кроме того, Front Door присоединяет X-Cache заголовок ко всем ответам. Заголовок X-Cache ответа содержит одно из следующих значений:

• TCP_HITилиTCP_REMOTE_HIT: первый 8-МБ фрагмент ответа является хитом кэша, а содержимое обслуживается из кэша Front Door.
• TCP_MISS: первый 8-МБ фрагмент ответа является пропущенным кэшем, и содержимое извлекается из источника.
• PRIVATE_NOSTORE: невозможно кэшировать запрос, так как заголовок ответа cache-Control имеет значение private или no-store.
• CONFIG_NOCACHE: запрос настроен для не кэширования в профиле Front Door.

Журналы и отчеты.

Журнал доступа включает состояние кэша для каждого запроса. Кроме того, отчеты включают сведения о том, как кэш Azure Front Door используется в приложении.

Журнал доступа включает состояние кэша для каждого запроса.

Поведение и длительность кэширования

Поведение и длительность кэширования можно настроить в обработчике правил. Конфигурация кэширования обработчика правил всегда переопределяет конфигурацию маршрута.

• При отключении кэширования Azure Front Door не кэширует содержимое ответа независимо от директив ответа источника.

• Если кэширование включено, поведение кэша отличается в зависимости от значения поведения кэша, применяемого обработчиком правил:

  • Происхождение чести: Azure Front Door всегда учитывает директиву заголовка ответа источника. Если директива источника отсутствует, Azure Front Door кэширует содержимое в любом месте от одного до трех дней.
  • Переопределение всегда: Azure Front Door всегда переопределяет длительность кэша, то есть кэширует содержимое в течение длительности кэша, игнорируя значения из директив ответа источника. Это поведение применяется только в том случае, если ответ можно кэшировать.
  • Переопределите, если источник отсутствует: если источник не возвращает значения TTL, Azure Front Door использует указанную длительность кэша. Это поведение применяется только в том случае, если ответ можно кэшировать.

Примечание.

• Azure Front Door не дает никаких гарантий в отношении времени, в течение которого содержимое хранится в кэше. Кэшированное содержимое может быть удалено из кэша периферии до истечения срока действия содержимого, если оно не используется часто. Front Door может обслуживать данные из кэша, даже если срок действия кэшированных данных истек. Такое поведение может помочь вашему сайту оставаться частично доступным, когда ваши источники отключены.
• Источники могут указывать не кэшировать определенные ответы, используя заголовок Cache-Control со значением no-cache, private или no-store. При использовании в ответе HTTP с исходного сервера на POPs Azure Front Door Azure Front Door поддерживает директивы управления кэшем и учитывает поведение кэширования для директив управления кэшем в RFC 7234 — протокол http/1.1: кэширование (ietf.org).

Поведение и длительность кэширования можно настроить как в правиле маршрутизации конструктора Front Door, так и в обработчике правил. Конфигурация кэширования обработчика правил всегда переопределяет конфигурацию правила маршрутизации конструктора Front Door.

• При отключении кэширования Azure Front Door (классическая модель) не кэширует содержимое ответа независимо от директив ответа источника.

• Если кэширование включено, поведение кэша отличается для разных значений длительности использования кэша по умолчанию.

  • При использовании длительности кэша по умолчанию задано значение Yes, Azure Front Door (классическая) всегда учитывает директиву заголовка ответа источника. Если директива источника отсутствует, Front Door кэширует содержимое в любом месте от одного до трех дней.
  • При использовании длительности кэша по умолчанию задано значение No, Azure Front Door (классическая) всегда переопределяется с длительностью кэша (обязательные поля), то есть кэширует содержимое в течение длительности кэша, игнорируя значения из директив ответа источника.

Примечание.

• Azure Front Door (классическая модель) не дает никаких гарантий относительно времени, в течение которого содержимое хранится в кэше. Кэшированное содержимое может быть удалено из кэша периферии до истечения срока действия содержимого, если оно не используется часто. Azure Front Door (классическая модель) может обслуживать данные из кэша, даже если срок действия кэшированных данных истек. Такое поведение может помочь вашему сайту оставаться частично доступным, когда ваши источники отключены.
• Длительность кэширования, заданная в правиле маршрутизации конструктора Front Door, — это минимальная длительность кэширования. Это переопределение не будет работать, если заголовок элемента управления кэшем из источника имеет больший срок жизни, чем значение переопределения.

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

• Узнайте, как создать Azure Front Door (классическая модель).
• Узнайте, как работает Azure Front Door (классическая модель)

• См. дополнительные сведения об условиях соответствия для набора правил.
• См. дополнительные сведения о действиях набора правил.