Universidad Tecnológica La Salle

ULSA

Tecnología de Redes Globales Práctica HTTP - NetGUI

Integrantes:

Alejandro Balmaceda Carrión.

Fausto León Amador Mairena.

e-mail: fausto1mayo@gmail.com

Balmaceda.carrion@gmail.com

Profesor:

Ing. Aldo Martínez

Introducción

Para la realización de los siguientes ejercicios es necesario descomprimir el fichero lab-HTTP.tgz en la cuenta de usuario de la siguiente forma: Desde el siguiente link puedes descargar el archivo lab-HTTP.tgz: https://dl.dropbox.com/u/48246154/lab-HTTP-v2.tgz usuario@zetaXX:~$ tar xzvf lab-HTTP.tgz Antes de arrancar NetGUI, en la ventana de terminal fija la memoria de las máquinas virtuales de NetGUI al menos a 24 MB: export NETKIT_MEMORY=24 Arranca NetGUI desde la misma ventana de terminal en que hayas ejecutado el comando anterior, y abre el escenario definido dentro del directorio lab-HTTP (en el menú Archivo-Abrir, seleccionar en la caja "Nombre de archivo" el directorio lab-HTTP).

Se cargará el escenario que se muestra en la figura 1.

1.1. Servidor HTTP Vamos a utilizar el programa apache2 como servidor de web para realizar las pruebas. Para arrancar el servidor de web utilizaremos el siguiente comando en la máquina donde queremos arrancarlo:

/etc/init.d/apache2 start Este servidor está sirviendo las páginas que se encuentran en el directorio /var/www/ de la máquina donde está arrancado. Para interrumpir el servidor de web utilizaremos el siguiente comando en la máquina donde se encuentra arrancado:

/etc/init.d/apache2 stop 1.2. Cliente HTTP Utilizaremos el programa wget como cliente HTTP para acceder a las páginas del servidor de web. Este programa no es un navegador de web, es una herramienta para descargar páginas web de un servidor, por ejemplo se utiliza para descargar un sitio web completo. Para ejecutar wget utilizaremos el siguiente comando en la máquina donde queremos arrancarlo, por ejemplo:

wget -r http://pc2.emp2.net/index.html Este comando se conectará a la máquina pc2.emp2.net y al puerto 80 y descargará la página index.html. La información descargada a través de HTTP se almacena en la máquina donde se ejecuta wget en un directorio que lleva el nombre de la máquina del servidor de web. En el ejemplo anterior, el directorio llevará el nombre pc2.emp2.net.

1.3. Tráfico HTTP en Wireshark Cuando un mensaje HTTP ocupa m_as de un segmento TCP, Wireshark muestra el siguiente mensaje por cada uno de los segmentos TCP que son parte de dicho mensaje HTTP: [TCP segment of a reassembled PDU] Cuando Wireshark interpreta que se ha recibido todo el mensaje HTTP, como resultado de haber recibido previamente un conjunto de segmentos TCP segment of a reassembled PDU, Wireshark concatena todos estos segmentos para mostrar el mensaje HTTP completo.

2. HTTP y las conexiones TCP subyacentes 2.1. HTTP con conexiones no persistentes Para ver el funcionamiento de las conexiones HTTP no persistentes vamos a descargar en pc1 una página web que se encuentra alojada en un servidor de web en pc2. Antes de realizar la transferencia, responde a las siguientes preguntas:

1. ¿Cuántas conexiones TCP crees que se establecerán para que pc1 se descargue la página index.html de pc2? ¿Por qué?

Para comprobar tus suposiciones realiza las siguientes acciones:

- Arranca el programa tcpdump, por ejemplo en la interfaz eth0 de r1, para capturar todos los paquetes relacionados con esta transferencia.

- Inicia el servidor de web en la máquina pc2 tal y como se ha explicado en la sección

anterior.

- A continuación utiliza el programa wget desde pc1 para descargarte la página index.html del servidor de web en pc2.

