Tema 3 y 4 Transporte UDP TCPv1

Temas 3 y 4 Capa de transporte UDP y TCP
Para qu sirve?
2
La capa de transporte
Objetivos
3
Comprender los servicios que puede ofrecer la capa de transporte:
Multiplexacin/demultiplexacin lgica
Transferencia de datos fiable
Control de flujo
Control de congestin
Conocer los protocolos de transporte usados en Internet:
UDP: no orientado a conexin

TCP: orientado a conexin
Control de congestin en TCP
Contenidos
4
1.
2.
3.
4.
5.
6.
La capa de transporte y sus servicios

Multiplexacin y demultiplexacin
Transporte sin conexin: UDP
Transporte orientado a la conexin: TCP
Principios del control de congestin
Mecanismo de control de congestin de TCP
Servicios de transporte
5
Protocolo de la capa de transporte:
Protocolo de la capa de red:
Proporciona comunicacin lgica entre procesos que

se ejecutan en hosts diferentes
application
transport
network
data link
physical
Proporciona comunicacin lgica entre hosts
El protocolo de transporte corre en sistemas

finales
Transmisor: trocea (si es necesario) los
mensajes de aplicacin en segmentos, que
pasa a la capa de red
Receptor: reensambla (si es necesario)
segmentos en mensajes, que pasa a la
capa de aplicacin
application
transport
network
data link
physical
Protocolos de transporte en Internet
Ms de un protocolo de transporte disponible
Internet: TCP y UDP
Fiable y entrega en orden (TCP)
Control de congestin
Control de flujo
Gestin de conexin
No fiable y sin garantas de orden: UDP
Otros nuevos adicionales ms recientes
Extensin del modelo de IP basado en besteffort
Servicios no disponibles en TCP y UDP:
Garanta de retardo
Garanta de ancho de banda
Garanta de seguridad
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Contenidos
7
1.
2.
3.
4.
5.
6.
7.
La capa de transporte y sus servicios

Multiplexacin y demultiplexacin
Transporte sin conexin: UDP
Principios de un servicio de transferencia de datos fiable
Transporte orientado a la conexin: TCP
Requisitos direccionamiento
8
Se requieren tres niveles de direccionamiento:
Cada host necesita una direccin de red nica
Identificar el protocolo de transporte.
Direccin IP: gestionada por la capa de red

Se indica en la cabecera de IP.
Cada proceso necesita un direccin nica dentro del equipo
Puerto: la capa de transporte ofrece esa multiplexacin/demultiplexacin.

SAP en nomenclatura OSI.
Aplicacin
1
Transporte
TCP
UDP
Red
17
Nmero
de Puerto
Direccin
de Protocolo
IP
Multiplexacin/Demultiplexacin
9
La capa de transporte:
Recoge datos de distintos procesos en un equipo origen: Multiplexa.
Los entrega a otros procesos en equipo(s) destino: Demultiplexa.
Distintos procesos en un mismo equipo pueden necesitar un

mismo protocolo de transporte (ej: DNS y TFTP)
Para distinguir procesos cada entidad de transporte usa nmeros de

puerto.
Well-known ports
Ephemeral ports
Multiplexacin/Demultiplexacin
10
Multiplexacin en el emisor:
Demultiplexacin en el receptor:
Datos de mltiples sockets
Entrega de segmentos
al socket correcto
= proceso
= socket
application
P3
P1
P1
application
P2
P4
application
transport
transport
transport
network
network
network
link
link
link
physical
host 1
physical
host 2
physical
host 3
Cmo funciona la demultiplexacin

11
La capa de red recibe datagramas IP

Cada datagrama tiene direccin IP
origen y direccin IP destino
Cada datagrama puede contener un
segmento de la capa de transporte
Cada segmento tiene un nmero de
puerto origen y un nmero de puerto
destino
Los hosts usan las direcciones IP y
nmeros de puerto para entregar el
segmento al socket apropiado
32 bits
Nm. Puerto Origen
Nm. Puerto Destino
Otros campos de cabecera
Datos de Aplicacin
(mensaje)
Formato general del

segmento TCP/UDP
Demultiplexacin en UDP
12
Socket UDP se identifica por: (dir IP destino, puerto destino)

Cuando un host recibe un segmento UDP:
Datagramas IP con diferente IP y/o nmero de puerto origen, son

dirigidos al mismo socket si coinciden:
Comprueba el nmero de puerto destino

Dirige el segmento UDP al socket con ese nmero de puerto
Direccin IP destino
Puerto destino
Para qu enviar direccin y puerto origen?
Para un posible retorno

Demultiplexacin en UDP
13
DatagramSocket serverSocket = new DatagramSocket(6428);
P2
PO: 6428
PD: 9157
Cliente
IP: A
P1
P1
P3
PO: 9157
PD: 6428
PO: Puerto Origen

PD: Puerto Destino
PO: 6428
PD: 5775
Servidor
IP: C
PO: 5775
PD: 6428
Cliente
IP:B
PO proporciona la posibilidad de un camino de retorno

Demultiplexacin en TCP
14
Socket TCP identificado por 4

valores:
Dir IP origen
Puerto origen
Dir IP destino
Puerto destino
El host servidor puede soportar varios

sockets simultneamente:
Cada socket identificado por sus 4 valores
El host receptor usa estos 4

valores para dirigir el mensaje al
socket adecuado
Demultiplexacin en TCP
15
Correspondencia uno a uno entre procesos y sockets

P1
P4
P5
P2
P6
P1P3
PO: 5775
PD: 80
IP_O: B
IP_D:C
Cliente
IP: A
PO: 9157
PD: 80
IP_O: A
IP_D:C
Servidor
IP: C
PO: 9157
PD: 80
IP_O: B
IP_D:C
Cliente
IP:B
IP_O: Direccin IP Origen

IP_D: Direccin IP Destino
16
Demultiplexacin en TCP basada en hilos

Correspondencia uno a varios entre proceso y sockets
P1
P2
P4
P1P3
PO: 5775
PD: 80
IP_O: B
IP_D:C
Cliente
IP: A
PO: 9157
PD: 80
IP_O: A
IP_D:C
Servidor (Web)
IP: C
PO: 9157
PD: 80
IP_O: B
IP_D:C
Cliente
IP:B
17
La capa de Transporte
Transporte sin conexin: UDP (User Datagram Protocol)
UDP en la pila de protocolos IP
Uso de Puertos UDP

