2 tcp v2 - it.uc3m.es€¦ · Pag. 4 TCP AVANZADO-TIMEOUTS Y RETRANSMISIONES Definición • TCP es...

Celeste Campo

[email protected]

UNIVERSIDAD CARLOS III DE MADRIDDEPARTAMENTO DE INGENIERÍA TELEMÁTICA

TCP AVANZADO

Pag. 1

TCP AVANZADO-TIMEOUTS Y RETRANSMISIONES

ÍNDICE

1. Introducción.

2. Establecimiento y finalización de la conexión.

3. Flujo de datos interactivo.

4. Flujo de datos masivo.

5. Timeouts y retransmisiones.

6. Temporizador persistente.

7. Temporizador “keepalive”.

8. Futuro y prestaciones.

Pag. 2


BIBLIOGRAFÍA• Básica:

– W. R. Stevens: "TCP/IP Illustrated Vol.1 The protocols". PrenticeHall, 1994. (Chapter 17 – Chapter 24).

– D.E. Comer: "Internetworking with TCP/IP vol I.", 4 Ed., Prentice Hall, 2000.

– Andrew S. Tanenbaum: "Computer Networks", 3 Ed., Prentice HallInternational, 1996.

• Complementaria:– A. Rodríguez, J. Gatrell, J. Karas, R. Peschke: "TCP/IP Tutorial and

Technical Overview", 7ª Ed, IBM Redbooks, 2001.

– W. Stallings. “High-speed networks: TCP/IP and ATM design principles”.Prentice Hall, 1998.

• RFCs:– RFC 793: Transmission Control Protocol.1981.

Pag. 3


ÍNDICE

1. Introducción:A. Definición.

B. Formato segmento TCP.

C. Campos cabecera segmento TCP.

Pag. 4


Definición

• TCP es un protocolo orientado a conexión que proporciona un servicio de transporte fiable de un flujo de bytes entre aplicaciones:– “Orientado a conexión” ⇒ previo al intercambio de datos los

extremos (aplicaciones) tienen que establecer una conexión.

– “Fiable” ⇒ garantiza la entrega ordenada del flujo de bytes entre los extremos de la conexión.

– “Flujo de bytes” ⇒ por la conexión se transmite un flujo de bytes.

Pag. 5


Definición: fiabilidad

• TCP divide los datos pasados por las aplicaciones en bloques denominados segmentos TCP.

• TCP cuando envía un segmento establece un temporizador esperando asentimiento.

• TCP cuando recibe un segmento envía un asentimiento.

• TCP emplea un código de redundancia (“checksum”) de su cabecera y datos.

• TCP reordena los datos si es necesario.

• TCP descarta paquetes duplicados.

• TCP proporciona control de flujo.

Pag. 6


Formato segmento TCP

• Los segmentos TCP se encapsulan en datagramas IP.

CABECERAIP

CABECERATCP

DATOS APLICACIÓN

Segmento TCP

Datagrama IP

CABECERAIP

CABECERATCP

DATOS APLICACIÓNCABECERAETHERNET

ETHERNETTRAILER

Pag. 7


Formato segmento TCP

puerto origen (16 bits)

número de secuencia (32 bits)

número de asentimiento (ACK) (32 bits)

longitudcabecera(4 bits)

código redundancia (16 bits) puntero datos urgentes

campos opcionales + relleno (si hay)

reservado(6 bits)

datos (si hay)

20 octetos

0 31

puerto destino (16 bits)

tamaño ventana(16 bits)U

RG

AC

K

PS

H

RS

T

SY

N

FIN

1516

Pag. 8


Campos cabecera TCP• Puertos origen y destino: indican la conexión lógica entre las

dos aplicaciones que se están comunicando (FTP, TELNET, SMTP, etc.).– Identificador único de conexión:

• Par de “socket”– socket (definido en la RFC 793) = dirección IP + puerto

• Dirección IP origen, Puerto origen, Dirección IP destino, Puerto destino

• Número de secuencia: posición del primer octeto en el campo de datos en relación con la secuencia original.– Campo de 32 bits ⇒ rango entre 0 y 2³²-1.– Si el flag SYN está activo, este campo contiene el número de

secuencia inicial (n) y el primer octeto de datos es el n+1. El flag SYN consume un número de secuencia.

– Servicio “full-duplex” ⇒ cada extremo de la conexión mantiene su número de secuencia de flujo de datos en esa dirección.

Pag. 9


Campos cabecera TCP

• Número de asentimiento: número de secuencia siguiente al octeto confirmado, indica la posición que ocuparía el próximo octeto que se espera recibir.– Sólo es válido si está activo el flag ACK.

• Longitud cabecera: número de palabras de 32 bits que componen la cabecera. – Necesario porque la cabecera es de longitud variable

(opciones).

– Campo de 4 bits ⇒ cabecera TCP limitada a 60 octetos.

– Sin opciones la longitud de la cabecera son 20 octetos.

• Reservado: reservados para uso futuro, deben estar a cero.

Pag. 10


Campos cabecera TCP

• Flags:– URG: indica que el campo Puntero Datos Urgentes tiene

validez.

– ACK: indica que el campo Número de Asentimiento tiene validez.

– PSH: indica que el segmento requiere envío y entrega inmediata.

– RST: indica aborto de la conexión.

– SYN: sincroniza números de secuencia en el establecimiento de conexión.

• Confirmación con ACK

– FIN: indica liberación de conexión. • Confirmación con ACK.

Pag. 11


Campos cabecera TCP• Tamaño ventana: indica el número de octetos, adicionales al

apuntado por ACK, que está dispuesto aceptar. – Mecanismo de control de flujo de TCP.– Anunciado por cada extremo de la conexión.– Campo de 16 bits ⇒ tamaño limitado a 65535 octetos.

• Código de redundancia: campo obligatorio que debe ser calculado por el emisor y verificado por el receptor.– Incluye todo el segmento TCP, tanto cabecera como datos.

• Puntero datos urgentes: indica el offset (positivo) que debe ser añadido al número de secuencia del segmento para obtener el número de secuencia del último octeto de datos urgentes.– Sólo es válido si está activo el flag URG.

Pag. 12


Campos cabecera TCP

• Campos opcionales: para incluir opciones.– Tamaño máximo de datos en un segmento (MSS – Maximun

Segment Size):• Utilizada en el establecimiento de la conexión.

• Indica la longitud máxima de datos en un segmento que puede recibir un extremo.

– Escala del tamaño de la ventana:• Expandir el tamaño de la ventana TCP.

• Datos:– Opcional.

Pag. 13


ÍNDICE

2. Establecimiento y finalización de la conexión:A. Establecimiento conexión (“three-way handshake”).

B. Finalización conexión.

C. TCP Half-close.

D. Tamaño máximo del segmento (MSS - Maximun SegmentSize).

E. Estados de TCP.

