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

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

предисловие

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

[Практическая серия] Маршрутизация внешнего интерфейса

[Серия упражнений] Принцип Вавилона

[Практическая серия] Обещания / Спецификация A+

Заинтересованные студенты могут подписаться[Серия упражнений]. Попросите звездочку и попросите подписаться~

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

содержание

 1. DNS 缓存   // 虽说跟标题关系不大,了解一下也不错
 2. CDN 缓存   // 虽说跟标题关系不大,了解一下也不错
 3. 浏览器缓存 // 本文将重点介绍并实践

Кэш DNS

Что такое DNS

Полное название — Domain Name System, то есть система доменных имен.

В качестве распределенной базы данных, которая сопоставляет доменные имена и IP-адреса друг с другом, World Wide Web может упростить пользователям доступ в Интернет без необходимости запоминать строки IP, которые могут быть напрямую прочитаны машинами. Протокол DNS работает поверх протокола UDP и использует порт номер 53.

разрешение DNS

Проще говоря, процесс получения IP-адреса, соответствующего доменному имени, через доменное имя называется разрешением доменного имени (или разрешением имени хоста).

www.dnscache.com (域名)  - DNS解析 -> 11.222.33.444 (IP地址)

Кэш DNS

Где днс, там и кеш. Браузеры, операционные системы, локальный DNS и корневые серверы имен доменов — все в определенной степени кэшируют результаты DNS.

Процесс DNS-запроса выглядит следующим образом:

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

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

  3. Если в локальном файле hosts нет отношения сопоставления, найдите локальный DNS-сервер (сервер интернет-провайдера или DNS-сервер, установленный вами вручную).Если он существует, разрешение доменного имени завершается здесь.

  4. Если локальный DNS-сервер не найден, он сделает рекурсивный запрос к корневому серверу.

Нажмите здесь, чтобы узнать больше о процессе разрешения DNS

Кэш CDN

Что такое CDN

Полное название Content Delivery Network, то есть Content Delivery Network.

Извлеките метафору изображения, чтобы понять, что такое CDN.

10 лет назад не было агентства по продаже билетов на поезд, а о 12306.cn и говорить было невозможно. В то время билеты на поезд можно было купить только в кассах вокзала, а в маленьком районе, где я жил, не было доступа к поездам. Все билеты на поезд нужно было покупать на вокзале в городе. от окружного центра до города туда и обратно было 4 часа езды - пустая трата жизни. Потом было хорошо.Появились пункты продажи билетов на поезда в небольших уездах,и даже в городах.Железные билеты можно купить прямо в пунктах продажи,что намного удобнее.Горожане больше не должны работать в какой-то момент выстроились в очередь, чтобы купить билеты.

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

Когда пользователь просматривает веб-сайт, CDN выбирает ближайший к пользователю пограничный узел CDN, чтобы ответить на запрос пользователя, чтобы запрос пользователя Hainan Mobile не перемещался за тысячи миль на сервер в компьютерной комнате Beijing Telecom (при условии, что исходный сайт развернут в Beijing Telecom. Машинное отделение).

Кэширование CDN

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

Cache-control: max-age   //后面会提到

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

Когда браузер запрашивает данные из узла CDN, узел CDN определяет, истек ли срок действия кэшированных данных.Если срок действия кэшированных данных не истек, он напрямую возвращает кэшированные данные клиенту; в противном случае узел CDN отправит обратно -to-origin запрос к серверу, от Сервер извлекает последние данные, обновляет локальный кеш и возвращает последние данные клиенту. Поставщики услуг CDN обычно предоставляют время кэширования CDN на основе нескольких измерений суффикса файла и каталога, чтобы предоставить пользователям более точное управление кэшем.

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

  1. Узлы CDN решают проблему межоператорского и межрегионального доступа, а задержка доступа значительно сокращается.
  2. Большинство запросов выполняются на граничных узлах CDN, а CDN играет роль в разгрузке, снижая нагрузку на исходный сервер.

Нажмите здесь, чтобы узнать больше о рабочем процессе CDN

Кэш браузера (http-кеш)

Смотрю на эту картинку 30 секунд~

image

Что такое кеширование браузера

image

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

Куда идут кешированные ресурсы?

Вам может быть интересно, браузер хранит ресурсы, так где же он хранит ресурсы?

memory cache

MemoryCache, как следует из названия, кэширует ресурсы в памяти, и не требует повторной загрузки ресурсов при ожидании следующего доступа, а получает их непосредственно из памяти. Webkit уже поддерживает memoryCache. В настоящее время ресурсы Webkit делятся на две категории: одна — это основные ресурсы, такие как HTML-страницы или загружаемые элементы, а другая — производные ресурсы, такие как изображения или ссылки на скрипты, встроенные в HTML-страницы, соответствующие двум классам в коде. : MainResourceLoader и SubresourceLoader . Хотя Webkit поддерживает memoryCache, он предназначен только для производных ресурсов.Ему соответствующий класс — CachedResource, который используется для сохранения исходных данных (таких как CSS, JS и т. д.) и данных декодированного изображения.

disk cache

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

