Capa Transporte3-1 Capítulo 3: Capa Transporte - III ELO322: Redes de Computadores Agustín J....
-
Upload
purificacion-ana-medina-torregrosa -
Category
Documents
-
view
218 -
download
1
Transcript of Capa Transporte3-1 Capítulo 3: Capa Transporte - III ELO322: Redes de Computadores Agustín J....
Capa Transporte 3-1
Capítulo 3: Capa Transporte - III
ELO322: Redes de ComputadoresAgustín J. González
Este material está basado en: Material de apoyo al texto Computer Networking: A Top Down Approach Featuring the Internet 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, 2004.
Capa Transporte 3-2
Capítulo 3: Continuación
3.1 Servicios de la capa transporte
3.2 Multiplexing y demultiplexing
3.3 Transporte sin conexión: UDP
3.4 Principios de transferencia confiable de datos
3.5 Transporte orientado a la conexión: TCP Estructura de un
segmento Transferencia confiable
de datos Control de flujo Gestión de la conexión
3.6 Principios del control de congestión
3.7 Control de congestión en TCP
Capa Transporte 3-3
TCP: Generalidades RFCs: 793, 1122, 1323, 2018, 2581
Transferencia full duplex (dos sentidos): Flujo de datos bi-
direccionales en la misma conexión
MSS: maximum segment size, depende del Maximum Transmission Unit de la capa enlace)
Orientado a la conexión: Handshaking
(intercambio de mensajes de control) inicializa al Tx y Rx antes del intercambio de datos
Tiene control de flujo: Tx no sobrecargará al Rx
También tiene control de congestión
Es una comunicación Punto-a punto: Un Tx y un Rx
flujo de bytes confiable y en orden: No hay “límites del
inicio/término de mensaje” Usa pipeline:
El tamaño de la ventana TCP es definido por el control de congestión y control de flujo
Usa buffer en Tx & Rx
socketdoor
TCPsend buffer
TCPreceive buffer
socketdoor
segment
applicationwrites data
applicationreads data
Capa Transporte 3-4
Estructura de un segmento TCP
# puerto origen # puerto dest.
32 bits
Datos de laaplicación
(largo variable)
Número de secuencia
Número de acknowledgement
RcvWindow
Puntero dato urgentechecksum
FSRPAUlargohead
Nousado
Opciones (largo variable)
URG: urgent data (generalmente no usado)
ACK: mensaje porta ACK válido
PSH: push data now(entregar datos a aplic. ahora – gen. no usado)
RST, SYN, FIN:Establecimiento de
conexión(comandos de inicio
y cierre)
# bytes que elRx estádispuesto aaceptar(control de flujo)
Cuenta bytesde datos(no segmentos)Sec: flujo idaAck: flujo vuelta
checksum(como en UDP)
Usado para negociar MSSo para factorde escalamientoventana
5
?
Un autodidacta de Internet dice “Como el campo número de puerto es de 16 bits, un servidor TCP no pueden atender más de 216 clientes simultáneamente.” ¿Está usted de acuerdo? Justifique.
No es correcto. El rango para el número de puerto no limita el número de clientes conectados a un servidor. En general los clientes vienen desde distintas máquinas y el servidor creará un nuevo socket (no puerto) por cada cliente. Ciertamente hay un límite pero no está relacionado con el rango para los puertos pues todos los sockets usan único puerto en el servidor.
Capa Transporte 3-6
Ejemplo: Uso de # de sec. y ACKs en Telnet (Aplicación sobre TCP)
# de Sec.: “número” del byte
dentro del flujo correspondiente al primer byte del segmento de datos
ACKs: # sec. del próximo
byte esperado desde el otro lado
ACK es acumulativoQ: ¿Cómo el receptor
maneja segmentos fuera de orden? la especificación de
TCP lo deja a criterio del implementador
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usuarioescribe
‘C’
host acusarecibo deeco ‘C’
host acusa recibo de ‘C’ y envíaecho de ‘C’
tiempoEscenario telnet simple
Con conexión ya establecida
Capa Transporte 3-7
Round-Trip Time y Timeout en TCP
Q: ¿Cómo fijar valor de timeout en TCP?
Mayor que RTT pero RTT varía
Muy corto: timeout prematuro Retransmisiones
innecesarias Muy largo: lenta
reacción a pérdidas de segmentos
Q: ¿Cómo estimar el RTT?
SampleRTT: mide tiempo desde tx del segmento hasta recibo de ACK Ignora retransmisiones
SampleRTT varía, hay que suavizar el RTT estimado Promediar varias
medidas recientes, no considerar sólo el último SampleRTT
Estimación de RTT no considera tamaño de paquetes.
8
?¿Por qué en la estimación de RTT, TCP omite la medición de SampleRTT de segmentos retransmitidos?
Porque el segmento original podría no haberse perdido y su ACK sólo esté retrasado, luego al enviar la retransmisión, la llegada del ACK podría corresponder al ACK retrasado. La medición de SampleRTT sería errada en este caso; al no distinguir en qué caso estamos, TCP decide no considerar esa medición.
Capa Transporte 3-9
Round-Trip Time y Timeout en TCP
EstimatedRTTi=(1-)*EstimatedRTT
i-1+*SampleRTT
i
Promedio móvil ponderado exponencial Influencia de las muestras pasadas
decrece exponencialmente rápido
Ejercicio: anote EstimatedRTTi en función SampleRTT1..SampleRTTi
Valor típico: = 0.125 = (1/8) = 3 right shifts en binario.
(aunque hoy un right shift tiene costo similar a una multiplicación)
Capa Transporte 3-10
Ejemplo de estimación de RTT:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
Capa Transporte 3-11
Timeout en TCP
Timeout usa EstimatedRTT más un “margen de seguridad” Si hay gran variación en EstimatedRTT => usar gran margen
Primero estimamos cuánto se desvía el SampleRTT del EstimatedRTT:
TimeoutIntervali = EstimatedRTT
i + 4*DevRTT
i
DevRTTi=(1-)*DevRTT
i-1 + *|SampleRTT
i-EstimatedRTT
i|
(típicamente, = 0.25)
Entonces TCP fija el timeout como:
No es desviación estándar,pero es más rápido de calcular.
Capa Transporte 3-12
Capítulo 3: Continuación
3.1 Servicios de la capa transporte
3.2 Multiplexing y demultiplexing
3.3 Transporte sin conexión: UDP
3.4 Principios de transferencia confiable de datos
3.5 Transporte orientado a la conexión: TCP Estructura de un
segmento Transferencia confiable
de datos Control de flujo Gestión de la conexión
3.6 Principios del control de congestión
3.7 Control de congestión en TCP
Capa Transporte 3-13
Transferencia confiable de datos en TCP TCP crea un servicio
de transferencia confiable sobre el servicio no confiable de IP
Usa envío de segmentos en pipeline
ACKs acumulativos TCP usa un timer
único de retransmisión
Retransmisiones son activadas por: Eventos de timeout ACKs duplicados
Inicialmente consideremos un Tx TCP simplificado: Ignora ACKs duplicados Ignora control de flujo y
control de congestión
Capa Transporte 3-14
Eventos del transmisor en TCP:Datos recibidos desde
aplicación: Crea segmento con # de
sec. # sec es el número dentro
del flujo para el primer byte del segmento
Inicia timer si no está ya corriendo (asociar el timer al segmento más viejo sin acuse de recibo)
Tiempo de expiración: TimeOutInterval
Timeout: Retransmitir el segmento que
causó el timeout (sólo 1) Típicamente el intervalo del
timeout se duplica en retransmisiones. ¿Por qué?
Re-iniciar el timer Recepción de ACK: Si es el ACK de un segmento
previo sin acuse de recibo Actualizar estado sobre acuses
recibidos Iniciar timer si hay segmentos
sin acuses de recibo.
Capa Transporte 3-15
Tx TCP(simplificado)
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum
loop (forever) { switch(event)
event: datos recibidos desde la aplicación Crear segmento TCP con número de sec. NextSeqNum if (timer actualmente no está corriendo) iniciar timer pasar segmento a IP (capa red) NextSeqNum = NextSeqNum + length(data) break;
event: timeout del timer retransmitir segmento con menor # de sec. sin acuse iniciar timer break;
event: recepción de ACK con campo ACK de valor x if (x > SendBase) { SendBase = x if (hay segmentos sin acuse de recibo aún) iniciar timer else detener timer } } /* end of loop forever */
Comentarios:• SendBase: Byte más antiguo sin ACK• SendBase-1: último Byte con ACK recibido
Ejemplo:• SendBase = 71 y se recibe ACK con x = 72• El Rx quiere nuevos bytes con seq = 72• Como x > SendBase, llegó acuse de recibode dato (seq = 71)
Notar que evento de timeout envía sólo el paquete más antiguo.
Capa Transporte 3-16
TCP: escenarios de retransmisiónTimeout prematuroPérdida de ACK
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeo
ut
Host B
X
Seq=92, 8 bytes data
ACK=100
time
SendBase= 100
SendBase= 92
Host A
Seq=100, 20 bytes data
ACK=100
time
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
92
tim
eout
ACK=120
Seq=
92
tim
eout
SendBase= 120
SendBase= 120
Sendbase= 100
SendBase= 92
Capa Transporte 3-17
TCP escenarios de retransmisión (más)
ACK acumulado
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeo
ut
Host B
X
Seq=100, 20 bytes data
ACK=120
time
SendBase = 120
SendBase = 92
Estos diagramas no reflejan tiempos de transmisión ni almacenamientos y reenvíos en la ruta.
Capa Transporte 3-18
Generación de ACK en TCP [RFC 1122, RFC 2581]
Evento en Receptor
Llegada de segmento en orden con# sec. esperado. Ya se envió elACK de todo lo previo.
Llegada de segmento en orden con# sec. esperado. Algún segmentotiene ACK pendiente
Llegada de segmento fuera de ordencon # sec. mayor al esperado. Se detecta un vacío.
Llegada de segmento que llena elvacío parcialmente o completamente
TCP acción del receptor
ACK retardado. Espera hasta 500mspor próximo segmento. Si no llegaotro segmento, enviar ACK
Enviar inmediatamente un ACK acumuladose da acuse así a ambos segmentosen orden.
Enviar inmediatamente un ACK duplicado,indicando # sec. del próximo byte esperado
Enviar inmediatamente un ACK si es que el segmento se ubica al inicio del vacío desegmentos recibidos
Notar efecto en RTT
Capa Transporte 3-19
¿Cuál es el propósito de enviar ACK retardados en TCP?
TCP envía ACK retardados para reducir el número de ACKs cuando el canal de receptor a transmisor no requiere enviar datos de regreso (recordar que cada conexión TCP es bidireccional). Retardar en envío de ACK permite mejorar la opción de enviar el ACK en un paquete de datos o enviar un ACK acumulado, mejorando el uso de los recursos de la red.
Capa Transporte 3-20
TCP: Retransmisiones Rápidas: no ignoremos ACK duplicados
Periodo de Time-out es a menudo largo: Retardo largo antes de
re-envío de paquetes perdidos
Se puede detectar paquetes perdidos vía ACKs duplicados. Tx a menudo envía
muchos segmentos seguidos
Si un segmento es perdido, probablemente habrá muchos ACKs duplicados.
Si Tx recibe 3 ACKs de un mismo dato, éste supone que el segmento después de este dato se perdió: Retransmisiones
rápidas: reenviar el segmento antes que el timer expire.
Capa Transporte 3-21
Retransmisiones rápidasHost A
timeo
ut
Host B
time
X
resend 2nd segment
Capa Transporte 3-22
event: Llega ACK, con campo ACK de valor x if (x > SendBase) { SendBase = x if (hay segmentos sin acuse de recibo aún) iniciar timer else detener timer } else { // x == SendBase incrementar cuenta de ACKs de x duplicados if (cuenta de ACKs de x duplicados == 3) { re-enviar segmento con # de secuencia x iniciar timer }
TCP: Algoritmo de Retransmisión Rápida
ACK duplicado de unsegmento con ACKrecibido
Retransmisión rápida
23
?¿Cuándo se genera una retransmisión rápida en TCP?
Cuando se recibe un tercer ACK duplicado.
Capa Transporte 3-24
TCP: TimeoutDuplicando el tiempo del timeout Algunas modificaciones en muchas implementaciones de
TCP: La primera concierne al largo del intervalo de timeout
después que el timer expira• En esta modificación cuando ocurre un timeout, TCP
retransmite el segmento sin ACK con menor número de secuencia pero por cada retransmisión TCP duplica el valor previo de TimeoutInterval
• De esta forma los intervalos crecen exponencialmente después de cada retransmisión sucesiva.
La segunda es si se recibe un ACK entonces se recalcula TimeoutInterval usando EstimatedRTT y DevRTT
Esta es una forma limitada de control de congestión
Capa Transporte 3-25
Capítulo 3: Continuación
3.1 Servicios de la capa transporte
3.2 Multiplexing y demultiplexing
3.3 Transporte sin conexión: UDP
3.4 Principios de transferencia confiable de datos
3.5 Transporte orientado a la conexión: TCP Estructura de un segmento Transferencia confiable de
datos Control de flujo Administración de conexión
3.6 Principios del control de congestión
3.7 Control de congestión en TCP
Capa Transporte 3-26
Control de flujo en TCP
El lado receptor (Rx) de TCP tiene un buffer receptor de datos:
El proceso aplicación puede ser lento en la lectura del buffer (capa transporte).
La idea es hacer coincidir la tasa de transmisión con la tasa de lectura de la aplicación.
Tx no debe sobrecargar el buffer del receptor por
transmitir demasiado rápido
Control de flujo
Hemos visto cómo TCP asegura confiabilidad en la transferencia, ahora veremos cómo consigue controlar el flujo de datos.
Capa Transporte 3-27
Control de flujo en TCP: Cómo trabaja
(supongamos que receptor descarta segmentos fuera de orden)
Espacio libre en bufferRcvWindow = RcvBuffer -
[LastByteRcvd - LastByteRead]
Rx comunica el espacio libre a través del valor de RcvWindow en los segmentos
Así el receptor limita datos en transito (sin ACK) a RcvWindow (Tx debe respetar el no envío de más datos que RcvWindow) Esto garantiza que el
buffer del Rx no se rebalse (overflow)
Capa Transporte 3-28
Control de flujo en TCP: Cómo trabaja El Transmisor debe tomar en cuenta los
segmentos en tránsito Luego el número de bytes que el Tx puede enviar
es en general menor que el anunciado por la RevWindows.
¿Cuál es la expresión para el número de Bytes posibles de enviar sin colapsar al receptor?
29
?
¿Cuál es la función principal o propósito del control de flujo?
Impedir que el transmisor envíe más datos que los que puede almacenar el receptor.
30
?Cuando el transmisor de una conexión TCP está a punto de enviar un segmento con número de secuencia 773, recibe un acuse de recibo con numeración 123 y ventana de recepción 1300. ¿Cuántos bytes como máximo puede transportar el segmento que está a punto de enviar?
Los bytes 123 hasta 772 inclusive (650 bytes) están en tránsito para el valor de ventana de recepción 1300. Es así como podemos asegurar que el receptor podrá almacenar 1300-650 =650 bytes, éste es el número máximos de bytes a transportar en el próximo segmento.
Capa Transporte 3-31
Capítulo 3: Continuación
3.1 Servicios de la capa transporte
3.2 Multiplexing y demultiplexing
3.3 Transporte sin conexión: UDP
3.4 Principios de transferencia confiable de datos
3.5 Transporte orientado a la conexión: TCP Estructura de un
segmento Transferencia confiable
de datos Control de flujo Administración de
conexión
3.6 Principios del control de congestión
3.7 Control de congestión en TCP
Capa Transporte 3-32
Administración de Conexión en TCP
Recordar: Transmisor y receptor TCP establecen una “conexión” antes de intercambiar segmentos de datos
TCP inicializa variables: # de secuencia buffers, información de
control de flujo (e.g. RcvWindow)
cliente: Iniciación de conexión
Socket clientSocket = new Socket("hostname","port
number"); server: contactado por
clienteSocket connectionSocket = welcomeSocket.accept();
Saludo de manos de tres vías (Three way handshake):
Paso 1: host cliente envía segmento TCP SYN al servidor Informa # secuencia inicial no data
Paso 2: host servidor recibe SYN, responde con segmento SYN & ACK Servidor ubica buffers Informa su # secuencia inicial
Paso 3: cliente recibe SYN & ACK, responde con segmento ACK, el cual podría contener datos.
Capa Transporte 3-33
Administración de Conexión en TCP (cont.)
client
SYN=1, seq=client_isn
server
SYN=1, seq=server_isn,
ack=client_isn+1
Connectionrequest
SYN=0, seq=client_isn+1,ack=server_isn+1
Connectiongranted
ACK
Establecimiento de conexión
Capa Transporte 3-34
Administración de la conexión TCP (cont.)
Cerrando una conexión:
Cliente cierra socket: clientSocket.close();
Puede ser iniciado por el servidor, aquí suponemos lo inicia el cliente.
Paso 1: host cliente envía segmento TCP FIN al servidor
Paso 2: servidor recibe FIN, responde con ACK. Ante un cierre de conexión de la aplicación y envía FIN.
client
FIN
server
ACK
ACK
FIN
close
close
closed
timed
wait
closing
closing
closed
Capa Transporte 3-35
Administración de la conexión TCP (cont.)
Paso 3: cliente recibe FIN, responde con ACK.
Entra en “tiempo de espera” – responderá con ACK a FINs recibidos
Paso 4: servidor, recibe ACK. Pasa a conexión cerrada.
Nota: Con pequeña modificación se puede manejar FINs simultáneos.
client
FIN
server
ACK
ACK
FIN
close
close
closed
timed
wait
closing
closing
closed
Cualquiera de los dos puede iniciar el cierre
Capa Transporte 3-36
Administración de la Conexión TCP (cont)
Ciclo de vida delcliente TCP
Ciclo de vidadel servidor TCP
Capa Transporte 3-37
Administración de la Conexión TCP (cont)
CLOSED
LISTEN
SYN_RCVD SYN_SENT
ESTABLISHED
CLOSE_WAIT
LAST_ACKCLOSING
TIME_WAIT
FIN_WAIT_2
FIN_WAIT_1
Passive open Close
Send/SYNSYN/SYN + ACK
SYN + ACK/ACK
SYN/SYN + ACK
ACK
Close/FIN
FIN/ACKClose/FIN
FIN/ACKACK + FIN/ACK Timeout after two segment lifetimes
FIN/ACKACK
ACK
ACK
Close/FIN
Close
CLOSED
Active open /SYN
clienteservidor
Diagrama de estados completo e incluyendo ambos casos
Close llega desde capa aplicación
38
?En una conexión TCP uno de los extremos espera un tiempo (time_wait) luego de enviar su último segmento. Usando un diagrama temporal de intercambio de mensajes muestre y explique el problema que se presentaría si se decidiera no esperar ese time_wait.
Varias situaciones inconvenientes pueden ocurrir, una de ellas se muestra abajo.
Fin
ACK
Fin
No time_wait
ACKX
Fin
Repite Fin luego de time outEspera ACKque no llegará
Capa Transporte 3-39
Capítulo 3: Continuación
3.1 Servicios de la capa transporte
3.2 Multiplexing y demultiplexing
3.3 Transporte sin conexión: UDP
3.4 Principios de transferencia confiable de datos
3.5 Transporte orientado a la conexión: TCP Estructura de un
segmento Transferencia confiable
de datos Control de flujo Administración de
conexión
3.6 Principios del control de congestión
3.7 Control de congestión en TCP