Основы веб-кеширования: терминология, заголовки HTTP и стратегии кэширования

Введение

Интеллектуальное кэширование контента — один из наиболее эффективных способов улучшить впечатление посетителей вашего сайта. Кэширование или временное хранение контента из предыдущих запросов является частью основной стратегии доставки контента, реализованной в протоколе HTTP. Все компоненты на пути доставки могут кэшировать элементы для ускорения последующих запросов в соответствии с политиками кэширования, объявленными для контента.

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

Что такое кэширование?

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

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

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

Преимущества

Эффективное кэширование помогает как потребителям контента, так и его поставщикам. Некоторые преимущества кэширования при доставке контента:

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

Терминология

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

Исходный сервер. Исходный сервер – это исходное местоположение контента. Если вы действуете как администратор веб-сервера, вы управляете этой машиной. Он отвечает за обслуживание любого контента, который не может быть извлечен из кэша по маршруту запроса, и за настройку политики кэширования для всего контента.
Коэффициент попаданий в кеш. Эффективность кеша измеряется с точки зрения его коэффициента попаданий в кеш или коэффициента попаданий. Это отношение запросов, которые можно извлечь из кэша, к общему количеству выполненных запросов. Высокий коэффициент попаданий в кэш означает, что большой процент содержимого удалось извлечь из кэша. Обычно это желаемый результат для большинства администраторов.
Свежесть. Свежесть – это термин, используемый для описания того, считается ли элемент в кеше кандидатом на показ клиенту. Содержимое в кеше будет использоваться для ответа только в том случае, если оно находится в пределах срока актуальности, указанного в политике кэширования.
Устаревшее содержимое. Срок действия элементов в кэше истекает в соответствии с настройками актуальности кэша в политике кэширования. Контент с истекшим сроком действия является «устаревшим». Как правило, контент с истекшим сроком действия нельзя использовать для ответа на запросы клиентов. Необходимо повторно связаться с исходным сервером, чтобы получить новый контент или, по крайней мере, убедиться, что кэшированный контент по-прежнему точен.
Проверка. Устаревшие элементы в кэше можно проверить, чтобы обновить срок их действия. Проверка включает в себя проверку на исходном сервере, чтобы узнать, представляет ли кэшированный контент самую последнюю версию элемента.
Инвалидация. Инвалидация — это процесс удаления контента из кэша до истечения срока его действия. Это необходимо, если элемент был изменен на исходном сервере и наличие устаревшего элемента в кэше может вызвать серьезные проблемы для клиента.

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

Что можно кэшировать?

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

Логотипы и изображения брендов
Изображения без поворота (например, навигационные значки)
Таблицы стилей
Общие файлы Javascript
Загружаемый контент
Медиафайлы

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

Некоторые элементы, с которыми вы должны быть осторожны при кэшировании:

HTML-страницы
Поворот изображений
Часто изменяемые Javascript и CSS
Контент, запрошенный с помощью файлов cookie аутентификации

Некоторые элементы, которые почти никогда не следует кэшировать:

Активы, связанные с конфиденциальными данными (банковская информация и т. д.)
Контент, который зависит от пользователя и часто изменяется.

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

Места, где кэшируется веб-контент

Контент может кэшироваться в разных точках цепочки доставки:

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

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

Кэширование заголовков

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

Большая часть поведения кэширования определяется политикой кэширования, которая устанавливается владельцем контента. Эти политики в основном сформулированы с помощью определенных заголовков HTTP.

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

