В режиме обратного прокси Squid может кэшировать контент с веб-сайтов, к которым ранее обращались устройства в сети.
Что произойдет, если содержимое удаленного сайта каким-либо образом изменится, например, из-за нажатия кода? Как Squid узнает, что ему нужно перейти на исходный сайт, чтобы получить новую версию ресурса, вместо его кеша?
Это больше проблема для динамических сайтов на основе javascript (одностраничных)?
Дополнительный вопрос: "Обратный прокси" по сути то же самое, что "режим ускорителя" для Squid?
Да, Squid кэширует ответы от внутреннего сервера (ов), используя обычный метод интерпретации заголовков, которые внутренний сервер отправляет с каждым ответом.
Типичный ответ для динамического содержимого, которое не следует кэшировать, выглядит примерно так:
Expires: Fri Jul 25 10:19:36 CEST 2014 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Технически каждый из этих заголовков сам по себе уже достаточен для объявления содержимого динамического ответа, но общепринятое мнение, кажется, все еще использует их все. Культ карго или обратная совместимость?
Кэш-контроль - это заголовок, который вас больше всего беспокоит. Это инструкции по кэшированию как для вашего обратного прокси-сервера Squid, так и для любых промежуточных кэширующих прокси-серверов, вплоть до самого браузера. Возможные варианты:
private или public ; частный ответ специфичен для пользователя и не должен кэшироваться, публичный ответ может кэшироваться.no-cache делает в основном то, что звучит, и представляет собой инструкцию для повторной проверки ресурса для каждого последующего запроса. Хотя после проверки подтверждено, что ресурс все еще действителен, кэшированный ответ все еще может быть обработан. no-store четкая инструкция о том, что ответ должен рассматриваться как конфиденциальный и не храниться вообще, немного сильнее, чем вариант без кеширования выше.max-age в секундах переопределяет заголовок Expires и указывает, когда ресурс истек и должен быть удален из кеша. s-maxage в секундах, как указано выше, но для общих кешей, таких как сети доставки контента.Истекает это классический способ установки инструкции кеширования с простой меткой времени не более чем на 1 год в будущем.
Прагма это действительно олдскульный заголовок, установив его на no-cache будет интерпретироваться любым последним браузером как Cache-Control: no-cache и я думаю, что он больше не присутствует в более поздних спецификациях протокола HTTP, хотя по-прежнему учитывается за историческую обратную совместимость.
Заголовки, установленные для более статичного содержимого, должны указывать 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 обратный прокси и веб-ускоритель тоже самое.