F. Apertura simultánea.

G. Cierre simultáneo.

Pag. 14


Establecimiento conexión

• Uso de “three way handshake”.

• Se emplea el bit SYN en la solicitud de conexión y SYN + ACK en la respuesta. La respuesta es a su vez confirmada con ACK.

• Se fija el número de secuencia inicial en ambas direcciones.

TCP 1

SYN (seq=x)

ACK (seq=x+1,ack=y+1)

RED TCP 2

SYN (seq=y,ack=x+1)

DATA (seq=x+1,ack=y+1)

1

2

3

Pag. 15


Finalización conexión• Liberación ordenada e independiente por cada uno de los sentidos

de transmisión.

• El extremo que desea cesar de transmitir envía segmento con FIN, que debe ser confirmado por el corresponsal con FIN, ACK.

TCP 1

FIN (seq=x)

RED TCP 2

ACK (seq=y,ack=x+1)

ACK (seq=x+1,ack=y+1)

1

2(informa a la aplicación)

FIN, ACK (seq=y, ack=x+1)3

4

Pag. 16


Ejemplosrv4 % telnet bsdi discard

Trying 192.82.148.3...

Connected to it011.lab.it.uc3m.es.

Escape character is '^]'.

^]

telnet> quit

Connection closed

Pag. 17


Ejemplo: Notación tcpdump

Fuente > destino nº secuencia inicial nº secuencia final (nº de octetos de datos)

Ninguno de los cuatro flags activos-.

El segmento requiere envío y entrega inmediataPSHP

Aborto conexiónRSTR

Emisor ha acabado de enviar datosFINF

Sincroniza números de secuenciaSYNS

DescripciónAbreviatura (3 carac.)Flag

Pag. 18


Ejemplo: Salida tcpdump

. ack 1823083523 win 4096svr4.1037 > bsdi.discard:4.180662 (0.0225) 7

F 1823083522:1823083522(0)

ack 1415531523 win 4096

bsdi.discard > svr4.1037:4.158144 (0.0014) 6

. ack 1415531523 win 4096 bsdi.discard > svr4.1037:4.156747 (0.0013) 5

F 1415531522:1415531522(0)

ack 1823083522 win 4096svr4.1037 > bsdi.discard:4.155441 (4.1482) 4

. ack 1823083522 win 4096svr4.1037 > bsdi.discard:0.007224 (0.0048) 3

S 1823083521:1823083521(0)ack 1415531522 win 4096 <mss 1024>

bsdi.discard > svr4.1037:0.002402 (0.0024) 2

S 1415531521:1415531521(0) win 4096 <mss 1024>

svr4.1037 > bsdi.discard:0.0 1

ES

TA

BL

EC

IMIE

NT

OF

INA

LIZ

AC

IÓN

Pag. 19


Ejemplo: Línea temporalE

ST

AB

LE

CIM

IEN

TO

(th

ree-

way

han

dsh

ake)

3 se

gm

ento

s

FIN

AL

IZA

CIÓ

N4

seg

men

tos

Active open Pasive open

Active close

Pasive close

Pag. 20


TCP Half-Close• TCP, al establecer una conexión “full-duplex”, cada extremo puede

finalizar la transmisión de datos de forma independiente.

• Pocas aplicaciones hacen uso de esta característica.

TCP 1

aplicación shutdown

RED TCP 2

entrega EOF a la aplicación

aplicación read

FIN

ACK del FIN

DATOSaplicación write

ACK de DATOS

FIN

ACK del FIN

aplicación close

entrega EOF a la aplicación

Pag. 21


Ejemplosun % rsh bsdi sort < datafile

rsh sort

host sun host bdi

conexión TCPdatafile

terminal

entradaestándar

salidaestándar

• Programa sort en bdi no puede generar ninguna salida hasta que no haya recibido el fichero datafile.

• Cuando sun finaliza de transmistir el contenido del fichero realiza un “half-close” de la conexión TCP.

• El host bdi envía la salida de sort a sun y cuando finaliza cierra la conexión TCP.

Pag. 22


MSS: Maximum Segment Size

• MSS: longitud máxima de datos que se enviarán en un segmento al otro extremo TCP.

• El datagrama IP resultante normalmente será 40 octetos mayor que este valor.

• En el establecimiento de la conexión, cada extremo puede anunciar el MSS que espera recibir (si no se establece, por defecto es 536 octetos).– Se incluye como una opción en segmentos TCP SYN.

– MTU¹ – tamaño cabecera IP – tamaño cabecera TCP (ej. Ethernet se anunciaría 1460 octetos)

¹ MTU = Maximum Transmission Unit

Pag. 23


Estados de TCP

Estado Descripcion

CLOSED No existe conexión activa ni pendiente

LISTEN El servidor está esperando por una conexión

SYN_RCVD Una petición de conexión ha llegado, espera ACK

SYN_SENT El cliente ha comenzado a abrir una conexión

ESTABLISHED Estado de transferencia de datos

FIN_WAIT_1 El cliente ha dicho que ha acabado

FIN_WAIT_2 El servidor ha aceptado liberación conexión

TIME_WAIT Espera por paquetes pendientes (“2MSL wait state”)

CLOSING Ambos extremos han intentado cerrar la conexión simultáneamente.

CLOSE_WAIT Servidor ha iniciado liberación conexión

LAST_ACK Espera por ACK del FIN

(mismo nombre de estados que el programa netstat)

Pag. 24


Estados TCP en un establecimiento y finalización “normal” de la conexión

SYN (seq = x)

SYN (seq = y, ack = x + 1 )

(ack = y + 1 )

SYN_SENT(active open)

SYN_RCVD

ESTABLISHED

FIN_WAIT_1(active close)

LISTEN(passive open)

FIN (seq = m)CLOSE_WAIT(passive close)(ack = m+ 1 )

FIN (seq = n )

(ack = n+1)

LAST_ACK

FIN_WAIT_2

TIME_WAIT

CLOSED

ESTABLISHED

Pag. 25


Nomenclatura

appl:

recv:

send:

transiciones habituales para el cliente

indica transición entre estados debida a operaciones de la aplicación

transiciones habituales para el servidor

indica lo que se envía en esta transición

indica transición entre estados debida a la recepción de un segmento

Pag. 26


Diagrama de transición entre estados

CLOSED

LISTEN

SYN_SENTSYN_RCVD

ESTABLISHED

starting point

pasive open

simultaneous open

recv: SYN

send: SYN, ACK

appl: active open

send: SYNappl: send data

send: SYNappl: closeor timeout

recv: SYN; send: SYN,ACK

recv: RST

active openrecv: ACK

send: <nothing> recv

: SYN, A

CK

send: A

CK

data transfer state

appl: pasive opensend: <nothing>

appl: closesend: FIN

recv:FINsend:FIN

Pag. 27


