Tema 1bis. TCP y UDP (aka Tema 5. TCP y UDP)

Ingeniería de protocolos

Curso 2012/13

Jaime Benjumea Mondéjar

Dpto. Tecnología Electrónica

(Univ. de Sevilla)

Indice

• Protocolos de nivel de transporte.

• Servicios TCP.

• Cabecera TCP.

• Máquina de estados

• Inicio de conexión.

• Modo ESTABLISHED: – Transferencia de información.

– Control de flujo.

– Resolución de problemas.

• Cierre de conexión.

• Opciones TCP.

• Protocolo UDP

Protocolos de nivel de transporte en Internet

Aplicación

TCP / UDP

IP

Acceso al medio

físico

Aplicación

TCP / UDP

IP

Acceso al medio

físico

IP

Acceso al medio

físico

• Los protocolos de nivel de transporte

son los primeros considerados

extremo a extremo, no existen nodos

intermediarios entre origen y destino.

• Requieren un protocolo de nivel de

red que haga llegar la información al

otro extremo (sin éste no saben hacer

nada).

• El nivel de transporte, no está implementado en los nodos intermedios (routers), excepto cuando

éstos actúan como nodos finales (cuando los configuramos via telnet, cuando intercambian

información, cuando generan alarmas SNMP, etc.).

• Ofrecen conectividad a las aplicaciones, a través de sus servicios cuyo centro es el concepto de

puerto (que identifica un servicio dentro de una misma máquina).

• TCP (RFC793), ofrece un servicio orientado a la conexión.

• UDP (RFC768), ofrece un servicio NO orientado a la conexión.

• Existen aplicaciones que normalmente usan TCP: FTP, HTTP, SMTP y otras que normalmente

usan UDP: SNMP, DNS(*), TFTP. (*) También usa TCP dependiendo del tipo de respuesta.

TCP. Servicios

Puerto: Al igual que una dirección IP distingue una

máquina de otra, un puerto distingue un servicio

(aplicación) de otro en una misma máquina.

Socket: El par formado por IP+Puerto, identifica un

lado de la conexión. Cada ordenador tiene varios,

cada conexión se identifica por dos sockets.

192.168.5.10

22 25 80 110

SSH SMTP HTTP POP3

Puertos

Aplicaciones

Socket

Para las aplicaciones

más conocidas, se

suele usar siempre el

mismo puerto

• Transferencia de datos: Será Full-duplex, TCP es libre de retrasar el envío de un segmento (unidad

de transmisión), esperando más datos, pero se debe ofrecer la posibilidad de forzar el enviarlo (PUSH).

• Fiabilidad: TCP ofrece un servicio sin pérdidas, duplicidades ni desórdenes. Para ello se utilizan

números de secuencia, ACK y retransmisiones.

• Control de flujo: TCP ofrece un mecanismo para controlar la cantidad de información que se pone en

la red por unidad de tiempo. Para ello, con cada ACK, se indica la ventana máxima que estamos

dispuestos a aceptar.

• Multiplexación: TCP soporta múltiples conexiones sobre un mismo socket.

• Orientado a la conexión: Se establece un mecanismo para iniciar la conexión, antes de enviar datos,

y para terminarla.

Servicios

Cabecera TCP

Fuente: W. Stallings, Data and Computer

Comunications, 7ed. (Developed by Adrian J Pullin )

• TCP viaja sobre datagramas IP, Protocol=6.

• La longitud mínima de la cabecera TCP es 20bytes.

• Source & Destination Port (16 bits): Indican el puerto

origen y destino del segmento, estos datos junto con las

direcciones IP determinan la conexión concreta.

• Seq. Number (32 bits) : Es el número de secuencia del

primer octeto de datos del segmento, OJO: Cuenta bytes y no

segmentos.

• ACK (32 bits): Indica el número de secuencia esperado del

otro extremo (confirma, por tanto, todos los anteriores).

Nótese que tal y como aparece este número (esto es, en todos los segmentos), en TCP se permite piggybacking.

