SlideShare uma empresa Scribd logo
1 de 13
Baixar para ler offline
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
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

Mais conteúdo relacionado

Mais procurados (20)

Analisis de red mediante Wireshark y Tcpdump
Analisis de red mediante Wireshark y TcpdumpAnalisis de red mediante Wireshark y Tcpdump
Analisis de red mediante Wireshark y Tcpdump
 
Servicio FTP en Windows
Servicio FTP en WindowsServicio FTP en Windows
Servicio FTP en Windows
 
Servidor ftp1
Servidor ftp1Servidor ftp1
Servidor ftp1
 
Wireshark1
Wireshark1Wireshark1
Wireshark1
 
Sockets tcp
Sockets tcpSockets tcp
Sockets tcp
 
Protocolos en wireshark
Protocolos en wiresharkProtocolos en wireshark
Protocolos en wireshark
 
Http
HttpHttp
Http
 
Ltps
LtpsLtps
Ltps
 
Taller wireshark
Taller wiresharkTaller wireshark
Taller wireshark
 
Indicacion de fecha de examen
Indicacion de fecha de examenIndicacion de fecha de examen
Indicacion de fecha de examen
 
Puertos tcp mas usados
Puertos tcp mas usadosPuertos tcp mas usados
Puertos tcp mas usados
 
Dhcp+ldap+gosa
Dhcp+ldap+gosaDhcp+ldap+gosa
Dhcp+ldap+gosa
 
Protocolo TCP/IP
Protocolo TCP/IPProtocolo TCP/IP
Protocolo TCP/IP
 
Configuracion de Firewalls e Pasarelas
Configuracion de Firewalls e PasarelasConfiguracion de Firewalls e Pasarelas
Configuracion de Firewalls e Pasarelas
 
10 network applications
10 network applications10 network applications
10 network applications
 
Taller de wireshark final
Taller de wireshark finalTaller de wireshark final
Taller de wireshark final
 
Wireshark
Wireshark Wireshark
Wireshark
 
Protocologos 1
Protocologos 1Protocologos 1
Protocologos 1
 
Servidores web, dhcp, correo, dns
Servidores web, dhcp, correo, dnsServidores web, dhcp, correo, dns
Servidores web, dhcp, correo, dns
 
Protocolo tftp trabajo
Protocolo tftp trabajoProtocolo tftp trabajo
Protocolo tftp trabajo
 

Destaque

Casos de estudio y asignacion de recursos
Casos de estudio y asignacion de recursos Casos de estudio y asignacion de recursos
Casos de estudio y asignacion de recursos Fausto Amador Mairena
 
TELE TRABAJO_DERECHO INFORMATICO
TELE TRABAJO_DERECHO INFORMATICOTELE TRABAJO_DERECHO INFORMATICO
TELE TRABAJO_DERECHO INFORMATICOWolf Man
 
Presentación (vi) microboock
Presentación (vi) microboockPresentación (vi) microboock
Presentación (vi) microboockMartaDD
 
Ensayo fotografico
Ensayo fotograficoEnsayo fotografico
Ensayo fotograficodad1029
 
El origen de la tierra
El origen de la tierraEl origen de la tierra
El origen de la tierraabrucena
 
Adopción de menores por parejas del mismo sexo
Adopción de menores por parejas del mismo sexoAdopción de menores por parejas del mismo sexo
Adopción de menores por parejas del mismo sexocesargerardoespinosa
 
Mi proyecto de vida
Mi proyecto de vidaMi proyecto de vida
Mi proyecto de vidagloriamausa
 
Trabajo de comunicación científica
Trabajo de comunicación científicaTrabajo de comunicación científica
Trabajo de comunicación científicaJordy Chauca
 
Pasos para la solución de un problema por computador
Pasos para la solución de un problema por computadorPasos para la solución de un problema por computador
Pasos para la solución de un problema por computadoreduardzavala93
 
Iniciaciacion deportiva
Iniciaciacion deportivaIniciaciacion deportiva
Iniciaciacion deportivamigueuc
 
La carta de resposta
La carta de respostaLa carta de resposta
La carta de respostaPEPASC4
 
El origen de la tierra
El origen de la tierraEl origen de la tierra
El origen de la tierrajuan674
 
INFORMACIÓN, MENOS CONOCIMIENTO
INFORMACIÓN, MENOS CONOCIMIENTOINFORMACIÓN, MENOS CONOCIMIENTO
INFORMACIÓN, MENOS CONOCIMIENTOWolf Man
 

Destaque (20)

Servidor apache
Servidor apacheServidor apache
Servidor apache
 
Clase practica strips resuelto
Clase practica strips resueltoClase practica strips resuelto
Clase practica strips resuelto
 
