О чем мы говорим, когда говорим о кэшировании HTTP

внешний интерфейс сервер HTTP браузер
О чем мы говорим, когда говорим о кэшировании HTTP

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

О чем мы говорим, когда говорим о кэшировании HTTP:

На самом деле мы говорим о следующих двух ситуациях:

Как показано на рисунке выше, в HTTP-кэше браузера для статических ресурсов есть две ситуации: сильный кеш (локальный кеш) и слабый кеш (согласованный кеш).


Процесс кэширования:

Когда браузер запрашивает ресурс в первый раз:

图片出自网络

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

Процесс сопоставления, когда браузер впоследствии запрашивает ресурсы:

Из приведенного выше рисунка вы можете узнать процесс HTTP, когда браузер запрашивает статический ресурс:

  1. Стадия сильного кеша: сначала ищите ресурс локально, если ресурс найден и нет проблем с другими ограничениями (например, временем действия кеша), нажмите на сильный кеш, верните 200, используйте сильный кеш напрямую и не будете отправить запрос на сервер
  2. Стадия слабого кеша: найти ресурс в локальном кеше, отправить http-запрос на сервер, сервер определяет, что ресурс не был изменен, и возвращает 304, чтобы позволить браузеру использовать ресурс.
  3. Стадия сбоя кэширования (повторный запрос): когда сервер обнаруживает, что ресурс был изменен или кэшированный ресурс не найден локально, сервер возвращает данные ресурса.

Разница между сильным кешем и слабым кешем:

Получить форму ресурса: Все получают ресурсы из кеша.

код состояния: Сильный кеш возвращает 200 (из кеша), слабый кеш возвращает код состояния 304.

запрос (наибольшая разница):

Сильный кеш не отправляет запросы, а извлекает напрямую из кеша.

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


Сильный кеш:

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

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

Cache-Control

Cache-Control находится в http1.1, чтобы компенсироватьExpiresДобавлен дефект: когда Expires и Cache-Control существуют одновременно, Cache-Control имеет более высокий приоритет, чем Expires.

Опции:

Кэшируемость:

public: кэширование как на стороне сервера, так и на стороне браузера.

private: может кэшироваться только на стороне браузера

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

only-if-cached: указывает, что клиент принимает только кешированные ответы и не проверяет на исходном сервере более новую копию.

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

max-age=60: установить максимальный период хранения кеша, по истечении которого кеш считается просроченным (в секундах). вот 60 секунд

другие настройки:

no-store: без кеша, использовать согласованный кеш

must-revalidate: Кэш ДОЛЖЕН проверять состояние старых ресурсов перед их использованием и НЕ ДОЛЖЕН использовать ресурсы с истекшим сроком действия.

больше настроек, мобильныйMDN

// 示例
Cache-Control: no-cache, no-store, must-revalidate
Cache-Control:public, max-age=31536000
Cache-Control: max-age=3600, must-revalidate

Кэш в эпоху http1.0 Expires+Pragma

Expires используется для установки времени истечения срока действия кеша.:

Укажите абсолютное время истечения срока действия кеша по Гринвичу. Если установлено значение max-age, max-age переопределит значение expires. Если истечет срок действия, вам необходимо повторно запросить.

Expires:Sat, 09 Jun 2018 08:13:56 GMT

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

Прагма отключить кеш:

Pragma : no-cacheУказывает, что для предотвращения кэширования клиента необходимо принудительно получать последние данные с сервера;

Pragma : no-cache  //只有这一个用法 禁用缓存,强制从服务器获取最新的数据; 

Сильное попадание в кеш из кеша памяти и из кеша диска

Во время теста, когда я увидел сильное попадание в кеш, было два состояния: 200 (из кеша памяти) кеша и 200 (из кеша диска), поэтому я искал разницу между ними:

кэш памяти: хранить ресурсы вОЗУ, полученное из памяти.

дисковый кеш: кешировать ресурсы вдиск, полученный с диска.

Самая большая разница между ними заключается в следующем:При выходе из процесса данные в памяти будут очищены, а данные на диске не будут.

Более подробное введение рекомендую этостатья


Слабый кеш:

Если время сильного кэша истекает или не установлено, это приводит к промаху. Он вступил в стадию слабого кеша.

Last-Modified & if-modified-since:

Last-Modified и If-Modified-Since — это пара заголовков, принадлежащих http 1.0.

last-modified — это время последней модификации файла, которую веб-сервер рассматривает.last-modifiedКогда файл запрашивается в первый раз,сервер возвращаетатрибут .

Last-Modified: Sat, 09 Jun 2018 08:13:56 GMT 

При втором запросе файла браузер помещаетIf-Modified-Sinceотправить на сервер, спрашивая, был ли файл изменен с тех пор.

If-Modified-Since: Sat, 09 Jun 2018 08:13:56 GMT // 跟Last-Modified的值一样

ETag & If-None-Match

ETag и If-None-Match — это пара пакетов, принадлежащих http 1.1.

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

Механизм ETag аналогичен механизму оптимистической блокировки: если ETag сообщения запроса не совпадает с ETag сервера, это означает, что ресурс был изменен и в браузер необходимо отправить самое последнее содержимое.

ETagТакже при первом запросе сервер возвращает:

ETag: "8F759D4F67D66A7244638AD249675BE2" // 长这样

If-None-MatchОн также отправляется браузером на сервер, чтобы убедиться, что файл изменился:

If-None-Match: "8F759D4F67D66A7244638AD249675BE2" // 跟ETag的值一样

Процесс Etag/lastModified выглядит следующим образом:

  1. В первый раз, когда клиент делает запрос к серверу, сервер прикрепитLast-Modified/ETagк предоставленным ресурсам
  2. Когда ресурс запрашивается снова,Если сильный кеш не попал, при выполнении проверкиПередайте Last-Modified/ETag, возвращенный сервером при последнем запросе к серверу..
  3. Сервер проверяет Last-Modified или ETag и определяет ресурсСтраница не была изменена с момента последнего запроса клиента, возвращает ответ 304 и пустое тело ответа..

Используйте оба заголовка одновременно:

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

Etag в основном предназначен для решения некоторых проблем, которые не может решить Last-Modified:

  1. Некоторые файлы могут не менять содержимое (меняется только время модификации), в это время мы не хотим, чтобы файл перезагружался. (значение Etag активирует кэш, Last-Modified не активирует)
  2. Детализация, которую может проверить If-Modified-Since, составляет секунды.Когда модификация очень частая, Last-Modified активирует кеш, но значение Etag не будет запускаться и перезагружаться.
  3. Некоторые серверы не могут получить точное время последней модификации файла.

Действия пользователя и кеш

Сброс F5 вызывает сильную недействительность кеша.

ctrl+F5 принудительно обновить сильный кеш страницы, слабый кеш будет недействителен.

图片出自网络

Как это настроить?

Как правило, эти заголовки запросов устанавливаются на стороне сервера, я пытался использовать настройки сервера Alibaba Cloud самостоятельно.Cache-Control, очень удобно его настраивать.


резюме

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

Если в статье есть какие-то неправильные места, прошу поощрить всех проходящих мимо! Если вам нравится, поторопитесьподпискаПодпишитесь/Нравится.

Поощряйте меня:

Если вы думаете, что это хорошо, дайте мне проектstarБар