Laboratorio de Comunicación de Datos

Práctica 2. Protocolos de nivel de transporte UDP y TCP

Departamento de Eléctrica y Electrónica

Resumen

Esta práctica está orientada a entender el funcionameinto básico de los pro-

tocolos de nivel de transporte UDP y TCP y a entender el funcionamiento
de los mecanismos de control de flujo y control de congestión de TCP.
Nota: Al cargar cada una de las capturas en Wireshark, es necesario or-
denar los paquetes por su marca de tiempo, pulsando en la pestaña Time,
de esta forma podremos analizar lo que ha ocurrido ordenamente siguiendo
el eje temporal.

1. Comunicación UDP

En la captura udp.cap se muestra una comunicación UDP. Contesta a

las siguientes preguntas:

1. ¿Cuáles son las direcciones IP y puertos involucrados en la comunica-

ción?

2. ¿En qué red se ha realizado la captura?

3. ¿Cuál es el número de paquetes UDP y número de bytes de datos

intercambiados?

4. Dibuja un escenario en NetGUI con 2 subredes conectadas a través de

r1:

Subred 11.0.0.0 máscara 255.255.255.0

Subred 12.0.0.0 máscara 255.255.255.0

Dibuja 2 pcs:

pc1 conectado a la subred 11.0.0.0, configurando su dirección IP

a 11.0.0.10
pc2 conectado a la subred 12.0.0.0, configurando su dirección IP
a 12.0.0.10

1
 Asigna direcciones IP a r1 y configura las rutas que consideres necesa-
rias para que los pcs puedan comunicarse.
El comando nc puede utilizarse para generar tráfico UDP. Por ejem-
plo, el siguiente comando ejecutado en pc1 envı́a lo introducido por la
entrada estándar a la máquina 12.0.0.10, puerto UDP 11111:

pc1: ∼ # nc -u 12.0.0.10 11111

Utiliza este comando dentro de NetGUI para explicar razonadamente

qué tráfico se generarı́a en las siguientes situaciones cuando desde pc1
se intena enviar datagramas UDP a la máquina 12.0.0.10, puerto 11111:

a) Existe la máquina 12.0.0.10 pero no hay una aplicación escuchando

en el puerto 11111.
b) Existe la red 12.0.0.0/24 y hay ruta para llegar hasta ella, pero no
existe la máquina 12.0.0.10. (para realizar este apartado apaga la
máquina 12.0.0.10)

2. Comunicación TCP
2.1. Establecimiento de conexión, envı́o de datos y finalización de
conexión

En la captura tcp.cap se muestra una comunicación TCP entre dos apli-

caciones.
Para filtrar el tráfico de una conexión TCP de entre el resto del tráfico
que aparezca en una captura se puede seleccionar uno de sus segmentos y
luego seleccionar la opción de menú Analyze → Follow TCP Stream. De esta
forma Wireshark sólo mostrará los segmentos de la conexión seleccionada.
Contesta a las siguientes preguntas:

1. ¿Cuál es la dirección IP y el puerto del cliente TCP y la dirección IP

y el puerto del servidor TCP?

2. ¿Cuántos segmentos TCP se han enviado desde el cliente al servidor?

3. ¿Cuántos segmentos TCP se han enviado desde el servidor al cleine?

4. Indica qué extremo cierra antes la conexión.

2
2.1.1. Números de secuencia

En el menú de Wireshark, seleccionando en el menú Edit→Preferences→Protocolos→TCP,

puedes desactivar la opción Relative Sequence Numbers & Window Scaling.
De esta forma podrás observar los números de secuencia reales, en lugar de
los números relativos que muestra por omisión Wireshark.
1. ¿Cuántos bytes de datos envı́a el servidor al cliente? Razona la res-
puesta. Indica cuáles son los números de secuencia del SYN y del FIN
que envı́a el servidor, y qué relación tienen con la cantidad de datos
enviada por el servidor al cliente.

2. ¿Cuántos bytes de datos envı́a el cliente al servidor? Razona la respues-

ta. Indica cuáles son los números de secuencia del SYN y del FIN que
envı́a el cliente, y qué relación tienen con la cantidad de datos enviada
por el cliente al servidor.
Cuando hayas observado los números de secuencia reales, vuelve a acti-
var la opción Relative Sequence Numbers & Window Scaling para que resulte
más fácil analizar la captura en los siguientes apartados.

2.1.2. RTT

