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)’
Práctica 3: Ejercicio 2-C
2.c.Analizar los valores de la ventana de receptor. ¿Cuál es más grande?
La ventana más grande corresponde con el paquete identificado como 0x5c94 y pose un tamaño de ventana de 65535
La ventana más grande corresponde con el paquete identificado como 0x5c94 y pose un tamaño de ventana de 65535
Práctica 3: Ejercicio 3-Protocolo TCP
4.Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232(Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño. ¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?
No estos paquetes no han sido fragmentados porque son del protocolo TCP. Este protocolo es un protocolo seguro y no permite fragmentación, como podemos comprobar, el bit de ‘no fragmentación de segmento’ esta activo.
El protocolo TCP tiene esta condición para que no se pueda perder información por un paquete mal recibido, no tendría mucho sentido que invirtamos tiempo de codificación y decodificación de seguridad para que luego llegasen paquetes fragmentados con posibles errores.
El tamaño del MSS de la conexión es de 1460 bytes(2014 bytes de Ethernet,menos 14 cabecera Ethernet, menos 20 bytes de cabecera de IP y 20 bytes más de cabecera de TCP).
No estos paquetes no han sido fragmentados porque son del protocolo TCP. Este protocolo es un protocolo seguro y no permite fragmentación, como podemos comprobar, el bit de ‘no fragmentación de segmento’ esta activo.
El protocolo TCP tiene esta condición para que no se pueda perder información por un paquete mal recibido, no tendría mucho sentido que invirtamos tiempo de codificación y decodificación de seguridad para que luego llegasen paquetes fragmentados con posibles errores.
El tamaño del MSS de la conexión es de 1460 bytes(2014 bytes de Ethernet,menos 14 cabecera Ethernet, menos 20 bytes de cabecera de IP y 20 bytes más de cabecera de TCP).
Práctica 3: Ejercicio 4-
4.Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 10.3.7.0. ¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?
¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?
El valor de MSS negociado entre nuestra máquina y el servidor 10.3.7.0 es de 460 bytes. Esto es debido a que el MTU de la conexión entre nuestro router de encaminamiento y el router la maquina con la que queremos contactar es 514 bytes, por lo tanto el MSS será de 460 bytes como ya hemos dicho.
El protocolo TCP usará un tamaño de segmento de 480 bytes contando la cabecera, ya que la longitud del segmento será el MSS más los 20 bytes de cabecera.
Que MTU de cada red varían y por lo tanto la negociación del MSS entre nuestra máquina y la maquina exterior debe adaptarse al caso más restrictivo de la conexión.
¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?
El valor de MSS negociado entre nuestra máquina y el servidor 10.3.7.0 es de 460 bytes. Esto es debido a que el MTU de la conexión entre nuestro router de encaminamiento y el router la maquina con la que queremos contactar es 514 bytes, por lo tanto el MSS será de 460 bytes como ya hemos dicho.
El protocolo TCP usará un tamaño de segmento de 480 bytes contando la cabecera, ya que la longitud del segmento será el MSS más los 20 bytes de cabecera.
Que MTU de cada red varían y por lo tanto la negociación del MSS entre nuestra máquina y la maquina exterior debe adaptarse al caso más restrictivo de la conexión.
Práctica 3: Ejercicio 5-Tranferencia de datos FTP
5.Realiza una conexión FTP a la máquina de un compañero de clase. ¿Qué obtienes en el Monitor de Red al intentar realizar esta conexión?
Nuestro ordenador intenta conectar 3 veces con la máquina de nuestro compañero, mi máquina es la 147.20.43.207 y la de nuestro compañero es la 172.20.43.208. Al intentar contactar con esta máquina recibimos tantos errores como intentos realizamos debido a que las máquinas de los alumnos tienen desactivada esta opción.
Nuestro ordenador intenta conectar 3 veces con la máquina de nuestro compañero, mi máquina es la 147.20.43.207 y la de nuestro compañero es la 172.20.43.208. Al intentar contactar con esta máquina recibimos tantos errores como intentos realizamos debido a que las máquinas de los alumnos tienen desactivada esta opción.
Práctica 3: Ejercicio 6-Análisis práctico del cálculo de MSS
Ejecuta el comando route delete 172.20.41.241 y a contintinuación route add 172.20.41.241 172.20.43.231.
Todo seguido activa el monitor de red y captura la secuencia de tramas mandadas al ejecutar:
C:\ftp 172.20.41.241
Usuario: alumnos
Contraseña: alumnos
Bin
Put p3.txt
quit
¿Cuál es el MSS de la red?
Inicialmente se realiza la conexión entre nuestra máquina y la máquina deseada. Negocian su MSS para la conexión, inicialmente será de 460 bytes, ya que es la más restrictiva de las dos redes. Una vez que ya se ha establecido la conexión, nuestra máquina envía dos paquetes de TCP para comenzar la información, pero al intentar pasar por el router, este da un error ya que su MTU es de 400 bytes, por lo tanto, no permite la conexión. Nuestra máquina al recibir el mensaje de error cambia su MSS a 360 bytes que será el tamaño correcto de conexión que mantendrá hasta que termine la transferencia de datos.
Todo seguido activa el monitor de red y captura la secuencia de tramas mandadas al ejecutar:
C:\ftp 172.20.41.241
Usuario: alumnos
Contraseña: alumnos
Bin
Put p3.txt
quit
¿Cuál es el MSS de la red?
Inicialmente se realiza la conexión entre nuestra máquina y la máquina deseada. Negocian su MSS para la conexión, inicialmente será de 460 bytes, ya que es la más restrictiva de las dos redes. Una vez que ya se ha establecido la conexión, nuestra máquina envía dos paquetes de TCP para comenzar la información, pero al intentar pasar por el router, este da un error ya que su MTU es de 400 bytes, por lo tanto, no permite la conexión. Nuestra máquina al recibir el mensaje de error cambia su MSS a 360 bytes que será el tamaño correcto de conexión que mantendrá hasta que termine la transferencia de datos.
Subscriure's a:
Missatges (Atom)
