Вопросы Теги

То, как Сквид знает, является ли это кэш, проверен

В обратном режиме прокси Сквид может кэшировать содержание с веб-сайтов, к которым ранее получают доступ устройства в сети.

Что происходит, если содержание на удаленном сайте изменяется в некоторым образом, возможно, нажатием кода? Как Сквид знает, что должен перейти к исходному сайту для получения новой версии актива, вместо он - кэш?

Это - больше проблемы теперь с основанным на JavaScript динамическим (единственная страница) сайты?

Вопрос о стороне: "реверс является прокси", по существу то же самое как "режим акселератора" для Сквида?

3
задан 25 July 2014 в 10:55
1 ответ

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

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

Expires: Fri Jul 25 10:19:36 CEST 2014 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

Технически каждый из этих заголовков сам по себе уже достаточен, чтобы объявить содержимое ответа динамическим, но общепринятая мудрость, похоже, все равно использует их все. Программирование культа груза или обратная совместимость?

Cache-Control - это заголовок, который должен вас больше всего волновать. Это инструкции по кэшированию как для Squid reverse proxy, так и для любых промежуточных кэширующих прокси-серверов вплоть до реального браузера. Варианты:

  • private или public; частный ответ специфичен для пользователя и не должен быть кэширован, публичный ответ может быть кэширован.
  • no-cache делает в основном то, что звучит, и является инструкцией по повторной проверке ресурса для каждого последующего запроса. Хотя после подтверждения ресурса все еще действителен, кэшированный ответ все еще может быть использован.
  • no-store четкая инструкция, что ответ должен рассматриваться как конфиденциальный и не храниться вообще, немного сильнее, чем вариант no-cache выше.
  • max-age в секундах перекрывает заголовок Expires и дает инструкции, когда ресурс истекает и должен быть очищен от кэша.
    • s-maxage в секундах то же самое, что и выше, но для общего кэша, например, для сетей доставки контента.

Expires является классическим способом установки кэш-инструкции, с простой меткой времени не более 1 года в будущем.

Pragma - это действительно заголовок старой школы, установка его на no-cache будет интерпретироваться любым недавним браузером как Cache-Control: no-cache и я думаю, что он больше не присутствует в более поздних спецификациях протокола HTTP, хотя все еще удостоен чести за историческую совместимость с back-ward.

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

Cache-Control: no-transform,public,max-age=300,s-maxage=900
Content-Type: text/html; charset=UTF-8
Date: Fri Jul 25 10:19:36 CEST 2014 GMT
Expires: Sat Jul 26 10:19:36 CEST 2014 GMT

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

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

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

И да, в контексте Squid обратный прокси и веб-акселератор являются то же самое.

4
ответ дан 3 December 2019 в 06:06

Теги

Похожие вопросы