- Carga en Wireshark la captura que has realizado. Observarás que Wireshark interpreta algunos de los paquetes capturados como tráfico HTTP. Observando la captura de tráfico que has realizado:

Una conexión para descargarse el fichero index.html y además una conexión por cada objeto que contenga dicha página (en este caso la página contiene 2 objetos que son imágenes). Con conexiones no persistentes para cada objeto se abre una nueva conexión TCP. Suponiendo que las caches de DNS estaban vacías (no se había realizado ninguna consulta de DNS previa) se generaran los siguientes 8 mensajes: -pc1 solicita el registro A de pc2.emp2.net a dnsemp1. -dnsemp1 solicita el registro A de pc2.emp2.net a dnsroot. -dnsroot responde con el registro NS del dominio net y el registro A de dnsnet a dnsemp1. -dnsemp1 solicita el registro A de pc2.emp2.net a dnsnet. -dnsnet responde con el registro NS del dominio emp2.net y el registro A de dnsemp2 a dnsemp1. -dnsemp1 solicita el registro A de pc2.emp2.net a dnsemp2. -dnsemp2 responde con el registro A de pc2.emp2.net a dnsemp1. -dnsemp1 responde con el registro A de pc2.emp2.net a pc1.

2. Qué versión de HTTP están utilizando tanto el cliente como el servidor? El cliente wget utiliza HTTP/1.0. El servidor apache puede usar hasta HTTP/1.

3. Cuántas conexiones TCP se han establecido entre pc1 y pc2 al realizarse la descarga con wget? ¿Por qué? Se han establecido 3 conexiones: Conexión para descargar index.html Conexión para descargar foto1.jpg. Conexión para descargar foto2.jpg. Dado que se están utilizando conexiones no persistentes (wget está utilizando la versión HTTP/1.0) es necesario establecer una conexión diferente por cada objeto que se desea descargar.

4. Indica qué método se está utilizando en la petición HTTP. Método GET. 5. ¿Qué líneas de cabecera de HTTP está utilizando el cliente para sus mensajes de petición? Líneas de cabecera para la petición de index.html: User-Agent: Wget/1.9.1 Host: pc2.emp2.net Accept: */* Líneas de cabecera para las peticiones de foto1.jpg y foto2.jpg: User-Agent: Wget/1.9.1 Host: pc2.emp2.net Accept: */* Referer: http://pc2.emp2.net/index.html

6. Observa las líneas de cabecera HTTP Content-Length y Content-Type de los mensajes de respuesta que envía el servidor. ¿Son siempre las mismas? Content-Length y Content-Type indican el tamaño y el tipo de datos que viaja en el mensaje HTTP. Por tanto, no son iguales en todos los mensajes del servidor, dependerá de la respuesta que envié el servidor. En la respuesta del servidor que contiene el chero index.html: Content-Length: 120 Content-Type: text/html; charset=iso-8859-1 En la respuesta del servidor que contiene el chero foto1.jpg: Content-Length: 12211 Content-Type: image/jpeg En la respuesta del servidor que contiene el chero foto2.jpg: Content-Length: 14166

Content-Type: image/jpeg

7. Observa que el servidor de HTTP envía la cabecera Connection: close en cada respuesta para indicar que después de cada transferencia cerrará la conexión TCP, ya que está utilizando no conexiones persistentes. El servidor de HTTP envía la cabecera Connection: close en cada respuesta para indicar que está utilizando conexiones no persistentes, a pesar de que podría utilizar conexiones persistentes ya que es el comportamiento por defecto en HTTP/1.1.

2.2. HTTP con conexiones persistentes Vamos a realizar la misma transferencia que en el apartado anterior (borrando previamente los

ficheros descargados en la máquina pc1), pero configurando el cliente de HTTP para que utilice

conexiones HTTP persistentes.

HTTP 1.0 permite utilizar conexiones persistentes si el cliente incluye la línea de cabecera:

