Instructivo

Transcripción

Instructivo

Redes de Datos – Laboratorio – Instructivo
Laboratorio 3:
Capa de Transporte (TCP)
Instrucciones generales
Para poder realizar exitosamente la práctica, deberá cumplir las siguientes etapas:
Previo al laboratorio
Estudiar la información contenida en este instructivo.
Se recomienda consultar las referencias sugeridas u otras de su preferencia.
Al comienzo del laboratorio se realizará un cuestionario sobre los temas tratados en este
instructivo. Se recomienda realizar los ejercicios sugeridos al final del instructivo.
Imprimir y leer el procedimiento de la práctica incluido en el Informe.
Se recomienda imprimir una página por faz.
Traer el instructivo del Wireshark utilizado en las prácticas anteriores para facilitar el uso del mismo
Traer un disquete/memoria USB para poder guardar resultados.
Durante el laboratorio
Seguir el procedimiento indicado en el Informe y completarlo en forma grupal. El Informe deberá
ser entregado al finalizar la práctica. NO SE ACEPTA ENTREGA DE INFORMES EN OTRO
MOMENTO.
Después del laboratorio
Agradecemos que nos envíe sus aportes al foro específico creado en la página web del curso.
Objetivo:
Examinar e interpretar los detalles del protocolo TCP:
1.
2.
3.
4.
Establecimiento de conexión en TCP.
Fin de conexión en TCP.
Mecanismo control de flujo de TCP.
Políticas de transmisión de TCP (Algoritmo de Nagle y algoritmo de Clark).
Con el uso del analizador de protocolos Wireshark se examinarán los paquetes intercambiados entre
dos máquinas al establecer y liberar una conexión, se examinará la variación de la ventana de
recepción como acción del control de flujo y se verificará la política de transmisión de datos aislados
(Algoritmo de Nagle y de Clark).
Al final de la práctica el estudiante será capaz de:


Identificar e interpretar los segmentos del establecimiento de conexión de tres vías
("three-way handshake") empleado en TCP.
Identificar e interpretar los segmentos del fin de conexión empleados en TCP.
Redes de Datos 2016 – Instructivo Laboratorio 3
Página 1 de 7


