1. Universidad Tecnológica La Salle
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
ULSA
2. 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.
3. 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.
4. 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.
5. 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
6. 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:
7. 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.
8. 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:
9. 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:
10. 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.
11. -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:
12. 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.
13. 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