Напишите на обложке: Недавно я изучил брошюру Сюяня и получил много пользы. Что касается кэша HTTP, после запроса данных и размышлений у меня также есть некоторые собственные мысли и понимание, и я надеюсь поделиться ими с вами для обсуждения и совместного развития.
Обзор содержания
- Что такое кэш и его преимущества
- Этапы обработки кэша
- Надежный кеш и кеш согласования
- кэширование решений
- Резюме и размышления
1. Кэш и его преимущества
тайник
Кэширование — это метод, который автоматически сохраняет копию общего ресурса и может использовать эту копию вместо ее повторной загрузки при следующем запросе.
То есть, когда мы делаем запрос ресурса в первый раз, в то время как сервер возвращает ресурс клиенту, кеш-сервер или локальный кеш также сохраняет копию ресурса (если кеширование разрешено), когда мы пытаемся для использования ресурса в следующий раз При выполнении запроса копия ресурса используется напрямую, без повторного запроса документа с исходного сервера.
Преимущества кэширования
- Кэширование может уменьшить избыточную передачу данных.
- Кэширование может решить проблему узких мест в сети.
- Кэширование может снизить требования к исходному серверу.
- Кэширование может уменьшить задержку запросов на расстоянии.
избыточная передача данных
Когда несколько клиентов обращаются к одному и тому же документу, исходный сервер снова и снова возвращает документы с одним и тем же содержимым разным клиентам, и эти дубликаты документов вызывают избыточную передачу данных.
проблема с узким местом в сети
В большинстве случаев клиент всегда будет получать доступ к прокси-серверу быстрее (более высокую пропускную способность и более низкую задержку), чем исходный сервер, поэтому, если прокси-сервер может предоставить полную копию, это намного быстрее, чем получить его с оригинального сервера. Эффективные данные - особенно для больших файлов.
Снижение исходных требований к серверу
Когда внезапные события (такие как экстренные новости, событие со знаменитостями) приводят к тому, что многие люди получают доступ к веб-документу почти в одно и то же время, возникает мгновенная перегрузка. Возникающие в результате чрезмерные скачки трафика могут привести к сбою сети и веб-серверов. Использование кеша может в определенной степени снизить нагрузку на исходный сервер.
Уменьшить задержку расстояния запроса
Физическое расстояние также является аспектом, который снижает производительность сети. Для одного и того же ресурса чем ближе исходный сервер к запрашивающей стороне, тем быстрее будет получен ресурс.
2. Надежный кеш и кеш согласования
1. Объяснение концепций, связанных с кэшем
попадание в кеш
Если результат запроса обслуживается кэшированной копией, это называется попаданием в кэш.
промах кеша
Если в кеше нет доступной копии или срок действия копии истек, запрос перенаправляется на исходный сервер, что называется промахом кеша.
Обнаружение свежести
HTTP хранит копию документа сервера в кэше в течение определенного периода времени. В течение этого времени документ считается «свежим», и кэш может обслуживать документ напрямую, не связываясь с сервером. Но как только кешированная копия слишком долго остается за пределом свежести документа, объект считается «устаревшим», и перед обслуживанием документа кеш должен снова проверить сервер, чтобы увидеть, не изменился ли документ.
переаттестация
Контент на исходном сервере может измениться в любое время, и кэш должен часто проверять его, чтобы убедиться, что копия, которую он сохраняет, по-прежнему является самой последней копией на сервере. Эти проверки актуальности называются повторными проверками HTTP.
Кэши могут перепроверять реплики в любое время, но большинство кэшей перепроверяют реплики только тогда, когда клиент инициирует запрос, а реплика достаточно старая, чтобы ее можно было проверить.
Попадания при повторной валидации и промахи при повторной валидации
Когда кеш повторно проверяет кешированную копию, он отправляет запрос на повторную проверку на исходный сервер, и, если содержимое не изменилось, сервер отвечает 304 Not Modified. Это называется попаданием повторной проверки или медленным попаданием. Если содержимое изменилось, сервер ответит 200. Это называется промахом ревалидации.
2. Этапы обработки кэша
- Во-первых, когда пользователь запрашивает ресурс, он определяет, есть ли кеш, а если нет, то запрашивает ресурс с исходного сервера.
- Если есть кеш, он войдет в категорию сильного кеша, чтобы определить, свежий ли кеш.Если кеш свежий, он будет напрямую возвращать копию кеша клиенту. Если кеш не свежий, это означает, что сильный кеш выходит из строя и войдет в кеш согласования.
- Кэш согласования определит, есть ли заголовки Etag и Last-Modified, и проверит, изменился ли ресурс через эти заголовки. вернуть ресурс клиенту, в противном случае, если кеш согласования отсутствует, сервер вернет новый ресурс.
Сначала вы можете посмотреть на это изображение несколько раз и получить общее представление о процессе кэширования, а затем я буду интерпретировать каждую часть этого изображения. В конце, когда вы снова посмотрите на эту картинку, вы почувствуете, что кэширование — это такой простой процесс.
3. Концепция сильного кэша и кэша согласования
Сильный кеш
После того, как сервер информирует клиента о времени кэширования, клиент оценивает и решает, следует ли использовать кэш.
То есть, когда запрос инициируется в первый раз, сервер запишет время свежести кэша в заголовках ответа. При повторном запросе, если кеш свежий, ресурс будет извлечен непосредственно из кеша без дальнейшей связи с сервером.
Договориться
Сервер должен решить и сообщить клиенту, следует ли использовать кеш.
В соответствии с согласованным механизмом кэширования браузер должен запросить у сервера соответствующую информацию о кеше, а затем определить, следует ли повторно инициировать запрос, загрузить полный ответ или получить кэшированные ресурсы локально.
4. Принцип реализации сильного кэша и кэша согласования
(1) Принцип реализации сильного кеша
Надежное кэширование достигается за счет заголовка Expires или Cache-Control: max-age.
Expires и Cache-Control: max-age — это заголовки, используемые для определения времени истечения срока действия ресурса.
Истекает (HTTP/1.0)
Expires описывает абсолютное время, возвращаемое сервером, выраженное в виде строки в формате GMT.
Поскольку expires является абсолютным временем, если время будет изменено искусственно, это повлияет на срок действия кеша, что сделает настройку срока действия кеша бессмысленной. Таким образом, в http1.1 у нас есть полная замена для управления кешем заголовка expires: max-age
Cache-Control(HTTP/1.1)
Значение max-age — это относительное время, которое определяет максимальный возраст документа — максимально допустимое время жизни (в секундах) с момента создания документа до момента, когда документ перестанет быть свежим и непригодным для использования.
Описание процесса
- Когда мы запрашиваем ресурс в первый раз, сервер запишет заголовок expires или управление кешем в заголовках ответа, возвращая ресурс, чтобы определить время истечения срока действия кеша, и копия кеша сохранит эту часть информации.
- При повторном запросе ресурса кэш сравнивает дату (Date — общий заголовок, указывающий время отправки исходного сообщения сервера. Означает время первого запроса ресурса) и expires/cache-control. , чтобы определить, достаточно ли свежа кэшированная копия.
(2) Принцип реализации кэша согласования
Согласованное кэширование достигается с помощью заголовка запроса Last-Modified или Etag.
Last-Modified определяет время последнего изменения документа, а Etag кодирует содержимое документа.
Last-Modified
проиллюстрировать:
- Когда ресурс запрашивается в первый раз, сервер записывает заголовок Last-Modified в заголовки ответа при возврате ресурса, указывая время последней модификации ресурса на сервере.
- Когда ресурс запрашивается снова, заголовок If-Modified-Since будет записан в заголовки запроса, а значение If-Modified-Since в это время является значением Last-Modified, возвращаемым при первом запросе ресурса.
- После того, как сервер получит запрос, он определит, изменился ли ресурс после даты, в соответствии со значением If-Modified-Since.
- Если нет, он вернет 304 Not Modified; если он изменился, он вернет измененный ресурс и обновит значение Last-Modified.
(1) Скриншот сетевой панели, что ресурс не обновляется
Первый запрос:Повторный запрос:
(2) Скриншот сетевой панели при обновлении ресурсов
Первый запрос:
Запросите еще раз: (Вы можете видеть, что время Last-Modified и If-Modified-Since отличается)
Etag
Мы видим, что процесс реализации Etag точно такой же, как и у Last-Modified.Чтобы узнать о конкретном процессе, пожалуйста, обратитесь к Last-Modified, поэтому я не буду подробно описывать его здесь.
Некоторые проблемы с Last-Modified
Некоторые документы могут периодически переписываться, но часто содержащиеся в них фактические данные остаются теми же. Хотя содержание не изменилось, изменится дата модификации.
Некоторые документы могли быть изменены, но изменения не важны, и кэш не нужно перегружать данными (такими как изменения орфографии или комментарии).
Для некоторых серверов, которые обслуживают документы, которые изменяются с интервалом в доли секунды (например, мониторы реального времени), односекундной даты модификации может быть недостаточно для этих серверов.
С помощью этих описаний мы можем обобщить некоторые недостатки Last-Modified:
- Невозможно определить, действительно ли изменилось содержимое файла. Повторный запрос, когда этого не следует делать.
- Изменения содержания менее чем за секунду не могут быть восприняты. Когда пришло время повторного запроса, он не повторил запрос.
Для вышеуказанных проблем Etag появляется как дополнение к Last-Modified.Etag — это уникальная строка идентификации, сгенерированная сервером для каждого ресурса. Эта строка идентификации кодируется на основе содержимого файла. соответствующий Etag отличается, поэтому Etag может точно воспринимать изменения в файле.
Сильные и слабые валидаторы Etag
ETags делятся на сильные валидаторы и слабые валидаторы.
Сильный валидатор требует, чтобы каждый байт документа был равен, в то время как слабый валидатор требует, чтобы значение документа было одинаковым.
Строгая проверка:Слабая проверка (с префиксом «W/» для идентификации):
5. Описание общих атрибутов заголовка запроса Cache-Control
max-age/s-maxage
Функция директивы s-maxage такая же, как и у max-age, единственное различие между ними заключается в том, что директива s-maxage применяется только к кешам прокси-серверов. s-maxage имеет приоритет над max-age.
public/private
Публичные и частные — это набор противоположных концепций того, могут ли ресурсы кэшироваться прокси-сервисами.
Если мы установим общедоступный для ресурса, он может кэшироваться как браузерами, так и прокси-серверами; если мы установим частный, ресурс может быть кэширован только браузерами.
no-cache/no-store
no-cache означает, что клиенту требуется кэш для проверки документа с исходным сервером перед обслуживанием его кэшированной копии. То есть фаза сильного кэша принудительно пропускается, а кэширование согласования выполняется напрямую. Сильный кеш не знает, действительно ли кеш достаточно свежий.Цель использования no-cache — предотвратить возврат просроченных ресурсов из кеша и повторная проверка кеша.
no-store означает, что кеширование запрещено, то есть каждый раз напрямую связывается с исходным сервером и возвращает ресурсы с исходного сервера. Как правило, устанавливается ресурс без хранения, что означает, что ресурс содержит конфиденциальную информацию.
6. ПРИОРИТЕТНЫЕ ВОПРОСЫ
(1) Expires и Cache-Control: max-age
Когда сервер кэширования, использующий HTTP/1.1, одновременно обнаруживает поле заголовка Expires, он отдает приоритет команде max-age и игнорирует поле заголовка Expires. Противоположное дело обстоит с кэш-серверами HTTP/1.0, где директива max-age игнорируется.
(2) Last-Modified и Etag (сомнительная часть)
После прочтения большого количества информации говорится, что приоритет Etag выше, чем у Last-Modified, но есть также информация о том, что когда Etag и Last-Modified существуют одновременно, они вместе решают, следует ли документ, удостоверяющий личность, изменился.
Поэтому я интерпретирую приоритет здесь: когда они существуют одновременно, браузер сначала оценивает Etag.Если If-None-Match и время последней модификации ресурса сервера различаются, это означает, что файл изменено. Затем он напрямую возвращает 200. В настоящее время нет необходимости проверять If-Modified-Since. При попадании Etag будет оцениваться, попало ли также Last-Modified, и только при обоих совпадениях из кэша будет получена копия кэша.
Примечание: я не знаю, верна ли эта точка зрения, но я думаю, что она разумна.Приглашаю всех обсудить или дать несколько советов.
3. Кэширование решений
Поскольку у меня нет практического опыта работы с http-кешированием, я действительно не разбираюсь в решениях по кэшированию.
В-четвертых, размышление и подведение итогов
На изучение HTTP-кеширования ушло много времени, и я обнаружил, что концепции и знания в нем были относительно беспорядочными, и поначалу было невозможно связать весь процесс кэширования последовательно. Просматривая блоги и книги, я, наконец, разобрался в процессе кэширования, а также в понятиях и знаниях, задействованных на каждом этапе. Не только иметь четкий контроль над всем процессом, но и иметь определенное понимание всех аспектов и деталей процесса.
После долгих размышлений о том, как написать текст, я могу не только четко объяснить большой процесс, но и учесть вещи, связанные с каждым этапом. Я надеюсь, что, поделившись, я смогу поделиться с вами некоторыми новыми вещами и мыслями, тогда я буду удовлетворен.
Наконец, вспомните процесс кэширования и нарисуйте в уме такую картинку:
Наконец, спасибо за чтение, спасибо за вашу тяжелую работу ^_^
Если есть ошибка, поправьте меня
Ссылка на данные
- Буклет Nuggets — Принципы и методы оптимизации производительности внешнего интерфейса
- Говоря о механизме кеширования браузера http
- Полное руководство по HTTP(Код извлечения: 4e45)
- Графический HTTP