Diagrama de transición entre estados

ESTABLISHEDdata transfer state

CLOSE_WAIT

LAST_ACK

recv:FINsend:ACK

appl: closesend: FIN

recv: ACKsend:<nothing>

passive close

FIN_WAIT_1

FIN_WAIT_2

CLOSING

TIME_WAIT

simultaneous closerecv:FIN

send:ACK

recv:FINsend:ACK

recv: ACKsend: <nothing>

recv: ACKsend: <nothing>

recv: FIN, ACK

send: ACK

2MSL timeout

appl

:clo

sese

nd:

FIN

appl: close

send: FIN

active close

Pag. 28


Estado “2MSL Wait State”

• TCP después de realizar un “active close” y enviar el ACK del FIN debe esperar un tiempo TIME_WAIT.

• ¿Por qué?:– Permite a TCP reenviar el ACK del FIN si éste se pierde (el otro

extremo, en este caso, reenviará el FIN cuando venza su temporizador)

• Hasta que no finalice este temporizador no se liberan el par de sockets de la conexión.

• Cada implementación selecciona un valor de MSL (MaximunSegment Lifetime): típicamente 2 minutos o 1 minuto o 30 segundos.

2MSL Wait State = TIME_WAIT

Pag. 29


“Resetting” de conexiones• Se indica activando el flag RST.

• Normalmente generados automáticamente por el software TCP.

• ¿Cuándo se activa el flag RST?– Llega un petición de conexión y no existe un proceso servidor

escuchando en el puerto destino.– Llega un segmento TCP que no corresponde con ninguna

conexión activa.– Abortar una conexión a nivel aplicación (en vez de enviar un

FIN se envía un RST):• El receptor tira todos los datos pendientes de transmisión.• No asiente el segmento RST.• Se finaliza la conexión.

Pag. 30


Apertura simultánea• Dos aplicaciones realizan un “active open” simultáneamente.

• TCP está especialmente diseñado para que en este caso sólo se establezca una conexión NO dos conexiones (otros protocolos crean dos conexiones).

• La apertura de la conexión requiere el intercambio de 4 segmentos, NO 3.

TCP 1 RED TCP 2SYN JSYN_SENT(active open) SYN K

SYN K, ACK J+1SYN J, ACK K+1

ESTABLISHED

ESTABLISHED

SYN_RCVDSYN_RCVD

SYN_SENT (active open)

Pag. 31


Finalización simultánea• Dos aplicaciones realizan un “active close” simultáneamente.

• En la finalización de la conexión se siguen intercambiando 4 segmentos.

TCP 1 RED TCP 2

FIN JFIN_WAIT_1(active close)FIN K

ACK J+1ACK K+1

TIME_WAIT

CLOSINGCLOSING

FIN_WAIT_1 (active close)

TIME_WAIT

Pag. 32


ÍNDICE

3. Flujo de datos interactivo:A. Entrada interactiva.

B. Asentimientos retardados.

C. Algoritmo de Nagle.

Pag. 33


Flujo de datos interactivos

• Estudio de estadísticas sobre el tráfico TCP:– Medido en número de paquetes:

• ~ 50% son datos interactivos (ej. Telnet o Rlogin).

• ~ 50% son flujo de datos masivo (ej. FTP, correo electrónico).

– Medido en bytes:• ~ 10% son datos interactivos.

• ~ 90% son flujo de datos masivo.

• TCP tiene diferentes mecanismos para gestionar estos dos tipos de transferencia de datos.

Pag. 34


Entrada interactiva

• Aplicaciones de terminal remoto (ej. Telnet) envían cada carácter escrito por el usuario al servidor. El servidor interpreta el carácter y lo envía de nuevo al cliente.

• Podemos ver que por cada carácter se transmiten 3 segmentos TCP:– Cliente ⇒ Servidor: incluyendo el carácter.– Servidor ⇒ Cliente: haciendo eco del carácter y asintiendo el

segmento anterior.– Cliente ⇒ Servidor: asintiendo el segmento anterior.

1. Envía carácter

2. Interpretacarácter

3. Envía eco del carácter y/o salida

Host concliente Telnet

Host conservidor Telnet

Pag. 35


Entrada interactiva

• ¿Por qué tres segmentos y no cuatro?:– Se combina el ACK del

carácter enviado por el cliente, con el carácter de eco enviado por el servidor.

– Este característica se conoce como “asentimientos retardados”

CARÁCTER

ACK DEL CARÁCTER

ECO DEL CARÁCTER

ACK DEL CARÁCTER ECO

CARÁCTER

ACK Y ECO DEL CARÁCTER

ACK DEL CARÁCTER ECO

SERVIDORCLIENTE

Pag. 36


Asentimientos retardados

• Normalmente los ACKs no se envían inmediatamente después de recibir datos.

• Un ACK se puede retardar:– Hasta que existan datos para enviar hacía el otro extremo:

• El ACK se incluye en el segmento de datos (ACK piggyback con los datos).

– Hasta un máximo de 200 ms. (valor habitual en las implementaciones):

• RFC indica que debería implementarse un retardo en el envío de los ACKs y que este retardo debe ser menor de 500 ms.

Pag. 37


Asentimientos retardados: Ejemplo

bsdi:~> rlogin srv4…srv4:~> dateSat Feb 6 07:52:17 MST 1993srv4:~>

Pag. 38


Asentimientos retardados: Ejemplo1 0.0 bsdi.1023 > srv4.login: P 0:1(1) ack 1 win 4096

2 0.016497 (0.0165) srv4.login > bsdi.1023: P 1:2(1) ack 1 win 4096

3 0.139955 (0.1235) bsdi.1023 > srv4.login: . ack 2 win 4096

4 0.458037 (0.3181) bsdi.1023 > srv4.login: P 1:2(1) ack 2 win 4096












d

a

t

e

\n(CR + LF)

Pag. 39


Asentimientos retardados: Ejemplo





date

prompt

Sat Feb 6 07:52:17 MST 1993 + “CR” + “LF”

srv4:~>

Pag. 40


Algoritmo de Nagle

• El algoritmo de Nagle (RFC 896) plantea una solución al problema siguiente:– En algunos casos, se envían pocos octetos de datos en cada

segmento (tinygrams) y por lo tanto, se aumenta el sobrecarga debido a las cabeceras.

– Sin efecto en redes LAN, pero puede aumentar la congestión en redes WAN.

– Ejemplo anterior:• Cada octeto se envía en un datagrama IP de 41 octetos:

– 20 octetos de la cabecera IP.

– 20 octetos de la cabecera TCP.

– 1 octeto de datos.

Pag. 41


Algoritmo de Nagle

• El algoritmo de Nagle dice:– Una conexión TCP sólo puede tener un segmento TCP

pendiente de asentimiento.

– Mientras se espera el asentimiento se van acumulando los datos pendientes, que se enviarán juntos en el siguiente segmento.

