2010-02-18 12 views
32

He estado leyendo un libro y tengo una pregunta en particular sobre el capítulo ETag. El autor dice que los ETags pueden dañar el rendimiento y que debe sintonizarlos o deshabilitarlos por completo.Obtener ETags correctamente

Ya sé lo que son ETags y entiendo los riesgos, pero ¿es tan difícil conseguir ETags verdad?

Acabo de hacer una aplicación que envía un ETag cuyo valor es el hash MD5 del cuerpo de la respuesta. Esta es una solución simple, fácil de lograr en muchos idiomas.

  • ¿Está utilizando el hash MD5 del cuerpo de respuesta como ETag? Si es así, ¿por qué?

  • ¿Por qué el autor (que obviamente me supera en muchos órdenes de magnitud) no propone una solución tan simple?

Esta última pregunta es difícil de responder a menos que usted es el autor :), por lo que estoy tratando de encontrar los puntos débiles de la utilización de un hash MD5 como un ETag.

+6

Nunca es seguro asumir que un autor te supera un poco. – spender

+13

@spender: de acuerdo, pero es aún menos seguro asumir que usted es más astuto que el autor. – Oddthinking

+7

y ni siquiera vamos a tocar la inteligencia de los comentaristas web, de una forma u otra ;-) –

Respuesta

39

ETag es similar al encabezado Last-Modified. Es un mecanismo para determinar el cambio por parte del cliente.

Podría decirse que una ETag que SÓLO SUCEDE como la última fecha de modificación (es decir, el mismo texto) cumple con todos los criterios necesarios para una ETag. Simplemente necesita ser un valor único que represente el estado de un recurso. No es único en todo el dominio de recursos, simplemente dentro del recurso.

Ahora, técnicamente, un ETag tiene una resolución "infinita" en comparación con un encabezado Last-Modified. Last-Modified solo cambia con una granularidad de 1 segundo, mientras que un ETag puede ser sub segundo.

Puede implementar ETag y Last-Modified, o simplemente uno u otro (o ninguno, por supuesto). Si Last-Modified no es suficiente, entonces considere un ETag.

Ten en cuenta que no establecería ETag para "cada" recurso. Básicamente, no lo configuraría para nada que no tenga expectativas de ser almacenado en caché (contenido dinámico notablemente). No tiene sentido en ese caso, solo trabajo desperdiciado.

Editar: Veo su edición y aclaro.

MD5 está bien. El único inconveniente es calcular MD5 todo el tiempo. Ejecutar MD5 en, digamos, un archivo PDF de 200K, es costoso. Ejecutar MD5 en un recurso que no tiene ninguna expectativa de almacenamiento en caché es simplemente un desperdicio (es decir, contenido dinámico).

El truco es simplemente que sea cual sea el mecanismo que utilice, debe ser tan barato como lo es típicamente Last-Modified. Last-Modified es, de nuevo, típicamente, una propiedad del recurso y, por lo general, es de acceso muy económico.

ETags debe ser similarmente barato. Si está utilizando MD5, y puede almacenar en caché/almacenar la asociación entre el recurso y el hash MD5, entonces esa es una buena solución. Sin embargo, volver a calcular el MD5 cada vez que se necesita ETag es básicamente contrario a la idea de utilizar ETags para mejorar el rendimiento general del servidor.

+0

Gracias. En mi caso particular, ya tengo el MD5 porque estoy firmando digitalmente las solicitudes, pero veo que esto podría ser un problema de rendimiento para otros escenarios. ¡Gracias! –

+11

"una ETag que SÓLO SUCEDE como la última fecha de modificación (es decir, el mismo texto) cumple todos los criterios necesarios para una ETag". Esto no es cierto porque ambas respuestas, Gzipped y unGzipped, tendrían la misma fecha de modificación; sin embargo, deben tener diferentes Etags: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727 – johnstok

+11

"Ejecutar MD5 en, por ejemplo, un archivo PDF de 200 K, es caro" - por lo general, no, en los procesadores modernos MD5 es mucho más rápido que incluso Gbit Ethernet, y mucho menos las conexiones a Internet de los usuarios finales. Si sus ETags tienen la posibilidad de evitar incluso el 1% de las transferencias, probablemente compensan el tiempo de CPU utilizado. – intgr

0

Creo que perceived problem con ETAGS es probable que su navegador tenga que emitir y analizar una solicitud/respuesta (simple y pequeña) para cada recurso en su página para comprobar si el valor de etag ha cambiado en el lado del servidor.

Personalmente encuentro que estos pequeños viajes de ida y vuelta al servidor son aceptables para cambiar imágenes, css, javascript (el servidor no necesita volver a enviar el contenido si el etag del navegador es actual) ya que el mecanismo hace que sea bastante fácil marcarlo ' contenido actualizado

+0

El problema mencionado en el libro es que debes idear una estrategia especial y quizás __martilla__ (el autor incluso alienta a dejar de apoyar a los etags si no puedes encontrar una buena estrategia). Eso es lo que me parece raro, ¿es MD5 una buena solución? si es así, ¿por qué no decir eso? –

+0

Un "máximo de edad" o "Vencimiento" adecuado le indicaría al cliente cuánto esperar sin enviar siquiera ese pequeño "¿Hay algo nuevo?" solicitud. Para que pueda guardar los viajes de ida y vuelta también. –

+0

@Pablo Fernandez: MD5 está bien, pero yo personalmente no hackearía todo el contenido del archivo. Hashing la 'última fecha de modificación del archivo' debería ser suficiente. Acerca del bit '¿por qué no decir eso?': La respuesta probablemente esté en el título del libro (sitios web de alto rendimiento). Los Etags (y sus recorridos de ida y vuelta) agregan algunos gastos generales y podrían ser un factor importante a tener en cuenta en un servidor web muy cargado (pero al mismo tiempo agregan flexibilidad) ... – ChristopheD

1

Al no haber leído el libro, no puedo hablar sobre las preocupaciones exactas del autor.

Sin embargo, la generación de ETags debe ser tal que una ETag solo se genere una vez cuando una página ha cambiado. La generación de un hash MD5 de una página web le cuesta a los procesadores el poder y el tiempo en el servidor; si tiene muchos clientes conectados, podría comenzar a causar problemas de rendimiento.

Por lo tanto, necesita una buena técnica para generar ETags solo cuando sea necesario y almacenarlos en caché en el servidor hasta que la página relacionada cambie.

+1

Tengo que firmar digitalmente cada respuesta del servidor con un secreto compartido. Entonces el ETag fue un efecto secundario agradable :) –

4

Estamos utilizando etags para nuestro contenido dinámico en instela.

Nuestra estrategia está al final de la salida generando el hash md5 del contenido a enviar y si existe el encabezado if-none-match, comparamos el encabezado con el hash generado. Si los dos valores son los mismos, enviamos el código 304 e interrumpimos la solicitud sin devolver ningún contenido.

Es cierto que consumimos un poco de CPU para actualizar el contenido, pero finalmente estamos ahorrando mucho ancho de banda.

Tenemos una página principal de estilo de noticias de facebook que tiene un contenido diferente para cada usuario. Como el contenido del suministro de noticias cambia solo 3-4 veces por hora, las actualizaciones de la página principal son muy eficientes para el lado del cliente. En la era móvil, creo que es mejor gastar un poco más de tiempo de CPU que gastar ancho de banda. El ancho de banda es aún más caro que la CPU, y es una mejor experiencia para el cliente.

Cuestiones relacionadas