Capa de Transporte - Descripción General

Página 1
Capa de transporte: descripción general

Nuestro objetivo:
▪ comprender los principios ▪ aprender sobre el transporte por Internet
detrás de la capa de transporte protocolos de capa:
servicios: • UDP: transporte sin conexión
• multiplexación, • TCP: fiable orientado a la conexión
demultiplexando transporte
• transferencia de datos confiable • Control de congestión de TCP
• control de flujo
• control de la congestión
Capa de transporte: 3-1
Página 2
Capa de transporte: hoja de ruta

▪ Servicios de la capa de transporte
▪ Multiplexación y demultiplexación
▪ Transporte sin conexión: UDP
▪ Principios de transferencia de datos confiable
▪ Transporte orientado a la conexión: TCP
▪ Principios de control de la congestión
▪ Control de congestión de TCP
▪ Evolución de la capa de transporte
funcionalidad
Página 3
Servicios y protocolos de transporte

solicitud
transporte
▪ proporcionar comunicación lógica

la red
red móvil enlace de datos
físico
ISP nacional o global
entre procesos de solicitud transporte lógico de extremo a extremo
ejecutándose en diferentes hosts
▪ acciones de protocolos de transporte al final
sistemas: local o
• remitente: rompe los mensajes de la aplicación ISP regional
en segmentos , pasa a la capa de red red domestica contenido

• receptor: vuelve a ensamblar segmentos en proveedor
la red centro de datos
mensajes, pasa a la capa de aplicación solicitud
transporte
la red
la red
▪ dos protocolos de transporte disponibles para enlace de datos

físico
Aplicaciones de internet empresa

la red
• TCP, UDP
Página 4
Transporte frente a servicios y protocolos de capa de red

analogía del hogar:
12 niños en la casa de Ann enviando
cartas a 12 niños en la casa de Bill:
▪ hosts = casas
▪ procesos = niños
▪ mensajes de la aplicación = letras en
sobres
▪ protocolo de transporte = Ann y Bill
que se mudan a los hermanos de la casa
▪ protocolo de capa de red = postal
Servicio
Página 5
Transporte frente a servicios y protocolos de capa de red
▪ capa de red: lógica analogía del hogar:

comunicación entre 12 niños en la casa de Ann enviando
Hospedadores cartas a 12 niños en la casa de Bill:
▪ hosts = casas
▪ capa de transporte : lógica ▪ procesos = niños
comunicación entre ▪ mensajes de la aplicación = letras en
procesos sobres
• confía en, mejora, red ▪ protocolo de transporte = Ann y Bill
servicios de capa que se mudan a los hermanos de la casa
▪ protocolo de capa de red = postal
Servicio
Página 6
Acciones de la capa de transporte
Remitente:
solicitud ▪ se pasa una solicitud- solicitud
aplicación. msg
mensaje de capa
transporte ▪ determina el segmento T transporte
T aplicación. msg
h h
valores de los campos de encabezado

red (IP)
▪ crea segmento red (IP)
Enlace
▪ pasa segmento a IP Enlace
físico físico
Página 7
Acciones de la capa de transporte
Receptor:
solicitud ▪ recibe segmento de IP solicitud
▪ verifica los valores del encabezado
transporte
aplicación. msg ▪ extrae la capa de aplicación transporte
mensaje
red (IP) red (IP)
Enlace ▪ demultiplexa
a la aplicaciónelamensaje
través del enchufe Enlace
físico físico
Th aplicación. msg
Página 8
Dos protocolos principales de transporte de Internet

solicitud
transporte
▪ TCP: Protocolo de control de transmisión red

la red
móvil enlace de datos
físico
ISP nacional o global
• entrega confiable y en orden transporte lógico de extremo a extremo
• configuración de la conexión
local o
ISP regional
▪ UDP: Protocolo de datagramas de usuario
• entrega no confiable y desordenada red domestica contenido
proveedor
• extensión sencilla de la propiedad intelectual del "mejor esfuerzo" la red
solicitud
transporte
centro de datos
la red
la red
▪ servicios no disponibles: enlace de datos
físico
• garantías de demora empresa

la red
• garantías de ancho de banda
Página 9
Capítulo 3: hoja de ruta

funcionalidad
Página 10
Servidor HTTP
cliente
solicitud solicitud
Mensaje HTTP
transporte
transporte la red transporte
la red Enlace la red

Enlace físico Enlace
físico físico

Página 11
Servidor HTTP
cliente
solicitud solicitud
Mensaje HTTP
transporte
H t Mensaje HTTP

físico físico
Pagina 12
Servidor HTTP
cliente
solicitud solicitud
Mensaje HTTP
transporte
H t Mensaje HTTP
transporte H la
nH red
t Mensaje HTTP
transporte
Enlace la red
la red
físico físico
Página 13
Servidor HTTP
cliente
solicitud solicitud
transporte

Enlace la red
la red
físico físico
H nH t Mensaje HTTP
Página 14
Servidor HTTP
cliente1 cliente2
solicitud P-cliente 1 P-cliente 2 solicitud
transporte

físico físico
Página 15
Multiplexación / demultiplexación
mulfiplexado en el remitente: demulfiplexación en el receptor:

manejar datos de múltiples usar la información del encabezado para entregar
sockets, agregar encabezado de transporte segmentos recibidos para corregir
(luego usado para demultiplexar) enchufe
solicitud
solicitud P1 P2 solicitud enchufe

P3 transporte P4 proceso

físico Enlace
Enlace
físico físico
Página 16
Cómo funciona la demultiplexación
▪ el host recibe datagramas de IP 32 bits
• cada datagrama tiene una IP de origen Puerto de origen # dest puerto #
dirección, dirección IP de destino
• cada datagrama lleva uno otros campos de encabezado
segmento de la capa de transporte
• cada segmento tiene fuente, solicitud
número de puerto de destino datos
▪ el host usa direcciones IP y puerto (carga útil)
números para dirigir el segmento a

enchufe apropiado Formato de segmento TCP / UDP
Página 17
Demultiplexación sin conexión

Recordar: al recibir el host recibe
▪ al crear socket, debe Segmento UDP :
• comprueba el número de puerto de destino en
especificar el puerto local del host #: segmento
DatagramSocket mySocket1 = nuevo
DatagramSocket ( 12534 ); • dirige el segmento UDP al socket
con ese puerto #
▪ al crear mensajes para
enviar en el zócalo UDP, debe Datagramas IP / UDP con el mismo destino.
especificar número de puerto, pero IP de origen diferente
• puerto de destino # losdirecciones
números sey dirigirán
/ o puertoalde origen
mismo
enchufe en el host receptor
Página 18
Demultiplexación sin conexión: un ejemplo

DatagramSocket
serverSocket = nuevo
DatagramSocket
DatagramSocket mySocket2 = DatagramSocket mySocket1 =
nuevo DatagramSocket ( 6428 ); nuevo DatagramSocket ( 5775 );
( 9157 ); solicitud
solicitud solicitud
P1
P3 P4
transporte
transporte transporte
la red
físico físico
puerto de origen: 6428 Puerto de origen: ?

puerto de destino: 9157 puerto de destino:?
puerto de origen: 9157 Puerto de origen: ?

puerto de destino: 6428 puerto de destino:?
Página 19
Demultiplexación orientada a la conexión

▪ Socket TCP identificado por ▪ el servidor puede admitir muchos
4- tupla: sockets TCP simultáneos:
• dirección IP de origen • cada enchufe identificado por su
• número de puerto de origen propio 4-tupla
• dirección IP de destino • cada enchufe
un cliente asociado con
de conexión diferente
• número de puerto de destino
▪ demux: el receptor usa todos
cuatro valores (4-tupla) para
segmento directo a
enchufe apropiado
Página 20
Demultiplexación orientada a la conexión: ejemplo

solicitud
solicitud P4 P5 P6 solicitud
P1 P2 P3
transporte
la red
físico físico
servidor IP
dirección B
anfitrión: IP IP de origen, puerto: B, 80 anfitrión: IP

dest IP, puerto: A, 9157 IP de origen, puerto: C, 5775 dirección C
dirección A dest IP, puerto: B, 80
IP de origen, puerto: A, 9157
dest IP, puerto: B, 80
IP de origen, puerto: C, 9157
dest IP, puerto: B, 80
Tres segmentos, todos destinados a la dirección IP: B,

puerto de destino: 80 se demultiplexan a diferentes sockets
Página 21
Resumen
▪ Multiplexación, demultiplexación: basada en segmento, datagrama
valores de campo de encabezado
▪ UDP: demultiplexación utilizando el número de puerto de destino (solo)
▪ TCP: demultiplexación con 4 tuplas: IP de origen y destino
direcciones y números de puerto
▪ La multiplexación / demultiplexación ocurre en todas las capas
Página 22

funcionalidad
Página 23
UDP: Protocolo de datagramas de usuario

▪ "sin lujos", "básico" ¿Por qué existe un UDP?
▪ sin conexión
Protocolo de transporte de Internet
establecimiento (que puede
▪ servicio de "mejor esfuerzo", UDP añadir retardo RTT)
los segmentos pueden ser: ▪ simple: sin estado de conexión
• perdido en el remitente, el receptor
▪ tamaño de encabezado pequeño
• entregado fuera de servicio a la aplicación
▪ sin conexión: ▪ sin control de congestión
▪ UDP puede disparar tan rápido como
• sin apretón de manos entre UDP
¡deseado!
enviador recibidor ▪ puede funcionar frente a
• cada segmento UDP manejado congestión
independientemente de los demás
Página 24
UDP: Protocolo de datagramas de usuario

