el nivel de transporte en internet - spw.cl wan ip-atm/tcp_udp.pdf · – campo protocolo en...

Redes 6-1

Tema 6

El Nivel de Transporte en Internet

Redes 6-2

Sumario

• Aspectos generales del nivel de transporte• 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

• Protocolo UDP

Redes 6-3

Funciones del Nivel de Transporte• Se encarga del transporte de los datos extremo a extremo

(host a host). • Realiza la comunicación de forma transparente al medio

físico. Usa los servicios del nivel de red• Multiplexa tráfico de diversas instancias (procesos) del

nivel de aplicación• La unidad de transferencia de información a nivel de

transporte es la TPDU (Transport Protocol Data Unit)• Generalmente las aplicaciones requieren un servicio fiable,

sin pérdidas ni datos duplicados. Para ello se utiliza un servicio orientado a conexión (CONS). Ej.: TCP, TP4 (OSI)

• A otras aplicaciones les basta con un servicio no fiable, no orientado a conexión (CLNS). Ej.: UDP, TP0 (OSI)

Redes 6-4

Equivalencia Internet – OSI

Tipo de protocolo Internet OSI

Nivel de red IP (Internet Protocol) CLNP (ConnectionlessNetwork Protocol

Routing interno OSPF (Open Shortest Path First)

IS-IS (Intermediate System –Intermediate System

Routing externo BGP (BorderGateway Protocol)

IDRP (Inter Domain RoutingProtocol)

Nivel de transporte orientado a conex.

TCP (TransmissionControl Protocol)

TP4 (Transport Protocolclase 4)

Nivel de transporte no orientado a conex.

UDP (User Datagram Protocol)

TP0 (Transport Protocolclase 0)

Redes 6-5

TSAP• El TSAP (Transport Service Access Point) es el punto

donde el nivel de aplicación accede al servicio del nivel de transporte.

• Por ejemplo en Internet el TSAP se especifica por:– Dirección IP– Campo Protocolo en cabecera IP (6 para TCP, 17 para

UDP)– Puerto en la cabecera TCP/UDP

• El puerto permite multiplexar en una sola instancia del nivel de transporte múltiples instancias del nivel de aplicación

• Normalmente los servidores utilizan puertos ‘bien conocidos’

Redes 6-6

Aplicación

Transporte

Red

Enlace

Física

Host 1 Host 2

NSAP NSAP

Cliente Servidor

TSAP TSAP

TSAP y NSAP de una conexión

147.156.135.22 147.156.1.11

147.156.1.11:80 (TCP)

147.156.135.22:8000 (TCP)

Redes 6-7

Sumario



• Protocolo UDP

Redes 6-8

TCP (Transmission Control Protocol)

• 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 TPDUs de TCP se llaman segmentos.• El TCP actual se especificó en 1981 en el RFC 793

y sigue plenamente vigente.

Redes 6-9

Servicio orientado a conexión• Los servicios orientados a conexión requieren un

procedimiento explícito de establecimiento y terminación de la comunicación.

• Durante la conexión las entidades participantes mantienen en memoria una información relativa a dicha conexión (contadores de bytes, etc.). Dicha información se conoce como información de estado.

• Para describir los servicios orientados a conexión se suele utilizar un modelo basado en dos protagonistas:– Cliente: el que inicia la conexión– Servidor: el que es invitado a conectar

• Una conexión puede terminarse tanto por iniciativa del cliente como del servidor.

Redes 6-10

Funciones de TCP

• Establecer y terminar conexiones• Gestionar los buffers y ejercer control de

flujo de forma eficiente• Multiplexar el nivel de aplicación (port) e

intercambiar datos con las aplicaciones• Controlar errores, retransmitir segmentos

perdidos o erróneos y eliminar duplicados• Efectuar control de congestión

Redes 6-11

Relleno

Flags8 bits

Reserv.4 bits

Puntero datos urgentes

Tamaño ventana

Puerto de destino

Opciones

Checksum

Lon. Cab

Número de acuse de recibo

Número de secuencia

Puerto de origen

Flags: CWR: Congestion Window ReducedECE: ECN Echo (ECN=Explicit Congestion Notification) URG: el segmento contiene datos urgentesACK: el campo número de acuse de recibo tiene sentidoPSH: el segmento contiene datos ‘Pushed’RST: ha habido algún error y la conexión debe cerrarseSYN: indica el inicio de una conexiónFIN: indica el final de una conexión

La cabecera TCP32 bits

20bytes

Redes 6-12

Dirección IP de origenDirección IP de destino

00000000 00000110 Long. Segmento TCP

La pseudocabecera TCP

32 bits

Se añade al principio del segmento para el cálculo del checksum. Permite a TCP comprobar que IP no se ha equivocado en la entrega del datagrama.

El valor 1102 = 610 indica que el protocolo de transporte es TCP

Redes 6-13

Sumario



• Protocolo UDP

Redes 6-14

Multiplexación

• La multiplexación se realiza mediante 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 dirección IP y puerto identifica el ‘socket’

• Una conexión TCP queda especificada por los dos sockets que se comunican

Redes 6-15

Nivel de enlace

Nivel de red

Nivel de transporte

Nivel de aplicación

Ethertype 0800 DATAGRAMA IP CRC

Protocolo 6 SEGMENTO TCP

Puerto dest. 23 DATOS APLICACIÓN

SMTP(Puerto 25)

Telnet(Puerto 23)

FTP(Puerto 21)

Cabecera MAC Ethernet

Cabecera IP

Cabecera TCP

Multiplexación

Redes 6-16

Cliente IP 147.156.1.202

Servidor IP 147.156.1.25

Port23

Port 1038

Conexión TCPPort 1038

Cliente IP 158.42.3.47

Conexión TCP

Socket: 147.156.1.25.23

Socket: 147.156.1.202.1038

Socket: 158.42.3.47.1038

Dos conexiones TCP de clientes con diferentes direcciones IP

Redes 6-17

Cliente IP 147.156.1.202

Servidor IP 147.156.1.25

Port23

Socket: 147.156.1.25.23

Socket: 147.156.1.202.1038

Port1039

Port1038

Socket: 147.156.1.202.1039

Dos conexiones TCP de clientes con la misma IP

Redes 6-18

Netstat -anActive 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 ESTABLISHEDtcp 0 0 147.156.1.25.23 147.156.96.8.1034 ESTABLISHEDtcp 0 240 147.156.1.25.23 147.156.1.219.1036 ESTABLISHEDtcp 0 0 147.156.1.25.513 147.156.1.3.1018 ESTABLISHEDtcp 0 0 147.156.1.25.513 147.156.1.3.1019 ESTABLISHEDtcp 0 0 147.156.1.25.2429 147.156.1.15.6000 ESTABLISHEDtCP 0 0 147.156.1.25.2428 147.156.1.15.6000 ESTABLISHEDtcp 0 0 147.156.1.25.1022 147.156.1.3.1002 ESTABLISHEDtcp 0 0 147.156.1.25.514 147.156.1.3.1004 CLOSE_WAITtcp 0 0 147.156.1.25.1023 147.156.1.3.1005 ESTABLISHEDtcp 0 0 147.156.1.25.514 147.156.1.3.1007 CLOSE_WAITtcp 0 0 147.156.1.25.139 147.156.1.219.1029 ESTABLISHEDtcp 0 0 *.143 *.* LISTENtcp 0 0 *.144 *.* LISTENtcp 0 0 147.156.1.25.23 147.156.3.12.1945 ESTABLISHEDtcp 0 0 *.139 *.* LISTENtcp 0 0 *.5000 *.* LISTENtcp 0 0 *.25 *.* LISTENtcp 0 0 *.19 *.* LISTENtcp 0 0 *.9 *.* LISTENudp 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 *.*

Conexiones TCP del host UNIX 147.156.1.25 (conectado por telnet desde 147.156.1.219)

Redes 6-19

Sumario



• Protocolo UDP

Redes 6-20

Primitivas básicas de conexión/desconexión

Cliente Servidor

Connect(bloqueado)

ReceiveSend

(bloqueado)

Receive...Disconnect

(libera conexión)

Listen (bloqueado)

ReceiveSend

(bloqueado)

ReceiveSend

(bloqueado)...

ReceiveDisconnect

(libera conexión)Listen

(bloqueado)

Petición conexión

Conexión

aceptada

Datos

Datos

Petición desconexión

Petición

desconexión

Redes 6-21

INACTIVO

PENDIENTE CONEXIÓN

PASIVA

PENDIENTE CONEXIÓN

ACTIVA

CONEXIÓN ESTABLECIDA

INACTIVO

PENDIENTE DESCONEXIÓN

PASIVA

PENDIENTE DESCONEXIÓN

ACTIVA

SERVIDORCLIENTE

Primitiva Connectejecutada

TPDU de conexión recibida

Primitiva Connectejecutada

TPDU de conexión recibida

TPDU de desconexión

recibida

Primitiva Disconnectejecutada

Primitiva Disconnectejecutada

TPDU de desconexión recibida

Evolución de estados en una conexión/desconexión

Redes 6-22

Conexión por ‘Saludo a tres vías’• En TCP pueden llegar segmentos duplicados (ej. Se pierde la

confirmació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, como que una sesión entera se duplique.

• Para evitarlo se utiliza el saludo a tres vías, un procedimiento de conexión más elaborado que evita los problemas debidos a duplicados

• Para ello se identifica cada intento de conexión mediante un número diferente. El cliente elige un número a modo de clave para la comunicación en sentido de ida y el servidor otro para el sentido de vuelta.

• Estos dos números actúan como PINs que identifican cada intento de conexión y lo protegen de segmentos retrasados que pudieran aparecer fruto de conexiones anteriores.

Redes 6-23

Procedimiento del saludo a tres vías1. 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.

Redes 6-24

TCP A TCP B

←Ti

empo

seq=100, SYN

seq=300, ack=101, SYN, ACK

seq=101, ack=301, ACK

Establecimiento de una conexión TCP por saludo a tres vías

CLOSED

SYN-SENT(ISN 100)

LISTEN

SYN-RECEIVED

(ISN 300)

ESTABLISHED

ESTABLISHED

Redes 6-25

TCP A TCP B

←Ti

empo

seq=100, SYN

seq=300,ack=101,

SYN, ACKseq=100, ack=301,SYN,ACK

Conexión saludo a tres vías, conexión simultánea

CLOSED

SYN-SENT(ISN 100)

CLOSED

SYN-RECEIVED

ESTABLISHED ESTABLISHED

seq=300, SYN SYN-SENT(ISN 300)

SYN-RECEIVED

Redes 6-26

TCP A TCP B←

Tiem

po

seq=100, SYN


seq=91, RST

Conexión con SYN duplicado

CLOSED

SYN-SENT(ISN 100)

LISTEN

SYN-RECEIVED(ISN 300)

LISTEN

seq=90, SYN

seq=100, SYNSYN-RECEIVED(ISN 400)


ESTABLISHED seq=101, ack=401, ACKESTABLISHED

SYN90

SYN-SENT(ISN 90)

seq=90, SYN

(timeout)

SYN90

SYN100

SYN100

Redes 6-27

Conexión en TCP• Los dos primeros segmentos de la conexión se identifican

con el flag SYN.• El número de secuencia es un campo de 32 bits que cuenta

bytes en módulo 232 (el contador se da la vuelta cuando llega al valor máximo).

• El número de secuencia no empieza normalmente en 0, sino en un valor denominado ISN (Initial SequenceNumber) 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.

Redes 6-28

Conexión en TCP• 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 min.

• El MSL (Maximum Segment Lifetime) 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 mecanismo de protección frente a sabotajes. Es muy fácil averiguar el ISN de una conexión e interceptarla suplantando a alguno de los dos participantes.

Redes 6-29

Desconexión

• Puede ser de dos tipos:– Simétrica: la conexión se considera formada 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 host la termina en ambos sentidos sin esperar a recibir confirmación del otro). Puede provocar pérdida de información.

Redes 6-30

Host 1 Host 2←

Tiem

po

DATOS

DATOS

DATOS

DR: Disconnect Request

Desconexión asimétrica

ConectadoConectado

NoConectado

NoConectado

DR

Datos perdidos

Redes 6-31

Mensaje de Desconexión

• EL mensaje solicitando la desconexión se puede perder. Por eso se pide una confirmación (ACK).

• Pero la confirmación también podría perderse, por lo que habría que enviar una reconfirmacion, y así sucesivamente.

• Este problema no tiene solución infalible, pues estamos usando un canal no fiable para asegurar un envío de información. Es lo que se conoce como el problema de los dos ejércitos.

Redes 6-32

El problema de los dos ejércitos

Redes 6-33

Desconexión por saludo a tres 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 mensajes, de forma análoga a la conexión, de ahí su nombre.

• En caso de que alguno de los mensajes de desconexión se pierda una vez iniciado el proceso la conexión se termina por timeout.

Redes 6-34

Desconexión en TCP

• Se utiliza el ‘saludo a tres vías’ invitando a la otra parte a cerrar.

• Para indicar el cierre se utiliza el flag FIN• La desconexión puede inciarla 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

Redes 6-35

TCP A TCP B

seq = 100, ack=300, FIN, ACK

seq=300, ack=101 ACK

seq=101, ack=301, ACK

Desconexión a tres vías, caso normal

ESTABLISHED

FIN-WAIT-1

ESTABLISHED

CLOSE-WAIT

FIN-WAIT-2LAST-ACKseq=300, ack=101, FIN, ACK

TIME-WAIT

CLOSED

CLOSED

2MSL

MSL: Maximum Segment Lifetime (normalmente 2 minutos)

Redes 6-36

Libera conexión

Envía ACK

Host 1

(Timeout)libera

conexión

Host 2

FIN

FIN

ACK

Host 1

Libera conexión

Host 2FIN

FIN

ACK

FIN

FINEnvía FIN y

arranca timer

(Timeout)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


(N timeouts)Libera

conexión Conectado

Pérdida de ACK final Pérdida de respuesta FIN

Pérdida de todos los FIN de host 1

Otras formas de terminar una conexión TCP

FINHost 1 Host 2

FIN

FIN

FIN(timeout)envía FIN y

arranca timer



(N timeouts)Libera

conexión

(Timeout)libera

conexión

Pérdida de todo menos primer FIN

Conectado

Redes 6-37

Redes 6-38

Números de secuencia y flags• 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 flags SYN y FIN, cuando están puestos, incrementan

en 1 el número de secuencia. • Esto permite que se pueda acusar recibo de un segmento

SYN o FIN sin ambigüedad.• Podemos considerar que los segmentos que tienen puesto

el flag SYN o FIN lleva un byte de datos ‘virtual’• La presencia del flag ACK no incrementa el número de

secuencia

Redes 6-39

Sumario



• Protocolo UDP

Redes 6-40

Intercambio de datos TCP ↔ aplicació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 continuode 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 mantendrá después de transmitir los datos.

Redes 6-41

Intercambio de datos TCP ↔ TCP• 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 Segment Size)

• Cada segmento ha de viajar en un datagrama• Normalmente TCP intenta agrupar los datos para que los

segmentos tengan la longitud máxima, reduciendo así eloverhead 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.

Redes 6-42

Aplicaciónorigen

TCPreceptor

TCPemisor

Aplicacióndestino

A criterio de la aplicación(sujeto a disponibilidad de buffer en TCP emisor)

A criterio dela aplicación

A criterio del TCP emisor(sujeto a disponibilidadde buffer en TCP receptory no congestión de la red)

Empuja

Empuja

Estira

Buffer Buffer

Intercambio de datos TCP ↔ Aplicación y TCP ↔ TCP

Redes 6-43

Aplicaciónorigen

TCPreceptor

TCPemisor

Aplicacióndestino

Buffer Buffer

Intercambio de datos TCP ↔ Aplicación y TCP ↔ TCP

Escribe

Envía

Lee2048 Bytes1024 Bytes

1024 Bytes

512 B 512 B512 B 512 B

(MSS 512 Bytes)

Redes 6-44

Gestión de buffers y Control de Flujo

• El TCP receptor informa 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.

Redes 6-45

Emisor Receptor

Gestión de buffers y Control de flujo

EmisorBloqueado

Buffer

La aplicaciónescribe 2 KB Seq = 0

Seq = 2048

Seq = 4096

Ack = 2048, Win = 2048

Ack = 4096, Win = 0

Ack = 4096, Win = 2048

La aplicaciónescribe 3 KB

El emisorpuede enviar

hasta 2 KB

Vacío

Lleno

2 KB

2 KB

0 4K

La aplicaciónlee 2 KB

3 KB

2 KB

2 KB

1 K

Redes 6-46

Gestión de buffers y Control de Flujo

• 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 norma básica de Internet:

‘Sé estricto al enviar y tolerante al recibir’

Redes 6-47

Reenvío de segmentos

• 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 normal es utilizar retroceso n

Redes 6-48

Host 1 Host 2Seq=1000, Win=4000

Seq=1500, Ack=1001, Win=4000

Control de flujo y números de secuenciaCaso normal, sin pédidas

Seq=1001, Ack=1501, Win=40001000 bytes

Seq=1501, Ack=2001, Win=3000 1000 bytes

Seq=2001, Ack=2501, Win=3000Seq=3001, Ack=2501, Win=3000

Seq=4001, Ack=2501, Win=3000

1000 bytes

1000 bytes

1000 bytes

BloqueadoSeq=2501, Ack=5001, Win=2000

Seq=5001, Ack=2501, Win=3000

Seq=2501, Ack=6001, Win=30001000 bytes

Seq=2501, Ack=5001, Win=0Aplicación lee2000 bytes

SYN

SYN

Redes 6-49


Seq=1500, Ack=1001, Win=4000

Pérdida de un paqueteRetransmisión con retroceso n

Seq=1001, Ack=1501, Win=40001000 bytes

Seq=1501, Ack=2001, Win=30001000 bytes


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

Timeout

Seq=4001, Ack=2501, Win=3000

Ignorado

Aplicación lee2000 bytes

Timeout

SYN

SYN

1000 bytes

1000 bytesSeq=2501, Ack=5001, Win=0

Redes 6-50


Seq=1500, Ack=1001, Win=4000

Seq=1001, Ack=1501, Win=40001000 bytes

Seq=1501, Ack=2001, Win=30001000 bytes


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


Timeout

1000 bytesAplicación lee2000 bytes

SYN

SYN

Pérdida de un paqueteRetransmisión con repetición selectiva

Seq=2501, Ack=5001, Win=0

Redes 6-51

Intercambio de datos: casos excepcionales

• 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 Urgent Offset)– 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

