HTTP
Кэширование HTTP-ответов

Android Angular 2 AngularJS C# Language HTML Java Language JavaScript Node.js PHP Python Language
Поиск…


замечания

Ответы кэшируются отдельно для каждого URL-адреса и каждого метода HTTP.

HTTP-кэширование определено в RFC 7234 .

глоссарий

  • fresh - состояние кэшированного ответа, которое еще не истекло. Как правило, свежий ответ может удовлетворять запросы без необходимости контактировать с сервером ответ, исходящий из него.
  • stale - состояние кэшированного ответа, которое прошло по истечении срока его действия. Как правило, устаревшие ответы не могут использоваться для удовлетворения запроса без проверки с сервером, сохраняется ли он.
  • удовлетворяющий запросу с кешированием, удовлетворяет запросу, когда все условия в запросе соответствуют кешированному ответу, например, они имеют один и тот же HTTP-метод и URL-адрес, ответ свежий или запрос позволяет выполнять устаревшие ответы, заголовки заголовков запросов заголовков, перечисленные в заголовке ответа Vary , и т. д. ,
  • revalidation - проверка того, является ли кешированный ответ свежим. Обычно это делается с условным запросом, содержащим статус If-Modified-Since или If-None-Match и ответ 304 .
  • частный кеш- кеш для одного пользователя, например, в веб-браузере. Частные кэши могут хранить персонализированные ответы.
  • общий кэш - кеш, общий для многих пользователей, например, на прокси-сервере. Такой кеш может отправлять один и тот же ответ нескольким пользователям.

Кэш-ответ для каждого в течение 1 года

Cache-Control: public, max-age=31536000

public означает, что ответ одинаковый для всех пользователей (он не содержит персонализированной информации). max-age - через несколько секунд. 31536000 = 60 * 60 * 24 * 365.

Это рекомендуется для статических активов, которые никогда не должны меняться.

Персонализированный ответ кэша в течение 1 минуты

Cache-Control: private, max-age=60

private указывает, что ответ может быть кэширован только для пользователя, который запросил ресурс, и не может использоваться повторно, когда другие пользователи запрашивают тот же ресурс. Это подходит для ответов, которые зависят от файлов cookie.

Прекратите использование кэшированных ресурсов, не проверив сначала сервер

Cache-Control: no-cache

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

Ответы no-cache будут медленнее (высокая латентность) из-за необходимости обращаться к серверу каждый раз, когда они используются.

Однако для экономии пропускной способности клиенты могут сохранять такие ответы. Ответы no-cache не будут использоваться для удовлетворения запросов без обращения к серверу каждый раз, чтобы проверить, можно ли повторно использовать кешированный ответ.

Запросить ответы не на всех

 Cache-control: no-store

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

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

Он подходит только в конкретных случаях, когда данные ответа всегда разные, например, конечная точка API, которая возвращает большое случайное число. В противном случае для no-cache и повторной аттестации можно использовать поведение «неприкасаемого» ответа, сохраняя при этом некоторую пропускную способность.

Устаревшие, избыточные и нестандартные заголовки

  • Expires - указывает дату, когда ресурс становится устаревшим. Он полагается на серверы и клиенты, имеющие точные часы и поддерживающие часовые пояса правильно. Cache-control: max-age имеет преимущество перед Expires и, как правило, более надежным.

  • директивы post-check и pre-check являются нестандартными расширениями Internet Explorer, которые позволяют использовать устаревшие ответы. Стандартная альтернатива является stale-while-revalidate .

  • Pragma: no-cache - устарел в 1999 году . Вместо этого следует использовать Cache-control .

Изменение кэшированных ресурсов

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

http://example.com/image.png?version=1
http://example.com/image.png?version=2

Эти два URL-адреса будут кэшироваться отдельно, поэтому даже если …?version=1 было кэшировано навсегда , новая копия может быть немедленно восстановлена ​​как …?version=2 .

Не используйте случайные URL-адреса для обхода кешей. Используйте Cache-control: no-cache или Cache-control: no-store вместо этого. Если ответы со случайными URL-адресами отправляются без директивы no-store , они будут излишне храниться в кэшах и выталкивать из кэша более полезные ответы, снижая производительность всего кеша.



Modified text is an extract of the original Stack Overflow Documentation
Лицензировано согласно CC BY-SA 3.0
Не связан с Stack Overflow