Какие обратные прокси-серверы поддерживают заголовки HTTP/1.1 ETag и If-None-Match?
Я разрабатываю систему кеширования для платформы электронной коммерции, которая будет использовать обратный прокси для кеширования. Я планирую обработать недействительность, используя надлежащие заголовки HTTP/1.1. То есть я установлю ETag для первого поколения контента и кеша этого значения ETag в приложении. Заголовок Cache-Control будет указывать "must-revalidate", поэтому прокси должен устанавливать заголовок If-None-Match при последующих запросах с ETag. Приложение выполнит поиск кэшированного значения ETag и, если оно совпадет, отправит ответ 304, в противном случае будет сгенерировано полное значение 200.
Я надеялся использовать nginx, но не могу с уверенностью сказать, что он поддерживает ETag (документы указывают, что это не так, но, возможно, они устарели?). Лак это еще один вариант, но я не уверен, что здесь..
Какие обратные прокси-серверы имеют полную поддержку ETag? Я бы хотел, чтобы он на самом деле кэшировал несколько версий, чтобы я мог выполнять такие вещи, как сплит-тестирование, без необходимости отключения кэша. То есть HTTP/1.1 указывает, что клиент может отправить If-None-Match с несколькими значениями ETag, и сервер должен ответить, с каким ETag сопоставлено (если есть). Если обратный прокси-сервер хранит несколько копий, а не только последнее увиденное значение, и позволяет серверу указывать при каждом запросе, который использовать, это было бы идеально.
5 ответов
На сегодняшний день я считаю, что до сих пор нет прокси, которые полностью поддерживают эту спецификацию HTTP. Итак, около года назад я решил написать свой собственный, используя Node.js и MongoDb.
Я только что проверил в исходном коде 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
Для nginx требуются сторонние модули для поддержки ETag. И их два.
- Статические ETag для кеширования статического контента
- Динамические ETag для кеширования динамического контента
Поправьте меня, если я ошибаюсь, и я знаю, что это старый пост - но я бы хотел прокомментировать новых прохожих. Я считаю, что кэш обратного прокси-сервера не помогает так сильно, как вы хотели бы при использовании ETag.
Механизмы кэширования проверки используют исходный сервер для проверки того, является ли 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) механизм для обратного прокси-кэша, поскольку кэш-память может возвращать ответ, предполагая, что он не устарел, даже не попав на исходный сервер.
Вы можете посмотреть на Apache TrafficServer, который, кажется, имеет то, что вам нужно.