http 2011 1

Protocolo HTTP

Carlos E. Gómez Abril/2011

Interacción entre cliente y servidor HTTP

Carlos E. Gómez Abril/2011 BASHAM, B., SIERRA, K. y BATES, B. Head First Servlets y JSP O'Reilly. 2008.

Carlos E. Gómez Abril/2011 BASHAM, B., SIERRA, K. y BATES, B. Head First Servlets y JSP O'Reilly. 2008.

Interacción entre cliente y servidor HTTP


El código HTML es parte del mensaje de respuesta HTTP


Método GET


Método POST


•  Una página Web está es un conjunto de objetos. •  Los objetos pueden serarchivos HTML, imágenes

JPEG, applets de Java, archivos de audio, etc. •  Una página Web consiste en un archivo base

HTML el cual incluye referencias a varios objetos •  Cada objeto es alcanzable por un URL. Ejemplo:

grid.uniquindio.edu.co/proyecto437/informe.pdf

host name path name

Terminología

¨  HTTP: hypertext transfer protocol.

•  Protocolo de la capa de aplicación. •  Modelo cliente/servidor.

•  Cliente: navegador que solicita, recibe y muestra los objetos web.

•  Servidor: El servidor Web envía objetos en respuesta a las solicitudes.

•  HTTP 1.0: RFC 1945. •  HTTP 1.1: RFC 2068, 2616. Carlos E. Gómez Abril/2011

Generalidades de HTTP


•  Usa TCP. •  El cliente inicia la conexión (crea el socket) al

servidor, en el puerto 80. •  El servidor acepta la conexión TCP del cliente. •  Intercambio de mensajes de la capa de aplicación

entre el navegador (cliente HTTP) y el servidor Web (servidor HTTP).




•  La conexión TCP se cierra al terminar la comunicación.

•  El servidor no mantiene información del estado acerca de las solicitudes anteriores del cliente.


•  Dos tipos de mensajes HTTP

•  HTTP Request •  HTTP Response

Mensajes HTTP


HTTP Request Message

Ejemplo Método GET


Subiendo un formulario HTML


•  Método Post. •  Usados frecuentemente en formularios de entrada en

las páginas Web. •  Las entradas son enviadas al servidor en el entity

body.


HTTP Response Message


¨  200 OK •  Solicitud exitosa, el objeto solicitado va después en este mensaje

301 Moved Permanently •  El objeto solicitado ha sido movido, la nueva ubicación será

especificada después en este mensaje (Location:) 400 Bad Request

•  El mensaje de solicitud no fue entendido por el servidor 404 Not Found

•  El objeto solicitado no fue encontrado en este servidor 505 HTTP Version Not Supported

•  La versión del protocolo HTTP no es soportada por este servidor

Códigos de respuesta

Tipos de conexiones en HTTP

¨  No persistentes ¨  Persistentes

¤ Sin pipelining ¤ Con pipelining


Conexiones no persistentes

¨  Máximo un objeto es enviado sobre una conexión TCP.

¨  Un nuevo objeto deberá ser solicitado dentro de otra conexión TCP.

¨  HTTP/1.0 usa conexiones no persistentes.


Conexiones persistentes

Sin pipelining ¨  Múltiples objetos

pueden ser enviados sobre la misma conexión TCP.

¨  El cliente solicita un nuevo objeto después de recibir el anterior.

Con pipelining ¨  Múltiples objetos

pueden ser enviados sobre la misma conexión TCP.

¨  El cliente puede solicitar un nuevo objeto antes de recibir el objeto anterior.

¨  Es el modo por defecto usado en HTTP/1.1.


Análisis de desempeño de acuerdo al tipo de conexión

RTT ¨  Tiempo que tarda un paquete pequeño en ir del

cliente al servidor y regresar al cliente. ¨  Ejemplo:

¤ Tiempo que se demora en enviar una solicitud de conexión TCP y recibir el acuse de recibo del servidor.

RTT



Con conexiones no persistentes

¨  Se necesita un RTT para el establecimiento de la conexión entre el cliente y el servidor (para cada objeto).

¨  Existe una sobrecarga por la cantidad de conexiones TCP que deben ser establecidas.

