тип кэша
Сильный кеш
определение:
Когда HTTP-запрос инициирован, он не будет делать запрос к серверу. Пока текущее время находится в пределах срока действия кеша, оно будет получено непосредственно из кеша клиента. Когда срок действия кеша истечет, сервер действительно хотите снова инициировать запрос на получение ресурса.
характерная черта
Откройте инструменты разработчика, и вы увидите в Сети, что код состояния, возвращаемый HTTP-запросом, равен 200, за которым следует из кеша памяти или из кеша диска.
Как установить сильный кеш:
Из-за обновления версии HTTP до HTTP1 указанное время истечения срока действия ресурса равно xpires. локальное время и время истечения срока действия кеша.Сравнение времени, если оно находится в пределах срока действия, данные кеша считываются напрямую с клиента, что означает, что вы можете принудительно аннулировать кеш, изменив локальное системное время.
Установите Cache-Control в заголовке запроса или ответа. Роль Cache-Control заключается в указании механизма кэширования запроса или ответа. Он является однонаправленным, то есть, если вы установите этот атрибут в заголовке запроса, он не Должен присутствовать в заголовках ответа. Он может быть установлен двумя способами, один устанавливается клиентом, а другой устанавливается на сервере после того, как сервер получает запрос.Необязательные значения двух методов настройки различны.MDNОбъясните следующим образом:
Подробнее о значении необязательных значений см.MDN: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control
Что делает сильное кэширование:
1) Для ресурсов на странице, которые потребляют пропускную способность и не часто изменяются, после загрузки они могут быть напрямую кэшированы в браузере, и пользователи могут использовать их снова, что может значительно сократить время ожидания загрузки и улучшить взаимодействие с пользователем;
2) Для пользователей со слабой сетью или нестабильной сетью сильный кеш может резервировать достаточную пропускную способность для запроса основного ресурса, чтобы предотвратить нормальное отображение страницы из-за тайм-аута запроса основного ресурса.
недостатки
Преимущество сильного кэширования заключается в том, что пока у клиента есть ресурсы в течение срока действия, он больше не будет получать ресурсы с сервера, и его преимущества также являются его недостатками.Если ресурсы сервера обновлены или исправлена ошибка, принудительное кэширование Если время слишком велико, это вызовет проблему обратного обновления информации о клиенте, что мне делать? Может ли быть такое решение: каждый раз, когда запрашивается ресурс, сначала спрашивать сервер: нужно ли мне снова получать ресурс? Сервер сравнивает кэшированные данные, и время кэширования не истекло, а затем говорит клиенту продолжать использовать сохраненные данные.Я ничего не изменил. Это решает как проблему кэша, так и проблему обновления. Хотя запрос по-прежнему отправляется каждый раз, количество запросов не уменьшается, но может уменьшить объем передаваемых данных. Есть ли такой план? имеют. как это называется? Согласовать кеш.
резюме
При сильном кэшировании, будь то ресурс, полученный от клиента, или обновленный ресурс, полученный с сервера, при успешном получении возвращаемый код состояния равен 200. Единственная разница заключается в том, есть ли кеш из памяти после кода состояния. .Или из дискового кеша.В течение срока действия только первый раз реально будет отправлять запрос на сервер для получения данных
Согласовать кеш
Как настроить согласование кеша:
Настройки в шапке ответа
etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT
etag: каждый файл уникален, и etag меняется при изменении ресурса. Это хэш файла. Цель его добавления — сравнить, согласованы ли клиент и сервер, и определить, есть ли обновление. Если они несогласованны, они считаются обновленными, а если они считаются неизменными. last-modified: время модификации файла с точностью до секунд.
То есть etag и last-modified в заголовке ответа возвращаются каждый раз, когда делается запрос, и эти два вносятся в заголовок запроса в следующем запросе Сервер сравнивает идентификаторы, которые вы передали, и затем судит изменился ли ресурс.Теперь, если он был изменен, он будет напрямую возвращать новый ресурс и обновлять etag и last-modified соответствующего заголовка ответа. Если ресурс не изменился, то etag и last-modified останутся без изменений.В это время для клиента каждый запрос должен быть согласован и кэширован, а именно:
Отправить запрос --> Проверить, истек ли срок действия ресурса --> Срок действия --> Запросить сервер --> Сервер сравнивает, действительно ли срок действия ресурса истек --> Не истек --> Вернуть код состояния 304 --> Клиент использует кешированный старый ресурс.
Это полный процесс согласования кеша.
Когда сервер обнаружит, что срок действия ресурса действительно истек, он выполнит следующий процесс:
Отправить запрос --> Проверить, истек ли срок действия ресурса --> Истек срок действия --> Запросить сервер --> Сервер сравнивает, действительно ли срок действия ресурса истек --> Срок действия --> Вернуть код состояния 200 --> Если клиент получает это впервые. Как и ресурсы, обратите внимание на max-age, etag, last-modified и т. д. в его управлении кешем.
Итак, краткое изложение шагов согласования кеша:
При запросе ресурса локальный etag пользователя ресурса одновременно доставляется на сервер, и сервер сравнивается с последним ресурсом. Если ресурс не изменился, возвращается 304, и браузер считывает локальный кеш. Если ресурс изменился, верните 200 и верните последний ресурс.
Зачем нужны etags?
Вы можете подумать, что использования last-modified достаточно, чтобы сообщить браузеру, достаточно ли свежа локальная кешированная копия, зачем вам etag? Появление etag в HTTP 1.1 (то есть etag является новым, чтобы решить недостатки только If-Modified до этого) в основном для решения нескольких проблем, которые трудно решить с помощью last-modified:
1) Некоторые файлы могут периодически изменяться, но их содержимое не меняется (только время модификации), в это время мы не хотим, чтобы клиент думал, что файл был изменен, и получал его снова;
2) Некоторые файлы изменяются очень часто, например, модификация в течение секунд (например, N раз в течение 1 с), степень детализации, которую можно проверить с помощью if-modified-since, измеряется секундами, и эту модификацию нельзя оценить (или в других слова, записи UNIX MTIME могут быть точными только до секунд);
3) Некоторые серверы не могут точно получить время последней модификации файла.
резюме
Первый успешный запрос на согласование кеша вернет код состояния 200. Далее, если файл не изменился, он вернет код состояния 304. Таким образом, вы сможете определить, обновляется ли ресурс повторно или из кеша оценивая значение кода состояния. Кроме того, поскольку last-modify и etag, определяющие допустимость ресурса, определяются сервером, кэш согласования не подвержен изменениям локального системного времени.
упражнение:
Прочитав вышеизложенное, вы можете подумать над следующими вопросами:
Свойства настройки сильного кеша и согласованного кеша различаются. Значит ли это, что два метода кеша могут быть установлены одновременно?
Если сильный кеш и согласованный кеш могут быть установлены одновременно, а также могут быть установлены действительные и недопустимые состояния каждого кеша, то в четырех комбинациях типа кеша и действительного состояния откуда клиент получает данные?
Добро пожаловать, чтобы оставить свой ответ в области комментариев
Нравится + Следуйте, позвольте себе бежать быстрее.