Получение ETags правильно

Question

Я читал книгу, и у меня есть конкретный вопрос о главе ETag. Автор говорит, что ETag могут нанести вред производительности, и вы должны точно их настроить или полностью отключить.

Я уже знаю, что такое ETag, и понимаю риски, но так ли трудно получить ETag, верно?

Я только что создал приложение, которое отправляет ETag, значение которого является хешем MD5 тела ответа. Это простое решение, которого легко достичь на многих языках.

• Использует ли MD5-хэш тела ответа как ETag неправильно? Если так, то почему?

• Почему автор (который явно опережает меня на много порядков) не предлагает такого простого решения?

На этот последний вопрос сложно ответить, если вы не автор :), поэтому я пытаюсь найти слабые стороны использования хеша MD5 в качестве ETag.

Answer 1

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

Возможно, ETag, который ПРОСТО СЛУЧАЕТСЯ быть датой последнего изменения (т.е. того же текста), отвечает всем критериям, необходимым для ETag. Это просто должно быть уникальное значение, представляющее состояние ресурса. Не уникален во всем домене ресурсов, просто внутри ресурса.

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

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

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

Редактировать: я вижу ваши правки и уточняю.

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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