¨  Se necesita un RTT + el tiempo de transmisión para obtener cada objeto.

RTT

RTT

RTT

RTT

Establecimiento de la conexión

Mensaje de solicitud HTTP

Mensaje de solicitud HTTP

Acuse de recibo

Acuse de recibo

Mensaje de respuesta HTTP O

bjet

o #

1 O

bjet

o #

2

Mensaje de respuesta HTTP

Establecimiento de la conexión

Tiem

po d

e tr

ansm

isió

n



Con conexiones no persistentes

¨  En total, 2 RTT por cada objeto + el tiempo de transmisión de cada objeto.

¨  Para n objetos, se necesitan 2nRTT + tiempo de transmisión de los objetos



Con conexiones persistentes ¨  El servidor deja abierta la conexión después de

enviar la respuesta. ¨  Los mensajes HTTP que se intercambien pueden ser

enviados por la misma conexión.



Con conexiones persistentes sin pipelining

¨  Los clientes envían una nueva solicitud solo cuando la respuesta a la petición anterior ha sido recibida.

¨  Se necesita un RTT para el establecimiento de la conexión + un RTT + el tiempo de transmisión para obtener cada objeto.

¨  En total, 1 RTT + 1 RTT por cada objeto + el tiempo de transmisión de cada uno.

¨  Para n objetos, se necesitan nRTT + 1 + tiempo de transmisión de los objetos



Con conexiones persistentes con pipelining

¨  Se necesita un RTT para el establecimiento de la conexión entre el cliente y el servidor, una sola vez.

¨  El cliente envía mensajes de solicitud HTTP tan pronto como encuentra objetos referenciados.

¨  Se necesita un solo RTT para todos los objetos referenciados.

¨  Es difícil establecer el tiempo pero es notoriamente inferior frente a no usar pipelining.


HTTP no guarda el estado

•  HTTP es “stateless”. •  El servidor genera una respuesta y olvida tanto la

solicitud como el cliente, es decir, no guarda ninguna información acerca de las solicitudes anteriores de los clientes.

•  Esta característica contribuyó con la escalabilidad de la Web, sin embargo se convirtió en un problema para ciertas aplicaciones.


HTTP no guarda el estado

•  Un sitio de compras necesita seguir la pista de los objetos que un usuario ha puesto en el carrito de compras virtual.

•  También podría estar interesado en saber si un cliente ha visitado el sitio antes para adecuar el contenido que será presentado.

•  Mantener el estado de la información de todos los clientes, sería inmanejable lo que afecta la escalabilidad.


Cookies

•  Las cookies son una forma de manejar la información del estado de los clientes.

•  Una cookie es una pequeña cantidad de información de estado que un servidor Web envía a un cliente Web para que la almacene y la envíe en futuras solicitudes.

•  Cuando un cliente contacta por primera vez a un servidor que tiene habilitadas las cookies, la respuesta del servidor contiene una línea de encabezado Set-Cookie, con un valor para la cookie.


Cookies

•  El valor de la cookie es una cadena arbitraria seleccionada por el servidor.

•  Los clientes no interpretan la cookie, simplemente la almacenan en el disco local.

•  En las solicitudes posteriores al mismo servidor Web, el cliente incluye la línea de encabezado Cookie con el valor respectivo.

•  Por ejemplo, un servidor puede tener un identificador por cada cliente y almacenarlo en una cookie.


Cookies

•  Entonces el identificador podría servir como llave en una base de datos en la cual se almacena información del cliente.

•  El identificador puede ser enviado como valor de la cookie.

•  De este modo, el servidor puede reconocer al cliente y presentar información de acuerdo con el usuario en particular.


Cookies

•  Un servidor podría almacenar información de cuáles páginas Web han sido visitadas por un cliente durante la sesión actual.

•  Este mecanismo fue introducido por Netscape en 1994 y posteriormente fue estandarizado y formalizado su uso en el RFC 2965.

•  Las cookies representan un simple pero poderoso mecanismo para mantener el estado de múltiples solicitudes HTTP.


Cookies

•  Las cookies también han sido usadas para hacer seguimiento al comportamiento de los usuarios afectando de alguna forma su privacidad.