1. Para cada uno de los segmentos de datos que envı́a el cliente al servidor,
indica cuál es el RTT. Observa para ello los tiempos de envı́o de los
segmentos y los de recepción de sus correspondientes asentimientos.
2.1.3. Ventana anunciada y factor de escala

En los segmentos que llevan activado el flag SYN se informa de los valores
de número de secuencia inicial y ventana inicial anunciada que tiene cada
extremo de la comunicación TCP. La opción factor de escala de la ventana
(window scale) puede indicarse en la parte de opciones de los segmentos
que llevan el flag SYN.
Cuando el lado que abre la conexión quiere utilizar un factor de escala
para la ventana anunciada, activará la opción en su paquete SYN. El otro lado
debe activar la opción en su paquete SYN+ACK para indicar que entiende
esta opción de TCP y va a utilizarla también. A partir de este momento,
en los segmentos que envı́en ambos lados se aplicará el factor de escala para
calcular el valor real de la ventana que se está anunciando: se multiplicará
2f actor por el campo de ventana anunciada que viaja en el segmento. Nótese
que solo en el segmento SYN y en el SYN+ACK viaja el factor de escala,

3
pero éste no se aplica al campo ventana anunciada de estos dos segmentos,
sino que se aplica a todos los demás segmentos enviados.
Wireshark aplica automáticamente el factor de escala y lo indica con la
etiqueta scaled. Para ver el campo ventana anunciada que viaja realmente en
la cabecera TCP hay que desactivar la opción Relative Sequence Numbers &
Window Scaling en el menú Edit→Preferences→Protocolos→TCP.

1. Indica cuál es el valor del campo de ventana anunciada (Window size)

en los segmentos SYN en cada uno de los dos sentidos.

2. Indica cuál es el valor del campo de ventana anunciada (Window size)

en los segmentos que no tienen el flag SYN activado en cada uno de los
dos sentidos.1 .

3. Indica cuál es el valor real de ventana anunciada teniendo en cuenta el

factor de escala que se incluye en las opciones de los segmentos SYN y
SYN+ACK.

Cuando hayas observado el campo de la ventana anunciada, vuelve a ac-

tivar esta opción para que resulte más fácil analizar la captura.

2.1.4. MSS

En la captura tcp-mss.cap se muestra una comunicación TCP. Contesta

a las siguientes preguntas:

1. Indica cuál es el valor anunciado de MSS en las cabeceras opcionales

en los dos sentidos. Justifica estos valores.

2. Indica los tamaños de las cabeceras de los segmentos medidos en pala-

bras de 4 bytes y razona por qué son distintos. ¿Crees que el tamaño
de la cabecera puede influir en el tamaño máximo de datos que poste-
riormente utilizará TCP para enviar segmentos?

3. Teniendo en cuenta que en el instante en el que se envı́a el segmento

número 8, la máquina 11.0.0.2 tenı́a 762 datos que enviar a la máqui-
na 12.0.0.2, justifica el tamaño del campo de datos en los segmentos
número 8 y número 9.
1
TCP inicialmente no anuncia en el campo Window size todo el buffer que tiene dispo-
nible, sigue un algoritmo para anunciar inicialmente un valor pequeño y lo va aumentando
según va avanzando la conexión hasta que llega a anunciar el tamaño total del buffer

4
2.1.5. El servidor TCP no está disponible

Dibuja un escenario en NetGUI con 2 subredes conectadas a través de r1:

Subred 11.0.0.0 máscara 255.255.255.0

Subred 12.0.0.0 máscara 255.255.255.0

Dibuja 2 pcs:

pc1 conectado a la subred 11.0.0.0, configurando su dirección IP a

11.0.0.10

pc2 conectado a la subred 12.0.0.0, configurando su dirección IP a

12.0.0.10

Asigna direcciones IP a r1 y configura las rutas que consideres necesarias

para que los pcs puedan comunicarse.
El comando nc puede utilizarse para generar tráfico TCP. Por ejemplo,
el siguiente comando ejecutado desde pc1 intenta establecer una conexión
TCP con la máquina 12.0.0.10, puerto TCP 11111:

pc1: ∼ # nc 12.0.0.10 11111

Utiliza este comando dentro de NetGUI para explicar razonadamen-

te qué tráfico se generarı́a en las siguientes situaciones cuando se intenta
establecer una conexión TCP desde pc1 con la máquina 12.0.0.10, puerto
11111:

1. Existe la máquina 12.0.0.10 pero no hay una aplicación escuchando en

el puerto 11111.

