El N
ivel
de
Tra
nsp
orte
en Inte
rnet
2
Sum
ario
�Funcionesdel nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
3
Funci
ones
del
Niv
el d
e Tra
nsp
orte
�Se encarga del transporte de los datos extremo a
extremo (hosta host).
�Realiza la comunicación de form
a transparente al medio
físico. Usa los servicios del nivel de red
�Multiplexatráfico de diversas instancias (procesos) del
nivel de aplicación. El nivel de transporte (como el de
red) tiene una sola instancia en el host
�El servicio que ofrece puede ser de dos tipos:
−Orientado a conexión: garantiza la entrega de los datos,
sin pérdidas ni duplicados. Ej.: TCP (Internet), TP4 (OSI)
−No orientado a conexión: equivale al servicio que ofrece
IP,pero
a nivel de transporte. Ej.: UDP (Internet), TP0
(OSI)
4
�Funcionesdel nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
Sum
ario
5
Pro
toco
lo U
DP
�Servicio sencillo, CLNS, no fiable
�Se utiliza en los siguientes entornos:
−El intercambio de m
ensajes es m
uy escaso,
ej.:consultas al DNS (servidor de nombres)
−La aplicación es en tiempo real y no puede esperar
confirm
aciones. Ej.: videoconferencia, voz sobre IP.
−Los m
ensajes se producen regularm
ente y no
importa si se pierde alguno. Ej: NTP, SNMP
−El medio de transmisión es altamente fiable y sin
congestión (LANs). Ej: NFS
−Se envía tráfico broadcast/multicast
6
Pro
toco
lo U
DP
�Las TPDUsde UDP se denominan m
ensajeso
datagramasUDP
�UDP m
ultiplexalos datos de las aplicaciones y
efectúa opcionalmente una comprobación de
errores, pero no realiza:
−Control de flujo
−Control de congestión
−Retransmisión de datos perdidos
−Conexión/desconexión
32 bits
00010001
Long. DatagramaUDP
00000000
Dirección IP de destino
Dirección IP de origen
Checksum
Puerto de destino
Longitud datagrama
UDP
Puerto de origen
La
cabec
era
UD
P
Pseudocabecera
Cabecera
La pseudocabecerase añade al principio del datagramapara el cálculo del
checksum, pero no se envía. Permite a UDP comprobar que IP no se ha
equivocado (ni le ha engañado) en la entrega del datagrama.
El valor 100012= 1710indica que el protocolo de transporte es UDP
32 bits
Multip
lexa
ción
�La m
ultiplexación se realiza m
ediante el puerto
(origen o destino) que puede valer de 0 a 65535.
�Los puertos 0 a 1023 están reservados para
servidores ‘bien conocidos’(‘well known ports’)
�La combinación de una dirección IP y un puerto
identifica un ‘socket’(origen o destino de los
datagramasUDP): 147.156.135.22.1038
Direcció
n I
PP
uert
o
Socket
CRC
DATAGRAMA IP
Ethertype0800
Nivel de enlace
Nivel de red
Nivel de transporte
Nivel de aplicación
DATAGRAMA UDP
Prot. 17
DATOS APLICACIÓN
P. dest. 13
NTP
(Puerto 123)
DNS
(Puerto 53)
Daytime
(Puerto 13)
Cabecera MAC Ethernet
Cabecera IP
Cabecera UDP
Checksum
Checksum
CRC
Múltiples instancias
(una por interfaz)
Una instancia IP
(puede haber otros
protocolos)
Dos instancias
(TCP y UDP)
Múltiples instancias
(una o varias por
protocolo)
Multip
lexa
ción
Cliente
IP 10.0.1.50
Servidor Daytime
IP 10.0.1.25Port
13
Port
1038
Socket: 10.0.1.25.13
Socket: 10.0.1.50.1038
Conex
ión U
DP
clie
nte
-ser
vidor
Mensaje
UD
P
p.o
. 1038, p.d
. 13
Mensaje
UD
P
p.o
. 13, p.d
. 1038
IP: -----
IP Header-----
IP:
IP: Version=4, header
length=20 bytes
IP: DiffServ
= 00
IP: Total length
= 160 bytes
IP: Identification
= 2015
IP: DF = 0, MF = 0
IP: Fragment
offset
= 0 bytes
IP: Time to live
= 64 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header
checksum
= 7061 (correct)
IP: Source
address
= [128.1.1.10]
IP: Destination
address
= [128.1.1.1]
IP: No options
IP:
UDP: -----
UDP Header
-----
UDP:
UDP: SourcePort = 161 (SNMP)
UDP: Destination
port
= 1227
UDP: Length= 140
UDP: Checksum
= 4D4F (correct)
UDP:
IP: -----
IP Header-----
IP:
IP: Version=4, header
length=20 bytes
IP: DiffServ
= 00
IP: Total length
= 131 bytes
IP: Identification
= 21066
IP: DF = 0, MF = 0
IP: Fragment
offset
= 0 bytes
IP: Time to live
= 60 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header
checksum
= 2A13 (correct)
IP: Source
address
= [128.1.1.1]
IP: Destination
address
= [128.1.1.10]
IP: No options
IP:
UDP: -----
UDP Header
-----
UDP:
UDP: SourcePort = 1227
UDP: Destination
port
= 161 (SNMP)
UDP: Length= 111
UDP: No checksum
UDP:
Cab
ecer
as IP y
UD
P P
etic
ión/Res
pues
ta S
NM
P
Sum
ario
�Funcionesdel nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
TC
P (Tra
nsm
ission
Control P
roto
col)
�El protocolo TCP ofrece el servicio de transporte
orientado a conexión (CONS) en Internet.
�Está
diseñado para ofrecer un transporte fiable
sobre un servicio no fiable del nivel de red (el
que le suministra IP).
�Las TPDUsde TCP se llaman segmentos.
�El TCP actual se especificóen el RFC 793 en
1981 y sigue plenamente vigente.
Ser
vici
o o
rien
tado a
conex
ión
�Los servicios orientados a conexión requieren un
procedimiento explícito de establecimiento y
term
inación de la comunicación.
�Durante la conexión las entidades participantes
mantienen en m
emoria una inform
ación relativa a dicha
conexión (contadores de bytes, espacio libre en buffers,
etc.). Dicha inform
ación se conoce como inform
ación de
estado.
�Para describir los servicios orientados a conexión se
suele utilizar un m
odelo basado en dos protagonistas:
�Cliente: el que inicia la conexión
�Servidor: el que está
a la espera de recibir peticiones de
conexión
�Una conexión puede term
inarse tanto por iniciativa del
cliente como del servidor.
�También hay aplicaciones que utilizan el modelo igual a
igual (peer-to-peer) como Emule, Edonkey, etc.
Funci
ones
de
TC
P
�Multiplexarel nivel de aplicación (port)
�Controlar errores, retransmitiendo segmentos
perdidos o erróneos. Eliminar duplicados
�Establecer y term
inar conexiones
�Gestionar los buffers
y ejercer control de flujo de
form
a eficiente
�Gestionar el intercambio de datos con las
aplicaciones
�Efectuar control de congestión
Fla
gs:
CW
R:
Congestion
Win
dow
Reduced
EC
E:
EC
N E
cho (
EC
N=
Explic
itC
ongestion
Notification)
UR
G:
el segm
ento
contiene d
ato
s u
rgente
s
AC
K:
el cam
po n
úm
ero
de a
cuse d
e r
ecib
o tie
ne s
entido
PS
H:
el segm
ento
contiene d
ato
s ‘P
ushed’
RS
T:
ha h
abid
o a
lgún e
rror
y la c
onexió
n d
ebe c
err
ars
e
SY
N:
indic
a e
l in
icio
de u
na c
onexió
n
FIN
:in
dic
a e
l final de u
na c
onexió
n
La
cabec
era
TC
P
Relle
no
Fla
gs
(8 b
its)
Resv.
(4 b
its)
Punte
ro d
ato
s u
rgente
s
Tam
año v
enta
na
Puert
o d
e d
estino
Opcio
nes
Checksum
L. C
ab.
(4 b
its)
Núm
ero
de
acuse d
e r
ecib
o
Núm
ero
de
secuencia
Puert
o d
e o
rigen
32 b
its
20
byte
s
0000
011
0Long.
Segm
ento
TC
P0000
000
0
Direcció
n I
P d
e d
estino
Direcció
n I
P d
e o
rigen
La
pse
udoca
bec
era
TC
P
32
bits
Se
añ
ad
e a
l p
rincip
io d
el se
gm
en
to s
olo
para
el cá
lculo
de
l
Ch
ecksum
, no se envía. P
erm
ite
a T
CP
com
pro
ba
r qu
e IP
no
se
ha
equ
ivo
ca
do
(n
i le
ha
eng
añ
ado)
en
la e
ntr
ega
de
l se
gm
en
to.
El va
lor
11
02
= 6
10
ind
ica
qu
e e
l pro
toco
lo d
e tra
nsp
ort
e e
s T
CP
Sum
ario
�Aspectos generales del nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
Multip
lexa
ción
�Se utiliza el número de puerto (origen o destino)
como en UDP. Puede valer de 0 a 65535.
�Como en UDP los puertos 0 a 1023 están
reservados para servidores ‘bien conocidos’
�Como en UDP la combinación de dirección IP y
puerto identifica el ‘socket’
�Una conexión TCP queda especificada por los dos
socketsque se comunican (IP origen-puerto
origen, IP destino-puerto destino)
Alg
unos se
rvic
ios ‘b
ien c
onoci
dos’
X38
9L
DA
P
X44
3H
TT
PS
X16
1S
NM
P
X12
3N
TP
X11
0P
OP
3
X80
HT
TP
X69
TF
TP
X67
BO
OT
P
XX
53
Dom
ain
(DN
S)
X25
SM
TP
X23
Te
lNe
t
X22
SS
H
X21
FT
P
XX
13
Da
yT
ime
UDP
TCP
Puerto
Servicio
Nivel de enlace
Nivel de red
Nivel de transporte
Nivel de aplicación
CRC
DATAGRAMA IP
Ethertype(0800)
SEGMENTO TCP
Prot. (6)
DATOS APLICACIÓN
P. dest. (23)
SMTP
(Puerto 25)
Telnet
(Puerto 23)
FTP
(Puerto 21)
Cabecera MAC Ethernet
Cabecera IP
Cabecera TCP
Multip
lexa
ción
Checksum
Checksum
HTTP
(Puerto 80)
HTTP
(Puerto 400)
Múltiples instancias
(una por interfaz)
Dos instancias
(TCP y UDP)
Múltiples instancias
(una o varias por
protocolo)
Una instancia IP
(puede haber otros
protocolos)
Cliente
IP 10.0.1.50
Servidor telnet
IP 10.0.1.25Port
23
Port
1038
Conexión TCP
10.0.1.25.23-10.0.2.47.1038
Port
1038 Cliente
IP 10.0.2.47
Conexión TCP
10.0.1.25.23-10.0.1.50.1038
Socket: 10.0.1.25.23
Socket: 10.0.1.50.1038
Socket: 10.0.2.47.1038
Este sockettiene dos
conexiones simultáneas
Dos co
nex
iones
TC
P m
ism
o P
ort
A un m
ismo socketdesde dos sockets
con el mismo número de puerto
Cliente
IP 10.0.1.80
Servidor
IP 10.0.1.25
Port
23
Socket: 10.0.1.25.23
Socket: 10.0.1.80.1038
Port
1039
Port
1038
Socket: 10.0.1.80.1039
Dos co
nex
iones
TC
P m
ism
o IP
Conexión TCP
10.0.1.25.23-10.0.1.80.1038
Conexión TCP
10.0.1.25.23-10.0.1.80.1039
A un m
ismo socketdesde dos sockets
con la m
isma dirección IP
Netstat-an
Active Internet connections(including
servers)
Proto
Recv-Q Send-Q Local Address
Foreign
Address
(state)
tcp
0 0 147.156.1.25.2480 147.156.1.1.143
ESTABLISHED
tcp
0 0 147.156.1.25.23 147.156.96.8.1034
ESTABLISHED
tcp
0 240 147.156.1.25.23 147.156.1.219.1036
ESTABLISHED
tcp
0 0 147.156.1.25.513 147.156.1.3.1018
ESTABLISHED
tcp
0 0 147.156.1.25.513 147.156.1.3.1019
ESTABLISHED
tcp
0 0 147.156.1.25.2429 147.156.1.15.6000
ESTABLISHED
tCP
0 0 147.156.1.25.2428 147.156.1.15.6000
ESTABLISHED
tcp
0 0 147.156.1.25.1022 147.156.1.3.1002
ESTABLISHED
tcp
0 0 147.156.1.25.514 147.156.1.3.1004
CLOSE_WAIT
tcp
0 0 147.156.1.25.1023 147.156.1.3.1005
ESTABLISHED
tcp
0 0 147.156.1.25.514 147.156.1.3.1007
CLOSE_WAIT
tcp
0 0 147.156.1.25.139 147.156.1.219.1029
ESTABLISHED
tcp
0 0 *.143 *.*
LISTEN
tcp
0 0 *.144 *.*
LISTEN
tcp
0 0 147.156.1.25.23 147.156.3.12.1945
ESTABLISHED
tcp
0 0 *.139 *.*
LISTEN
tcp
0 0 *.5000 *.*
LISTEN
tcp
0 0 *.25 *.*
LISTEN
tcp
0 0 *.19 *.*
LISTEN
tcp
0 0 *.9 *.*
LISTEN
udp
0 0 *.16522 *.*
udp
0 0 *.16520 *.*
udp
0 0 147.156.1.25.123 *.*
udp
0 0 127.0.0.1.123 *.*
udp
0 0 *.123 *.*
Conex
iones
TC
P
(host147.156.1.25
conec
tado p
or te
lnet
des
de
147.
156.
1.21
9)
Sum
ario
�Aspectos generales del nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
�Opciones de TCP
Conex
ión p
or ‘S
aludo a
tre
s ví
as’
�Los segmentos pueden llegar duplicados (p. ej. se
pierde la confirm
ación de un segmento con lo que el
emisor lo reenvía)
�Con un procedimiento de conexión simple los
segmentos duplicados podrían causar problemas. Una
sesión entera podría duplicarse.
�Para evitar los problemas debidos a duplicados lo se
utiliza un procedimiento de conexión m
ás elaborado
denominado saludo a tres vías.
�El saludo a tres vías se basa en la elección de un
número que identifica de form
a única cada intento de
conexión y que actúa como PIN. De este m
odo se evita
el riesgo de aceptar como válidos segmentos retrasados
que pudieran aparecer fruto de conexiones anteriores.
Pro
cedim
iento
del
sal
udo a
tre
s ví
as
1.
El cliente elige para cada intento de conexión un
número único. El número elegido lo incluye en la
petición de conexión que envía al servidor.
2.
El servidor, cuando recibe la petición, elige otro
número único y envía una respuesta al cliente
indicándoselo.
3.
El cliente al recibir la respuesta considera
establecida la conexión. A continuación envía un
tercer mensaje en el que acusa recibo del
anterior. El servidor considera establecida la
conexión cuando el recibe este tercer mensaje.
TCP A
TCP B
←←←←Tiempo
seq=100, SYN
seq=300, ack=101, SYN, ACK
seq=101, ack=301, ACK
Est
able
cim
iento
Conex
ión T
CP
Sal
udo a
tres
vía
s
CLOSED
SYN-SENT
(ISN 100)
LISTEN
SYN-RECEIVED
(ISN 300)
ESTABLISHED
ESTABLISHED
TCP A
TCP B
←←←←Tiempo
seq=100, SYN
seq=300,ack=101,
SYN, ACK
seq=100, ack=301,
SYN,ACK
Sal
udo a
tres
vía
s
Conex
ión sim
ultán
ea
CLOSED
SYN-SENT
(ISN 100)
CLOSED
SYN-RECEIVED
ESTABLISHED
ESTABLISHED
seq=300, SYN
SYN-SENT
(ISN 300)
SYN-RECEIVED
TCP A
TCP B
←←←←Tiempo
seq=100, SYN
seq=300, ack=91, SYN, ACK
seq=91, R
ST
Conex
ión c
on S
YN
duplic
ado
CLOSED
SYN-SENT
(ISN 100)
LISTEN
SYN-RECEIVED
(ISN 300)
LISTEN
seq=90, SYN
seq=100, SYN
SYN-RECEIVED
(ISN 400)
seq=400, ack=101, SYN, ACK
ESTABLISHED
seq=101, ack=401, ACK
ESTABLISHED
SYN
90
SYN-SENT
(ISN 90)
seq=90, SYN
(timeout)
SYN
90 SYN
100
SYN
100
Conex
ión e
n T
CP
�Los dos primeros segmentos de la conexión se
identifican con el flagSYN.
�El número de secuencia es un campo de 32 bits que
cuenta bytes en m
ódulo 2
32 (el contador se da la vuelta
cuando llega al valor máximo).
�El número de secuencia no empieza norm
almente en 0,
sino en un valor denominado ISN (InitialSequence
Number) elegido al azar; el ISN sirve de ‘PIN’en el
saludo a tres vías para asegurar la autenticidad de la
comunicación.
�Una vez establecida la comunicación el ‘seq’y el ‘ack’
sirven para contar los bytes transmitidos y recibidos.
Conex
ión e
n T
CP
�El ISN es elegido por el sistema (cliente o servidor). El
estándar sugiere utilizar un contador entero
incrementado en 1 cada 4 µs aproximadamente. En este
caso el contador se da la vuelta (y el ISN reaparece) al
cabo de 4 horas 46 m
in.
�El MSL (Maximum
SegmentLifetime) típico es de unos 2
minutos, con lo que la probabilidad de que dos ISN
coincidan es despreciable.
�El mecanismo de selección de los ISN es
suficientemente fiable para proteger de coincidencias
debidas al azar, pero no es un m
ecanismo de protección
frente a sabotajes. Es m
uy fácil averiguar el ISN de una
conexión e interceptarla suplantando a alguno de los
dos participantes.
Des
conex
ión
�Puede ser de dos tipos:
�Simétrica: la conexión se considera form
ada por dos
circuitos simplex y cada host solo puede cortar uno
(aquel en el que él emite datos). El cierre de un sentido
se interpreta como una ‘invitación’a cerrar el otro.
�Asimétrica: desconexión unilateral (un hostla term
ina
en ambos sentidos sin esperar a recibir confirm
ación del
otro). Puede provocar pérdida de inform
ación.
Host 1
Host 2
←←←←Tiempo
DATOS
DATOS
DATOS
DR:
DisconnectRequest
Des
conex
ión a
sim
étrica
Conectado
Conectado
No
Conectado
No
Conectado
DR
Datos perdidos
Men
saje
de
Des
conex
ión
�EL m
ensaje solicitando la desconexión se puede
perder. Por eso se pide una confirm
ación (ACK).
�Pero la confirm
ación también podría perderse,
por lo que habría que enviar una reconfirm
acion,
y asísucesivamente.
�Este problema no tiene solución infalible, pues
estamos usando un canal no fiable para asegurar
un envío de inform
ación. Es lo que se conoce
como el problema de los dos ejércitos.
Des
conex
ión p
or sa
ludo a
tre
s ví
as
�Se trata de una desconexión simétrica en la que
se tiene una seguridad razonable de que no se
pierden datos.
�Supone el intercambio de tres m
ensajes, de
form
a análoga a la conexión, de ahísu nombre.
�En caso de que alguno de los m
ensajes de
desconexión se pierda una vez iniciado el proceso
la conexión se term
ina por timeout.
Des
conex
ión e
n T
CP
�Se utiliza el ‘saludo a tres vías’invitando a la otra
parte a cerrar.
�Para indicar el cierre se utiliza el flagFIN
�La desconexión puede iniciarla cualquiera de los
dos TCP (el cliente o el servidor).
�Una vez efectuada la desconexión el host que
inicióel proceso está
un cierto tiempo a la espera
por si aparecen segmentos retrasados
TCP A
TCP B
seq= 100, ack=300, FIN, ACK
seq=300, ack=101 ACK
seq=101, ack=301, ACK
Des
conex
ión a
tres
vía
s, c
aso n
orm
al
ESTABLISHED
FIN-W
AIT-1
ESTABLISHED
CLOSE-W
AIT
FIN-W
AIT-2
LAST-ACK
seq=300, ack=101, FIN, ACK
TIME-W
AIT
CLOSED
CLOSED
2MSL MSL: MaximumSegmentLifetime (norm
almente 2 minutos)
Libera
conexión
Envía ACK
Host 1
(Timeout)
libera
conexión
Host 2
FIN FIN
ACK
Host 1
Libera
conexión
Host 2
FIN FIN
ACK
FIN FIN
Envía FIN y
arranca timer
(Timeout)
envía FIN y
arranca timer
Envía FIN y
arranca timer
Envía FIN y
arranca timer
Envía FIN y
arranca timer
Envía FIN y
arranca timer
Libera
conexión
Envía ACK
Host 1
Host 2
FIN
(timeout)
envía FIN y
arranca timer
Envía FIN y
arranca timer
(N timeouts)
Libera
conexión
Conectado
Pérd
ida d
e A
CK
fin
al
Pérd
ida d
e r
espuesta
FIN
Pérd
ida d
e t
od
os los F
IN d
e h
ost
1
Des
conex
ión a
tres
vía
s, c
asos an
orm
ales
FIN
Host 1
Host 2
FIN FIN
FIN
(timeout)
envía FIN y
arranca timer
Envía FIN y
arranca timer
Envía FIN y
arranca timer
(N timeouts)
Libera
conexión
(Timeout)
libera
conexión
Pérd
ida d
e t
od
o m
enos p
rim
er
FIN
Conectado
Núm
eros de
secu
enci
a y
flag
s
�El número de secuencia es el que corresponde al primer
byte enviado en ese segmento.
�TCP incrementa el número de secuencia de cada
segmento según los bytes que tenía el segmento
anterior, con una sola excepción:
Los flagsSYN y FIN, cuando están puestos,
incrementan en 1 el número de secuencia.
�Esto perm
ite que se pueda acusar recibo de un
segmento SYN o FIN sin ambigüedad.
�Podemos considerar que los segmentos que tienen
puesto el flagSYN o FIN lleva un byte de datos ‘virtual’
�La presencia del flagACK no incrementa
el número de
secuencia
Sum
ario
�Funcionesdel nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
Inte
rcam
bio
de
dat
os TC
P ↔
aplic
ació
n
�Aplicación → →→→
TCP: la aplicación envía los datos a TCP
cuando quiere
(siempre y cuando TCP tenga espacio
libre en el buffer de emisión)
�TCP → →→→
Aplicación: la aplicación lee del buffer de
recepción de TCP cuando quiere y cuanto quiere.
Excepción: datos urgentes
�Para TCP los datos de la aplicación son un flujo continuo
de bytes, independientemente de la separación que
pueda tener la aplicación (registros, etc.). Es
responsabilidad de la aplicación asegurarse que esa
separación (si existe) se m
antendrá
después de
transmitir los datos.
Inte
rcam
bio
de
dat
os TC
P ↔
TC
P
�El TCP emisor manda los datos cuando quiere.
Excepción: datos ‘Pushed’
�El TCP emisor decide el tamaño de segmento según sus
preferencias. Al inicio de la conexión se negocia el MSS
(Maximum
SegmentSize)
�Cada segmento ha de viajar en un datagrama
�Norm
almente TCP intenta agrupar los datos para que
los segmentos tengan la longitud m
áxima, reduciendo
asíel overhead debido a cabeceras y proceso de
segmentos.
�El TCP emisor puede aplicar la técnica de
descubrimiento de la MTU del trayecto (‘Path MTU
Discovery’, MTU = Maximum Transfer Unit) para ajustar
el MSS al tamaño óptimo para esa comunicación.
Ap
lica
ció
n
ori
ge
n
TC
P
rece
pto
r
TC
P
em
isor
Ap
lica
ció
n
de
stino
A c
rite
rio d
e la a
plic
ació
n
(suje
to a
dis
ponib
ilidad
de b
uffer
en T
CP
em
isor)
A c
rite
rio d
e
la a
plic
ació
n
A c
rite
rio d
el T
CP
em
isor
(suje
to a
dis
ponib
ilidad
de b
uffer
en T
CP
recepto
r
y n
o c
ongestión d
e la r
ed)
Empuja
Empuja
Estira
Buff
er
Buff
er
Inte
rcam
bio
de
dat
os
TC
P ↔
Aplic
ació
n y
TC
P ↔
TC
P
Ap
lica
ció
n
ori
ge
n
TC
P
rece
pto
r
TC
P
em
isor
Ap
lica
ció
n
de
stino
Buff
er
Buff
er
Inte
rcam
bio
de
dat
os
TC
P ↔
Aplic
ació
n y
TC
P ↔
TC
P
Escribe
Envía
Lee
2048 Bytes
1024 Bytes
1024 Bytes
512 B
512 B
512 B
512 B
(MS
S 5
12 B
yte
s)
Ges
tión d
e buff
ersy
Control d
e Flu
jo
�El TCP receptor inform
a en cada segmento al
emisor del espacio que le queda libre en el
buffer para esa comunicación. Para ello usa el
campo tamaño de ventana.
�Anunciando una ventana cero el receptor
puede bloquear al emisor, y ejercer asícontrol
de flujo.
�La ventana anunciada es un espacio que el
TCP receptor reserva para esa comunicación
en su buffer.
�Tanto los números de secuencia como los
tamaños de ventana cuentan bytes.
Emisor
Receptor
Ges
tión d
e buff
ersy
Control d
e flujo
Emisor
Bloqueado
Buffer
La aplicación
escribe 2 KB
Seq
= 0
Seq
= 2048
Seq
= 4096
Ack= 2048, W
in= 2048
Ack= 4096, W
in= 0
Ack= 4096, W
in= 2048
La aplicación
escribe 3 KB
El emisor
puede enviar
hasta 2 KB
Vacío
Lle
no
2 K
B
2 K
B
04K
La aplicación
lee 2 KB
3 K
B
2 K
B
2 K
B
1 K
Ges
tión d
e buff
ersy
Control d
e Flu
jo
�El TCP receptor nunca debería retirar el
espacio en buffer que ya ha anunciado al
emisor.
�Sin embargo TCP debe estar preparado por si
el del otro lado lo hace (esto se denomina
‘contraer la ventana’).
(Recordemos la Ley de Postel):
‘Séestricto al enviar y tolerante al
recibir’
Ree
nví
o d
e se
gmen
tos
�En caso de pérdida de un paquete en la red el
segmento TCP no llegará
a su destino
�Cada TCP cuando envía un segmento espera
recibir el ACK; si este no llega dentro de un
tiempo razonable reenvía el segmento.
�Si se enviaron varios segmentos y se pierde
uno se puede hacer dos cosas:
�Enviar solo ese segmento (repetición selectiva)
�Enviar todos los segmentos a partir de ese
(retroceso n)
�Lo norm
al es utilizar retroceso n
Host 1
Host 2
Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
Control d
e flujo
y n
úm
eros de
secu
enci
a
Cas
o n
orm
al, s
in p
édid
as
Seq=1001, Ack=1501, Win=4000
1000 bytes
Seq=1501, Ack=2001, Win=3000
1000 bytes
Seq=2001, Ack=2501, Win=3000
Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
1000 bytes
1000 bytes
1000 bytes
Bloqueado
Seq=2501, Ack=5001, Win=2000
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
1000 bytes
Seq=2501, Ack=5001, Win=0
Aplic
ació
n lee
2000 b
yte
s
SYN
SYN
Host 1
Host 2
Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
Pér
did
a de
un p
aquet
e
Ret
ransm
isió
n c
on ret
roce
so n
Seq=1001, Ack=1501, Win=4000
1000 bytes
Seq=1501, Ack=2001, Win=3000
1000 bytes
Seq=2001, Ack=2501, Win=3000
Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
1000 bytes
1000 bytes
1000 bytes
Bloqueado
Seq=2501, Ack=5001, Win=2000
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
1000 bytes
Seq=2501, Ack=3001, Win=2000
Seq=3001, Ack=2501, Win=3000
Tim
eout
Seq=4001, Ack=2501, Win=3000
Ignorado
Aplic
ació
n lee
2000 b
yte
s
Tim
eout
SYN
SYN
1000 bytes
1000 bytes
Seq=2501, Ack=5001, Win=0
Host 1
Host 2
Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
Seq=1001, Ack=1501, Win=4000
1000 bytes
Seq=1501, Ack=2001, Win=3000
1000 bytes
Seq=2001, Ack=2501, Win=3000
Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
1000 bytes
1000 bytes
1000 bytes
Bloqueado
Seq=2501, Ack=5001, Win=2000
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
1000 bytes
Seq=2501, Ack=3001, Win=1000
Seq=3001, Ack=2501, Win=3000
Tim
eout
1000 bytes
Aplic
ació
n lee
2000 b
yte
s
SYN
SYN
Pér
did
a de
un p
aquet
e
Ret
ransm
isió
n c
on rep
etic
ión sel
ectiva
Seq=2501, Ack=5001, Win=0
Inte
rcam
bio
de
dat
os: c
asos ex
cepci
onal
es
�Datos ‘Pushed’(bit PSH)
�La aplicación pide al TCP emisor que envíe esos datos lo
antes posible. El TCP receptor los pondrá
a disposición
de la aplicación de inmediato, para cuando ésta le pida
datos. Ejemplo: telnet.
�Datos Urgentes (bit URG y UrgentOffset)
�Los datos se quieren entregar a la aplicación remota sin
esperar a que esta los pida. Ejemplo: abortar un
programa con CTRL-C en una sesión telnet
Tim
erde
Per
sist
enci
a
�Mientras la ventana está
cerrada el TCP
emisor puede enviar de vez en cuando un
segmento con un byte de datos; esto provoca
el envío de un ACK por parte del receptor y
evita el bloqueo que se podría producir en
caso de pérdida de un segmento anunciando
una ventana m
ayor que cero
�La frecuencia con que el TCP emisor envía los
reintentos se fija en el ‘Timer de Persistencia’.
TCP A
TCP B
←←←←Tiempo
(seq=401)(ack=601)(ctl=ACK)(W=0)
(seq=601)(ack=401)(ctl=ACK)(datos)
Tim
erde
per
sist
enci
a
(seq=501)(ack=401)(ctl=ACK)(datos)
Timerde
Persistencia
100 bytes
(501-600)
Buffer lleno
(seq=401)(ack=601)(ctl=ACK)(W=400)
Datos leídos por
la aplicación
Datos puestos
en buffer para
la aplicación
(seq=401)(ack=602)(ctl=ACK)(W=(399)
1 byte
(601)
Bloqueado
Men
saje
y tim
erde
keep
aliv
e
�Evita que se queden conexiones ‘medio abiertas’
�Se implementa reenviando el último byte transmitido en
un segmento; el receptor descarta el dato pero
devuelve un ACK
�Si se envían varios m
ensajes de keepalivesin respuesta
se considera que se trata de una conexión m
edio
abierta y se cierra.
�Para declarar una conexión m
edio abierta se espera a
veces hasta 2 horas.
�El tiempo de envío de los m
ensajes se regula con el
timerde keepalive.
�El keepaliveno requiere m
odificaciones en el TCP
receptor
TCP Servidor
TCP Cliente
←←←←Tiempo
(seq=401)(ack=601)(ctl=ACK)
(seq=600)(ack=401)(ctl=ACK)(datos)
Men
saje
s de
keep
aliv
e
(seq=501)(ack=401)(ctl=ACK)(datos)
Timer
Keepalive
(seq=401)(ack=601)(ctl=ACK)
100 bytes
(501-600)
1 byte
(600)
Datos puestos
en buffer para
la aplicación
Datos duplicados
descartados
4. DATA
TCP: ---TCP header
---
TCP:
TCP: Source
port
= 23 (Telnet)
TCP: Destport= 2345
TCP: Seq. Number = 390272002
TCP: AcknowledgmentNumber = 16421122
TCP: Data offset
= 20 bytes
TCP: Flags= 18 (ACK,PSH)
TCP: Window
= 4096
TCP: Checksum= 9FEF (correct)
TCP: No TCP options
TCP: [12 byte(s) of data]
3. ACK
TCP: ---TCP header
---
TCP:
TCP: Source
port
= 2345
TCP: Destport= 23 (Telnet)
TCP: Seq. Number = 16421122
TCP: AcknowledgmentNumber = 390272002
TCP: Data offset
= 20 bytes
TCP: Flags= 10 (ACK)
TCP: Window
= 2048
TCP: Checksum= DF43 (correct)
TCP: No TCP options
2. SYN
TCP: ---TCP header
--
TCP:
TCP: Source
port
= 23 (Telnet)
TCP: Destport= 2345
TCP: Initial
seq. Number = 390272001
TCP: AcknowledgmentNumber = 16421122
TCP: Data offset
= 24 bytes
TCP: Flags= 12 (ACK,SYN)
TCP: Window
= 4096
TCP: Checksum= C13A (correct)
TCP:
TCP: Options
follow
TCP: Max segment
size= 1024
1. SYN
TCP: ---TCP header
---
TCP:
TCP: Source
port
= 2345
TCP: Destport= 23 (Telnet)
TCP: Initial
seq. Number = 16421121
TCP: Data offset
= 24 bytes
TCP: Flags= 02 (SYN)
TCP: Window
= 2048
TCP: Checksum= F2DA (correct)
TCP:
TCP: Options
follow
TCP: Max segment
size= 1460
Cab
ecer
as T
CP
Inic
io d
e una
conex
ión T
elnet
Clie
nte
Se
rvid
or
SEQ=16421121, SYN
SEQ=390272001, ACK=16421122, SYN
El serv
idor
envía
la
secuencia
:UNIX
Login:
TC
P C
onecta
do
Inte
rcam
bio
de
segm
ento
sca
so a
nte
rior
SEQ=16421122, ACK=390272002
SEQ=390272002, ACK=16421122
TC
P C
onecta
do
Clie
nte
Se
rvid
or
SEQ=92, ACK=109, Datos =C
SEQ=109, ACK=93, Datos =C
El servidor telnet
procesa el mensaje
y devuelve una ‘C’; como
la respuesta llega con
rapidez en el mismo
segmento se envían los
datos de vuelta y el ACK
El TCP envía
un ACK del
segmento recibido
SEQ=93, ACK=110
Funci
onam
iento
de
TC
P e
n T
elnet
con e
co rem
oto
, res
pues
ta rap
ida
de
men
saje
s
El usuario
teclea una ‘C’
Clie
nte
Se
rvid
or
El usuario
teclea una ‘C’
SEQ=92, ACK=109, Datos =C
SEQ=109, ACK=93
Cuando el servidor
telnetha procesado
el mensaje devuelve
otro segmento con
el carácter ‘C’
El TCP envía
un ACK del
segmento recibido
SEQ=93, ACK=110
El TCP receptor, al ver
que no se produce
respuesta en un tiempo
razonable, genera un
mensaje de ACK
SEQ=109, ACK=93, Datos=C
Funci
onam
iento
de
TC
P e
n T
elnet
con e
co rem
oto
, res
pues
ta len
ta d
e m
ensa
jes
Sum
ario
�Funcionesdel nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
Baj
a ef
icie
nci
a en
TC
P
�El funcionamiento eficiente de TCP aconseja
enviar segmentos del tamaño m
áximo
perm
itido
�Cuando la aplicación emisora genera los datos
en pequeñas dosis (telnetcon eco remoto por
ejemplo) se da un problema de eficiencia que
se resuelve con el algoritm
o de Nagle.
�Si la aplicación receptora los recoge byte a
byte también se puede dar una baja eficiencia;
esto se conoce como síndrome de la ventana
tonta
y se resuelve con la Solución de Clark.
Solu
ción d
e C
lark
(RFC
813
)
�El TCP receptor solo debe notificar una
nueva ventana cuando tenga una cantidad
razonable de espacio libre. Razonable
significa:
�Un MSS (segmento del tamaño m
áximo), o la
mitad del espacio disponible en el buffer
Sum
ario
�Aspectos generales del nivel de transporte
�Protocolo UDP
�Protocolo TCP
�Multiplexación
�Conexión/Desconexión
�Intercambio de datos y control de flujo
�Casos de baja eficiencia en TCP
�Control de congestión
Control d
e co
nge
stió
n
�Por medio del tamaño de ventana el receptor puede
dosificar al emisor en función del buffer disponible. Esto
es control de flujo.
�Pero puede que el receptor tenga espacio de sobra pero
la red esté
congestionada. En este caso el TCP debe
regularse para no inyectar demasiado tráfico, a pesar
de que la ventana disponible sea m
uy grande. Esto es
control de congestión.
�Norm
almente en TCP se utiliza control de congestión
implícito. Ahora se está
empezando a experimentar en
Internet con el control de congestión explícito.
Co
ntr
ol d
e flu
joC
on
tro
l d
e c
on
gestió
n
Control d
e co
nge
stió
n e
n T
CP
�Cuando hay congestión TCP ha de reducir el flujo
�El mecanismo para detectarla es implícito, por la
pérdida de segmentos. Cuando ocurre TCP baja el
ritm
o.
�Se presupone que la red es altamente fiable a nivel
físico y que las pérdidas se deben a congestión
únicamente. Cuando no es así(redes con errores) bajar
el ritm
o es contraproducente.
�Además de la ventana de control de flujo
(dictada por el
receptor y transmitida en la cabecera TCP) el emisor
tiene una ventana de control de congestión, que ajusta
a partir de los segmentos perdidos. En cada m
omento
se usa la m
ás pequeña de ambas.
�El mecanismo de control de congestión de TCP se
denomina slow-start(arranque lento) y fue diseñado
por Van Jacobson en los años 80.
Tim
erde
retran
smisió
n
�Debe ser adecuado para la comunicación:
�Si es excesivo se esperará
innecesariamente
�Si es m
uy corto se harán reenvíos
innecesarios
�Como la fluctuación es m
uy grande se utilizan
mecanismos autoadaptativos. A partir de los
ACK se m
ide el tiempo de ida y vuelta o Round
TripTime (RTT)
�La estimación de este timeres crucial para el
correcto funcionamiento del ‘slow-start’.
Sí
Sí
Multiplexación
No
Sí
Establecimiento/
term
inación de conexión
No
Sí
Control de congestión
No
Sí
Control de flujo
No
Sí
Corrección de errores
Opcional(*)
Sí
Detección de errores
Sí
Sí
Transporte
UDP
TCP
Función
(*) Obligatorio en IPv6
Com
par
ació
n T
CP -
UD
P
Descartar
¿Trama long. entera ≥ ≥≥≥64 ≤ ≤≤≤1518?
Trama recibida
¿CRC correcto?
No
Sí
Descartar
No
Sí
¿MAC destino reconocida?
Descartar
No
Sí
¿ChecksumIP correcto?
Descartar
No
Sí
Tarjeta de red
DriverTarjeta
Proceso IP
Proceso TCP/UDP
Depositar contenido en buffer para proceso en puerto destino y devolver ACK (TCP)
¿IP destino reconocida?
Descartar
No
Sí
¿ChecksumTCP/UDP correcto?
Descartar
No
Sí
¿Puerto destino reconocido?
Descartar y
devolver ICMP
destino inacc.
No
Sí
¿Datos duplicados (TCP)?
Descartar y
devolver ACK
Sí
No
Tarjeta
red
CPU
¿Protocolo reconocido?
No
Sí
Descartar y
devolver ICMP
destino inacc.
Pro
ce
so
de
un
a tra
ma
Eth
ern
et T
CP
/IP
recib
ida
por
un
host
Top Related