Redes 6-52

Timer de Persistencia

• 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 mayor que cero

• La frecuencia con que el TCP emisor envía los reintentos se fija en el ‘Timer de Persistencia’.

Redes 6-53

TCP A TCP B←

Tiem

po

(seq=401)(ack=601)(ctl=ACK)(W=0)

(seq=601)(ack=401)(ctl=ACK)(datos)

Timer de persistencia


Timer de 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

Redes 6-54

Mensaje y timer de keepalive

• 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 mensajes de keepalive sin respuesta se considera que se trata de una conexión medio abierta y se cierra.

• Para declarar una conexión medio abierta se espera a veces hasta 2 horas.

• El tiempo de envío de los mensajes se regula con el timerde keepalive.

• El keepalive no requiere modificaciones en el TCP receptor

Redes 6-55

TCP Servidor TCP Cliente←

Tiem

po

(seq=401)(ack=601)(ctl=ACK)


Mensajes de keepalive


TimerKeepalive

(seq=401)(ack=601)(ctl=ACK)

100 bytes(501-600)

1 byte(600)

Datos puestos en buffer para la aplicación

Datos duplicados descartados

Redes 6-56

1. SYNTCP: --- TCP header ---TCP:TCP: Source port = 2345TCP: Dest port = 23 (Telnet)TCP: Initial seq. Number = 16421121

