dilluns, 17 de maig del 2010
PRÁCTICA 3
Las siguientes entradas están dedicadas a la realización de la tercera práctica de la asignatura para la que está dedicada este blog, "Redes de ordenadores" de ITT: sonido e imagen. En esta práctica pretendemos profundizar en la capa de transporte de la arquitectura TCP/IP. Dentro de este nivel indagaremos en el formato de las estructuras de datos, así como el direcionamiento a puertos de enlace con diferentes aplicaciones. Los ejercicios desarrollados son los siguientes:
Práctica 3: Ejercicio 1-Sobre Transmisión de datos a puertos de enlace
Para el desarrollo del primero de los ejercicios de la última práctica de la asignatura, la tercera, vamos a desarrollar las dos siguientes entradas de nuestro blog. Cada una de estas entradas estarán dedicadas a cada uno de los subapartados del ejercicio.
Práctica 3: Ejercicio 1-A
1.a.Utilizar el programa udp.exe para realizar un envío de datos al puerto 7 (eco) o al puerto 13 (hora y día) del servidor Linux1 (10.3.7.0). Para ello basta especificar la dirección IP y el puerto del servidor, colocar algún texto en la ventana y pulsar el botón "Envía UDP". Con el monitor de red, analiza la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo “hola”. Utiliza el filtro adecuado en el Monitor de Red (direcciones y protocolos).
Como podemos comprobar si mandamos al puerto 7 la frase “Hola me llamo Alejandro”, cumple su función de eco y responde con la misma frase que le ha sido enviada. Sin embargo al intentar contactar con el puerto 13 y mandarle la misma frase, o al intentar contactar con el de cualquier manera, responde con la hora. Si analizamos los puertos de los paquetes enviados poseen la misma numeración, 1663, ya que parten de la misma aplicación, sin embargo los paquetes que llegan tiene numeración distinta debido a que nacen en puertos distintos, 7 y 13.
Como podemos observar en el monitor de red aparecen dos paquetes por cada llamada que hacemos, las dos primeras corresponden a la comunicación con el puerto ‘eco’ que responde con la misma información. En cuanto a las direcciones de los mismos podemos comprobar como en el primer paquete el origen es mi máquina y el destino la 10.3.7.0 y en el segundo paquete las direcciones están a la inversa.
Si analizamos los paquetes que van al puerto 13 observamos que la información de las direcciones son las mismas, mientras que la información es distinta ya que ambos paquetes se suponen que van a contener información relativa a la fecha y hora.
Como podemos comprobar si mandamos al puerto 7 la frase “Hola me llamo Alejandro”, cumple su función de eco y responde con la misma frase que le ha sido enviada. Sin embargo al intentar contactar con el puerto 13 y mandarle la misma frase, o al intentar contactar con el de cualquier manera, responde con la hora. Si analizamos los puertos de los paquetes enviados poseen la misma numeración, 1663, ya que parten de la misma aplicación, sin embargo los paquetes que llegan tiene numeración distinta debido a que nacen en puertos distintos, 7 y 13.
Como podemos observar en el monitor de red aparecen dos paquetes por cada llamada que hacemos, las dos primeras corresponden a la comunicación con el puerto ‘eco’ que responde con la misma información. En cuanto a las direcciones de los mismos podemos comprobar como en el primer paquete el origen es mi máquina y el destino la 10.3.7.0 y en el segundo paquete las direcciones están a la inversa.
Si analizamos los paquetes que van al puerto 13 observamos que la información de las direcciones son las mismas, mientras que la información es distinta ya que ambos paquetes se suponen que van a contener información relativa a la fecha y hora.
Práctica 3: Ejercicio 1-B
1.b.Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Esto se puede hacer copiando parte de algún fichero de texto en la ventana de udp.exe. ¿Se produce fragmentación IP de los paquetes UDP? Estudia las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detalla los paquetes (fragmentados o no) que observas en el Monitor (indica el valor del identificador, flags, tamaño, etc…)
El texto seleccionado será la explicación del punto anterior duplicándolo para aumentar su tamaño
En total se han mando 2386 bytes de datos.
En el monitor de red observamos que hemos mandado dos partes, un paquete inicial que corresponde con la primera parte de la información y el segundo paquete corresponde con la segunda parte de la información, ya que la cantidad de datos era excesivamente grande y no cabía en una única trama. El primer paquete tendrá una longitud de 1514 bytes de los cuales 14 suponen la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 1472 bytes de datos, el segundo paquete tendrá una longitud de 948 bytes de los cuales 14 suponen la cabecera de Ethernet y 20 la cabecera IP, por lo tanto nos llegan 914 bytes de datos, por lo tanto con la unión de ambos paquetes tendremos el total de la información, 2386 bytes de datos.
Sin embargo en la recepción recibimos muchos más, un total de 5 paquetes. Esto es debido a que el enlace físico desde el router de salida de nuestra red y el servidor 10.3.7.0 acepta únicamente un total de 514 bytes de trama, por lo tanto los paquetes a enviar se deben ajustar a ese tamaño. De aquí deducimos que: el primer paquete posee 14 bytes de la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 472 bytes de datos, los siguientes 3 paquetes tendrán la misma estructura, tendrán una longitud de 514 bytes, de los cuales 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos. En cuanto al último paquete, como contiene menos datos que los anteriores, su tamaño será de 508, con 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos 474, por lo tanto entre todos los paquetes hemos conseguido los 2386 bytes de datos originales
En cuanto a la identificación de los paquetes, los dos primeros paquetes tendrán la misma identificación 0x4ea3, y el primer paquete tendrá el parámetro ‘flags’ activado ya que si que posee segmentación y el segundo no. En cuanto al campo ‘Header checksum’, ambos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
Por otro lado, la respuesta del servidor, también tendrán la misma identificación entre ellos, 0x0411, y los cuatro primeros tendrán el campo ‘flags’ activado, ya que todos poseen segmentación posterior excepto el último. En cuanto al campo ‘Header checksum’, todos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
El texto seleccionado será la explicación del punto anterior duplicándolo para aumentar su tamaño
En total se han mando 2386 bytes de datos.
En el monitor de red observamos que hemos mandado dos partes, un paquete inicial que corresponde con la primera parte de la información y el segundo paquete corresponde con la segunda parte de la información, ya que la cantidad de datos era excesivamente grande y no cabía en una única trama. El primer paquete tendrá una longitud de 1514 bytes de los cuales 14 suponen la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 1472 bytes de datos, el segundo paquete tendrá una longitud de 948 bytes de los cuales 14 suponen la cabecera de Ethernet y 20 la cabecera IP, por lo tanto nos llegan 914 bytes de datos, por lo tanto con la unión de ambos paquetes tendremos el total de la información, 2386 bytes de datos.
Sin embargo en la recepción recibimos muchos más, un total de 5 paquetes. Esto es debido a que el enlace físico desde el router de salida de nuestra red y el servidor 10.3.7.0 acepta únicamente un total de 514 bytes de trama, por lo tanto los paquetes a enviar se deben ajustar a ese tamaño. De aquí deducimos que: el primer paquete posee 14 bytes de la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 472 bytes de datos, los siguientes 3 paquetes tendrán la misma estructura, tendrán una longitud de 514 bytes, de los cuales 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos. En cuanto al último paquete, como contiene menos datos que los anteriores, su tamaño será de 508, con 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos 474, por lo tanto entre todos los paquetes hemos conseguido los 2386 bytes de datos originales
En cuanto a la identificación de los paquetes, los dos primeros paquetes tendrán la misma identificación 0x4ea3, y el primer paquete tendrá el parámetro ‘flags’ activado ya que si que posee segmentación y el segundo no. En cuanto al campo ‘Header checksum’, ambos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
Por otro lado, la respuesta del servidor, también tendrán la misma identificación entre ellos, 0x0411, y los cuatro primeros tendrán el campo ‘flags’ activado, ya que todos poseen segmentación posterior excepto el último. En cuanto al campo ‘Header checksum’, todos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
Práctica 3: Ejercicio 2-Establecimiento de conexión para transmitir datos
Las tres siguientes entradas de este blog están dedicadas al desarrollo del tercer ejercicio de la tercera práctica. En este ejercicio tratamos de entender el procedimiento para la conexión y posterior transmisión de datos TCP.
Práctíca 3: Ejercicio 2-A
2.a.Comprueba las secuencias de conexión-desconexión TCP. ¿Son similares a las que se detallan en la figura 6? (Puede que observes que el cliente contesta a una solicitud de SYN del servidor con un RST. Esto ocurre porque el servidor trata de autentificar al cliente, algo que no permite el PC).
Si coincide, primero establece la conexión entre ambos terminales, acto seguido pasa al traspaso de datos entre ellos y una vez que todos los datos han sido transmitido, finaliza la conexión y deja los recursos de conexión libre.
Si coincide, primero establece la conexión entre ambos terminales, acto seguido pasa al traspaso de datos entre ellos y una vez que todos los datos han sido transmitido, finaliza la conexión y deja los recursos de conexión libre.
Práctica 2: Ejercicio 2-B
2.b.Comprueba el valor de los puertos utilizados. Indica su valor.
Cuando nosotros mandamos los segmentos utilizamos el puerto de enlace ‘exec(512)’ que corresponde con el puerto asignado a la aplicación ‘Rexec’.
Cuando el servidor nos manda información utiliza el puerto de enlace ‘asdis(2192)’, que corresponde con el puerto de salida del servidor.
También encontramos dos puertos distintos en la conexión que nos servirá para realizar la identificiación. El puerto de identificación de nuestra máquina será el ‘gtrack-ne(3592)’ y del servidor del destino es el ‘ident(113)’
Cuando nosotros mandamos los segmentos utilizamos el puerto de enlace ‘exec(512)’ que corresponde con el puerto asignado a la aplicación ‘Rexec’.
Cuando el servidor nos manda información utiliza el puerto de enlace ‘asdis(2192)’, que corresponde con el puerto de salida del servidor.
También encontramos dos puertos distintos en la conexión que nos servirá para realizar la identificiación. El puerto de identificación de nuestra máquina será el ‘gtrack-ne(3592)’ y del servidor del destino es el ‘ident(113)’
Subscriure's a:
Missatges (Atom)
