Soluciones de las Ejercicios de Sistemas Telem aticos I

Protocolos de Transporte: UDP y TCP

Departamento de Sistemas Telem aticos y Computaci on (GSyC)
Mayo de 2010
1. Comunicaci on UDP
1. Origen: 10.0.0.2, puerto 32768.
Destino: 11.0.0.2, puerto 33000.
2. En la red 10.0.0.0. Lo pone de maniesto la presencia del ARP, que solo puede ser capturado en la red en la que
estan las maquinas que participan en el.
3. 2 paquetes UDP. Se han intercambiado 11 bytes de datos (5 en el primer paquete, y 6 en el segundo).
4. a) Por cada paquete UDP enviado aparece un mensaje ICMP de tipo 3 y codigo 3: Destino inalcanzable por
puerto inalcanzable. Este mensaje lo enva la maquina destino del paquete UDP original.
b) Por cada paquete UDP enviado aparece un mensaje ICMP de tipo 3 y codigo 1: Destino inalcanzable por
maquina inalcanzable. Este mensaje lo enva el router r1 al no recibir respuesta a la solicitud de ARP
preguntando por la 12.0.0.10 que el hace en la red 12.0.0.0.
2. Comunicaci on TCP
2.1. Establecimiento de conexi on, envo de datos y nalizaci on de conexion
1. En una conexion TCP el cliente es el proceso que primero enva el SYN. As que, en este caso:
Cliente: 10.0.0.2, puerto 60709.
Servidor: 11.0.0.2, puerto 34000.
2. 6 segmentos: SYN, ACK, DATA, DATA, FIN, ACK
3. 4 segmentos: SYN+ACK, ACK, ACK, FIN+ACK
4. En esta conexion quien enva el FIN primero (y por lo tanto cierra primero la conexion) es el cliente.
2.1.1. N umeros de secuencia
1. 0 bytes de datos.
Los datos enviados pueden calcularse sumando todos los bytes de datos de los segmentos de ese sentido de la
comunicacion que contienen datos (estos segmentos aparecen etiquetados en Wireshark con un Len distinto de
0), sin tener en cuenta los segmentos que son retransmisiones.
Otra forma mas sencilla de calcular en n umero de bytes de datos enviados es jarse en los n umeros de secuencia
del paquete SYN y del paquete FIN de ese sentido de la comunicacion. As:
Bytes de datos transmitidos = N
o
sec FIN - N
o
sec SYN - 1
Por lo tanto, para el sentido de los datos enviados del servidor al cliente el n umero de bytes de datos transmitidos
es 0.
2. 11 bytes de datos, calculados de la misma manera.
1
2.1.2. RTT
1. Primer segmento con datos: 0.001017 segundos (diferencia entre el tiempo de recepcion del ACK y el tiempo
del envo del segmento).
Segundo segmento con datos: 0.000549 segundos.
2.1.3. Ventana anunciada y factor de escala
1. 11.0.0.2 12.0.0.2: Ventana anunciada = 5840 bytes
12.0.0.2 11.0.0.2: Ventana anunciada = 5792 bytes
2. 11.0.0.2 12.0.0.2: Ventana anunciada = 2920 bytes
12.0.0.2 11.0.0.2: Ventana anunciada = 2896 bytes
3. 11.0.0.2 12.0.0.2: El campo de ventana anunciada tiene un valor de 2920 bytes, y en el paquete SYN su
factor de escala es 1 (lo que indica que hay que multiplicar por 2
1
el campo de ventana). Por lo tanto la
ventana real es 5840 bytes.
12.0.0.2 11.0.0.2: El campo de ventana anunciada tiene un valor de 2896 bytes, y en el paquete SYN+ACK
su factor de escala es 1 (lo que indica que hay que multiplicar por 2
1
el campo de ventana). Por lo tanto la
ventana real es 5792 bytes.
2.1.4. MSS
1. 11.0.0.11 12.0.0.12: MSS = 660 bytes.
12.0.0.12 11.0.0.11: MSS = 560 bytes.
Los dos sentidos de la comunicacion usaran como tama no maximo de datos el menor de estos dos valores, es
decir, 560 bytes.
2. En ambos sentidos, el SYN tiene tama no de cabecera 10 palabras de 4 bytes (40 bytes): 5 palabras (20
bytes) de la parte ja de la cabecera, y 5 palabras (20 bytes) de opciones.
En el resto de segmentos, el tama no de cabecera es 8 palabras de 4 bytes (32 bytes): 5 palabras (20 bytes)
de la parte ja de la cabecera, y 3 palabras (12 bytes) de opciones.
Los tama nos de las cabeceras de los distintos segmentos son diferentes porque hay opciones que solo viajan en
los paquetes SYN, concretamente las opciones MSS y Window Scale. Por eso los paquetes SYN y SYN+ACK
tienen mayor tama no de cabecera.
El tama no de la cabecera s inuye en el tama no de datos de los segmentos: el valor de MSS esta calculado para
el supuesto de que los paquetes no lleven opciones ni en la cabecera IP ni en la cabecera TCP. Cuando se enve
un segmento concreto al MSS habra que restarle lo que ocupen las cabeceras opcionales que lleve dicho segmento,
y el resultado sera la mayor cantidad de bytes de datos que pueden viajar en ese segmento.
3. En el segmento 4 el cliente enva menos de los 2000 bytes para intentar evitar la fragmentacion IP. Para ello
tiene en cuenta el menor de los dos valores de MSS anunciados al establecerse la conexion, es decir, 560 bytes.
Este tama no de datos se utilizara en paquetes sin opciones en la cabera de IP y sin opciones en la cabecera de
TCP. Como el segmento 4 tiene 12 bytes de opciones en la cabera TCP (y 0 bytes de opciones en la cabecera
IP), dicho segmento puede llevar un maximo de 560 - 12 = 548 bytes de datos.
4. Los paquetes 5 y 7 son mensajes de ICMP de destino inalcanzable porque se necesitaba fragmentacion. Los enva
un router del camino entre el cliente y el servidor.
El que existan estos paquetes en la captura indica que un router del camino esta conectado a un nivel de enlace
que requiere un tama no maximo permitido para los datos a un menor que el que se esta usando en la conexion
1
.
Los paquetes 4 y 6 llevan activado en la cabecera IP el ag DF (No Fragmentar). Eso hace que cuando lleguen a
un router que necesite fragmentar esos datagramas (en este caso el router 11.0.0.1) no pueda hacerlo por estar
activado dicho ag, y no le quede otro remedio que descartarlos, y enviar un mensaje ICMP al origen por cada
datagrama que descarta.
La tecnica conocida como Path MTU Discovery consiste precisamente en este hecho de enviar los datagramas
IP con el ag DF activado, esperando a recibir ICMPs de destino inalcanzable por necesitar fragmentacion, y en
ese caso, hacer los datagramas mas peque nos.
1
El elegir el menor de los dos valores de MSS enviados en el establecimiento de la conexion no excluye la posibilidad de que, en tr ansito,
un router del camino se vea obligado a fragmentar pues este conectado a un nivel de enlace con un tama no maximo de paquete m as peque no
que los de los niveles de enlace a los que estan conectados cliente y servidor
2
5. El cliente de la conexion TCP, al recibir los ICMP, ve en su contenido (campo MTU of next hop) el tama no
maximo de datos que puede poner en sus segmentos: 500 bytes. Y como sabe que los segmentos 4 y 6 han sido
descartados, debe reenviarlos con el tama no adecuado. As, los 548 bytes de datos del segmento 4 se retransmiten
repartidos en el segmento 8 (500 bytes de datos) y segmento 9 (48 bytes de datos). Y analogamente ocurre con
los datos del segmento 6, que se retransmiten en los segmentos 12 y 13.
2.1.5. El servidor TCP no esta disponible
1. La conexion no puede establecerse. El cliente, tras enviar el SYN, recibe un segmento TCP desde 12.0.0.10 con
el ag RST (RESET) activado, lo que hace que se cierre abruptamente la conexion.
2. La conexion no puede establecerse. El cliente, tras enviar el SYN, recibe un mensaje ICMP de tipo 3 y codigo
1: Destino inalcanzable por maquina inalcanzable. Este mensaje lo enva el router r1 al no recibir respuesta a la
solicitud de ARP preguntando por la 12.0.0.10 que el hace en la red 12.0.0.0.
2.2. Retransmision de SYN
1. 5 veces.
2. Las secuencia de marcas de tiempo en los envos de los SYN es: 0.00, 2.96, 8.96, 20.96, 44.97. Restando de cada
tiempo el anterior, para ver el plazo de retransmision, nos quedan los valores para el plazo de 2.96, 6.00, 12.00,
y 24.01, lo que muestra el mecanismo del exponential backo.
3. Cada SYN que llega al servidor provoca el envo de un ACK. Como el retardo es muy grande, vencen los plazos
que va teniendo el cliente, pero como los mensajes no se han perdido, a cada uno de ellos el servidor debe
responder con un SYN+ACK.
3. Slow Start en el inicio de la conexi on
Nunca se llega a enviar tantos datos como el valor dado por la ventana de control de ujo (o ventana anunciada)
ya que en este caso siempre esta limitando la ventana de control de congestion.
Se envan inicialmente 3 segmentos con datos (instante aprox. 1.0). Hay que recordar que en Linux la ventana
de congestion inicial es un valor al azar entre 1 y 3.
Recibidos sus ACKs se pueden enviar hasta 6 segmentos, y de hecho se envan 6 segmentos con datos (instante
aprox. 2.0)
Al recibir sus ACKs podramos enviar hasta 12 segmentos, y se envan 7 segmentos (instante 3.1 aprox), pues no
se dispone de mas segmentos procedentes de la aplicacion en ese momento.
Al recibir sus ACKs se podran enviar hasta 19 segmentos (sumando uno a la ventana de congestion por cada
ACK recibido), y se envan 11.
Y as sucesivamente.
4. Timeout
1. En el inicio de la conexion, TCP se encuentra en Slow Start: se envan 2 segmentos con datos (instante aprox
1.5), al recibirse los ACKs se permite enviar hasta 4 segmentos y se envan 4 segmentos (instante aprox 2.5), al
recibirse los ACKs se permite enviar hasta 8 segmentos y se envan 6 segmentos (instante aprox 3.5).
2. Hay una retransmision por timeout del segmento con n umero de secuencia 8689 (instante aprox 7.9). En ese
momento se inicia de nuevo Slow-Start con ventana de congestion 1 y valor de threshold igual a 4.
Al recibir el ACK de la retransmision del segmento 8689, la ventana de control de congestion pasa a valer 2 y
se transmiten 2 segmentos (son retransmisiones). Al recibir los ACKs de estas dos retransmisiones, la ventana
de congestion pasa a 4, se envan 4 segmentos y se pasa del modo Slow Start a Additive Increase ya que se ha
alcanzado el threshold.
3
5. Fast Retransmit / Fast Recovery
1. Conviene ordenar la captura de segmentos por su marca de tiempo. Se puede ver que ninguna de las retrans-
misiones que aparecen son debidas al vencimiento del timeout, sino a ACKs repetidos.
Puede observarse que cada retransmision esta precedida por al menos 3 ACKs duplicados, y ademas se transmiten
paquetes nuevos antes de que llegue el ACK de lo retransmitido.
Wireshark no identica correctamente que el paquete 114 es una retransmision rapida.
2. Las 4 retransmisiones se deben a Fast Retransmit: los segmentos con n umero: 46, 114, 173 y 215.
3. La ventana de congestion vale 12 alrededor del instante 3.0. Se reciben 4 ACKS alrededor del instante 4.0, lo
que hace que la ventana de congestion tenga un valor de 16 segmentos en el momento del Fast Retransmit del
segmento 46. Por tanto, en ese momento el threshold toma el valor de 8 segmentos. Se entra en Fast Recovery y
en el segmento n umero 62 se recibe el ACK que asiente lo retransmitido (y mas segmentos), momento en que la
ventana de control de congestion pasa a tomar el valor threshold, 8, pudiendose enviar hasta 8 segmentos. En la
gura se observa que se envan 6.
4. Se envan 4 segmentos nuevos. En Fast Recovery se mantiene la ventana de congestion que haba en el momento
del Fast Retransmit, que era 16, e incluso se aumenta en 1 por cada ACK repetido que vaya llegando. Como antes
del Fast Retransmit solo se haban enviado 12 segmentos, a un pueden enviarse nuevos segmentos, y se envan
estos 4.
6. Ventana anunciada
1. Los anuncios de ventana 0 los enva el servidor al cliente en los segmentos n umero 80 y 82. Wireshark los etiqueta
como [TCP ZeroWindow].
Las sondas de ventana las enva el cliente al servidor en los segmentos n umero 81 y 83. Wireshark los etiqueta
como [TCP Keep-Alive].
2. En la captura se observa que a partir de segmento n umero 43 la ventana anunciada va disminuyendo. En el
segmento 41 la ventana anunciada es 44888 a partir del n umero de secuencia 22177 (como maximo se permite
enviar hasta el byte n umero 67064). En el segmento 43 la ventana anunciada es 36200 a partir del n umero de
secuencia 30865 (como maximo se permite enviar hasta el byte 67064). En el segmento n umero 51 la ventana
anunciada es 34752 a partir del n umero de secuencia 32313 (como maximo se permite enviar hasta el byte 67064).
Y as sucesivamente hasta el segmento 79 donde se anuncia una ventana 4344 a partir del n umero de secuencia
67065 (como maximo se permite enviar hasta el byte 71408).
En el segmento n umero 80 se anuncia una ventana 0 a partir del n umero de secuencia 71409. Debido a que el
ultimo segmento enviado es el n umero 78 donde se enviaron los n umeros de secuencia desde 69961 hasta 71408,
ya no se pueden enviar mas datos hasta que no se anuncie un valor de ventana mayor.
Lo que ha ocurrido es que la aplicacion receptora no esta leyendo los datos y por tanto, el nivel TCP en el lado
receptor ha llenado por completo su buer de recepcion y no tiene capacidad para almacenar mas datos.
En el segmento 81 el lado emisor enva una sonda de ventana para que el receptor pueda contestar con un valor
de ventana que le permita enviar mas datos. La sonda de ventana no enva datos nuevos (no puede), repite el
ultimo n umero de secuencia (71408), pero no enva bytes de datos.
La ventana se abre en el segmento n umero 84, donde se anuncia un valor de ventana 2896 a partir del n umero
de secuencia 71409. Este evento coincidira con que la aplicacion ha comenzado a leer los datos que TCP tena
almacenados en su buer de recepcion.
El emisor ahora puede enviar dos nuevos segmentos (el lmite para el envo de datos en este momento no lo
establece la ventana de control de congestion sino la ventana de control de ujo).
A partir del segmento 87 el valor de la ventana anunciado va aumentando, permitiendo que el emisor pueda
enviar mas datos.
3. En ning un momento de la conexion se observa ninguna retransmision, por lo que en todo momento el modo de
control de congestion es Slow Start. Notese como el que se cierre la ventan anunciada no tiene inuencia en el
modo de control de congestion.
Lo que s puede observarse es que entre los segmentos 78 y 85 lo que limita al cliente es la ventana anunciada, y
no la ventana de congestion.
4
7. Estados de una conexi on TCP
7.1. Establecimiento de la conexi on
5. Antes de arrancar el cliente, el servidor se encuentra en estado LISTEN.
7. El servidor pasa de LISTEN a SYN_RCVD, y posteriormente, a ESTABLISHED.
9. La ventana anunciada por el servidor es de 36 bytes.
7.2. Intercambio de datos
5. El valor de Recv-Q en el lado del servidor es 36. Aunque el cliente ha enviado mas de 36 caracteres, como el
servidor anuncio una ventana de 36 bytes, y como esta detenido sin que la aplicacion lea los datos almacenados
en el buer de recepcion, el cliente no ha podido enviar mas datos al llenar la ventana anunciada.
6. En la captura de traco de r1 puede verse que el cliente, tras recibir del servidor un anuncio de ventana 0, enva
sondas de ventana, esperando que el servidor reabra la ventana y le enve un ack con nuevo tama no para la
ventana anunciada.
7.3. Finalizaci on de la conexion
4. La aplicacion en el cliente se mantiene durante un minuto en el estado TIME_WAIT. La razon es que, tras enviar
el cliente su ACK al FIN del servidor, no puede saber si este ACK llegara al servidor. Si no llegara, el servidor
reenviara su FIN, y el cliente debe mantenerse activo para reenviar el ACK. Si transcurrido este minuto no ha
recibido nada, sale denitivamente de la conexion.
5. La aplicacion en servidor termina inmediatamente al recibirse el cliente el ACK al FIN del servidor, ya que no
puede recibir ya mas paquetes procedentes del cliente.
5