предисловие
Если вы все еще ищете собеседование при приеме на работу, взгляните. Статья, которую я прочитал сегодня рано утром, была опубликована @yeheying.
@ye Heying, фронтенд-инженер Tencent, крупный проект в области систем исследований и разработок и платформы электронной коммерции
Текст начинается здесь~
Обзор
Механизм кеша браузера также называется механизмом кеша HTTP.Механизм основан на идентификаторе кеша HTTP-сообщения.Поэтому, прежде чем анализировать механизм кеша браузера, давайте кратко представим сообщение HTTP с картинками и текстом.Там два типа текстов:
Сообщение HTTP-запроса (запроса), формат сообщения: строка запроса — заголовок HTTP (заголовок общей информации, заголовок запроса, заголовок объекта) — тело сообщения запроса (только POST имеет тело сообщения), как показано ниже.
Сообщение HTTP-ответа (Response), формат сообщения следующий: строка состояния — заголовок HTTP (заголовок общей информации, заголовок ответа, заголовок объекта) — тело сообщения ответа, как показано ниже.
Примечание. Заголовок общей информации относится к полям заголовка, поддерживаемым пакетами запроса и ответа, а именно Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade, Via; заголовок объекта представляет собой поле заголовка объекта информации объекта. , Это Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Etag, Expires, Last-Modified и extension-header. Здесь просто для удобства понимания заголовок общей информации, заголовок ответа/заголовка запроса и заголовок объекта классифицируются как заголовки HTTP.
Вышеупомянутые понятия здесь не объясняются, только краткое введение.Заинтересованная детская обувь может изучить самостоятельно.
Анализ процесса кэширования
Способ взаимодействия браузера с сервером — это режим ответа, то есть: браузер инициирует HTTP-запрос — сервер отвечает на запрос. Затем, после того как браузер инициирует запрос к серверу в первый раз и получит результат запроса, он решит, следует ли кэшировать результат в соответствии с идентификатором кеша HTTP-заголовка в ответном сообщении Процесс выглядит следующим образом:
С вышеуказанного графика мы можем знать:
-
Каждый раз, когда браузер инициирует запрос, он сначала ищет результат запроса и идентификатор кеша в кеше браузера.
-
Каждый раз, когда браузер получает возвращенный результат запроса, он сохраняет результат и идентификатор кеша в кеше браузера.
Вышеприведенные два вывода являются ключом к механизму кэширования браузера.Он обеспечивает хранение кеша и чтение каждого запроса.Пока мы понимаем правила использования кеша браузера, все проблемы будут решены.Эта статья также будет посвящена этому пункт подробно анализируется. Чтобы облегчить ваше понимание, здесь мы разделяем процесс кэширования на две части в зависимости от того, нужно ли вам повторно инициировать HTTP-запрос к серверу, а именно обязательное кэширование и согласованное кэширование.
Принудительно кэшировать
Принудительное кэширование — это процесс нахождения результата запроса в кеше браузера и принятия решения о том, использовать ли закешированный результат в соответствии с правилами кэширования результата.Существует три основных типа принудительного кэширования (процесс кэширования согласования не будет анализироваться для настоящее время) следующим образом:
Если результат кеша и идентификатор кеша не существуют, и кеш принудительно аннулируется, запрос делается непосредственно на сервер (так же, как и первый запрос), как показано на следующем рисунке:
Если результат кеша и идентификатор кеша существуют, но результат недействителен, и кеш вынужден быть недействительным, используется согласованный кеш (пока не анализируется), как показано на следующем рисунке.
Если кешированный результат и кешированный идентификатор существуют, а срок действия результата еще не истек, принудительно вступит в силу кеш и вернет результат напрямую, как показано на следующем рисунке.
Итак, каковы правила кэширования, обеспечивающие кэширование?
Когда браузер инициирует запрос к серверу, сервер помещает правило кэширования в HTTP-заголовок сообщения ответа HTTP и возвращает его браузеру вместе с результатом запроса. Control, приоритет Cache-Control Priority выше, чем Expires.
Expires
Expires — это поле, используемое HTTP/1.0 для управления кешированием веб-страницы.Его значение — время истечения кэша, возвращаемого сервером.То есть, когда запрос инициируется снова, если время клиента меньше, чем значение Expires , кэшированный результат будет использоваться напрямую.
Expires — это поле HTTP/1.0, но теперь браузеры используют HTTP/1.1 по умолчанию, поэтому кэширование веб-страниц по-прежнему контролируется Expires в HTTP/1.1?
В http/1.1 Expire заменен на cache-control, потому что принцип Expires control cache заключается в сравнении времени клиента и времени, возвращаемого клиентом, то если используется клиент и сервер (например, часовой пояс разный) У клиента и сервера какое-то время неточное), то принудительный кеш истечет сразу, так что существование кеша бессмысленно, как контроль Кэш-Контроля?
Cache-Control
В HTTP / 1.1 в, Cache-Control является наиболее важным правилом, в основном используется для управления кэшем страницы, основными значениями:
-
общедоступный: весь контент будет кэшироваться (кэшируется как клиент, так и прокси-сервер)
-
private: весь контент может кэшироваться только клиентом, значение по умолчанию для Cache-Control
-
no-cache: клиент кэширует содержимое, но необходимость использования кеша должна быть проверена путем согласования кеша.
-
no-store: Весь контент не будет кэшироваться, т. е. не используется ни принудительный кеш, ни согласованный кеш.
-
max-age=xxx (xxx — число): кешированное содержимое истечет через xxx секунд.
Далее, давайте посмотрим непосредственно на пример, как показано ниже:
Из приведенного выше примера мы можем знать, что:
-
Значение времени expires в ответном сообщении HTTP является абсолютным значением.
-
Cache-Control в ответном сообщении HTTP имеет значение max-age=600, что является относительным значением.
Поскольку приоритет Cache-Control выше, чем expires, кеш напрямую зависит от значения Cache-Control, а это означает, что если запрос будет инициирован снова в течение 600 секунд, кэшированный результат будет использоваться непосредственно для принудительного запуска кеша. вступить в силу.
Примечание. Cache-Control — лучший выбор, чем expires, когда невозможно определить, синхронизировано ли время клиента со временем сервера, поэтому, когда оба существуют, вступает в силу только Cache-Control.
Разобравшись с процессом принудительного кэширования, давайте подумаем об этом шире:
Где хранится кеш браузера и как браузер может определить, действует ли принудительный кеш?
Здесь мы пример запроса в блоге, код состояния представляет собой серые запросы, используя принудительное значение размера запроса кэширования, представляет позицию, соответствующую хранению буфера, соответственно, и из кэша памяти, от кэша памяти.
Так что же представляют из кеша памяти и из кеша диска? Когда вы будете использовать кеш диска и когда вы будете использовать кеш памяти?
из кэша памяти означает использование кэша в памяти, из дискового кэша означает использование кэша на жестком диске, а браузер читает кэш в порядке память -> диск.
Хотя вывод я прямо изложил, я полагаю, что многие этого не понимают.Тогда давайте разберем проблему чтения кеша подробнее.В качестве примера для анализа я все же возьму свой блог:
Посетите https://heyingye.github.io/ —> 200 —> закройте вкладку блога —> снова откройте https://heyingye.github.io/ —> 200 (из кеша диска) —> обновите —> 200 (из памяти кеш)
Процесс выглядит следующим образом:
-
Посетите https://heyingye.github.io/
-
Закрыть вкладку блога
-
Снова откройте https://heyingye.github.io/
-
обновить
from disk memory
Увидев, что кто-то, возможно, спросил здесь, когда последний шаг обновляется, нет ли одновременно из кеша диска и из кеша памяти?
Для этой проблемы нам нужно понять кеш памяти (из кеша памяти) и кеш жесткого диска (из кеша диска) следующим образом:
-
Кэш памяти (из кеша памяти): Кэш памяти имеет две характеристики, а именно быстрое чтение и своевременность:
-
Быстрое чтение: кэш памяти будет напрямую хранить компиляционные и анализируемые файлы в памяти процесса, занимая определенный ресурс памяти процесса, чтобы облегчить быстрое чтение в следующем прогоне.
-
Время: как только процесс будет выключен, память процесса будет очищена.
-
Кэш жесткого диска (из кеша диска): Кэш жесткого диска напрямую записывает кеш в файл жесткого диска.Чтение кеша требует операций ввода-вывода с файлами жесткого диска, хранящимися в кеше, а затем повторно анализирует содержимое кеша, который сложен для чтения и быстр. Медленнее, чем memcache.
В браузере браузер будет напрямую хранить js, изображения и другие файлы в кеше памяти после синтаксического анализа и выполнения, поэтому при обновлении страницы ее нужно только прочитать непосредственно из кеша памяти (из кеша памяти); в то время как файл css будет храниться в кеше памяти, в файле жесткого диска, поэтому каждый раз при рендеринге страницы кеш нужно считывать с жесткого диска (из дискового кеша).
Согласовать кеш
Согласование кэширования — это процесс, в котором браузер инициирует запрос к серверу с идентификатором кеша после принудительного отказа кеша, и сервер решает, использовать ли кеш на основе идентификатора кеша. Есть два основных случая:
Кэш согласования вступает в силу и возвращает 304, как показано ниже.
Кэш-память согласования недействителен, возвращая 200 и результат запроса, следующим образом
Точно так же идентификатор кэша согласования также возвращается в браузер вместе с результатом запроса в HTTP-заголовке ответного сообщения.Поля, управляющие кэшем согласования: Last-Modified/If-Modified-Since и Etag/If -None-Match , где Etag/If-None-Match имеет более высокий приоритет, чем Last-Modified/If-Modified-Since.
Last-Modified / If-Modified-Since
Last-Modified — это время последнего изменения файла ресурсов на сервере, когда сервер ответил на запрос следующим образом.
If-Modified-Since означает, что когда клиент снова инициирует запрос, он несет значение Last-Modified, возвращенное последним запросом, и значение этого поля сообщает серверу время последнего изменения ресурса, возвращенного последним запросом. Когда сервер получает запрос и обнаруживает, что заголовок запроса содержит поле If-Modified-Since, он сравнивает значение поля If-Modified-Since со временем последнего изменения ресурса на сервере. время ресурса сервера больше, чем Если значение поля Modified-Since, ресурс будет возвращен снова, а код состояния равен 200, в противном случае будет возвращено 304, что означает, что ресурс не был обновлен, и файл кэша можно продолжать использовать следующим образом.
Etag / If-None-Match
Etag — это уникальный идентификатор (генерируемый сервером) текущего файла ресурсов, который возвращается, когда сервер отвечает на запрос следующим образом.
If-None-Match означает, что когда клиент снова инициирует запрос, он несет значение Etag уникального идентификатора, возвращенное последним запросом, и значение этого поля сообщает серверу значение уникального идентификатора, возвращенное последним запросом ресурса. После того, как сервер получит запрос и обнаружит, что заголовок запроса содержит If-None-Match, он сравнит значение поля If-None-Match со значением Etag ресурса на сервере. 304, что указывает на то, что ресурс не обновлен. , продолжайте использовать файл кеша; если он несовместим, вернитесь к файлу ресурсов, код состояния 200, как показано ниже.
Примечание: Etag/If-None-Match имеет более высокий приоритет, чем Last-Modified/If-Modified-Since, и только Etag/If-None-Match вступают в силу, если они существуют одновременно.
Суммировать
Обязательное кэширование имеет приоритет над согласованным кэшированием.Если действует обязательное кэширование (Expires и Cache-Control), кеш используется напрямую.Если оно не действует, выполняется согласованное кэширование (Last-Modified / If-Modified-Since и Etag /If-None-Match) , кэш согласования определяется сервером, следует ли использовать кеш. Если кеш согласования недействителен, кеш, представляющий запрос, недействителен, а результат запроса повторно загружается и сохраняется в браузере. cache, если он валиден, возвращает 304 и продолжает использовать кеш.Основной процесс выглядит следующим образом:
Наконец, я рекомендую для вас
【Ошибка 903】Анализ механизма кэширования браузера
[Ошибка 887] Краткий обзор механизма кэширования браузера
Об авторе этой статьи: @ye Heying Исходный текст: https://heyingye.github.io/2018/04/16/ Тщательно изучите механизм кэширования браузера/