•Data offset (4 bits): Indica la longitud (en palabras de 32-bits) de la cabecera TCP. Indica dónde comienzan los datos.

• Reserved (6 bits): Reservado para usos futuros.

• Flags (6 bits): Se refieren a URG: El campo Urgente pointer es válido, ACK: El campo ACK es válido, PSH: Se refiere a la

función PUSH. RST: Sirve para resetear una conexión (por ejemplo si ya no es válida). SYN: Se usa para indicar el

comienzo de una conexión. FIN: Indica que se quiere finalizar la conexión en curso.

• Window: Número máximo de octetos, comenzando por el indicado en el ACK, que estamos dispuestos a aceptar. Permite

hace control de flujo independientemente de la recepción de un ACK (cosa que ocurría en los protocolos de v. deslizante).

• Checksum: Es un código de verificación tanto de la cabecera como de los datos, se incluye en el código de verficacación

una pseudocabecera que contiene la dirección IP fuente, IP destino, tipo de protocolo (6) y Longitud total (todo TCP).

• Urgent Pointer: Indica el offset que apunta al último byte de datos urgentes.

• Options: Indican una serie de opciones adicionales (que veremos posteriormente).

Máquina de estados TCP

Fuente:TCP/IP Illustrated, Volume 1 By W. Richard Stevens

Una conexión TCP puede estar: estableciéndose,

establecida, cerrándose o cerrada.

Una conexión se puede establecer de dos formas

distintas: Activa y pasiva.

Apertura pasiva

(servidor)

Servidor

Web

Apertura pasiva

en puerto 80/tcp (no se envían

datos)

TCP 80

El puerto 80/tcp permanece

“LISTENING”, esperando conexiones

remotas y asociado a su aplicación.

Apertura activa

(cliente)

Navegador

Web Solicita conexión a

<IPdest>, puerto

80/tcp

TCP 1309

TCP elige (de

forma dinámica),

un puerto

“anónimo” que

no esté en uso. Este será el puerto que

se use en esta parte

de la comunicación

TCP 80

Servidor WEB

TC

P

1309

TC

P

1509

Apertura activa

Conexió

n 1

Conexión 2

Apertura pasiva

dos conexiones al mismo

puerto a Multiplexación

Diagrama ilustrativo IP1

IP2

IP3

Las conexiones las inicia el

cliente, usando un puerto

anónimo (>1024), hacia un

puerto remoto.

En este ejemplo hay 3 sockets.

Y 2 conexiones

(IP2:1309,IP1:80 y

IP3:1509,IP1:80)

Puertos anónimos: Son los que

el SO escoge al hacer una

apertura activa, son aleatorios

y, no privilegiados (son

privilegiados del 1-1024).

Inicio de conexión TCP NOTA: Se ha usado Tethereal para

obtener estas secuencias.

tatooine -> titan.imse.cnm.es TCP 1229 > smtp [SYN] Seq=396871380 Ack=0 Win=16320 Len=0

Cliente SMTP

(tatooine)

Servidor

SMTP (titan) IP origen IP destino

Puerto origen (lado tatooine),

lo escoge el Sistema Operativo

Puerto destino, lo abre el servidor,

lo define la aplicación en el servidor

Bandera SYN activa,

Solicitud de conexión Numero de secuencia inicial

(sentido tatooine->titan),

No tiene sentido pues, el otro extremo

todavía no ha enviado nada, el flag ACK es cero.

Indica que hemos (tatooine) lanzado una solicitud de conexión y estamos a la espera de una respuesta (de titan). SYN_SENT

Indica que se ha efectuado una apertura pasiva, el puerto 25 de titan está así inicialmente. LISTEN

Significado Estado

titan.imse.cnm.es -> tatooine TCP smtp > 1229 [SYN, ACK] Seq=647453907 Ack=396871381 Win=24648 Len=0

SYN sigue activo, la conexión

no está iniciada aún

El ACK

está activo

