Шаги кэширования браузера
1) Когда браузер загружает ресурс, он сначала судит, попал ли он в сильный кеш по некоторым http-заголовкам ресурса. сервер. Например, для файла css, если конфигурация кеша файла css попадает в сильный кеш, когда браузер загружает веб-страницу, на которой он находится, браузер напрямую загружает css из кеша, и даже запрос не будет отправляется на сервер, где находится веб-страница;
2) Когда сильный кеш не попадает, браузер обязательно отправит запрос на сервер, и сервер проверит, попадает ли ресурс в согласованный кеш в соответствии с другими HTTP-заголовками ресурса. вернет запрос, но не вернет данные этого ресурса, а сообщит клиенту, что ресурс можно загрузить прямо из кеша, поэтому браузер загрузит ресурс из собственного кеша;
3) Общим моментом между сильным кешем и кешем согласования является то, что при попадании ресурс загружается из клиентского кеша вместо данных ресурса с сервера, отличие состоит в том, что сильный кеш не отправляет запросы на сервер, а кэш согласования будет отправлять запросы на сервер.
4) Когда согласованный кеш не срабатывает, браузер загружает данные ресурсов непосредственно с сервера.
Пример: Возьмем распространенный запрос на стиль CSS.
первый запрос
Обычно сервер отправляет эти 4 поля, это могут быть все 4 поля или ни одно из них. Здесь мы в основном объясняем ситуацию, когда существуют все 4 поля.
второй запрос
Front-end: сначала браузер проверит Cache-Control и Expires.Если есть Cache-Control, будет стандарт.Если время ожидания истекло, он отправит запрос на back-end с If-Modified-Since , Если-Нет-совпадения.
Предыстория: после того, как внутренний сервер получит запрос, он сравнит эти два поля, а также будет использовать If-None-Match в качестве стандарта. сравнение Позже обнаруживается, что срок действия файла не истек, то есть Etag не изменился, или Last-Modified согласуется с If-Modified-Since (только если If-Modified-Since существует). Если он изменился, будет отправлен новый файл, в противном случае будет возвращено сразу 304.
Классификация кэша браузера
Сильный кеш
Когда клиент запрашивает у сервера ресурс в первый раз, сервер отбрасывает запрошенный клиентом ресурс и говорит клиенту сохранить ресурс локально, и если ресурс все еще нужен до определенного момента в будущем, он можно получить напрямую с локального, не запрашивая сервер. Ресурсы, кэшированные таким образом, называются сильными кэшами. Сильное кэширование контролируется полями Expires (поле заголовка объекта) или Cache-Control (поле общего заголовка) в заголовке возврата HTTP, которые используются для указания времени кэширования ресурсов. Сервер информирует клиента о времени истечения срока действия кеша и максимальном жизненном цикле кеша ресурса через эти два поля заголовка. После того, как клиент узнает время истечения срока действия кеша и максимальный жизненный цикл ресурса, он может определить, может ли он получить ресурс напрямую из кеша браузера, не устанавливая связь с сервером.
При попадании в сильный кеш браузер также получит ответ status = 200. В Chrome ресурс, возвращенный с сервера, или ресурс, полученный из сильного кеша, можно отличить по размеру.
Expires
Это поле является спецификацией http1.0, а значение представляет собой строку времени в формате абсолютного времени по Гринвичу, которая представляет время истечения срока действия кэшированного ресурса. До этого момента времени происходит попадание в кэш. Процесс выглядит следующим образом:
Когда браузер запрашивает ресурс у сервера в первый раз, сервер добавит Expires в соответствующий заголовок при возврате ресурса, как показано на рисунке: буфер обмена.png
После того, как браузер получит ресурс, он кэширует ресурс вместе с заголовком ответа;
Когда браузер снова запрашивает ресурс, он сначала находит ресурс в кеше, а затем сравнивает время Expires с текущим временем запроса.Если время Expires позже времени запроса текущего браузера, это означает, что кеш не просрочено, то есть попадание в кеш;
Если текущее время запроса позже, чем Expires, это означает, что срок действия кеша истек, то есть кеш не попал, и браузер отправит запрос на сервер для подачи заявки на ресурс.
Недостатки: точка времени Expires, возвращаемая сервером, является временем на сервере, которое может иметь разницу во времени с клиентом.Если разница во времени слишком велика, кэш может быть перепутан.
Cache-Control:max-age
Cache-Control имеет много свойств, и разные свойства представляют разные значения.
частный: клиент может кэшировать
общедоступный: и клиенты, и прокси-серверы могут кэшировать
max-age=t: кешированный контент истечет через t секунд
No-Cache: Cache Consultation требуется для проверки кэша данных
no-store: Весь контент не будет кэшироваться.
Это поле является спецификацией http1.1. Strong cache использует значение max-age для определения максимального жизненного цикла кэшированных ресурсов. Его значение указано в секундах. Cache-Control: max-age=3600 означает, что эффективное время кэширования ресурсов составляет 1 час. , то есть запросы в течение одного часа с момента первого получения ресурса считаются способными попасть в сильный кэш. Процесс выглядит следующим образом:
Когда браузер запрашивает ресурс у сервера в первый раз, когда сервер возвращает ресурс, он добавит Cache-Control:max-age=XXXXXXXX в соответствующий заголовок, как показано на рисунке: буфер обмена.png
После того, как браузер получает ресурс, он кэширует его вместе с заголовком ответа;
Когда браузер снова запрашивает тот же ресурс с сервера, он сначала находит ресурс в кеше, получает дату (время отклика первого возврата ресурса) и максимальный возраст, а также вычисляет период действия (дата + макс. age), а затем Затем сравните его со временем запроса браузера и, наконец, оцените, попадает ли он в кеш (логика такая же, как у Expires);
Если кеш не попал, браузер запрашивает ресурс непосредственно с сервера, и Cache-Control будет обновляться при получении ресурса с сервера.
Cache-Control описывает относительное время и использует местное время для расчета срока действия ресурсов, поэтому он более надежен, чем Expires.
Вы можете использовать только один из этих двух заголовков или использовать их вместе. Cache-Control имеет преимущественную силу при совместном использовании.
Согласовать кеш
Когда клиент запрашивает у сервера ресурс в первый раз, сервер возвращает запрошенный ресурс клиенту, и в то же время клиенту также возвращается некоторая информация о ресурсе (сводка файла или время последней модификации). , сообщая клиенту кэшировать этот ресурс локально. Когда клиенту понадобится этот ресурс в следующий раз, он отправляет запрос и соответствующую информацию (сводку файла или время последнего изменения) на сервер, и сервер определяет, нужно ли обновлять кэшированный клиентом ресурс: если он не нуждается для обновления, просто скажите клиенту получить ресурс локального кэша; если его необходимо обновить, верните последний ресурс вместе с соответствующей информацией клиенту. Когда сильный кеш промахивается, браузер отправит запрос на сервер, и сервер проверит, сработал ли кеш согласования. будет отображаться, и браузер получит ответ. После этого он будет загружен из кеша.
Кэш согласования управляется двумя парами заголовков [Last-Modified, If-Modified-Since] и [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 соответствует времени последней модификации, кеш попадает, сервер возвращает 304, а браузер возвращает с сервера 304. Ресурс получается из кеша, если кеш не попал, сервер одновременно возвращает ресурс, и Last-Modified кэшированного ресурса браузера будет обновляться.
ETag & If-None-Match
В некоторых случаях недостаточно проверить, изменился ли ресурс, просто определив дату последнего изменения:
Некоторые ресурсы периодически переписываются, но фактическое содержание ресурсов не меняется;
Измененная информация не важна, например, комментарии и т.п.;
Last-Modified не может иметь точность до миллисекунд, но частота обновления некоторых ресурсов иногда меньше одной секунды.
Чтобы решить эти проблемы, http позволяет пользователям маркировать ресурсы (ETag), чтобы различать, является ли содержимое ресурсов, полученных двумя идентичными путями, согласованным. Обычно криптографическая хеш-функция, такая как MD5, используется для кодирования ресурса для получения метки (сильный валидатор) или с помощью номера версии, например, W/"v1.0" (W/ указывает на слабый валидатор).
ETag — соответствующее поле заголовка, представляющее уникальный идентификатор содержимого ресурса, который возвращается с ответом сервера;
Если-None-Match является полем заголовка запроса, сервер определяет, был ли ресурс изменен между двумя запросами, сравнивая If-None-Match в заголовке запроса с ETag текущего ресурса, чтобы определить, был ли ресурс изменен. изменяется между двумя запросами. Согласование кеша, браузер получает ресурс из кеша, если есть какие-либо изменения, сервер возвращает ресурс и возвращает новый ETag. Процесс выглядит следующим образом:
-
Когда сервер получает запрос ресурса от браузера в первый раз, он добавит ETag в заголовки ответа.Этот ETag представляет собой уникальный идентификатор, сгенерированный на основе ресурса.Этот уникальный идентификатор представляет собой строку, если сервер считает что ресурс изменился и должен быть предоставлен Для новых ресурсов ETag должен измениться. Браузер кэширует ресурс вместе с ETag.
-
Когда браузер снова отправляет запрос ресурса на сервер, он добавит If-None-Match в заголовки запроса, что является значением ETag, возвращенным сервером в первый раз;
-
После того, как сервер получит запрос ресурса, он пересчитает и сгенерирует соответствующий ETag в соответствии с запрошенным ресурсом, а затем сравнит его с If-None-Match. Если результаты сравнения непротиворечивы, кеш срабатывает. Если они несовместимы, кеш пропускается. Ресурс возвращается, и в браузер отправляется новый ETag.
Согласовать управление кешем [Last-Modified , If-Modified-Since] и [ETag , If-None-Match] обычно включаются одновременно, это необходимо для устранения ненадежной ситуации last-Modified.
Решение для внешнего развертывания
Как вы, возможно, уже знаете, существует всего несколько способов, которыми компании управляют статическими ресурсами и кэшированием. 1 Добавьте номер версии v=1.111 после имени статического ресурса.
2 Чтобы точно определить, был ли файл изменен, измените следующий номер версии на сводную информацию о файле (значение, в основном сгенерированное в соответствии с содержимым файла).
3 Объедините имя файла ресурсов непосредственно с именем файла, используя абстрактный файл или фиксированную строку плюс абстрактный файл.
(Пасхальное яйцо: интересно, я нашел несколько веб-сайтов TX и обнаружил, что не все веб-сайты используют последний метод. Я думаю, что технологии должны использоваться для достижения совершенства, но реализация все еще достигается людьми, в конце концов, людям нравится любить быть ленивым.)
Так вот вопрос? В чем разница между тремя вышеуказанными методами? Почему в конечном итоге он превратился в третий путь?
1 В первом методе необходимо сохранить номер версии.Если в файле несколько ресурсов, номер версии неизмененного файла ресурсов также будет изменен, что приведет к ненужной загрузке ресурсов. (Конечно, если вам нужно добавить метку времени или тому подобное, она больше не будет принадлежать первому диапазону)
2 Вторым способом можно узнать, какой именно файл был изменен. Это требует перезагрузки клиента. Но будут и некоторые проблемы. Как правило, компании, которые могут использовать второй способ, могут естественным образом представить веб-трафик (небольшие компании, пожалуйста, игнорируйте их автоматически). Затем, когда версия будет выпущена, будет два типа файлов, которые необходимо выпустить: 1) html файл со ссылками на файлы ресурсов 2) Файл ресурсов
Тогда порядок публикации двух вышеуказанных файлов становится проблемой.
Если вы сначала отправляете файл html: Затем это приведет к перезагрузке ресурсов, но все равно не сможет получить доступ к последним функциям. (Ведь файл ресурсов действительно не обновлялся.) Если структура Html-страницы была обновлена, но загружены старые ресурсы, это, скорее всего, вызовет путаницу в структуре страницы. И ресурс будет кэшироваться до истечения срока его действия, в противном случае это всегда будет страница с ошибкой, если только она не будет принудительно обновлена. (Здесь следует отметить, что поскольку старый ресурс загружается в первый раз, номер версии является новым номером версии, поэтому даже если ресурс будет загружен после этого, старый ресурс все равно будет здесь прочитан.)
Если файл ресурсов отправляется первым: Если страница посещалась ранее, будет локальный кеш, поэтому проблем не будет, поскольку доступ к файлу кеша все еще есть. Однако если это новый пользователь, то будет осуществлен доступ к новому файлу ресурсов, что, вероятно, вызовет путаницу на странице. После публикации html страницы страница возвращается в нормальное состояние.
PS: Конечно, некоторые люди могут сказать, что релиз займет некоторое время, так что нужно заботиться об этих маленьких моментах? Если вы так думаете, то я могу только сказать, что мне нечего сказать.
И то, и другое — это покрытые релизы ресурсов, как бы вы с ними не справлялись, такие проблемы будут. Тогда решение третье. Незакрытый выпуск.
3 Третий способ должен быть самым совершенным решением: 1 Сначала отправьте файл ресурсов.Поскольку имя файла отличается, он не перезапишет существующий файл ресурсов, и клиент по-прежнему сможет безопасно получить к нему доступ. 2. Повторно отправьте клиентский файл. После того, как клиентский файл будет успешно выпущен, он будет немедленно нарезан на новые функции, и середина может быть легко подключена. Это так называемая схема выпуска без покрытия.