TCP: Data offset = 24 bytesTCP: Flags = 02 (SYN)TCP: Window = 2048TCP: Checksum = F2DA (correct)TCP:TCP: Options followTCP: Max segment size = 1460

2. SYNTCP: --- TCP header --TCP:TCP: Source port = 23 (Telnet)TCP: Dest port = 2345TCP: Initial seq. Number = 390272001TCP: Acknowledgment Number = 16421122TCP: Data offset = 24 bytesTCP: Flags = 12 (ACK,SYN)TCP: Window = 4096TCP: Checksum = C13A (correct)TCP:TCP: Options followTCP: Max segment size = 1024

3. ACKTCP: --- TCP header ---TCP:TCP: Source port = 2345TCP: Dest port = 23 (Telnet)TCP: Seq. Number = 16421122TCP: Acknowledgment Number =

390272002TCP: Data offset = 20 bytesTCP: Flags = 10 (ACK)TCP: Window = 2048TCP: Checksum = DF43 (correct)TCP: No TCP options

4. DATATCP: --- TCP header ---TCP:TCP: Source port = 23 (Telnet)TCP: Dest port = 2345TCP: Seq. Number = 390272002TCP: Acknowledgment Number = 16421122TCP: Data offset = 20 bytesTCP: Flags = 18 (ACK,PSH)TCP: Window = 4096TCP: Checksum = 9FEF (correct)TCP: No TCP optionsTCP: [12 byte(s) of data]