Al ser un segmento de vuelta, se

intercambian puerto origen-destino.

Numero de secuencia inicial

(sentido tintan->tatooine).

Confirmo que he recibido el SYN (I), espero (de

tatooine) que el siguiente octeto sea este

I

II

III

Indica que espera (titan) la confirmación final después de haber recibido y enviado solicitudes de conexión. SYN_RCV

Significado Estado

tatooine -> titan.imse.cnm.es TCP 1229 > smtp [ACK] Seq=396871381 Ack=647453908 Win=16320 Len=0

En este caso el segmento SYN

(I), ha contado como un octeto,

por eso se añade uno más.

Este ACK, confirma que

se recibió el SYN (II).

Ninguno de estos tres

segmentos lleva datos

Indica que la conexión está activa. ESTABLISHED

Significado Estado

CLOSEDaSYN_SENT

LISTENaSYN_RCV

LISTEN

SYN_SENT

SYN_SENTaESTABLISHED

SYN_RCV

Pasa a EST.

cuando llegue

el ACK

Transferencia de datos

smtp > 1229 [PSH, ACK] Seq=647453908 Ack=396871381 Win=24648 Len=92

1229 > smtp [PSH, ACK] Seq=396871381 Ack=647454000 Win=16320 Len=15

Si finalmente llega el último ACK, tendremos a tatooine (izquierda) y a titan (derecha) en el estado

ESTABLISHED y, por tanto, dispuestos a transferir información.

Se envía el primer dato, de 92 bytes.

El flag PUSH indica que tatooine

debe entregar los datos al nivel de

aplicación “inmediatamente”.

Tatooine no tiene ahora datos que enviar, así

que simplemente confirma la recepción del

segmento anterior, el ACK es la suma de la

longitud más el número de segemento que titan

puso en su anterior segmento.

Números de secuencia tras el

establecimiento de conexión 396871381 647453908

1229 > smtp [ACK] Seq=396871381 Ack=647454000 Win=16228 Len=0 Eso es un solo ACK (len=0), no se confirma

Ahora tengo datos, los envío, podemos

observar que seq y ack son iguales que

antes (no hemos recibido ni enviado

nada desde el segmento anterior).

1229 > smtp [ACK] Seq=396871396 Ack=647454247 Win=16320 Len=0 Se confirma la recepción Eso es un solo ACK (len=0), no se confirma

Piggybacking

Esto si tenía datos así que

confirmo la recepción, pero sin

enviar datos adicionales.

smtp > 1229 [ACK] Seq=647454000 Ack=396871396 Win=24648 Len=0 a

smtp > 1229 [PSH, ACK] Seq=647454000 Ack=396871396 Win=24648 Len=247 Envío nuevos datos (247 bytes) b

Consiste en retener un poco un

ACK y enviarlo con un segmento

que tiene datos. Por ejemplo a y

b. Si retraso la salida del ACK (a),

puedo emitir un único segmento

que transmita los datos y haga de

ACK.

smtp > 1229 [PSH, ACK] Seq=647454000

Ack=396871396 Win=24648 Len=247

(De hecho es idéntico a “b”, “b” por si sólo

también hubiera hecho las funciones de “a”)

tatooine titan

Eso es un solo ACK (len=0), no se confirma

Retrasar un Ack “un poco”

mejora el uso de la red.

Pero retrasarlo mucho,

provocaría retransmisiones

inútiles

Control de flujo TCP

Buffer saturado:

No envío ACK.

Comienzan las

Retransmisiones

(innecesario)

Transmisor Receptor

Pro

ble

ma d

e c

ontr

ol

de f

lujo

con v

enta

na

desliz

ante

tra

dic

ional

…Ack=647454000 Win=16228 Len=0

El que transmite esto, indica lo máximo que puede recibir son

Win bytes contados desde el ack.

• TCP permite cambiar la ventana del transmisor de forma dinámica.

• El tamaño de la ventana lo anuncia el receptor en los segmentos que él

mismo envía.