• El algoritmo de Nagle tiene la propiedad:– Cuanto más rápido llegan los asentimientos, más rápido se

envían los segmentos de datos (“self-clocking”).

– Así en una WAN los asentimientos llegarán más lentos y por lo tanto se reducirá el número de “tinygrams” enviados (se envían menos segmentos de mayor tamaño).

Pag. 42


Deshabilitar el algoritmo de Nagle

• Es posible y deseable en algunos casos deshabilitar el algoritmo de Nagle:– Servidor de ventanas:

• Los movimientos de ratón deben enviarse sin ningún retraso.

– Envío de teclas de función en un login:• Teclas de función están compuestas de varios caracteres.

• Es necesario que esos caracteres vayan juntos para que el usuario no detecte retardos en la interacción con el servidor remoto.

• Las implementaciones permiten deshabilitar este algoritmo.

Pag. 43


Algoritmo de Nagle: Ejemplo

PSH 5:6(1) ACK 47, WIN 4096

PSH 47:48(1) ACK 6, WIN 8192

PSH 6:7(1) ACK 48, WIN 4096

PSH 48:49(1) ACK 7, WIN 8192

PSH 7:9(2) ACK 49, WIN 4095

PSH 49:51(2) ACK 9, WIN 8192

PSH 9:10(1) ACK 51, WIN 4094

PSH 51:52(1) ACK 10, WIN 8192

PSH 10:12(2) ACK 52, WIN 4095

1

2

3

4

5

6

7

8

9

slip.1023 vangogh.login

PSH 52:54(2) ACK 10, WIN 819210

0.0

0.197694 (0.1977)

0.232457 (0.0348)

0.437593 (0.2051)

0.464257 (0.0267)

0.677658 (0.2134)

0.707709 (0.0301)

0.917762 (0.2101)

0.945862 (0.0281)

1.157640 (0.2118)

PSH 12:14(2) ACK 54, WIN 40941.187501 (0.0299)

Pag. 44


ÍNDICE

3. Flujo de datos masivo:A. Flujo normal de datos.

B. Mecanismo de control de flujo:1. Ventana deslizante en TCP.

C. Mecanismo de control de congestión:1. “Slow start”.

D. Flag PUSH.

E. Modo urgente (flag URG).

Pag. 45


Flujo normal de datos• Idea: permitir al emisor enviar múltiples segmentos, antes de parar y

esperar por el asentimiento:– Transferencia más rápida de los datos.

• Los mecanismos de control de flujo previenen que el emisor sature al receptor con datos:– TCP emplea como mecanismo de control de flujo una ventana

deslizante:• Permite que el emisor transmita varios paquetes antes de parar y esperar

por un asentimiento pero sin saturar al receptor.

• Los mecanismos de control de congestión previenen que el emisor sature la red con datos:– TCP emplea como mecanismos básico de control de congestión “slow-

start” (comienzo lento):• Permite que el emisor envíe datos a la misma velocidad con la que se

envían asentimientos desde el otro extremo.– Más mecanismos añadidos basados en temporizadores.

Pag. 46


Ventana deslizante en TCP

• Permite el control de flujo:– El envío de ACK es independiente del establecimiento de

tamaño de la ventana del receptor.

– Los ACKs no incrementan automáticamente el tamaño de la ventana.

– Los ACK son acumulativos.

1 2 3 4 5 6 7 8 9 10 11 …

ventana ofrecida

(anunciada por el receptor)

ventana utilizable

enviado, no asentido

puede enviarse ASAP

no puede enviarse

hasta ampliar la ventanaenviado y

asentido

Pag. 47


Ventana se “cierra”

1 2 3 4 5 6 7 8 9 10 11 …

1 2 3 4 5 6 7 8 9 10 11 …

1 2 3 4 5 6 7 8 9 10 11 …

Se transmite un único octeto con (seq=7)

Se recibe un asentimiento (ack=6 y win=4)

Pag. 48


Ventana se “abre”

1 2 3 4 5 6 7 8 9 10 11 …

1 2 3 4 5 6 7 8 9 10 11 …


• El receptor abre la ventana cuando el buffer TCP se vacía (significa que los datos se han entregado a la aplicación).

Pag. 49


Ventana se “encoge”

1 2 3 4 5 6 7 8 9 10 11 …

1 2 3 4 5 6 7 8 9 10 11 …


• En la RFC se recomienda “fuertemente” no encoger la ventana.

Pag. 50


Gestión de la ventana deslizante en TCP

• El receptor envía dos parámetros al emisor:

• La interpretación es:– “estoy preparado para recibir nuevos datos, desde seq=ack,

ack+1,…,ack+win-1”.

• El receptor puede asentir datos sin abrir la ventana.

• El receptor puede cambiar el tamaño de la ventana sin asentir datos.

ACK WIN

32 bits 16 bits

Pag. 51


Ventana deslizante: Ejemplo

• Transferencia de 8192 octetos desde la máquina srv4 a la máquina bsdi:

bsdi% sock –i –s 7777

svr4% sock –i –n8 bsdi 7777

• El cliente (svr4) realiza ocho escrituras de 1024 bytes, el servidor (bsdi) lee los datos recibidos y los descarta.

Pag. 52


Ventana deslizante: Ejemplo

PSH 1:1025(1024) ACK 1, WIN 4096

ACK 2049, WIN 4096

1

34

5

6

7

11

10

0.017868

0.022699 (0.0048)

0.027650 (0.0050)

0.027799 (0.0001)

0.031881 (0.0041)

0.039276 (0.0045)

0.044618 (0.0053)

0.055441 (0.0002)

0.066206 (0.0045)

svr4.1056 bsdi.7777

PSH 1025:2049(1024) ACK 1, WIN 40962PSH 2049:3073(1024) ACK 1, WIN 4096

ACK 3073, WIN 3072 5

PSH 3073:4097(1024) ACK 1, WIN 4096

ACK 4097, WIN 4096

PSH 4097:5121(1024) ACK 1, WIN 4096PSH 5121: 6145(1024) ACK 1, WIN 4096PSH 6145:7169(1024) ACK 1, WIN 4096

ACK 6145, WIN 4096

8

9

PSH 7169:8193(1024) ACK 1, WIN 4096

ACK 8193, WIN 4096 12

0.034789 (0.0029)

0.050326 (0.0057)

0.055286 (0.0050)

0.061742 (0.0063)

Pag. 53


… si “emisor rápido, receptor lento”

PSH 1:1025(1024) ACK 1, WIN 4096

ACK 4097, WIN 0

1

3

5

11

0.006806

0.008838 (0.0020)

0.010490 (0.0017)

0.012057 (0.0016)

0.038562 (0.0265)

0.071915 (0.0089)

svr4.1056 bsdi.7777

