Кэширование HTTP просто для понимания. В статье систематизированы соответствующие материалы и зафиксированы некоторые практики. Удобно всем легко разбираться в кеше. Если вы можете ответить на три вопроса выше, HTTP-кэширование понятно. Можно ли кэшировать? Кэш истекает? Договориться о кеше?

резюме:

• веб-кэш
• Обработка кеша
• Интерфейсные решения
• Суммировать

1. веб-кэш

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

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

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

Ключевые слова: кеш, исходный сервер (генерирует оригинальные документы).

1.1 Тип кэша

Виды кеширования: кеширование браузера (рассматривается в этой статье), кеширование прокси, кеширование шлюза.

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

Эти тайники можно разделить на две категории:

• Частный кэш (Private Cache): Частный кэш предназначен для одного пользователя.
• Общий кеш: общий для нескольких пользователей.

Источник изображения: HTTP-кеширование

На изображении выше показано:

Без кэширования:Нет кеша для запроса ресурсов напрямую с сервера.

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

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

1.2 Назначение кэша

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

2. Обработка кеша

Простые вопросы и соответствующие поля заголовков, задействованные в процессе кэширования HTTP.

2.1 Связанные поля заголовка

2.1.1 Можно ли кэшировать данные, связанные поля

(1) Хранилище по умолчанию

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

Обычные кэши HTTP обычно ограничиваются кэшированием ответов на GET и могут отклонять другие методы. Первичный ключ кэша состоит из метода запроса и целевого URI (обычно используется только URI, поскольку только запросы GET являются целями кэша).

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

Ответы с кодами состояния 200, 203, 206, 300, 301 или 410 также могут сохраняться в кэше и использоваться для ответов на последующие запросы.

конкретная ссылкаКэширование ответов

⑵ Управление кэшем

Cache-ControlNo-store, no-cache, Public, Private, max-age в заголовке используются дляУказывает, может ли клиент сохранить содержимое ответа,

⑶ Срок действия:

Указывает, что он может быть сохранен клиентом, а также сообщает время. (Заголовок Expires и заголовок Cache-control:max-age в основном делают одно и то же)
Истекает: значение – это время истечения срока действия кэша, которое используется для указания времени истечения срока действия ресурса. Это конкретный момент времени на стороне сервера. Браузер может напрямую использовать кэшированные данные до истечения срока действия. Заголовок Expires будет игнорироваться, если в ответе присутствует заголовок Cache-Control с директивой max-age или s-maxage.

2.1.2 Срок действия кеша истек?

⑴ Нельзя использовать напрямую

Кэш-контроль: без кеша

Кэш проверит этот запрос (с полями проверки, связанными с локальным кешем) на исходный сервер перед использованием кэшированной копии.

⑵ истекает ли расчет

Дата:Дата и время создания сообщения.

Expires:Указывает, что он может быть сохранен клиентом, а также сообщает время. (Заголовок Expires и заголовок Cache-control:max-age в основном делают одно и то же).

Кэш-Контроль:max-age= Время действия кэша.

Формула расчета свежести выглядит следующим образом:

max-age指令优先于Expires，因此，如果响应中存在max-age，则计算很简单：
// 新鲜度 = max_age_value
fresh_lifetime = max_age_value
否则，如果响应中存在Expires，则计算为：
// 新鲜度 = expires_value - date_value(Date创建报文的日期时间(启发式缓存阶段会用到这个字段))
fresh_lifetime = expires_value - date_value

Возраст:Сообщите получателю, как долго был сгенерирован ответ (значение возраста можно просмотреть, если вас интересует конкретный алгоритм).Age Calculations)(HTTP/1.1Кэш ДОЛЖЕН включать заголовок Age с каждым отправленным ответом)

Срок действия расчета кеша истекает:

// 响应是否新鲜    current_age: 是浏览器计算出的age 值
response_is_fresh = (freshness_lifetime > current_age)