▪ Uso de UDP:
▪ aplicaciones multimedia de transmisión (tolerantes a pérdidas, sensibles a la velocidad)
▪ DNS
▪ SNMP
▪ HTTP / 3
▪ si se necesita una transferencia confiable a través de UDP (por ejemplo, HTTP / 3):
▪ agregar la confiabilidad necesaria en la capa de aplicación
▪ agregar control de congestión en la capa de aplicación
Página 25
UDP: acciones de la capa de transporte
Cliente SNMP Servidor SNMP

solicitud solicitud
(UDP) (UDP)
red (IP) red (IP)
Enlace Enlace
físico físico
Página 26
Cliente SNMP Servidor SNMP

solicitud ▪ se pasa una
Acciones del solicitud-
remitente UDP: solicitud
Mensaje SNMP
mensaje de capa
transporte
transporte ▪ determina el segmento UDP UDP
UDP Mensaje SNMP
hh
(UDP) (UDP)
valores de los campos de encabezado
red (IP) ▪ crea segmento UDP red (IP)
Enlace
▪ pasa segmento a IP Enlace
físico físico
Página 27
Cliente SNMP Acciones del receptor UDP: Servidor SNMP

solicitud ▪ recibe segmento de IP solicitud
▪ comprueba la suma de comprobación UDP
Mensaje SNMP valor del encabezado (UDP)
(UDP) ▪ extrae la capa de aplicación
redh Mensaje
UDP (IP) SNMP mensaje red (IP)
▪ demultiplexa el mensaje
Enlace Enlace
a la aplicación a través del enchufe
físico físico

Página 28
Encabezado de segmento UDP

32 bits
Puerto de origen # dest puerto #
largo suma de comprobación
solicitud longitud, en bytes de

datos Segmento UDP,
(carga útil) incluyendo encabezado
datos a / desde
Formato de segmento UDP capa de aplicación
Página 29
Suma de comprobación UDP

Objetivo: detectar errores ( es decir, bits invertidos) en el segmento transmitido
1 st número 2 nd número suma
Transmitido: 5 6 11
Recibido: 4 6 11
receptor calculado calculado por el remitente
=
suma de comprobación
suma de comprobación (como se recibió)
Página 30
Suma de comprobación UDP

Objetivo: detectar errores ( es decir, bits invertidos) en el segmento transmitido
remitente: receptor :
▪ tratar el contenido de UDP ▪ calcular la suma de comprobación de los recibidos
segmento (incluido el encabezado UDP segmento
campos y direcciones IP) como
secuencia de enteros de 16 bits ▪ comprobar si la suma de comprobación calculada es igual
▪ suma de comprobación: suma (de uno valor del campo de suma de comprobación:
• Diferente: error detectado
suma del complemento) del segmento
contenido • Igual: no se detectó ningún error. Pero tal vez
▪ valor de suma de comprobación puestoerrores
en no obstante? Más tarde ….
Campo de suma de comprobación UDP
Página 31
Suma de comprobación de Internet: un ejemplo
ejemplo: sume dos enteros de 16 bits

1110011001100110
1101010101010101
envolver alrededor 11011101110111011
suma 1011101110111100
suma de comprobación 0100010001000011
Nota: al sumar números, se debe realizar un arrastre del bit más significativo.
agregado al resultado
* Consulte los ejercicios interactivos en línea para ver más ejemplos: h ttp: //gaia.cs.umass.edu/kurose_ross/interactive/
Página 32
Suma de comprobación de Internet: ¡protección débil!
ejemplo: sume dos enteros de 16 bits

01
1110011001100110 10
1101010101010101
envolver alrededor 11011101110111011 Aunque

los números tienen
suma 1011101110111100 cambiado (poco
volteretas), sin cambios
suma de comprobación 0100010001000011
en suma de comprobación!
Página 33
Resumen : UDP
▪ Protocolo "sin florituras":
• los segmentos se pueden perder, entregar fuera de servicio
• servicio de mejor esfuerzo: "envíe y espere lo mejor"
▪ UDP tiene sus ventajas:
• no se necesita configuración / protocolo de enlace (no se incurre en RTT)
• puede funcionar cuando el servicio de red está comprometido
• ayuda con la confiabilidad (suma de verificación)
▪ construir funcionalidad adicional sobre UDP en la capa de aplicación
(p. ej., HTTP / 3)
Página 34

funcionalidad
Página 35
Principios de la transferencia de datos confiable
enviando recepción
proceso proceso
solicitud datos datos
transporte
canal confiable
abstracción de servicio confiable
Página 36
enviando recepción enviando recepción

proceso proceso proceso proceso
solicitud datos datos solicitud datos datos
canal confiable
lado del remitente de lado del receptor
abstracción de servicio confiable datos fiables
protocolo de transferencia de datos confiables
protocolo de transferencia
transporte
la red
canal no confiable
implementación de servicio confiable
Página 37
enviando recepción
proceso proceso
transporte

datos fiables de datos confiables
Complejidad de datos confiables protocolo de transferencia protocolo de transferencia
el protocolo de transferencia dependerá
(fuertemente) en las características detransporte
la red
canal no confiable (perder, canal no confiable
corrupto, reordenar datos?)

Página 38

enviando recepción
proceso proceso
transporte

datos fiables de datos confiables
Remitente, receptor no lo sé protocolo de transferencia protocolo de transferencia
el "estado" de cada uno, por ejemplo,
se recibió un mensaje? transporte
la red
▪ a menos que se comunique a través de un canal no confiable
mensaje
Página 39
Protocolo de transferencia de datos confiable (rdt): interfaces
rdt_send (): llamado desde arriba,

deliver_data (): llamado por rdt a
(por ejemplo, por aplicación). Pasó datos a entregar datos a la capa superior
entregar a la capa superior del receptor
enviando recepción
proceso proceso
rdt_send () datos datos
entregar_datos ()
lado del remitente datos

lado del receptor
implementación de implementación de
datos fiables rdt datos fiables rdt
paquete
protocolo de transferencia protocolo de transferencia
udt_send () datos
Encabezamiento datos
Encabezamiento rdt_rcv ()
canal no confiable
udt_send (): llamado por rdt rdt_rcv (): llamado cuando paquete
transferir el paquete llega al lado del receptor de
Comunicación bidireccional sobre
canal no confiable al receptor canal no confiable canal
Página 40
Transferencia de datos confiable: primeros pasos

Lo haremos:
▪ incrementalmente desarrollar remitente, los lados del receptor de r eliable d ata t ransfer
protocolo (rdt)
▪ considerar solo la transferencia de datos unidireccional
• ¡ Pero la información de control fluirá en ambas direcciones!
▪ utilizar máquinas de estado finito (FSM) para especificar el remitente, el receptor

evento que causa la transición de estado
acciones tomadas en la transición de estado
estado: cuando en este "estado"
estado
siguiente estado de forma única estado
determinado por el siguiente 1 evento
2
evento comportamiento
Página 41
rdt1.0: transferencia confiable a través de un canal confiable

▪ canal subyacente perfectamente confiable
• sin errores de bits
• sin pérdida de paquetes
▪ FSM separados para remitente, receptor:

• el remitente envía datos al canal subyacente
• el receptor lee datos del canal subyacente
Esperar rdt_send (datos) rdt_rcv (paquete)
Esperar
remitente Llamada de
paquete = make_pkt (datos) receptor Llamada de extraer (paquete, datos)
encima udt_send (paquete) debajo deliver_data (datos)
Página 42
rdt2.0: canal con errores de bit

▪ el canal subyacente puede invertir bits en el paquete
• suma de comprobación (por ejemplo, suma de comprobación de Internet) para detectar errores de bits
▪ la pregunta: ¿cómo recuperarse de los errores?
¿Cómo se recuperan los humanos de los "errores" durante la conversación?
Página 43
rdt2.0: canal con errores de bit

▪ el canal subyacente puede invertir bits en el paquete
• suma de comprobación para detectar errores de bits
▪ la pregunta: ¿cómo
• reconocimientos recuperarse
(ACK): el receptordele los
diceerrores?
explícitamente al remitente ese paquete
recibido OK
• reconocimientos negativos (NAK): el receptor le dice explícitamente al remitente
ese paquete tenía errores
• el remitente retransmite el paquete al recibir NAK
detente y espera
el remitente envía un paquete, luego espera la respuesta del receptor
Página 44
rdt2.0: especificaciones FSM

rdt_send (datos)
snkpkt = make_pkt (datos, suma de comprobación)
udt_send (snkpkt)
rdt_rcv (rcvpkt) &&
Esperar Esperar isNAK (rcvpkt)
remitente Llamada de ACK o udt_send (sndpkt) rdt_rcv (rcvpkt) && corrupto (rcvpkt)
encima NAK
udt_send (NAK)
rdt_rcv (rcvpkt) && isACK (rcvpkt)

Esperar
□
Llamada de receptor
debajo
rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)

extraer (rcvpkt, datos)
deliver_data (datos)
udt_send (ACK)
Página 45
rdt2.0: especificación FSM
rdt_send (datos)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
encima NAK
udt_send (NAK)

isACK (rcvpkt)
Esperar
□
Llamada de receptor
debajo
Nota: "estado" del receptor (¿el receptor obtuvo mi

mensaje correctamente?) no es conocido por el remitente a menos que
de alguna manera comunicado del receptor al remitente deliver_data (datos)
▪ ¡ por eso necesitamos un protocolo! udt_send (ACK)
Página 46
rdt2.0: operación sin errores

rdt_send (datos)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
remitente Llamada de ACK o rdt_rcv (rcvpkt) && corrupto (rcvpkt)
udt_send (sndpkt)
encima NAK
udt_send (NAK)