• El transmisor sabe que no puede superar esa ventana (excepto URG).

Ejemplo de control de flujo (ventana en titan): (NOTA: Partimos de la trama III de la transparencia en la que se describe el inicio de conexión)

… Ack=647453908 Win=16320 Len=0

647453908 647470227

(datos enviados

y confirmados) (ventana de transmisión) (no los puedo

usar todavía)

Con ese segmento autorizo

el envío de 16320 bytes,

desde el lugar indicado.

En ese instante, titan enviaba datos (transparencia de transferencia de datos)

… Ack=396871381 Win=24648 Len=92 Se envían 92 bytes

de datos de

aplicación.

647453908 647470227

647453999 (datos enviados y

NO confirmados)

La ventana de

transmisión se

acorta por la

izquierda al

enviar datos

647454000

Tatooine, confirma la recepción, pero no aumenta la ventana

… Ack=647454000 Win=16228 Len=0 Win ahora 92 bytes

menos que el original,.

647470227

647454000

El control de flujo,

impide mover el

lado derecho a la

derecha a pesar

de recibir ack

Tatooine, más tarde, envía datos y de paso aumenta la ventana.

… Ack=647454000 Win=16320 Len=15 Ahora Win tiene el

valor original

647470319

647454000

Ahora el lado

derecho de la

ventana puede

desplazarse

Comportamiento ante problemas (I)

• TCP usa un esquema de corrección de errores similar al de ventana deslizante (vuelta atrás-N,

retransmisión por timeout).

• Pero hay errores en los que es necesario abortar la conexión (flag RST), en los casos en los que

claramente la conexión ya no es recuperable (caída de un extremo, cierre de la aplicación, etc).

2525 > 1660 [RST, ACK] Seq=0 Ack=3230986018 Win=0 Len=0

1660 > 2525 [SYN] Seq=3230986017 Ack=0 Win=16384 Len=0

2525/tcp

CLOSED

ssh >1665 [PSH, ACK] Seq=545722741

Ack=2864468475 Win=16060 Len=112 ESTABLISHED

CRASH

Este extremo (tatooine, cliente SSH)

“cae” sin previo aviso

1

1665 > ssh [RST] Seq=2864468475

Ack=2864468475 Win=0 Len=0

ssh > 1665 [PSH, ACK] Seq=545722741

Ack=2864468475 Win=16060 Len=112

ESTABLISHED

CLOSED

2

Titan todavía cree que la

conexión está activa (retransmite por timeout) Ese puerto (1665)

está cerrado en

tatooine

Se genera RST Se aborta la conexión

existente en titan

Situación 1. Puerto destino cerrado (CLOSED): Enviar RST al origen

1.1: Se intenta iniciar una conexión a un puerto

destino en titan que está cerrado. La respuesta es un

RST con numero de ACK uno más que el del SYN que

provoca el error.

1.2: Un extremo “cae”, tenemos un extremo de la conexión abierto y el otro cerrado por la caída (half-open connection), se envía un RST,

con el valor de Seq al indicado en el ACK el error.

Este es el caso típico de caída de cualquiera de los extremos (cliente o servidor) como

mecanismo para avisar al que no ha caído de que la conexión ya no es válida.

Es caso típico es si nos queremos conectar a un servicio (puerto) que no existe en el

destino, como mecanismo para avisarnos y no tener que esperar un timeout.

Comportamiento ante problemas (y II)

Recepción de RST

ssh > 1665 [RST] Seq=2864468475 Ack=2864468475 Win=0 Len=0

2525 > 1660 [RST, ACK] Seq=0 Ack=3230986018 Win=0 Len=0 Si el estado es

SYN-SENT Se valida que el ACK confirma el SYN anterior

Siguiente

estado

CLOSED

Resto de los

estados Se valida que el número de secuencia es

el válido para esta conexión.

Siguiente

estado

• Si originalmente estaba

LISTEN a LISTEN.

• Si estaba en SYN-RCV

(pero antes estaba en

LISTEN) a LISTEN

