Что такое пост кэш
Различные виды кеширования
Техника кеширования заключается в сохранении копии полученного ресурса для возврата этой копии в ответ на дальнейшие запросы. Запрос на ресурс, уже имеющийся в веб-кеше, перехватывается, и вместо обращения к исходному серверу выполняется загрузка копии из кеша. Таким образом снижается нагрузка на сервер, которому не приходится самому обслуживать всех клиентов, и повышается производительность — кеш ближе к клиенту и ресурс передаётся быстрее. Кеширование является основным источником повышения производительности веб-сайтов. Однако, кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется хранить только до того момента, как ресурс изменился, но не дольше.
Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надёжности, производительности и масштабируемости веб-сайтов и веб-приложений.
Приватный (private) кеш браузера
Общий (shared) прокси-кеш
Кеш совместного использования — это кеш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой трафик и время ожидания.
Цели кеширования
Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:
Ответы на запросы отличные от GET , если есть что-либо, подходящее для использования в качестве ключа кеша.
Управление кеш ированием
Заголовок Cache-control
Полное отсутствие кеширования
В кеше не должно сохраняться ничего — ни по запросам клиента, ни по ответам сервера. Запрос всегда отправляется на сервер, ответ всегда загружается полностью.
Кешировать, но проверять актуальность
Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.
Приватные (private) и общие (public) кеши
Директива "public" указывает, что ответ можно сохранять в любом кеше. Это бывает полезно, если возникает потребность сохранить страницы с HTTP-аутентификацией, или такими кодами ответа, которые обычно не кешируются. Директива же "private" указывает, что ответ предназначен отдельному пользователю и не должен храниться в кеше совместного использования. В этом случае ответ может сохраняться приватным кешем браузера.
Срок действия (Expiration)
Самой важной здесь является директива "max-age=<seconds>" — максимальное время, в течение которого ресурс считается "свежим". В отличие от директивы Expires , она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять "агрессивное" кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).
Подробнее об этом рассказывается в разделе Свежесть ресурса.
Проверка актуальности
При использовании директивы "must-revalidate" кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.
Заголовок Pragma
Свежесть сохранённой копии
Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют вытеснением данных из кеша (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохранённой копии. До его истечения ресурс считается свежим (fresh), после — устаревшим (stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении её срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком If-None-Match (en-US) на случай, если копия все ещё актуальна. Если это так, сервер возвращает заголовок 304 Not Modified («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.
Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:
Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок "Cache-control: max-age=N", то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок Expires , и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.
Время устаревания (expirationTime) вычисляется следующим образом:
где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.
Обновление статических ресурсов (Revved resources)
Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их "срок годности" имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.
Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе с новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.
Номер версии, добавляемый к статическому ресурсу, не обязательно записывать в виде стандартного номера версии наподобие 1.1.3, или другого возрастающего числового значения. Это может быть что угодно, позволяющее избежать совпадений — например, дата.
Валидация кеша
Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок "Cache-control: must-revalidate". Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.
При истечении срока годности документа он либо проходит валидацию, либо повторно доставляется с сервера. Валидация может выполняться только если на сервере реализован сильный валидатор или слабый валидатор.
Заголовки ETag
Заголовок ответа ETag является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок ETag , клиент может транслировать его значение через заголовок If-None-Match (en-US) будущих запросов для валидации кешированного ресурса.
Заголовок ответа Last-Modified можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified , то для валидации кешированного документа клиент может выводить в запросах заголовок If-Modified-Since .
При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ 200 OK , либо вернуть ответ 304 Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.
Изменяющиеся ответы
Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком Vary , то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.
Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).
Поскольку значение заголовка User-Agent (en-US) различается ("varies") у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.
Когда вы открываете любые сайты, открытки, картинки, видео, их копии остаются в памяти браузера. Это происходит, даже если вы не скачиваете контент, а просто просматриваете. Как раз эти копии и называются кэшем. Он нужен для того, чтобы сократить количество запросов к сайтам. Например, через некоторое время вы вновь решите посмотреть страницу, которую открывали раньше. Кэш моментально загрузит ее с жесткого диска.
Кэширование работает практически во всех программах и приложениях. Некоторые данные очищаются автоматически, а другие копятся на жестком диске. Это создает дополнительную нагрузку на память устройства. Замедляется работа смартфона, ноутбука, компьютера. Интернет «зависает». Некоторые уверены: дело — в провайдере. Но даже если вы подключите самую высокую скорость (например, 1 Гб/с от МТС ), сайты все равно не будут грузиться быстрее, пока вы не очистите кэш.
Как чистить кэш, сколько раз в месяц это нужно делать
Самый простой способ очистить кэш — перезагрузить устройство. Речь идет не только о компьютерах и смартфонах, но и о wi-fi роутерах, и его модель не имеет значения. Даже самые современные и мощные маршрутизаторы от Ростелеком или Билайн нуждаются в регулярной перезагрузке (примерно, раз в месяц).
Рассказываем, как чистить кэш на Android:
- Откройте настройки смартфона.
- Перейдите в раздел «Устройство».
- Выберите вкладку «память» или «хранилище» (в зависимости от модели смартфона).
- Кликните на «данные кэша» или «cache».
- Нажмите «Очистить» либо «clear cache».
- Подтвердите действие.
Как очистить кэш на iOS:
- Откройте настройки.
- Найдите вкладку браузера Safari.
- Нажмите на вкладку и выберите «Очистить историю и данные».
- Подтвердите действие.
Имейте в виду: вместе с кэшем в айфоне удалится вся история посещений.
Как очистить кэш на компьютере или ноутбуке
Кэш на компьютере обычно чистят через данные локального диска:
- Откройте системный диск (как правило это локальный диск C).
- Кликните по нему правой кнопкой мышки и выберите вкладку «Свойства».
- В разделе «Общие» есть пункт «Очистка диска». Нажмите на эту кнопку.
- Выберите «Очистить системные файлы». Поставьте галочки напротив основных разделов, где хранится кэш:
— временные файлы интернета;
— файлы для отчетов об ошибках;
- Нажмите «Ок» и дождитесь, пока система удалит ненужные данные.
Процесс может занять некоторое время.
Есть еще один вариант: очистить кэш не в самом устройстве, а в браузере. Зайдите в тот, которым обычно пользуетесь (Mozilla Firefox, Google Chrome, Opera). Нажмите в правом верхнем углу на три точки или три горизонтальные полоски (в разных браузерах разные значки). Откроются настройки. Найдите вкладку «История» и нажмите «Очистить». Хотите, чтобы некоторые сайты сохранились в памяти? Добавьте их в закладки (для этого зайдите на страницу и нажмите комбинацию клавиш Ctrl+D).
Если статья оказалась полезной, не забывайте ставить лайк. Подписывайтесь на наш канал и узнавайте еще больше полезного о домашнем и мобильном интернете.
с очень простой семантикой кэширования: если параметры одинаковы (и URL-адрес такой же, конечно), то это хит. Это возможно? Рекомендовали?
ответы на этот метод не кэшируются, если только ответ включает соответствующие поля заголовка Cache-Control или Expires. Однако, ответ 303 (см. Другой) можно использовать для направления агента пользователя получить кэшируемый ресурс.
мне не ясно, как эти спецификации могут позволить осмысленный кэширование.
согласно разделу 9.5 RFC 2616:
"ответы на метод POST не cacheable, если ответ включает соответствующий контроль кэша или Истекает полей заголовка."
Итак, да, вы можете кэшировать ответ на запрос POST, но только если он поступает с соответствующими заголовками. В большинстве случаев вы не хотите кэшировать ответ. Но в некоторых случаях - например, если вы не сохраняете данные на сервере-это вполне уместно.
Примечание, однако многие браузеры, включая текущий Firefox 3.0.10, не будут кэшировать ответ POST независимо от заголовков. IE ведет себя более умно в этом отношении.
теперь, я хочу прояснить некоторую путаницу в документе RFC 2616 С. 13.10. Метод POST в URI не "аннулирует ресурс для кэширования", как некоторые заявили здесь. Он делает ранее кэшированную версию этого URI устаревшей, даже если его заголовки управления кэшем указывают на свежесть дольше продолжительность.
общие:
в принципе POST не является идемпотентной операцией. Поэтому вы не можете использовать его для кэширования. GET должна быть идемпотентной операцией, поэтому она обычно используется для кэширования.
кроме семантики метода GET:
сам метод POST семантически предназначен для публикации чего-либо на ресурсе. POST не может быть кэшируется, потому что если вы делаете что-то один раз против двух против трех раз, то вы изменяете ресурс сервера каждый раз. Каждый запрос имеет значение и должен быть доставлен на сервер.
сам метод PUT семантически предназначен для размещения или создания ресурса. Это идемпотентная операция, но она не будет использоваться для кэширования, потому что удаление могло произойти в то же время.
сам метод DELETE семантически предназначен для удаления ресурса. Это идемпотент операция, но она не будет использоваться для кэширования, потому что PUT мог произойти в то же время.
относительно кэширования на стороне клиента:
веб-браузер всегда будет пересылать ваш запрос, даже если он имеет ответ от предыдущей операции POST. Например, вы можете отправлять электронные письма с gmail через пару дней. Они могут быть одним и тем же предметом и телом, но оба письма должны быть отправлены.
по поводу кэширования прокси-сервера:
по поводу кэширования сервера:
сервер по умолчанию не будет автоматически обрабатывать запрос POST, проверяя его кэш. Но, конечно, запрос POST может быть отправлен в ваше приложение или надстройку, и у вас может быть свой собственный кэш, который Вы читаете, когда параметры одинаковы.
аннулирование a ресурс:
Если вы кэшируете ответ POST, он должен быть в направлении веб-приложения. Это то, что подразумевается под "ответами на этот метод недоступны, если ответ не включает соответствующие поля заголовка Cache-Control или Expires."
следующие GET могут быть поданы из кэша при этом предположении.
приложение, которое не может прикрепить необходимые и правильные заголовки, чтобы различать доступную и недоступную почту ответы виноваты в любых недопустимых результатах кэширования.
тем не менее, каждый пост, который попадает в кэш, требует проверки с использованием условных заголовков. Это необходимо для обновления содержимого кэша, чтобы избежать того, чтобы результаты POST не отражались в ответах на запросы до истечения срока службы объекта.
конечно, это возможно. Если вы хотите поймать почтовые запросы, отправленные на ваш сервер, и кэшировать данные, отправленные обратно для повторной отправки позже-без проблем.
Довольно подробное и интересное изложение материала, касающегося кэша и его использования. Часть 2.
Существует две основные причины, по которым используется веб-кэш:
1. Уменьшение времени ожидания — так как данные по запросу берутся из кэша (который располагается “ближе” к клиенту), требуется меньше времени для получения и отображения контента на стороне клиента. Это делает Веб более отзывчивым (прим. переводчика — “отзывчивым” в контексте быстроты реакции на запрос, а не эмоционально).
2. Снижение сетевого трафика — повторное использование контента снижает объем данных, передаваемых клиенту. Это, в свою очередь, экономит деньги, если клиент платит за трафик, и сохраняет низкими и более гибкими требования к пропускной способности канала.
Виды веб-кэшей
Кэш браузера (Browser cache)
Если вы изучите окно настроек любого современного веб-браузера (например, Internet Explorer, Safari или Mozilla), вы, вероятно, заметите параметр настройки «Кэш». Эта опция позволяет выделить область жесткого диска на вашем компьютере для хранения просмотренного ранее контента. Кэш браузера работает согласно довольно простым правилам. Он просто проверяет являются ли данные “свежими”, обычно один раз за сессию (то есть, один раз в текущем сеансе браузера).
Прокси-кэш (Proxy cache)
Прокси-кэш работает по аналогичному принципу, но в гораздо большем масштабе. Прокси обслуживают сотни или тысячи пользователей; большие корпорации и интернет-провайдеры часто настраивают их на своих файрволах или используют как отдельные устройства (intermediaries).
Поскольку прокси не являются частью клиента или исходного сервера, но при этом обращены в сеть, запросы должны быть к ним как-то переадресованы. Одним из способов является использование настроек браузера для того, чтобы вручную указать ему к какому прокси обращаться; другой способ — использование перехвата (interception proxy). В этом случае прокси обрабатывают веб-запросы, перенаправленные к ним сетью, так, что клиенту нет нужды настраивать их или даже знать об их существовании.
Прокси-кэши являются своего рода общей кэш-памятью (shared cache): вместо обслуживания одного человека, они работают с большим числом пользователей и поэтому очень хороши в сокращении времени ожидания и сетевого трафика. В основном, из-за того, что популярный контент запрашивается много раз.
Кэш-шлюз (Gateway Cache)
Также известные как “реверсивные прокси-кэши” (reverse proxy cache) или “суррогаты” (surrogate cache) шлюзы тоже являются посредниками, но вместо того, чтобы использоваться системными администраторами для сохранения пропускной способности канала, они (шлюзы) обычно используются веб-мастерами для того, чтобы сделать их сайты более масштабируемыми, надежными и эффективными.
Запросы могут быть перенаправлены на шлюзы рядом методов, но обычно используется балансировщик нагрузки в той или иной форме.
Сети доставки контента (content delivery networks, CDN) распространяют шлюзы по всему интернету (или некоторой его части) и отдают кэшированный контент заинтересованным веб-сайтам. Speedera и Akamai являются примерами CDN.
Это учебное пособие преимущественно сфокусировано на браузерных кэшах и прокси, но некоторая информация подходит также и тем, кому интересны шлюзы.
Почему я должен им пользоваться
Кэширование является одной из наиболее неправильно понятых технологий в интернете. Веб-мастера, в частности, боятся потерять контроль над их сайтом, потому что прокси могут “скрыть” их пользователей, сделав сложным наблюдение посещаемости.
К несчастью для них (веб-мастеров), даже если бы веб-кэша не существовало, есть слишком много переменных в интернете, чтобы гарантировать, что владельцы сайтов будут в состоянии получить точную картину того, как пользователи обращаются с сайтом. Если это является для вас большой проблемой, данное руководство научит вас как получить необходимую статистику, не делая ваш сайт “кэшененавистником”.
Другой проблемой является то, что кэш может хранить содержимое, которое устарело или просрочено.
С другой стороны, если вы ответственно подходите к проектированию вашего веб-сайта, кэш может помочь с более быстрой загрузкой и сохранением нагрузки на сервер и интернет-соединение в рамках допустимого. Разница может быть впечатляющей: загрузка сайта, не работающего с кэшем, может потребовать нескольких секунд; в то время как преимущества использования кэширования могут сделать её кажущейся мгновенной. Пользователи по достоинству оценят малое время загрузки сайта и, возможно, будут посещать его чаще.
Подумайте об этом в таком ключе: многие крупные интернет-компании тратят миллионы долларов на настройку ферм серверов по всему миру для репликации контента для того, чтобы ускорить, как только можно, доступ к данным для своих пользователей. Кэш делает то же самое для вас и он гораздо ближе к конечному пользователю.
CDN, с этой точки зрения, являются интересной разработкой, потому что, в отличие от многих прокси-кэшей, их шлюзы приведены в соответствие с интересами кэшируемого веб-сайта. Тем не менее, даже тогда, когда вы используете CDN, вы все равно должны учитывать, что там будет прокси и последующее кэширование в браузере.
Резюмируя, прокси и кэш браузера будут использоваться, нравится вам это или нет. Помните, если вы не настроите ваш сайт для корректного кэширования, он будет использовать настройки кэша по-умолчанию.
Как работает веб-кэш
Вообще говоря, это самые общие правила (не волнуйтесь, если вы не понимаете детали, они будут объяснены ниже):
Свежесть (freshness) и валидация (validation) являются наиболее важными способами, с помощью которых кэш работает с контентом. Свежий контент будет доступен мгновенно из кэша; валидное же содержимое избежит повторной отправки всех пакетов, если оно не было изменено.
Читайте также: