Получение ETags правильно
Я читал книгу, и у меня есть конкретный вопрос о главе ETag. Автор говорит, что ETag могут повредить производительности, и что вы должны точно их настроить или полностью отключить.
Я уже знаю, что такое ETag, и понимаю риски, но так ли трудно получить ETag правильно?
Я только что сделал приложение, которое отправляет ETag, значением которого является хэш MD5 тела ответа. Это простое решение, которого легко достичь на многих языках.
Использует ли MD5-хэш тела ответа как ETag неправильно? Если так, то почему?
Почему автор (который явно опережает меня на много порядков) не предлагает такого простого решения?
На этот последний вопрос сложно ответить, если вы не автор:), поэтому я пытаюсь найти слабые стороны использования хеша MD5 в качестве ETag.
4 ответа
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, опять же, как правило, является свойством ресурса и обычно очень дешев для доступа.
ETags должны быть такими же дешевыми. Если вы используете MD5, и вы можете кэшировать / сохранять связь между ресурсом и хешем MD5, то это прекрасное решение. Однако пересчет MD5 каждый раз, когда необходим ETag, в основном противоречит идее использования ETag для повышения общей производительности сервера.
Мы используем etags для нашего динамического контента в инстела.
Наша стратегия заключается в конце вывода, генерирующего хэш md5 содержимого для отправки, и если заголовок if-none-match существует, мы сравниваем заголовок с сгенерированным хешем. Если два значения одинаковы, мы отправляем код 304 и прерываем запрос, не возвращая никакого контента.
Это правда, что мы используем немного процессора для хэширования контента, но в итоге мы экономим большую пропускную способность.
У нас есть главная страница в стиле новостной ленты на Facebook, которая имеет разный контент для каждого пользователя. Поскольку содержание новостной ленты изменяется только 3-4 раза в час, обновление главной страницы настолько эффективно для клиентской стороны. В эпоху мобильных устройств я считаю, что лучше тратить немного больше времени на процессор, чем на трафик. Пропускная способность по-прежнему дороже, чем процессор, и это лучший опыт для клиента.
Не читая книгу, я не могу говорить о точных проблемах автора.
Однако генерация ETag должна быть такой, чтобы ETag генерировался только один раз, когда страница изменилась. Генерирование MD5-хеша веб-страницы требует вычислительной мощности и времени на сервере; если у вас много клиентов, подключающихся, это может привести к проблемам с производительностью.
Таким образом, вам нужен хороший метод для генерации ETag только при необходимости и кэширования их на сервере, пока не изменится соответствующая страница.
Я думаю perceived problem с ETAGS, вероятно, ваш браузер должен выдавать и анализировать (простой и небольшой) запрос / ответ для каждого ресурса на вашей странице, чтобы проверить, изменилось ли значение etag на стороне сервера.
Лично я нахожу, что эти сверхкрупные переходы на сервер приемлемы для часто меняющихся изображений, CSS, Javascript (серверу не нужно повторно отправлять контент, если в браузере указан etag), так как механизм довольно легко маркирует "обновленный" контент.