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

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

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

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

Использует ли MD5 хэш тела ответа как ETag неправильно? Если да, то почему?
Почему автор (который явно превосходит меня на многие порядки) не предлагает такого простого решения?

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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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