Esperar
□
Llamada de receptor
debajo

udt_send (ACK)
Página 47
rdt2.0: escenario de paquete dañado

rdt_send (datos)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
encima NAK
udt_send (NAK)

Esperar
□
Llamada de receptor
debajo

udt_send (ACK)
Página 48
¡rdt2.0 tiene un defecto fatal!

que pasa si ACK / NAK manejo de duplicados :
corrupto ? ▪ el remitente retransmite el paquete actual si
▪ el remitente no sabe qué ACK / NAK dañado
sucedió en el receptor! ▪ el remitente agrega un número de secuencia a
▪ no cada paquete
se puede simplemente retransmitir: posible
duplicar ▪ el receptor descarta (no entrega
arriba) paquete duplicado
detente y espera
el remitente envía un paquete, luego
espera la respuesta del receptor
Página 49
rdt2.1: remitente, manejo de ACK / NAK confusos

rdt_send (datos)
sndpkt = make_pkt (0, datos, suma de comprobación)
udt_send (sndpkt) rdt_rcv (rcvpkt) &&
(corrupto (rcvpkt) ||
Esperar Esperar isNAK (rcvpkt))
llamar 0 desde ACK o
NAK 0 udt_send (sndpkt)
encima
rdt_rcv (rcvpkt)
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt) &&
&& notcorrupt (rcvpkt)
isACK (rcvpkt)
&& isACK (rcvpkt)
□
□
Esperar Esperar
ACK o llamar 1 desde
rdt_rcv (rcvpkt) NAK 1 encima
&& (corrupto (rcvpkt) ||
isNAK (rcvpkt)) rdt_send (datos)
udt_send (sndpkt) sndpkt = make_pkt (1, datos, suma de comprobación)

udt_send (sndpkt)
Página 50
rdt2.1: receptor, manejo de ACK / NAK confusos

&& has_seq0 (rcvpkt)
sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) && rdt_rcv (rcvpkt) &&
(corrupto (rcvpkt) (corrupto (rcvpkt)
sndpkt = make_pkt (NAK, chksum) sndpkt = make_pkt (NAK, chksum)
udt_send (sndpkt) udt_send (sndpkt)
Esperar Esperar
rdt_rcv (rcvpkt) && 0 de 1 de rdt_rcv (rcvpkt) &&
no corrupto (rcvpkt) && debajo debajo no corrupto (rcvpkt) &&
has_seq1 (rcvpkt) has_seq0 (rcvpkt)
sndpkt = make_pkt (ACK, chksum) sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt) udt_send (sndpkt)

sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt)
Página 51
rdt2.1: discusión
remitente: receptor:
▪ seq # agregado al paquete ▪ debe verificar si recibió el paquete
▪ dos seq. #s (0,1) será suficiente. es duplicado
• estado indica si 0 o 1 es
¿Por qué?
# de secuencia de paquete esperado
▪ debe verificar si recibió ACK / NAK
▪ nota: el receptor no puede saber si
corrupto
su último ACK / NAK recibió OK
▪ el doble de estados en el remitente
• el estado debe "recordar" si
El paquete "esperado" debe tener el número de secuencia
de 0 o 1
Página 52
rdt2.2: un protocolo libre de NAK
▪ la misma funcionalidad que rdt2.1, usando solo ACK

▪ en lugar de NAK, el receptor envía ACK para el último paquete recibido OK
• el receptor debe incluir explícitamente el número de secuencia del paquete que se está ACKED
▪ duplicar ACK en el remitente da como resultado la misma acción que NAK:
retransmitir el paquete actual
Como veremos, TCP usa este enfoque para estar libre de NAK
Página 53
rdt2.2: fragmentos de emisor, receptor

rdt_send (datos)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
(corrupto (rcvpkt) ||
Esperar Esperar
ACK
isACK (rcvpkt, 1) )
llamar 0 desde
encima 0 udt_send (sndpkt)
remitente FSM
fragmento rdt_rcv (rcvpkt)
rdt_rcv (rcvpkt) && && isACK (rcvpkt, 0)
(corrupto (rcvpkt) || □
has_seq1 (rcvpkt)) Esperar receptor FSM
0 de
udt_send (sndpkt) debajo fragmento
sndpkt = make_pkt (ACK1, chksum)
udt_send (sndpkt)
Página 54
rdt3.0: canales con errores y pérdidas

Supuesto de canal nuevo: el canal subyacente también puede perder
paquetes (datos, ACK)
• La suma de comprobación, los números de secuencia, los ACK, las retransmisiones serán de ayuda ...
pero no lo suficiente
P: ¿Cómo manejan los humanos la pérdida de remitente a

receptor de palabras en la conversación?
Página 55
rdt3.0: canales con errores y pérdidas

Enfoque: el remitente espera una cantidad de tiempo "razonable" para recibir ACK
▪ retransmite si no se recibe un ACK en este tiempo
▪ si el paquete (o ACK) acaba de retrasarse (no se pierde):
• La retransmisión será duplicada, ¡pero los números de secuencia ya manejan esto!
• el receptor debe especificar el número de secuencia del paquete que se está ACKED
▪ usar el temporizador de cuenta regresiva para interrumpir después de una cantidad "razonable" de
tiempo
se acabó el tiempo
Página 56
remitente rdt3.0
rdt_send (datos)
udt_send (sndpkt)
start_timer
Esperar Esperar
llamar 0 desde por
encima ACK0
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt) rdt_rcv (rcvpkt)
&& isACK (rcvpkt, 1) && notcorrupt (rcvpkt)
stop_timer && isACK (rcvpkt, 0)
stop_timer
Esperar Esperar
por llamar 1 desde
ACK1 encima
rdt_send (datos)
udt_send (sndpkt)
start_timer

Página 57
remitente rdt3.0
rdt_send (datos)
rdt_rcv (rcvpkt) &&
sndpkt = make_pkt (0, datos, suma de comprobación)(corrupto (rcvpkt) ||
udt_send (sndpkt) isACK (rcvpkt, 1))
rdt_rcv (rcvpkt) start_timer □
□ Esperar Esperar
por se acabó el tiempo
llamar 0 desde
ACK0 udt_send (sndpkt)
encima
start_timer
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt) rdt_rcv (rcvpkt)
&& isACK (rcvpkt, 1) && notcorrupt (rcvpkt)
stop_timer && isACK (rcvpkt, 0)
stop_timer
Esperar Esperar
se acabó el tiempo por llamar 1 desde
udt_send (sndpkt) ACK1 encima
start_timer rdt_rcv (rcvpkt)
□
rdt_send (datos)
rdt_rcv (rcvpkt) &&
(corrupto (rcvpkt) || udt_send (sndpkt)
isACK (rcvpkt, 0)) start_timer
□
Página 58
rdt3.0 en acción
remitente receptor remitente receptor
enviar pkt0 enviar pkt0 pkt0
pkt0
rcv pkt0 rcv pkt0
enviar ack0 ack0 enviar ack0
ack0
rcv ack0 rcv ack0
enviar pkt1 pkt1 enviar pkt1 pkt1
rcv pkt1 X
pérdida
ack1 enviar ack1
rcv ack1
enviar pkt0 pkt0
rcv pkt0 se acabó el tiempo
ack0 enviar ack0 reenviar pkt1 pkt1
rcv pkt1
ack1 enviar ack1
rcv ack1
enviar pkt0 pkt0
(a) sin pérdida rcv pkt0
ack0 enviar ack0
(b) pérdida de paquetes

Página 59
rdt3.0 en acción
remitente receptor
remitente receptor enviar pkt0
pkt0
rcv pkt0
enviar pkt0 pkt0 enviar ack0
ack0
rcv pkt0 rcv ack0
ack0 enviar ack0 enviar pkt1 pkt1
rcv ack0 rcv pkt1
enviar pkt1 pkt1 enviar ack1
rcv pkt1 ack1
ack1 enviar ack1
X se acabó el tiempo
pérdida reenviar pkt1
pkt1 rcv pkt1
se acabó el tiempo
reenviar pkt1 pkt1 rcv ack1 (detectar duplicado)
rcv pkt1 pkt0 enviar ack1
(detectar duplicado)
enviar pkt0
ack1 enviar ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 enviar ack0
enviar pkt0 pkt0 (ignorar) ack0
rcv pkt0
ack0 enviar ack0 pkt1
(c) Pérdida de ACK (d) tiempo de espera prematuro / ACK retrasado

Página 60
Rendimiento de rdt3.0 (detener y esperar)

▪ U remitente: ufilización - fracción de tiempo que el remitente está ocupado enviando
▪ ejemplo: enlace de 1 Gbps, 15 ms prop. retraso, paquete de 8000 bits
• tiempo para transmitir el paquete al canal:
L 8000 bits
Dtrans = R = = 8 microsegundos
10 9 bits / seg
Página 61
rdt3.0: operación de parada y espera

remitente receptor
primer bit de paquete transmitido, t = 0
llega el primer bit del paquete

RTT llega el último bit del paquete, envíe ACK
Llega ACK, enviar siguiente

paquete, t = RTT + L / R
Página 62
rdt3.0: operación de parada y espera
remitente receptor
L/R L/R
Remitente =
U
RTT+ L / R
RTT
.008
= 30.008
= 0,00027
▪ ¡El rendimiento del protocolo rdt 3.0 apesta!

▪ El protocolo limita el rendimiento de la infraestructura subyacente (canal)
Página 63
rdt3.0: operación de protocolos canalizados