Cabeceras TCP del inicio de una conexión Telnet

Redes 6-57

Cliente Servidor

SEQ=16421121, SYN

SEQ=390272001, ACK=16421122, SYN

El servidor envía la secuencia:

UNIXLogin:

TCP Conectado

Intercambio de segmentos del caso anterior

SEQ=16421122, ACK=390272002

SEQ=390272002, ACK=16421122

TCP Conectado

Redes 6-58

Cliente Servidor

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

Funcionamiento de TCP en Telnet con eco remotocuando el host responde rápidamente a los mensajes

El usuario teclea una ‘C’

Redes 6-59

Cliente Servidor

El usuario teclea una ‘C’


SEQ=109, ACK=93

Cuando el servidortelnet ha procesado el mensaje devuelveotro segmento con

el carácter ‘C’

El TCP envía un ACK del

segmento recibidoSEQ=93, ACK=110

Funcionamiento de TCP en Telnet con eco remotocuando el host responde con lentitud a los mensajes

El TCP receptor, al ver que no se produce

respuesta en un tiemporazonable, genera un

mensaje de ACK

SEQ=109, ACK=93, Datos=C

Redes 6-60

Sumario



• Protocolo UDP

Redes 6-61

Baja eficiencia en TCP• El funcionamiento eficiente de TCP aconseja

