Автор оригинала: David Wong.
I. Предисловие
Кэширование можно назвать простым и эффективным методом оптимизации производительности. Отличная стратегия кэширования может сократить расстояние между запросами веб – страниц и уменьшить задержку. Поскольку кэшированные файлы можно использовать повторно, это также может снизить пропускную способность и нагрузку на сеть.
Для запроса данных его можно разделить на три этапа: инициирование сетевого запроса, внутренняя обработка и ответ браузера. Кэширование браузера может помочь нам оптимизировать производительность на первом и третьем этапах. Например, если вы используете кэширование напрямую вместо запроса, или если вы инициируете запрос, но данные, хранящиеся в серверной части, совпадают с данными, хранящимися в интерфейсной части, тогда нет необходимости возвращать данные обратно, что уменьшает данные ответа.
Далее мы рассмотрим механизм кэширования браузера с помощью расположения кэширования, стратегии кэширования и применения стратегии кэширования в реальных сценариях.
2. Расположение кэша
Существует четыре вида мест кэширования, и каждое из них имеет свой собственный приоритет. Когда кеши будут просматриваться последовательно и попаданий не будет, будет запрошена сеть.
Работник сферы услуг
Кэш памяти
Дисковый кэш
Принудительный кэш
1.Работник сферы Услуг
Service Worker – это отдельный поток, работающий за браузером, который можно использовать для реализации функции кэширования. В случае Service Worker транспортный протокол должен быть HTTPS. Поскольку перехват запросов задействован в Service Worker, для обеспечения безопасности необходимо использовать протокол HTTPS. Кэширование работника службы отличается от других встроенных механизмов кэширования в браузерах. Это позволяет нам контролировать, какие файлы кэшируются, как сопоставлять кэши, как читать кэши, и эти кэши являются постоянными. 。
Работник службы реализует функцию кэширования в три этапа: сначала ему необходимо зарегистрировать Работника службы, затем он может кэшировать необходимые файлы после прослушивания события установки. Затем, при следующем посещении пользователя, он может запросить, есть ли кэш или нет, перехватив запрос. Если есть кэш, он может идти прямо. Прочитайте файл кэша или запросите данные.
Когда работник службы не попадает в кэш, нам нужно вызвать функцию выборки, чтобы получить данные. То есть, если мы не попадем в кэш в Service Worker, мы будем искать данные в соответствии с приоритетом поиска в кэше. Но независимо от того, извлекаем ли мы данные из кэша памяти или из сетевых запросов, браузеры будут показывать то, что мы получаем от Работника службы.
2.Кэш памяти
Кэш памяти-это также кэш в памяти, который в основном содержит ресурсы, захваченные на текущей странице, такие как стиль, сценарии, изображения, загруженные на страницу. Данные в памяти должны считываться быстрее, чем с диска. Кэш памяти эффективен для чтения, но продолжительность кэша очень мала, и он будет освобожден с выпуском процесса. Как только мы закрываем страницу вкладки, кэш в памяти освобождается. 。
Итак, поскольку кэширование памяти настолько эффективно, можем ли мы сохранить все данные в памяти?
Это невозможно. Память компьютера должна быть намного меньше емкости жесткого диска, операционной системе необходимо тщательно рассчитать использование памяти, чтобы мы могли использовать меньше памяти.
Когда мы заходим на страницу и обновляем ее снова, мы видим, что много данных поступает из кэша памяти.
Одним из важных ресурсов кэширования в кэшировании памяти являются ресурсы, загружаемые инструкциями, связанными с предварительным загрузчиком, такими как <ссылка>. Хорошо известно, что инструкции предварительного загрузчика уже являются одним из распространенных средств оптимизации страниц. Он может анализировать файлы JS/CSS при запросе следующего ресурса в сети.
Обратите внимание, что Кэширование памяти не заботится о значении управления кэшированием заголовка HTTP-кэша при кэшировании ресурсов. В то же время сопоставление ресурсов заключается не только в сопоставлении URL-адресов, но и в проверке других функций, таких как Тип контента, ЯДРА и так далее. 。
В то же время сопоставление ресурсов заключается не только в сопоставлении URL-адресов, но и в проверке других функций, таких как Тип контента, ЯДРА и так далее. Кэш
Дисковый кэш – это кэш, хранящийся на жестком диске. Он читается медленно, но все можно сохранить на диске. Кэш памяти лучше, чем кэш памяти, с точки зрения емкости и своевременности хранения. 。
Дисковый кэш имеет самый большой охват из всех кэшей браузера. Он определит, какие ресурсы необходимо кэшировать, какие ресурсы можно использовать напрямую без запросов, а какие ресурсы истекли и должны быть повторно запрошены на основе полей в HTTP-обработчике. И даже в межсайтовых ситуациях, как только ресурсы с одним и тем же адресом будут кэшированы на жестком диске, они не будут запрашивать данные снова. Большинство кэшей поступает из дискового кэша. Ниже мы подробно обсудим поля кэширования в заголовках HTTP-протокола.
Какие файлы браузеры загружают в память? Какие из них выбрасываются на жесткий диск?
На этот счет в Интернете существуют разные мнения, но следующие мнения более надежны:
Для больших файлов велика вероятность того, что они не хранятся в памяти, и наоборот.
Если текущая система имеет высокую загрузку памяти, файлы должны быть сначала сохранены на жестком диске.
4.Нажмите Кэш
Push-кэш (push-кэш) – это содержимое HTTP/2. Он используется только тогда, когда ни один из трех кэшей не попал. Он существует только в сеансах, освобождается после завершения сеанса, а время кэширования невелико. В браузере Chrome у него есть всего около 5 минут, и он не строго выполняет инструкции по кэшированию в заголовках HTTP.
Push-кэш может найти очень мало информации в Китае, также потому, что HTTP/2 не популярен в Китае. Здесь мы рекомендуем прочитать статью Джейка Арчибальда HTTP/2 push сложнее, чем я думал. Несколько выводов в этой статье заключаются в следующем:
Все ресурсы можно перемещать и кэшировать, но браузеры Edge и Safari имеют относительно слабую поддержку.
Ресурсы, которые могут передавать данные без кэша и без хранилища
Как только соединение будет закрыто, кэш Push будет освобожден
Несколько страниц могут использовать одно и то же соединение HTTP/2, и также может использоваться один и тот же кэш Push. В основном это зависит от реализации браузеров. По соображениям производительности некоторые браузеры будут использовать одно и то же HTTP-соединение для одного и того же доменного имени, но с разными тегами вкладок.
Кэш в Push-кэше можно использовать только один раз
Браузеры могут отклонить отправку существующего ресурса
Вы можете перенаправлять ресурсы на другие доменные имена
Если ни один из четырех кэшей не попал, запросы могут быть сделаны только для получения ресурсов.
По соображениям производительности большинство интерфейсов должны выбирать хорошую стратегию кэширования. Как правило, стратегии кэширования браузера делятся на два вида: сильное кэширование и кэширование с согласованием, а стратегии кэширования реализуются путем установки заголовков HTTP. 。
Здесь я рекомендую круг интерфейсной разработки и общения: 1007317281, в котором собрано большое количество учебных материалов, все товары для галантереи, в котором обобщены разработки веб-сайтов мобильных приложений, css , html , webpack, Vue node angular и ресурсы для интервью. Предоставьте его каждому партнеру по работе с большими данными, чтобы облегчить самостоятельное обучение. Здесь не только место сбора Сяобая, но и онлайн-ответ Даниэля! Приглашаем младших и продвинутых малых партнеров присоединиться к группе, чтобы учиться, общаться и вместе добиваться прогресса! ___________
3. Анализ процесса кэширования
Браузер взаимодействует с сервером в режиме ответа, то есть браузер инициирует HTTP – запрос- сервер отвечает на запрос. Итак, как браузеры определяют, следует ли кэшировать ресурс или нет, и как его кэшировать? ? После того как браузер сначала инициирует запрос на сервер и получает результат запроса, он сохраняет результат запроса и идентификатор кэша в кэше браузера. Обработка кэша браузером определяется заголовком ответа, возвращаемым при запросе первого ресурса. 。 Конкретный процесс заключается в следующем:
Как мы можем видеть из рисунка выше:
Каждый раз, когда браузер инициирует запрос, он сначала находит результат запроса и идентификатор кэша в кэше браузера.
Каждый раз, когда браузер получает возвращенный результат запроса, он сохраняет результат и идентификатор кэша в кэше браузера.
Два приведенных выше вывода являются ключом к механизму кэширования браузера, который гарантирует, что кэш каждого запроса сохраняется и считывается. Пока мы понимаем правила кэширования браузера, все проблемы будут решены. Этот документ также будет подробно посвящен этому вопросу. Чтобы облегчить ваше понимание, мы разделяем процесс кэширования на две части: сильное кэширование и кэширование согласования, в соответствии с необходимостью повторного запуска HTTP-запросов на сервер.
IV. Сильный Коучинг
Надежный кэш: запросы на сервер не отправляются, а ресурсы считываются непосредственно из кэша. В сетевом параметре консоли chrome вы можете видеть, что запрос возвращает 200 кодов состояния, а размер отображается из кэша диска или из кэша памяти. Сильное кэширование может быть достигнуто путем настройки двух HTTP-заголовков: Expires и Cache-Control.
Сильное кэширование может быть достигнуто путем настройки двух HTTP-заголовков: Expires и Cache-Control.
Время истечения срока действия кэша, используемое для указания времени истечения ресурсов, является конкретным моментом времени на стороне сервера. 。 То есть-возраст + время запроса необходимо использовать в сочетании с Последним изменением. Истекает срок действия-это поле заголовка ответа веб-сервера, которое сообщает браузеру, что он может кэшировать данные непосредственно из браузера до истечения срока действия, когда он отвечает на HTTP-запросы, не требуя другого запроса.
Срок действия истекает по протоколу HTTP/1 и ограничен по местному времени. Если вы измените местное время, это может привести к аннулированию кэша. 。 Срок действия: Ср, 22 октября 2018 г. 08:41:00 по Гринвичу указывает, что ресурсы истекут после Ср, 22 октября 2018 г. 08:41:00 по Гринвичу и их необходимо запросить снова.
Срок действия: Ср, 22 октября 2018 г. 08:41:00 по Гринвичу указывает, что ресурсы истекут после Ср, 22 октября 2018 г. 08:41:00 по Гринвичу и их необходимо запросить снова.
В HTTP/1.1 Контроль кэша является наиболее важным правилом, которое в основном используется для управления веб-кэшированием. Например, когда Cache-Control:, сильный кэш поражается, если ресурс загружается снова в течение пяти минут после правильного времени возврата запроса (которое браузер также запишет).
Управление кэшем может быть задано в заголовке запроса или в заголовке ответа и может использовать комбинацию инструкций:
общественность : Все содержимое будет кэшировано (могут быть кэшированы как клиентские, так и прокси-серверы). 。 В частности, ответ может быть кэширован любым промежуточным узлом, таким как браузер < – proxy1 < – proxy2 < – Сервер. Промежуточный прокси-сервер может кэшировать ресурсы, например, запрашивать тот же прокси-сервер ресурса 1 непосредственно в браузере в следующий раз вместо запроса прокси-сервера 2.
частное : Все содержимое может быть кэшировано только клиентом Значение по умолчанию для управления кэшем. В частности, это означает, что промежуточный узел не разрешает кэширование. Для браузера < – – proxy1 < – – proxy2 < – Сервер, прокси честно отправит данные, возвращенные Сервером, в proxy1 без кэширования каких-либо данных. В следующий раз, когда браузер снова запросит, прокси выполнит хорошую работу по пересылке запросов, а не по защите кэшированных данных для себя.
содержимое кэширования без кэша клиента, независимо от того, использовать кэширование или нет, необходимо проверить путем согласования кэширования. Указывает, что вместо использования элемента управления кэшем Cache-Control для предварительной проверки вы используете Etag или поля последнего изменения для управления кэшем. Следует отметить, что название no-cache несколько вводит в заблуждение. Когда не настроен кэш, браузерам больше не нужно кэшировать данные, но при использовании кэшированных данных браузеры должны убедиться, что данные согласованы с сервером.
нет-магазин Все содержимое не будет кэшироваться, т. е. не будет обязательного кэширования или кэширования по согласованию.
максимальный возраст Максимальный возраст (xxx-числовое значение) указывает, что срок действия содержимого кэша истечет после ХХХ секунд
s-maxage (ins): Как и max-age, он работает только на прокси-серверах (таких как кэш CDN). Например, когда в течение этих 60 секунд, даже если содержимое CDN будет обновлено, браузеры не будут делать запросы. Максимальный возраст используется для общего кэширования, в то время как s-maxage используется для кэширования прокси. Возраст S-MAX имеет более высокий приоритет, чем максимальный возраст 。 Если существует возраст S-MAX, заголовок max-age и Expires перезаписываются.
макс-несвежий Максимальное допустимое время истечения срока годности. Инструкция max-stale указывает, что клиент готов получить ответ с истекшим сроком действия. Если указано значение max-stale, максимальное допустимое время составляет соответствующее количество секунд. Если не указано, браузер готов получить любой ответ о возрасте (возраст представляет собой разницу между временем, когда ответ был сгенерирован или подтвержден исходной станцией, и текущим временем).
min-свежесть Минимальная свежесть, которую можно переносить. Min-fresh указывает, что клиент не желает принимать ответ со свежестью, не превышающей сумму времени, установленного текущим возрастом, плюс min-fresh.
Из рисунка мы видим, что мы можем использовать несколько инструкций вместе для достижения нескольких целей. Например, мы хотим, чтобы ресурсы кэшировались, и можно кэшировать как клиентские, так и прокси-серверы, можно установить время истечения срока действия кэша и так далее.
3. Сравнение между истекшим сроком действия и контролем кэша
На самом деле, между ними нет большой разницы. Разница в том, что Expires является продуктом HTTP 1.0, а Cache-Control-продуктом HTTP 1.1. Если оба существуют одновременно, управление кэшем имеет более высокий приоритет, чем истекает. Срок действия может быть полезен в средах, которые не поддерживают HTTP 1.1. Таким образом, Expires является продуктом устаревания, и его существование на данном этапе-всего лишь способ обеспечения совместимости.
Строгое кэширование определяет, основано ли кэширование на том, были ли обновлены файлы на стороне сервера, независимо от того, были ли обновлены файлы на стороне сервера, что может привести к загрузке файлов, которые не являются последним содержимым на стороне сервера. Как мы узнаем, был ли обновлен контент на стороне сервера? ? На этом этапе нам нужно использовать стратегию кэширования переговоров.
V. Кэш переговоров
Кэширование согласования-это процесс принудительного сбоя кэширования, и браузеры инициируют запросы к серверам с идентификаторами кэширования. Сервер решает, использовать кэширование или нет, в соответствии с идентификаторами кэширования. Есть две основные ситуации. :
Кэш согласования вступает в силу и возвращает 304 без изменений
Сбой кэша согласования, Возврат 200 и Результат запроса
Кэширование согласования может быть достигнуто путем настройки двух HTTP-заголовков: Last-Modified и ETag.
Последнее изменение и Если оно было изменено- С
Когда браузер впервые обращается к ресурсу, сервер возвращает ресурс и добавляет заголовок последнего изменения в заголовок ответа. Значение-это время последнего изменения ресурса на сервере. Браузер кэширует файл и заголовок после его получения.
Последнее изменение: Пт, 22 июля 2016 01:47:00 GMT
В следующий раз, когда браузер запрашивает этот ресурс, браузер обнаруживает, что существует заголовок “Последнее изменение с момента”, а затем добавляет заголовок “если изменено с момента”, который является значением в “Последнее изменение”; сервер снова получает запрос ресурса в соответствии со значением в “Если изменено с момента” и временем последнего изменения ресурса на сервере. Если время if-Modified-Since меньше, чем время последнего изменения ресурса на сервере, это означает, что файл был обновлен, поэтому он возвращает новый файл ресурсов и 200.
Но у последнего изменения есть некоторые недостатки:
Если файл кэша открыт локально, даже если файл не изменен, это приведет к изменению последнего изменения, и сервер не сможет попасть в кэш для отправки того же ресурса.
Поскольку время последнего изменения может быть рассчитано только в секундах, если файл будет изменен за незаметное время, сервер подумает, что ресурс поврежден, и не вернет правильный ресурс.
Поскольку все еще существуют некоторые недостатки при принятии решения о том, следует ли кэшировать в зависимости от времени изменения файла, можем ли мы напрямую определить стратегию кэширования в зависимости от того, следует ли изменять содержимое файла? Таким образом, ETag и If-None-Совпадение появились в HTTP/1.1
2. ETag и если- Нет-Совпадение
Etag-это уникальный идентификатор (генерируемый сервером), который возвращает текущий файл ресурсов, когда сервер отвечает на запрос. Пока ресурс меняется, Etag будет восстанавливаться. 。 Когда браузер в следующий раз загрузит ресурс для отправки запроса на сервер, он поместит значение Etag, возвращенное в предыдущий раз, в поле Если-Нет-Совпадения в заголовке запроса. Серверу нужно только сравнить, если-Нет-Совпадение от клиента с ETag ресурса на своем собственном сервере, и тогда он может точно судить, соответствует ли ресурс клиенту. Была ли она изменена? Если сервер обнаружит, что ETag не соответствует должным образом, он отправит новые ресурсы (включая новый ETag) клиенту напрямую в виде обычного рюкзака GET 200; если ETag соответствует, он вернется непосредственно к 304, чтобы сообщить клиенту напрямую об использовании локального кэша.
3. Сравнение между этими двумя:
Во-первых, этап лучше, чем Последний-Изменен по точности.
Время последнего изменения указано в секундах. Если файл изменяется несколько раз в секунду, то их Последнее изменение фактически не отражает изменения, но Etag меняется каждый раз для обеспечения точности; если это сервер с балансировкой нагрузки, последнее изменение, сгенерированное каждым сервером, также может отличаться.
Во-вторых, с точки зрения производительности Etag уступает последней модификации. В конце концов, для последнего изменения требуется только время записи, в то время как Etag требует, чтобы сервер вычислял значение хэша с помощью алгоритма.
В-третьих, проверка сервера дает приоритет Etag по приоритету
6. Механизм кэширования
Принудительное кэширование имеет приоритет над согласованным кэшированием. Если истекает срок действия и управление кэшем вступает в силу, они используют кэширование напрямую. Если они не вступают в силу, они используют кэширование согласования (Последнее изменение/Если-Изменено-С тех пор и Etag/Если-Нет-Совпадают). Кэширование согласования определяется сервером, использовать кэширование или нет. Если кэширование согласования не удается, пожалуйста, сделайте это от имени сервера. Запрошенный кэш завершается неудачно, возвращает 200, возвращает ресурсы и идентификаторы кэша, а затем сохраняет их в кэше браузера; если он действителен, возвращает 304 и продолжает использовать кэш. 。 Блок-схема выглядит следующим образом:
Видя это, мне интересно, есть ли у вас такой вопрос: Если политика кэширования не установлена, что будет делать браузер?
В этом случае браузер использует эвристический алгоритм, обычно принимая дату в заголовке ответа минус 10% от последнего измененного значения в качестве времени кэширования.
7. Применение стратегии кэширования в реальных сценариях
1. Часто меняющиеся ресурсы
Управление кэшем: без кэша
Для часто изменяющихся ресурсов первым шагом является использование Cache-Control: no-cache, чтобы браузер каждый раз запрашивал сервер, а затем сотрудничал с ETag или Последним изменением, чтобы проверить действительность ресурсов. Хотя такой подход не может сэкономить количество запросов, он может значительно уменьшить размер данных ответа.
2. Изменение ресурсов
Управление кэшем:
Обычно при работе с такими ресурсами для их управления кэшем настраивается большой (один год), чтобы браузер запрашивал один и тот же URL-адрес после попадания в обязательный кэш. Чтобы решить проблему обновления, нам нужно добавить хэш, номер версии и другие динамические символы в имя файла (или путь), затем изменить динамические символы, чтобы достичь цели изменения ссылочного URL-адреса, чтобы предыдущий обязательный кэш был недействительным (на самом деле он не сразу недействителен, просто больше не используется).
Онлайн-библиотеки классов (такие как jquery-3.3.1.min.js, lodash.min.js, и т.д.) все принимают этот режим.
8. Влияние поведения пользователя на кэш браузера
Так называемое влияние поведения пользователя на кэширование браузера относится к тому, какую стратегию кэширования пользователи будут запускать при работе браузеров. Существует три основных типа:
Откройте страницу и введите адрес в адресную строку: узнайте, есть ли совпадение в кэше диска. Если да, используйте его; если нет, отправляйте сетевые запросы.
Обычное обновление (F5): Поскольку вкладка не закрыта, кэш памяти доступен и будет использоваться предпочтительно (при совпадении). Далее идет дисковый кэш.
Принудительное обновление (Ctrl + F5): Браузеры не используют кэширование, поэтому заголовки запросов отправляются с помощью Cache-control: no-cache (Pragma: no-cache для совместимости), и сервер возвращает 200 и последнее содержимое напрямую. эпилог
Спасибо, что посмотрели. Если есть какие-либо недостатки, вы можете критиковать и исправлять. Доступ к информации (iv), (iv) На этот раз мы рекомендуем бесплатную учебную группу, которая обобщает разработку веб-сайтов мобильных приложений, css, html, webpack, Vue node angular и ресурсы для интервью. Студенты, интересующиеся технологиями веб-разработки, могут присоединиться к группе Q: ??? 1007317281??? Независимо от того, являетесь ли вы Сяобаем или Дэниелом, я приветствую Дэниела в организации набора эффективных учебных маршрутов и учебных пособий, которыми он может поделиться с вами бесплатно, обновляя при этом видеоматериалы каждый день.
Наконец, я желаю вам всем успехов в учебе как можно скорее, получить удовлетворительное предложение, получить быстрое повышение по службе и повысить зарплату, а также достичь вершин своей жизни.
Оригинал: “https://developpaper.com/caching-mechanism-of-deep-resolution-browser/”