2. Existe la red 12.0.0.0 y hay ruta para llegar hasta ella, pero no existe
la máquina 12.0.0.10. (Para realizar este apartado apaga la máquina
12.0.0.10).

2.2. Retransmisión de SYN

En la captura tcp-syn.cap se muestra una comunicación TCP. Contesta

a las siguientes preguntas:

1. ¿Cuántas veces se envı́a el segmento SYN del cliente al servidor?

5
 2. Indica la secuencia de marcas de tiempo de los segmentos SYN envia-
dos, y explica sus valores atendiendo al mecanismo exponential backoff.
3. Explica por qué aparecen varios segmentos ACK repetidos.

3. Slow Start en el inicio de la conexión

En este experimento se observa el comportamiento del mecanismo de TCP

arranque lento (Slow Start).
Carga en Wireshark la captura slow-start.cap. Selecciona el primer seg-
mento que envı́a el cliente al servidor, y a continuación muestra en Wires-
hark el diagrama de la conexión mediante el menú: Statistics→TCP Stream
Graph→Time-Sequence Graph (tcptrace)
Observa la gráfica de la captura, y cada uno de los segmentos. Explica
cómo afecta Slow Start el envı́o de nuevos segmentos en el inicio de la cone-
xión.

4. Timeout

En este experimento se observa el comportamiento del mecanismo de

control de congestión de TCP tras un timeout.
Carga en Wireshark la captura ss-timeout.cap. Selecciona el primer
segmento que envı́a el cliente al servidor, y a continuación muestra en Wires-
hark el diagrama de la conexión mediante el menú: Statistics→TCP Stream
Graph→Time-Sequence Graph (tcptrace)

1. Observa la captura y explica cómo afecta Slow Start al envı́o de nuevos

segmentos al inicio de la conexión.
2. Estudia el comportamiento tras el timeout. Analiza tanto la gráfica co-
mo cada uno de los segmentos. Explica qué diferencia aprecias respecto
al comportamiento al inicio de la conexión.

5. Fast Retransmit / Fast Recovery

En este experimento se observa el comportamiento de TCP tras la re-

cepción de 3 ACKs duplicados. Carga en Wireshark la captura fr-fr.cap y
ordena los paquetes de la captura según la columna Time.
Para identificar si una retransmisión es debida a Fast Retransmit com-
prueba las siguientes condiciones:

a) Anteriormente a la retransmisión hay 4 ACKs (1 + 3 duplicados) o más

sobre el número de secuencia que se está retransmitiendo.

6
 b) Se envı́an más datos nuevos después de realizar la retransmisión y antes
de recibir su ACK.

Wireshark interpreta los segmentos TCP de las capturas e identifica si una

retransmisión es debida a Timeout o Fast Retransmit. Sin embargo, a veces
la captura no está bien ordenada según el eje temporal y las interpretaciones
que hace Wireshark no son correctas. Por este motivo para saber por qué
se produce una retransmisión es necesario analizar las condiciones descritas
anteriormente.
Observando la captura fr-fr.cap responde a las siguientes preguntas:
1. ¿Cuántas retransmisiones debidas a timeout se observan en la traza?
Identifica en qué instante se producen.

2. ¿Cuántas retransmisiones debidas a Fast Retransmit se observan en la

traza? Identifica en qué instante se producen.

3. Observa la primera ocasión en la que se produce Fast Retransmit. Com-

prueba cuántos paquetes se envı́an después de haber recibido el primer
ACK nuevo. Relaciona este valor con el valor que tenı́a la ventana de
congestión cuando ocurrió Fast Retransmit.

4. Después de enviar el paquete retransmitido en la primera ocasión en

que se produce Fast Retransmit, se envı́an nuevos segmentos antes de
recibir ACKs. ¿Cuántos? ¿Por qué?
6. Ventana enunciada

En este experimento se observa cómo se comporta TCP atendiendo al

valor de ventana anunciada.
Carga en Wireshark la captura sondas.cap.
Observa la captura y comprueba el comportamiento de la ventana anun-
ciada a partir del segmento 43.

1. Localiza en la traza anuncios de ventana 0 enviados por el servidor

al cliente. Observa las sondas de ventana que envı́a el cliente en ese
periodo.

2. Explica el comportamiento de TCP entre los segmentos 43 y 87.

3. Indica en qué modo de control de congestión se encuentra la conexión

TCP en los siguientes puntos:

Antes del segmento 43.

7
Entre el segmento 43 y 87
Después del segmento 87