Casos de estudio y asignacion de recursos
Casos de estudio y asignacion de recursos Casos de estudio y asignacion de recursos
Casos de estudio y asignacion de recursos
 
TELE TRABAJO_DERECHO INFORMATICO
TELE TRABAJO_DERECHO INFORMATICOTELE TRABAJO_DERECHO INFORMATICO
TELE TRABAJO_DERECHO INFORMATICO
 
Presentación (vi) microboock
Presentación (vi) microboockPresentación (vi) microboock
Presentación (vi) microboock
 
Ensayo fotografico
Ensayo fotograficoEnsayo fotografico
Ensayo fotografico
 
Trabajo anime lina
Trabajo anime linaTrabajo anime lina
Trabajo anime lina
 
El origen de la tierra
El origen de la tierraEl origen de la tierra
El origen de la tierra
 
Adopción de menores por parejas del mismo sexo
Adopción de menores por parejas del mismo sexoAdopción de menores por parejas del mismo sexo
Adopción de menores por parejas del mismo sexo
 
Italia
ItaliaItalia
Italia
 
Mi proyecto de vida
Mi proyecto de vidaMi proyecto de vida
Mi proyecto de vida
 
Practica 1
Practica 1Practica 1
Practica 1
 
Trabajo de comunicación científica
Trabajo de comunicación científicaTrabajo de comunicación científica
Trabajo de comunicación científica
 
Pasos para la solución de un problema por computador
Pasos para la solución de un problema por computadorPasos para la solución de un problema por computador
Pasos para la solución de un problema por computador
 
Iniciaciacion deportiva
Iniciaciacion deportivaIniciaciacion deportiva
Iniciaciacion deportiva
 
La carta de resposta
La carta de respostaLa carta de resposta
La carta de resposta
 
Educación..
Educación..Educación..
Educación..
 
Ricoeur, P.
Ricoeur, P. Ricoeur, P.
Ricoeur, P.
 
El origen de la tierra
El origen de la tierraEl origen de la tierra
El origen de la tierra
 
INFORMACIÓN, MENOS CONOCIMIENTO
INFORMACIÓN, MENOS CONOCIMIENTOINFORMACIÓN, MENOS CONOCIMIENTO
INFORMACIÓN, MENOS CONOCIMIENTO
 

Semelhante a Http net gui preguntas y soluciones

Semelhante a Http net gui preguntas y soluciones (20)

Curso de php
Curso de phpCurso de php
Curso de php
 
Servidor web apache
Servidor web apacheServidor web apache
Servidor web apache
 
Instalación de Tomcat 7 en Linux y Windows
Instalación de Tomcat 7 en Linux y WindowsInstalación de Tomcat 7 en Linux y Windows
Instalación de Tomcat 7 en Linux y Windows
 
Servidor HTTP Apache
Servidor HTTP ApacheServidor HTTP Apache
Servidor HTTP Apache
 
Mininet.pdf
Mininet.pdfMininet.pdf
Mininet.pdf
 
01intalacion de apache
01intalacion de apache01intalacion de apache
01intalacion de apache
 
Apps_2.3.ppt
Apps_2.3.pptApps_2.3.ppt
Apps_2.3.ppt
 
Taller Sockets TCP UDP Multicast
Taller Sockets TCP UDP MulticastTaller Sockets TCP UDP Multicast
Taller Sockets TCP UDP Multicast
 
Servidor ftp
Servidor ftpServidor ftp
Servidor ftp
 
Curso Redes Linex 2
Curso Redes Linex 2Curso Redes Linex 2
Curso Redes Linex 2
 
Curso Redes Linex 2
Curso Redes Linex 2Curso Redes Linex 2
Curso Redes Linex 2
 
2.13 ftp
2.13 ftp2.13 ftp
2.13 ftp
 
Presentación1
Presentación1Presentación1
Presentación1
 
Capa de Transporte - Redes de Computadoras
Capa de Transporte - Redes de ComputadorasCapa de Transporte - Redes de Computadoras
Capa de Transporte - Redes de Computadoras
 
Presentacion_PHP5_Avanzado.pdf
Presentacion_PHP5_Avanzado.pdfPresentacion_PHP5_Avanzado.pdf
Presentacion_PHP5_Avanzado.pdf
 
3.1. intro wirehsark
3.1. intro wirehsark3.1. intro wirehsark
3.1. intro wirehsark
 
Curso Redes Linex 5
Curso Redes Linex 5Curso Redes Linex 5
Curso Redes Linex 5
 
Curso Redes Linex 5
Curso Redes Linex 5Curso Redes Linex 5
Curso Redes Linex 5
 
File Transfer Protocol
File Transfer ProtocolFile Transfer Protocol
File Transfer Protocol
 
Mail
MailMail
Mail
 

Http net gui preguntas y soluciones

  • 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