1. Введение
кеш браузераИменно браузер сохраняет запрошенные пользователем статические ресурсы (html, css, js) на локальный диск компьютера, при повторном обращении браузер может загрузить их прямо с локального, и нет необходимости перейти на сервер для запроса.
Но это не значит, что у кеша нет недостатков, если с ним не обращаться должным образом, это может привести к обновлению кода на стороне сервера, но пользователь по-прежнему остается старой страницей. Следовательно, интерфейс должен разработать разумную стратегию кэширования в соответствии с реальной ситуацией каждого ресурса в проекте.
Преимущества кэширования:
- Сократите избыточную передачу данных и снизьте расходы на сеть
- Снизьте нагрузку на сервер и улучшите производительность сайта
- Более быстрая загрузка веб-страниц на стороне клиента
2. Процесс кэширования
Вот обзор процесса кэширования ресурсов браузером.
Мы можем думать, что в браузере есть база данных, предназначенная для хранения правил кэширования, или можно сказать, что это таблица сопоставления, которая сопоставляет информацию о ресурсах кэша с адресом фактического файла на диске компьютера. (наверное имел ввиду, не серьезно)
А эту таблицу правил кэширования можно увидеть в браузере: chrome://cache/
Но после того, как я обновил браузер, он больше не работал, но я нашел chrome://net-internals/#httpCache, я не знаю, оригинальный ли это, и студенты, которые его знают, также могут оставить отзыв
Когда браузер запрашивает ресурс в первый раз
сказано вышеправила кэширования, заключается в том, чтобы объявить запрошенный ресурс, какую стратегию кэширования следует использовать? Как долго кэшировать? и т.п. . . И это правило возвращается в заголовке http.
Уведомление:Это заголовок ответа, а не заголовок запроса! ! !
На самом деле, заголовок запроса также будет содержать информацию о правиле, как будет показано ниже, чтобы различать запрос и ответ.
3. Правила кэширования
Надежный кеш и кеш согласования.
Сильный кеш
Просто и грубо, если ресурс не просрочен, брать кеш, а если истечет, запрашивать сервер.
Как судить о том, просрочен ли ресурс, то есть правила сильного кэширования?
В основном смотрите на значение Cache-Control в заголовках ответа, max-age=31xxxxxxx на рисунке, то есть в эти секунды кеш используется напрямую, и если оно превышается, сервер будет продолжать запрашиваться
Параллельно с Cache-Control есть еще один Expires, который в принципе убрали, так что не парьтесь по этому поводу
Несколько значений значения Cache-Control:
частный:Только браузеры могут кэшировать
публичный:Кэшировать могут как браузеры, так и прокси-серверы (для приватных и публичных интерфейс можно считать одинаковым, вдаваться в подробности не нужно)
max-age=xxxСрок годности (важно)
no-cacheНет сильного кэширования (важно)
no-storeНет сильного кеша, нет кеша согласования, в основном бесполезно, чем больше кеша, тем лучше.
Примечание: Есть также много правил.
Итак, для сильного кеширования в основном изучаем max-age и no-cache в Cache-Control
Таким образом, чтобы определить, попадает ли ресурс в сильный кэш, это зависит от значения Cache-Control в ответе.Если есть max-age=xxx секунд, значит попал в сильный кэш. Если значение Cache-Control равно no-cache, это означает, что сильный кэш не попал, и используется кэш согласования.
Сильный процесс кэширования:
Итак, шаги сильного кэширования уже ясны:
- При первом запросе a.js такой информации в таблице кеша нет, и запрашивается внутренний сервер напрямую.
- Внутренний сервер возвращает a.js, а элемент управления кешем в заголовке ответа http имеет значение max-age=xxxx, поэтому это строгое правило кеша, которое хранится в таблице кеша.
- Второй запрос a.js, таблица кеша имеет максимальный возраст, затем попадает в сильный кеш, а затем определяет, истек ли срок его действия, если он не истек, непосредственно считывает кешированный a.js, если срок его действия истек, затем выполняет шаг согласование кеша.
Уведомление
Здесь есть проблема, то есть max-age = 0, в чем разница между no-cache и no-cache.Я так понимаю, что no-cache напрямую не выполняет сильное кэширование, позволяя договориться о кэшировании, в то время как max-age=0 для сильного кэширования.Кэш, срок действия которого истек, необходимо обновить. . . Хотя на самом деле похоже, что эффект от обоих одинаков.
Woohoo. Я перевожу R.com/go ah/details/…
Согласовать кеш
Условия срабатывания:
- Значение Cache-Control равно no-cache (нет сильного кеша).
- Или истек срок действия max-age (сильный кеш, но всегда бывают случаи, когда он истекает)
То есть, несмотря ни на что, у вас может получиться оговоренный кеш (кроме no-store)
На этом рисунке, несмотря на сильное попадание в кеш, также присутствуют ETag и Last-Modified, которые являются соответствующими правилами для согласования кеша. Хотя предыдущий процесс сильного кеша к ним не имеет никакого отношения. . .
ETag: есть по одному для каждого файла, он будет меняться при изменении файла, может выглядеть как md5
Last-Modified: время модификации файла.
То есть каждый раз, когда http возвращаетresponseETag и Last-Modified в заголовке, в следующем запросеrequestЗаголовок принесет эти два (но имя изменилось на ETAG -> если-нет, если-match-Modificed -> Если-modified - с), логотип, который сервер приносит вам, текущий логотип ресурса Сделайте сравнение, а затем определите, изменился ли ресурс.
Этот процесс цикличен, то есть кэш-таблица будет обновлять правила после каждого успешного запроса.
1. При успешном выполнении n-го запроса:
2. Обновите значение ETag ресурса в таблице кеша.
3. n+1-й запрос:
Получите последний ETag ресурса из таблицы кеша и добавьте его в заголовок запроса. Обратите внимание, что имя было изменено на ETag --> If-None-Match.
картина:
Итак, краткое изложение шагов согласования кеша:
- При запросе ресурса локальный ETag пользователя ресурса одновременно передается на сервер, и сервер сравнивается с последним ресурсом.
- Если ресурс не изменился, возвращается 304, и браузер считывает локальный кеш.
- Если ресурс изменился, верните 200 и верните последний ресурс.
4. Отображение кэш-попаданий
- Получить новые ресурсы с сервера
- Нажмите на сильный кеш, и срок действия ресурса не истек, прочитайте локальный кеш напрямую
- Нажмите на согласованный кеш, и ресурс не изменился, прочитайте локальный кеш
Примечание: независимо от того, согласован ли кеш, он должен отправить запрос на сервер, однако, когда ресурс не изменяется, возвращается только информация заголовка, поэтому размер невелик, а когда ресурс изменяется, данные тела также возвращается, поэтому размер будет большим.
7. Другие
0. Как настроить правила кеша для ресурсов
Может быть конфигурация back-end сервера, либо она может быть настроена в nginx, а конфигурация nginx будет обновлена позже
1. Почему Etag?
Вы можете подумать, что использования Last-Modified достаточно, чтобы сообщить браузеру, достаточно ли свежа локальная кешированная копия, зачем вам Etag? Появление Etag в HTTP 1.1 (то есть ETag является новым, чтобы решить недостатки только If-Modified до этого) в основном для решения нескольких проблем, которые сложно решить с помощью Last-Modified:
-
Некоторые файлы могут периодически изменяться, но их содержимое не меняется (только время изменения модификации) В это время мы не хотим, чтобы клиент думал, что файл был изменен, и повторно ПОЛУЧАЛСЯ;
-
Некоторые файлы изменяются очень часто, например, если они изменяются в течение секунд (например, они изменяются N раз в течение 1 с), степень детализации, которую может проверить If-Modified-Since, находится на уровне s, и эту модификацию нельзя оценить. (или Говорят, что UNIX записи MTIME могут быть точными только до секунды);
-
Некоторые серверы не могут получить точное время последней модификации файла.
2. Разницу между сильным кешем и согласованным кешем можно представить в следующей таблице:
3. Влияние поведения пользователя на кеширование
То есть: F5 пропустит сильные правила кеша и перейдет непосредственно к согласованному кешу;;; Ctrl+F5, пропустит все правила кеша и повторно получит ресурсы, как в первом запросе.
4. Стратегия кэширования предметов
Например, в проекте vue скаффолдинг уже захешировал измененные файлы, поэтому общие файлы js и css нам не нужны для работы.
Для index.html нам нужно сделать обработку no store на nginx, то есть вообще не кэшировать index.html, а каждый раз запрашивать самый свежий html. . . Поскольку css и js будут внешне связаны в html, если мой html все еще кэшируется, старый css все равно будет связан, подумайте об этом? ? ?
6. Резюме
взять две картинки