PSH 1025:2049(1024) ACK 1, WIN 40962PSH 2049:3073(1024) ACK 1, WIN 4096

4097:5121(1024) ACK 1, WIN 4096

ACK 4097, WIN 4096

5121:6145(1024) ACK 1, WIN 4096

ACK 8194, WIN 0

0.055994 (0.0174)

0.074313 (0.0024)

6145:7169(1024) ACK 1, WIN 4096

12

PSH 3073:4097(1024) ACK 1, WIN 40964

6

FIN, PSH 7169:8193(1024) ACK 1, WIN 4096

ACK 8194, WIN 4096

7

9

8

10

0.057815 (0.0018)

0.059777 (0.0020)

0.061439 (0.0017)

0.062992 (0.0016)

Pag. 54


“Slow Start”

• Algoritmo que permite el control de la congestión, es decir, evita que el emisor sature la red:– En redes LAN la selección de parámetros de conexión es

sencilla.

– En redes WAN pueden ocurrir dificultades cuando routersintermedios tienen paquetes encolados.

• El algoritmo de “slow start” consiste en:– La velocidad de envío de paquetes depende de la velocidad de

los asentimientos recibidos.

– Se introduce una ventana en el emisor, que se denomina, ventana de congestión (cwnd).

Pag. 55


Algoritmo de “Slow Start”• Cuando se establece la conexión se establece el valor inicial

cwnd=1 (unidades de segmentos).

• Cada vez que se recibe un asentimiento (ACK), la ventana de congestión se incrementa en un segmento cwnd=cwnd+1.– Normalmente, se recibe un ACK por cada segmento:

• pero se puede recibir un ACK que asiente varios segmentos, • o recibir un ACK que asiente menos de un segmento

– En cualquier caso, siempre se incrementa en 1 segmento.

• El emisor podrá enviar tantos datos como el mínimo entre la ventana de congestión y la ventana anunciada.

• El crecimiento de la ventana de congestión normalmente se incrementa exponencialmente:– No es así si se envían ACK acumulados.

Pag. 56


Algoritmo de “Slow Start”

Segmento 1

ACK del segmento 1

cwnd = 1

cwnd = 2 Segmento 2Segmento 3

ACK del segmento 2

cwnd = 4 Segmento 4Segmento 5Segmento 6

ACK del segmento 4

cwnd = 8

ACK del segmento 3

ACK del segmento 5

ACK para segmento 6

Segmento 7

ACK para segmento 7

Pag. 57


“Slow Start”: Ejemplo

1:513(512) ACK 1, WIN 4096

ACK 1025, WIN 8192

1

3

11

0.0

0.716330 (0.7163)

0.716967 (0.0006)

0.717640 (0.0007)

1.466086 (0.7484)

1.467425 (0.0006)

1.946065 (0.4786)

2.576084 (0.6287)

sun.1118 vangogh.discard

2

513:1025(512) ACK 1, WIN 4096

5

2561:3073(512) ACK 1, WIN 40963073:3585(512) ACK 1, WIN 4096

9

10

1.466778 (0.0007)

1.946709 (0.0006)

1.947350 (0.0006)

2.576294 (0.0002)

ACK 513, WIN 8192

1025:1537(512) ACK 1, WIN 40964

ACK 1537, WIN 8192

61537:2049(512) ACK 1, WIN 4096

8

2049:2561(512) ACK 1, WIN 40967

cwnd = 2

cwnd = 1

cwnd = 3

cwnd = 4

ACK 2049, WIN 8192

ACK 2561, WIN 8192 12cwnd = 5

cwnd = 6

Pag. 58


Flag “PUSH”• Notificación del emisor al receptor para que el receptor pase

inmediatamente los datos que ha recibido a la aplicación receptora:– Todos los contenidos en el segmento con PUSH activo.

– Datos previos almacenados por TCP.

• Inicialmente las aplicaciones podían indicar al stack TCP que activase el flag de PUSH para que los datos se enviaran de manera inmediata:– Pero la mayoría de implementaciones actuales no soportan esta

característica a nivel API.

• Implementaciones actuales (Berkeley y derivadas):– Activan PUSH en el segmento que vacía el buffer de transmisión.

– Siempre entregan de forma inmediata los datos en recepción, por lo tanto ignoran el flag PUSH.

Pag. 59


Datos urgentes (flag “URG”)• Notificación para indicar que existen datos urgentes en el flujo de

octetos:– Activar el flag de URG.– Valor del puntero a datos urgentes:

• Indica el offset (positivo) que debe ser añadido al número de secuencia del segmento para obtener el número de secuencia del último octeto de datos urgentes (RFC).

• En muchas implementaciones este offset apunta al siguiente octeto después de los datos urgentes.

• El extremo TCP receptor debe indicar la llegada de datos urgentes a la aplicación receptora.

• ¿Por qué se utiliza?:– Permite al extremo emisor enviar un segmento aunque el tamaño de la

ventana ofrecida sea cero.

• ¿Cuándo se utiliza?:– Tecla de interrupción para una conexión remota (rlogin, telnet).– Interrumpir la transferencia de un fichero en FTP.

Pag. 60


Datos urgentes: Ejemplo • Arrancamos un programa sock en la máquina bsdi y está en pausa

durante 10 seg. después del establecimiento de la conexión:bsdi % sock –i –s –P10 5555

• Arrancamos un cliente en la máquina sun, indicándole que va a utilizar un buffer de transmisión de 8192 octetos y que realice seis escrituras de 1024 octetos, e indicamos que envíe un octeto de datos urgentes justo antes de realizar la quinta escritura (-U5 ):sun % sock –v –i –n6 –S8192 –U5 bsdi 5555

connected on 140.252.13.33.1305 a 140.252.13.35.5555

SO_SNDBUF = 8192

TCP_MAXSEG = 1024

wrote 1024 bytes

wrote 1024 bytes

wrote 1024 bytes

wrote 1024 bytes

wrote 1 bytes of urgent data

wrote 1024 bytes

wrote 1024 bytes

Pag. 61


Datos urgentes: Ejemplo 1 0.0 sun.1305 > bsdi.5555: P 1:1025(1024) ack 1 win 4096

2 0.073743 (0.0737) sun.1305 > bsdi.5555: P 1025:2049(1024) ack 1 win 4096

3 0.096969 (0.0232) sun.1305 > bsdi.5555: P 2049:3073(1024) ack 1 win 4096

4 0.157514 (0.0605) bsdi.5555 > sun.1305: . ack 3073 win 1024

5 0.164267 (0.0068) sun.1305 > bsdi.5555: P 3073:4097(1024) ack 1 win 4096

6 0.167961 (0.0037) sun.1305 > bsdi.5555: . ack 1 win 4096 urg 4098





11 0.367533 (0.1868) bsdi.5555 > sun.1305: . ack 4097 win 0


Aplicación escribe 1 octeto de datos urgentes (seq=4097)