- memory cache disk cache
Та же точка Может хранить только некоторые файлы ресурсов производного класса Может хранить только некоторые файлы ресурсов производного класса
разница Данные очищаются при выходе из процесса Данные не очищаются при выходе из процесса
ресурсы хранения Общие скрипты, шрифты и картинки будут храниться в памяти Как правило, в памяти будут существовать не-скрипты, такие как css и т. д.

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

Принцип трехуровневого кэша (приоритет доступа к кэшу)

  1. Сначала найдите его в памяти и загрузите напрямую, если он есть.
  2. Если его нет в памяти, то он будет искаться на жестком диске, а если есть прямая загрузка.
  3. Если жесткого диска нет, то сделать сетевой запрос.
  4. Запрошенный ресурс кэшируется на жестком диске и в памяти.

Классификация кеша браузера

  1. Сильный кеш

  2. Согласовать кеш

Когда браузер запрашивает ресурсы с сервера, он сначала оценивает, попадает ли он в сильный кэш, а затем оценивает, попадает ли он в согласованный кеш!

Преимущества кеширования браузера

1. Уменьшите избыточную передачу данных

2. Снизить нагрузку на сервер и значительно повысить производительность сайта

3. Ускорить загрузку веб-страниц на стороне клиента

Сильный кеш

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

Информация в заголовке здесь относится к срокам действия и контролю кэширования.

Expires

Полеhttp1.0спецификации, его значение равноабсолютное времяСтрока времени в формате GMT, например Expires:Mon,18 Oct 2066 23:59:59 GMT. Это время представляет собой время аннулирования ресурса. До этого времени происходит попадание в кеш. У этого метода есть очевидный недостаток: поскольку время инвалидации является абсолютным временем, при большой разнице во времени между сервером и клиентом это приведет к путанице в кеше.

Cache-Control

Кэш-Контроль даhttp1.1Информация заголовка, которая появляется, когдаmax-ageценность, чтобы судить, этоОтносительное время, например Cache-Control:max-age=3600, что означает, что срок действия ресурса составляет 3600 секунд. В дополнение к этому полю cache-control имеет следующие часто используемые значения параметров:

no-cache: согласование кеша, отправка запроса на сервер для подтверждения использования кеша.

no-store: отключить использование кеша и каждый раз повторно запрашивать данные.

public: может кэшироваться всеми пользователями, включая конечных пользователей и промежуточные прокси-серверы, такие как CDN.

private: он может кэшироваться только браузером конечного пользователя и не может быть кэширован серверами кэширования ретрансляции, такими как CDN.

Cache-Control и Expires можно включить одновременно в конфигурации сервера, и Cache-Control имеет более высокий приоритет при одновременном включении.

Согласовать кеш

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

Информация в заголовке здесь относится к Last-Modify/If-Modify-Since и ETag/If-None-Match.

Last-Modify/If-Modify-Since

Когда браузер запрашивает ресурс в первый раз, заголовок, возвращаемый сервером, добавляет Last-Modify, Last-modify — это время, определяющее время последней модификации ресурса.

Когда браузер снова запрашивает ресурс, заголовок запроса будет содержать If-Modify-Since, то есть Last-Modify, возвращаемый перед кешем. После получения If-Modify-Since сервер определяет, нужно ли попадать в кеш, в соответствии со временем последней модификации ресурса.

Если кеш попал, возвращается 304, а содержимое ресурса не возвращается, а Last-Modify не возвращается.

недостаток:

Ресурсы изменились за короткий промежуток времени, и Last-Modified не изменится.

циклические изменения. Если ресурс изменяется обратно в исходное состояние в течение цикла, мы думаем, что кеш можно использовать, но Last-Modified так не думает, поэтому есть ETag.

ETag/If-None-Match

В отличие от Last-Modify/If-Modify-Since, Etag/If-None-Match возвращает контрольную сумму. ETag может гарантировать, что каждый ресурс уникален, а изменения ресурсов приведут к изменениям ETag. Сервер определяет, нужно ли попадать в кеш, в соответствии со значением If-None-Match, отправленным браузером.

В отличие от Last-Modified, когда сервер возвращает ответ 304 Not Modified, поскольку ETag был перегенерирован, ETag будет возвращен в заголовке ответа, даже если ETag не изменился по сравнению с предыдущим.

Last-Modified и ETag можно использовать вместе. Сервер сначала проверит ETag. Если он непротиворечив, он продолжит сравнение Last-Modified и, наконец, решит, возвращать ли 304.

Суммировать

Когда браузер снова посещает уже посещенный ресурс, он делает это:

1. Посмотрите, не попал ли в сильный кеш, если да, используйте кеш напрямую.

2. Если надежный кэш не сработал, отправьте запрос на сервер, чтобы проверить, сработал ли кэш согласования.

3. При попадании в кеш согласования сервер вернет 304, чтобы указать браузеру использовать локальный кеш.

4. В противном случае вернуть последний ресурс.

практика для углубления понимания

говорить дешево, покажи мне код. Дайте нам знать правду через практику~

На практике обратите внимание на консоль браузера Network

image
Не отмечайте кнопку.

