0 Предисловие

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

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

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

1 система веб-кэширования

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

В этой статье основное внимание уделяется кэшированному содержимому в красном поле выше.

2 Знайте кеш браузера

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

Эти файлы, сохраняемые браузером, называются кэшами (а не файлами cookie или Localstorage).

Итак, как узнать, читает ли браузер кеш или запрашивает сервер напрямую? В качестве примера возьмем следующий веб-сайт:

После открытия сайта в первый раз, если снова обновить страницу. Вы обнаружите, что среди множества ресурсов, загружаемых браузером, некоторые размеры имеют определенные значения, но все же есть некоторые запросы, такие как изображения, файлы css и js, которые не отображают размер файла, а отображаютfrom dis cacheилиfrom memory cacheшрифт. Это означает, что ресурс считывается напрямую с локального жесткого диска или из памяти браузера без запроса сервера.

Есть как минимум два очевидных преимущества включения кэширования в браузере:(1) сократить время загрузки страницы, (2) уменьшить нагрузку на сервер;

Использует ли браузер кеш и как долго он кешируется, контролируется сервером.. Если быть точным, когда браузер запрашивает веб-страницу (или другой ресурс),Некоторые поля в разделе «Заголовок ответа» ответа, отправленного обратно сервером, содержат ключевую информацию о кэше.. Давайте посмотрим на поля заголовка, связанные с кэшированием в HTTP-сообщении:

Общие поля заголовка(то есть поля, которые можно использовать как в пакетах запроса, так и в пакетах ответа)
поля заголовка запроса
поля заголовка ответа
поле заголовка сущности

3 Механизм кэширования браузера

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

1) Когда браузер загружает ресурс, он сначала оценивает, попадает ли он в сильный кеш, на основе некоторых http-заголовков ресурса.При попадании сильного кеша браузер считывает ресурс напрямую из собственного кеша и не отправляет запрос на сервер. Например: файл css, если конфигурация кеша файла css попадает в сильный кеш, когда браузер загружает веб-страницу, на которой он находится, браузер напрямую загружает css из кеша, и даже запрос не будет отправлен на сервер, на котором находится веб-страница. ;

2) При не попадании сильного кеша браузер обязательно отправит запрос на сервер,Проверьте, попадает ли ресурс в согласованный кеш через сервер на основе других заголовков HTTP ресурса., если кеш согласования сработает, сервер вернет запрос,Но не вернет данные этого ресурса, а скажет клиенту, что ресурс можно загрузить прямо из кеша, поэтому браузер будет загружать ресурс из собственного кеша;

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

4) Когда согласованный кеш не срабатывает, браузер загружает данные ресурсов непосредственно с сервера.

3.1 Сильный кеш: Expires&Cache-Control

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

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

Expires — это заголовок, предложенный HTTP 1.0, который представляет время истечения ресурсов, описывает абсолютное время, которое возвращается сервером и представляется строкой в формате GMT., например: Expires:Thu, 31 Dec 2037 23:55:55 GMT, файл, содержащий тег заголовка Expires, означает, что браузер полностью контролирует файловый кеш.

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

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

Браузер запрашивает ресурс у сервера в первый раз. Когда сервер возвращает ресурс, он добавляет заголовок Expires к заголовку ответа, например:
После того, как браузер получит ресурс, он будет кэшировать ресурс вместе со всеми заголовками ответа (поэтому заголовки, возвращаемые запросом на попадание в кэш, не от сервера, а из ранее кэшированных заголовков);
Когда браузер снова запрашивает этот ресурс,Сначала ищем из кеша, после нахождения ресурса вытаскиваем его Expires и сравниваем с текущим временем запроса, если время запроса раньше указанного в Expires времени, можно попасть в кеш, иначе не сработает;
Если кеш не попал, когда браузер загружает ресурс напрямую с сервера, заголовок Expires будет обновляться при перезагрузке;

Expires — это старый надежный заголовок управления кешем,Поскольку это абсолютное время, возвращаемое сервером, когда разница между временем сервера и временем клиента велика, управление кешем подвержено проблемам.Например: произвольное изменение времени клиента может повлиять на результат попадания в кеш..所以在HTTP 1.1的时候，提出了一个新的header，Это Cache-Control, которое является относительным временем. При настройке кэша он выражается в секундах и выражается в виде численного значения., например: Cache-Control:max-age=315360000, его принцип кэширования:

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

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

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

Дополнительно можно указать для Cache-Controlpublicилиprivateотметка.Если используется private, это означает, что ресурс принадлежит только конечному пользователю, делающему запрос, что предотвращает кэширование таких ресурсов промежуточными серверами (например, прокси-серверами).. Для файлов, содержащих личную информацию пользователя (например, HTML-документ, содержащий имена пользователей), может быть установлено значение private.С одной стороны, эти кэши не имеют значения для других пользователей, а с другой стороны, пользователи могут не захотеть, чтобы связанные файлы были хранятся в ненадежных местах на сервере. Следует отметить, что private не делает кэш более безопасным, он также будет передаваться на промежуточный сервер (если у сайта высокие требования к безопасности передачи, следует использовать меры безопасности транспортного уровня).Для общедоступных всем серверам разрешено кэшировать ресурс.. Как правило, для ресурсов, доступных всем (таких как логотипы веб-сайтов, изображения, скрипты и т. д.),Для Cache-Control разумно по умолчанию использовать общедоступный.

3.2 Кэш согласования: Last-Modified&Etag