FTP
p1
TELNET
p2
FTP
...
p1
p3
Router
UDP (TCP
Red (IP)
Red (IP)
Subred 1
TELNET
p2
UDP (TCP
Red (IP)
Subred 2
...
p3
Formato de la PDU de UDP

0
16
31
Puerto origen
Puerto destino
Longitud
Checksum
Datos
RFC 768. STD 6.

Origen y Destino identifican puertos de comunicacin (TFTP, ECHO, USERS,
etc). El primero es opcional (cero si no se usa)
Longitud: en octetos del datagrama completo.
Checksum: cdigo de proteccin frente a errores. Es opcional (0 = no
usado).
Figure 7.20 UDP datagram format: (a) UDP header fields; (b) fields used in pseudo header
for computation of checksum (Ref. Fred Halsall. Redes de Comp. e Internet)
Clculo de checksum
El Checksum se calcula sobre los siguientes campos:
Datagrama UDP
Direcciones IP de origen y destino
Cdigo de tipo de protocolo de UDP segn IP
Longitud del datagrama UDP
Se necesita saber la direccin IP origen, por lo que hay

que interactuar con la entidad IP antes de enviar el
datagrama.
User Datagram Protocol (UDP)
Servicio sin conexin segn RFC 768

Ultrasimplificado
Servicio no fiable
Sin entrega garantizada
Sin control de paquetes duplicados
Sobrecarga mnima
Aplicaciones:
Recepcin de datos
Diseminacin de datos
Peticin-respuesta simple (conexin controlada en aplicacin)
Tiempo real (voz, multimedia,)
24
Transporte orientado a conexin: TCP
25
Tema 3: La capa de Transporte

3.1 La capa de Transporte y sus servicios
3.2 Multiplexaccin y demultiplexacin
3.3 Transporte sin conexin: UDP
3.5 Transporte orientado a conexin: TCP
3.5.1 La conexin TCP
3.5.2 Estructura del segmento TCP
3.5.3 Estimacin del tiempo de ida y vuelta y fin de temporizacin
3.5.4 Transferencia de datos fiable
3.5.5 Control de flujo
3.5.6 Gestin de la conexin TCP
3.6 Principios de control de congestin
3.7 Mecanismo de control de congestin de TCP
26
TCP: Transmission Control Protocol
Especificado en varias RFC:

RFCs 793, 1122, 1323, 2018, y 2581
Protocolo de la capa de Transporte

Orientado a conexin
Provee control de flujo y control de congestin
Fiable
En base a los principios bsicos
Deteccin de errores
Retransmisiones
Asentimientos acumulativos
Nmeros de secuencia
Temporizadores
27
TCP: La conexin TCP
Orientado a conexin
Los procesos de Aplicacin, en sistemas finales, primero deben
establecer-acordar la comunicacin
Intercambio de segmentos especiales para establecer parmetros para transferencia

de datos
Las partes (Cliente y Servidor) inician diferentes variables de estado para TCP
Los sistemas intermedios (Routers, etc) son TOTALMENTE

TRANSPARENTES a la conexin TCP
No mantienen estados de la conexin TCP
28
TCP: La conexin TCP
Conexin TCP
Full-duplex Bidireccional simultnea
De flujo de octetos NO estructurados Flujo de octetos, NO de mensajes
Punto a punto
No posibilita multidifusin ni difusin
Acuerdo en tres fases (three-way handshake)
Intercambio de tres segmentos especiales para el acuerdo lgico
Concluye con el establecimiento de las variables de estado y capacidades en buffers
Los dos primeros segmentos No portan datos de la capa de Aplicacin

Tercer segmento Puede portar datos de la capa de Aplicacin
En ambos procesos TCP en sistemas finales
Conlleva un retardo intrnseco para la transferencia de datos

29
TCP: La conexin TCP
Conexin TCP establecida
Proceso Cliente pasa datos a la capa TCP
TCP transfiere segmentos que contienen PDUs de la capa de Aplicacin

Segn su propia conveniencia. La especificacin TCP es vaga en este sentido
Buffers TCP Introducen cierto retardo

Ver applet que muestra animacin de los buffers TCP emisor y receptor
Cliente
http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/flow/FlowControl.htm
Servidor
Toda conexin TCP requiere en

Emisor y Receptor:
Buffers
Variables
Socket de conexin a un proceso
30
TCP: La conexin TCP
MSS: Maximum Segment Size

Cantidad mxima de datos que puede portar el segmento TCP
Depende del tamao de la MTU, segn:
Trama ms grande que puede ensamblar el Emisor, y

Trama ms grande que puede enviarse entre Emisor y Receptor a travs de todos los
enlaces entre origen y destino
Hay mtodos para determinar la MTU del trayecto y establecer el MSS en

correspondencia
Garanta de que el segmento TCP se ajuste a una nica

trama (PDU2)
31
TCP: Estructura del segmento TCP
Cabeceras obligatorias
20 octetos
Cabeceras opcionales
Longitud variable
Para chequear la
integridad del
segmento.
Se calcula igual
que en UDP
Cuerpo MSS
28
31
32
33
34
35
36
39
TCP: Estructura del segmento TCP. Cabeceras
32
Puertos origen y destino (16 bits)

SEQ nbr: N de secuencia (32 bits)
Para transferencia fiable y control de flujo
ACK nbr: N de reconocimiento (32 bits)
HLEN: Longitud de cabecera (4 bits)
Flags: Indicadores (1 bit c/u)
En palabras de 32 bits
Si est vaco 20 octetos
URG, ACK, PSH, RST, SYN, FIN
Ventana de recepcin (16 bits) Para control de flujo

Suma de comprobacin (16 bits) Sobre el segmento completo + Pseudo cabecera
Puntero de datos urgente (16 bits) Para indicar ubicacin (inicio) de datos urgentes
Opciones (es opcional, longitud variable) Normalmente NO presente
33

Indicadores (flags)
ACK
SYN, FIN, RST
Para establecimiento, cierre y rechazo (o reinicio) de conexiones
PSH
Indica que el valor del campo N de Reconocimiento es vlido
Para indicar al Receptor* que pase los datos de inmediato a la capa

superior
URG
Para indicar que el segmento tiene datos que han sido marcados como
urgentes por la capa superior Campo Puntero de datos urgente vlido
34
Nmero de secuencia
Indica el N del primer octeto del segmento, respecto al flujo total de octetos
Indica lo que se enva
Nmero de reconocimiento
Indica el N de secuencia del siguiente octeto que se espera recibir
Indica lo que se espera recibir
Ambos SIEMPRE presentes en TODO segmento TCP

Hacen referencia al flujo de octetos, NO a los segmentos
TCP percibe los datos como un flujo de octetos NO estructurado y ordenado
Eleccin de los N de secuencia

De manera aleatoria por ambas partes de la conexin
Para minimizar posibilidad de coincidencia con segmentos antiguos que estn en la red
Ver caso de estudio con Telnet (pginas 234 - 236)

35
TCP: Estructura del segmento TCP
Reconocimientos acumulativos
TCP slo confirma (reconoce) hasta el primer octeto que falta en el flujo
Qu hace un Host cuando NO recibe los segmentos en orden?

Las especificaciones TCP no establecen nada al respecto
Queda a decisin de los implementadores
Opciones bsicas:
Receptor descarta segmentos que no lleguen en secuencia
Se simplifica el diseo del Receptor
Receptor acepta segmentos fuera de secuencia, los almacena en el buffer en espera de

los faltantes
Solucin ms eficiente respecto a uso del ancho de banda

Solucin normalmente utilizada en la prctica
36
TCP: Estimacin del RTT y fin de temporizacin
Cmo TCP se recupera ante la prdida de segmentos?

Con procedimientos ARQ y Temporizadores
Gestin de Temporizadores en TCP (RFC 2988)

En base al valor del RTT Timeout > RTT
RTT varia para cada segmento Se calculan RTTs estimados
RTTestimado = (1 )RTTestimado + RTTmuestra
RTTdesv: estimacin de cunto se desva RTTmuestra de RTTestimado
Se recomienda = 0,125 = 1/8

RTTestimado = 0,875RTTestimado + 0,125RTTmuestra
RTTdesv = (1- )RTTDesv + |RTTmuestra RTTestimado|
Se recomienda = 0,25 = 1/4
RTTdesv = (1- )RTTDesv + |RTTmuestra RTTestimado|
Timeout = IntervaloFinTemporizacin = RTTestimado + 4RTTdesv

37
TCP: Estimacin del RTT y fin de temporizacin
RTTmuestra y RTTestimado para una conexin TCP entre EE.UU. y Francia

RTTestimado = 0,875RTTestimado + 0,125RTTmuestra
RTTmuestra: tiempo que transcurre
desde que se pasa el segmento a la
capa IP (se enva), hasta que se recibe
su reconocimiento
RTTestimado: valor promedio de los
valores RTTmuestra
Alfa = = 1/8 = 0,125
Nuevo valor RTTmuestra cada RTT segundos aproximadamente

38
TCP: Transferencia de datos fiable
La gestin de Temporizadores Carga de trabajo
En consecuencia, para TCP la RFC 2988 recomienda:
Puede ser considerable

Un nico* Temporizador de retransmisin
Independientemente del N de segmentos pendientes de ser reconocidos*
Sucesos importantes en el Emisor TCP, relativos a la transmisin y

retransmisin de datos, son:
Datos recibidos desde la Aplicacin

Fin de la temporizacin (Timeout)
Recepcin de ACKs
39

Sucesos importantes en el Emisor TCP (versin simplificada)
Datos recibidos desde la Aplicacin

TCP lo encapsula en un segmento, y lo pasa a la capa IP
Si el Temporizador NO est iniciado Se inicia el Temporizador
Fin de temporizacin
TCP retransmite segmento asociado a dicha temporizacin*
Se reinicia el Temporizador
Recepcin de un segmento con ACK vlido

Compara el valor ACK y con la variable BaseEmision
BaseEmision = N de secuencia ms antiguo pendiente de ACK
Si y > BaseEmision El ACK confirma uno, o ms segmentos anteriores NO reconocidos
Se actualiza la variable BaseEmision

Si hay segmentos an NO reconocidos Se inicia el Temporizador
40
Escenario posible
TCP espera
ACK = 100
Duplicado,
TCP lo
descarta
41
Escenario posible
Inicio del
Temporizador para
N de Sec = 100
Fin del
Temporizador para
N de Sec = 100
42
Escenario posible
Se eliminan del Buffer

los segmentos con N
de Sec. 92 y 100
Finaliza
Temporizador para
N de Sec = 92
Si hay uno, o ms segmentos

pendientes de ACK, se reinicia
el Temporizador para el ms
antiguo
43

Duplicacin del Timeout
Modificacin utilizada en la mayora de implementaciones TCP cuando

vence el Temporizador
Cada vez que TCP retransmite, redefine el Timeout
Nuevo Timeout = 2 veces Timeout anterior
NO se obtiene el Timeout a partir de RTTestimado + 4RTTdesv

Los Timeout crecen exponencialmente despus de cada retransmisin
Se posibilita una forma limitada de control de congestin
Posibilita actuacin consciente de TCP frente a congestiones de red
Aumenta los intervalos de retransmisin, evitando empeoramiento de la congestin
En los otros dos casos, recepcin de datos de Aplicacin y ACK:
Nuevo Timeout = RTTestimado + 4.RTTdesv

44

Retransmisin Rpida
Solucin frente a problemas derivados de retransmisiones por vencimiento

del Timeout
El Timeout puede ser grande Se retarda la retransmisin Aumenta retardo entre
Sistemas Finales
Solucin ACK duplicados (NAK implcitos)

ACK duplicados respecto al ltimo octeto de datos recibido en secuencia
Posibilitan al Emisor detectar, a menudo, prdida de paquetes antes de que caduque el
Timeout Se reduce tiempo de espera para retransmitir
Si Emisor recibe tres (3) ACK duplicados Asume perdido el segmento que sigue al
segmento reconocido tres veces Emisor realiza una retransmisin rpida antes que
caduque el Timeout del segmento
Ejemplo en la siguiente figura 3.37

45

Ejemplo de Retransmisin Rpida
Segundo segmento, con N de

secuencia 100, se retransmite antes
que caduque su Temporizador
Inicio del
Temporizador para
N de Sec = 100
46

Poltica de generacin de ACKs por el Receptor TCP
Recomendacn segn RFCs 1122 y 2581

Receptor NO descarta segmentos fuera de secuencia
Suceso
Accin del Receptor TCP
Se recibe segmento con N de secuencia esperado. Ns

anteriores ya reconocidos
ACK retardado. Se espera 500 mseg la llegada de otro

segmento en secuencia. Si no llega, se enva ACK
Se recibe segmento con N de secuencia esperado. Hay

otro segmento en orden esperando transmisin de un
ACK
ACK nico acumulativo. Se reconocen ambos

segmentos ordenados
Se recibe segmento fuera de secuencia, con N mayor

que el esperado. Se detecta un hueco
ACK duplicado. Se enva de inmediato ACK con N de

secuencia del siguiente octeto esperado (lmite inferior
del hueco)
Se recibe segmento que completa parcial o totalmente

hueco en los datos recibidos
ACK inmediato. Se enva de inmediato ACK si el

segmento comienza en el lmite inferior del hueco
47

TCP: Retroceder N (GBN) o Repeticin Selectiva (SR)?
TCP utiliza reconocimientos acumulativos

Segmentos bien recibidos, pero fuera de secuencia, NO se reconocen de
manera individual por el Receptor TCP
Emisor slo necesita mantener los Ns BaseEmision y SigNumSec (ver Fig. 3.19)
Muchas implementaciones TCP almacenan en el buffer del Receptor

segmentos fuera de secuencia
TCP provee retransmisin selectiva*
Por tanto, el procedimiento TCP para recuperacin de errores puede ser
considerado una solucin HBRIDA entre GBN y SR
48
TCP: Control de flujo
Procedimiento TCP para frenar regular la velocidad de

transmisin de datos
Servicio de adaptacin de velocidades entre Emisor y Receptor
Objetivo No desbordar el buffer del Receptor TCP

El proceso de Aplicacin NO lee los datos del buffer en el instante de
llegada, hay cierta demora mayor o menor
Importante
Control de flujo NO ES LO MISMO que control de la congestin, si bien
ambos conllevan a frenar al Emisor
Se aplican por razones diferentes
49

Procedimiento TCP para control de flujo
Se supone descarte de segmentos fuera de secuencia

Receptor gestiona un buffer de recepcin
Emisor conoce valor de la variable ventana de recepcin
Ventana de recepcin
Variable que conoce Emisor TCP
Proporciona informacin del espacio libre en el buffer del Receptor
Tamao del buffer = BufferRecepcion

Variables asociadas al buffer:
UltimoByteLeido
UltimoByteRecibido
50

UltimoByteRecibido UltimoByteLeido BufferRecepcion
VentanaRecepcion = BufferRecepcion [UltimoByteRecibido UltimoByteLeido]
VentanaRecepcion Variable dinmica, vara en el tiempo
51

Variable VentanaRecepcion y Control de Flujo

Receptor notifica espacio libre en su buffer mediante el campo ventana de
recepcin en cada segmento que transmite 8
Receptor inicialmente establece:
VentanaRecepcion = BufferRecepcion
Emisor
Controla las variables UltimoByteEnviado y UltimoByteReconocido
UltimoByteEnviado UltimoByteReconocido = Cantidad de datos NO reconocidos
Garantiza, para todo el tiempo de vida de la conexin TCP:
UltimoByteEnviado UltimoByteReconocido VentanaRecepcion
52

Procedimiento TCP para control de flujo: PROBLEMA
Si Receptor:
Buffer lleno VentanaRecepcion = 0 Se notifica al Emisor
NADA que enviar Proceso de Aplicacin saca datos del buffer, pero NO enva
segmentos al Emisor (ni siquiera ACKs)
Emisor NO es informado de la disponibilidad de espacio en el buffer del Receptor
Emisor bloqueado, NO enva datos
SOLUCIN
Cuando Emisor conoce que el Receptor tiene lleno el buffer (VentanaRecepcion = 0)
NO se envan segmentos con nuevos valores VentanaRecepcion
Debe continuar enviando segmentos con slo un octeto de datos

Estos segmentos sern reconocidos por el Receptor Emisor ser notificado cuando el
Receptor disponga de espacio libre en su buffer Emisor NO queda bloqueado
Ver Applet que ilustra funcionamiento de la ventana de recepcin en:

http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/flow/FlowControl.htm
53
TCP: Gestin de la conexin
Gestin de conexin Control del establecimiento y terminacin

de la conexin TCP
Tras este procedimiento subyacen dos cosas muy importantes
Puede aumentar SIGNIFICATIVAMENTE el retardo entre sistemas finales

Muchos de los ataques de red ms comunes explotan las vulnerabilidades intrnsecas
de la gestin de conexin TCP
Establecimiento de la conexin TCP
Tres pasos Tres fases Tres segmentos especiales (de control)

Acuerdo en tres fases
Terminacin de la conexin TCP
Cuatro pasos Cuatro fases Cuatro segmentos especiales (de control)
54

Pasos para establecer una conexin TCP
Paso 1
Cliente
Selecciona de manera aleatoria el N de secuencia inicial (cliente_nsi)
Requiere procedimiento apropiado para evitar ciertos ataques de seguridad
Enva segmento SYN
Campo N de secuencia = cliente_nsi

Indicador SYN activado SYN = 1 Informacin de control
Indicador ACK desactivado ACK = 0
NO contiene datos
55

Paso 2
Servidor
Recibe segmento SYN

Asigna buffer y variables a la conexin
Vulnerabilidad (ataque denegacin de servicio)
Enva segmento conexin aceptada (Segmento SYN-ACK)
NO contiene datos
Contiene informacin de control
(nsi = nmero de secuencia inicial)
Campo N de secuencia = nsi_servidor (seleccionado de manera aleatoria)
Campo N de reconocimiento = nsi_cliente + 1
Indicador SYN activado SYN = 1
Indicador ACK activado ACK = 1
56

Paso 3
Cliente
Recibe segmento SYN-ACK

Asigna buffer y variables a la conexin
Enva segmento reconocimiento de conexin aceptada
Contiene informacin de control

Campo N de reconocimiento = servidor_nsi + 1
Indicador SYN desactivado SYN = 0
Indicador ACK activado ACK = 1
Puede contener datos
57
Pasos para establecer una

conexin TCP*
Acuerdo en tres fases
Parte que inicia la conexin
acta como Cliente
Una vez establecida la
conexin, las partes pueden
intercambiar datos mediante
segmentos de datos
En el mismo segmento con ACK

Indicador SYN = 0
58

Pasos para cerrar una conexin TCP
Paso 1
Parte que inicia
Paso 2
La otra Parte
Enva (devuelve) segmento ACK
Paso 3
La otra parte
Enva segmento FIN Indicador FIN activado FIN = 1
Enva segmento FIN Indicador FIN activado FIN = 1
Paso 4
Parte que inici
Enva (devuelve) segmento ACK
59
Pasos para cerrar una

conexin TCP
Cualquiera de las partes puede
cerrar la conexin
Conexin terminada:
Se liberan recursos utilizados
Buffer y variables
Ns de puerto
Tiempo de espera* por si

hay que re-enviar el ACK.
Timeout dependiente de la
Aplicacin. Valores tpicos:
30, 60 y 120 segundos
Los Ns de Secuencia se
utilizan igual que en la fase de
establecimiento de la conexin
60

Estados TCP en el lado Cliente. Lado Cliente inicia el cierre de la conexin
Este diagrama slo muestra el
establecimiento y cierre normal
de una conexin TCP.
Otros escenarios ms complejos
se pueden presentar en la
prctica. Ver fuente sugerida en
el libro de texto (pgina 252).
Este diagrama corresponde con
la figura 3.40 del libro de texto,
donde se muestran
explcitamente los cuatro pasos
para el cierre de la conexin TCP
61

Estados TCP en el lado Servidor. Lado Cliente inicia el cierre de la conexin
Este diagrama slo muestra el
establecimiento y cierre normal
de una conexin TCP.
Otros escenarios ms complejos
se pueden presentar en la
prctica. Ver fuente sugerida en
el libro de texto (pgina 252).
Este diagrama corresponde con
la figura 3.40 del libro de texto,
donde se muestran
explcitamente los cuatro pasos
para el cierre de la conexin TCP
Diagrama de
Estados de
TCP
Estados
LISTEN: A la espera de peticiones de conexin

SYN-SENT: A la espera de confirmacin de peticin del otro extremo tras
enviar una peticin de conexin.
SYN-RECEIVED: A la espera de ACK tras haber enviado y recibido peticin
(SYN)
ESTABLISHED: Conexin establecida. Estado de transferencia de datos
FIN-WAIT-1 : A la espera de peticin remota de terminacin o asentimiento
de la peticin de terminacin enviada.
FIN-WAIT-2 : A la espera de peticin de terminacin del extremo remoto.
CLOSE-WAIT: A la espera de peticin de terminacin del usuario local
CLOSING: A la espera de asentimiento remoto a peticin de terminacin
de conexin.
LAST-ACK A la espera de asentimiento de la peticin de terminacin de
conexin previamente enviada al TCP remoto, lo que incluye asentmiento
de su peticin de terminacin de conexin
TIME-WAIT: Espera del tiempo suficiente para asegurar que el TCP
remoto recibi el asentimiento a su peticin de terminacin
CLOSED : Conexin eliminada
Establecimiento de conexin
Establecimiento
normal (Cl-S)
Conexin
simultnea
(colisin)
Three Way
Handshake:
Diagrama de
estados
completo
66
Indicador RST de la cabecera TCP
Se utiliza en el segmento especial de reinicio

Indicador RST activado RST = 1
Para indicar cosas como:
No existe socket activo para la direccin IP o puerto origen de la solicitud*

Servidor NO est escuchando por el puerto al que el Cliente enva segmento SYN
Reiniciar conexin cuando se han producido errores o cada de la conexin
El empleo de nmeros de secuencia en

SYN y ACK evita errores de
establecimiento debidos a SYNs y ACKs
retrasados
El nmero de
secuencia permite
identificar la
conexin fallida a
resetear
Liberacin de conexin
Liberacin ordenada e independiente por cada uno de

los sentidos de transmisin.
El extremo que desea cesar de transmitir enva
segmento con FIN (como un octeto ms), que debe ser
confirmado por el corresponsal con FIN, ACK.
Para liberar de forma destructiva se emplea el bit RST.
No se confirma.
Cierres de conexin
Normal
3 vas
Simultneo
Cierre de tres vas:
Partido
estados TCP izquierdo derecho
Recuperacin de fallos
Si se produce restart en uno de los dos sistemas, se pierde la informacin de estado y las
conexiones activas
Quedan las conexiones medio abiertas (en el lado que no ha cado)
Se cierran mediante temporizador Keepalive
Esperar ack tras varias retransmisiones del segmento

Cierra la conexin y notifica a la aplicacin
El lado que ha cado y se recupera puede enviar RSTs al otro para cerrar rpidamente
las conexiones.
El manejo a nivel de aplicacin de la reconexin es resp. del usuario. Peligro de
inconsistencia de datos.
72
73

3.4 Principios de transferencia de datos fiable
3.6 Principios del control de congestin
74
Principios de control de la congestin
Congestin de la red
Desbordamiento de los Buffers de los Routers a consecuencia del
aumento del trfico en la red
Descarte/prdida de paquetes por los Routers TCP responde retransmitiendo

Reduccin del rendimiento ofrecido a las Aplicaciones
Retransmisin de paquetes (mecanismo de fiabilidad)
Se ocupa de un sntoma de la congestin
A veces puede ser peor el remedio que la enfermedad
NO se ocupa de la causa de la congestin
Muchos emisores generando trfico a velocidades mayores que las recomendables en

situaciones concretas
75
Principios de control de la congestin
Retos ante la congestin de la red

Evitacin de la congestin
Procedimientos adecuados para evitar la congestin
Solucin de la congestin
Reaccin adecuada ante la congestin
Procedimientos adecuados para regular el flujo de datos cuando aparezcan sntomas

de congestin
Control de la congestin Evitacin y Solucin
Uno de los problemas ms importantes de las redes de computadores,

junto a la transferencia fiable
76
Mtodos de control de congestin
De manera general, las tcnicas para control de congestin se

pueden clasificar atendiendo a:
La capa de Red NO interviene
Control de congestin terminal a terminal
La capa de Red interviene
Control de congestin asistido por la red
77
Control de congestin terminal a terminal

La capa de Red NO provee soporte explcito a la capa de Transporte
Es el caso de TCP
La congestin tiene que ser inferida por los Sistemas Finales
A partir slo del comportamiento observado de la red, p.e:
Prdida de segmentos TCP

Por vencimiento del Timeout, tres ACKs duplicados
Retardos crecientes
78

Los Routers (capa de Red) proporcionan notificacin explcita al Emisor,
indicando el estado de congestin de la Red
Mediante algn procedimiento de realimentacin al Emisor
Se utiliza, p.e:
En redes ATM, en el mecanismo de control de congestin ABR
ABR: Available Bit-Rate
Propuesto tambin para redes TCP/IP
Bits ECN de cabecera IP
ECN: Explicit Congestion Notification
En la prctica NO se utiliza
79

Dos posibles formas de notificacin explcita al Emisor
Notificacin directa al Emisor desde un Router del trayecto, o
Notificacin indirecta al Emisor desde un Router del trayecto

Router marca/actualiza un campo del paquete de datos que va de Emisor a Receptor
Entonces, Receptor notifica al Emisor Tiempo de notificacin > RTT entre los Sistemas finales
80

81

3.4 Principios de transferencia de datos fiable
3.6 Principios de control de congestin
3.7.1 Equidad
Mecanismos de control de congestin de TCP

82
TCP utiliza control de congestin terminal a terminal

La capa de Red (IP) no provee realimentacin explcita para notificacin de congestin
Emisor TCP regula la velocidad de transmisin de segmentos

En funcin de la congestin de red percibida
No congestin Aumenta velocidad de transmisin

Congestin Reduce velocidad de transmisin
Entonces, en relacin con la lgica TCP, caben tres cuestiones:
Cmo limita TCP la velocidad de transmisin?

Cmo percibe TCP la congestin de la red?
Qu algoritmo utiliza para actuar en consecuencia?
Cmo aprovecha al mximo el ancho de banda sin congestionar?

83
Cmo limita (regula) TCP la velocidad de transmisin?

En base a la variable VENTANA DE CONGESTIN
VENTANA DE CONGESTIN (VC)

Impone restricciones a la velocidad mxima que el Emisor puede operar
Debe ser grande en cada momento, sin llegar a provocar congestin
Valor lmite de la Ventana del Emisor
Ventana del Emisor (VE):
N de octetos que se pueden enviar sin esperar ACKs

Mnimo {Ventana de Congestin, Ventana de Recepcin}
Debe cumplirse, en el Emisor:

(ltimoByteEnviado ltimoByteReconocido) Min {VentanaCongestin, VentanaRecepcin}
N de octetos pendientes de ACKs
Ventana del Emisor


84
SUPUESTOS, para centrarnos en el control de la congestin:

Buffer del Receptor TCP muy grande
No se requiere Control de Flujo
(ltimoByteEnviado ltimoByteReconocido) VentanaCongestin
Emisor siempre tiene datos para enviar
Todos los segmentos de la VentanaCongestin son enviados
No prdida de segmentos y retardo de transmisin despreciable
Velocidad de Transmisin VC / RTT

Ajustando el valor VentanaCongestin Emisor puede ajustar (regular) la
velocidad de transmisin de datos

85
Cmo percibe TCP la congestin?

Mediante el suceso prdida de segmento
Se reduce velocidad de transmisin
A partir del vencimiento del TIMEOUT o tres ACKs duplicados
Cmo percibe TCP la NO congestin?

Se reciben ACKs
Se aumenta tamao de la Ventana de Congestin

Se aumenta velocidad de transmisin
Se reciben ACKs lentamente
Debido a retardos elevados y/o enlaces lentos

Incremento lento de la Ventana de Congestin
Se reciben ACKs rpidamente
Incremento rpido de la Ventana de Congestin
TCP es auto-temporizado
Rapidez de incremento de
la Ventana de Congestin
en funcin de la frecuencia
de los ACKs

86
Resumiendo
TCP utiliza ACKs y sucesos de prdidas de segmentos como indicadores del estado
de la red
Suceso prdida de segmentos: vencimiento Timeout o 3 ACKs duplicados

A la recepcin de ACKs La red est entregando segmentos
Prdida de segmento Congestin
Emisor aumenta la VC Aumenta velocidad de transmisin. Cmo la aumenta?

Emisor reduce la VC Reduce velocidad de transmisin. Cmo la reduce?
Tanteo del ancho de banda: incremento de la VC (la velocidad de transmisin)
Y observa lo que le va llegando
Cada Emisor TCP reacciona a su propia situacin, de manera independiente
Buscando mxima velocidad de emisin sin congestionar la red
Compromiso:
Si emisor transmite demasiado rpido Congestin

Si emisor demasiado cauteloso Infrautilizar recursos
Algoritmo de control de congestin de TCP

87
Estndar RFC 2581

Consta de tres componentes (modos):
Arranque Lento (Slow Start)
Evitacin de la Congestin (Congestion Avoidance)
Obligatorio en TCP
Recuperacin Rpida (Fast Recovery)
Obligatorio en TCP
Recomendable, NO obligatorio en TCP
Arranque Lento y Evitacin de la Congestin

En ambos, incremento del tamao de la Ventana de Congestin
Pero ms rpido en Arranque lento

Algoritmo de control de congestin de TCP: Modos

88
Arranque Lento (AL)
Cuando se inicia la conexin TCP, normalmente:

Umbral: variable de estado TCP, relativa al control de congestin.
Ventana de Congestin (inicial) = VC = 1 MSS

Velocidad de transmisin inicial = Vi MSS/RTT
Por ejemplo:
Valor estimado a partir del cual puede ocurrir congestin

Valor inicial = 64KB
Si MSS = 500 octetos y RTT = 200 mseg.

Vi 20 kbps
Luego:
Valor de la VC se incrementa 1 MSS por cada primer ACK de un segmento
transmitido
Ver ejemplo siguiente (Fig. 3.51)

89
Ejemplo de Arranque Lento TCP

Inicialmente VC = 1 MSS
Se enva primer segmento
Se espera, y se recibe, el primer ACK
Emisor incrementa VC en 1 MSS VC = 2 MSS
Se envan dos segmentos
Se esperan, y se reciben, los dos ACKs
Emisor incrementa VC en 1 MSS por cada ACK

VC = 4 MSS
Se envan cuatro segmentos
Y as sucesivamente
La velocidad de transmisin:
Se duplica por cada perodo RTT

Crece exponencialmente durante la fase de
Arranque Lento
Figure 3.51

90
Arranque Lento (AL)
Cundo finaliza el Arranque Lento, y el incremento exponencial de la

velocidad?
El modo Arranque Lento puede finalizar en cualquiera de las tres situaciones siguientes:
Vencimiento del Timeout
Valor VC = Umbral
Recepcin de tres ACKs duplicados
Vase transparencia siguiente

91
Arranque Lento (AL) finaliza cuando:

Vencimiento del Timeout
Fin de Timeout Segmento perdido Se asume congestin en la red
Emisor TCP:
Redefine e inicializa la variable de estado Umbral, que establece el Umbral de Arranque Lento:
Umbral = 0,5 (Valor VC cuando se detecta congestin)
Establece VC = 1 MSS
Inicia nuevamente el modo Arranque Lento
Valor VC = Umbral
Se asume que la red NO est congestionada, pero podra pronto congestionarse

Se pasa al modo Evitacin de la Congestin
Recepcin de tres ACKs duplicados
Se asume congestin en la red, pero menos severa que por vencimiento del Timeout
Umbral = 0,5 (Valor VC cuando se detecta congestin)
VC = Umbral + 3
Se pasa al modo Recuperacin Rpida

92
Evitacin de la congestin (EC)
Al entrar en el estado Evitacin de la Congestin, se tiene:
VC = 64 KB, si antes NO se detect congestin, o
VC 0,5 [VC cuando se detect congestin por ltima vez]
Se puede estar al borde de la congestin
Entonces, incremento del valor de la VC de la siguiente manera:
Un MSS por cada RTT
(1 / VC) MSS por cada ACK recibido Un MSS cada vez que se recibe un N de ACKs = VC
VC VC + MSS (MSS / VC)
Mtodo ms conservador que el Arranque Lento, NO se duplica la VC
Ejemplo:
Si MSS = 1460 B y VC = 14600 B MSS / VC = 1 / 10

Por cada ACK la VC se incrementa en un valor igual a MSS / 10
Se enviarn 10 segmentos en un RTT
La VC aumenta en un MSS despus de los ACKs de los 10 segmentos

14
Evitacin de la congestin (EC)
Cuando cesa el incremento lineal de la VC (1 MSS por cada RTT)?

Cuando vence el Timeout Prdida de segmento
dem al caso de Arranque Lento
Umbral = 0,5 (VC cuando se produce la prdida del segmento)

Establece VC = 1 MSS
Se pasa al modo Arranque Lento
Cuando se reciben tres ACKs duplicados Prdida de segmento
Pero la red est entregando segmentos, el receptor est recibiendo segmentos, as lo indica la llegada de
ACKs duplicados
Por tanto, TCP se comporta de manera menos drstica que cuando vence el Timeout, y establece:
Umbral = 0,5.(VC cuando se recibieron los tres ACKs)

VC para dos/tres posibles implementaciones:
VC = Umbral + 3 o VC = Umbral (se pasa al modo Recuperacin Rpida), o
VC = 1 MSS (se pasa al modo Arranque Lento)

Y se retransmite el segmento perdido
Ver
diapositiva 16

94
Recuperacin Rpida (RR)

Procedimiento recomendado, NO obligatorio
La VC se incrementa en un MSS por cada ACK duplicado

ACK relativo al segmento que falta, que condujo a entrar al modo RR
Y se transmite un nuevo segmento si lo permite el valor VC
Cuando se recibe el ACK para el segmento que falta, entonces:

Se reduce valor de la VC VC = Umbral
VC VC + MSS
Umbral = 0,5 (VC cuando se produjo la congestin)
Se pasa al modo Evitacin de la Congestin
Cuando vence el Timeout
Umbral = 0,5 (Valor VC cuando vence el Timeout)
Se establece VC = 1 MSS
Se pasa al modo Arranque Lento


16
Ocho primeros ciclos de transmisin
Tahoe y Reno, dem
Umbral inicial: 8 MSS
Hasta el 4 ciclo de transmisin
Del 4 al 8 ciclo de transmisin
A partir del 9 ciclo de transmisin

Tahoe y Reno diferentes
TCP Reno VC cae hasta 9 o 6 MSS. Nuevo Umbral = 6 MSS
VC crece linealmente (lnea ROJA o lnea NEGRA)
TCP Tahoe VC cae hasta 1 MSS. Nuevo Umbral = 6 MSS
VC crece exponencialmente hasta nuevo Umbral
A partir del nuevo Umbral, VC crece linealmente
VC crece exponencialmente (modo AL)

VC crece linealmente (modo EC)
8 ciclo de transmisin, 3 ACKs duplicados
TCP Tahoe
Versin anterior de TCP
3 ACKs duplicados Se pasa al modo AL
TCP Reno
Versin actual y ms utilizada de TCP

3 ACKs duplicados Se pasa al modo RR con
nuevo Umbral
Algoritmo de control de congestin de TCP: Modos-Estados

96
ACK duplicado
ContadorACK++
VC = 1 MSS
umbral = 64 KB
contadorACKdupl = 0
Arranque
lento
Fin Timeout
umbral = VC/2
VC = 1 MSS
contadorACKdupl = 0
Retransmitir Segmento que falta
contadorACKduplicado == 3
ACK nuevo
VC = VC + MSS
ContadorACKdupl = 0
Transmitir seg. nuevo(s) cdo sea posible
VC umbral
Fin Timeout
umbral = VC/2
VC = 1 MSS
contadorACKdupl = 0
Retransmitir segmento que falta
Fin Timeout
umbral = VC/2
VC = 1
contadorACKdupl = 0
ACK nuevo
VC = VC + MSS(MSS/VC)
contadorACKdupl = 0
Transmitir segmento(s) nuevo(s) cuando sea posible
Evitacin
de la
congestin
ACK duplicado
contadorACKdupl ++
Nuevo ACK
VC = umbral
contadorACKdupl = 0
contadorACKdupl == 3
umbral= VC/2
VC = umbral + 3
umbral = VC/2
VC = umbral + 3
Recuperacin
rpida
Figura 3.52
ACK duplicado
VC = VC + MSS
Transmitir segmento(s) nuevo(s) cuando sea posible
Control de congestin TCP: AIMD

97
Supuestos:
Se ignora fase inicial de Arranque Lento, y
Prdida de segmentos slo por recepcin de tres ACKs duplicados
Bajo tales supuestos, se suele plantear que:

Control de congestin TCP es de la forma AIMD:
CRECIMIENTO ADITIVO DECRECIMIENTO MULTIPLICATIVO
AIMD: Additive-Increase, Multiplicative-Decrease
Control de congestin TCP: AIMD

98
Control de congestin TCP AIMD
Aumento lineal del tamao de la VC

Aumento lineal de la velocidad de
transmisin
Comportamiento en forma de diente de sierra
Tres ACKs duplicados

VC 0,5VC
Decrecimiento multiplicativo
Nuevamente crecimiento lineal de la VC
Tanteo para detectar disponibilidad de Figure 3.54

ancho de banda
AIMD de TCP: algoritmo que posibilita optimizar:
Prestaciones a los usuarios, y
Rendimiento de la red
Tasa de transferencia de TCP

99
Ignorando las fases de Arranque Lento (de muy corta duracin):

La velocidad de transmisin en una conexin TCP tiene un comportamiento del tipo
diente de sierra
A largo plazo, y bajo las siguientes suposiciones:
La velocidad de transmisin vara entre W/2.RTT y W/RTT, de manera lineal
La red descarta un paquete cuando la velocidad alcanza el valor W/RTT
W: tamao de VC cuando se produce prdida de un segmento

W y RTT aproximadamente constantes durante la conexin
La velocidad se reduce a la mitad: W/2RTT

A continuacin va aumentando a razn de MSS/RTT cada RTT, hasta que llega nuevamente al
valor W/RTT
Proceso que se repite una y otra vez
Entonces

100
Tasa de transferencia media de TCP
Bajo las consideraciones de la transparencia anterior, se tiene:

TTM-TCP = 0,75 W / RTT
Siendo:
TTM-TCP: Tasa de Transferencia Media de una conexin TCP
W: tamao de VC cuando se produce prdida de un segmento
RTT: tiempo de ida y vuelta
24
Tamao ventana
W
3W/4
W/2

101
Tasa de transferencia media de TCP
Otra frmula para la TTM-TCP, en funcin de los siguientes parmetros:
L: tasa de prdidas
RTT: tiempo de ida y vuelta
MSS: tamao mximo del segmento
TTM -TCP = (1,22 MSS) / (RTTL)
25
Equidad TCP
102
Para que CC-TCP sea equitativo, respecto al reparto del ancho de banda de
un enlace compartido, debe cumplirse:
Para:
K conexiones simultneas, sobre un enlace de velocidad R bps

Que:
Velocidad media de transmisin R/K bps , para cada conexin
Sin embargo, se ha demostrado que:

De manera aproximada, algoritmo AIMD reparte equitativamente el ancho de banda
Pero NO tan equitativamente, pues:
Sesiones con valores menores de RTT abren ms rpido sus VC
Disfrutan de mayor tasa de transferencia

Se apropian ms rpidamente del AB a medida que ste se va liberando en enlaces compartidos
Equidad TCP
103
Ejemplo de equidad de reparto de AB con algoritmo AIMD de TCP

Enlace
cuello de botella
Figure 3.55
Supuestos:
Para cada conexin TCP: MSS, RTT, VC iguales

Misma tasa de transferencia por conexin
Se ignora fase de Arranque Lento
Ambas conexiones operando en modo AIMD
Ninguna otra conexin TCP, ni trfico UDP
Figure 3.56
Enlace cuello de botella, nico enlace:

Congestionado entre sistemas finales para cada conexin
Que limita la velocidad de trasferencia a las Aplicaciones
Equidad TCP
104
Equidad y conexiones TCP en paralelo
Las conexiones TCP en paralelo son, por principio, anti-equitativas

No hay nada que impida a una Aplicacin, basada en TCP, utilizar varias conexiones en
paralelo
Aplicaciones con conexiones TCP en paralelo
Cosa muy comn en los Navegadores Web
Utilizacin de mayor fraccin de AB respecto a otras Aplicaciones mono-conexin

Rompe con la equidad que en principio provee el algoritmo AIMD
Dado que actualmente el trfico Web es dominante en Internet
Es muy comn la utilizacin de mltiples conexiones TCP en paralelo
Equidad UDP
105
En contraste con TCP, UDP no regula la velocidad de transmisin de las

Aplicaciones
Las Aplicaciones sobre UDP emiten a su antojo Nada las frena
No cooperan para repartir equitativamente los recursos disponibles

No reducen la velocidad de transmisin ante situaciones de congestin
Resultado:
UDP NO provee control de congestin
Puede ocurrir que trfico UDP desproporcionado termine por expulsar al trfico TCP
En consecuencia:
Actualmente se investiga en mecanismos de control que impidan al trfico UDP expulsar,

y eventualmente reducir a cero, el trfico TCP en Internet
Algoritmo TCP Vegas

106
Otra variante de algoritmo para control de congestin TCP

Intenta evitar congestin manteniendo una buena tasa de
transferencia
Idea bsica:
Detectar la congestin antes de que se pierda un segmento
Reducir velocidad de transmisin linealmente cuando se supone
prdida inminente de segmentos
Se predice observando el RTT
Mayor RTT Mayor congestin en la red
EPLOGO del Tema 3: La capa de Transporte

107
Todo nuestro estudio de la capa de Transporte se ha basado en UDP y TCP

Protocolos fundamentales en las redes TCP/IP, en particular en Internet
Han demostrado ser suficientemente buenos, pero
Hay situaciones en que ni UDP ni TCP son satisfactorios

Consecuencia:
Se han desarrollado otros protocolos para la capa de Transporte:
RFC 4340
RFCs 2969 y 3286
SCTP: Stream Control Transmission Protocol
RFC 5348
DCCP: Datagram Congestion Control Protocol
TFRC: TCP-Friendly Rate Control
El futuro dir si son aceptados o no


Tema 3 y 4 Transporte UDP TCPv1

Cargado por

Copyright:

Formatos disponibles

Tema 3 y 4 Transporte UDP TCPv1

Cargado por

Información del documento

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

Tema 3 y 4 Transporte UDP TCPv1

Cargado por

Copyright:

Formatos disponibles

Temas 3 y 4 Capa de transporte UDP y TCP

Comprender los servicios que puede ofrecer la capa de transporte:

Conocer los protocolos de transporte usados en Internet:

UDP: no orientado a conexin

La capa de transporte y sus servicios

Protocolo de la capa de transporte:

Protocolo de la capa de red:

Proporciona comunicacin lgica entre procesos que

Proporciona comunicacin lgica entre hosts

El protocolo de transporte corre en sistemas

Protocolos de transporte en Internet

Ms de un protocolo de transporte disponible

Internet: TCP y UDP

Fiable y entrega en orden (TCP)

No fiable y sin garantas de orden: UDP

Otros nuevos adicionales ms recientes

Extensin del modelo de IP basado en besteffort

Servicios no disponibles en TCP y UDP:

Garanta de ancho de banda

La capa de transporte y sus servicios

Se requieren tres niveles de direccionamiento:

Cada host necesita una direccin de red nica

Identificar el protocolo de transporte.

Direccin IP: gestionada por la capa de red

Cada proceso necesita un direccin nica dentro del equipo

Puerto: la capa de transporte ofrece esa multiplexacin/demultiplexacin.

Distintos procesos en un mismo equipo pueden necesitar un

Para distinguir procesos cada entidad de transporte usa nmeros de

Datos de mltiples sockets

Cmo funciona la demultiplexacin

La capa de red recibe datagramas IP

Nm. Puerto Destino

Otros campos de cabecera

Formato general del

Socket UDP se identifica por: (dir IP destino, puerto destino)

Datagramas IP con diferente IP y/o nmero de puerto origen, son

Comprueba el nmero de puerto destino

Para qu enviar direccin y puerto origen?

Para un posible retorno

DatagramSocket serverSocket = new DatagramSocket(6428);

PO: Puerto Origen

PO proporciona la posibilidad de un camino de retorno

Socket TCP identificado por 4

El host servidor puede soportar varios

Cada socket identificado por sus 4 valores

El host receptor usa estos 4

Correspondencia uno a uno entre procesos y sockets

IP_O: Direccin IP Origen

Demultiplexacin en TCP basada en hilos

UDP en la pila de protocolos IP

Uso de Puertos UDP

Formato de la PDU de UDP

RFC 768. STD 6.

El Checksum se calcula sobre los siguientes campos:

Se necesita saber la direccin IP origen, por lo que hay

User Datagram Protocol (UDP)

Servicio sin conexin segn RFC 768

Tema 3: La capa de Transporte

TCP: Transmission Control Protocol

Especificado en varias RFC: