• Author / Uploaded
• Carla

Citation preview

REDES Y TELEPROCESO 2 Laboratorio 07: Wireshark - TCP 3.1)

¿Cuál es la dirección IP y el número de puerto TCP usados por la computadora cliente (fuente) que está transfiriendo el archivo a gaia.cs.umass.edu?

3.2)

¿Cuál es la dirección IP de gaia.cs.umass.edu? ¿Sobre qué número de puerto se está enviando y recibiendo segmentos TCP para esta conexión?

Responder las siguientes preguntas para los segmentos TCP: 4.6)

Considerar el segmento TCP conteniendo el HTTP POST como el primer segmento en la conexión TCP ya establecida. ¿Cuáles son los números de secuencia absolutos de los primeros 6 segmentos en la conexión TCP (incluyendo el segmento conteniendo el HTTP POST)? ¿A qué hora fue cada segmento enviado? ¿Cuándo fue el ACK para cada segmento recibido? Dada la diferencia entre cuando cada segmento TCP fue enviado y cuando su acuse de recibo fue recibido ¿cuál es el valor de RTT para cada uno de los 6 segmentos? ¿Cuál es el valor de RTTestimado después del recibo de cada ACK?

Asumir que el valor de RTTestimado es igual al RTTmedido para el primer segmento en la conexión ya establecida, y luego se calcula usando la ecuación de RTTestimado dada en la Lección Nº 05 para todos los segmentos subsecuentes.

Primero identificamos el segmento TCP conteniendo el HTTP POST: En nuestro caso es el paquete número 24.

Segundo identificamos los 6 primeros segmentos de la conexión TCP: (Cliente  Servidor) En nuestro caso serán los paquetes números 24, 25, 26, 27, 29 y 30. Tercero identificamos los 6 primeros segmentos de la conexión TCP: (Servidor  Cliente) En nuestro caso serán los paquetes números 28, 31, 32, 37, 40 y 43.

Segmento hora envío

No. Seg. (SC)

# Ack (SC)

Ack hora recepción

1460

15:30:35.592616000

1(28)

2123316097

15:30:35.605558000

2123316097

1460

15:30:35.592629000

2(31)

2123317557

2123317557

1460

15:30:35.592634000

3(32)

2123319017

4 (27)

2123319017

1460

15:30:35.592639000

4(37)

5 (29)

2123320477

1460

15:30:35.605600000

5(40)

6 (30)

2123321937

1460

15:30:35.605606000

6(43)

No. Seg. (CS)

# Sec. (CS)

Tamaño datos

1 (24)

2123314637

2 (25) 3 (26)

RTT

RTT est

0.012942000

0.012942000

15:30:35.611443000

0.018814000

0.013676000

15:30:35.611444000

0.018810000

0.014317750

2123320477

15:30:35.611605000

0.018966000

0.014898780

2123321937

15:30:35.690669000

0.085069000

0.023670060

2123323397

15:30:35.694785000

0.089179000

0.031858680

Para hallar el RTT estimado aplicamos la siguiente formula:

EstimatedRTT EstimatedRTT EstimatedRTT EstimatedRTT EstimatedRTT EstimatedRTT

Segmento 1 = 0.012942000 Segmento 2 = 0.875 * 0.012942000 + 0.125 * 0.018814000= 0.013676000 Segmento 3 = 0.875 * 0.013676000 + 0.125 * 0.018810000 = 0.014317750 Segmento 4 = 0.875 * 0.014317750 + 0.125 * 0.018966000 = 0.014898780 Segmento 5 = 0.875 * 0.014898780 + 0.125 * 0.085069000 = 0.023670060 Segmento 6 = 0.875 * 0.023670060 + 0.125 * 0.089179000 = 0.031858680

Nota: Wireshark tiene una característica simpática que permite plotear el RTT para cada uno de los segmentos TCP enviados. Seleccionar un segmento TCP en la ventana de "Lista de paquetes capturados" que se está enviando desde el cliente al servidor gaia.cs.umass.edu. Luego seleccionar: Statistics->TCP Stream Graph->Round Trip Time Graph.

4.7)

¿Cuál es la longitud de los datos en cada uno de los 6 primeros segmentos TCP, después que la conexión ha sido establecida? Segmento 1 (24) 2 (25) 3 (26) 4 (27) 5 (29) 6 (30)

Longitud 1460 bytes 1460 bytes 1460 bytes 1460 bytes 1460 bytes 1460 bytes

4.10) ¿Cuántos datos el receptor típicamente "acusa recibo" a través de los 6 primeros ACKs? ¿Se puede identificar casos donde el receptor está ACKeando cada segmento recibido (ver Tabla 3.2 en la Lección Nº 05)? ¿Se puede identificar un caso por lo menos donde el receptor ACKea segmentos recibidos según la Tabla 3.2 (ver Lección Nº 05)? Cantidad de datos ACKeados

Nro. Segmento

# Ack recibido en el Ex desde el servidor

1(28)

1461

1460

2(31)

2921

1460

3(32)

4381

1460

4(37)

5841

1460

5(40)

7301

1460

6(43)

8761

1460

 Entonces la cantidad de datos que el receptor (servidor) típicamente ACKea es igual a 1460 bytes.  Sí, todos los primeros segmentos son ACKeados uno por uno.  Si, el servidor ACKea por encima del valor típico (1460). 4.11) ¿Cuál es el throughput (los bytes transferidos por unidad de tiempo) para la conexión TCP? Explicar cómo se calculó este valor. Throughput promedio de una conexión = (0.75*W)/RTT Donde: W = valor del tamaño de la ventana (bytes) RTT = tiempo de ida y vuelta actual (segundos)

W (Tamaño de la ventana del primer segmento) es : 251 RTT del primer segmento es : 0.012942000 Throughput promedio de la conexión = (0.75*251)/ 0.012942000 bytes/seg = 14545.665275 bytes/seg = 14.2041015625 Kb/seg Responder las siguientes preguntas para los segmentos TCP de la traza capturada: 5.12) Usar la herramienta de ploteo Time-Sequence-Graph (Stevens) para visualizar el número de secuencia vs. el plot de tiempo de los segmentos siendo enviados desde el cliente al servidor gaia.cs.umass.edu. ¿Puede identificar donde la fase de arranque lento (slow start) de TCP comienza y termina, y donde la evitación de congestión toma el relevo? Comentar sobre los modos en los cuales los datos medidos difieren del comportamiento idealizado de TCP que se estudió en el texto. (Dibujo)

 El slow start : [0.0, 0.2]  La evitación de congestión [0.2, 0.35] U [0.5, 0.8] Sabemos que el mecanismo de Inicio Lento permite incrementar gradualmente la cantidad de datos en tránsito, este mecanismo utiliza una nueva ventana llamada ventana de congestión (cwnd) de manera que en cada momento, el emisor puede enviar el mínimo número de segmentos de entre la cantidad permitida por la ventana de control de flujo y la permitida por la ventana de congestión. Por esta razón los gráficos estudiados en clase difieren mucho del grafico hallado en este laboratorio. También por que los datos enviados y recibidos tomados en este laboratorio fueron recogidos en promedio de 15 (seg) por lo que hay pocos segmentos perdidos. De igual manera vemos que la razón principal es que el emisor TCP no está enviando datos suficientes agresivamente para impulsar al estado de congestión