Разбирание в Завершающих тегах
Я читал книгу, и у меня есть конкретный вопрос о главе Завершающего тега. Автор говорит, что Завершающие теги могли бы вредить производительности и что необходимо настроить их точно или отключить их полностью.
Я уже знаю, какие Завершающие теги являются и понимают риски, но это что трудно разобраться в Завершающих тегах?
Я только что подал заявку, которая отправляет Завершающий тег, значение которого является хешем MD5 органа по ответу. Это - простое решение, легкое достигнуть на многих языках.
Использует хеш MD5 органа по ответу как Завершающий тег неправильно? Если так, почему?
Почему автор (кто, очевидно, перехитряет меня многими порядками величины) не предлагает такого простого решения?
На этот последний вопрос трудно ответить, если Вы не автор :), таким образом, я пытаюсь найти слабые места использования хеша MD5 как Завершающий тег.
3 ответа
ETag похож на заголовок Last-Modified. Это механизм для определения изменения клиентом.
Возможно, что ETag, который ДЕЙСТВИТЕЛЬНО совпадает с датой Last Modified (т.е. тот же текст), отвечает всем критериям, необходимым для ETag. Он просто должен быть уникальным значением, представляющим состояние ресурса. Не уникальным во всем домене ресурсов, а только в пределах ресурса.
Теперь, технически, ETag имеет "бесконечное" разрешение по сравнению с заголовком Last-Modified. Last-Modified изменяется только с дискретностью в 1 секунду, в то время как ETag может быть субсекундным.
Вы можете реализовать и ETag, и Last-Modified, или просто одно или другое (или ни одного, конечно). Если Last-Modified недостаточно, подумайте об ETag.
Учтите, я бы не стал устанавливать ETag для "каждого" ресурса. В основном, я бы не стал устанавливать его для всего, что не ожидает кэширования (в частности, для динамического контента). В этом случае нет никакого смысла, только напрасная работа.
Edit: Я вижу вашу правку и уточняю.
MD5 - это нормально. Единственным недостатком является постоянное вычисление MD5. Выполнять MD5, скажем, для 200K PDF файла, дорого. Выполнение MD5 на ресурсе, который не ожидает кэширования, просто расточительно (т.е. динамический контент).
Хитрость заключается в том, что какой бы механизм вы ни использовали, он должен быть таким же дешевым, каким обычно является Last-Modified. Last-Modified, опять же, обычно является свойством ресурса, и доступ к нему обычно очень дешев.
ETags должен быть таким же дешевым. Если вы используете MD5, и вы можете кэшировать/хранить ассоциацию между ресурсом и хэшем MD5, то это отличное решение. Однако, пересчет MD5 каждый раз, когда требуется ETag, противоречит идее использования ETags для повышения общей производительности сервера.
Не читая книгу, я не могу говорить о точных опасениях автора.
Однако генерация ETag должна быть такой, чтобы ETag генерировался только один раз при изменении страницы. Создание хэша MD5 веб-страницы требует вычислительной мощности и времени на сервере; если у вас много подключенных клиентов, это может вызвать проблемы с производительностью.
Таким образом, вам нужна хорошая техника для генерации ETags только , когда это необходимо, и их кэширования на сервере до тех пор, пока соответствующая страница не изменится.
Я думаю, что видимая проблема с ETAGS, вероятно, заключается в том, что ваш браузер должен выдать и разобрать (простой и небольшой) запрос / ответ для каждого ресурса на вашей странице, чтобы проверить, изменилось ли значение etag на стороне сервера.
Лично я считаю эти дополнительные небольшие обходы сервера приемлемыми для часто меняющихся изображений, css, javascript (серверу не нужно повторно отправлять содержимое, если etag браузера является актуальным), поскольку механизм позволяет довольно легко помечать "обновленный" контент.