Ниже мы тренируемся только в Cache-Control сильного кеша и ETag согласованного кеша, а другие друзья могут практиковаться сами~

package.json

{
 "name": "webcache",
 "version": "1.0.0",
 "description": "",
 "main": "index.js",
 "scripts": {
   "cache": "nodemon ./index.js"
 },
 "author": "webfansplz",
 "license": "MIT",
 "devDependencies": {
   "@babel/core": "^7.2.2",
   "@babel/preset-env": "^7.2.3",
   "@babel/register": "^7.0.0",
   "koa": "^2.6.2",
   "koa-static": "^5.0.0"
 },
 "dependencies": {
   "nodemon": "^1.18.9"
 }
}

.babelrc

{
 "presets": [
   [
     "@babel/preset-env",
     {
       "targets": {
         "node": "current"
       }
     }
   ]
 ]
}

index.js

require('@babel/register');
require('./webcache.js');

webcache.js

import Koa from 'koa';
import path from 'path';
//静态资源中间件
import resource from 'koa-static';
const app = new Koa();
const host = 'localhost';
const port = 4396;
app.use(resource(path.join(__dirname, './static')));

app.listen(port, () => {
  console.log(`server is listen in ${host}:${port}`);
});

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>前端缓存</title>
    <style>
      .web-cache img {
        display: block;
        width: 100%;
      }
    </style>
  </head>
  <body>
    <div class="web-cache"><img src="./web.png" /></div>
  </body>
</html>

Сначала мы используем koa для запуска веб-сервера, затем используем промежуточное ПО koa-static для конфигурации статических ресурсов и помещаем index.html и web.png в статическую папку.

Хорошо, давайте начнем службу дальше.

npm run cache

сервер прослушивает localhost:4396.

Далее открываем браузер и вводим адрес:

localhost:4396

image

идеально

Хорошо!!! Далее потренируемсяСильный кеш. ~

Cache-Control

webcache.js

import Koa from 'koa';
import path from 'path';
//静态资源中间件
import resource from 'koa-static';
const app = new Koa();
const host = 'localhost';
const port = 4396;

app.use(async (ctx, next) => {
 // 设置响应头Cache-Control 设置资源有效期为300秒
  ctx.set({
    'Cache-Control': 'max-age=300'  
  });
  await next();
});
app.use(resource(path.join(__dirname, './static')));

app.listen(port, () => {
  console.log(`server is listen in ${host}:${port}`);
});

image
Когда мы обновляем страницу, мы видим, что Cache-Control заголовка ответа стал max-age=300.

кстати проверимПринцип кэша L3

Мы только что сделали сетевой запрос, и браузер сохранил файл web.png на диск и в память.

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

image

Мы видели в красной строке, из кеша памяти. мило~

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

По принципу кеша третьего уровня, если ресурс не найден в памяти, он отправится на поиски на диск!

image

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

Мы просто устанавливаем срок действия ресурса на 300 секунд, затем мы проверим, недействителен ли кеш.

Через 300 секунд. . .

image

Из возвращаемого значения видно, что кеш недействителен.

Получили ли вы более глубокое понимание сильного кэширования благодаря вышеописанной практике?

Хорошо!!! Далее потренируемсяСогласовать кеш. ~

Поскольку значение Cache-Control по умолчанию равно no-cache (необходимо согласовать кеш, отправить запрос на сервер, чтобы подтвердить, использовать ли кеш), поэтому нам не нужно устанавливать здесь Cache-Control!

ETag

//ETag support for Koa responses using etag.
npm install koa-etag -D
// etag works together with conditional-get
npm install koa-conditional-get -D

Здесь мы напрямую используем готовые плагины, которые помогают нам вычислить значение ETag файла, стоящего на плечах гигантов!

webcache.js

import Koa from 'koa';
import path from 'path';
//静态资源中间件
import resource from 'koa-static';
import conditional from 'koa-conditional-get';
import etag from 'koa-etag';
const app = new Koa();
const host = 'localhost';
const port = 4396;

// etag works together with conditional-get
app.use(conditional());
app.use(etag());
app.use(resource(path.join(__dirname, './static')));

app.listen(port, () => {
 console.log(`server is listen in ${host}:${port}`);
});

в порядке. первый запрос.

image
Мы обнаружили, что в возвращаемом значении уже есть значение Etag.

В следующем запросе браузер возьмет заголовок запроса If-None-Match и присвоит ему значение Etag последнего возвращаемого заголовка, а затем сравнит его со значением Etag возвращаемого значения на этот раз. Если они непротиворечивы, нажмите на кэш согласования. Возвращает 304 Не изменено. Далее, давайте проверим ~

image
Хорошо, как показано на картинке, это прекрасно подтверждает приведенное выше утверждение.

Затем мы модифицируем файл web.png, чтобы проверить, не сработает ли согласованная стратегия кэширования при изменении ресурса?

image

Как показано на рисунке, практика согласования кеша также подтверждает принцип.

ты закончил

Писать статью очень утомительно, если вы считаете, что она вам поможет, поддержите автора звездочкой/фолловером~

Адрес источника

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

Использование кеша для оптимизации производительности интерфейса

Категории