Говоря о HTTP-кэше (HTTP-кэш)

1. Введение

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

Проблемы, с которыми можно столкнуться, могут быть:Развернутый код не работает

На этот раз моя команда также столкнулась с похожими проблемами, вот краткое описание:

Проект будет использовать chunkHash для обработки статических ресурсов (таких как: css, js), поэтому он может гарантировать, что имя старого файла кода не будет повторяться после модификации. чтобы избежать невозможности обновления изменений.
После развертывания в этом проекте сделайте код один разlocation.reload, изменения вступят в силу.

Наконец, я узнал, что заголовки ответов всех статических ресурсов на сервере, развернутом проектом, установлены следующим образом:

response headers:

cache-control: public, max-age=31536000

Но фатально запись проекта:index.htmlтоже так. Так что на самом деле это потому, что все файлы .html попали в кеш.Сильный кеш, что не позволяет пользователю напрямую представлять изменения в обновленном коде.

Я нашел причину и подумал о следующих трех решениях

Добавить временную метку при прыжке, например:

В частности, почему это можно сделать, он будет проанализирован, когда будет проанализирован позже, чтобы увидеть, есть ли шаг кэширования.
```
location.href = 'https://www.localhost:5000.com/index.html?t=201811141248001';
```
Изменить управление кешем в заголовках ответов

Пример:
```
cache-control: public, max-age=0
```
Использование метатегов HTML

Вы можете добавить метатеги в html-код:
```
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
```
Функция приведенного выше кода состоит в том, чтобы сообщить браузеру, что текущая страница не кэшируется, и при каждом посещении необходимо обращаться к серверу, чтобы получить ее. Он прост в использовании, но поддерживается только некоторыми браузерами и не поддерживается всеми кеширующими прокси-серверами, поскольку прокси-сервер сам не анализирует содержимое HTML.

HTML-теги лучше не указывать, так как может возникнуть путаница (в конце концов это конец, реальный заголовок ответа имеет более высокий приоритет). Кроме того, в HTML5 эти теги недействительны. Разрешены только эквиваленты HTTP, перечисленные в спецификации HTML5.

Вы можете обратиться к:W3 HTML spec chapter 5.2.2

2. Основные понятия кэширования HTTP

Теперь, когда я нашел проблему, я думаю, что сделаю краткое резюме.

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

(1) Упростить процесс

Ключевые шаги:

Определить, есть ли кеш
Определить, действителен ли кеш (То есть попадает ли сильный кеш)
Запросите сервер, чтобы определить, обновлены ли ресурсы сервера (То есть, попадает ли кеш согласования)
Верните ресурс (если сервер возвращает ресурс, сохраните запрос локально, включая информацию заголовка запроса)

(2) Проверьте, есть ли кеш

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

Возьмите Firefox в качестве примера, вы можете ввести в адресную строку:about:cache

P.S: chrome://cacheУстарело после версии chrome66.

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

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

Как показано выше, это файл, который отвечает на запрос один раз, и в нем будет записан полный URL-адрес, включая: строку запроса.

Как вы можете видеть на двух рисунках выше, мы изменили значение параметра t. На самом деле мы поставили метку времени после URL, чтобы не попасть в кеш. На самом деле здесь изменен URL-адрес запроса, чтобы браузер не мог запрашивать тот же локальный кеш, что и предыдущий запрос.

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

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

(3) Сильный кеш

[1] Надежная концепция кэширования

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

На самом деле, это входит в наш общий процесс, чтобы увидеть, есть ли кеш, и проверить, действителен ли кеш.

[2] Как реализовать надежный кеш

Реализация сильного кэширования в основном основана на двух полях в заголовке ответа на стороне сервера, зарезервированных клиентом:expires,cache-control.
cache-controlсоотношение приоритетовexpiresвысоко.

Как показано на рисунке:

На рисунке показана разница между двумя

Значение времени expires в сообщении ответа HTTP является абсолютным значением.
Cache-Control в ответном сообщении HTTP имеет значение max-age=31536000, что является относительным значением.

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

Expires