canalización: el remitente permite múltiples, "en curso", aún por confirmar
paquetes
• se debe aumentar el rango de números de secuencia
• almacenamiento en búfer en el emisor y / o receptor
Página 64
Canalización: mayor utilización

remitente receptor
primer bit de paquete transmitido, t = 0
último bit transmitido, t = L / R
llega el primer bit del paquete

RTT llega el último bit del paquete, envíe ACK
el último bit de 2 nd paquete llega, ACK envío
el último bit de 3 rd paquete llega, ACK envío
Llega ACK, enviar siguiente
paquete, t = RTT + L / R
Aumentos de la canalización de 3 paquetes

utilización por un factor de 3!
Página 65
Go-Back-N: remitente
▪ remitente: “ventana” de hasta N, paquetes consecutivos transmitidos pero no APILADOS
• número de secuencia de k bits en el encabezado del paquete
▪ ACK acumulafivo: ACK ( n ): ACK todos los paquetes hasta, incluido el nº de secuencia n
• al recibir ACK ( n ): mueve la ventana hacia adelante para comenzar en n + 1
▪ temporizador para el paquete en vuelo más antiguo
▪ fimeout (n): retransmite el paquete ny todos los paquetes seq # superiores en la ventana
Página 66
Go-Back-N: receptor
▪ Solo ACK: envíe siempre ACK para el paquete recibido correctamente hasta ahora, con
más alto orden en la SEC #
• puede generar ACK duplicados
• solo necesito recordar rcv_base
▪ al recibir un paquete fuera de servicio:
• puede descartar (no almacenar en búfer) o almacenar en búfer: una decisión de implementación
• re-ACK pkt con el número de secuencia en orden más alto
Vista del receptor del espacio del número de secuencia:

recibido y ACKed
... ... Fuera de servicio: recibido pero no ACKED
rcv_base
No recibido
Página 67
Go-Back-N en acción
ventana del remitente (N = 4) remitente receptor
012345678 enviar pkt0
recibir pkt0, enviar ack0
enviar pkt3 Pérdida X recibir pkt1, enviar ack1
012345678
(Espere)
recibir pkt3, descartar,
012345678 rcv ack0, enviar pkt4 (re) enviar ack1
012345678 rcv ack1, enviar pkt5 recibir pkt4, descartar,
(re) enviar ack1
ignorar ACK duplicado recibir pkt5, descartar,
(re) enviar ack1
tiempo de espera del paquete 2
012345678 enviar pkt4 rcv pkt2, entregar, enviar ack2
012345678 enviar pkt5 rcv pkt3, entregar, enviar ack3
rcv pkt4, entregar, enviar ack4
rcv pkt5, entregar, enviar ack5
Página 68
Repetición selectiva
▪ el receptor reconoce individualmente todos los paquetes recibidos correctamente
• almacena los paquetes, según sea necesario, para una eventual entrega en orden a la parte superior
capa
▪ el remitente agota el tiempo de espera / retransmite individualmente para paquetes no APILADOS
• el remitente mantiene el temporizador para cada paquete no APILADO
▪ ventana del remitente
• N números de secuencia consecutivos
• limita los números de secuencia de paquetes enviados y no APILADOS
Página 69
Repetición selectiva: ventanas de emisor, receptor
Página 70
Repetición selectiva: emisor y receptor

remitente receptor
datos de arriba: paquete n en [ rcvbase, rcvbase + N-1]
▪ si el próximo número de secuencia disponible en▪ enviar ACK ( n )
ventana, enviar paquete ▪ fuera de servicio: búfer
▪ en orden: entregar (también entregar
tiempo de espera ( n ):
paquetes en orden, almacenados en búfer),
▪ reenviar el paquete n , reiniciar el temporizador
Avanzar ventana a la siguiente todavía no
paquete recibido
ACK ( n ) el
▪ marcar enpaquete
[sendbase, sendbase
n como + N] :
recibido paquete n en [rcvbase-N, rcvbase-1]
▪ ACK ( n )
▪ si es el paquete más pequeño sin empaquetar,
avanzar la base de la ventana a la siguiente de lo contrario:
# de secuencia sin respaldo ▪ ignorar
Página 71
Repetición selectiva en acción

ventana del remitente (N = 4) remitente receptor
enviar pkt2 recibir pkt0, enviar ack0
012345678
enviar pkt3 Pérdida X recibir pkt1, enviar ack1
012345678
(Espere)
recibir pkt3, buffer ,
012345678 rcv ack0, enviar pkt4 enviar ack3
012345678 rcv ack1, enviar pkt5
recibir pkt4, buffer,
record ack3 llegó enviar ack4
recibir pkt5, buffer,
tiempo de espera del paquete 2 enviar ack5
012345678 (pero no 3,4,5)
012345678 rcv pkt2; entregar pkt2,
012345678 pkt3, pkt4, pkt5; enviar ack2
P: ¿que pasa cuando llega ack2?
Página 72
ventana del remitente ventana del receptor
Repetición selectiva: (después de recibirlo)
pkt0
(después de recibirlo)
¡un dilema!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012
0123012
0123012 pkt3
X
ejemplo:
▪ seq #s: 0, 1, 2, 3 (contando base 4)
0123012
pkt0 aceptará el paquete
con el número de secuencia 0
▪ tamaño de la ventana = 3 (a) no hay problema
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012

X 0123012
X
se acabó el tiempo
retransmitir pkt0
0123012 pkt0
aceptará el paquete
(b) ¡Ups!
Página 73
ventana del remitente ventana del receptor
Repetición selectiva: (después de recibirlo)
pkt0
(después de recibirlo)
¡un dilema!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012
0123012
ejemplo: 0123012 pkt3

