DEBUG de peticiones en Transparent CDN

Los sistemas de caché, como Transparent CDN, pueden aportarnos infinidad de ventajas a nuestro sitio web, entre los que podemos destacar, reducción de los tiempos de la carga de la páginas, absorción de grandes volúmenes de tráfico, mejoras de la seguridad del portal o en ocasiones hasta una reducción de costes en infraestructura. Pues bien, como todas las cosas en este mundo tiene sus inconvenientes, pero no lo son tanto cuando comprendes cómo funciona una caché y el flujo de peticiones http.

Por eso, la intención de este post es la de explicar el funcionamiento interno de una petición http, analizar las cabeceras de la solicitud y la respuesta, y finalmente como interpreta eso una caché http.

Flujo HTTP 1

En la figura de arriba vemos el flujo de una petición web de un objeto http desde un cliente convencional al servidor web (sin pasar por ninguna caché) que alberga el site www.transparentcdn.com No parece muy complicado, ¿no? Vamos a analizarlo en más detalle.

En primer lugar, y por simplificar el tema al máximo, el cliente (después de establecer la conexión TCP con el servidor generalmente por el puerto 80) envía una solicitud http pidiendo, con el método GET, que le devuelva el objeto “ / ”(este objeto “barra” es la portada principal del site, si quisiera otro objeto, en lugar de “ / “, aparecería “/categorías” o “/imagen.png”). Junto con la petición GET el cliente envía una serie de cabeceras, todas opcionales a excepción de la cabecera Host.

La cabecera Host se utiliza para que los servidores configurados en modo multidominio sepan cual de todos los sitios web que tienen configurados tiene que servirle al cliente. En caso de no estar ésta cabecera, el servidor interpretará que debe servir el sitio web que tenga configurado por defecto.

Como digo, el resto de cabeceras son opcionales aunque los navegadores modernos suelen enviar bastante información en las cabeceras de la solicitud como el User Agent, que identifica el tipo de navegador que estamos usando para la petición, la cabecera Cookie que contiene información guardada en el navegador del usuario y que el sitio web usa para infinidad de cosas o la cabecera Referer que le dice al servidor de qué página venimos.

En la respuesta a esta solicitud, el servidor web además del contenido propiamente dicho, devuelve una serie de cabeceras, alguna de ellas bastante importantes para el tema que nos ocupa.

En la primera línea vemos que el servidor responde con un “HTTP/1.1 200 OK” , aquí el servidor le dice al cliente que el recurso que solicitaba ha sido encontrado y servido con éxito mediante el código 200. En la RFC2616, sección 10 se definen todos los códigos de estado que un servidor web puede devolver como respuesta a una solicitud http.

En segundo lugar, vemos la cabecera Cache-Control, que puede configurarse en el servidor web, bien a nivel de web server o bien a nivel de código y lo que hace es decirle al navegador del cliente (y todas las caches por las que pasa las request) que ese objeto debe actualizarse cada 2592000 segundos en este caso, o lo que es lo mismo, ese objeto puede guardarse en la caché del navegador durante 30 días.

El resto de cabeceras no vamos a entrar a analizarlas por no alargarnos mucho.

Ahora bien, ¿cómo sería esta petición si metemos una caché como Transparent CDN por medio? Vamos a verlo:

Flujo HTTP 2

Bueno parece que la cosa se complica un poco pero en realidad es más sencillo de lo que parece. He numerado los pasos que sigue la petición para facilitar un poco la explicación.

En primer lugar, y este paso no cambia, el cliente o navegador web hace una petición http, pero en este caso en lugar de ir directamente contra el servidor web va a pasar por una caché como Transparent CDN. Decir que para el cliente web este paso es totalmente transparente ya que en realidad él no sabe si la petición se la hace a un servidor web directamente o a una caché. Volviendo al tema, la petición es recibida por el sistema de cachés y una vez aquí la caché comprueba si el objeto que pide el cliente lo tiene o no disponible en la caché. Si lo tiene, se lo devuelve sin necesidad de pedirlo al servidor web, si no, como es el caso ilustrado, va a pedirlo al servidor web retransmitiendo exactamente la misma request que el cliente le ha mandado (paso 2).

En este momento, la request llega al servidor web, quien la procesa y le manda el contenido solicitado a la caché, junto con las cabeceras de la respuesta (paso 3).

La caché acaba de recibir el contenido procedente del servidor web y aquí ahora es donde se hace la magia del web caching, ya que inspeccionando las cabeceras de esa respuesta http, la caché se da cuenta que el servidor mediante la cabecera Cache-control le está diciendo que guarde el objeto por periodo de 2592000 segundo (30 días) de manera que todas las peticiones que lleguen a la caché solicitando ese objeto durante ese periodo de tiempo, no tendrán que pedirse al servidor web y serán servidas desde la caché. De esta manera hemos mejorado la velocidad de carga de las páginas y descargado de trabajo al servidor web.

En este punto, el sistema de cachés incorpora una serie de cabeceras como pueden ser la cabecera Age, que le dice al cliente cuanto tiempo (en segundos) lleva ese objeto guardado en la caché, TP-Cache o TP2-Cache que son dos cabeceras exclusivas de Transparent CDN que le indican al navegador si el objeto ha sido servido desde la primera caché de cachés (TP-Cache: HIT), desde la segunda (TP2-Cache: HIT) o desde ninguna (TP-Cache: MISS y TP2-Cache: MISS) y el objeto ha tenido que ser pedido al servidor web.

Por último, en el paso cuatro, la caché le envía el contenido al cliente quien lo interpreta y lo visualiza.