Connection: Keep-Alive

Esta cabecera no se encontraba en la especificación original de HTTP 1.0, se añadió osteriormente. Aunque el comportamiento por defecto en HTTP 1.0 sea utilizar conexiones no persistentes, si el

cliente envía esta línea de cabecera el servidor mantendrá la conexión TCP abierta para realizar

otras transferencias, usando la misma conexión.

Antes de realizar la transferencia, responde a las siguientes preguntas:

1. ¿Cuántas conexiones TCP crees que se establecerán si pc1 realiza la misma descarga que en el apartado anterior pero ahora utilizando conexiones HTTP persistentes? Para comprobar tus suposiciones realiza las siguientes acciones: -En pc1 borra los ficheros descargados en el apartado anterior para ver cómo se descargan otra vez (utiliza la orden rm -rf pc2.emp2.net desde la máquina pc1). -Para que wget utilice conexiones persistentes, edita el _chero .wgetrc (por ejemplo con mcedit) de la maquina pc1 y activa la opción http_keep_alive de la siguiente manera: http_keep_alive=on -Arranca de nuevo tcpdump para capturar todos los paquetes relacionados con la descarga que vas a realizar a continuación. -Utiliza wget para que pc1 se descargue la página index.html que tiene el servidor de web de pc2. Observando la captura de tráfico que has realizado:

R= Solo una conexión TCP para la descarga de index.html y todos los objetos que contenga.

2. ¿Cuántas conexiones TCP se han establecido entre pc1 y pc2 al realizarse la descarga con wget? ¿Por qué? Observa que la petición de HTTP se realiza usando la versi_on HTTP 1.0 con la cabecera Connection: Keep-Alive y el servidor responde utilizando la versión HTTP 1.1. Solo una conexión TCP porque se están utilizando conexiones persistentes. El cliente envía Connection: Keep-Alive para indicar al servidor que puede utilizar conexiones persistentes aunque el cliente este usando HTTP/1.0.

3. ¿Puedes apreciar si se ha ahorrado tiempo de descarga con respecto a la descarga con conexiones HTTP no persistentes? Con conexiones no persistentes el cliente realizo la descarga en 0.14 seg. Con conexiones persistentes el cliente realizo la descarga en 0.12 seg.

3. Formularios en HTTP 3.1. Envió de datos de un formulario desde el cliente al servidor En este apartado vamos a ver como se utiliza el método GET y POST para enviar datos dentro de un formulario. Para este apartado vamos a utilizar un navegador de web en modo texto, llamado lynx. Desde pc1 accederemos a un formulario en el servidor que se encuentra en pc2, rellenaremos los campos del formulario y se lo enviaremos al servidor.

3.2. Método POST -Arranca de nuevo tcpdump para capturar todos los paquetes relacionados con la descarga que vas a realizar a continuación entre pc1 y pc2. -En pc1 arranca el navegador web lynx de modo que se descargue el formulario form1.html de pc2: lynx http://pc2.emp2.net/form1.html

Rellena el campo Nombre, muévete con el tabulador hasta el campo Apellido, muévete con el tabulador hasta el campo Enviar y pulsa tecla <Enter>. Esto provocara el envió de los datos a un programa en la máquina del servidor, que tratara dichos datos y construirá una página a partir de los mismos, devolviéndosela al cliente. Para salir pulsa la letra q y después confirma que quieres salir de lynx con la letra y. Interrumpe la captura y analízala. Responde a las siguientes preguntas: 1. Busca en la captura el segmento donde el cliente le envía los datos del formulario al servidor y comprueba que se está realizando con el método POST.

El cliente envía solicita la página form1.html al servidor con el método GET. El servidor se la envía. El cliente muestra el formulario al usuario. El usuario rellena los campos Nombre y Apellidos.