Expires. Заголовок Expires очень прост, хотя и довольно ограничен по объему. По сути, он устанавливает время в будущем, когда срок действия контента истечет. На этом этапе любые запросы на один и тот же контент должны будут возвращаться на исходный сервер. Этот заголовок, вероятно, лучше всего использовать только как запасной вариант.
Cache-Control: это более современная замена заголовка Expires. Он хорошо поддерживается и реализует гораздо более гибкий дизайн. Почти во всех случаях это предпочтительнее, чем Expires, но может не помешать установить оба значения. Мы обсудим особенности параметров, которые вы можете установить с помощью Cache-Control, чуть позже.
Etag: заголовок Etag используется при проверке кеша. Источник может предоставить уникальный Etag для элемента, когда он изначально предоставляет контент. Когда кэшу необходимо проверить доступный контент по истечении срока действия, он может отправить обратно Etag, который у него есть для контента. Источник либо сообщит кешу, что контент тот же, либо отправит обновленный контент (с новым Etag).
Last-Modified: этот заголовок указывает время последнего изменения элемента. Это может быть использовано как часть стратегии проверки для обеспечения актуальности контента.
Content-Length. Хотя заголовок Content-Length не участвует в кэшировании, его важно установить при определении политик кэширования. Определенное программное обеспечение откажется кэшировать содержимое, если оно заранее не знает размер содержимого, для которого ему потребуется зарезервировать место.
Вариант. Кэш обычно использует запрошенный хост и путь к ресурсу в качестве ключа для хранения элемента кеша. Заголовок Vary можно использовать, чтобы указать кэшам обратить внимание на дополнительный заголовок при принятии решения о том, относится ли запрос к тому же элементу. Это чаще всего используется, чтобы сообщить кешу, что нужно вводить ключ с помощью заголовка Accept-Encoding, чтобы кеш знал, как различать сжатое и несжатое содержимое.

Немного о заголовке Vary

Заголовок Vary дает вам возможность хранить разные версии одного и того же контента за счет разбавления записей в кеше.

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

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

Как флаги Cache-Control влияют на кэширование

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

Вот некоторые из параметров Cache-Control, которые можно использовать для определения политики кэширования вашего контента:

no-cache: эта инструкция указывает, что любой кешированный контент должен проходить повторную проверку при каждом запросе, прежде чем он будет передан клиенту. Это, по сути, сразу помечает содержимое как устаревшее, но позволяет использовать методы повторной проверки, чтобы избежать повторной загрузки всего элемента снова.
no-store: эта инструкция указывает, что содержимое никоим образом не может быть кэшировано. Это уместно установить, если ответ представляет собой конфиденциальные данные.
public: это помечает контент как общедоступный, что означает, что он может кэшироваться браузером и любыми промежуточными кэшами. Для запросов, использующих HTTP-аутентификацию, ответы по умолчанию помечаются как private. Этот заголовок переопределяет этот параметр.
private: контент помечается как private. Частный контент может храниться в браузере пользователя, но он не должен не кэшироваться какими-либо посредниками. Это часто используется для пользовательских данных.
max-age: этот параметр настраивает максимальный срок хранения содержимого в кэше до того, как оно должно будет пройти повторную проверку или повторную загрузку содержимого с исходного сервера. По сути, это заменяет заголовок Expires для современного просмотра и является основой для определения свежести контента. Этот параметр принимает значение в секундах с максимальным действительным сроком действия в один год (31536000 секунд).
s-maxage: этот параметр очень похож на параметр max-age, поскольку он указывает количество времени, в течение которого контент может кэшироваться. Отличие в том, что этот параметр применяется только к промежуточным кэшам. Сочетание этого с вышеперечисленным обеспечивает более гибкое построение политик.
необходимо перепроверить: это указывает на то, что информация о свежести, указанная с помощью заголовков max-age, s-maxage или Expires должна строго соблюдаться. Устаревший контент не может быть показан ни при каких обстоятельствах. Это предотвращает использование кэшированного контента в случае сбоев в сети и подобных ситуаций.
proxy-revalidate: работает так же, как и предыдущий параметр, но применяется только к промежуточным прокси. В этом случае браузер пользователя потенциально может быть использован для обслуживания устаревшего контента в случае прерывания сети, но для этой цели нельзя использовать промежуточные кеши.
no-transform: этот параметр указывает кэшам, что им не разрешено изменять полученный контент из соображений производительности ни при каких обстоятельствах. Это означает, например, что кеш не может отправлять сжатые версии контента, которые он не получил от исходного сервера, сжатые и не разрешенные.

Их можно комбинировать по-разному для достижения различных режимов кэширования. Некоторые взаимоисключающие значения:

no-cache, no-store и обычное поведение кэширования, на которое указывает отсутствие любого из них
общедоступный и частный

Параметр no-store заменяет параметр no-cache, если присутствуют оба. Для ответов на неаутентифицированные запросы подразумевается public. Для ответов на аутентифицированные запросы подразумевается private. Их можно переопределить, включив противоположную опцию в заголовок Cache-Control.

Разработка стратегии кэширования

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

Общие проблемы

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

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