Когда запрос браузера на ресурс не попадает в сильный кеш,На сервер будет отправлен запрос, чтобы проверить, попал ли кеш согласования.Если кеш согласования попал, статус HTTP, возвращаемый ответом на запрос, равен 304, и будет отображаться строка «Не изменено».Например, если вы открываете домашнюю страницу JD.com, нажимаете F12, чтобы открыть инструменты разработчика, затем нажимаете F5, чтобы обновить страницу, проверяете сеть, и вы видите, что многие запросы попадают в кеш согласования:

Просмотр заголовка ответа одного запроса,Вы также можете увидеть код состояния 304 и строку Not Modified. Пока вы видите это, это означает, что ресурс попадает в кеш согласования, а затем загружается из кеша клиента., вместо последнего ресурса сервера:

Кэш согласования управляется двумя парами заголовков [Last-Modified, If-Modified-Since] и [ETag, If-None-Match]..

Принцип управления кэшем [Last-Modified, If-Modified-Since] следующий::

Браузер запрашивает ресурс у сервера в первый раз. Когда сервер возвращает ресурс,В заголовок ответа добавить заголовок Last-Modified, в котором указано время последней модификации ресурса на сервере:
Когда браузер снова запрашивает этот ресурс с сервера,Добавьте заголовок If-Modified-Since в заголовок запроса., значением этого заголовка является значение Last-Modified, возвращенное в последнем запросе:
Когда сервер снова получает запрос ресурсов,Определите, изменился ли ресурс в соответствии с параметром If-Modified-Since, переданным браузером, и временем последней модификации ресурса на сервере., если нет изменений, он вернет 304 Not Modified, но содержимое ресурса не будет возвращено; если есть изменение, содержимое ресурса будет возвращено в обычном режиме.Когда сервер возвращает ответ 304 Not Modified, заголовок Last-Modified не будет добавлен в заголовок ответа., так как ресурс не изменился, то и Last-Modified не изменится.Это заголовок ответа, когда сервер возвращает 304:
Получив ответ 304, браузер загружает ресурс из кеша.
Если согласованный кеш отсутствует, и браузер загружает ресурс напрямую с сервера,Заголовок Last-Modified будет обновлен при перезагрузке, при следующем запросеIf-Modified-Since активирует возвращаемое последнее измененное значение..

[Last-Modified, If-Modified-Since] — это заголовки, возвращаемые по времени сервера.Без корректировки времени сервера и вмешательства в кэш клиента эти два заголовка очень надежно работают вместе для управления кэшем согласования, но иногда ресурсы на сервере действительно меняются, но время последней модификации не меняется., и эту проблему нелегко обнаружить, и когда это произойдет, это повлияет на надежность кэша согласования.Таким образом, есть еще одна пара заголовков для управления кешем согласования: [ETag, If-None-Match].. Способ управления их кешем:

Браузер запрашивает ресурс с сервера в первый раз,Когда сервер возвращает этот ресурс, он добавляет заголовок ETag к заголовку ответа., этот заголовок представляет собой уникальный идентификатор, сгенерированный сервером на основе текущего запрошенного ресурса,Этот уникальный идентификатор представляет собой строку, которая отличается до тех пор, пока изменяется ресурс., не имеет ничего общего со временем последней модификации, поэтому может быть хорошим дополнением к задаче Last-Modified:
Когда браузер снова запрашивает этот ресурс с сервера,Добавьте заголовок If-None-Match в заголовок запроса., значение этого заголовка — это значение ETag, возвращенное в последнем запросе:
Когда сервер снова получает запрос ресурсов,Согласно браузеру передать If-None-Match, а затем сгенерировать новый ETag в соответствии с ресурсом, если два значения совпадают, значит, ресурс не изменился, в противном случае изменение есть, если изменений нет, вернет 304 Not Modified, но содержимое ресурса не будет возвращено, если есть изменение, содержимое ресурса будет возвращено в обычном режиме. В отличие от Last-Modified, когда сервер возвращает ответ 304 Not Modified,Поскольку ETag был перегенерирован, ETag также будет возвращен в заголовке ответа., даже если этот ETag не отличается от предыдущего:
Получив ответ 304, браузер загружает ресурс из кеша.

Etag очень похож на Last-Modified, и оба используются для определения параметра, чтобы решить, следует ли включать кэширование.Однако ETag также имеет свои преимущества перед Last-Modified, который может более точно определить, было ли изменено содержимое файла., так что это более практично в практической эксплуатации.

Кэш согласования отличается от сильного кеша тем, что сильный кеш не отправляет запросы на сервер.Поэтому иногда ресурс обновляется, а браузер еще не знает об этом, но кеш согласования отправит запрос на сервер., поэтому обновляется ли ресурс, сервер должен знать. Большинство веб-серверов включают кеш согласования по умолчанию и одновременно включают [Last-Modified, If-Modified-Since] и [ETag, If-None-Match], например apache:

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

[Last-Modified, If-Modified-Since] и [ETag, If-None-Match] обычно включаются одновременно, это связано с ненадежностью Last-Modified. Есть один сценарий, о котором следует знать:

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

Распределенные системы должны стараться как можно чаще закрывать ETag (ETag, генерируемые каждой машиной, будут разными).;

Например, для запроса ресурса страницы Jingdong возвращенный заголовок ответа имеет значение Last-Modified и отсутствует ETag:

Кэш согласования необходимо использовать с сильным кешем.На приведенном выше снимке экрана, в дополнение к заголовку Last-Modified, есть также связанные заголовки для сильного кеша.Потому что нет смысла обсуждать кэширование без включения сильного кэширования..

4 Процесс оценки кеша

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

5 Другие ссылки

Говоря о веб-кэше
Говоря о механизме кеширования браузера http