Aplicación escribe 1024 octetos

Aplicación escribe 1024 octetos

Aplicación realiza close

Pag. 62


Datos urgentes: Ejemplo

13 9.829712 (9.4612) bsdi.5555 > sun.1305: . ack 4097 win 2048

14 9.831578 (0.0019) sun.1305 > bsdi.5555: . 4097:5121(1024) ack 1 win 4096

urg 4098

15 9.833303 (0.0017) sun.1305 > bsdi.5555: . 5121:6145(1024) ack 1 win 4096

• 9.835089 (0.0018) bsdi.5555 > sun.1305: . ack 4097 win 4096

• 9.835913 (0.0008) sun.1305 > bsdi.5555: FP 6145:6146(1) ack 1 win 4096

• 9.840264 (0.0044) bsdi.5555 > sun.1305: . ack 6147 win 2048

• 9.842386 (0.0021) bsdi.5555 > sun.1305: . ack 6147 win 4096

• 9.843622 (0.0012) bsdi.5555 > sun.1305: F 1:1(0) ack 6147 win 4096

• 9.844320 (0.0007) sun.1305 > bsdi.5555: . ack 2 win 4096

TCP envía el octeto urgente en este segmento

Se desactiva el modo urgente porque ya ha sido enviado el octeto de datos urgentes

Receptor abre la ventana anunciada (aplicación se “despierta”)

Receptor abre la ventana anunciada

TCP envía el último octeto de datos e inicia el fin de la conexión

Pag. 63

TCP AVANZADO

ÍNDICE

4. Timeouts y retransmisiones:A. Temporizadores en TCP.

B. Retransmisiones y temporizador de retransmisión en TCP.

C. Algoritmo de Karn/Partridge.

D. Algoritmo para evitar la congestión (“congestion avoidance”).

E. “Fast recovery” y “Fast retransmit”.

Pag. 64


Temporizadores en TCP

• TCP gestiona cuatro temporizadores por cada conexión:– Temporizador de retransmisión:

• Permite retransmitir datos si no se recibe un asentimiento del receptor.

– Temporizador persistente:• Permite el flujo de información del tamaño de la ventana aunque el

otro extremo haya cerrado la ventana anunciada.

– Temporizador de “keepalive”:• Permite detectar cuando el otro extremo de la conexión se cae o

se reinicializa.

– Temporizador “2MSL”:• Permite esperar un tiempo para garantizar que se cierra

correctamente la conexión.

• Tiempo que permanece en el estado TIME_WAIT.

Pag. 65


Retransmisiones en TCP• Se debe realizar control de errores porque:

– Se pueden perder segmentos.– Se pueden recibir segmentos erróneos.

• Técnicas de control de errores:– Esquemas de detección de errores (CRC).– Esquema de retransmsiones.

• TCP emplea como esquema de retransmisión una versión de Go-Back-N ARQ (“Automatic Repeat Request”).

• TCP retransmite un segmento cuando asume que se ha perdido:– No se recibe asentimiento y vence el temporizador de

retransmisión.– Se reciben múltiples asentimientos para el mismo segmento.

Pag. 66


Temporizador de retransmisiones en TCP

• Por cada conexión se establece un temporizador de retransmisiones.

• Cuando el temporizador vence (“timeout”), el emisor retransmite el primer segmento que no ha sido asentido:– RTO = “Retransmission Timeout”

• El temporizador se activa cuando:– Se envía un segmento con datos y el temporizador no estaba

activo.

– Llega un ACK que asiente nuevos datos.

– Se retransmite un segmento.

• El temporizador se desactiva cuando:– Todos los segmentos enviados son asentidos.

Pag. 67


¿Cómo se establece el RTO?• El valor del RTO es crucial para obtener unas buenas

prestaciones de TCP:– Un valor demasiado pequeño implica retransmisiones

innecesarias.

– Un valor demasiado grande implica esperar demasiado tiempo antes de realizar la retransmisión.

• Principal problema para establecer su valor es que los retardos en la red no son fijos:– RTO debe tener un valor variable y que se adapte

dinámicamente a las condiciones de la red.

– Por lo tanto, va a estar basado en la medida de “round-trip time” (RTT) que realiza TCP.

Pag. 68


Medida del RTT• TCP debe medir la

diferencia de tiempos entre la transmisión de un segmento y la recepción del correspondiente ACK.

• Se realiza una única medida simultáneamente, es decir, no existen medidas que se solapen.

Segmento 1

Segmento 4

ACK segmento 1

Segmento 2Segmento 3

ACK segmento 2 + 3

Segmento 5

ACK segmento 4

ACK segmento 5

RT

T #1

RT

T #2

RT

T #3

Pag. 69


Cálculo del RTO a partir de RTT

Siendo:

• srtt estimador suave de RTT.

• α = 0.9 y β = 2 (valores recomendados).