Verificar y comprender la técnica empleada en TCP para el manejo de ventanas.
Verificar y comprender la política empleada en TCP para la transmisión de datos
aislados.
Preparación.
1. Establecimiento de conexión en TCP.
En TCP se utiliza un establecimiento de conexión de tres vías (Fig. 1):
1. La aplicación de la máquina 1 inicia el establecimiento de conexión ejecutando una primitiva
CONNECT donde especifica la dirección IP y el puerto al que desea conectarse en la
Máquina 2. La capa de transporte envía un segmento TCP con el bit SYN=1 y el bit ACK=0.
Elige un Número de Secuencia x generado a partir de su reloj y fija algunos parámetros
opcionales (ver opciones de TCP).
2. Cuando la Máquina 2 recibe el segmento, su entidad TCP verifica si algún proceso ha
activado la primitiva LISTEN (escucha) sobre el puerto indicado en el campo Puerto Destino
del segmento recibido. Si no lo hay, responde con un segmento con la bandera RST
encendida y la conexión no se establece. Si hay un proceso en escucha (LISTEN activo), la
entidad TCP acepta la conexión y responde con un envío de reconocimiento: bit SYN=1, bit
ACK=1, un Número de Secuencia y (elegido independientemente de x) y un Número de
Reconocimiento x+1 (el próximo número de secuencia que está esperando recibir).
3. La Máquina 1 recibe la respuesta y responde a su vez con un segmento con el bit SYN=0,
bit ACK=1, Número de Secuencia x+1 tal cual espera la Máquina 2, Número de
Reconocimiento y+1. La comunicación queda establecida.
En el segmento 2 va incluido el reconocimiento del segmento 1. Usar un segmento de otro tipo para
enviar en él un reconocimiento de un segmento anterior se denomina "piggybacking"; ahorra el envío
de un segmento exclusivo para el reconocimiento.
Fig. 1. TCP: establecimiento de conexión
Página 2 de 7
2. Fin de conexión en TCP.
TCP establece una conexión bidireccional full-duplex que puede verse como dos conexiones
unidireccionales independientes, una de Máquina 1 a Máquina 2 y otra de Máquina 2 a Máquina 1.
El fin de conexión en TCP se realiza para cada una de estas conexiones unidireccionales en forma
independiente como se indica en la figura 2.
1. La aplicación en la Máquina 1 cierra la conexión (significa que no va a enviar más datos,
pero sí seguirá leyendo los datos que reciba). Se envía a la Máquina 2 un segmento con la
bandera FIN encendida, con Número de Secuencia x. La Máquina 2 lo recibe, reconoce el
pedido de fin de conexión y envía inmediatamente un reconocimiento a la Máquina 1, al
tiempo que informa a la aplicación de la Máquina 2 sobre el fin de conexión iniciado desde la
Máquina 1. Para indicar que está reconociendo el FIN, el campo de nº de reconocimiento lo
setea en x+1
2. Cuando la aplicación de la Máquina 2 decide cerrar la conexión (no va a enviar más datos,
pero seguirá enviando segmentos de reconocimiento si es necesario), se envía a la Máquina
1 un segmento con bandera de FIN encendida, con Número de Secuencia y, Bandera de
ACK= 1 y Número de Reconocimiento x+1. La Máquina 1 recibe el segmento FIN y
responde con un segmento ACK de Número de Reconocimiento y+1.
Es posible que el reconocimiento del FIN de máquina 1, y la indicación de FIN de la máquina 2
se envíen en el mismo segmento (piggybacking).
Fig. 2. TCP: fin de conexión
El envío de un segmento RST durante cualquier momento de la conexión significara la
finalización asimétrica de la conexión.
3. Control de flujo en TCP.
Para el control de flujo, TCP utiliza ventanas de tamaño variable. Al transmitir se deben mantener
almacenados los segmentos ya enviados que no han recibido el ACK correspondiente.
El tamaño de la ventana de recepción es indicado en cada segmento TCP mediante el campo
“Window Size” (WIN) del encabezado, que indica la cantidad de bytes que pueden ser recibidos en
cada momento.
Por detalles del control de flujo en capa de transporte, consultar el libro “Computer Networks” de
Andrew S. Tanenbaum y el material de teórico.
Página 3 de 7
4. Control de congestión en TCP.
Cuando la carga en una red excede su capacidad surge la congestión: los segmentos se demoran en
los almacenamientos temporales ("buffers") de los enrutadores, y pueden ser descartados. Cuando
las demoras exceden los tiempos esperados los segmentos se consideran perdidos, volviendo a
transmitirse. La congestión, una vez iniciada, crece rápidamente.
TCP intenta manejar la congestión manipulando dinámicamente el tamaño de la ventana del
transmisor, para no inyectar en la red más segmentos de los que esta pueda manejar. TCP asume
que la confiabilidad actual de los medios físicos permite suponer que todas las pérdidas de
segmentos se deben a fenómenos de congestión. Esto no siempre es cierto, por ejemplo hay enlaces
inalámbricos y satelitales con altas tasas de pérdidas, y esto empeora la performance de TCP.
Como además de esta ventana de control de congestión en el transmisor existe la ventana del
receptor (para el control de flujo), deberá tomarse el mínimo de ambas ventanas para determinar lo
que puede transmitirse. En lo que sigue se asume que la ventana del receptor es infinita, por lo que el
comportamiento indicado en la figura 3 no tiene en cuenta la limitación que impondría la ventana del
receptor.
En el mecanismo clásico de control de congestión, el emisor comienza fijando el valor de la ventana
de transmisión en 1 MSS1 (típicamente 1460 bytes en una ethernet). Envía una ráfaga del tamaño de
la ventana, y si recibe todos los reconocimientos en tiempo (no hay "timeout"), duplica el tamaño de la
ventana (en realidad, por cada byte reconocido, aumenta el tamaño de la ventana en un byte). Este
algoritmo de crecimiento exponencial se denomina "de arranque lento". El crecimiento continúa de
esta manera (incrementando la ventana en un byte por cada byte reconocido) hasta alcanzar un valor
umbral, fijado inicialmente en 64 KBytes. Una vez alcanzado el umbral se continúa con un crecimiento
lineal, agregando 1 MSS (Aprox. 1460) cada vez que se recibe el reconocimiento de toda una ventana
de datos.
Cuando ocurre un "timeout", el umbral se reduce a la mitad del tamaño de la ventana en dicho
instante, y la ventana de congestión se reinicia a 1 MSS (en la versión original de TCP),
recomenzando su crecimiento tal cual se indicó anteriormente (Fig. 3).
Fig 3. Control de congestión
1Maximum Segment Size, que es el máximo tamaño de segmento que la red permite sin fragmentar, normalmente 1500 bytes
menos los encabezados de capa 3 y de capa 4
Página 4 de 7
4. Temporizadores en TCP.
TCP usa varios temporizadores, algunos de los más importantes son:

temporizador de retransmisión: arranca al enviar un segmento, si no llega el
reconocimiento antes de expirar, retransmite. A nivel de Capa de Transporte las variaciones
en el tiempo de retorno (ida y vuelta) hacen difícil fijar un valor fijo para el temporizador. TCP
emplea el algoritmo de Jacobson para estimar una variable RTT ("round-trip time", tiempo
de ida y vuelta) en base a la cual fija el temporizador de retransmisión (ver Tanenbaum).

temporizador de persistencia: es utilizado para evitar el bloqueo producido por la perdida
de un segmento avisando ventana no nula luego de que el emisor haya recibido un anuncio
de ventana de recepción 0. Al expirar el temporizador de persistencia, el emisor envía un
segmento de sondeo (con 1 byte de datos) al receptor para actualizar información sobre la
ventana de recepción. Otra opción para recibir una actualización de ventana que se utiliza
es enviar un segmento sin datos y con un número de secuencia que ya fue reconocido, de
esta manera el receptor supone que es un segmento repetido, entonces re-envía el último
reconocimiento con el valor de ACK y tamaño de ventana correctos. Como ejemplos, Linux
utiliza la segunda opción, mientras que FreeBSD utiliza la primera.

temporizador de tiempo de vida: cuando la conexión ha estado inactiva mucho tiempo,
este temporizador expira y se envía al otro lado un segmento de verificación: si no es
contestado, se procede a iniciar la secuencia de corte de conexión.
5. Política de transmisión en TCP
En TCP el emisor no está obligado a transmitir datos en cuanto los recibe de la aplicación, ni el
receptor a enviar los reconocimientos en forma inmediata. Una aplicación de edición remota puede
recibir caracteres del usuario de a uno, lo que obligaría en principio a transmitir un segmento por cada
carácter. Esto tiene un alto costo: 20 bytes de encabezado IP + 20 bytes encabezado TCP + 1 byte
del carácter (datos) = 41 bytes.
A su vez este envío generará una respuesta de reconocimiento de TCP (20 bytes de encabezado IP +
20 bytes encabezado TCP) y luego la aplicación del receptor enviará un mensaje con el eco del
carácter para ser desplegado en la aplicación del emisor.
Una primera mejora es demorar el reconocimiento (como máximo unos 500 ms.) en espera de datos
moviéndose en la otra dirección, para mandar el reconocimiento en el mismo segmento
(piggybacking). Con esta mejora, el reconocimiento del primer segmento y el eco generado por el
receptor viajarían en el mismo segmento.
El algoritmo de Nagle intenta mejorar la eficiencia enviando los primeros bytes recibidos de la
aplicación y reteniendo los subsiguientes hasta recibir reconocimiento del primero, momento en el
cual se envían todos los retenidos en un solo segmento, volviendo a retener los siguientes bytes
recibidos hasta el nuevo reconocimiento.
El algoritmo dice que solamente puede haber en tránsito (sin haber sido reconocido) un segmento de
tamaño no máximo.
Una situación similar se da cuando la aplicación en el receptor lee los datos de a un byte (o muy
pocos) por vez. Una vez llena la ventana de recepción, si la aplicación lee un byte y el receptor
anuncia una ventana de 1 byte, entonces el emisor enviaría un segmento con un solo byte de datos,
generando la misma ineficiencia. Este efecto se conoce como Síndrome de ventana tonta. La solución
utilizada (conocida como solución de Clark) consiste en impedir al receptor enviar avisos de tamaño
de ventana hasta no tener capacidad para alojar un MSS o la mitad de la capacidad de buffer total (el
menor de los casos).
El algoritmo de Nagle y la solución de Clark son complementarias, actuando una en el emisor y la otra
en el receptor.
Página 5 de 7
Es de observar que distintas implementaciones de TCP (distintos sistemas operativos) tienen
pequeñas variaciones en la implementación de estas políticas.
6. El programa "sock".
Este es un programa de prueba capaz de generar tráfico de capa de transporte controlando diversos
parámetros. Es utilizado en el libro "TCP/IP Illustrated, Volume 1: The Protocols" para ejemplificar
diversos problemas. Según los parámetros que se le indiquen, permite trabajar en modo servidor o
cliente; pueden fijarse también los puertos involucrados en la conexión y configurar el tamaño de las
ventanas, el largo de los segmentos, la cantidad de segmentos, introducir pausas, deshabilitar Nagle,
etc. Puede trabajar con protocolos TCP o UDP.
El programa se encuentra brevemente documentado en el material publicado separadamente.
Siguen algunos ejemplos.
El cliente debe elegir a qué máquina y a qué puerto desea conectarse:
sock m1 9
donde m1 es una máquina ficticia; la conexión se pide al puerto 9 (discard) de la máquina m1. Para
que se establezca la conexión es necesario que la máquina esté brindando el servicio en el puerto
solicitado. Como el programa permite operar también como servidor, trabajaremos con el mismo
programa sock en los dos extremos, usando números de puertos que normalmente se encuentran
libres. Debe iniciarse primero el servidor y luego el cliente.
Para iniciar el servidor ejecutar en la máquina m1:
sock -s 5555
La opción -s indica que es un servicio y 5555 es el número de puerto que atiende. Luego iniciamos el
cliente en la máquina m2:
sock m1 5555
De ahora en más todo lo digitado en m2 se transferirá a m1, apareciendo los datos en la terminal de
m1.
Veamos otras opciones. Trabajaremos siempre con la opción -v (verboso), para disponer de
información sobre la conexión. Usaremos también la opción -i : en el cliente indica escribir datos en la
red, en el servidor indica leer y descartar (sin usar la salida estándar). La cantidad de datos a escribir
por el cliente en cada oportunidad se indica con la opción -w n y la que leerá el servidor con la opción
-r n, encontrándose por defecto ambas en n=1024 bytes. La opción -n n indica el número de buffers
de ese tamaño a escribir.
Podríamos entonces transferir 15 buffers de 1024 bytes ejecutando primero en m1:
sock -s -i -v 6001
y en luego en m2:
sock m1 -i -v -n15 6001
Las opciones -R y -S que permiten seleccionar los tamaños de los buffers del puerto receptor y
transmisor. Al ejecutar en m1:
sock -s -i -v -R4096 6666
estamos indicando que queremos que el buffer del puerto 6666 tenga un tamaño de 4096 bytes, por
lo que si el sistema operativo lo respeta, la ventana del receptor estará siempre acotada por dicho
valor.
Otras opciones útiles son:
-p n establece pausa de n segundos entre cada transmisión (o recepción si va junto con -s);
-P n establece pausa de n segundos luego de la primera recepción o transmisión;
-u los segmentos serán de UDP en lugar de TCP;
-N deshabilita el algoritmo de NAGLE.
Página 6 de 7
El conjunto de opciones puede verse en el material publicado aparte sobre el Programa sock.
Observación: el programa sock tiene un error de implementación, que hace que a veces cuando los
datos se envían en bloques que generan segmentos que no sean de tamaño máximo, el servidor se
corte antes de finalizar la lectura de datos.
7. Ejercicios Sugeridos
•
Analice el uso de las banderas en el inicio y fin de una conexión TCP.
•
Analice como configurar la aplicación TELNET para que envie los datos a la capa de
transporte a medida que ingresan y no espere a completar una linea.
•
Repase la utilización de filtros de captura y visualización en Wireshark.
•
Analice las siguientes llamadas al programa SOCKS para conocer sus opciones.
◦
sock -s -v -i -r1448 -R11584 5500
◦
sock -v -i -n20 -w1448 m2 5500
◦
sock -s -v -i -r16 -R128 5500
8. Referencias.