enviar segmentos del tamaño máximo permitido• Cuando la aplicación emisora genera los datos en

pequeñas dosis (telnet con eco remoto por ejemplo) se da un problema de eficiencia que se resuelve con el algoritmo de Nagle.

• Si la aplicación receptora los recoge byte a bytetambié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.

Redes 6-62

Algoritmo de NagleCuando la aplicación envía datos en pequeños grupos TCP

envía el primero y retiene los demás hasta recibir el ACK; por cada ACK recibido envía un segmento con los bytes que hubiera pendientes, y así sucesivamente.También se envía un segmento cuando los datos

acumulados igualan o superan el MSS (tamaño máximo de un segmento), o la mitad de la ventana.El mecanismo es autoadaptativo, pues cuanto más cargada

esté la red mas tardarán los ACK y mas agrupados irán los datos•Se puede aplicar a datos pushed en caso necesario

Redes 6-63

Síndrome de la ventana tonta

1. La aplicación que envía datos los genera rápidamente2. La aplicación receptora los recupera lentamente, un byte

cada vez3. El buffer del TCP receptor se llena4. El TCP receptor notifica al emisor que su ventana está

cerrada 5. La aplicación receptora lee un byte6. EL TCP receptor envía un ACK al emisor para

anunciarle que dispone de un byte libre7. El TCP emisor envía un segmento con un byte de datos8. Volvemos al punto 3

Redes 6-64

La aplicación lee un byte

Buffer receptor lleno

Un byte libre

Buffer receptor lleno

Cabecera IP-TCPSe envía segmento deactualización de ventana

Cabecera IP-TCP Se recibe segmentocon un byte de datos

1 Byte

Síndrome de la ventana tonta

40 Bytes

40 Bytes

Redes 6-65