•  Las cookies por sí solas no pueden actuar de forma maliciosa sobre el computador del usuario, no acceden al disco ni pueden expandir virus.

•  Las cookies pueden ser usadas para aprender acerca del comportamiento de los usuarios al navegar en la Web.


Cookies

•  Las cookies, por otra parte, son transmitidas por la red en texto claro, por lo que podrían presentar un problema de seguridad.

•  En algunos casos, los usuarios deshabilitan la recepción de cookies en el navegador, haciendo imposible a los sitios Web usa este mecanismo.

•  Este hecho debe ser considerado al momento de desarrollar los sitios Web.


Cookies


Servidor Proxy Cache

•  Es un intermediario entre los clientes y el acceso a Internet.

•  Se utiliza con el fin de mejorar la sensación del usuario acerca de la velocidad de descarga de objetos Web.

•  El navegador debe ser configurado para pasar por el servidor proxy cuando hace cada solicitud.

•  La configuración del navegador permite excepciones, para que no todas las peticiones sean enviadas al servidor proxy.


¨  El servidor proxy usualmente mantiene un caché que ayuda a reducir el tráfico hacia Internet.

¨  Cuando un navegador solicita un objeto que se encuentra en el caché, lo obtiene mucho más rápido que si lo tiene que buscar en el servidor de origen.

¨  El servidor proxy más usado en la actualidad es Squid.


¨  Usualmente el servidor proxy caché es instalado en una red corporativa como una empresa o una universidad.

¨  Los proveedores de acceso a Internet también configuran un servidor proxy para atender a los usuarios.

¨  Es posible tener un proxy transparente que no sea necesario configurar en los computadores de los usuarios. El caso más común, el del servidor proxy del proveedor de acceso a Internet.

Servidor proxy caché


Servidor proxy caché


•  Suposiciones: •  Tamaño promedio de los objetos: 1.000.000 bits. •  Cantidad promedio de solicitudes en la institución: 20/seg. •  Delay desde el router institucional a cualquier servidor origen y

regresar al enrutador: 2 seg. •  Consecuencias:

•  Utilización del la LAN: 20%. •  Utilización del enlace de acceso:100%. •  El delay total es difícil de calcular porque en el enlace de

acceso a la red institucional se presenta un cuello de botella.

Posible solución


Incrementar el ancho de banda del acceso, por ejemplo a 100 Mbps.

Posible solución


•  Consecuencias: •  Utilización de la LAN: 20%. •  Utilización del enlace: 20%. •  El delay total mejora porque ya hay posibilidad de usar

el canal de acceso a Internet, pero cada objeto se demora 2 segundos más el delay de acceso más el delay de la LAN.

•  Es una costosa actualización que no presenta una mejora significativa.

Otra posible solución


Instalar servidor proxy caché. Suponga un hit rate de 0.4.

Otra posible solución


•  Consecuencias: •  40% de las solicitudes serán satisfechas casi

inmediatamente. •  60% solicitudes serán satisfechas por los servidores de

origen. •  La utilización del enlace de acceso es reducido a un

60%, resultando delays insignificantes del orden de milisegundos.

•  Delay total promedio = Delay Internet + DelayAcceso + DelayLAN = 0.6*2 seg + 0.4*0

•  Delay total promedio ≈ 1,2 seg

Solicitudes condicionales


•  Es un mensaje que envía el servidor proxy caché al servidor de origen con el fin de validar si la copia del objeto solicitado por el cliente es una versión actualizada del objeto.

•  El servidor proxy caché especifica la fecha de almacenamiento de la copia en el mensaje HTTP request enviado al servidor de origen.



•  Utiliza la línea de encabezado If-modified-since: <date> en el mensaje HTTP request.

•  El servidor de origen solo envía el objeto en la respuesta si la copia que está almacenada en el servidor proxy caché está desactualizada.



•  El servidor de origen utiliza la línea de encabezado HTTP/1.0 304 Not Modified en el mensaje HTTP response para indicar que el objeto no será enviado porque no ha sido modificado.

•  El servidor de origen utiliza la línea de encabezado HTTP/1.0 200 OK en el mensaje HTTP response para indicar que el objeto ha cambiado y que a continuación del mensaje el objeto será enviado.

http 2011 1

Education