Tipo de implementaciones
La idea de implementar un servidor de este tipo, es que las peticiones de los clientes sean recibidas por el Web Caché antes de salir a la nube. Para ello es necesario re direccionar ese tráfico saliente de los clientes hacia el servidor, y que este luego resuelva en que porcentaje las peticiones podrán ser respondidas por el mismo o si deberá buscarla información y luego enviar los resultados al cliente.
La forma más común es, configurar el navegador del cliente en su apartado proxy, con la ruta completa hacia el servidor. Este método se denomina No Transparente o Manual y se justifica
TOMO 1 – TEORÍA, ASPECTOS TÉCNICOS Y ELEMENTOS DE UN WISP
Otra forma, menos común pero más practica a los fines de grandes implementaciones, es en primera instancia centralizar el tráfico a nivel de red y no de usuario. Este tráfico centralizado, es redirigido al web proxy en una segunda instancia, y finalmente este completa el proceso. Este tipo de implementación de proxy se denomina Transparente. Es muy útil porque no
existe injerencia en el plano cliente; el usuario nunca se entera que está bajo un proxy, además de las ventajas que esto supone desde el punto de vista de la implementación.
La gran mayoría del tráfico web consultado, pertenece al protocolo HTTP. Los programas de cacheo web hacen uso de los mecanismos que este define para su cache:
Los recursos de una página web son, principalmente, los archivos HTML, JS, CSS y las imágenes. El funcionamiento de la caché web se determina por la solicitudes del navegador y la verificación de la información en el servidor Web Caché, recurriendo a la nube (Internet) en caso de que la información no esté o esté caducada. En líneas generales el funcionamiento es el siguiente:
TOMO 1 – TEORÍA, ASPECTOS TÉCNICOS Y ELEMENTOS DE UN WISP
- Una página web debe enviar una cabecera de validación denominada “Last-Modified”
o “E-Tag” , para que el servidor cache (en nuestro caso) pueda controlar la caducidad
del recurso y por tanto lo pueda cachear.
- Petición de recurso: El usuario realiza la petición, el servidor Web Caché verifica si lo
tiene almacenado
- En caso negativo, lo busca en internet, actualiza el Caché y Carga el Recurso.
- En caso positivo (en caché) es necesario saber si el recurso ha Caducado o no, a
través de una comparación de fecha. Los recursos en la caché del servidor Web Caché
disponen de una fecha de caducidad obtenida de una cabecera “Cache-Control: max-
age” o “Expires” que fueron enviadas anteriormente por el servidor web.
o Recurso no caducado: en este caso, le sirve el recurso desde la caché sin
necesidad de realizar ninguna conexión con el servidor web o internet.
o Recurso caducado: el servidor Web Caché enviará una consulta con una cabecera
“If -Modified-Since” y la fecha de última modificación “Last-Modified” que tenga
almacenada. El servidor web o internet, comprueba si el recurso ha sido modificado.
En caso negativo, el servidor web o internet, responde con un código de
estado “HTTP 304 NotModified” . El Web Caché procede a recuperar la copia
desde su caché ya que no ha sido modificada. Esto conlleva una conexión con el servidor pero sólo se reciben las cabeceras HTTP.
En caso positivo, es decir, el recurso fue modificado, el servidor web
enviará un código 200 y el contenido del nuevo recurso. El Web Caché actualizará entonces la información en la caché.
- Finalmente el recurso es entregado al usuario
Los posibles códigos de estado se identifican con números de tres cifras y se clasifican en cinco grupos:
1. Números del estilo 1XX que representan mensajes de tipo informativo.
2. Números del estilo 2XX que indican que se completó satisfactoriamente la solicitud del cliente.
3. Números del estilo 3XX que indican que la solicitud fue redirigida. 4. Números del estilo 4XX que indican un error en la solicitud del cliente. 5. Números del estilo 5XX que indican un error en el lado del servidor.
TOMO 1 – TEORÍA, ASPECTOS TÉCNICOS Y ELEMENTOS DE UN WISP
TOMO 1 – TEORÍA, ASPECTOS TÉCNICOS Y ELEMENTOS DE UN WISP
En el protocolo HTTP las URLs comienzan con "http://" y utilizan por omisión el puerto 80, las URLs de HTTPS comienzan con "https://" y utilizan el puerto 443 por omisión.
HTTP es inseguro y está sujeto a ataques que pueden permitir al atacante obtener acceso a cuentas de un sitio web e información confidencial. HTTPS está diseñado para resistir esos ataques y ser más seguro.
HTTP opera en la capa más alta del modelo OSI, la capa de aplicación; pero el protocolo de seguridad opera en una subcapa más baja, cifrando un mensaje HTTP previo a la transmisión y descifrando un mensaje una vez recibido. Estrictamente hablando, HTTPS no es un protocolo separado, pero refiere el uso del HTTP ordinario sobre una Capa de Conexión Segura cifrada Secure Sockets Layer (SSL) o una conexión con Seguridad de la Capa de Transporte (TLS). Con el advenimiento de las redes sociales, home banking, compras por internet, etc., fue necesario aplicar este cifrado al HTTP, generando una complicación extra al cacheo por sus características.
En este trabajo no abarcamos el cacheo HTTPS por las siguientes razones:
- Se requieren direccionamientos especiales del puerto 443
- Se requiere instalación de certificados del servidor cache en cada pc de usuario, lo cual
haría inviable el proyecto