Всегда хотел научиться кэшировать эту вещь вместе, в конце концов, кеш оптимизации производительности переднего плана, на который приходится большая часть роли. Кэш делится на два типа: кэш обязательных консультаций и кэш. Прочитано много статей, говорящих о различиях между ними, но не имеет никакого реального значения, только знаю, что не знаю, как настроить, нет никакой реальной памяти причины также всегда были очень расплывчатыми, практика - лучший учитель! Запишите, что я использую в процессе изучения кеша сервера nginx.
Предварительное исследование
Первый яnginxсоздал новый в корневом каталогеindex.htmlдокументы иindex.jsдокумент. В настоящее времяnginxФайл конфигурации выглядит следующим образом:
server {
listen 8080;
server_name localhost;
location / {
root /Volumes/myFile/nginx_root;
index index.html index.htm;
}
}
Затем наш браузер обращается к localhost:8080. Открываем консоль и обнаруживаем, что в ней есть два запроса:
Вы можете видеть, что для первого доступа коды состояния обоих запросов равны 200. Щелкнем по одному из запросов, чтобы увидеть информацию заголовка ответа:
Как видите, заголовок ответа несет намEtagтак же какLast-ModifiedИнформация. Это поле используется кэшем согласования. похоже на тоnginxКэш у нас уже используется по умолчанию. Затем мы снова обновляем страницу, чтобы проверить, не изменяя файл html и файл js.Если кеш согласования попал, код состояния должен быть возвращен нам.304 Not Modified. Я несколько раз обновлялся, чтобы наблюдать за кодом состояния http-запроса. HTML-файл каждый раз возвращает 304. Но файл js сначала становится после 304200 OK (from memory cache). Другими словами, каждый html-файл является кешем согласования попадания, а файл JS попадает в сильный буфер (приоритет сильного кеша выше, чем у кеша согласования). Почему у вас такая ситуация, я буду Baidu:
Почему некоторые кеши 200 в порядке (из кеша), а некоторые кеши 304 не изменены? Очень просто, посмотрите, удален ли Entity Tag. Удалено, всегда 200 ОК (из кеша). Если не удалить, они будут появляться попеременно.
Итак, в чем разница между синхронизацией двух триггеров? 200 OK (из кеша) — это прямой щелчок по ссылке для доступа, ввод URL-адреса и нажатие Enter для доступа к нему, а 304 Not Modified срабатывает при обновлении страницы или когда установлен сильный кеш, но теги объектов не удаляются.
На своем примере я понимаю это так:index.htmlСтраница обновления файла попадает в согласованный кеш и возвращает 304, а файл js связан в файле index.html, поэтому попадание в сильный кеш — это 200 OK (из кеша). Чтобы проверить свою идею, я использовал адресную строку для прямого доступаindex.jsдокумент. Введите в адресной строке: localhost:8080/index.js, в этот раз он вернул мне 304, давайте посмотрим на заголовок запроса в это время:
На этот раз можно увидетьCache-ControlОн дает max-age=0, затем он также содержит соответствующие параметры согласованного кеша. Кажется, он будет перенесен при обновлении браузера.Cache-Control:max-age=0Это позволяет избежать попадания в сильные кеши.
nginx отключить сильный кеш
пытающийсяnginxЧто происходит после отключения сильного кэширования. ИсправлятьnginxКонфигурационный файл:
server {
listen 8080;
server_name localhost;
location / {
root /Volumes/myFile/nginx_root;
index index.html index.htm;
add_header Cache-Control no-cache;
# 为 public可以被任何对象缓存，private只能针对个人用户，而不能被代理服务器缓存
add_header Cache-Control private;
}
}
ИзмененоnginxПосле конфигурационного файла перезагружаемсяnginxсервер. В настоящее время доступ к localhost:8080
Видно, что и файл html, и файл js имеют 304 совпадения в кэше согласования в это время.
Cache-Control:no-store
Отключите все кэширование (именно это означает, что ответы не кэшируются). Кэш обычно пересылает клиенту ответ об отсутствии хранилища, как некэширующий прокси-сервер, а затем удаляет объект.
Кэш-контроль: без кеша
Заставить клиента отправлять запросы непосредственно на сервер, что означает, что каждый запрос должен быть отправлен на сервер. Сервер получает запрос, а затем оценивает, изменился ли ресурс, если да, возвращает новый контент, в противном случае возвращает 304, без изменений. Это легко понять неправильно, заставив людей думать, что ответ не кэшируется. На самом деле Cache-Control: no-cache будет кэшироваться, но каждый раз, когда данные ответа предоставляются клиенту (браузеру), кэш должен оценивать достоверность кэшированного ответа серверу.
на самом деле будетCache-ControlУстановить какno-storeЭто реальный смысл не кэшироваться, а затем изменить егоnginxфайл будетCache-ControlУстановить какno-storeПосмотрите, что происходит. В этот момент снова обновите браузер.
Как видите, модифицировалnginxПосле файла конфигурации, за исключением того, что в первый раз это 304 (на этот раз браузер только что получил информацию об отсутствии сохранения, а заголовок запроса все еще содержит информацию, связанную с кешем), остальная часть страницы обновляется, возвращая 200. Ни сильный кеш, ни согласованный кеш не попали. смотря наindex.jsИнформация о http-заголовке файла.
Я не вырезал здесь всю картинку, на самом деле заголовок ответа также содержитCache-Control: no-store. Видно, что вCache-Control: no-storeПо благословению, даже если служба вернет параметры кэша согласования в заголовке ответа, но когда браузер запрашивает ресурс, он не приводит параметры, относящиеся к кешу, поэтому теперь нет кеша, он не будет ударить по сильному Кэш не будет попадать в кеш согласования, а ресурсы каждого HTTP-запроса возвращаются с сервера.
Эпилог
Это исследование подошло к концу, фактически, это запись моего обучения. После того, как я попрактиковался один раз, у меня появилось более четкое понимание тайника, и я действительно узнал правду. В будущем я планирую записать статью о том, как использовать ресурсы фронтенда после того, как фронтенд будет упакован такими фреймворками, как React.js или Vue.js.nginxЕсть статьи про развёртывание и настройку родственных кешей, а дальше посмотрю, есть ли смысл их записывать.
Наконец, спасибоПрочитав это, я все еще не знаю кэш, пожалуйста, ударьте меняавтор статьиСанмей, часть объяснения про поле кэша в статье прямо скопирована из его статьи.
Поправьте меня, если в статье есть ошибки.
Справочная статья:Прочитав это, я все еще не знаю кэш, пожалуйста, ударьте меня