Я разрабатываю систему кеширования для платформы электронной коммерции, которая будет использовать обратный прокси-сервер для кэширования. Я планирую обрабатывать аннулирование, используя правильные заголовки HTTP / 1.1. То есть я устанавливаю ETag для первого поколения контента и кэширую это значение ETag в приложении. Заголовок Cache-Control будет указывать «must-revalidate», поэтому прокси-сервер должен устанавливать заголовок If-None-Match для последующих запросов с ETag. Приложение будет искать кэшированное значение ETag и, если оно совпадает, отправит ответ 304, в противном случае сгенерирует полный ответ 200.
Я надеялся использовать nginx, но я не могу точно сказать, поддерживает ли он ETags (в документации указано, что это не так, но, возможно, они устарели?). Лак - еще один вариант, но я здесь тоже не уверен.
Какие обратные прокси-серверы полностью поддерживают ETags? Я бы хотел, чтобы он кэшировал несколько версий, чтобы я мог выполнять такие вещи, как сплит-тестирование, не отключая кеш. То есть HTTP / 1.1 указывает, что клиент может отправить If-None-Match с несколькими значениями ETag, и сервер должен ответить, с каким ETag сопоставлен (если есть). Если бы обратный прокси-сервер хранил несколько копий, а не только последнее обнаруженное значение, и позволял серверу указывать при каждом запросе, что использовать, это было бы идеально.
nginx требует сторонних модулей для поддержки ETag. И здесь два из них.
Я только что проверил исходный код Varnish, и хотя он поддерживает If-Modified-Since и If-None-Match заголовки, он не поддерживает must-revalidate в Cache-Control. Единственные поддерживаемые атрибуты в Cache-Control являются max-age и s-max-age.
Ссылки:
bin/varnishd/cache/cache_rfc2616.cв RFC2616_Do_Cond ()bin/varnishd/cache/cache_rfc2616.c в RFC2616_Ttl()include/tbl/http_headers.hВы можете посмотреть на Сервер Apache TrafficServer, что кажется есть то, что тебе нужно.
Поправьте меня, если я ошибаюсь, и я знаю, что это старый пост, но я хотел бы прокомментировать для новых прохожих. Я считаю, что кеш обратного прокси не помогает при использовании ETags.
Механизмы кэширования проверки используют исходный сервер для проверки того, является ли ETag (или дата последнего изменения) в запросе все еще действительным (соответствует или не совпадает с etag ресурсов, в зависимости от того, какой заголовок используется, или был / не был изменен с даты, указанной в запросе).
Это означает, что обратный прокси-кеш, такой как Varnish, по-прежнему будет передавать этот запрос на исходный сервер. Он может ответить запросом вместо того, чтобы сервер обработал его, но вы не сохранили путь туда и обратно на исходный сервер.
Браузеры могут кэшировать ответы и обрабатывать ответ 304 в любом случае, поэтому частный кеш пользователя может быть лучше приспособлен для обработки этого, чем использование обратного прокси (YMMV, особенно в масштабе и, конечно, в зависимости от вашего варианта использования. Я не хотите сделать предположения о ваших приложениях).
Из спецификации 13,3:
Когда в кеше есть устаревшая запись, которую он хотел бы использовать в качестве ответа на запрос клиента, он сначала должен проверить с исходным сервером (или, возможно, с промежуточным кешем со свежим ответом), чтобы увидеть, можно ли его кешированную запись по-прежнему использовать. . Мы называем это «проверкой» записи кэша. Поскольку мы не хотим оплачивать накладные расходы на повторную передачу полного ответа, если кешированная запись в порядке, и мы не хотим оплачивать накладные расходы на дополнительный круговой обход, если кешированная запись недействительна, протокол HTTP / 1.1 поддерживает использование условных методов.
а затем обратите внимание 13.3.4:
Кэширующий прокси-сервер HTTP / 1.1 после получения условного запроса, который включает дату последнего изменения и один или несколько тегов объекта в качестве валидаторов кеша, НЕ ДОЛЖЕН возвращать клиенту локально кэшированный ответ, если этот кешированный ответ не согласуется со всеми поля условного заголовка в запросе.
Итак, Varnish может вернуть вам ответ, но у вас все еще есть обратный путь к серверу. Если вы можете использовать кеш приложения, такой как APC или memcache, то это все равно того стоит. Однако кэширование проверки обычно лучше для экономии полосы пропускания, чем для экономии ресурсов сервера.
Кэширование валидации лучше всего оставить на усмотрение клиента (браузер или код API).
Использование модели Expiration для кэширования - вот где действительно проявляется кеш обратного прокси. Это позволяет вам вообще пропустить обращение к исходному серверу. С помощью Expires, Cache-Control, Dateи т. д., является лучшим (опять же, IMO) механизмом для обратного прокси-кеша, поскольку кеш может возвращать ответ, предполагая, что он не устарел, даже не затрагивая исходный сервер.
На сегодняшний день я считаю, что до сих пор нет прокси, полностью поддерживающих эту спецификацию HTTP. Итак, около года назад я решил написать свой собственный, используя Node.js и MongoDb.