X
0123012
▪ seq #s: 0, 1, 2, 3 (contando base 4) ▪ el receptor no pkt0
puede aceptará el paquete
ver el lado del remitente con el número de secuencia 0
▪ tamaño de la ventana = 3 (a) no hay problema
▪ receptor
comportamiento
idenfical en ambos
¡casos!
▪ 0algo
123012
es pkt0
0(¡muy
1 2 3 0 1 2 mal! pkt1
P: que relación se necesita
0123012
0123012 pkt2 X 0123012

entre el tamaño de la secuencia # y X 0123012
tamaño de la ventana para evitar problemas

se acabó el tiempo
X
en el escenario (b)? retransmitir pkt0

0123012 pkt0
aceptará el paquete
(b) ¡Ups!
Página 74

• estructura de segmento
• transferencia de datos confiable
• gestión de la conexión
Página 75
TCP: descripción general RFC: 793,1122, 2018, 5681, 7323

▪ punto a punto : ▪ ACK acumulativos
• un remitente, un receptor ▪ canalización:
▪ byte confiable y en orden • Control de flujo y congestión de TCP
vapor: establecer el tamaño de la ventana
• sin "límites de mensajes" ▪ orientado a la conexión:
▪ datos full duplex: • apretón de manos (intercambio de control
• flujo de datos bidireccional en mensajes) inicializa el remitente,
estado del receptor antes del intercambio de datos
• MSS:
mismatamaño máximo de segmento▪ flujo controlado:
conexión
• el remitente no abrumará al receptor
Página 76
Estructura del segmento TCP

32 bits
Puerto de origen # dest puerto # # de secuencia de segmento: contando

ACK: número de secuencia del próximo esperadosecuencia de números bytes de datos en bytestream
byte; Un poco: esto es un ACK (¡no segmentos!)
número de acuse de recibo
cabeza no
longitud (del encabezado TCP) len usó CE PUA FSR recibir ventana control de flujo: # bytes
Suma de comprobación de Internet suma de comprobación
Puntero de datos urg receptor dispuesto a aceptar
opciones (variable
C, E: notificación de congestión largo)
Opciones de TCP
solicitud datos enviados por
RST, SYN, FIN: conexión datos aplicación en
administración (Longitud variable)
Zócalo TCP
Página 77
Números de secuencia TCP, ACK

segmento saliente del remitente
Números de secuencia: Puerto de origen # dest puerto #

secuencia de números
• flujo de bytes "número" de número de acuse de recibo
rwnd
primer byte en los datos del segmento suma de comprobación
puntero urg
tamaño de ventana
norte
Agradecimientos : byte esperado
• seq # del próximo
desde el otro lado espacio del número de secuencia del remitente
• ACK acumulativo enviado enviado, no usable no

ACKED aún ACKED pero no usable
("En vuelo") aún enviado
P : ¿cómo maneja el receptor los
ordenar segmentos segmento saliente del receptor
• A: la especificación de TCP no dice, - arriba

Puerto de origen # dest puerto #
secuencia de números
al implementador
número de acuse de recibo
A rwnd
suma de comprobación
puntero urg
Página 78
Números de secuencia TCP, ACK

Anfitrión A Anfitrión B
Tipos de usuario 'C'

Seq = 42, ACK = 79, datos = 'C'
recibo de ACK del host de 'C',
repite 'C'
Seq = 79, ACK = 43, datos = 'C'
recibo de ACK de host
de repetida 'C'
Seq = 43, ACK = 80
escenario telnet simple

Página 79
Tiempo de ida y vuelta de TCP, tiempo de espera

P: cómo configurar el tiempo de espera
P : ¿cómo
de TCPestimar el RTT?
¿valor? ▪ SampleRTT: tiempo medido
▪ más largo que RTT, ¡pero RTT varía! desde la transmisión del segmento hasta
Recibo ACK
▪ demasiado corto: tiempo de espera prematuro,
• ignorar retransmisiones
retransmisiones innecesarias
▪SampleRTT variará, quiere
▪ demasiado tiempo: reacción lenta a
RTT estimado "más suave "
pérdida de segmento • promedio de varios recientes
mediciones, no solo de corriente
SampleRTT
Página 80

RTT estimada = (1- α ) * RTT estimada + α * RTT de muestra
▪ media móvil ponderada exponencial (EWMA)
▪ la influencia de la muestra pasada disminuye exponencialmente rápido
RTT: gaia.cs.umass.edu a fantasia.eurecom.fr
▪ valor típico: α = 0,125 350
RTT: gaia.cs.umass.edu a fantasia.eurecom.fr

s)
D 300
norte
co
)
s 250
illise
D
norte
o
C
mi
(metro
illis
(metro
T T
T
T R 200
R
sampleRTT
150
RTT estimado
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
tiempo (segundos)
tiempo (segundos)
SampleRTT RTT estimado
Página 81

▪ intervalo de tiempo de espera: RTT estimado más "margen de seguridad"
• gran variación en EstimatedRTT: desea un mayor margen de seguridad
TimeoutInterval = EstimatedRTT + 4 * DevRTT
RTT estimado "margen de seguridad"
▪ DevRTT : EWMA de la desviación SampleRTT de EstimatedRTT :

DevRTT = (1- β ) * DevRTT + β * | SampleRTT-EstimatedRTT |
(normalmente, β = 0,25)
Página 82
Remitente TCP (simplificado)

evento: datos recibidos de evento: fimeout
solicitud ▪ retransmitir segmento que
▪ crear segmento con seq # provocó el tiempo de espera
▪ reiniciar el temporizador
▪ seq # es el número de flujo de bytes
del primer byte de datos en el segmento
▪ iniciar el temporizador si aún no lo ha hecho evento:
▪ si ACK ACK recibido
reconoce
corriendo
segmentos previamente no respaldados
• Piense en el temporizador como si fuera el más antiguo
• actualizar lo que se sabe que es
segmento sin respaldo
• intervalo de caducidad: ACKED
TimeOutInterval • iniciar el temporizador si aún quedan
segmentos sin respaldo
Página 83
Receptor TCP: generación de ACK [RFC 5681]

Evento en el receptor Acción del receptor TCP
llegada del segmento en orden con ACK retrasado. Espere hasta 500ms
# de secuencia esperada. Todos los datospara el siguiente segmento. Si no hay un segmento siguiente,
hasta
# de secuencia esperada ya ACKed enviar ACK
llegada del segmento en orden con enviar inmediatamente un único acumulativo

# de secuencia esperada. Uno mas ACK, ACKing ambos segmentos en orden
el segmento tiene ACK pendiente
llegada de segmento fuera de servicio enviar inmediatamente ACK duplicado ,

secuencia superior a la esperada #. indicando seq. # del próximo byte esperado
Brecha detectada
llegada del segmento que enviar ACK inmediato, siempre que

llena parcial o completamente el hueco el segmento comienza en el extremo inferior del espacio
Página 84
TCP: escenarios de retransmisión

Anfitrión A Anfitrión B Anfitrión A Anfitrión B
SendBase = 92
Seq = 92, 8 bytes de datos Seq = 92, 8 bytes de datos
t t
tu tu Seq = 100, 20 bytes de datos
eo ACK = 100 eo
tim X tim
ACK = 100
ACK = 120
Seq = 92, 8 bytes de datos Secuencia = 92, 8

SendBase = 100 bytes de datos enviar acumulativo
SendBase = 120 ACK por 120
ACK = 100
ACK = 120
SendBase = 120
escenario ACK perdido tiempo de espera prematuro
Página 85
TCP: escenarios de retransmisión

Seq = 92, 8 bytes de datos
ACK = 100
X
ACK = 120
Coberturas acumulativas de ACK

para ACK perdido anterior
Página 86
Retransmisión rápida TCP

Retransmisión rápida TCP
si el remitente recibe 3 adicionales Seq = 92, 8 bytes de datos

ACK para los mismos datos ("triple Seq = 100, 20 bytes de datos
ACK duplicados ”), reenviar sin AACK

X
segmento con el número de secuencia más pequeño
▪ es probable que se pierda el segmento no APAGADO,
así que no esperes el tiempo de espera ACK = 100
t
eou ACK = 100
tim
ACK = 100
Recepción de tres ACK duplicados ACK = 100
indica 3 segmentos recibidos Seq = 100, 20 bytes de datos
después de un segmento perdido - perdido

segmento es probable. ¡Así que retransmite!
Página 87

• estructura de segmento
• transferencia de datos confiable
• gestión de la conexión
Página 88
Control de flujo de TCP

solicitud
P: ¿Qué sucede si la red Eliminación de aplicaciones
proceso
La capa entrega datos más rápido que datos del socket TCP
amortiguadores
capa de aplicación elimina Zócalo TCP
búferes del receptor
datos de los búferes de socket?
TCP
código
Capa de red
entrega de datagrama IP
carga útil en TCP IP
búferes de socket código
del remitente
pila de protocolo del receptor
Página 89

solicitud
proceso
amortiguadores
capa
datosde
deaplicación
los búfereselimina
de socket?
Zócalo
búferes delTCP
receptor
TCP
código
Capa de red
entrega de datagrama IP
carga útil en TCP IP
búferes de socket código
del remitente
Página 90

solicitud
proceso
amortiguadores
TCP
código
recibir ventana
control de flujo: # bytes
IP
receptor dispuesto a aceptar
código
del remitente
Página 91
solicitud
proceso
amortiguadores
TCP
código
control de flujo
el receptor controla al remitente, por lo que
el remitente no se desbordará IP
código
búfer del receptor por
transmitiendo demasiado, demasiado rápido
del remitente
Página 92

▪ El receptor TCP "anuncia" búfer libre
espacio en el campo rwnd en el encabezado TCP al proceso de solicitud
• Tamaño de RcvBuffer establecido a través del conector
opciones (el valor predeterminado típico es 4096RcvBuffer
bytes) datos almacenados en búfer
• muchos sistemas operativos se autoajustan
rwnd espacio libre de búfer
RcvBuffer
▪ el remitente limita la cantidad de
("En vuelo") datos recibidos rwnd Cargas útiles del segmento TCP
▪ garantiza que el búfer de recepción no Almacenamiento en búfer del lado del receptor TCP
Desbordamiento
Página 93

control de flujo: receptor de # bytes dispuesto a aceptar
▪ El receptor TCP "anuncia" búfer libre

espacio en el campo rwnd en el encabezado TCP
• Tamaño de RcvBuffer establecido a través del conector
recibir ventana
opciones (el valor predeterminado típico es 4096 bytes)
• muchos sistemas operativos se autoajustan
RcvBuffer
▪ el remitente limita la cantidad de
("En vuelo") datos recibidos rwnd
▪ garantiza que el búfer de recepción no
Desbordamiento
Formato de segmento TCP
Página 94
Gestión de conexiones TCP

antes de intercambiar datos, "apretón de manos" del remitente / receptor:
▪ aceptar establecer conexión (cada uno conoce al otro dispuesto a establecer conexión)
▪ acordar los parámetros de conexión (p. Ej., Números de secuencia iniciales)
solicitud solicitud
estado de conexión: ESTAB estado de conexión: ESTAB
variables de conexión: Variables de conexión:
seq # cliente a servidor seq # cliente a servidor
servidor a cliente servidor a cliente
rcvBuffer tamaño rcvBuffer tamaño
en el servidor, cliente en el servidor, cliente
la red la red
Socket clientSocket = Conexión de enchufe

newSocket ("nombre de host", "número de puerto"); welcomeSocket.accept ();
Página 95
Aceptar establecer una conexión

Apretón de manos bidireccional:
P: ¿el apretón de manos bidireccional siempre

Hablemos trabajar en red?
ESTAB
OK ▪ retrasos variables
ESTAB
▪ mensajes retransmitidos (p. Ej.
req_conn (x)) debido a la pérdida del mensaje
▪ reordenación de mensajes
elige x
req_conn (x)
▪ no puede "ver" el otro lado
ESTAB
acc_conn (x)
ESTAB
Página 96
Escenarios de protocolo de enlace bidireccional

elige x
req_conn (x)
ESTAB
acc_conn (x)
ESTAB
datos (x + 1) aceptar
datos (x + 1)
ACK (x + 1)
conexión
x completa
¡No hay problema!
Página 97
elige x
req_conn (x)
ESTAB
retransmitir acc_conn (x)
req_conn (x)
ESTAB
req_conn (x)
conexión
cliente x completa servidor
termina olvida x
ESTAB
acc_conn (x)
Problema:
¡conexión!medio abierto
(sin cliente)
Página 98

elige x
req_conn (x)
ESTAB
retransmitir acc_conn (x)
req_conn (x)
ESTAB
datos (x + 1)
retransmitir
datos (x + 1)
conexión
x completa servidor
cliente
termina olvida x
req_conn (x)
ESTAB
datos (x + 1)
Problema: datos dup

¡aceptado!
Página 99
Protocolo de enlace de 3 vías TCP

Estado del servidor
serverSocket = socket (AF_INET, SOCK_STREAM)
Estado del cliente serverSocket.bind (('', serverPort))

serverSocket.listen (1)
clientSocket = enchufe (AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept ()
ESCUCHA
clientSocket.connect ((serverName, serverPort)) ESCUCHA
elija init seq num, x
enviar mensaje TCP SYN
SYNSENT SYNbit = 1, Seq = x
elija init seq num, y
enviar TCP SYNACK
msg, confirmando SYN SYN RCVD
SYNbit = 1, Seq = y
ACKbit = 1; ACKnum = x + 1
recibido SYNACK (x)
ESTAB indica que el servidor está activo;
enviar ACK para SYNACK;
este segmento puede contener ACKbit = 1, ACKnum = y + 1
datos de cliente a servidor
recibido ACK (y)
indica que el cliente está en vivo
ESTAB
Página 100
Un protocolo de apretón de manos de 3 vías humano
1. ¿Aseguramiento?
2. Asegurar.
3. Escalada.
Página 101
Cerrar una conexión TCP

▪ cliente, servidor, cada uno cierra su lado de conexión
• enviar segmento TCP con el bit FIN = 1
▪ responder al FIN recibido con ACK
• al recibir FIN, ACK se puede combinar con el propio FIN
▪ se pueden gestionar intercambios FIN simultáneos
Página 102

funcionalidad
Página 103
Principios del control de la congestión

Congestión:
▪ informalmente: “demasiadas fuentes envían demasiados datos demasiado rápido para
red para manejar "
▪ manifestaciones:
• retrasos prolongados (puesta en cola en búferes de enrutador)
• pérdida de paquetes (desbordamiento del búfer en los enrutadores)
▪ ¡ diferente del control de flujo!
control de la congestión:
▪ ¡ un problema de los 10 principales! demasiados remitentes,
enviando demasiado rápido
control de flujo: un remitente

demasiado rápido para un receptor
Página 104
Causas / costos de la congestión: escenario 1

datos originales: □en rendimiento: □ fuera
Escenario más simple: Anfitrión A
▪ un enrutador, búferes infinitos
▪ capacidad del enlace de entrada, salida: R infinito compartido
búferes de enlace de salida
▪ dos flujos
R R
▪ no se necesitan retransmisiones
Anfitrión B
R/2
t
tu
P: tasa
¿Quédesucede cuando □
en □
llegada
t: o
tu
pag
gh demora
se acerca a R / 2?
tu
ro
th
□ en R/2 □ en R/2
máximo por conexión grandes retrasos como tasa de llegada

rendimiento: R / 2 □
en capacidad de enfoques
Página 105

▪ un enrutador, búferes finitos
▪ el remitente retransmite el paquete perdido y agotado
• de entrada de capa de aplicación = salida de capa de aplicación: □ en = □ cabo
• la entrada de la capa de transporte incluye retransmisiones□: en□ ' en
Anfitrión A □ en : datos originales

□ fuera
□ 'en: datos originales, más
datos retransmitidos
R R
Anfitrión B salida compartida finita
búferes de enlace
Página 106

Idealización: conocimiento perfecto R/2
t
tu
▪ el remitente envía solo cuando los búferes del enrutador están disponibles
□o
t:
ughpu
a través de
Anfitrión A □ en : datos originales □ en

Copiar □ fuera R/2
espacio libre de búfer!
R R
búferes de enlace
Página 107

La idealización: algún conocimiento perfecto
▪ los paquetes se pueden perder (caer en el enrutador) debido a
búferes completos
▪ el remitente sabe cuándo se ha descartado el paquete:
solo se reenvía si se sabe que el paquete se ha perdido
Anfitrión A □ en : datos originales

Copiar □ 'en: datos originales, más
sin espacio de búfer!
R R
búferes de enlace
Página 108
Causas / costos de la congestión:
La idealización: algún conocimiento perfecto
escenario 2 R/2
t Capacidad "desperdiciada" debido
tu
▪ los paquetes se pueden perder (caer en el enrutador) debido a □o a retransmisiones
búferes completos
al enviar a
▪ el remitente sabe cuándo se ha descartado el paquete: poner:
R / 2, algunos paquetes
Se necesitan
solo se reenvía si se sabe que el paquete se ha perdido retransmisiones
mediante
Anfitrión A □ en : datos originales □ en R/2

R R
búferes de enlace
Página 109

Escenario realista: duplicados innecesarios R/2
t
▪ los paquetes se pueden perder, caer en el enrutador debido a tu
Capacidad "desperdiciada" debido
□o a innecesario
búferes completos, que requieren retransmisiones retransmisiones
▪ pero los tiempos del remitente pueden expirar prematuramente, t:
al enviar a
enviando dos copias, ambas entregadas ghpu
son retransmisiones,
a través de incluyendo necesario
Anfitrión A □ en : datos originales □ en

y innecesario
se acabó el tiempo R / 2 duplicados, que son
Copiar □ 'en: datos originales, más ¡entregado!

R R
búferes de enlace
Página 110

Escenario realista: duplicados innecesarios R/2
t
▪ los paquetes se pueden perder, caer en el enrutador debido a tu
Capacidad "desperdiciada" debido
□o a innecesario
búferes completos, que requieren retransmisiones retransmisiones
▪ pero los tiempos del remitente pueden expirar prematuramente, t:
al enviar a
enviando dos copias, ambas entregadas ghpu
son retransmisiones,
a través de incluyendo necesario
y innecesario
□ en R / 2 duplicados, que son
¡entregado!
"Costos" de la congestión:
▪ más trabajo (retransmisión) para un determinado rendimiento del receptor
▪ retransmisiones innecesarias: el enlace lleva varias copias de un paquete
• disminución del rendimiento máximo alcanzable
Página 111

▪ cuatro remitentes P: que sucede cuando □en y □ en' aumento?
▪ mulfi-hop caminos
A: como rojoen' aumenta,
□ todos los paquetes azules que llegan a la parte superior
▪ tiempo de espera / retransmisión cola se descartan, rendimiento azul g 0
Anfitrión A □en : datos originales
Anfitrión B
□ en' : datos originales, más
finito compartido
búferes de enlace de salida
Anfitrión D
□ fuera
Anfitrión C
Página 112

R/2
t
tu
o
□
□ en' R/2
otro "costo" de la congestión:

▪ cuando se cae un paquete, cualquier capacidad de transmisión ascendente y
el almacenamiento en búfer utilizado para ese paquete se desperdició.
Página 113
Causas / costos de la congestión: conocimientos

R/2
t
tu
lt:o
▪ el rendimiento nunca puede exceder la capacidad tu

pag
gh
tu
ro
th
yo en R/2
▪ la demora aumenta a medida que se acerca la capacidad elay

D
R/2
t
tu
yo en R/2
▪ pérdida / retransmisión disminuye la efectividad lo

t:
tu
pag
gh
rendimiento
tu
ro
th
yo en R/2 R/2
▪ duplicados innecesarios disminuyen aún más

t
tu
o
l
t:
tu
pag
rendimiento efectivo gh
tu
ro
th
R/2
yo en R/2
▪ capacidad de transmisión ascendente / almacenamiento en búfer

t
tu
o
l
desperdiciado por paquetes perdidos aguas abajo
yo 'en R/2
Página 114
Enfoques hacia el control de la congestión
Control de congestión de extremo a extremo:

▪ sin comentarios explícitos de
la red
▪ congestión inferida de ACK
datos datos
ACK
pérdida observada, retraso
▪ enfoque adoptado por TCP
Página 115
Enfoques hacia el control de la congestión
Congestión asistida por red

control: información explícita de congestión
▪ los enrutadores brindan retroalimentación directa

para enviar / recibir hosts con datos datos
ACK
flujos que atraviesan congestionados ACK
enrutador
▪ puede indicar el nivel de congestión o
establecer explícitamente la tasa de envío
▪ Protocolos TCP ECN, ATM, DECbit
Página 116

funcionalidad
Página 117
Control de congestión TCP: AIMD

▪ enfoque: los remitentes pueden aumentar la velocidad de envío hasta que se pierdan los paquetes
(congestión), luego disminuya la tasa de envío en caso de pérdida
Incremento adifivo Disminución de Mulfiplicafive
aumentar la tasa de envío en 1 reducir la tasa de envío a la mitad en
tamaño máximo de segmento cada cada evento de pérdida
RTT hasta que se detecte una pérdida
te
real academia de bellas artes
gramo
en
D
norte
Diente de sierra AIMD
mi
rS
comportamiento: sondeo
mi
D
norte para ancho de banda
se
PAG
C
T
tiempo Capa de transporte: 3-117
Página 118
TCP AIMD: más

Detalle de disminución múltiple : la tasa de envío es
▪ Reducir a la mitad la pérdida detectada por ACK duplicado triple (TCP Reno)
▪ Corte a 1 MSS (tamaño máximo de segmento) cuando la pérdida detecte
tiempo de espera (TCP Tahoe)
¿Por qué A I M D ?
▪ AIMD, un algoritmo asíncrono distribuido, se ha
mostrado a:
• ¡ Optimice los caudales congestionados en toda la red!
• tienen propiedades de estabilidad deseables
Página 119
Control de congestión TCP: detalles

espacio del número de secuencia del remitente
cwnd Comportamiento de envío de TCP:
▪ aproximadamente: enviar bytes cwnd,
espere RTT para ACKS, luego
enviar más bytes
último byte
ACKED enviado, pero no- disponible pero cwnd
no utilizado Velocidad deRTT
TCPbytes
~ / seg
aún ACKED
("En vuelo") último byte enviado
▪ El remitente TCP limita la transmisión:

LastByteSent- LastByteAcked < cwnd
▪ cwnd se ajusta dinámicamente en respuesta a la red observada

congestión (implementación de control de congestión TCP)
Página 120
Inicio lento de TCP

▪ cuando comienza la conexión,
aumentar la tasa exponencialmente un segmento
hasta el primer evento de pérdida: T
T
R
• inicialmente cwnd = 1 MSS dos segmentos
• doble cwnd cada RTT

• hecho incrementando cwnd
cuatro segmentos
por cada ACK recibido
▪ resumen: la tasa inicial es
lento, pero aumenta
tiempo
exponencialmente rápido
Página 121
TCP: desde un inicio lento hasta evitar la congestión
P: ¿ cuándo debería la exponencial

¿Aumentar el cambio a lineal?
X
R: cuando cwnd llega a la mitad de su
valor antes del tiempo de espera.
Implementación:
▪ variable ssthresh
▪ en caso de pérdida, ssthresh se establece en
1/2 de cwnd justo antes del evento de pérdida
Página 122
Resumen: control de congestión de TCP

Nuevo
Nuevo ¡ACK!
¡ACK!
ACK duplicado
dupACKcount ++ nuevo ACK
cwnd = cwnd + MSS
nuevo(MSS .
ACK/ cwnd)
dupACKcount = 0
cwnd = cwnd + MSS transmitir nuevos segmentos, según se permita
dupACKcount = 0
□ transmitir nuevos segmentos, según se permita
cwnd = 1 MSS
ssthresh = 64 KB cwnd> ssthresh
dupACKcount = 0
lento □ congestión
comienzo se acabó el tiempo evitación
ssthresh = cwnd / 2
cwnd = 1 MSS ACK duplicado
se acabó el tiempo dupACKcount = 0 dupACKcount ++
ssthresh = cwnd / 2 retransmitir segmento faltante
cwnd = 1 MSS
dupACKcount = 0
retransmitir segmento faltante Nuevo
se acabó el tiempo ¡ACK!
ssthresh = cwnd / 2
cwnd = 1 Nuevo ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmitir segmento faltante dupACKcount = 0
ssthresh = cwnd / 2 ssthresh = cwnd / 2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmitir segmento faltante
retransmitir segmento faltante
rápido
recuperación
ACK duplicado
cwnd = cwnd + MSS
transmitir nuevos segmentos, según se permita
Página 123
TCP CUBIC
▪ ¿Existe una forma mejor que AIMD de “sondear” el ancho de banda utilizable?
▪ Perspicacia / intuición:
• W max : velocidad de envío a la que se detectó la pérdida por congestión
• el estado de congestión del enlace de cuello de botella probablemente (?) No ha cambiado mucho
• después de reducir la velocidad / ventana a la mitad en la pérdida, inicialmente aumenta a W máx. Más rápido , pero luego
acercarse a W max más lentamente
W máx. TCP clásico
TCP CUBIC - superior

W máx. / 2 rendimiento en este
ejemplo
Página 124
TCP CUBIC
▪ K: momento en el que el tamaño de la ventana TCP alcanzará W máx.
• K en sí mismo es sintonizable
▪ aumentar W en función del cubo de la distancia entre la corriente
tiempo y K
• mayores aumentos cuando más lejos de K
• aumentos más pequeños (cauteloso) cuando está más cerca de K
▪ TCP CUBIC predeterminado W máx.
en Linux, la mayoría TCP Reno

TCP popular para TCP CUBIC
Web popular TCP
enviando
servidores índice
tiempo
t0 t1 t2 t3 t4
Página 125
TCP y el "vínculo de cuello de botella" congestionado

▪ TCP (clásico, CUBIC) aumenta la velocidad de envío de TCP hasta que se produce la pérdida de paquetes.
en la salida de algún enrutador: el enlace del cuello de botella
fuente destino
solicitud solicitud
TCP TCP
la red la red
Enlace Enlace
físico físico
cola de paquetes casi
nunca vacio, a veces
paquete de desbordamiento (pérdida)
enlace de cuello de botella (casi siempre ocupado)

Página 126
TCP y el "vínculo de cuello de botella" congestionado

▪ TCP (clásico, CUBIC) aumenta la velocidad de envío de TCP hasta que se produce la pérdida de paquetes.
en la salida de algún enrutador: el enlace del cuello de botella
▪ comprender la congestión: útil para centrarse en el vínculo de cuello de botella congestionado
conocimiento: aumentar la velocidad de envío de TCP

fuente no aumentar el final-final en todo destino
solicitud
con cuello de botella congestionado
solicitud
TCP TCP
la red la red
Enlace Enlace
físico físico
insight: aumento de TCP

la tasa de envío será
aumentar el RTT medido
Objetivo: "mantener el tubo de extremo a extremo lleno, pero no más lleno"
RTT
Página 127
Control de congestión TCP basado en retardo

Mantener la tubería del remitente al receptor "lo suficientemente llena, pero no más llena": mantenga
Enlace de cuello de botella ocupado transmitiendo, pero evite grandes retrasos / almacenamiento en búfer
# bytes enviados en
Medido último intervalo RTT
RTTMedido rendimiento =
RTTMedido
Enfoque basado en retrasos:
▪ RTT min : RTT mínimo observado (ruta no congestionada)
▪ rendimiento no congestionado con ventana de congestión cwnd es cwnd / RTT min
si el rendimiento medido es "muy cercano" al rendimiento no congestionado
aumentar cwnd linealmente / * ya que la ruta no está congestionada * /
de lo contrario, si el rendimiento medido "muy por debajo" no congestionado en todo
disminuir cwnd linealmente / * ya que la ruta está congestionada * /
Página 128
Control de congestión TCP basado en retardo

▪ control de la congestión sin inducir / forzar pérdidas
▪ maximizando ("manteniendo la tubería justa llena ...") mientras se mantiene
retraso bajo ("... pero no más completo")
▪ varios TCP implementados adoptan un enfoque basado en retrasos
▪ BBR implementado en la red troncal (interna) de Google
Página 129
Notificación de congestión explícita (ECN)

Las implementaciones de TCP a menudo implementan un control de congestión asistido por red :
▪ dos bits en el encabezado IP (campo ToS) marcados por el enrutador de red para indicar congestión
• política para determinar el marcado elegido por el operador de red
▪ indicación de congestión llevada al destino
▪ el destino establece el bit ECE en el segmento ACK para notificar al remitente de la congestión
▪ implica tanto IP (encabezado IP marcado de bits ECN) como TCP (encabezado TCP C, marcado de bits E)
fuente Segmento TCP ACK

destino
solicitud solicitud
ECE = 1
TCP TCP
la red la red
Enlace Enlace
físico físico
ECN = 10 ECN = 11
Datagrama de IP
Página 130
Equidad de TCP
Objetivo de equidad: si K sesiones de TCP comparten el mismo enlace de cuello de botella de
ancho de banda R , cada uno debe tener una tasa promedio de R / K
Conexión TCP 1
embotellamiento
Conexión TCP 2 enrutador
capacidad R
Página 131
P: ¿TCP es justo?
Ejemplo: dos sesiones de TCP en competencia:
▪ el aumento aditivo da una pendiente de 1, ya que a lo largo de los incrementos
▪ la disminución multiplicativa disminuye el rendimiento proporcionalmente
R cuota de ancho de banda igual
Utah ¿Es justo TCP?

hp R: Sí, poco idealizado
ug
ro pérdida: reducir la ventana por un factor de 2 supuestos:
th prevención de la congestión: aumento aditivo ▪ mismo RTT
pérdida: reducir la ventana por un factor de 2
n2
prevención de la congestión: aumento aditivo
▪ número fijo de sesiones
ectio solo en congestión
nn
o
evitación
C
Rendimiento de la conexión 1 R
Página 132
Equidad: ¿todas las aplicaciones de red deben ser "justas"?

Equidad y UDP Equidad, TCP paralelo
conexiones
▪ las aplicaciones multimedia a menudo no
utilizar TCP ▪ la aplicación puede abrir múltiples
• no quiero que la tasa se reduzca por conexiones paralelas entre dos
control de congestión Hospedadores
▪ en su lugar use UDP: ▪ los navegadores web hacen esto, por ejemplo, enlace de
• enviar audio / video a velocidad constante,
tasa R con 9 conexiones existentes:
tolerar la pérdida de paquetes • la nueva aplicación solicita 1 TCP, obtiene una tasa R / 10
▪ no hay "policía de Internet" • nueva aplicación solicita 11 TCP, obtiene R / 2
vigilar el uso de la congestión
control
Página 133
Capa de transporte: hoja de ruta

funcionalidad
Página 134
Evolución de la funcionalidad de la capa de transporte

▪ TCP, UDP: principales protocolos de transporte durante 40 años
▪ diferentes "sabores" de TCP desarrollados, para escenarios específicos:
Guión Desafíos
Tubos largos y gruesos (datos grandes
Muchos paquetes "en vuelo"; la pérdida se apaga
transferencias) tubería
Redes inalámbricas Pérdida debido a enlaces inalámbricos ruidosos, movilidad;
TCP trata esto como pérdida por congestión
Enlaces de larga demora RTT extremadamente largos
Redes de centros de datos Sensible a la latencia
Flujos de tráfico de fondo Flujos de TCP "en segundo plano" de baja prioridad
▪ mover las funciones de la capa de transporte a la capa de aplicación, por encima de UDP
• HTTP / 3: QUIC
Página 135
QUIC: Conexiones rápidas a Internet UDP

▪ protocolo de capa de aplicación, además de UDP
• aumentar el rendimiento de HTTP
• implementado en muchos servidores y aplicaciones de Google (Chrome, aplicación móvil de YouTube)
HTTP / 2 HTTP / 2 (reducido)

Solicitud HTTP / 3
TLS QUIC
Transporte TCP UDP
La red IP IP
HTTP / 2 sobre TCP HTTP / 2 sobre QUIC sobre UDP
Página 136
QUIC: Conexiones rápidas a Internet UDP

adopta enfoques que hemos estudiado en este capítulo para
establecimiento de conexión, control de errores, control de congestión
• control de errores y congestión: "Lectores familiarizados con la pérdida de TCP
La detección y el control de la congestión encontrarán aquí algoritmos que
TCP más conocidos ". [de la especificación QUIC]
• establecimiento de conexión: fiabilidad, control de congestión,
autenticación, cifrado, estado establecido en un RTT
▪ múltiples “flujos” a nivel de aplicación multiplexados sobre un solo QUIC

conexión
• transferencia de datos confiable separada, seguridad
• control de congestión común
Página 137
QUIC: establecimiento de conexión
Apretón de manos de TCP

(capa de transporte) Apretón de manos rápido
Apretón de manos TLS datos

(seguridad)
datos
TCP (fiabilidad, control de congestión QUIC: fiabilidad, control de congestión,

estado) + TLS (autenticación, cripto autenticación, estado criptográfico
estado)
▪ 1 apretón de manos
▪ 2 apretones de manos en serie
Página 138
QUIC: streams: paralelismo, sin bloqueo HOL
HTTP HTTP
OBTENER HTTP
OBTENER
OBTENER
HTTP HTTP
OBTENER OBTENER
HTTP
OBTENER QUIC QUIC QUIC QUIC QUIC QUIC
cifrar cifrar cifrar
aplicación cifrar cifrar cifrar
QUIC QUIC QUIC QUIC QUIC QUIC

Cifrado TLS Cifrado TLS RDT RDT RDT RDT
¡error!
RDT RDT
QUIC Cong. Cont. QUIC Cong. Cont.

TCP RDT TCP
¡error! RDT
TCP Cong. Contr.

transporte TCP Cong. Contr. UDP UDP
(a) HTTP 1.1 (b) HTTP / 2 con QUIC: sin bloqueo HOL
Página 139
Capítulo 3: resumen
▪ principios detrás del transporte Hasta la próxima:
servicios de capa: ▪ salir de la red
• multiplexación, demultiplexación "Borde" (aplicación,
• transferencia de datos confiable capas de transporte)
• control de flujo ▪ en el "núcleo" de la red
▪ dos capas de red
▪ instanciación, implementación
capítulos :
en Internet • plano de datos
• UDP • plano de control
• TCP
Página 140
Diapositivas adicionales del Capítulo 3
Página 141
Go-Back-N: FSM extendido del remitente

rdt_send (datos)
if (nextseqnum <base + N) {
sndpkt [nextseqnum] = make_pkt (nextseqnum, data, chksum)
udt_send (sndpkt [nextseqnum])
si (base == nextseqnum)
start_timer
nextseqnum ++
}
□ demás
rechazar_datos (datos)
base = 1
nextseqnum = 1
se acabó el tiempo
start_timer
Esperar udt_send (sndpkt [base])
rdt_rcv (rcvpkt) udt_send (sndpkt [base + 1])
&& corrupto (rcvpkt) ...
udt_send (sndpkt [nextseqnum-
1])
rdt_rcv (rcvpkt) &&
notcorrupt (rcvpkt)
base = getacknum (rcvpkt) +1
Si (base == nextseqnum)
stop_timer
demás
start_timer
Página 142
Go-Back-N: FSM extendido del receptor

cualquier otro evento
udt_send (sndpkt)
rdt_rcv (rcvpkt)
□ && hasseqnum (rcvpkt, esperabaseqnum)
esperadoseqnum = 1 Esperar extraer (rcvpkt, datos)

sndpkt = deliver_data (datos)
make_pkt (número esperado, ACK, chksum) sndpkt = make_pkt (número de secuencia esperado, ACK, chksum)
udt_send (sndpkt)
esperadoseqnum ++
Solo ACK: envíe siempre ACK para el paquete recibido correctamente con la mayor
# de secuencia en orden
• puede generar ACK duplicados
• solo es necesario recordar el número de secuencia esperado
▪ paquete fuera de servicio:
• descartar (no almacenar en búfer): ¡ sin almacenamiento en búfer del receptor!
• re-ACK pkt con el número de secuencia en orden más alto
Página 143
Remitente TCP (simplificado)

datos recibidos de la aplicación anterior
crear segmento, seq. #: NextSeqNum
pasar segmento a IP (es decir, "enviar")
NextSeqNum = NextSeqNum + longitud (datos)
si (el temporizador no está funcionando actualmente)
□ iniciar temporizador
NextSeqNum = InitialSeqNum Espere
SendBase = InitialSeqNum
por
evento se acabó el tiempo
retransmitir segmento aún no respondido
con la menor seq. #
iniciar temporizador
ACK recibido, con valor de campo ACK y
if (y> SendBase) {
SendBase = y
/ * SendBase – 1: último byte ACK de forma acumulativa * /
si (actualmente hay segmentos que aún no se han respondido)
iniciar temporizador
si no, detén el temporizador
}
Página 144
FSM de protocolo de enlace de 3 vías TCP

cerrado
Conexión de enchufe
welcomeSocket.accept ();
□ Socket clientSocket =
newSocket ("nombre de host", "número de puerto");
SYN (x)
SYNACK (seq = y, ACKnum = x + 1) SYN (seq = x)
crear un nuevo enchufe para la comunicación
volver al cliente
escucha
SYN
SYN enviado
rcvd
SYNACK (seq = y, ACKnum = x + 1)
ESTAB
ACK (ACKnum = y + 1) ACK (ACKnum = y + 1)
□
Página 145
Cerrar una conexión TCP

estado del cliente estado del servidor
ESTAB ESTAB
clientSocket.close ()
FIN_WAIT_1 no puedo más FINbit = 1, seq = x
enviar pero puede
recibir datos CLOSE_WAIT
ACKbit = 1; ACKnum = x + 1
todavía puede
FIN_WAIT_2 espera al servidor enviar datos
cerrar
LAST_ACK
FINbit = 1, seq = y
TIMED_WAIT no puedo más
enviar datos
ACKbit = 1; ACKnum = y + 1
espera cronometrada
para 2 * máx. CERRADO
vida útil del segmento
CERRADO
Página 146
Rendimiento de TCP
▪ prom. Thruput de TCP en función del tamaño de la ventana, RTT?
• ignore el inicio lento, suponga que siempre hay datos para enviar
▪ W: tamaño de la ventana (medido en bytes) donde ocurre la pérdida
• prom. el tamaño de la ventana (# bytes en vuelo) es ¾ W
• prom. thruput es 3 / 4W por RTT
3 W
Promedio TCP Thruput = bytes / seg
4 RTT
W
W/2
Página 147
TCP sobre "tuberías largas y gruesas"

▪ ejemplo: segmentos de 1500 bytes, RTT de 100 ms, desea un rendimiento de 10 Gbps
▪ requiere W = 83,333 segmentos en vuelo
▪ rendimiento en términos de probabilidad de pérdida de segmento, L [Mathis 1997]:
. MSS
Rendimiento de TCP = 1,22
RTT L
➜ para lograr un rendimiento de 10 Gbps, necesita una tasa de pérdida de L = 2 · 10-10 - a

tasa de pérdida muy pequeña!
▪ versiones de TCP para escenarios largos y de alta velocidad

Capa de Transporte - Descripción General

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capa de Transporte - Descripción General

Cargado por

Copyright:

Formatos disponibles

Página 1

Capa de transporte: descripción general

Capa de transporte: 3-1

Capa de transporte: hoja de ruta

Servicios y protocolos de transporte

▪ proporcionar comunicación lógica

en segmentos , pasa a la capa de red red domestica contenido

▪ dos protocolos de transporte disponibles para enlace de datos

Aplicaciones de internet empresa

Transporte frente a servicios y protocolos de capa de red

Capa de transporte: 3-4

Transporte frente a servicios y protocolos de capa de red

▪ capa de red: lógica analogía del hogar:

Acciones de la capa de transporte

valores de los campos de encabezado

Capa de transporte: 3-6

Acciones de la capa de transporte

Capa de transporte: 3-7

Dos protocolos principales de transporte de Internet

▪ TCP: Protocolo de control de transmisión red

• garantías de demora empresa

Capítulo 3: hoja de ruta

transporte la red transporte

la red Enlace la red

Capa de transporte: 3-10

transporte la red transporte

la red Enlace la red

Capa de transporte: 3-11

Capa de transporte: 3-12

transporte la red transporte

Capa de transporte: 3-13

la red Enlace la red

Capa de transporte: 3-14

mulfiplexado en el remitente: demulfiplexación en el receptor:

solicitud P1 P2 solicitud enchufe

la red Enlace la red

Capa de transporte: 3-15

números para dirigir el segmento a

Capa de transporte: 3-16

Demultiplexación sin conexión

Demultiplexación sin conexión: un ejemplo

puerto de origen: 6428 Puerto de origen: ?

puerto de origen: 9157 Puerto de origen: ?

Capa de transporte: 3-18

Demultiplexación orientada a la conexión

Demultiplexación orientada a la conexión: ejemplo

anfitrión: IP IP de origen, puerto: B, 80 anfitrión: IP

Tres segmentos, todos destinados a la dirección IP: B,

Capa de transporte: 3-21

Capítulo 3: hoja de ruta

UDP: Protocolo de datagramas de usuario

UDP: Protocolo de datagramas de usuario

Capa de transporte: 3-24

UDP: acciones de la capa de transporte

Cliente SNMP Servidor SNMP

red (IP) red (IP)

Capa de transporte: 3-25

UDP: acciones de la capa de transporte

Cliente SNMP Servidor SNMP

Capa de transporte: 3-26

UDP: acciones de la capa de transporte

Cliente SNMP Acciones del receptor UDP: Servidor SNMP

Capa de transporte: 3-27