• Resto: CLOSED

Situación 2. Puerto destino en estado no sincronizado ( LISTEN, SYN-

SENT y SYN-RECEIVED). Se recibe un ACK inaceptable Enviar RST, NO

modificar estado local

smtp > 1234 [RST] Seq=420 Ack=420

Win=0 Len=0

1234 > smtp [ACK] Seq=123 Ack=420

Win=512 Len=0

ESTABLISHED

LISTEN

Se genera RST Se aborta la conexión

existente en tatooine

La situación es similar a la anterior, pero en este caso en

“titan” se ha vuelto a arrancar el servicio smtp

Situación 3. Resto de estados. Si se recibe un segmento con numero de seq o

ack no válidos, enviar un ack (vacío) con los números de seq y ack correctos.

ssh > 1093 [ACK] Seq=948910617

Ack=3275328194 Win=16480 Len=0

1093 > ssh [ACK] Seq=420 Ack=420

Win=512 Len=0

ESTABLISHED

ESTABLISHED

Se genera ACK

Puede tratarse de un

segmento que se ha

“perdido” y llega ahora

No es usa RST, dado que puede tratarse de segmentos

duplicados, retrasados, etc.

Cierre de conexión • Una conexión TCP puede cerrarse por parte de cualquier

extremo.

• La conexión es FDX, así que aunque un extremo cierre,

el otro puede enviarnos todavía datos antes de cerrar él.

El usuario cierra

la aplicación

Se informa al otro

lado: Yo no enviaré

más datos

El otro lado todavía

puede enviar datos

El otro lado, cierra: Yo

no tengo más que decir

Cierre de conexión visto desde el lado que inicia el cierre

T=1) Desde (p. ej.) ESTABLISHED, se solicita

(app) el cierre, se envía un segmento FIN

indicando yo no tengo más datos y se pasa a

FIN_WAIT1:

smtp > 1229 [FIN, ACK] Seq=647454324

Ack=396871408 Win=24648 Len=0

T=3) El otro lado me confirma la recepción del

FIN, paso a esperar a que él cierre su parte de

la conexión (FIN_WAIT2):

1229 > smtp [ACK] Seq=396871408

Ack=647454325 Win=16320 Len=0

T=5) El otro lado cierra su parte de la

conexión, confirmo la recepción y paso a

TIME_WAIT.

Envío

R

ecib

o

1229 > smtp [FIN, ACK] Seq=396871408

Ack=647454325 Win=16320 Len=0

smtp > 1229 [ACK] Seq=647454325

Ack=396871409 Win=24648 Len=0

Envío

R

ecib

o

Cierre de conexión visto desde el lado que recibe el cierre

smtp > 1229 [FIN, ACK] Seq=647454324

Ack=396871408 Win=24648 Len=0

Recib

o

T=2) Se recibe la petición de cierre del otro extremo,

se confirma con ACK (FIN=1byte) se pasa a

CLOSE_WAIT

1229 > smtp [ACK] Seq=396871408

Ack=647454325 Win=16320 Len=0 Envío

T=4) Mientras estábamos en el estado anterior, la

aplicación podía seguir enviando datos. Cuando la

app. ordena el cierre de su parte, enviamos FIN y

pasamos a LAST_ACK.

1229 > smtp [FIN, ACK] Seq=396871408

Ack=647454325 Win=16320 Len=0 Envío

T=6) Al recibir el ACK del FIN, pasamos al estado

CLOSED

smtp > 1229 [ACK] Seq=647454325

Ack=396871409 Win=24648 Len=0

Recib

o

Permanece en TIME_WAIT hasta asegurarse de que el ACK enviado ha llegado al

otro extremo, se considera válida una espera de 2 veces Maximun Segment

Lifetime

Si T=6 no se produce, después de un t/o se aborta la conexión (se pasa a CLOSED)

informando a la aplicación de este hecho.

Opciones TCP

MSS (Maximun Segment Size) OPTION: Indica el tamaño máximo del