Общие рекомендации

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

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

Создайте специальные каталоги для изображений, CSS и общего контента. Размещение контента в специальных каталогах позволит вам легко обращаться к ним с любой страницы вашего сайта.
Используйте один и тот же URL-адрес для ссылок на одни и те же элементы. Поскольку ключ кеширования не зависит как от хоста, так и от пути к запрошенному контенту, убедитесь, что вы ссылаетесь на свой контент одинаково на всех своих страницах. Предыдущая рекомендация значительно упрощает эту задачу.
По возможности используйте спрайты изображений CSS: спрайты изображений CSS для таких элементов, как значки и навигация, сокращают количество циклов обработки, необходимых для отрисовки вашего сайта, и позволяют вашему сайту кэшировать один спрайт в течение длительного времени.
По возможности размещайте сценарии и внешние ресурсы локально. Если вы используете сценарии javascript и другие внешние ресурсы, рассмотрите возможность размещения этих ресурсов на своих собственных серверах, если правильные заголовки не предоставляются восходящим потоком. Обратите внимание, что вам нужно будет знать обо всех обновлениях, внесенных в исходный ресурс, чтобы вы могли обновить свою локальную копию.
Элементы кеша отпечатков пальцев. Для статического содержимого, такого как файлы CSS и Javascript, может быть уместно создавать отпечатки пальцев для каждого элемента. Это означает добавление уникального идентификатора к имени файла (часто хэш файла), чтобы в случае изменения ресурса можно было запросить новое имя ресурса, в результате чего запросы правильно обходят кеш. Существует множество инструментов, которые могут помочь в создании отпечатков пальцев и изменении ссылок на них в HTML-документах.

Что касается выбора правильных заголовков для различных элементов, то в качестве общего ориентира может служить следующее:

Разрешить всем кэшам хранить общие ресурсы. Статическое содержимое и содержимое, не относящееся к конкретному пользователю, можно и нужно кэшировать на всех этапах цепочки доставки. Это позволит промежуточным кэшам отвечать контентом для нескольких пользователей.
Разрешить браузерам кэшировать пользовательские ресурсы. Для пользовательского контента часто допустимо и полезно разрешить кэширование в браузере пользователя. Хотя этот контент нельзя кэшировать на каких-либо промежуточных кэширующих прокси-серверах, кэширование в браузере позволит пользователям мгновенно извлекать его во время последующих посещений.
Создавайте исключения для важного срочного контента. Если у вас есть контент, который зависит от времени, сделайте исключение из приведенных выше правил, чтобы устаревший контент не показывался в критических ситуациях. Например, если на вашем сайте есть корзина, она должна сразу отражать товары в корзине. В зависимости от характера содержимого для достижения этой цели в заголовке Cache-Control можно установить параметры no-cache или no-store. .
Всегда предоставляйте валидаторы. Валидаторы позволяют обновлять устаревший контент без повторной загрузки всего ресурса. Установка заголовков Etag и Last-Modified позволяет кэшам проверять их содержимое и повторно обслуживать его, если оно не было изменено в источнике, что еще больше снижает нагрузку.
Установите длительные периоды обновления для вспомогательного контента. Чтобы эффективно использовать кэширование, элементы, запрашиваемые в качестве вспомогательного контента для выполнения запроса, часто должны иметь длительный период обновления. Обычно это подходит для таких элементов, как изображения и CSS, которые извлекаются для отображения HTML-страницы, запрошенной пользователем. Установка расширенного времени обновления в сочетании со снятием отпечатков пальцев позволяет кэшам хранить эти ресурсы в течение длительных периодов времени. Если активы изменятся, измененный отпечаток сделает кэшированный элемент недействительным и вызовет загрузку нового контента. А до тех пор вспомогательные элементы можно кэшировать в далеком будущем.
Установите короткое время обновления для родительского контента. Чтобы описанная выше схема работала, содержащий элемент должен иметь относительно короткое время обновления или вообще не кэшироваться. Обычно это HTML-страница, которая вызывает другой вспомогательный контент. Сам HTML будет загружаться часто, что позволит ему быстро реагировать на изменения. Вспомогательный контент может быть агрессивно кэширован.

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

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

Цель состоит в том, чтобы по возможности перемещать контент в первые категории, сохраняя при этом приемлемый уровень точности.

Заключение

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