Оригинальная статья Tencent DeepOcean:сделать pro.IO/HTTP-wipe-car-…
Во-первых, давайте рассмотрим такой сценарийНастройка кэша http и cdn всегда была важным и распространенным методом оптимизации веб-производительности. Разумная конфигурация кэша http и cdn может уменьшить нагрузку на сервер, устранить узкие места в сети и улучшить взаимодействие с пользователем. Неправильная конфигурация кэша может привести к таким проблемам, как несвоевременное обновление ресурсов, различия в пользовательском опыте и даже ошибки процесса. В этой статье в основном объясняются принципы и правила настройки кэширования http и cdn.Я надеюсь, что благодаря объяснению этой статьи вы сможете понять, что такое разумная конфигурация кэша, как настроить схему кэширования для вашего собственного проекта и как проанализируйте, если у вас возникнут проблемы с кэшированием.
Проект А запустил новую функцию, включая изменения логики и обновления пользовательского интерфейса страницы. Сяомин представил код в качестве разработчика проекта и предварительно выпустил его. Менеджер по продукту Сяохун начал знакомиться с новыми функциями. Странно то, что Сяохун не увидел последние функции после входа в проект. В это время Сяомин немного подумал и сказал: «Сяохун, нажмите «Обновить» и попробуйте еще раз. Конечно же, , после обновления проекта Произошли изменения и появились новые функции, но в это время появились новые проблемы.Картинки в проекте кажутся старыми картинками.Сяо Мин немного подумал,а потом повозился перед компьютер, чтобы позволить Xiaohong испытать это снова Наконец, эта функция полностью принята в настоящее время. В приведенном выше случае это на самом деле включает в себя применение кэша http и кэша cdn.Конечно, это негативный учебный материал.На самом деле, в онлайн-процессе мы не можем позволить каждому пользователю нажимать кнопку «Обновить», чтобы испытать наши новые функции. Как мы должны это решить?Что касается вышеперечисленных проблем, давайте перейдем к галантерее.
http-кэш
Введение
HTTP-кэш — это кеш на стороне клиента.После того как браузер получает ответ сервера в качестве клиента, он анализирует поля заголовка ответа, анализирует соответствующие правила кеша, кэширует ресурсы в соответствии с правилами и считывает непосредственно, если кеш попадает, когда запрос сделан снова.Локальный кеш больше не делает запросы.
правила кэширования
Правила кэширования HTTP контролируются полями заголовка ответа, ключевые поля которыхExpires,Cache-Control,Last-Modified,Etagчетыре поля,Expiresа такжеCache-ControlИспользуется для определения времени хранения кэша,Last-Modifiedа такжеEtagОн используется для определения необходимости обновления кэша, кратко рассмотрим разницу.- expires: параметр, используемый для управления временем кэширования в HTTP 1.0.Заголовок ответа содержит дату/время, то есть по истечении этого времени срок действия ответа истекает.
-
cache-control: параметр, используемый для управления временем кэширования в HTTP1.1.
- public: указывает, что ответ может кэшироваться любым объектом (в том числе: клиентом, отправляющим запрос, прокси-сервером и т. д.).
- private: указывает, что ответ может кэшироваться только одним пользователем, а не как общий кэш (т. е. прокси-сервер не может кэшировать его).
- max-age=
: Установите максимальный период хранения кеша, который кешируется в секундах относительно запрошенного времени, в течение этого времени ресурс доступа напрямую считывает локальный кеш, не отправляя запрос на сервер. (максимальный возраст имеет более высокий приоритет, если он появляется одновременно с истечением срока действия) - s-maxage=
: правило такое же, как и max-age, переопределяет заголовок max-age или Expires, но применяется только к общим кешам (например, отдельным прокси) и игнорируется в частных кешах. (s-maxage имеет более высокий приоритет при совпадении с expires или max-age) - no-store: не кэшировать содержимое ответа сервера, каждый раз при доступе к ресурсу требуется полный ответ сервера
- no-cache: Кэшировать ресурс, но срок его действия истекает немедленно. Каждый запрос необходимо сравнивать с сервером, чтобы убедиться, что ресурс был изменен. (эквивалент max-age=0)
- Последнее изменение: дата и время изменения ресурса, идентифицированного исходным сервером. Менее точен, чем Etag. содержитIf-Modified-Sinceили If-Unmodified-SinceУсловные запросы в заголовке будут использовать это поле.
- Etag: заголовок ответа HTTP является идентификатором конкретной версии ресурса.
Конфигурация на рисунке
- cache-control: max-age=31535000 означает, что относительно времени запроса кеш кэшируется на 31536000 секунд, то есть 365 дней, за это время снова осуществляется обращение к ресурсу для прямого чтения локального кеша без отправки запроса на сервер.
- last-modified: Mon... Время последней модификации, если время кеша истечет, это поле будет использоваться для сравнения с полем If-Modified-Since в запросе, если оно непротиворечиво, предыдущий кеш будет по-прежнему актуален. используется, и если он несовместим, кеш будет считаться недействительным
- истекает: охвачен кешем-контролем в версии http1.0, здесь означает кеширование до субботы, 11 августа ...
кэш-процесс
Как работает правило кеша в нем, давайте посмотрим на несколько ключевых точек
Фокус 1: истекает ли срок действия кеша?
На основании последнего ответа ресурса на правило кэширования и выполнения следующих условий кэш считается не просроченным. Следует отметить, что определение того, истек ли срок действия кеша, относится только к клиенту, а не к серверу. Если 1&2&3 выполняются одновременно, считается, что срок действия кеша не истек, наоборот, срок его действия истек
- Значение управления кешем равно max-age.
- max-age > 0
- текущая дата
Фокус 2: Спросите, были ли изменены ресурсы сервера
Чтобы определить, изменен ли ресурс, клиент и сервер должны работать вместе.После того, как клиент получит кэш ресурсов в первый раз, он сохранит Etag (если есть) и Last-Modified (если есть) и будет пропишите Etag в заголовке запроса, когда срок действия кеша в следующий раз истечет.В If-None-Match в секции значение Last-Modified записывается в If-Modified-Since в заголовке запроса.Сервер сначала сравнивает Etag , а затем сравнивает Last-Modified. Кэш не изменяется. Если один элемент дает сбой, считается, что ресурс был изменен, а кеш недействителен.
Фокус 3: Правила кэширования
Правила кеша в основном отражаются полем управления кешем и полем expires. Когда они появляются одновременно, управление кешем имеет преимущественную силу. Конкретные условия следующие:
- cache-control=no-store не кэшировать никакие ресурсы
- cache-control=кеш без кеша, но с немедленным истечением срока действия
- cache-control=max-age(s-maxage) = 0 кеш, но истекает немедленно (эквивалентно без кеша)
- cache-control=max-age (s-maxage) = секунды (секунды > 0) - кешировать секунды на основе времени запроса
- cache-control=other В соответствии со стандартом http, если он не содержит никаких тегов о времени кэширования, время кэширования равно 10% разницы между текущим временем и временем последнего изменения, что эквивалентно кэшированию. -control=max-age=(date - Last-Modified)/10, исходный текст на английском языке можно увидеть с помощью захвата скрипачом: не было предоставлено явной информации о времени жизни HTTP-кэша.Эвристические политики истечения срока действия предлагают по умолчанию: 10 % дельты между Последнее изменение и дата.
- expires = прошедшее время или недопустимое время, кешируется, но истекает немедленно, эквивалентно cache-control=no-cache
- expires = будущее время, кэшированное до соответствующего времени
конфигурация кэша
Из приведенных выше правил и блок-схемы мы видим, что настройка правил кеша не сложна, за исключением того, что Etag и Last-Modified используются для сравнения кеша (нужно только включить эту функцию в реальном использовании), что нам нужно на что обратить внимание на самом деле это просто cache-control (expires можно преобразовать в форму max-age, так что не буду вдаваться в подробности), решение таково:- cache-control: no-store: Без кеширования, все ресурсы скачиваются с сервиса при каждом посещении.
- управление кешем: без кеша илиcache-control: max-age=0: Сравните кеш, кешируйте текущий ресурс, но каждый раз, когда вы к нему обращаетесь, вам нужно сравнить его с сервером, чтобы проверить, был ли изменен ресурс.
- cache-control: max-age=seconds //seconds > 0: сильный кеш, кеширование текущего ресурса, в течение определенного периода повторно запрашивать ресурс для прямого чтения локального кеша.
В реальных проектах практически незаметно применение схемы 1. По сравнению со схемой 2 и схемой 3 схема 1 не имеет преимуществ. При выборе варианта 2 и варианта 3 мы будем проводить различие между ресурсами.
- Для не-html-ресурсов, таких как img, css, js, шрифты и т. д., мы можем напрямую рассмотреть вариант 3, и время настройки max-age может быть как можно дольше, как и в случае с правилом кэширования,cache-control: max-age=31535000Настройте 365-дневный кеш.Следует отметить, что эта конфигурация не означает, что эти ресурсы должны оставаться неизменными в течение одного года.Фундаментальная причина заключается в том, что текущие средства построения внешнего интерфейса добавят концепцию штампов к статическим ресурсам (для например, [хэш в webpack]], gulp-rev в gulp), каждая модификация будет менять имя файла или увеличивать параметр запроса, что существенно меняет запрошенный адрес, поэтому проблемы с обновлением кеша не возникает.
- Для html-ресурсов мы рекомендуем, какой набор решений использовать в зависимости от частоты обновления проекта. HTML используется в качестве входного файла внешних ресурсов.После того, как он сильно закэширован, соответствующие js, css, img и т. д. не могут быть обновлены. Для бизнес-проектов, требующих частого обслуживания, рекомендуется использовать решение 2 или решение 3, но установить меньшее значение максимального возраста, например 3600, срок действия которого истекает через час. Для некоторых активных проектов после выхода в онлайн не будет внесено никаких серьезных изменений.Рекомендуется использовать схему 3, но max-age не следует ставить слишком большим, иначе пользователи не смогут вовремя обновиться раз баг или неизвестность возникает проблема.
резюме
Для настройки http-кэша нам всегда приходится делать две вещи, во-первых, четко понимать принципы и правила работы http-кеша, а во-вторых, четко понимать, что настройка кеша не является одноразовой конфигурацией. Воспроизведите значение HTTP-кэширования.кеш cdn
Кэш CDN — это кеш на стороне сервера. Поставщик услуг CDN кэширует ресурсы сайта-источника на высокопроизводительных узлах ускорения по всей стране. Когда пользователь получает доступ к соответствующим бизнес-ресурсам, пользователь отправляется на ближайший узел с IP-адрес ближайшего узла Назад к пользователю, в оптимизации веб-производительности, он в основном играет роль снижения нагрузки на исходный сайт и оптимизации скорости доступа и опыта разных пользователей.правила кэширования
В отличие от правила HTTP-кеша, это правило не является нормативным, а сформулировано поставщиком услуг cdn.В качестве примера возьмем Tencent Cloud, чтобы открыть конфигурацию службы ускорения cdn.Панель выглядит следующим образом.
Видно, что предоставленные нам элементы конфигурации - это только тип файла (или каталог файла) и время обновления, и смысл тоже очень простой.Для разных типов файлов соответствующее время кэшируется на узле cdn.
процесс работы cdn
Как видно из рисунка конфигурация cdn cache в основном используется на этапе обработки кэша.Хотя элементы конфигурации имеют только тип файла и время кэша, процесс не простой.Давайте сначала уточним понятие - вернемся к источник,смысл обратно к источнику Это вернуться к исходной станции.Что такое исходная станция,это наш собственный сервер.Многие неправильно понимают,что доступ к cdn означает размещение ресурсов на cdn.На самом деле это не тот случае. Как показано на рисунке, после доступа к cdn наш сервер является источником. В общем случае исходная станция будет получать запрос узла cdn только тогда, когда узел cdn не имеет ресурсов или ресурс cdn выходит из строя. В других случаях , станция-источник не получит запрос (конечно, если мы знаем адрес станции-источника, мы можем напрямую зайти на сайт-источник). После уточнения концепции back-to-source процесс cdn не так сложен.Простое понимание заключается в том, что если ресурса нет, то перейти на исходный сайт читать, а если есть ресурс, то он будет отправлен непосредственно пользователю. В отличие от http-кэша, в cdn нет кеша (max-age=0), когда мы устанавливаем время кеша в 0, этот тип файла считается некэшируемым, то есть все запросы напрямую перенаправляется в источник Только когда время кеша больше 0 и срок действия кеша истекает, он будет сравниваться с исходным сайтом, был ли кеш изменен.
конфигурация кэша
Конфигурация кэша cdn не вызывает затруднений, в целом рекомендуется оставить такую же, как и конфигурацию кэша http. Следует отметить, что конфигурация кеша cdn будет зависеть от конфигурации кеша http, и каждый поставщик услуг cdn не полностью согласован.В качестве примера Tencent Cloud документ конфигурации кеша содержит следующие инструкции.Как это повлияет на нас?
- Если мы http настройки кешаcache-control: max-age=600, то есть кешировать на 10 минут, но в конфигурации cdn cache установлено время кеша файла 1 час, то произойдет следующая ситуация: файл модифицируется и загружается на сервер через 12 минут после обращения, а пользователь повторно обращается к ресурсу, код ответа будет 304, кэш сравнения не был изменен, а ресурс все еще старый, и его можно обновить до последнего ресурса только после повторного посещения через час.
- Если вы не установите cache-control, мы сказали в http cache, что если вы не установите cache-control, будет время кэширования по умолчанию, но здесь поставщик услуг cdn явно поможет нам, когда нет кэша поле управления Добавить вcache-control: max-age=600.
резюме
Настройка кэша cdn не сложна.Сложная ситуация заключается в том, что конфигурация кэша cdn будет зависеть от конфигурации кэша http, и разные операторы cdn обрабатывают этот эффект непоследовательно.В реальном использовании рекомендуется перейти к соответствующему cdn поставщика услуг. Найдите соответствующие примечания в документации.Комбинация HTTP-кеша и cdn-кеша
После того, как мы разберемся с конфигурацией кеша http и кеша cdn соответственно, у нас есть еще одна вещь, а именно понимание потока запросов, когда они объединены.
Когда пользователь получает доступ к нашему бизнес-серверу, первое, что нужно сделать, это обработка кеша http.Если кеш http проходит проверку, он ответит непосредственно пользователю.Если он не проходит проверку, обработка кеша cdn будет продолжена.После обработка кэша cdn завершена, он будет возвращен клиенту, клиент хранит правила кэширования http и отвечает пользователю. Когда мы анализируем проблему кеша, мы должны анализировать два процесса независимо. Теперь давайте посмотрим на случай ошибки в начале.Очевидно, что в первой проблеме из-за необоснованной настройки http-кеша пользователь должен выполнить принудительное обновление для обновления ресурсов, вторая проблема связана с тем, что кеш cdn не обновляется вовремя.
Суммировать
HTTP-кэш и cdn-кэш, как кеш на стороне клиента и кеш на стороне сервера, соответственно, влияют на поток наших веб-запросов.Чтобы хорошо выполнить настройку кеша, в первую очередь нужно понять принцип и правила настройки кеширования. , а второй — анализировать уровень кеша в сочетании с проектом.