segmento (es como una MTU respecto a la aplicación). Se suele tomar

como MTU-40. Por defecto 536. Pertenece a la especificación original 802.5

Ethernet [SYN], xxx,

MSS=4460

1

[SYN,ACK],

xxx, MSS=1460

2

Sólo se ve en segmentos

SYN, obliga al que lo recibe

a enviar como máximo ese

temaño.

Evita la fragmentación

sKbytes

RTT

WinMAX

/131

PROBLEMA: En comunicación por

satélite, el tamaño de ventana

máximo (216) es muy pequeño para

tanta latencia (RTT=500ms).

Velocidad

Máxima

posible

SOLUCIÓN: Usar ventanas mayores.

WINDOW SCALE OPTION (RFC1323): Especifica que la

ventana original tiene un shift left indicado por un campo de un

byte. NOTA: Máximo valor 14.

PROBLEMA: Medir correctamente

el RTT es crítico para establecer

los temporizadores.

Dato1, Tsopt = (12, 50)

ACK (Dato1), Tsopt = (52, 12)

TIMESTAMP OPTION (RFC1323): Indica (dos palabras

de 32-bits), dos temporizadores; el primero es el de ese

segmento; el segundo es un eco del segmento anterior del

otro lado. Por ejemplo: 12 es el eco.

PROBLEMA: El tiempo de

reutilización de números de

secuencia es 232 bytes = 4GBytes.

En los años 80 era suficiente.

En redes a 10Gbps,

1,25GBytes/s, el tiempo

de reutilización es: 3,2

seg

PROBLEMA: La fragmentación representa un problema de rendimiento.

SOLUCIÓN: Usar la opción Timestamp

PAWS (Protecion Against Wrapped Sequence Numbers)

(RFC1323): Utiliza la opción timestamp para detectar

segmentos antiguos.

PROBLEMA: El sistema de

vuelta atrás-N definido en TCP

es ineficiente para redes con alto

índice de errores y latencia

elevada (con ventanas grandes).

A B C

La ventana permite

transmitir A-B-C, sólo

B se pierde.

ACK (B)

El siguiente

que espera es

B (incluso si C

llegó bien)

B C Se tiene que

transmitir B y C

SACK (Selective ACK) OPTION (RFC2018): Se permite

indicar un rango de números de secuencia recibidos

correctamente, aunque haya un hueco sin recibir.

1-15 16-20 21-25

ACK (16),

Sack=(21,25)

El campo ACK sigue

indicando una confirmación

acumulativa, pero la opción

Sack, determina que los

bytes 21 a 25 si se han

recibido bien

Protocolo UDP

Fuente: W. Stallings, Data and Computer Comunications, 7ed. (Developed by Adrian J Pullin )

• Definido en el RFC 768 es una

alternativa de transporte a TCP.

• Es un protocolo no fiable, no

orientado a la conexión.

• Source Port: Si tiene sentido será distinto de cero, indica el puerto (aplicación) que origina ese datagrama. Se

puede asumir que, habitualmente, la respuesta que demos será a ese puerto origen.

• Dest. Port: Mismo significado que en TCP.

• Longitud: Indica la longitud del datagrama UDP completo (cabecera y datos), la cabecera siempre es 8 bytes.

• Checksum: Se utiliza igual que en TCP.

¿POR QUÉ UDP?

UDP es una alternativa barata y poco fiable de enviar datos, en determinadas ocasiones puede ser útil:

• Sistemas de arranque remoto, desde tarjeta de red, es mucho más sencillo implementar UDP que TCP (ahorro en

el chip de arranque de la tarjeta), además en LAN la probabilidad de error es pequeña.

• A veces me interesa hacer la conexión sin mucho overhead como puede ocurrir con DNS.

• A veces el control de errores no me importa, transmisión de video por Internet (no merece la pena retransmitir,

porque el dato llegará tarde y no se usará).

• A veces el control de errores es imposible: Recepción de TV. por satélite.