Получение правильных тегов ETags

ETag похож на заголовок Last-Modified. Это механизм определения изменений со стороны клиента.

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

Теперь технически ETag имеет бесконечное разрешение по сравнению с заголовком Last-Modified. Last-Modified изменяется только с шагом в 1 секунду, тогда как ETag может быть меньше секунды.

Вы можете реализовать как ETag, так и Last-Modified, или просто одно или другое (или, конечно, ни одного). Если вам недостаточно Last-Modified, рассмотрите вариант ETag.

Обратите внимание, я бы не стал устанавливать ETag для каждого ресурса. По сути, я бы не стал устанавливать его для чего-либо, что не предполагает кэширования (особенно динамического содержимого). В этом случае нет никакого смысла, просто потраченная впустую работа.

Изменить: я вижу ваше редактирование и уточняю.

MD5 в порядке. Единственный недостаток - постоянный расчет MD5. Использование MD5, скажем, для файла PDF размером 200 КБ обходится дорого. Запуск MD5 на ресурсе, который не ожидает кэширования, просто расточителен (т. Е. Динамический контент).

Хитрость заключается в том, что какой бы механизм вы ни использовали, он должен быть таким же дешевым, как и Last-Modified. Last-Modified, опять же, как правило, является свойством ресурса и обычно очень дешево для доступа.

ETags также должны быть дешевыми. Если вы используете MD5 и можете кэшировать / сохранять связь между ресурсом и хешем MD5, то это прекрасное решение. Однако пересчет MD5 каждый раз, когда требуется ETag, в основном противоречит идее использования ETags для повышения общей производительности сервера.

Мы используем etags для нашего динамического контента в instela.

Наша стратегия находится в конце вывода, генерируя хэш md5 контента для отправки, и если заголовок if-none-match существует, мы сравниваем заголовок с сгенерированным хешем. Если два значения совпадают, мы отправляем код 304 и прерываем запрос, не возвращая никакого содержимого.

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

У нас есть главная страница в стиле ленты новостей facebook, содержание которой разное для каждого пользователя. Поскольку содержание новостной ленты меняется всего 3-4 раза в час, обновления главной страницы настолько эффективны для клиентской стороны. В эпоху мобильных устройств я думаю, что лучше потратить немного больше времени на процессор, чем на пропускную способность. Пропускная способность по-прежнему дороже, чем ЦП, и это лучше для клиента.

Не прочитав книгу, я не могу говорить о конкретных опасениях автора.

Однако генерация ETag должна быть такой, чтобы ETag генерировался только один раз при изменении страницы. Создание хэша MD5 веб-страницы требует вычислительной мощности и времени на сервере; если у вас много подключенных клиентов, это может вызвать проблемы с производительностью.

Таким образом, вам нужна хорошая техника для создания ETags только при необходимости и их кэширования на сервере до тех пор, пока соответствующая страница не изменится.

Я думаю, что perceived problem с ETAGS, вероятно, заключается в том, что ваш браузер должен выдать и проанализировать (простой и небольшой) запрос / ответ для каждого ресурса на вашей странице, чтобы проверить, изменилось ли значение etag на стороне сервера.

Я лично считаю эти дополнительные небольшие обращения к серверу приемлемыми для часто меняющихся изображений, css, javascript (серверу не нужно повторно отправлять контент, если etag браузера является текущим), поскольку этот механизм позволяет довольно легко пометить «обновленный» контент.