4. 2021
Arg
#10PinesConf
¿PARA QUÉ
SIRVE UNA
CACHÉ HTTP?
😴
Cache
🏃
♀️
🏃
♀️
🏃
♀️
🏃
♀️
🏃
♀️
🏃
♀️
🏃
♀️
🏃
♀️
🌎
🙋
♀️
Ya la
tenemos
👨🔧
👩🔧
A construir!
Sí. La
tenemos
😴
Web
server
Web
server
Web
server
6. 2021
Arg
#10PinesConf
¿EN DONDE
ESTÁ LA
CACHÉ? En el contexto de HTTP pueden estar en:
Browser (Chrome, Firefox, Safari..)
Servidor intermediario local (Proxy en la oficina)
Servidor intermediario externo (Cloudflare, Akamai)
🌎
7. 2021
Arg
#10PinesConf
¿PARA QUÉ
SIRVE UNA
CACHÉ HTTP?
● Reducir o eliminar latencia.
● Reducir o eliminar carga en el servidor web.
● Evitar la transferencia de datos a través de la red.
● Ahorrar uso de datos (4g) al evitar su transferencia.
12. 2021
Arg
#10PinesConf
1990 1991
Primer web
server
HTTP/0.9
1996
HTTP/1.0
1997 1999
HTTP/1.1
Mejoras
HTTP/1.1
Sólo soporta
GET
Resumen de
prácticas comunes
Primera
especificación
oficial
Expires
If-Modified-Since
Cache-control
Tweaks
varios
2015
HTTP/2
HTTP se hace
público
Extensiones y
mejoras
Aparece el cacheo
14. 2021
Arg
#10PinesConf
ESTADO DE LA
WEB 2020
Oportunidades de mejora:
Sólo 3% de los sitios obtuvo puntuación perfecta
66% de los sitios obtuvo menos de 40/100
Ahorros en transferencia de datos:
El 21% puede ahorrarse más de 2MB
Fuente: https://almanac.httparchive.org/en/2020/caching#identifying-caching-opportunities
27. 2021
Arg
#10PinesConf
Che, necesito la
imag… Ah, no, para!
Todavia sirve…
Todavia sirve
logo.png
Fua, eso fue
rápido!
Cliente
Cliente
Caché
Rapidez es
mi segundo
nombre
Web
server
Ay no! no me
están
pidiendo el
nuevo logo!
34. 2021
Arg
#10PinesConf
Che, necesito la
imagen logo.png
Tomá, guardatela y
usala 1 semana sin
preguntarme
Cliente
Web
server
logo.png
Cliente
logo.png
¿Qué sucede luego
de esa semana?
35. 2021
Arg
#10PinesConf
Otra vez a
procesar lo
mismo!
🤔
😧
😊
Ojalá pudiera
avisarle que
la respuesta
anterior aún
le sirve
Es igual! Ojalá
pudiéramos
comunicarnos
mejor
Venció! a pedir la
versión
actualizada!
Web
server
1
2
3
44. 2021
Arg
#10PinesConf
Conclusiones
● Sirve para reducir latencia, reducir carga,
mejorar velocidad y reducir transferencia
de datos
● Puede ser local/privado o remoto/público
● Se puede usar el mecanismo de frescura
con o sin validación
● ¿Por dónde empiezo? -> Revving + larga
duración para archivos estáticos
Una Caché o Cache en ingles
Componente de hardware o de software que guarda datos para ser recuperados luego de una forma más rápida
Esto sirve como optimizacion ya que permite acceder a los datos de una forma mas rápida de lo que se accede normalmente desde su fuente original
Como ejemplo tenemos:
En hardware, la memoria Caché de una CPU (memoria incorporada dentro del procesador que es más rapidade acceder que la memoria RAM)
En software, existe la técnica de memoización de funciones (memoization): Consiste en guardar en memoria el resultado de un calculo pesado para evitar tener que repetirlo
Y por utlimo, tambien en software, tenemos los Cachés HTTP que son de los que vamos a hablar en esta charla
Iconos:
Icons made by https://www.freepik.com from https://www.flaticon.com
https://www.flaticon.com/free-icon/cpu_911412?related_id=911514&origin=search
https://www.jimphicdesigns.com/downloads/download-page.php?id=15
Genial!Ahora ya sabemos Qué es una Caché.
A mi me gustaría además compartirles muchas otras preguntas que me hice en su momento.
Por ejemplo... ¿para qué sirve?
Pero esta es una pregunta que voy a intentar contestar más adelante.Porque primero quiero que pensemos en … PASAR SLIDE
¿Qué sucede en una request? En donde no hay ninguna caché involucrada.
Si ahora mismo abro mi browser y entro a una pagina web, muchas requests van a ocurrir para que yo pueda ver a la pagina renderizada.Cada una de esas requests va a llegar a un Web server.
Y el web server va a tener que armar la respuesta de lo que se le pide.Alguna de esas requests pueden ser: una para pedir alguna imagen, otra para pedir un archivo CSS, otra para obtener algún dato: por ejemplo si es un diario, ese dato podrían ser las diferentes noticias.
Y acá en el dibujo vemos que del lado del web server está la frase “A construir!” haciendo referencia a que hay que armar esa respuesta.
Y para armarla podría ser necesario acceder a alguna Base de Datos, Hacer cálculos, ambas o incluso hacer requests a otros web servers, tener que esperar su rta para armar la propia.En definitiva Construir lleva tiempo! Y esa es la conclusión con la que quiero que nos quedemos. PASAR SLIDE
Pero Volvamos a las preguntas de la caché.
La primera era ¿para qué sirve? y para poder responderla quiero seguir dando más contexto y contarles en dónde está.
Recordemos que Maty nos mencionó diferentes tipos de caché pero que vamos a enfocarnos en el mundo HTTP.
En ese mundo, la caché puede residir en:
Un Browser, en el propio dispositivo de quien está visitando un sitio web.
Un Servidor intermediario LOCAL, por ejemplo un Proxy en una oficina desde la cual hayan personas accediendo a la web.
Ó En un Servidor intermediario externo como por ej un CDN como Cloudflare ó Ákamai
Y Ahora sí!Para qué sirve?
Bueno, Voy a mencionar 4 usos. Pero primero quiero aclarar que dependiendo del escenario, se pueden lograr todos o no.
El primer uso es para reducir o eliminar latencia.
El 2do...
Recién vimos qué sucede en cada request. Ahora veamos qué sucede en cada request si efectivamente HAY una caché.
Para eso vamos a ver este 1er ejemplo.
Tenemos una persona usando un Browser, al que llamaremos Cliente, que está en Argentina.Vemos que necesita hacer una request y en vez de hacerla al Web Server, la hace al Server Intermediario Externo Que le pusismos “Caché” en el dibujo, que en este caso tmb está en Argentina. Podría no estarlo.
Y que tiene la respuesta para darle al cliente. Y se la da.
Entonces, en este caso logramos:
Reducir latencia. Porque si tuviesemos que hacer la request al Web Server, habria que hacerla a Alemania que está mucho más lejos.Y digo Reducir latencia porque no logramos eliminarla. La request hay que hacerla de todas formas ya que la caché está en un servidor en algún lugar de Argentina.
Eliminar carga en el servidor web, porque ni se entera de la request, entonces no tiene que construir nada.Veamos otro ejemplo PASAR SLIDE
Tenemos un browser que puede estar en una compu o en un celular. Tambien necesita hacer una request, pero esta vez utiliza la caché del Browser que es interno a cada dispositivo.
Entonces, en este caso logramos:
No solo reducir, sino Eliminar latencia. Porque ni siquiera hay que salir a la red.
Tambien logramos Eliminar carga en el servidor web. Que de nuevo ni se entera de la request.
Por otro lado Evitamos la transferencia de datos a través de la red porque estan dentro del browser.
Y eso nos lleva a Ahorrar uso de datos. Que este punto se refiere especialmente al uso desde el celular.
Ahora Maty nos va a contar un poquito de historia.PASAR SLIDE
Y desde cuando existen los Cachés HTTP?
Si miramos la historia del protocolo HTTP podemos identificar algunos hitos importantes
1991: Se considera el inicio de la web. En ese momento el protocolo era muy simple, solo existían las requests GET
1991-1996: hay una explosion de implementaciones independientes tanto de navegadores como servidores web
1996: Con lo cual en 1996 se hace una recopilacion de las prácticas comunes (usadas en estas implementaciones independientes) y se denomina a esa recopilacion: HTTP 1.0. Esto no era aun una especificacion
1997: Se crea la primera especificacion denominada HTTP 1.1
Entre 1996 y 1997 se definen la mayoria de herramientas de caché disponibles en HTTP hoy en dia.
Es decir, lo que vamos a contar en esta charla tiene alrededor de 25 años de existencia
En 1990 se crea el primer web server. En 1991 Tim Berners-Lee hace pública la idea de HTTP y el 6 de Agosto se considera el inicio de internet. No había especificación formal, solo lo que se construyó en el CERN por el proyecto World Wide Web.
HTTP/1.0: https://datatracker.ietf.org/doc/html/rfc1945
HTTP/1.1: https://tools.ietf.org/html/rfc2068
Mejoras HTTP/1.1: https://datatracker.ietf.org/doc/html/rfc2616
Con Orne nos preguntamos, que tanto se usa esto en el mundo?
Investigando encontramos que el proyecto abierto “HTTP archive” (archivo de HTTP en Español) publica un reporte llamado “web almanac” en donde se muestran los resultados de analizar la performance de millones de sitios web.
En el año 2020 analizaron 7 millones de sitios web con herramientas automatizadas como Lighthouse de Google para calcular diferentes métricas y así entender “el estado de la web”
El informe la verdad es muy interesante, les recomiendo que lo miren porque se puede aprender bastante. \
En una de las secciones el informe habla de qué tan bien se usan los cachés. El resultado en la sección de oportunidades de mejora muestra que solo el 3% de los sitios obtuvo una puntuación perfecta. El 97% de los sitios tienen alguna oportunidad de mejora.
Además, el 66% de los sitios, sacaron una puntuación muy baja, menor o igual a 40/100
Analizando el tamaño de las requests se puede ver que el 21% de los sitios podrian ahorrarse mas de 2MB de descargas si usaran la caché de una mejor forma.
Quizas 2MB no parece mucho, pero si tenemos en cuenta que mucha gente aun accede a internet usando una conexion movil 3G, esto es un problema. Porque descargar 2MB usando una conexion 3G es algo que tarda algunos segundos. Por lo tanto es imposible brindar una excelente experiencia de usuario en estas condiciones
https://almanac.httparchive.org/en/2020/caching#identifying-caching-opportunities
Bueno, y como se usa?
Para eso les pido que me acompañen a ver como es un dia normal en la internet
Frescura o freshness
Y cómo funciona?
La decision de usar frescura es del servidor
Bueno fantastico, entonces con esto solucionamos todo
Pero entonces me pregunto, funcionara siempre esto? parece muy facil. Veamos algo mas
El equipo de diseño de 10Pines decide cambiar el logo de la pagina.
Claro, como el web server dijo que no era necesario que le pregunten hasta el dia siguiente, entonces nadie habla con el web server. Y por como funciona HTTP, el web server no puede avisar que la imagen cambió
Revving: https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Immutable es una extension a HTTP que se publicó en el 2017 y que algunos browsers podrían no soportar
https://httpwg.org/specs/rfc8246.html#the-immutable-cache-control-extension
En el ejemplo de Maty, cuando el Web Server responde con el logo dice que puede guardarse por 1 semana.Y yo me pregunto:¿Qué sucede luego de esa semana?
Vamos a ver un ejemplo PASAR SLIDE
El browser dice “Venció!...” ya no está más vigente lo que se guardó en la caché.
Hace la request.
El Web server ve la request y se da cuenta de que otra vez tiene que procesar lo mismo para el mismo cliente. Y reflexiona que Ojalá pudiera avisarle que la respuesta anterior aun le sirve.
Al Browser le llega la rta y se da cuenta de que es igual a la que tenia cacheada. Es decir, realmente no estaba vencida.
Y reflexiona que ojalá pudieran comunicarse mejor.
Bueno, esto es ficción, el browser no se va a poner a comparar si la rta nueva era igual a la anterior. El server tampoco va a ponerse a sacar conclusiones.
Pero nos gustó esta ficción para poder mostrarles el ejemplo.
PASAR SLIDE
Hay una técnica llamada Validación para comprobar si una rta cacheada sigue siendo buena. PASAR SLIDE
Para mostrar cómo funciona quiero que recordemos de qué se compone una response HTTP.
Tiene:
Body con la información pedida. Por ej: el logo
Status. Por ej: 200 si todo salió bien.
Header con más información.
Dentro del Header encontraremos:
Validador
Teniendo eso en mente, vamos a ver un ejemplo. PASAR SLIDE
Del lado izquierdo vamos a hacer por 1era vez cierta request al web server.
Y Como decia recien, la response que devuelve tiene un Validador.
El browser no solamente va a guardar en su caché el body de la respuesta (el logo por ej). Va a guardar tambien al validador, recuerden que se guarda la request entera en la caché.
Entonces, en el lado derecho vemos que una vez que quede obsoleto lo guardado en la caché, Por ej porque ya pasó esa semana entera de los ejemplos anteriores.
El browser va a hacer una request condicional, para lo cual va a enviar a ese Validador que tenia guardado. PASAR SLIDE
Yendo más a lo implementativo. Hay dos tipos de validadores:
Last-modified
Etag es un string opaco.
Como decíamos, estos validadores son enviados en las responses, en el header. Sí, ambos tipos de validadores pueden ser enviados en cada response.
Vamos a ver otro ejemplo
PASA SLIDE
De nuevo en el sitio de 10pines.
Esta vez vamos a centrarnos en una request que busca tambien una imagen, que es la que esta ahi.
Pueden ir a buscarla ustedes tmb entrando al sitio de 10pines, está en el footer.
Bueno, en este ejemplo vemos que es la
La 1era vez que hacemos esta request. Llega al web server y nos responde agregando al famoso validador en la response.
Si mientras hacemos esta request abrimos las Developer tools del Browser y vamos a la sección de Network podemos buscar la request de esta imagen y ver un poquito más en profundidad qué nos está devolviendo.
Tiene un status 200, nos devolvió la imagen satisfactoriamente y nos dio los validadores etag y last modified.
Y ya casi cerrando, vamos a ver: ¿Qué pasa la proxima vez que hagamos esta request? Es una proxima vez en donde lo que tenemos cacheado supuestamente ya expiró. Nos dijeron que podiamos guardar la rta 1 semana y ya terminó.Dijimos que en ese caso ibamos a enviar los validadores.. es decir, hacer una request condicional.Pero Hasta ahora no habíamos hablado de cómo es la forma que tiene el Browser para enviar esos “validadores”.Vamos a echar un vistazo de nuevo a las dev tools del browser mientras hacemos la request.
Vemos que en los headers No hay mencion al etag ni al last modified, que eran nuestros validadores.
Eso es porque usamos otros atributos para enviarlos: ifmodifedsince y if none match.
Y si vemos la rta notamos que tenemos:
304 = Not Modified
El browser ahora sabe que puede seguir usando la imagen que ya tiene guardada en su cachéY tambien vemos que nos vuelve a dar el etag y el last modifed.
Bueno, este fue nuestro último ejemplo. Ahora vamos a pasar a unas últimas conclusiones.