1
Aplicacions i Serveis Telemàtics
Práctica 1
Protocolos de transporte en la arquitectura TCP/IP:
Transmission Control Protocol (TCP) y
User Datagram Protocol (UDP)
Anna Calveras, Jordi Casademont, Josep Paradells
1.
INTRODUCCIÓN ... 2
1.1.
PUERTOS Y SOCKETS ... 3
1.2.
ARQUITECTURA CLIENTE-‐‑SERVIDOR ... 3
2.
USER DATAGRAM PROTOCOL: UDP ... 4
3.
TRANSMISSION CONTROL PROTOCOL: TCP ... 5
3.1.
EL SEGMENTO TCP ... 5
3.2.
ESTABLECIMIENTO Y CIERRE DE UNA CONEXIÓN TCP ... 7
3.2.1.
Establecimiento de la conexión ... 7
3.2.2.
Cierre de una conexión TCP. ... 9
3.2.3.
Diagrama de transición de estados de TCP ... 9
4.
DESARROLLO DE LA PRÁCTICA ... 12
4.1.
OBJETIVOS ... 12
4.2.
ESTUDIO PREVIO ... 12
4.3.
ENTORNO DE LABORATORIO ... 13
4.4.
EJERCICIOS ... 14
4.4.1.
Ejercicio 1: Conexiones TCP y UDP ... 14
4.4.2.
Ejercicio 2: Tráfico UDP ... 17
2 1. Introducción
Dos de los protocolos de transporte estandarizados en la arquitectura TCP/IP son TCP (Transmission Control Protocol) y UDP (User Datagram Protocol). Previamente a describir TCP y UDP, veremos una clasificación de los protocolos en cuanto a cómo establecen la conexión y a su fiabilidad. Por lo que se refiere a esta práctica, solamente se hace referencia a la versión 4 del protocolo IP.
Un protocolo puede clasificarse en función de cómo realiza la conexión en:
• Orientado a conexión. En este caso, para realizar un intercambio de información entre dos entidades se pueden dis-‐‑tinguir las siguientes fases:
- Establecimiento de la conexión - Intercambio de información - Cierre de la conexión
Una de las características de un servicio orientado a conexión es que una vez establecida la conexión, los mensajes llegan al receptor en el mismo orden en que fueron enviados por el emisor.
• No orientado a conexión. En este caso, el intercambio de información no necesita de las fases de establecimiento y cierre de la conexión. El transmisor envía el mensaje sin que el receptor sepa que va a recibir ese mensaje.
Otro parámetro que se utiliza para clasificar un protocolo es la fiabilidad del protocolo en cuanto a la entrega de la información. De esta forma los podemos clasificar en:
• Protocolo fiable cuando implementa los mecanismos necesarios para que la información que transporta llegue al otro extremo libre de errores.
• Protocolo no fiable si no nos asegura la entrega de los mensajes al extremo receptor.
Como ejemplo, Internet Protocol (IP) es un protocolo no orientado a conexión y no fiable. Es no orientado a conexión porque un datagrama IP se entrega a la red sin un establecimiento previo de la conexión y es no fiable porque no asegura que el datagrama ha sido entregado al extremo receptor con éxito o si no ha podido ser entregado.
Dado que IP es un protocolo no orientado a conexión, no fiable, los protocolos que estén por encima de IP (Nivel de Transporte) se van a tener que enfrentar con las siguientes situaciones de error:
- Pérdida de una trama
- Llegada de una trama fuera de orden - Duplicación de una trama
- Modificación de los datos de la trama
TCP (Transmission Control Protocol) es un protocolo orientado a conexión y fiable. Esto nos indica que TCP va a tener que resolver las cuatro posibles situaciones de error que hemos visto para proporcionar un servicio orientado a conexión y fiable, a sus propios usuarios (por usuarios se entiende aquellos protocolos o aplicaciones que utilicen TCP como protocolo de transporte).
UDP (User Datagram Protocol) es un protocolo no orientado a conexión y no fiable. Si una aplicación desea un servicio fiable, o bien utiliza TCP; o si utiliza UDP deberá ser la aplicación misma quien implemente los mecanismos de fiabilidad.
Obsérvese que el uso de TCP o UDP dependerá de varios aspectos. Entre ellos, y además de la fiabilidad, la eficiencia. Un protocolo orientado a conexión (como TCP) utiliza un cierto tiempo en establecer y liberar la conexión. Por lo tanto su eficiencia dependerá del volumen de datos de usuario que se intercambien. A mayor
3
volumen de datos más eficiente. Por otro lado, la fiabilidad de un protocolo puede ser un factor determinante, pero no siempre. Cuando se transmite voz, es más importante que las muestras de voz estén disponibles en los instantes requeridos en el receptor, que el hecho de que haya alguna muestra errónea, perdida o duplicada. Por esta razón, la mayoría de sistemas de transmisión multimedia sobre IP utilizan el protocolo UDP.
1.1. Puertos y Sockets
Para explicar qué son los puertos y los sockets lo realizaremos a través de un ejemplo. Supongamos que tenemos en un misma máquina (Maq-‐‑A) varios procesos comunicándose simultáneamente con otros tantos procesos en diversas máquinas (Maq-‐‑B, Maq-‐‑C ...). Cada vez que un datagrama IP llega a Maq-‐‑A, el nivel IP extrae la información y la pasa al nivel de transporte (UDP ó TCP). El nivel de transporte, realizará las funciones específicas según sea UDP o TCP y posteriormente debe entregar la información al proceso al cual va dirigida. El nivel de transporte en la arquitectura TCP/IP, utiliza el concepto de puerto para demultiplexar la información recibida y entregarla a la aplicación correspondiente.
El puerto es un número de 16 bits sin signo (0-‐‑65535) que se asigna a un proceso que quiere comunicarse a través de TCP/IP y ese número de puerto va encapsulado en la cabecera de los paquetes TCP y UDP. La Figura 1 muestra un ejemplo de lo que se acaba de describir.
Figura 1. Puertos y Sockets.
Un socket identifica de forma unívoca una conexión entre dos procesos en TCP/IP. Refiriéndonos a la Figura 1, la conexión entre los procesos a y a’ está identificada por el socket (@IP1, P1, @IP2, P4), es decir, dirección IP y puerto de origen y dirección IP y puerto de destino. Obsérvese que el número de puerto es local a la máquina;
así dos procesos en máquinas diferentes pueden tener el mismo número de puerto.
La palabra socket se utiliza con acepciones diferentes según el entorno. Cuando se habla del protocolo TCP/IP, la definición es la que se ha dado. Si se está hablando del API de programación de TCP/IP su significado es diferente.
1.2. Arquitectura cliente-servidor
En la arquitectura TCP/IP las comunicaciones entre procesos siguen una arquitectura denominada cliente-‐‑
servidor. La idea es que un proceso actúa como un servidor (proporciona servicios a los clientes) y espera que algún cliente se conecte a él en demanda de un servicio. Otro proceso actúa como cliente y se conecta al servidor para obtener un servicio.
Un ejemplo del funcionamiento es la conexión desde un navegador a un servidor de WEB. El servidor de WEB debe estar “esperando” que algún navegador se conecte a él con el fin de proporcionar una página HTML. Desde el punto de vista del usuario, primero arranca el navegador, luego se realiza la conexión y
4
cuando el usuario ha terminado de navegar, cierra el navegador, mientras que el servidor de WEB continúa
“esperando” otras conexiones. La Figura 2 muestra el flujograma que describe este comportamiento.
Figura 2. Arquitectura Cliente Servidor
De esta arquitectura se deduce que un cliente debe conocer la IP y el puerto del servidor. Siguiendo con el ejemplo del navegador, si el usuario introduce la URL http://www.upc.edu, el navegador se conectará al puerto 80. Esto es debido a que hay una serie de puertos conocidos con el nombre de “well known ports” en los que se aconseja qué tipo de servicio deben proporcionar. Así el puerto 21 es para el servidor de ftp, 23 es para el servidor de telnet, el 25 para el servidor de SMTP (servicio de correo electrónico), el 80 para el servidor de http, etc. Esto no significa que todos los servidores WEB “escuchen” en el puerto 80, ya que es potestad del administrador del sistema decidir qué puerto utilizará su servidor WEB. Sin embargo, la mayoría de clientes tienen establecido un puerto por defecto para el servidor (como en el caso del navegador y el puerto 80), de forma que si se cambia el puerto de un servicio bien definido, sólo se logrará confundir al cliente (tanto el cliente software como al usuario que está utilizando ese cliente). A modo de ejemplo, si se desea utilizar un navegador para conectarnos a un puerto diferente del de defecto (por ejemplo el 8080), la forma de introducir la URL es http://nombre_servidor:8080. Si el servidor de WEB de la UPC estuviese en el puerto 8080, la URL sería http:// ://www.upc.edu:8080.
2. User Datagram Protocol: UDP
Tal como se ha comentado, UDP (User Datagram Protocol) es un protocolo no orientado a conexión y no fiable. La especificación oficial de UDP se encuentra en el RFC768. El formato y los campos de un datagrama UDP se muestran en la Figura 3.
. Figura 3. Datagrama UDP
El campo de longitud se refiere a la longitud total, en bytes, de la cabecera y los datos. La aplicación que utiliza UDP, debe controlar el tamaño del paquete UDP (la cantidad de bytes enviados en un mismo paquete UDP) si quiere evitar que el nivel IP fragmente el paquete UDP porque se ha excedido el MTU (Maximum Transmission Unit) del medio físico. Por ejemplo, si el medio físico es una Ethernet con tramas Ethernet II, el campo de datos de la trama Ethernet tiene una longitud máxima de 1500 bytes. En este caso, la longitud
5
máxima del datagrama IP encapsulado en una trama Ethernet será de 1500 bytes. Si utilizamos UDP como protocolo de transporte, la cantidad de bytes de usuario (campo data del datagrama UDP) será como máximo 1500 -‐‑ 20 -‐‑ 8 = 1472bytes (a 1500 se le resta la cabecera IP, usualmente 20 bytes, y la cabecera UDP, 8 bytes) El checksum incluye tanto la cabecera UDP como el campo de datos, (recordemos que el checksum de la cabecera de IP solo incluye la cabecera IP y no los datos del datagrama IP). En UDP el cálculo del checksum es opcional dado que recordemos que UDP ofrece un servicio no fiable. Si el emisor no realiza el cálculo del checksum, envía este campo con ceros. Si el emisor realiza el cálculo del checksum y obtiene un valor 0, envía todo unos (65535) que es equivalente en aritmética de complemento a uno. Si el emisor calcula el checksum y el receptor detecta un checksum erróneo, el datagrama UDP se descarta silenciosamente, es decir, esta condición de error no se indica ni al emisor ni a los protocolos de nivel superior del receptor.
3. Transmission Control Protocol: TCP
TCP es un protocolo orientado a conexión y fiable. Específicamente, se dice que TCP proporciona un servicio de transporte de un flujo de bytes, orientado a conexión, fiable.
El concepto de transporte de un flujo de bytes, indica que la aplicación entrega a TCP los bytes que desea transmitir y que TCP no interpretará esos bytes, únicamente los hará llegar a la aplicación receptora en el orden en que se los entregaron. En otras palabras, si una aplicación entrega 20 bytes a TCP, seguido de una entrega de 30 bytes, seguido de una entrega de 60 bytes, la aplicación receptora no sabe cuántas entregas se hicieron al TCP, sino que puede ocurrir que al leer los bytes recibidos, lo haga en cinco lecturas de 22 bytes.
3.1. El segmento TCP
La Figura 4 muestra cómo es el segmento TCP. Destacar que en un único formato de segmento, dependiendo de unos campos, podemos representar cualquier tipo de segmento TCP.
Figura 4. Segmento TCP
Los campos del segmento:
• Puertos origen y destino (32 bits): Los primeros 16 bits indican el puerto origen y los 16 siguientes el puerto destino.
• Número de Secuencia (32 bits): El número de secuencia identifica el primer byte del flujo de datos que está siendo enviado (que ocupa la primera posición en el campo de datos del segmento). El primer byte de un flujo en un segmento TCP no lleva el número 1 como número de secuencia, sino que se elige un número aleatorio (Inital Sequence Number) en cada conexión realizada y este número representa el número de secuencia del primer byte a transmitir durante esa conexión. Si el
6
ISN de una conexión es el 1415531521, el primer byte estaría identificado por este mismo número y el segundo sería 1415531521+ 1, y así sucesivamente. De esta forma si un segmento TCP llega a una conexión equivocada los números de secuencia de ambas conexiones no podrían a llegar a confundirse nunca, ya que ambas conexiones utilizaron un ISN muy diferente y los datos que llegaron a la conexión equivocada nunca serán pasados a la aplicación equivocada (TCP generaría un error al recibir un número de secuencia no esperado).
• Número de Reconocimiento (32 bits): El campo del número de reconocimiento (acknowledge number) se utiliza para almacenar el número del siguiente byte que se espera recibir. Este campo sólo se decodifica si el flag ACK está activado. Si se recibió un paquete de datos con el número de secuencia 1415531521 y con 100 bytes de datos (desde el 1415531521 hasta el 1415531620), el segmento TCP de respuesta llevaría activado el flag ACK y el número de reconocimiento sería el 1415531621, puesto que espera recibir el siguiente al 1415531620. Con este mecanismo se consigue que los reconocimientos sean acumulativos, con lo que la pérdida de un ACK no implica necesariamente la retransmisión del segmento en cuestión, dado que antes de que expire el temporizador de retransmisión puede llegar el ACK del siguiente segmento, con lo que el anterior y todos los anteriores serán reconocidos.
• Longitud de la cabecera (4 bits): El campo hdr len (Header Length) indica la longitud de la cabecera.
Este campo es necesario dado que la cabecera de TCP puede llevar opciones haciendo que la longitud de la cabecera varíe. Su valor se expresa en múltiplos de 32 bits (4 bytes). El valor mínimo de este campo es 5, que corresponde a un segmento sin opciones (20 bytes). Su valor máximo viene determinado por los 4 bits de este campo (2^4=16, por tanto 64 bytes).
• Reservados (6 bits): Bits reservados para uso futuro.
• Bits de código (6 bits): Los bits de código determinan el propósito y contenido del segmento. A continuación se explica el significado de cada uno de estos bits (mostrados de izquierda a derecha) si está a 1. Un mismo segmento puede tener varios activos simultáneamente. También se conocen como flags:
- urg: Indica que el campo de Puntero Urgente de la cabecera contiene información válida.
- ack: Indica que el campo Número de reconocimiento contiene información válida, es decir, que el segmento lleva un ACK. Observemos que un mismo segmento puede transportar los datos de un sentido y las confirmaciones del otro sentido de la comunicación.
- psh: Segmento con datos de usuario. Pasarlos a la aplicación tan pronto como sea posible.
- rst: Reinicio de la conexión. Por ejemplo un servidor que no acepta una conexión, mandará un segmento de reset.
- syn: Inicio de conexión. Los segmentos de sincronismo se intercambian en el establecimiento de la conexión TCP. En estos segmentos es en los que sincronizan los números de secuencia y se negocian los parámetros de la conexión TCP.
- fin: Final de conexión. Se indica al otro extremo que la aplicación quiere el cierre de la conexión. Se utiliza para solicitar el cierre de la conexión actual.
• Tamaño de ventana (16 bits): El campo window size indica el tamaño de ventana en bytes.
Representa el número de bytes que el emisor del segmento que contiene este valor está dispuesto a aceptar por parte del otro extremo en el momento actual. Esta ventana se conoce como ventana de transmisión. En el inicio de la conexión se negocia su valor máximo. El valor que se intercambia a lo largo de la transferencia de datos está relacionado con el mecanismo de ventana deslizante de TCP.
7
El valor máximo es de 2^16=65535 bytes, aunque en TCP se define una extensión (window scaling) que permite ampliar este valor. Su uso está recomendado en redes con un producto ancho de banda elevado, para permitir así que el mecanismo de ventana deslizante sea eficiente.
• Suma de verificación (16 bits): Estos bits se utilizan para el checksum. Para su cálculo se utiliza una pseudocabecera que incluye también las direcciones IP origen y destino.
• Puntero Urgente (16 bits): El campo urgent pointer se utiliza cuando se están enviando datos urgentes que deben tener preferencia sobre los demás. Este campo indica el siguiente bytes del campo de datos que sigue a los datos urgentes.
• Opciones (variable): Existen varias opciones en TCP, y la más utilizada es el MSS (Maximum Segment Size). Cada extremo de una conexión indica al otro cuál es el tamaño máximo de segmento que desea recibir. Este valor se especifica dentro del campo de opciones al inicio de la conexión. En caso de que las opciones no sean múltiplos de 32 bits, la cabecera se rellena (padding).
• Datos (variable): Información que envía la aplicación. Su longitud dependerá de la MMS determinada que normalmente se adecua a la MTU del interfaz de red.
3.2. Establecimiento y cierre de una conexión TCP
3.2.1. Establecimiento de la conexión
El proceso que abre una conexión, lo hace enviando un segmento TCP con el flag SYN activado y un número de secuencia (ISN) que identificará los bytes transmitidos. No se transmiten datos de usuario. El flag ACK no está activado porque todavía no hay bytes que reconocer.
El proceso que recibe este segmento, contesta con un segmento TCP con el flag SYN activado, un número de secuencia aleatorio, el flag ACK activado y el número de reconocimiento igual al ISN recibido más uno (se supone que un segmento SYN consume un byte).
El proceso que inició la conexión responde al segmento recibido con un segmento con el flag ACK activado y el número de secuencia de reconocimiento igual al número de secuencia recibido más uno.
En este momento ya está establecida la conexión. Esta apertura de conexión se conoce con el nombre de
“establecimiento de conexión a tres bandas”, porque se utilizan tres segmentos. La Figura 5 muestra el establecimiento de una conexión TCP.
Figura 5. Establecimiento de una conexión TCP. Tree way handshake.
Temporizador en el establecimiento de la conexión:
Puede ocurrir que el extremo remoto no responda al segmento SYN de apertura de conexión. En ese caso se reintenta la apertura de la conexión varias veces. En el ejemplo de la Figura 6 hemos intentado establecer una conexión ftp con un servidor remoto (74.125.230.180). Este servidor no ha respondido ni al primero, ni al
8
segundo ni al tercer intento. En este ejemplo la configuración de TCP permite realizar tres reintentos. Puede observarse que el tiempo entre reintentos es de aproximadamente 3 segundos 8parámetro también de TCP).
El tiempo de espera entre intentos de conexión está determinado por la variable /proc/sys/net/ipv4/tcp_retries1, aplicando el valor tcp_retries1 ·∙ 2n , n = 0,... , 4, donde n es el número de reintentos. El número de reintentos antes de decidir que la conexión no se puede realizar se controla a través de la variable /proc/sys/net/ipv4/tcp_syn_retries cuyo valor durante la prueba realizada era de 3.
Figura 6. Temporizador en el establecimiento de la conexión.
Maximum Segment Size (MSS):
Una de las opciones que se incluyen en los segmentos SYN es el Maximum Segment Size (MSS). Cada uno de los extremos informa al otro del tamaño máximo de segmento que desea recibir. Como regla general, cuanto mayor sea el MSS, sin que se produzca fragmentación a nivel IP, mayor será la eficiencia ya que se amortiza las cabeceras de IP y TCP. Si el nivel físico es Ethernet con tramas Ethernet II, el mayor datagrama IP será de 1500 bytes. Si restamos la longitud mínima de las cabeceras de IP y TCP tendremos el MSS: 1500 -‐‑ 20 -‐‑ 20 = 1460 bytes. En la Figura 7 puede verse como se intenta negociar una MSS de 1460 bytes.
Figura 7. Detalle del primer segmento en el establecimiento de la conexión.
9 3.2.2. Cierre de una conexión TCP.
El cierre de una conexión se realiza mediante segmentos TCP con el flag FIN activado. El cierre de una conexión TCP utiliza 4 segmentos. Esto es debido a que una conexión TCP es full-‐‑dúplex, y cada una de las direcciones debe ser cerrada independientemente de la otra. La Figura 8 muestra el cierre de una conexión TCP.
La idea en un cierre de conexión TCP es que cualquiera de los extremos que haya enviado todos los datos puede realizar un cierre de su conexión (half-‐‑close), mientras que puede seguir recibiendo datos del extremo remoto.
Figura 8. Cierre de una conexión TCP.
3.2.3. Diagrama de transición de estados de TCP
La Figura 9 muestra el diagrama de transición de estados de TCP. Algunos estados son específicos del servidor mientras que otros lo son del cliente. Por ejemplo, como se ha comentado anteriormente, un servidor puede estar “esperando” que los clientes se conecten a él. La espera corresponde a un estado de “LISTEN”.
En realidad se dice que el servidor está “escuchando”, en un puerto, nuevas conexiones. Cuando se ejecuta un servidor pasa de estado “CLOSED” a estado “LISTEN” esperando que le lleguen segmentos TCP con el flag SYN activado (establecimiento de conexión). Sin embargo, cuando se ejecuta un cliente, éste iniciará directamente la conexión con el servidor enviándole un segmento SYN.
10
Figura 9. Diagrama de transición de estados de TCP.
La Figura 10 es un ejemplo de los estados y los segmentos del cliente y servidor en la fase de establecimiento y cierre de la conexión para un modo de operación normal.
Figura 10. Estados de TCP correspondientes a un establecimiento y cierre de conexión.
11
La Figura 11 es un ejemplo de los estados en los que se encuentran las conexiones TCP de una máquina en un momento dado obtenidas mediante el comando netstat. Pueden verse varias conexiones TCP en diferentes estados.
Figura 11. Estado de las conexiones TCP de una máquina obtenidas mediante el comando netstat.
Estado TIME WAIT:
En la Figura 9 , debajo del estado TIME_WAIT, puede leerse “2MSL timeout”. Esto quiere decir que cuando el extremo TCP que realiza un cierre activo (active close) llega al estado TIME_WAIT debe esperar un cierto tiempo antes de dar por finalizada la conexión. Ese tiempo es 2*MSL donde MSL (Maximum Segment Lifetime) es el tiempo máximo de vida de un segmento. Dado que un segmento TCP viaja encapsulado en un datagrama IP, y éste tiene un campo TTL (time-‐‑to-‐‑live), un segmento TCP también tendrá un tiempo de vida en la red. El RFC 793 especifica el MSL con una duración de 2 minutos. El valor de MSL en diferentes implementaciones es de 30 segundos, 1 minuto o 2 minutos.
¿Por qué el extremo TCP que realiza un cierre activo debe esperar un cierto tiempo?. El cierre de una conexión nunca es una cosa sencilla, ya que los paquetes de cierre pueden perderse y los extremos TCP pueden quedarse en un estado incorrecto. Refiriéndonos a la Figura 15, una vez que el cliente ha recibido el segmento FIN, ha pasado al estado TIME_WAIT y envía un segmento de reconocimiento. Puede suceder que ese segmento de reconocimiento se “pierda” y no llegue nunca a su destino. Si así fuera el caso, el servidor volvería a retransmitir el segmento FIN. Por tanto, el cliente espera un tiempo prudencial (2 ·∙ MSL) de manera que pueda recibir esa retransmisión del segmento FIN si el reconocimiento se ha perdido.
Un efecto colateral de este estado de espera, es que durante ese tiempo el socket formado por la dirección IP del cliente, puerto del cliente, dirección IP del servidor, puerto del servidor, no puede ser usado para otra conexión. En realidad, la propia implementación de TCP implica que un puerto local que esté en un socket en estado TIME_WAIT no puede ser usado de nuevo hasta que expire ese estado.
12 4. Desarrollo de la práctica
4.1. Objetivos
Los objetivos de esta práctica son el profundizar en los protocolos de transporte de la arquitectura TCP/IP, concretamente el transporte fiable TCP y el no fiable UDP. Para ello, el alumno deberá tener un conocimiento teórico de base de los protocolos para poder adquirir los conocimientos prácticos en el desarrollo de este laboratorio.
Es necesario trabajar esta cuaderno de prácticas antes del acceso al laboratorio, con la lectura y asimilación de esta memoria, así y como la preparación del estudio previo y los diferentes ejercicios propuestos.
Durante la realización del laboratorio, el alumno debe realizar una memoria del trabajo realizado respondiendo a las preguntas propuestas y discutiendo todos aquellos aspectos que considere relevantes.
4.2. Estudio Previo
1. Busque puertos bien conocidos de TCP y UDP. Anote los 5 que encuentre más relevantes.
2. Busque aplicaciones y servicios en Internet que funcionan sobre UDP y otras sobre TCP. Ponga algunos ejemplos y justifique por qué se usa un protocolo de transporte u otro.
3. Busque información de los comandos Linux:
• sudo
• sock
• tc
• netstat
• grep
• fgrep
4. ¿Por qué le puede resultar interesante conocer las conexiones que su ordenador tiene abiertas?
13 4.3. Entorno de laboratorio
Para la realización de esta práctica va a usarse un entorno virtual como el mostrado en la Figura 12.
Figura 12. Entorno virtual del laboratorio.
Una máquina virtual (VM) es un entorno, por lo general un programa o sistema operativo, que no existe físicamente, pero se crea dentro de otro entorno. En este contexto, una VM se llama un "ʺguest"ʺ, mientras que el entorno en el que se ejecuta se llama un "ʺhost"ʺ. Un “host” puede ejecutar varias VM a la vez. Debido a que las VM están separadas de los recursos materiales que utilizan, el “host” a menudo es capaz de asignar dinámicamente los recursos entre ellos.
En este ejercicio práctico usaremos el entorno VirtualBox (http://www.virtualbox.org/) que emulará la red de la Figura 12. Por lo tanto, vamos a configurar en su conjunto una red de ordenadores, pero utilizando un solo equipo, y vamos a ser capaces de configurar todos los parámetros y ejecutar cualquier comando en cualquiera de estos equipos desde un solo teclado.
Para lanzar el entorno virtual siga las indicaciones del profesor que seguramente son los siguientes si no ha cambiado alguna configuración del laboratorio:
• Entre en la máquina softX con usuario y password master1.
• Inicie el Vbox. Para ello ir al menú Aplicacions>Eines de sistema>Oracle VirtualBox
• Ahora ya puede iniciar los nodos necesarios, que en esta práctica son únicamente client1 y serv3. La máquina servidora no tiene entorno gráfico a diferencia del cliente que sí lo tiene. En la máquina serv3 si queremos tener más de un terminal abierto podemos conmutar de uno a otro con la teclas Alt F1 , Alt F2 y así sucesivamente.
En el caso de que el VirtualBox no pueda ejecutar alguna máquina virtual deberá copiar el contenido del PenDrive subministrado por el profesor excepto el fichero VirtualBox.xml en el directorio /var/tmp/.
14
Seguidamente copiar el fichero VirtualBox.xml en ~/.VirtualBox/. Si el directorio no existe créelo.
Finalmente cambie los permisos de los ficheros que ha copiado:
chmod -R 777 directorio
chmod 666 fichero
4.4. Ejercicios
A no ser que se especifique lo contrario, los ejercicios propuestos se realizarán en el entorno virtual, concretamente en los ordenadores client1 y serv3 de la red vboxnet0.
Todas las capturas de tráfico se realizarán en la máquina real softX con el analizador de protocolos Wireshark (http://www.wireshark.org/). Para ello lance el analizador de protocolos y capturare el tráfico intercambiado en el interfaz vboxnet0. Podemos lanzar el analizador desde un terminal o desde el menú correspondiente:
gksudo /usr/bin/wireshark &
o
Aplicacions>Internet>Wireshark
Una vez en marcha seleccionar el menú Capture>Options y seleccione el interfaz vboxnet0.
Realice un ping de una máquina a otra y compruebe el correcto funcionamiento del sistema.
4.4.1. Ejercicio 1: Conexiones TCP y UDP
En este ejercicio se pretende visualizar los diferentes estados del cliente TCP a lo largo de una conexión. Para ello se va a utilizar el programa sock de R. STEVENS en modo cliente, para generar tráfico. El programa sock permite generar tráfico TCP y UDP actuando como cliente. Actuando como servidor, sock se convierte en un sumidero del tráfico generado por el cliente. sock tiene varias opciones para configurar el funcionamiento, los tamaños de los buffers, el número de buffers a transmitir, etc.
1. Vea todas las opciones de sock. Para ello ejecute sock en la máquina serv3 sin parámetros:
sock
Con ello observamos:
usage: sock [ options ] <host> <port> (for client; default) sock [ options ] -s [ <IPaddr> ] <port> (for server)
sock [ options ] -i <host> <port> (for "source" client) sock [ options ] -i -s [ <IPaddr> ] <port> (for "sink" server) options: -b n bind n as client's local port number
-c convert newline to CR/LF & vice versa
-f a.b.c.d.p foreign IP address = a.b.c.d, foreign port# = p -g a.b.c.d loose source route
-h issue TCP half close on standard input EOF
-i "source" data to socket, "sink" data from socket (w/-s) -j a.b.c.d join multicast group
-k write or writev in chunks
-l a.b.c.d.p client's local IP address = a.b.c.d, local port# = p -n n #buffers to write for "source" client (default 1024)
-o do NOT connect UDP client
-p n #ms to pause before each read or write (source/sink) -q n size of listen queue for TCP server (default 5) -r n #bytes per read() for "sink" server (default 1024) -s operate as server instead of client
-t n set multicast ttl -u use UDP instead of TCP -v verbose
-w n #bytes per write() for "source" client (default 1024) -x n #ms for SO_RCVTIMEO (receive timeout)
-y n #ms for SO_SNDTIMEO (send timeout)
15
-A SO_REUSEADDR option -B SO_BROADCAST option
-C set terminal to cbreak mode -D SO_DEBUG option
-E IP_RECVDSTADDR option
-F fork after connection accepted (TCP concurrent server) -G a.b.c.d strict source route
-H n IP_TOS option (16=min del, 8=max thru, 4=max rel, 2=min$) -I SIGIO signal
-J n IP_TTL option -K SO_KEEPALIVE option
-L n SO_LINGER option, n = linger time -N TCP_NODELAY option
-O n #ms to pause after listen, but before first accept -P n #ms to pause before first read or write (source/sink) -Q n #ms to pause after receiving FIN, but before close -R n SO_RCVBUF option
-S n SO_SNDBUF option -T SO_REUSEPORT option
-U n enter urgent mode before write number n (source only) -V use writev() instead of write(); enables -k too -W ignore write errors for sink client
-X n TCP_MAXSEG option (set MSS) -Y SO_DONTROUTE option
-Z MSG_PEEK
2. Ejecute el servidor sock en el serv3 en modo background:
sock -i -F -Q 5 -s 7777 &
Compruebe que el puerto se encuentra abierto.
3. Entre el ordenador client1 y el puerto 7777 del ordenador serv3 añadimos un retardo de 1.2 segundos. Ejecute en la máquina serv3:
sudo tc qdisc add dev eth0 root netem delay 1200ms
4. Empiece a capturar el tráfico del interfaz vboxnet0.
5. Abra dos consolas en la máquina client1. Desde una de ellas visualizaremos el estado de la conexión TCP de forma continua mediante el comando netstat con la opción -‐‑c para que se ejecute forma iterativa cada segundo.
netstat -anc | grep 7777
6. En la otra ejecutaremos el programa sock para que envíe 100 mensajes de longitud 1024 bytes (longitud por defecto), al servidor (@IP serv3), puerto 7777:
sock -n100 -i @IP_serv3 7777
7. A medida que se establezca la conexión, se transmitan los mensajes y se cierre la conexión, en la consola del netstat veremos los diferentes estados del TCP cliente. Guarde los datos obtenidos en un fichero para su posterior análisis (estados-‐‑tcp.txt) y guarde las trazas capturadas con el analizador en un fichero denominado trazas-‐‑1.cap, para su posterior análisis.
Responda a las siguientes preguntas:
8. Ayudándose de la Figura 12, interprete cada uno de los estados que ha visualizado, indicando, además, cómo se ha llegado a cada uno de esos estados.
16
9. El servidor sock se ha ejecutado con las opciones: sock -‐‑i -‐‑F -‐‑Q 5 -‐‑s 7777. ¿Qué ocurriría si la opción -‐‑Q 5 no se hubiese utilizado? ¿Para qué se ha utilizado un retardo tan elevado?
10. A partir de la información obtenida con netstat (recordar que se refresca la información cada segundo), estime la duración del estado TIME_WAIT.
11. Compruebe el valor obtenido con el configurado. Para ello tenga en cuenta que para ver las diferentes opciones y parámetros de TCP que se definen en Linux, podemos consultar los ficheros en el directorio /proc o utilizar el comando sysctl.
Por ejemplo, para obtener la información de todos los parámetros de TCP utilizamos:
sysctl -a | fgrep tcp También, desde dentro del directorio
cd /proc/sys/net/ipv4
podemos ver los parámetros de tcp y de ip respectivamente si ejecutamos:
more tcp*
more ip*
Para modificar un valor es suficiente con ejecutar:
sudo echo nuevo_valor > /proc/sys/net/ipv4/variable_o_parámetro
Este procedimiento deberá usarse en otros ejercicios. Si lo prefiere guarde los parámetros de TCP en un fichero para su posterior consulta:
more /proc/sys/net/ipv4/tcp* > parametros-tcp.txt
12. Concretamente consulte el valor y el significado de la variable tcp_fin_timeout.
13. Compruebe que en estado TIME_WAIT, no es posible utilizar el mismo puerto para volvernos a conectar al servidor. Para ello ejecute:
sock -n8 -i -v @IP_serv3 7777
Con la opción -v (verbose), se obtendrá por pantalla el puerto que está utilizando el cliente para conectarse al servidor.
Una vez acabada la conexión pero todavía en estado TIME_WAIT, volvemos a ejecutar el cliente utilizando como puerto de salida el valor de puerto obtenido en la conexión anterior:
sock -n8 -i -b port @IP_serv3 7777
La opción -b port obliga al cliente a utilizar el puerto port para la conexión. ¿Qué ocurre? ¿por qué?.
17 4.4.2. Ejercicio 2: Tráfico UDP
El objetivo de este ejercicio es la captura y análisis de tráfico UDP, con objeto de comparar este estudio con la captura y análisis de tráfico TCP que se realizará en ejercicios posteriores. El servidor que se utilizará para conectarnos y enviar tráfico UDP está en el puerto 7778 del ordenador serv3. Como en los ejercicios anteriores, se utilizará el programa sock incluyendo la opción -u para indicar que deseamos tráfico UDP.
14. Empiece a capturar el tráfico del interfaz vboxnet0.
15. En la máquina serv3 ejecute un servidor de UDP en background en el puerto 7778.
sock -i –s -u 7778 &
Compruebe que el puerto se encuentra abierto.
16. En una consola del cliente ejecute netstat -anc | grep 7778
i en la otra el programa sock para que envíe 8 mensajes de longitud 1024 bytes (longitud por defecto), al servidor (@IP serv3), puerto 7778:
sock –n 8 –v -i –u @IP_serv3 7778
17. Una vez terminada la transferencia guarde las trazas capturadas con el analizador en un fichero denominado trazas-‐‑2.cap para su posterior análisis.
Responda a las siguientes preguntas:
18. ¿Cuántos segmentos se utilizan para la apertura de la conexión?
19. ¿Cuál es el puerto que ha utilizado el cliente?
20. ¿Pueden coexistir simultáneamente dos clientes UDP con el mismo puerto de salida? Compruébelo utilizando la opción –b para forzar el mismo puerto. Mande 100.000 mensajes para poder ver el efecto.
21. ¿Pueden coexistir simultáneamente un cliente UDP y otro TCP con el mismo puerto de salida?
Compruébelo.
22. Comente los paquetes capturados con el analizador en el fichero trazas-‐‑2.cap. Explique cada uno de los campos del paquete UDP.
23. ¿Se utiliza el campo de ckecksum para la detección de errores en UDP? ¿Es obligatorio usarlo? ¿Por qué?
