el nivel de transporte en internet -...

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


�Protocolo UDP

�Protocolo TCP

�Multiplexació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)


(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


�Protocolo UDP

�Protocolo TCP

�Multiplexació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





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)


(una por interfaz)

Dos instancias

(TCP y UDP)


(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


�Protocolo UDP

�Protocolo TCP

�Multiplexació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=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)


ESTABLISHED


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


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


�Protocolo UDP

�Protocolo TCP

�Multiplexació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


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)


Men

saje

s de

keep

aliv

e


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: 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: 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


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=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


�Protocolo UDP

�Protocolo TCP

�Multiplexació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


�Protocolo UDP

�Protocolo TCP

�Multiplexació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

el nivel de transporte en internet -...

Documents