Если в ответе нет заголовка Cache-Contral:max-age и заголовка Expires, кэш может вычислить предварительный максимальный возраст, известный как эвристическое кэширование.

(3) Эвристический кеш:

Если Expires, Cache-Control: max-age или Cache-Control: s-maxage не отображаются в ответе и ответ не содержит других ограничений на кэширование, кэш может использовать эвристику для расчета времени жизни свежести.

Обычно на основе 2 полей времени в заголовке ответа Date минус 10% от значения Last-Modified в качестве времени кэширования.

// Date 减去 Last-Modified 值的 10% 作为缓存时间。
// Date：创建报文的日期时间, Last-Modified 服务器声明文档最后被修改时间
  response_is_fresh =  max(0,（Date -  Last-Modified)) % 10

Обычно рассчитанное значение устанавливается для перехода в онлайн. Но лучше отображать время истечения на стороне сервера

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

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

Когда Last-Modified время последнего изменения также не

Изображение взято из "Авторитетного руководства HTTP"

2.1.3 Согласовать, может ли кэш повторно использовать связанные поля

Когда клиент впервые запрашивает без условного заголовка, сервер отвечает условным заголовком, таким как Last-Modified, ETag и т. д. Когда срок действия следующего кеша истекает, клиент отправляет идентификатор кэшированных данных на сервер для проверки.

Два наиболее полезных оператора If в условном заголовке, определяемом HTTP.-Modified-Since и If-None-Match:

⑴ Последнее изменение и если изменено с момента
Last-Modified (заголовок ответа сервера): время обновления ресурса, записанное сервером.
If-Modified-Since (поле заголовка запроса): дата последнего изменения кэшированной копии.

По истечении срока действия кеша повторите проверку. Клиент отправляет на сервер идентификатор кэшированных данных If-Modified-Since, и сервер сравнивает Last-Modified и If-Modified-Since. Если значение поля-Modified-Since предшествует времени обновления ресурса Last-Modified, ожидается, что будет возвращен новый ресурс. После даты и времени, указанных в значении поля If-Modified-Since, если ни один из запрошенных ресурсов не был обновлен, возвращается ответ с кодом состояния 304 Not Modified.

Недостатки: Last-Modified может иметь точность только до секунд, а файлы изменяются очень часто.Если изменения вносятся в течение нескольких секунд, Last-Modified не может быть точным.

Хотя содержимое файла, расположенного на нескольких CDN-серверах, одинаково, время модификации отличается. (Обновление информации будет возвращено после сравнения)

Так ETag появился в HTTP/1.1.

⑵ ETag и If-None-Match

ETag (заголовок ответа сервера): идентификатор объекта. Это способ уникальной идентификации ресурсов в виде строк. Сервер присвоит каждому ресурсу соответствующее значение ETag.

If-None-Match (поле заголовка запроса): кэшированные теги сущностей. Когда значение тега объекта (ETag), используемое для указания значения поля If-None-Match, несовместимо с ETag запрошенного ресурса, он сообщает серверу обработать запрос и вернуть новый ресурс, в противном случае ответ со статусом возвращается код 304 Not Modified.

По истечении срока действия кеша повторите проверку. Клиент отправляет кэшированный тег объекта данных If-None-Match на сервер, и сервер сравнивает If-None-Match с ETag.

(3) Другое, если справочные документы заголовка условия

2.1.4 меняться можно легко понять

Варьировать можно легко понять, бэкэнд используется для настройки.

варьирование определяется следующим образом:

VaryЗаголовок ответа HTTP, который определяет, следует ли использовать кешированный ответ для будущего заголовка запроса или следует запрашивать новый ответ с исходного сервера. Он используется сервером, чтобы указать, чтоcontent negotiationКакие заголовки следует использовать при выборе представителя ресурса в алгоритме согласования контента.

Например: Источник изображения "Иллюстрация http"

Клиент запрашивает у сервера ресурс /sample.html, Accept-Language: en-us, у прокси-сервера нет этого ресурса, и запросы к серверу