Tanenbaum, Andrew. "Computer networks", 4a. edición, Prentice-Hall, 2003, 3a. edición.
Prentice-Hall, 1996. En la 4a. edición, 6.2 Elements of transport protocols y 6.5 The
Internet transport protocols: TCP. En la 3a edición, secciones 6.2 y 6.4.
Stevens, Richard. "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1996.
Capítulos 17 al 23.
FreeBSD
Hypertext
Man
Pages.
Páginas
"man"
de
unix
en
línea
(http://www.freebsd.org/cgi/man.cgi ). En particular para la práctica: telnet
Requests for Comments (RFC), por ejemplo en http://www.rfc-editor.org. En particular,
protocolo discard (RFC 863), algoritmo de Nagle (RFC 896), la solución de Clark (RFC
813).
Página de Wireshark www.wireshark.com. Contiene un tutorial.
Instructivo de Wireshark preparado para el curso.
The Internet Lab Manual. http://www.tcpip-lab.net/ . En particular, el capítulo 2, sección 6.5,
que tiene un detalle de como aplicar filtros en el Wireshark.
Para conocer más.


Analizar las diferencias entre el protocolo TCP y el UDP.
Realizar conexiones con el sock, utilizando pausas entre los segmentos, variando las
ventanas y cualquier combinación de parámetros que le parezca interesante.
Evaluación del laboratorio.
Agradecemos que nos envíe sus aportes al foro específico creado en la página web del curso.
Redes de Datos - Curso 2016 - Página del curso: http://eva.universidad.edu.uy/
course/view.php?id=545
Instituto de Ingeniería Eléctrica - Facultad de Ingeniería - UDELAR, CURE, Rocha.
Página 7 de 7

Instructivo

Transcripción

Documentos relacionados

Innovación