Cuando el usuario pulsa Enviar los datos al servidor, el cliente construye un mensaje POST que incluye los datos que ha introducido el usuario, la primera línea de ese mensaje es: POST /cgi-bin/p.pl HTTP/1.0 2. Indica cómo se llama el programa del servidor que va a recibir esos datos.

El programa que va a recibir los datos del mensaje POST se puede saber observando la primera línea del mensaje POST. El programa se llama p.pl y se encuentra en el directorio del servidor cgi-bin . 3. Indica los valores de Content-Length y Content-Type, si aparecen en el segmento en el que el cliente envía los datos del formulario al servidor.

Si aparecen, indicando la longitud del cuerpo de datos del mensaje POST y el formato de codificación de dichos datos. Content-Length: 48 Content-Type: application/x-www-form-urlencoded 4. Indica en que parte del mensaje van los datos del formulario que el cliente le envía al servidor.

En el campo de datos del mensaje POST. nombre=minombre&apellido=miapellido1+miapellido2 5. Por qué el cliente está enviando los datos del formulario usando el método POST y no usa el GET? En el formulario que le envía el servidor al cliente (el chero form1.html ) se especifica la forma en la que se van enviar los datos al servidor cuando el usuario rellene dicho formulario. Puede verse en la siguiente línea de form1.html: <FORM action="http://pc2.emp2.net/cgi-bin/p.pl" method=POST>

3.3. Método GET -Arranca de nuevo tcpdump para capturar todos los paquetes relacionados con la descarga que vas a realizar a continuación entre pc1 y pc2. -En pc1 arranca el navegador web lynx de modo que se descargue el formulario form2.html de pc2: lynx http://pc2.emp2.net/form2.html Rellena el campo Nombre, muévete con el tabulador hasta el campo Apellido, muévete con el tabulador hasta el campo Enviar y pulsa tecla <Enter>. Esto provocara el envió de los datos a un programa en la máquina del servidor, que tratara dichos datos y construirá una página a partir de los mismos, devolviéndosela al cliente. Para salir pulsa la letra q y después confirma que quieres salir de lynx con la letra y. Interrumpe la captura y analízala. Responde a las siguientes preguntas:

1. Busca en la captura el segmento donde el cliente le envía los datos del formulario al servidor y comprueba que se está realizando con el método GET.

El cliente envía solicita la página form2.html al servidor con el método GET. El servidor se la envía. El cliente muestra el formulario al usuario. El usuario rellena los campos Nombre y Apellidos. Cuando el usuario pulsa Enviar los datos al servidor, el cliente construye un mensaje GET que incluye los datos que ha introducido el usuario, la primera línea de ese mensaje es: GET /cgi-bin/p.pl?nombre=minombre&apellido=miapellido1+miapellido2 HTTP/1.0 2. Indica cómo se llama el programa del servidor que va a recibir esos datos.

El programa que va a recibir los datos del mensaje GET se puede saber observando la primera línea del mensaje GET donde se envían los datos. El programa se llama p.pl y se encuentra en el directorio del servidor cgi-bin. 3. Indica los valores de Content-Length y Content-Type, si aparecen en el segmento en el que el cliente envía los datos del formulario al servidor.

No aparecen 4. Indica en que parte del mensaje van los datos del formulario que el cliente le envía al servidor.

En la línea inicial del mensaje GET. GET /cgi-bin/p.pl?nombre=minombre&apellido=miapellido1+miapellido2 HTTP/1.0 5. Por qué el cliente está enviando los datos del formulario usando el método GET y no usa el POST?

En el formulario que le envía el servidor al cliente (el chero form2.html) se especifica la forma en la que se van enviar los datos al servidor cuando el usuario rellene dicho formulario. Puede verse en la siguiente línea de form1.html: <FORM action="http://pc2.emp2.net/cgi-bin/p.pl" method=GET>