Сервер возвращает ресурс, в заголовке HTTP-ответа Vary указывается Accept-Language, прокси-сервер возвращает ресурс клиенту и кэширует данные.

Второй клиент запрашивает у сервера ресурс /sample.html, Accept-Language: zh-cn, у прокси-сервера нет этого ресурса, и запрашивает у сервера

Сервер возвращает ресурс, в заголовке HTTP-ответа Vary указывается Accept-Language, прокси-сервер возвращает ресурс клиенту и кэширует данные. Кэш выглядит следующим образом

Третий клиент запрашивает у сервера ресурс /sample.html, Accept-Language: zh-cn или en-us, и прокси-сервер может вернуть кэшированные данные (срок действия кеша не истек).

так:

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

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

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

Если вам интересно, вы можете посмотреть:Understanding The Vary Header, Caching Negotiated Responses

2.2 Процесс кэширования

Предположим, есть только кеш браузера и серверные сценарии. Обратитесь к приведенному выше полевому рисунку следующим образом.

2.2.1 Анализ процесса

(1) Когда инициируется запрос ресурса, кеш анализирует сообщение URL-адреса и извлекает заголовок, чтобы определить, есть ли у клиента кеш.

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

С кешем:

• Кэш должен быть проверен, прежде чем его можно будет использовать, и соответствующие поля проверки (If-None-Match, If-Modified-Since) локального кеша отправляются на сервер исходного сервера для проверки.
• Кэш доступен, срок его действия истек?
• Кэш доступен, срок его действия не истек, создается ответное сообщение и отображается кэшированное содержимое.
• По истечении срока действия кеша отправьте соответствующие поля проверки (If-None-Match, If-Modified-Since) локального кеша на исходный сервер для проверки.

(2) Отправить соответствующие поля проверки (If-None-Match, If-Modified-Since), кэшированные локально на сервер, на исходный сервер для проверки.

Повторная проверка условного метода(согласование кеша):

• Условная проверка прошла успешно: исходный сервер отправляет клиенту небольшой ответ HTTP 304 Not Modified, исключая содержимое. Кэш на стороне клиента обновит актуальность кэшированного документа и создаст ответ для отображения кэшированного содержимого.
• Ошибка проверки: исходный сервер возвращает новый контент клиенту, клиент кэширует и отображает новый контент.
• Содержимое удалено: исходный сервер отправляет клиенту ответ 404 Not Found, и кеш клиента также удаляет кеш.

2.2.2 кэш памяти и дисковый кэш

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

Chrome использует два кеша — на диске и очень быстрый кеш в памяти. Время жизни кеша в памяти привязано к времени жизни процесса рендеринга, что примерно соответствует вкладке. Кэш в памяти невидим для API веб-запросов. Если обработчик запросов меняет свое поведение (например, поведение, в соответствии с которым блокируются запросы), простое обновление страницы может не учитывать это измененное поведение. Чтобы убедиться, что поведение изменилось проходит, звонитеhandlerBehaviorChanged() to flush the in-memory cache. But don't do it often; flushing the cache is a very expensive operation. You don't need to call handlerBehaviorChanged() after registering or unregistering an event listener.

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

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

Мое собственное простое понимание, как показано выше

Если интересует информация:Disk Cache 3.0

3. Интерфейсные решения

HTML: Установите Cache-control: no-cache (конфигурация на стороне сервера), и браузер всегда будет перепроверять документ при каждом запросе и получать последнюю версию при изменении содержимого.
js css png, смонтированные в HTML, содержат уникальную строку идентификации файла. При изменении любого файла URL-адрес изменится, что приведет к изменению HTML-файла. Ресурс будет обновлен при следующем запросе ресурса.

4. Резюме

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

Использованная литература:

«Иллюстрированный HTTP»

Полное руководство по HTTP

Understanding The Vary Header

rfc2616

Disk Cache 3.0

http-caching

HTTP caching(MDN)

Caching Tutorial

What does Blink in-memory cache store?