RTTsrttsrtt nn )1(1 αα −+=+

11 ++ = nn srttRTO β

• Modificación de Jacobson en 1999:– Mejora el estimador cuando existen grandes fluctuaciones en el RTT

(tiene en cuenta la varianza).

111

1

1

var4

var)1()(var

)1(

+++

+

+

+=

−+−=

−+=

nnn

nnn

nn

rttsrttRTO

rttsrttRTTrtt

srttRTTsrtt

ββ

αα

Siendo:

• rttvar estimador varianza de RTT.

• α = 0.125 y β = 0.25

Valores iniciales: )var2(.)3var.0(6 00000 rttsrttRTOsegrttsegsrttsegRTO o +====2/var5.0 111 srttrttRTTsrtt =+=

Pag. 70


Algoritmo de Karn/Partridge• Problema de ambigüedad de los asentimientos:

– Si se recibe un asentimiento de un segmento retransmitido, el emisor no sabe si el asentimiento corresponde al segmento original o al segmento retransmitido.

• Algoritmo de Karn/Partridge:– Cada vez que TCP retransmite un segmento, se paran la

medidas de RTT, hasta que se reciba un asentimiento asociado con un segmento no retransmitido:

• Si es preciso se reutiliza el último RTO.

– Cada vez que se retransmite un segmento, el valor del RTO se establece de la forma siguiente (“backoff exponencial”):

)64,2max(1 nn RTORTO =+

Pag. 71


Control de la congestión

• La mayoría de segmentos perdidos se deben a problemas de congestión en la red.

• Los mecanismos de retransmisión:– Valor de RTO en función del RTT.

– “Backoff exponencial”.

• Algoritmos específicos:– “Slow start” [Jacobson 88].

– “Congestion avoidance” [Jacobson 88].

– “Fast retransmit” y “fast recovery” [Jacobson 90].

Pag. 72


“Congestion avoidance”

• Se considera que existe congestión cuando se pierden segmentos:– Vence el temporizador de retransmisión.

– Llegan asentimientos duplicados.

• Se evita la congestión empleado los algoritmos de “slow start” y “congestion avoidance” juntos:– cwnd debe decrecer “mucho” cuando aumenta la congestión.

– cwnd debe crecer “lentamente” cuando la congestión mejora.

• Se introduce la variable ssthresh (“Slow Start Threshold Size”):– Si cwnd < ssthresh ⇒ TCP en modo “slow start”.

– Si cwnd >= ssthresh ⇒ TCP en modo “congestion avoidance”.

Pag. 73


“Slow start” + “Congestion avoidance”1. Valores iniciales:

– cwnd=1(segmento) y ssthresh=65535 octetos.

2. El emisor puede transmitir el mínimo entre ventana anunciada y ventana de congestión, es decir, ventana efectiva.

3. Si se detecta congestión:– stthresh = max(2 segmentos, ventana_efectiva/2).– Si es debida a un timeout además cwnd=1(segmento).

4. Cuando se recibe un asentimiento:– Si estamos en “slow start” (cwnd < ssthresh):

• cwnd se actualiza a (cwnd + 1) (segmentos).

– Si estamos en “congestion avoidance” (cwnd >= ssthresh):• cwnd se actualiza a (cwnd + 1/cwnd)(segmentos)

Pag. 74


“Slow start” + “Congestion avoidance”

0

2

4

6

8

10

12

14

t=0

t=2

t=4

t=6

ssthresh=8 (segmentos)

cwn

d(e

n s

egm

ento

s)

Roundtrip times

Pag. 75


“Fast retransmit ” y “Fast recovery”• “Fast retransmit” se aplica cuando se reciben tres o más

asentimientos duplicados:– Motivo: si TCP recibe un segmento fuera de secuencia

debe generar sin retardos un asentimiento (duplicado).– Algoritmo:

• Se envía inmediatamente (sin esperar a que venza el “timeout” correspondiente) el segmento que parece que se ha perdido.

• Actualiza el valor de ssthresh=cwnd/2(segmentos).• Entra en “slow start” cwnd=1(segmentos).

• “Fast recovery” evita entrar en modo “slow start” después de un “fast retransmit”:– Motivo: si se reciben asentimientos es que fluyen los

datos.

Pag. 76


“Fast retransmit ” + “Fast recovery”• En la práctica ambos algoritmos se implementan juntos,

así cuando se recibe el tercer ACK duplicado:1. Realiza los siguientes pasos:

• ssthresh=(cwnd/2) (segmentos).• se retransmite el segmento perdido.• cwnd=(ssthresh+3)(segmentos).

3. Cada vez que llega un ACK duplicado:• cwnd se actualiza a (cwnd+1)(segmentos).• transmite un segmento si se puede.

4. Cuando llega un ACK de nuevos datos: • cwnd=ssthresh (segmentos).

Pag. 77

TCP AVANZADO

ÍNDICE

5. Temporizador persistente:A. Síndrome de la ventana tonta (“Silly window syndrome”)

Pag. 78

TCP AVANZADO-TEMPORIZADOR PERSISTENTE

Temporizador persistente

• En TCP puede ocurrir:– El receptor cierre la ventana ofrecida (tamaño cero).– El receptor envía un asentimiento para abrir la

ventana pero este segmento se pierde.– Como los asentimientos no se envían de forma

fiable, podría darse una situación de “deadlock”.

• Solución a través del temporizador persistente:– El emisor envía segmentos (“window probe”)

periodicamente para saber si la ventana se ha abierto.

– La periodicidad de estos segmentos la establece el temporizador persistente.

Pag. 79


Temporizador persistente: Ejemplo

1 0.0 bsdi.1027>svr4.5555: P 1:1025(1024) ack 1 win 4096

2 0.191961(0.1920) svr4.5555>bsdi.1027: . ack 1025 win 4096 3

3 0.196950(0.0050) bsdi.1027>svr4.5555: . 1025:2049(1024) ack 1 win 4096

4 0.200340(0.0034) bsdi.1027>svr4.5555: . 2049:3073(1024) ack 1 win 4096

5 0.207506(0.0072) svr4.5555>bsdi.1027: . ack 3073 win 4096 6

6 0.212676(0.0052) bsdi.1027>svr4.5555: . 3073:4097(1024) ack 1 win 4096

7 0.216113(0.0034) bsdi.1027>svr4.5555: P 4097:5121(1024) ack 1 win 4096

8 0.219997(0.0039) bsdi.1027>svr4.5555: P 5121:6145(1024) ack 1 win 4096

9 0.227882(0.0079) svr4.5555>bsdi.1027: . ack 5121 win 4096 10

10 0.233012(0.0051) bsdi.1027>svr4.5555: P 6145:7169(1024) ack 1 win 4096

11 0.237014(0.0040) bsdi.1027>svr4.5555: P 7169:8193(1024) ack 1 win 4096

12 0.240961(0.0039) bsdi.1027>svr4.5555: P 8193:9217(1024) ack 1 win 4096

13 0.402143(0.1612) svr4.5555>bsdi.1027: . ack 9217 win 0

• El servidor (svr4) está dormido durante 100000 segundos, por lo tanto no leerálos datos recibidos:

svr4 % sock –i –s –P100000 5555

• El cliente (bsdi) realiza escrituras de 1024 octetos.

NOTA: Antes de cerrar la ventana acepta 9216 octetos es por motivos de implementación del

stack TCP/IP de svr4.

Pag. 80


Temporizador persistente: Ejemplo

14 5.351561(4.9494) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

15 5.355571(0.0040) svr4.5555>bsdi.1027: . ack 9217 win 0

16 10.351714(4.9961) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

17 10.355670(0.0040) svr4.5555>bsdi.1027: . ack 9217 win 0

18 16.351881(5.9962) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

19 16.355849(0.0040) svr4.5555>bsdi.1027: . ack 9217 win 0

20 28.352213(11.9964) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

21 28.356178(0.0040) svr4.5555>bsdi.1027: . ack 9217 win 0

22 52.352874(23.9967) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

23 52.356839(0.0040) svr4.5555>bsdi.1027: . ack 9217 win 0

24 100.354224(47.9974) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

25 100.358207(0.0040) svr4.5555>bsdi.1027: . ack 9217 win 0

26 160.355914(59.9977) bsdi.1027>svr4.5555: . 9217:9218(1) ack 1 win 4096

Activa el temporizador persistente (envía “window probe” ~5 seg. después)

Envía “window probe” ~5 seg después






Pag. 81


Temporizador persistente: Ejemplo• Normalmente el temporizador persistente sigue un mecanismo de

“backoff exponencial”.– ¿Por qué en la traza son 5, 6, 12, 24, 48, 60?

• El valor debe estar entre 5 y 60 segundos.• Por ejemplo, para un LAN típicamente:

– Primer valor = 1,5 seg. ⇒ 5 seg.– Segundo valor = 1,5 * 2 = 3 seg. ⇒ 5 seg.– Tercer valor = 3 * 2 = 6 seg.– …– Séptimo valor = 2 * 48 = 96 seg. ⇒ 60 seg.

• El segmento de “window probe” contiene un octeto:– TCP puede enviar un octeto más allá de la ventana ofrecida.– NOTA: en la traza los ACKs no asienten este octeto ⇒ este octeto debe

retransmitirse.

• TCP continúa enviando “window probe” (cada 60 seg.) hasta que:– Se abre la ventana.– Finaliza la aplicación.

Pag. 82


“Silly window syndrome”• Es un efecto que se puede producir en todos los protocolos

que emplean un mecanismo de ventana deslizante para el control de flujo.

• Problema: pueden intercambiarse pequeñas cantidades de datos en una conexión en vez de segmentos completos (MSS):– El receptor anuncia ventana de tamaño pequeño, en vez de

esperar y propagar una ventana mayor.

– El emisor transmite pequeñas cantidades de datos, en vez de esperar por datos adicionales que completen el MSS.

• Solución: ambos extremos tienen que evitar el “silly window syndrome” (SWS).

Pag. 83


Evitar SWS en el receptor• No debe anunciar ventanas de tamaño “pequeño”:

– No anunciar una ventana mayor hasta que la ventana pueda incrementarse hasta:

• MSS del receptor, o

• La mitad del buffer del receptor.

(el mínimo de los dos valores)

Pag. 84


Evitar SWS en el emisor• No transmite hasta que una de las siguientes condiciones se

cumpla:a) Pueda enviarse un segmento completo (MSS).b) Pueda enviarse al menos la mitad del tamaño máximo de la