Solución de Clark (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

Redes 6-66

Sumario



• Protocolo UDP

Redes 6-67

Control de congestió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 muy grande. Esto es control de congestión.

• Normalmente 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.

Redes 6-68

Control de flujo Control de congestión

Redes 6-69

Control de congestión en TCP

• 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 ritmo.• 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 ritmo 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 momento 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.

Redes 6-70

Slow Start (primera fase)

• Inicialmente la ventana de congestión tiene el tamaño de un MSS (Maximum Segment Size)

• Por cada segmento enviado con éxito la ventana se amplía en un MSS

• En la práctica esto supone un crecimiento exponencial (en potencias de dos)

• Si la ventana de congestión supera a la de control de flujo se aplica ésta con lo cual aquella deja de crecer

Redes 6-71

ACK 2

Emisor Receptor

SEG 1

ACK 1

SEG 2

ACK 3

SEG 4ACK 4

Con MSS = 1KB en 7 iteraciones se llega a 64 KB,

tamaño máximo de la ventana

Ventana

1 MSS

4 MSS

2 MSS

SEG 8ACK 8

8 MSS

SEG 3

SEG 5SEG 6

SEG 7ACK 5

ACK 6ACK 7

SEG 9SEG 10

SEG 11SEG 12

SEG 13SEG 14

SEG 15

ACK 9ACK 10

ACK 11ACK 12

ACK 13ACK 14

ACK 15

Funcionamiento de slow start, fase 1

Redes 6-72

Slow start (segunda fase)

• Cuando se pierde un segmento:– La ventana de congestión vuelve a su valor

inicial– Se fija un ‘umbral de peligro’ en un valor igual

a la mitad de la ventana que había cuando se produjo la pérdida.

– La ventana de congestión crece como antes hasta el umbral de peligro; a partir de ahí crece en sólo un segmento cada vez

Redes 6-73

Emisor Receptor

SEG 15 ACK 15

Ventana

1 MSS

SEG 162 MSS ACK 16

SEG 184 MSS ACK 18

SEG 22 ACK 22

SEG 27 ACK 27

5 MSS

6 MSS

ACK del segmento 15

perdido y retransmitidoSEG 17 ACK 17

SEG 19SEG 20

SEG 21

ACK 19ACK 20

ACK 21

SEG 23SEG 24

SEG 25SEG 26

ACK 23ACK 24

ACK 25ACK 26

SEG 28SEG 29

SEG 30SEG 31

SEG 32

ACK 28ACK 29

ACK 30ACK 31

ACK 32

Funcionamiento de slow start, fase 2

Redes 6-74

4

8

12

16

20

24

28

32

36

40

44

00 2 4 6 8 10 12 14 16 18 20 22 24

Un segmento perdido (40 KB)

Umbral (32 KB)

Umbral (20 KB)

Número del envío

Vent

ana

de c

onge

stió

n (K

iloB

ytes

)Evolución de la ventana de congestión

Redes 6-75

Timer de retransmisión

• Debe ser adecuado para la comunicación:– Si es excesivo se esperará innecesariamente– Si es muy corto se harán reenvíos innecesarios

• Como la fluctuación es muy grande se utilizan mecanismos autoadaptativos. A partir de los ACK se mide el tiempo de ida y vuelta o Round Trip Time (RTT)

• La estimación de este timer es crucial para el correcto funcionamiento del ‘slow-start’.

Redes 6-76

Timer de retransmisión

• El valor medio de RTT (MRTT) se calcula por la fórmula:MRTTn = α MRTTn-1 + (1 - α) RTTdonde: RTT: Valor más reciente medido de RTT

α: Factor de amortiguación. Normalmente 7/8• Para deducir el timeout a partir de MRTT tenemos que

tener una idea de la dispersión de los valores. Para eso calculamos la desviación estándar como:Dn = β Dn-1 + (1 - β) | MRTTn-1 – RTT|donde β suele valer 3/4.

• El timeout se calcula normalmente como MRTT + 4*D

Redes 6-77

Dispersión del timer de retransmisión

Redes 6-78

Redes 6-79

N MRTTn-1 RTTn MRTTn Dn-1 Dn Timeout

494

459,25

515.83

456.92

451.27

505.36

459,36

467,18

434,81

412,45

419,16

424,49

426,36

453,14

64

54,5

65,56

51,07

51,21

61,86

49,92

50,27

41,68

36,78

37,25

37,40

39,27

44,13

64

54,5

65,56

51,07

51,21

61,86

49,92

50,27

41,68

36,78

37,25

37,40

39,27

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

230 230,00

230,00 294 238,00

238,00 264 241,25

241,25 340 253,59

253,59 246 252,64

252,64 201 246,19

246,19 340 257,92

257,92 272 259,68

259,68 311 266,10

266,10 282 268,09

268,09 246 265,33

265,33 304 270,16

270,16 308 274,89

274,89 230 269,28

269,28 328 276,62

Evolución de MRTT, D y timeout de retransmisión en función del valor de RTT

Redes 6-80

Netstat -p tcptcp:978740 packets sent949215 data packets (1306073886 bytes)544 data packets (329353 bytes) retransmitted10186 ack-only packets (8786 delayed)0 URG only packets188 window probe packets17669 window update packets938 control packets

432947 packets received251266 acks (for 863756680 bytes)1294 duplicate acks0 acks for unsent data76150 packets (68148251 bytes) received in-sequence)174 completely duplicated packets (57347 bytes)15 packets with some dup. data (34 bytes duped)341 out-of-order packets (4224 bytes)23 packets (0 bytes) of data after window0 window probes23158 window update packets1 packet received after close0 discarded for bad checksums0 discarded for bad header offset fields0 discarded because packet too short

