Contents

1 ¿Qu es la Web?

• La (World Wide) Web es una aplicacin distribuida, inventada por Tim Berners-Lee [1] en el CERN a principios de los 90, que permite la transmisin de informacin bajo demanda.

Tpicamente, un servidor Web establece una comunicacin de forma simultnea con muchos clientes Web. El protocolo que define el intercambio de informacin es el HTTP (HyperText Transfer Protocol). Este se define en los RFC’s 1945 (HTTP/1.0) y 2616 (HTTP/1.1).

• La Web utiliza el TCP como protocolo de transporte [2].

2 La comunicacin Web

• En una comunicacin Web, un navegador Web (el cliente) realiza peticiones al servidor Web (a travs del puerto 80) y ste le entrega objetos Web. Ambos tipos de mensajes se realizan segn el HTTP.

  

• Entre los servidores Web ms populares se encuentran Apache y Microsoft Internet Information Server (vase la URL
  http://news.netcraft.com/archives/web_server_survey.html).

  

• Un objeto Web es cualquier cosa que puede ser referenciada por su URL (Universal Resource Locator). Ejemplos tpicos son las pginas Web (cdigo HTML¹ ), las imgenes GIF y las imgenes JPEG, aunque actualmente se utiliza el HTTP para transmitir cualquier tipo de archivo (con cualquier contenido).
• La estructura de una URL Web siempre es de la forma:

  http://host/camino_al_objeto_en_el_host

3 Las conexiones Web

• Cuando el cliente establece una conexin HTTP con un servidor Web, sta puede ser de 2 tipos: no persistente o persistente. El HTTP/1.0 utiliza slo conexiones no persistentes y el HTTP/1.1 puede utilizar adems conexiones persistentes.
• En una conexin no persistente, para cada objeto Web transferido se establece una conexin TCP independiente. En una conexin persistente, durante la misma conexin (establecida por un par cliente/servidor) se pueden transmitir muchos objetos Web, lo que generalmente ahorra recursos en el servidor (memoria y CPU) y en la red (ancho de banda).
• Ambos tipos de conexiones pueden ser adems secuenciales o paralelas (pipelining). Estas ltimas permiten ahorrar tiempo si transmitimos varios objetos Web porque el cliente puede realizar una nueva peticin antes de recibir la respuesta de una previa.

3.1 Conexiones no persistentes

RTT (Round-Trip Time) es el tiempo de ida y vuelta de un mensaje de longitud despreciable y $t_{\text{obj}}$ es el tiempo de transmisin del objeto Web. En cada conexin TCP, el tiempo de establecimiento de conexin TCP necesita un RTT (RTT${}_1$). El segundo RTT (RTT${}_2$) se emplea en solicitar el objeto.

3.2 Conexiones persistentes

El ahorro del establecimiento de una conexin TCP para cada conexin Web reduce el tiempo en el caso de las conexiones secuenciales. El tiempo de respuesta de las conexiones paralelas persistentes es el mismo que el de las conexiones no persistentes, aunque la carga para el servidor suele ser menor cuando son persistentes.

4 Los mensajes HTTP

• En una comunicacin HTTP slo existen dos tipos de mensajes, los de peticin (request) y los de respuesta (reply).

4.1 Un mensaje de peticin

En la Figura

1 puede verse un mensaje de peticin HTTP capturado usando ethereal cuando nos conectamos a www.google.es mediante mozilla. El significado de algunas de las lneas:

• Los mensajes de peticin estn codificados en ASCII, comienzan siempre por la cadena GET, la cadena POST o la cadena HEAD y acaban la mayora de las ocasiones en una lnea en blanco (retorno de carro y nueva lnea).
• El nmero de lneas es variable, pero como mnimo siempre existe la primera (lnea de peticin) donde se indica el tipo de peticin (GET), el objeto Web reclamado² y la versin del protocolo HTTP utilizado (HTTP/1.1).
• El resto de las lneas de cabecera.
  • La primera lnea, que comienza en el ejemplo por Host: especifica el host en que reside el objeto (necesario para los proxies).
  • La lnea Connection: indica el tipo de conexin (keep-alive significa conexin persistente y close conexin no persistente.
  • La lnea User-Agent: indica el navegador Web utilizado. Esto es importante para el servidor porque dependiendo del navegador se pueden enviar pginas HTML diferentes (con idntica URL).
  • La lnea Accept-Language: indica que el usuario prefiere recibir una versin en ingls del objeto.
• <Cuerpo de entidad> es un campo de los mensajes de peticin que est vaco cuando se utiliza el mtodo GET, pero que s se utiliza con el mtodo POST. Este mtodo se emplea, por ejemplo, para rellenar formularios (donde el cliente debe enviar informacin al servidor). Finalmente, el mtodo HEAD es similar al mtodo GET, pero el servidor en su respuesta no va a incluir el objeto pedido. Este mtodo es normalmente utilizado por los desarrolladores de aplicaciones.
• En la versin HTTP/1.1, adems de GET, POST y HEAD, existen otros dos mtodos: PUT que permite a un usuario cargar un objeto en el servidor Web y DELETE que permite borrarlo.

4.2 Un mensaje de respuesta

En la Figura

2 puede verse un mensaje de respuesta HTTP. El significado de algunas de las lneas:

• Los mensajes de respuesta siempre tienen 3 secciones: la lnea inicial de estados, las lneas de cabecera y el cuerpo de la entidad.
• La lnea inicial de estados tiene 3 campos: la versin del protocolo, el cdigo de estado y el estado (estas dos cosas significan lo mismo). En el ejemplo, 200 OK significa que el servidor ha encontrado el objeto y que lo ha servido (en el ejemplo no se muestra tal cual, se trata de un objeto comprimido). En la siguiente tabla se presentan algunos de los cdigos de control ms comunes:

  Cdigo	Significado
  200 OK	Peticin exitosa
  301 Moved Permanently	El objeto demandado ha sido movido
  	a la URL especificada en Location:
  304 Not Modified	El objeto no ha sido modificado
  400 Bad Request	Peticin no entendida por el servidor
  404 Not Found	Objeto no encontrado en el servidor
  505 HTTP Version Not Supported	Obvio

• Server: indica el software del servidor Web.
• Date: indica la fecha y hora en la que se cre y envi la respuesta HTTP. Este campo es importante porque ayuda a los proxies y navegadores a mantener sus cachs.
• Content-length: indica el tamao en bytes del objeto enviado.
• Content-Type: indica que el objeto enviado en el cuerpo de la entidad es texto HTML.

5 Paso de parmetros en las URL’s

• En la seccin anterior hemos visto que uno de los mtodos usados en los mensajes de peticin (POST) era utilizado para enviar datos de tipo “formulario” al servidor. Esto tambin ser puede realizar mediante GET.
• Para ello, en la URL usada se especifican dichos datos mediante la forma:

  URL?primer parmetro&segundo parmetro&$\dots$

  Por ejemplo (slo hay un parmetro):

  http://www.google.es/language_tools?hl=es

6 Identificacin de usuarios

• El HTTP no tiene estado lo que significa que un servidor no guarda informacin acerca de los datos enviados a un determinado cliente. Esto simplifica el diseo de los servidores.
• A menudo, el servidor necesita identificar a los usuarios, bien porque el acceso al servidor est restringido, o porque quisiera servir cierto contenido en funcin de la identidad del usuario.
• El HTTP proporciona dos mecanismos:
  1. La autorizacin “login/password”.
  2. Las cookies (galletas).

6.1 Autorizacin “login/password”

• El usuario se identifica mediante un nombre de usuario (login) y una palabra clave (password). Pasos:
  1. El servidor avisa al navegador que debe identificarse mediante una lnea inicial de estado

     HTTP/1.1 401 AuthorizationRequired

     en su mensaje HTTP de respuesta.

  2. El navegador solicita al usuario el login/password e incluye esta informacin en una lnea

     Authorization:

     del prximo mensaje de peticin. Dicha lnea se incluye en cualquier nueva peticin de cualquier nuevo objeto al servidor.

6.2 Cookies

• Las cookies sirven para que los navegadores identifiquen a los usuarios que anteriormente se han conectado.

  

• En la tabla de clientes existen entradas de la forma (cookie#,usuario), que son creadas la primera vez que el usuario se conecta.
• En el fichero de cookies recibidas el navegador almacena una entrada (servidor Web, cookie#) cada vez que se conecta (por primera vez) a un servidor que utiliza cookies.

7 Las cachs Web (proxies Web)

Funcionamiento

• Para minimizar los tiempos de respuesta y el trfico en la red, la Web utiliza un conjunto de servidores especiales (llamdos proxies Web³ ) que funcionan como una cach, almacenando todo lo que sirven a los clientes para su posterior reenvo.
• De esta forma, cuando un cliente (configurado para utilizar un proxy) solicita un objeto a un servidor Web, en lugar de hacerlo directamente al servidor lo realiza al proxy.
• El proxy entonces mira si posee una copia fresca del objeto y si es as, lo sirve. En caso contrario lo solicita al servidor, lo almacena y lo sirve.
• Los navegadores Web tiene su propia cach.⁴

8 Modelos de cacheo

8.1 El modelo basado en expiracin

Se basa en que cuando el servidor enva el objeto indica el instante de tiempo en que dicho objeto es enviado y cunto tiempo estar “fresco”. Ejemplo:

o el instante de tiempo en que el objeto dejar de estar “fresco”. Ejemplo:

Ntese que en el modelo basado en expiracin, el cliente no realiza ninguna peticin al servidor si el objeto est “fresco”, es decir, si el reloj del cliente todava no ha llegado a Mon 06 Oct 2008 12:43:48 GMT.

8.2 El modelo basado en validacin

En este caso, el cliente realiza un GET condicional. Su funcionamiento se basa en que todos los objetos que se envan por primera vez a un cliente tienen asociada una lnea que indica cundo fu modificado (o creado) por ltima vez el objeto. Ejemplo:

Primera peticin

Primera respuesta

Segunda peticin

Segunda respuesta

Suponiendo que el objeto est “fresco” ...

... y evidntemente, el objeto no se transmite (el cuerpo est vaco).

9 Arquitecturas Web

9.1 La configuracin ms sencilla

• En su configuracin ms simple, los clientes “atacan” directamente a/los servidores Web.

  

9.2 Sistemas proxy de 1 nivel

• El cliente solicita un objeto a su proxy local y si este no lo encuentra, lo solicita al servidor Web pertinente.

  

9.3 Sistemas proxy multinivel

• Los servidores proxy pueden configurarse para utilizar de forma recursiva otros servidores proxy de mayor ambito. A esto se le llama cach Web cooperativa.
• Los proxies de una jerarqua pueden utilizar el Internet Caching Protocol (ICP) para hablar todos con todos a la hora de localizar un objeto dentro de la jerarqua. De esta manera, si el objeto se localiza en un proxy cercano el proceso de descarga del objeto (que finalmente se realiza mediante HTTP) se acelerara.

9.4 Sistemas proxy distribuidos

• Los proxies pueden soportar cargas muy altas cuando “representan” a una gran cantidad de servidores Web.
• Cuando un proxy soporta demasiada carga se puede proceder a la distribucin del contenido de su cach sobre un conjuto de proxies.
• El contenido de cada proxy se controla mediante el Cache Array Routing Protocol (CARP) que utiliza rutado por dispersin (hashing). Esta forma de rutado consiste en usar un proxy distinto en funcin de la URL del objeto Web solicitado.
• Cuando todos los clientes utilizan la misma funcin de dispersin, un objeto slo reside en uno de los proxies (en ese nivel).

References