ventana que ha anunciado el otro extremo.c) Pueda enviar todo los datos disponibles siempre que:

• Si está habilitado Nagle: no tenga ningún segmento enviado anteriormente pendiente de asentimiento, o

• Si está deshabilitado Nagle.

• Consideraciones:– La condición (b) aborda el problema de receptores que anuncian

ventanas de tamaño pequeño (menor que el MSS). Esta condición sólo se observa con host antiguos.

– La condición (c) es el algoritmo de Nagle.

Pag. 85


SWS: Ejemplo• Programa cliente, realiza 6 escrituras de 1024 octetos:

sun% sock –i –n6 bsdi 7777

• Programa servidor, se detiene 4 seg. después de la primera escritura, y 2 seg. después de cada una de las siguientes:

bsdi% sock –i –s –P4 –p2 –r256 7777

La aplicación realiza lecturas de 256 octetos.

Pag. 86


SWS: Ejemplo

12782818read 25611.99

ACK 4099, WIN 0910.170

102230744098:4099(1)810.151

10233073read 2569.99

7673329read 2567.99

5113585read 2565.99

ACK 4098, WIN 075.17

25538414097:4098(1)65.151

2563840read 2563.99

ACK 4097, WIN 050.170

040963073:4097(1024)40.005

102430722049:3073(1024)30.003

307210241:1025(1024)10.000

204820481025:2049(1024)20.002

DisponibleDatosAplicaciónRecibe TCPEnvía TCP

15342562read 25613.99

buffer receptor (4096)

Acción#

segmentoTiempo

Pag. 87


SWS: Ejemplo

7683328FIN 5634:6145(511)1825.171

ACK 5634,WIN 12791725.170

127928175633:5634(1)1625.151

12802816read 25623.99

10243072read 25621.99

ACK 5633, WIN 01520.170

76833285124:5633(509)1420.151

12772819read 25619.99

10213075read 25617.99

7653331read 25615.99

ACK 5124,WIN 5091315.730

50935874100:5124(1024)1215.172

153325634099:4100(1)1015.151

ACK 4100,WIN 15331115.170


ACK 6146,WIN 7671925.174


Acción#

segmentoTiempo

Pag. 88


SWS: Ejemplo

40960read 256 (EOF)51.99

40960 read 25649.99

3840256read 25647.99

3584512read 25645.99

3328768read 25643.99

30721024read 25641.99

ACK 6146, WIN 28162039.99

28161280read 25639.99

25601536read 25637.99

23041792read 25635.99

20482048read 25633.99

17922304read 25631.99

15362560read 25629.99

10243072read 25625.99

12802816read 25627.99



Acción#

segmentoTiempo

Pag. 89


SWS: Ejemplo• Segmento 6: Vence el temporizador de persistencia.

• Segmento 8: Vence el temporizador de persistencia.

• Segmento 10 y 11: Vence el temporizador de persistencia y se anuncia un tamaño de ventana de 1533 (mayor que el MSS).

• Segmento 14: Se anuncia un tamaño de ventana de 509 porque sino produciríamos un “estrechamiento” de la ventana.

• Segmento 16 y 17: Vence el temporizador de persistencia y se anuncia un tamaño de ventana de 1279 (mayor que el MSS).

• Segmento 19: FIN ocupa un número de secuencia y también un espacio en el buffer de recepción.

• Segmento 20: Anuncia un nuevo tamaño de ventana porque puede aumentarse en más de la mitad del buffer del receptor (dependiente de la implementación, podría enviarlo antes)

Pag. 90

TCP AVANZADO

ÍNDICE

6. Temporizador “keepalive”.

Pag. 91


Temporizador de “keepalive”

• Aunque no exista intercambio de datos no se cierra la conexión TCP (no existen mecanismos de “polling”).

• Se introduce en TCP el temporizador de “keepalive” para detectar inactividad en el otro extremo de la conexión.

• Algoritmo: si no existe actividad en dos horas, un extremo envía un segmento de prueba a otro extremo, puede ocurrir:– Responde normalmente ⇒ se activa de nuevo el temporizador.

– No responde (caído, reinicializado, o no alcanzable) ⇒ se envían hasta 10 segmentos de prueba cada 75 seg. antes de dar por finalizada la conexión.

– Se recibe un reset (caído o reinicializado) ⇒ finaliza la conexión.

Pag. 92

TCP AVANZADO

ÍNDICE

7. Futuro y prestaciones.

Pag. 93

TCP AVANZADO-FUTURO Y PRESTACIONES

Futuro y prestaciones• Modificaciones que mejoran las prestaciones de TCP:

– Descubrimiento del MTU del camino (“Path MTU Discovery”).

– Opción de escalado de la ventana.

– Opción de sello temporal (“timestamp”).

2 tcp v2 - it.uc3m.es€¦ · Pag. 4 TCP AVANZADO-TIMEOUTS Y RETRANSMISIONES Definición • TCP es...

Documents

Transcript of 2 tcp v2 - it.uc3m.es€¦ · Pag. 4 TCP AVANZADO-TIMEOUTS Y RETRANSMISIONES Definición • TCP es...