4. Proxy HTTP En este apartado vamos a arrancar un proxy HTTP con cache en la maquina r1 y vamos a realizar la misma descarga que en los apartados anteriores. Los clientes HTTP 1.0 no envían la cabecera Connection: Keep-Alive cuando se comunican con un proxy 1, por tanto, desde pc1 wget utilizara conexiones no persistentes para comunicarse con el proxy. Dado que la petición de HTTP llega al proxy a través de una comunicación con conexiones no persistentes, el proxy cuando se comunica con el destino utilizara conexiones no persistentes. Antes de realizar la descarga:

1. Cuantas conexiones TCP crees que se van a necesitar para realizar la descarga descrita? Para comprobar tus suposiciones realiza las siguientes acciones: -En pc1 borra los ficheros descargados en el apartado anterior para ver cómo se descargan otra vez. -Arranca todos los procesos tcpdump que consideres necesarios para capturar todo el tráfico HTTP de la descarga que vamos a realizar usando el proxy HTTP de r1. -Dado que tienes el servidor de web en pc2 arrancado del apartado anterior, no es necesario que lo reinicies. -Para arrancar el proxy HTTP en la maquina r1 vamos a utilizar de nuevo la aplicación apache2 que puede funcionar como servidor HTTP y como servidor de proxy. Los ficheros de configuración de apache2 en r1 están configurados para que funcione como proxy HTTP. Por tanto, para arrancar el proxy HTTP utiliza el mismo comando que para arrancar el servidor HTTP apache2 en r1. Se ha configurado el proxy HTTP para recibir conexiones en el puerto 8080. -Para que wget utilice el proxy HTTP configurado en r1, es necesario editar el fichero de configuración .wgetrc de pc1 para que la línea http_proxy no aparezca comentada (quita el carácter #). En esta línea se indica en que máquina y puerto se encuentra el proxy. -Desde pc1 descarga la página index.html que se encuentra en pc2. Observando la/s captura/s de tráfico que hayas realizado: Se necesitaran las siguientes conexiones: -Una conexión entre pc1 y el proxy para solicitar index.html y descargarse ese fichero. -Una conexión entre el proxy y pc2 para solicitar index.html y descargarse ese fichero. -Tantas conexiones entre pc1 y el proxy como objetos contenga el chero index.html -Tantas conexiones entre el proxy y pc2 como objetos contenga el fichero index.html En nuestro caso, 6 conexiones. 2. Escribe la orden que has utilizado en pc1 para descargar la página index.html de pc2 arrancada en pc1. La línea en pc1 es la misma que escribiríamos si no hubiera proxy: wget -r http://pc2.emp2.net/inndex.html 3. Cuantas conexiones TCP se han establecido para realizar la descarga descrita? Explícalas. -Una conexión entre pc1 y el proxy para solicitar index.html y descargarse ese fichero. -Una conexión entre el proxy y pc2 para solicitar index.html y descargarse ese fichero. -Una conexión entre pc1 y el proxy para solicitar foto1.jpg y descargarse ese fichero.

-Una conexión entre el proxy y pc2 para solicitar foto1.jpg y descargarse ese fichero. -Una conexión entre pc1 y el proxy para solicitar foto2.jpg y descargarse ese fichero. -Una conexión entre el proxy y pc2 para solicitar foto2.jpg y descargarse ese fichero. 4. Como le indica el proxy de r1 a pc2 que quiere utilizar conexiones no persistentes con HTTP 1.1? A través de la siguiente cabecera: Connection: close 4.1. Cache en el proxy Nota: Si ha pasado más de una hora desde que hiciste el apartado anterior, necesitas repetir las descargas del apartado anterior (sin volver a capturar) antes de realizar este apartado. -En pc1 borra los ficheros descargados en el apartado anterior para ver cómo se descargan otra vez. -Arranca todos los procesos tcpdump que consideres necesarios para capturar todo el tráfico HTTP de una nueva descarga entre pc1 y pc2 que vamos a realizar usando el proxy HTTP de r1. -Repite la descarga anterior, para que pc1 obtenga de nuevo la página index.html de pc2. Observando la/s captura/s de tráfico que hayas realizado: 1. Cuantas conexiones TCP se han establecido para realizar la descarga descrita? Explícalas. 3 conexiones TCP, entre pc1 y el proxy. No hay conexiones TCP entre el proxy y pc2. Una para cada uno de los ficheros: index.html, foto1.jpg, foto2.jpg. 2. Es posible observar en el tráfico que r1 va almacenando en la cache las paginas descargadas? por qué? Si, se puede observar que el proxy no vuelve a solicitar los ficheros a pc2 y sin embargo, el proxy le envía dichos ficheros a pc2. Por tanto, el proxy debe tener almacenados dichos ficheros. 4.2. Actualización de la caché en el proxy Por defecto, el proxy tiene configurado que espere un tiempo máximo de 1 da para que los documentos permanezcan en la cache del proxy sin consultar al servidor original. Si se realiza una petición de una página de la cache después de ese tiempo máximo, el proxy deberá comprobar que los documentos no han cambiado. Por este motivo, vamos a cambiar la fecha en el servidor proxy para simular el paso del tiempo. -En pc1 borra los ficheros descargados en el apartado anterior para ver cómo se descargan otra vez. Ejecuta la siguiente instrucción para ver la fecha que tiene configurada el proxy r1:

Date - Ahora vuelve a ejecutar el mismo comando cambiando la fecha, sumando dos días al día actual que tenga configurado la máquina y que nos ha devuelto date, de la siguiente forma: date MMDDHHMM dónde: _ MM: número del mes en un año [01-12] _ DD: número de día del mes [01-31] _ HH: número de hora en el día [00-23] _ MM: número de minuto en la hora [00-59] Si por ejemplo date nos ha devuelto que tiene configurado el día 28 de noviembre de 2011 y son las 12:30. Nosotros cambiaremos la fecha al día 30 de noviembre de 2011 a las 12:30 (de esta forma sabremos con seguridad que los documentos en la cache del proxy han caducado, y se consultara con el servidor final): date 11301230 -Arranca todos los procesos tcpdump que consideres necesarios para capturar todo el tráfico HTTP de una nueva descarga entre pc1 y pc2 que vamos a realizar usando el proxy HTTP de r1. -Repite la descarga anterior, para que pc1 obtenga de nuevo la página index.html de pc2. Observando la/s captura/s de tráfico que hayas realizado: 1. Cuantas conexiones TCP se han establecido para realizar la descarga descrita? Explícalas. 6 conexiones: -Una conexión entre pc1 y el proxy para solicitar index.html y descargarse ese fichero. -Una conexión entre el proxy y pc2 para comprobar si el fichero index.html ha sido modificado. Como no ha sido modificado no se lo descarga. -Una conexión entre pc1 y el proxy para solicitar foto1.jpg y descargarse ese fichero. -Una conexión entre el proxy y pc2 para comprobar si el chero foto1.jpg ha sido modificado. Como no ha sido modificado no se lo descarga. -Una conexión entre pc1 y el proxy para solicitar foto2.jpg y descargarse ese fichero. Una conexión entre el proxy y pc2 para comprobar si el chero foto2.jpg ha sido modificado. Como no ha sido modificado no se lo descarga. 2. Es posible observar en el tráfico que r1 ya tiene los documentos? Por qué? El proxy utiliza la línea de cabecera If-modified-since , esto significa que el proxy tiene ya una versión almacenada de dicho fichero y quiere comprobar si ha cambiado. Además como los ficheros no se han modificado en el servidor, pc2 no se los vuelve a enviar al proxy. Sin embargo, el proxy si se lo envía a pc1. Por tanto, el proxy debe tenerlos almacenados.

3. Que mensajes de HTTP recibe r1 desde el servidor pc2? Por qué? Mensajes de pc2 al proxy que indican que los ficheros solicitados no se han modificado. HTTP/1.1 304 Not Modified