Expires — это поле, используемое HTTP/1.0 для управления кешированием веб-страницы.Его значение — время истечения кэша, возвращаемого сервером.То есть, когда запрос инициируется снова, если время клиента меньше, чем значение Expires , кэшированный результат будет использоваться напрямую.
```
Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

Cache-Control

В HTTP/1.1 Cache-Control является наиболее важным правилом, которое в основном используется для управления кэшированием веб-страниц.Перечислено несколько общих значений:

общедоступный: весь контент будет кэшироваться (кэшируется как клиент, так и прокси-сервер)
private: весь контент может кэшироваться только клиентом, значение по умолчанию для Cache-Control
no-cache: клиент кэширует содержимое, но необходимость использования кеша должна быть проверена путем согласования кеша.
no-store: Весь контент не будет кэшироваться, т. е. не используется ни принудительный кеш, ни согласованный кеш.
max-age=xxx (xxx — число): кешированное содержимое истечет через xxx секунд.
```
Cache-Control:public, max-age=31536000
```

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

Формула для расчета времени инвалидации кеша выглядит следующим образом:

expirationTime = responseTime + freshnessLifetime - currentAge

В приведенной выше формулеresponseTimeУказывает момент времени, когда браузер получил этот ответ.

[3] Как определить, попал ли сильный кеш или нет

Код состояниясерыйЗапрос означает, что используется принудительный кеш, а запрос, соответствующийЗначение Size представляет место, где хранится кеш.

Что касается кэша памяти и дискового кэша, то это относится к более позднему объяснению.

(4) Кэш согласования

[1] Согласование концепции кеша

Согласование кеша — это процесс, в котором браузер инициирует запрос с идентификатором кеша на сервер после принудительного отказа кеша, и сервер решает, использовать ли кеш в соответствии с идентификатором кеша.

[2] Как реализовать кеш согласования

Идентификатор кэша согласования также возвращается в браузер вместе с результатом запроса в HTTP-заголовке ответного пакета.Поля, управляющие кэшем согласования:Last-Modified / If-Modified-Sinceа такжеEtag / If-None-Match.
Etag / If-None-Matchсоотношение приоритетовLast-Modified / If-Modified-Sinceвысоко.

Last-modified:

Last-Modified — это время последнего изменения файла ресурсов на сервере, когда сервер ответил на запрос.

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

If-Modified-Since:

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Etag:

Etag — это уникальный идентификатор текущего файла ресурсов (генерируемый сервером), когда сервер отвечает на запрос.

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

If-None-Match:

If-None-Match означает, что когда клиент снова инициирует запрос, он несет значение Etag уникального идентификатора, возвращенное последним запросом, и значение этого поля сообщает серверу значение уникального идентификатора, возвращенное последним запросом ресурса. После того, как сервер получит запрос и обнаружит, что заголовок запроса содержит If-None-Match, он сравнит значение поля If-None-Match со значением Etag ресурса на сервере. 304, что указывает на то, что ресурс не обновлен. , продолжайте использовать файл кеша, в случае несоответствия вернитесь к файлу ресурсов, код состояния 200

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Затем мы смотрим на конкретный процесс:

[4] Как определить, попал ли кеш согласования или нет

Если согласованный кеш сработает, ответ на запрос вернет статус http 304 и отобразится строка Not Modified.

(5) Сходства и различия между двумя

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

4. Связанные операции просмотра

На самом деле соответствующие операции браузера будут иметь некоторое влияние на понимание разработчиком HTTP-кэша браузера, поэтому давайте разберем его подробно:

В серии «Механизмы веб-кэширования» Alloy Team есть краткое изложение:

Механизм веб-кэширования, серия 2 – Механизм кэширования веб-браузеров - Alloy Team

Операции, связанные с браузером	Expires/Cache-Control	Last-Modified / Etag
Введите в адресной строке	эффективный	эффективный
переход по ссылке на страницу	эффективный	эффективный
новое окно	эффективный	эффективный
вперед назад	эффективный	эффективный
обновить	неверный	эффективный
Принудительное обновление	неверный	неверный

Хочу разобрать этот кусок, поделиться им с вами и проверить:

Предпосылки теста:

Сервер устанавливает соответствующий заголовок ответа,
Соответствующие ресурсы были загружены впервые (если результаты теста совпадают, изображения результатов теста будут использованы повторно):

Протестированные браузеры:

Chrome 70
Firefox 63.0.1
Opera 56.0

Затронутые тестовые файлы:

index.html (главная страница)
index.js (ресурс js)
index.css (файл стиля)
doge.jpeg (файл изображения)
favicon.ico (файл значка)
temp.html (вспомогательная страница перехода, не устанавливайте заголовок ответа и не входит в область статистики)

Настройки заголовка ответа, используемые тестом:

Cache-Control: max-age=300 // кешировать на 5 минут
ETag: 33a64df551425fcc55e4d42a148795d9f25f89d4 // Фиксированный возврат сервера
Истекает: пятница, 16 ноября 2018 г., 09:33:01 GMT+0800 (CST) // кэш на 5 минут
Последнее изменение: ср, 21 октября 2018 г., 07:28:00 по Гринвичу // Исправлен возврат с сервера

(1) переход по ссылке на страницу

Результаты теста Chrome 70:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
Index.csss: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: не отображается (используйте инструмент захвата пакетов для захвата пакетов, запрос не выдается)

Результаты теста Firefox 63.0.1:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: хитСильный кеш(Используйте инструмент захвата пакетов для захвата пакета, запрос не выдается)

Результаты теста Opera 56.0:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: запрос не был отправлен (используйте инструмент захвата пакетов для захвата пакетов, запрос отсутствует)

(2) Новое окно

Результаты теста Chrome 70 (поскольку по умолчанию используется страница Google с использованием теста режима конфиденциальности):

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: запрос не был отправлен (используйте инструмент захвата пакетов для захвата пакетов, запрос отсутствует)

Результаты теста Firefox 63.0.1:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
Favicon.ico: хитСильный кеш(Используйте инструмент захвата пакетов для захвата пакета, запрос не выдается)

Результаты тестирования Opera 56.0 (режим конфиденциальности):

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: запрос не был отправлен (используйте инструмент захвата пакетов для захвата пакетов, запрос отсутствует)

(4) Вперед и назад

Результаты теста Chrome 70:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: запрос не был отправлен (используйте инструмент захвата пакетов для захвата пакетов, запрос отсутствует)

Результаты теста Firefox 63.0.1:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: хитСильный кеш(Используйте инструмент захвата пакетов для захвата пакета, запрос не выдается)

Результаты теста Opera 56.0:

Как показано на рисунке:

результат:

index.html: хитСильный кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: запрос не был отправлен (используйте инструмент захвата пакетов для захвата пакетов, запрос отсутствует)

(5) Обновить

Обновление этой части находится в центре внимания теста (из-за этого раньше)

Результаты теста Chrome 70:

Как показано на рисунке:

результат:

index.html: хитСогласовать кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico:нет попадания в кеш, сервер получает ресурс

Результаты теста Firefox 63.0.1:

Как показано на рисунке:

результат:

index.html: хитСогласовать кеш
index.js: хитСогласовать кеш
index.css: хитСогласовать кеш
doge.jpeg: хитСогласовать кеш
favicon.ico: хитСогласовать кеш

Результаты теста Opera 56.0:

Как показано на рисунке:

результат:

index.html: хитСогласовать кеш
index.js: хитСильный кеш
index.css: хитСильный кеш
doge.jpeg: хитСильный кеш
favicon.ico: запрос не был отправлен (используйте инструмент захвата пакетов для захвата пакетов, запрос отсутствует)

(6) Введите в адресной строке

Эта часть также разделена на возврат каретки с текущей вкладки и с другого URL-адреса.

Результаты теста Chrome 70:

[1] с другого URL перехода

эквивалентнопереход по ссылке на страницу

[2] Введите текущий URL

эквивалентнообновить

Результаты теста Firefox 63.0.1:

[1] с другого URL перехода

эквивалентнопереход по ссылке на страницу

[2] Введите текущий URL

эквивалентнопереход по ссылке на страницу

Результаты теста Opera 56.0:

[1] Перейти с другого URL

[2] Введите текущий URL

эквивалентнообновить

(6) Принудительное обновление

Результаты теста Chrome 70:

Как показано на рисунке:

результат:

INDEX.HTML: получить ресурсы со стороны сервера
index.js: доступ к ресурсам с сервера
index.css: получить ресурсы со стороны сервера
doge.jpeg: получить ресурсы со стороны сервера
favicon.ico: получить ресурсы со стороны сервера

Результаты теста Firefox 63.0.1:

Как показано на рисунке:

результат:

index.html: получить ресурсы со стороны сервера
index.js: получить ресурсы со стороны сервера
index.css: получить ресурсы со стороны сервера
doge.jpeg: получить ресурсы со стороны сервера
favicon.ico: получить ресурсы со стороны сервера
Результаты теста Opera 56.0:

Как показано на рисунке:

результат:

index.html: получить ресурсы со стороны сервера
index.js: получить ресурсы со стороны сервера
index.css: получить ресурсы со стороны сервера
doge.jpeg: получить ресурсы со стороны сервера
favicon.ico: получить ресурсы со стороны сервера

(7) Окончательное резюме:

Несмотря на то, что для проверки потребовалось столько усилий, окончательный вывод был лишь немного скорректирован:

Операции, связанные с браузером	Expires/Cache-Control	Last-Modified / Etag
переход по ссылке на страницу	эффективный	эффективный
новое окно	эффективный	эффективный
вперед назад	эффективный	эффективный
обновить	chrome opera html неверный файл ico недействителен, фф действителен	файл ico chrome opera недействителен, фф действителен
Введите в адресной строке	Введите текущий URL-адрес — chrome Opera с обновлением Введите текущий URL-адрес — ff — это то же самое, что и обновление. Введите другие URL-адреса — перейдите по ссылке на ту же страницу	Введите текущий URL-адрес — chrome Opera с обновлением Введите текущий URL-адрес — ff — это то же самое, что и обновление. Введите другие URL-адреса — перейдите по ссылке на ту же страницу
Принудительное обновление	неверный	неверный

6. Сводка связанных полей заголовка, связанных с HTTP

Изображение взято из:Механизмы веб-кэширования, серия 2 — механизмы кэширования для веб-браузеров

7. Полная блок-схема

Обобщает относительно полную блок-схему:

8. Некоторые недостатки статьи

(1) Распределенные системы связаны

Эта часть на самом деле не практиковалась, а только избранные мнения некоторых статей:

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

(2) Различные источники кеша связаны

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

На самом деле существует еще один механизм кэширования webkit, называемый pageCache, который здесь обсуждаться не будет:Кэш страницы WebKit I — основы

Chrome использует два кеша:disk cacheа такжеmemory cache

Следующие примеры предназначены только дляChrome

[1] disk cache

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

[2] memory cache

Получать ресурсы из памяти, и не нужно повторно загружать ресурсы при ожидании следующего доступа, а получать их прямо из памяти. Webkit уже поддерживает memoryCache.

[3] Как браузер различает их?

Условия испытаний такие же, как и в других испытаниях, описанных выше:

А. Текущий жизненный цикл вкладок не закончен

б) жизненный цикл текущей вкладки заканчивается

Базовое **"явление"** может быть получено:

Жизненный цикл кэша памяти примерно соответствует вкладкам вкладок.

The lifetime of an in-memory cache is attached to the lifetime of a render process, which roughly corresponds to a tab.

Вы можете обратиться к:developer.chrome - webRequest

в. Вопросы

Я видел аргумент:

В настоящее время ресурсы Webkit делятся на две категории:

основной ресурс

Основной источник: черезMainResourceLoaderЗагрузка, например HTML-страниц, элементов загрузки и т. д.
производный ресурс

Производный ресурс: , черезSubresourceLoaderЗагрузка, например, изображений или ссылок на скрипты, встроенных в HTML-страницы.

Хотя Webkit поддерживает memoryCache, он предназначен только для производных ресурсов.Ему соответствующий класс — CachedResource, который используется для сохранения исходных данных (таких как CSS, JS и т. д.) и данных декодированного изображения.

На этой картинке показано:

Вроде не применимо, полностью применимый css не работает с первого раза, загружается из кеша памяти,

Но через несколько раз, после прыжков назад и повторных прыжков (неопределенное количество раз):

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

9. Демонстрация для практики

Адрес демонстрационного склада

использованная литература:

HTTP-кеш MDN:

developer.Mozilla.org/this-cn/docs/…
Механизм веб-кэширования Series 2 Механизм кэширования веб-браузера:

woohoo.alloy team.com/2012/03/Веб…
W3 HTML spec chapter 5.2.2:

Я 3.org/TR/HTML4/eat…
Stackoverflow how-to-control-web-page-caching-across-all-browsers:

stackoverflow.com/questions/4…
Stackoverflow how-chrome-browser-determine-memory-cache-and-disk-cache:

stackoverflow.com/questions/4…
developer.chrome.comвеб-запрос:

developer.chrome.com/extensions/…