397 connection requests414 connection accepts629 connections established (including accepts)848 connections closed (including 38 drops)179 embryonic connections dropped313267 segments updated rtt (of 314002 attempts)347 retransmit timeouts2 connections dropped by rexmit timeout

190 persist timeouts54 keepalive timeouts53 keepalive probes sent1 connection dropped by keepalive

Redes 6-81

Opciones y extensiones de TCP

• Intercambio de valores de MSS entre los dos comunicantes. Es la más habitual

• Otras opciones son:– Factor de escala, para ventanas de hasta 1 GB

(RFC 1323). Mejora la eficiencia en redes ‘LFN’ (Long, Fat pipe Network) con elevado valor de BW*RTT

– Repetición selectiva y acuse de recibo negativo (NAK) (RFC 1106). También especialmente útil en LFNs.

• Se suelen negociar en el segmento de inicio de la conexión (el que lleva el bit SYN

Redes 6-82

Sumario



• Protocolo UDP

Redes 6-83

Protocolo UDP

• Servicio sencillo, CLNS, no fiable• Se utiliza en los siguientes entornos:

– El intercambio de mensajes es muy escaso, ej.:consultas al DNS (servidor de nombres)

– La aplicación es en tiempo real y no puede esperar los ACKs. Ej.: videoconferencia, voz sobre IP.

– Los mensajes se producen regularmente y no importa si se pierde alguno. Ej: NTP, SNMP

– El medio de transmisión es altamente fiable y sin congestion (LANs). Ej: NFS

– Se envía tráfico broadcast/multicast

Redes 6-84

Protocolo UDP

• Las TPDUs de UDP se denominan mensajes odatagramas UDP

• UDP multiplexa los 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

Redes 6-85

Puerto de origen Puerto de destinoLongitud datagrama UDP Checksum

La cabecera de UDP con la pseudocabecera

32 bits

Dirección IP de origenDirección IP de destino

00000000 00010001 Long. Datagrama UDPPseudocabecera

Cabecera

La pseudocabecera se añade al principio del datagrama para el cálculo del checksum. Permite a UDP comprobar que IP no se ha equivocado en la entrega del datagrama.

El valor 100012 = 1710 indica que el protocolo de transporte es UDP

Redes 6-86

IP: ----- IP Header -----IP:IP: Version=4, header length=20 bytesIP: DiffServ = 00 IP: Total length = 131 bytesIP: Identification = 21066IP: DF = 0, MF = 0IP: Fragment offset = 0 bytesIP: Time to live = 60 seconds/hopsIP: Protocol = 17 (UDP)IP: Header checksum = 2A13 (correct)IP: Source address = [128.1.1.1]IP: Destination address = [128.1.1.10]IP: No optionsIP:UDP: ----- UDP Header -----UDP:UDP: Source Port = 1227 (SNMP)UDP: Destination port = 161UDP: Length = 111UDP: No checksumUDP:

IP: ----- IP Header -----IP:IP: Version=4, header length=20 bytesIP: DiffServ = 00 IP: Total length = 160 bytesIP: Identification = 2015IP: DF = 0, MF = 0IP: Fragment offset = 0 bytesIP: Time to live = 64 seconds/hopsIP: Protocol = 17 (UDP)IP: Header checksum = 7061 (correct)IP: Source address = [128.1.1.10]IP: Destination address = [128.1.1.1]IP: No optionsIP:UDP: ----- UDP Header -----UDP:UDP: Source Port = 161 (SNMP)UDP: Destination port = 1227UDP: Length = 140UDP: Checksum = 4D4F (correct)UDP:

Cabeceras IP y UDP en una petición/respuesta SNMP

Redes 6-87

Función TCP UDPTransporte Sí SíMultiplexación Sí SíDetección de errores Sí Opcional(*)

Corrección de errores Sí NoControl de flujo Sí NoControl de congestión Sí NoEstablecimiento/ terminación de conexión

Sí No

(*) Obligatorio en IPv6

Comparación Protocolos de transporte de Internet

Redes 6-88

Ejercicios

Redes 6-89

Ejercicio 4

P: El tamaño máximo de un segmento TCP es 65.515 bytes. ¿Podría explicar de donde viene ese valor?

R: La longitud máxima de un datagrama se especifica en un campo de 16 bits, por lo que es 65535 bytes. De estos al menos 20bytes son la cabecera IP, con lo que quedan 65515 bytes para el segmento TCP.

Redes 6-90

Ejercicio 6

• ¿Debe TCP preocuparse de reordenar los fragmentos de un datagrama?

• NO. El nivel IP reconstruye el datagrama original en orden antes de entregar el segmento a TCP; para ello usa los campos identificación, fragmentoffset y MF. TCP no puede reordenar los fragmentos puesto que normalmente solo el primero tiene cabecera TCP.

Redes 6-91

Internet

Se quiere poner en el router una regla que impida el establecimiento de conexiones TCP desde fuera

Red interna

Ejercicio 7

Router filtro

Redes 6-92

Ejercicio 7

Solución:Filtrar los datagramas que entren por la interfaz serie y que cumplan simultáneamente:– Tener el valor 6 en el campo protocolo

(TCP)– Tener a 1 el bit SYN y a 0 el ACK en la

cabecera TCP.

Redes 6-93

Ejercicio 8

• Aplicación genera mensaje de 1540 bytes. • MTU del trayecto: 800 bytes• Indique cuantos datagramas y bytes recibe

el nivel de red en el host de destino

Redes 6-94

IP Datos

Ejercicio 8: solución• Aplicación: 1540 bytes• TCP: 1540 + 20 = 1560• IP: 1560 + 20 = 1580• MTU = 800 bytes

IP TCP Datos

IP Datos

20 20

20

20

776

8

756

Múltiplo de 8 bytes

Redes 6-95

Ejercicio 9

P: Sesión TCP con 100 Mb/s de BW y 20 msde RTT. Calcular caudal máximo aprovechable.

R: De la fórmula: Ventana = BW * RTT obtenemos BW = Ventana / RTT

Sustituyendo:BW = 65535*8 / 0,02 = 26,2 Mb/s

Redes 6-96

Ejercicio 9Cálculo detallado (con segmentos de 1 Kbyte por ejemplo):0 ms TCP emisor empieza a enviar 1er segmento0,08 ms TCP emisor empieza a enviar 2º segmento0,16 ms TCP emisor empieza a enviar 3er segmento... ...5,16 ms TCP emisor empieza a enviar segmento 645,24 ms TCP emisor queda a la espera10 ms TCP receptor empieza a recibir 1er segmento10,08 ms TCP receptor devuelve primer ACK20,08 ms TCP emisor recibe primer ACK y empieza a

transmitir segmento 65

Eficiencia: 5,24/20,08 = 0,261 = 26,1 Mb/s

Redes 6-97

Ejercicio 12

• Una conexión TCP sobre medio físico poco fiable pierde una trama de cada 10. El nivel de enlace (PPP) descarta las tramas erróneas sin pedir reenvío. Preguntas:– Como evolucionará la ventana de congestión en el TCP

emisor (retransmisión selectiva)– Que merma cualitativa cabe esperar por la tasa de error:

• Menor del 10%• Alrededor del 10%• Mayor del 10%

– Como influiría el RTT en el rendimiento

Redes 6-98

Ventana cong. (KB) Trama Segmento Umbral peligro (KB)1 1 1

2,34,5,6,7

8,9,10,11,12,13,14,1510

16,1718,19,20,21

1 23 19 22 24,25 22,23 23 26,27,28 24,25,26 24 29,30,31,32 27,28,29,30 21 33 28 22 34,35 31,32 23 36,37,38 33,34,35 24 39,40,41,42 36,37,38,39 21 43 37 22 44,45 40,41 23 46,47,48 42,43,44 24 49,50,51,52 45,46,47,48 21 53 46 22 54,55 49,50 2

642 2,3 644 4,5,6,7 648 8,9,10,11,12,13,14,15 641 16 42 17,18 44 19,20,21,22 4

Evolución de la ventana de congestión de TCP

Redes 6-99

Descartar¿Trama long. entera ≥ 64 ≤ 1518?

Trama recibida

¿CRC correcto?

NoSíDescartarNo

Sí¿MAC destino reconocida? Descartar

NoSí

¿Checksum IP correcto? DescartarNoSí

Tarjeta de red

Driver Tarjeta

Proceso IP

Proceso TCP/UDP

Depositar contenido en buffer para proceso en puerto destino y devolver ACK (TCP)

¿IP destino reconocida? DescartarNoSí

¿Checksum TCP/UDP correcto? DescartarNoSí

¿Puerto destino reconocido? Descartar y

devolver ICMPdestino inacc.

NoSí

¿Datos duplicados (TCP)? Descartar ydevolver ACK

SíNo

Tarjetared

CPU

¿Protocolo reconocido? No

Sí Descartar ydevolver ICMPdestino inacc.

Proceso de una trama Ethernet TCP/IP recibida por un host

Redes 6-100

Internet

Broadcast en IP

147.156.1.2/24

147.156.1.3/24

147.156.1.200/24

………

147.156.255.2/24

ping 147.156.1.255

A recibe 199ICMP echo reply

ping 147.156.1.255

B recibe un ICMPecho reply (de X)

147.156.1.1/24

no ip directed-broadcast

ping 147.156.255.255

A

B

D

D recibe un ICMP echo reply (de X)

X

Y

147.156.2.2/24

C

ping 147.156.1.255

C recibe un ICMPecho reply (de X)

ping 147.156.2.255

D recibe un ICMP echo reply (de Y)

el nivel de transporte en internet - spw.cl wan ip-atm/tcp_udp.pdf · – campo protocolo en...

Documents