Práctica Nº3.-Proxy HTTP Caché. Squid
Práctica Nº3.- Proxy HTTP Caché. Squid En esta práctica configuraremos nuestro equipo GNU/Linux (Ubuntu, Debian, Raspberry, etc.) como servidor Proxy HTTP Caché. Para ello se hará uso del afamado software de servicio Proxy Squid. ¡¡Aclaración!! Se denomina Proxy a todo equipo de ofrece un servicio de intermediario entre un equipo cliente y un equipo servidor. Es decir, el cliente hace una solicitud al equipo Proxy, y este se encarga de suplantarle y hacerla llegar al servidor. Este tipo de entorno suele ser muy habitual, ya que nos permite filtrar las conexiones del cliente, forzar una autenticación, o directamente garantizar una determinada calidad de servicio (QoS). Al igual que cuando se configura dentro de una red un servidor DNS caché, con la configuración de un Proxy HTTP se pretende optimizar al máximo el ancho de banda contratado, reduciendo en lo máximo posible la salida a Internet de los equipos cuando ya no es necesario. Por ejemplo, en el caso del servidor DNS Caché, nuestro servidor almacenaba en memoria las resoluciones DNS directas o inversas (Nombre DNS FQDN con su correspondiente dirección IP) que son solicitadas por los clientes de la Intranet durante el "Time To Live" (TTL) indicado en la definición de la correspondiente zona maestra del dominio solicitado, evitando de esta forma tener que salir a Internet a buscar repetidas veces la correspondiente resolución del nombre a IP cada vez que un cliente lo requiere, cuando previamente ya ha sido solicitado, optimizando de esta manera el ancho de banda consumido. Al igual que el servidor DNS Caché, el Proxy HTTP Caché almacenará en memoria las distintas páginas Web solicitadas por los clientes, evitando de esta forma tener que salir a Internet a buscar los documentos Web en el caso de que los tenga cacheados debido a que esa solicitud fue previamente solicitada y cacheada, optimizando de esta manera igualmente el ancho de banda. Por tanto, dos ventajas nos ofrece un Proxy a la hora de configurarlo dentro de nuestra red de área local: a) Acceso a los contenidos de una manera más rápida. Contenidos que hayan sido previamente cacheados no será necesario salir de nuevo a Internet a buscarlos, entregándoselos al cliente de manera directa y rápida. b) Reducción del consumo de ancho de banda. Al evitar tener que salir a Internet, en el caso de que la información solicitada este cacheada, nos ahorramos el correspondiente consumo de ancho de banda, permitiendo que otras aplicaciones o servicios puedan hacer uso de él. ¡¡Aclaración!! Cuando decimos que squid cachea la información que solicitamos a través de Internet, nos referimos únicamente a objetos con carácter no dinámico, ya que si cacheara contenido dinámico la información recibida por el cliente sería obsoleta. Por tanto, páginas Web dinámicas escritas en PHP, PyThon, ASP, etc. no serán cacheadas por defecto por squid. Por el contrario, contenidos HTML estáticos, imágenes JPG/PNG/..., documentos en formato PDF, etc. si serán cacheados, agilizando nuestra conexión a Internet y ahorrándonos el correspondiente ancho de banda. No obstante, desde el lado del servidor, el desarrollador ha podido definir los objetos como cacheable o no, provocando que squid lo cachee o no. El desarrollador también puede definir un Time To Live (TTL) para sus objetos, que será el tiempo que permanecerán en la memoria caché de Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 85
