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
• Los protocolos de nivel de transporte
Aplicación Aplicación son los primeros considerados
extremo a extremo, no existen nodos
TCP / UDP TCP / UDP
intermediarios entre origen y destino.
IP IP IP
• Requieren un protocolo de nivel de
Acceso al medio Acceso al medio Acceso al medio red que haga llegar la información al
físico físico físico
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
Aplicaciones
Puerto: Al igual que una dirección IP distingue una SSH SMTP HTTP POP3
máquina de otra, un puerto distingue un servicio
Puertos 22 25 80 110 Para las aplicaciones
(aplicación) de otro en una misma máquina. más conocidas, se
192.168.5.10 suele usar siempre el
Socket: El par formado por IP+Puerto, identifica un mismo puerto
lado de la conexión. Cada ordenador tiene varios, Socket
cada conexión se identifica por dos sockets.

Servicios
• 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.
 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
 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 Apertura activa
(servidor) (cliente)

Servidor Navegador
Solicita conexión a
Web <IPdest>, puerto Web
80/tcp
Apertura pasiva (no se envían
en puerto 80/tcp datos)

TCP TCP elige (de TCP

80 forma dinámica), 1309
un puerto
El puerto 80/tcp permanece “anónimo” que Este será el puerto que
“LISTENING”, esperando conexiones no esté en uso. se use en esta parte
remotas y asociado a su aplicación. de la comunicación

Servidor WEB
Diagrama ilustrativo Apertura pasiva
IP1

 Las conexiones las inicia el dos conexiones al mismo

cliente, usando un puerto puerto a Multiplexación
anónimo (>1024), hacia un

Conexión 1
puerto remoto.
IP2 TCP

TCP
1309
 En este ejemplo hay 3 sockets. 80
 Y 2 conexiones
(IP2:1309,IP1:80 y
IP3:1509,IP1:80)
IP3

TCP
1509
Puertos anónimos: Son los que Conexión 2
el SO escoge al hacer una
apertura activa, son aleatorios
Fuente:TCP/IP Illustrated, Volume 1 By W. Richard Stevens y, no privilegiados (son
privilegiados del 1-1024). Apertura activa
NOTA: Se ha usado Tethereal para
obtener estas secuencias.
Inicio de conexión TCP
Cliente SMTP Servidor
Puerto destino, lo abre el servidor, No tiene sentido pues, el otro extremo
(tatooine) IP origen IP destino lo define la aplicación en el servidor todavía no ha enviado nada, el flag ACK es cero.
SMTP (titan)

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

I Puerto origen (lado tatooine), Bandera SYN activa, Numero de secuencia inicial
LISTEN
CLOSEDaSYN_SENT lo escoge el Sistema Operativo Solicitud de conexión (sentido tatooine->titan),

Estado Significado
LISTEN Indica que se ha efectuado una apertura pasiva, el puerto 25 de titan está así inicialmente.
SYN_SENT Indica que hemos (tatooine) lanzado una solicitud de conexión y estamos a la espera de una respuesta (de titan).

SYN sigue activo, la conexión El ACK Confirmo que he recibido el SYN (I), espero (de
no está iniciada aún está activo tatooine) que el siguiente octeto sea este

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

II Al ser un segmento de vuelta, se Numero de secuencia inicial LISTENaSYN_RCV

SYN_SENT intercambian puerto origen-destino. (sentido tintan->tatooine).

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

Pasa a EST.
tatooine -> titan.imse.cnm.es TCP 1229 > smtp [ACK] Seq=396871381 Ack=647453908 Win=16320 Len=0 cuando llegue
III el ACK

En este caso el segmento SYN Este ACK, confirma que Ninguno de estos tres SYN_RCV
(I), ha contado como un octeto, se recibió el SYN (II). segmentos lleva datos
SYN_SENTaESTABLISHED por eso se añade uno más.

Estado Significado
ESTABLISHED Indica que la conexión está activa.

 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.
396871381
tatooine
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.
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).
Eso es un solo ACK (len=0), no se confirma
smtp >
Se confirma la recepción
Piggybacking
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.
Transferencia de datos
Números de secuencia tras el
establecimiento de conexión 647453908 titan
Se envía el primer dato, de 92 bytes.
El flag PUSH indica que tatooine
smtp > 1229 [PSH, ACK] Seq=647453908 Ack=396871381 Win=24648 Len=92 debe entregar los datos al nivel de
aplicación “inmediatamente”.
1229 > smtp [ACK] Seq=396871381 Ack=647454000 Win=16228 Len=0 Eso es un solo ACK (len=0), no se confirma
1229 > smtp [PSH, ACK] Seq=396871381 Ack=647454000 Win=16320 Len=15 Esto si tenía datos así que
confirmo la recepción, pero sin
enviar datos adicionales.
a 1229 [ACK] Seq=647454000 Ack=396871396 Win=24648 Len=0
smtp >
b 1229 [PSH, ACK] Seq=647454000 Ack=396871396 Win=24648 Len=247
Envío nuevos datos (247 bytes)
1229 > smtp [ACK] Seq=396871396 Ack=647454247 Win=16320 Len=0 Eso es un solo ACK (len=0), no se confirma
 Retrasar un Ack “un poco”
mejora el uso de la red.
smtp > 1229 [PSH, ACK] Seq=647454000
Ack=396871396 Win=24648 Len=247
 Pero retrasarlo mucho,
(De hecho es idéntico a “b”, “b” por si sólo provocaría retransmisiones
también hubiera hecho las funciones de “a”)
inútiles
 Transmisor Receptor
Control de flujo TCP
• TCP permite cambiar la ventana del transmisor de forma dinámica.
deslizante tradicional
Problema de control
de flujo con ventana

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

mismo envía.
Buffer saturado:
No envío ACK. • El transmisor sabe que no puede superar esa ventana (excepto URG).
Comienzan las El que transmite esto, indica lo máximo que puede recibir son
Retransmisiones …Ack=647454000 Win=16228 Len=0 Win bytes contados desde el ack.
(innecesario)

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)
647453908 647470227
Con ese segmento autorizo
… Ack=647453908 Win=16320 Len=0
el envío de 16320 bytes,
desde el lugar indicado. (datos enviados (ventana de transmisión) (no los puedo
y confirmados) usar todavía)

 En ese instante, titan enviaba datos (transparencia de transferencia de datos) 647454000 La ventana de
647453908 647470227
transmisión se
Se envían 92 bytes acorta por la
… Ack=396871381 Win=24648 Len=92
de datos de izquierda al
(datos enviados y 647453999
aplicación. enviar datos
NO confirmados)

Tatooine, confirma la recepción, pero no aumenta la ventana El control de flujo,

647470227 impide mover el
lado derecho a la
… Ack=647454000 Win=16228 Len=0 Win ahora 92 bytes derecha a pesar
menos que el original,. de recibir ack
647454000

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

647470319 Ahora el lado
derecho de la
… Ack=647454000 Win=16320 Len=15 Ahora Win tiene el ventana puede
valor original desplazarse
647454000
 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).

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

 1.1: Se intenta iniciar una conexión a un puerto 1660 > 2525 [SYN] Seq=3230986017 Ack=0 Win=16384 Len=0
destino en titan que está cerrado. La respuesta es un
2525/tcp
RST con numero de ACK uno más que el del SYN que CLOSED
2525 > 1660 [RST, ACK] Seq=0 Ack=3230986018 Win=0 Len=0
provoca el error.

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.

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.
Titan todavía cree que la
(retransmite por timeout) Ese puerto (1665)
conexión está activa
está cerrado en
tatooine
2 ssh > 1665 [PSH, ACK] Seq=545722741
1 Ack=2864468475 Win=16060 Len=112
CRASH CLOSED
ssh >1665 [PSH, ACK] Seq=545722741
Ack=2864468475 Win=16060 Len=112
ESTABLISHED ESTABLISHED
1665 > ssh [RST] Seq=2864468475
Este extremo (tatooine, cliente SSH) Se aborta la conexión Ack=2864468475 Win=0 Len=0 Se genera RST
“cae” sin previo aviso existente en titan

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.
 Comportamiento ante problemas (y II)

Situación 2. Puerto destino en estado no sincronizado ( LISTEN, SYN- Situación 3. Resto de estados. Si se recibe un segmento con numero de seq o
SENT y SYN-RECEIVED). Se recibe un ACK inaceptable Enviar RST, NO ack no válidos, enviar un ack (vacío) con los números de seq y ack correctos.
modificar estado local

Puede tratarse de un 1093 > ssh [ACK] Seq=420 Ack=420

1234 > smtp [ACK] Seq=123 Ack=420
segmento que se ha Win=512 Len=0
Win=512 Len=0
LISTEN “perdido” y llega ahora ESTABLISHED

ESTABLISHED
smtp > 1234 [RST] Seq=420 Ack=420 ssh > 1093 [ACK] Seq=948910617
Se aborta la conexión Win=0 Len=0 Se genera RST ESTABLISHED Ack=3275328194 Win=16480 Len=0 Se genera ACK
existente en tatooine

La situación es similar a la anterior, pero en este caso en No es usa RST, dado que puede tratarse de segmentos
“titan” se ha vuelto a arrancar el servicio smtp duplicados, retrasados, etc.

Recepción de RST

2525 > 1660 [RST, ACK] Seq=0 Ack=3230986018 Win=0 Len=0 CLOSED
Si el estado es
Siguiente
SYN-SENT Se valida que el ACK confirma el SYN anterior estado

• Si originalmente estaba
LISTEN a LISTEN.
ssh > 1665 [RST] Seq=2864468475 Ack=2864468475 Win=0 Len=0 • Si estaba en SYN-RCV
Resto de los (pero antes estaba en
Siguiente
estados
Se valida que el número de secuencia es
estado
LISTEN) a LISTEN
el válido para esta conexión.
• Resto: CLOSED
 Cierre de conexión Se informa al otro
lado: Yo no enviaré
El usuario cierra
• Una conexión TCP puede cerrarse por parte de cualquier la aplicación
más datos

El otro lado todavía

extremo. puede enviar datos

• La conexión es FDX, así que aunque un extremo cierre, El otro lado, cierra: Yo
no tengo más que decir
el otro puede enviarnos todavía datos antes de cerrar él.

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

T=1) Desde (p. ej.) ESTABLISHED, se solicita T=2) Se recibe la petición de cierre del otro extremo,
se confirma con ACK (FIN=1byte) se pasa a
(app) el cierre, se envía un segmento FIN CLOSE_WAIT
indicando yo no tengo más datos y se pasa a

Recibo
FIN_WAIT1: smtp > 1229 [FIN, ACK] Seq=647454324
Ack=396871408 Win=24648 Len=0
Envío

smtp > 1229 [FIN, ACK] Seq=647454324

Ack=396871408 Win=24648 Len=0

Envío
1229 > smtp [ACK] Seq=396871408
Ack=647454325 Win=16320 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): T=4) Mientras estábamos en el estado anterior, la
aplicación podía seguir enviando datos. Cuando la
Recibo

1229 > smtp [ACK] Seq=396871408 app. ordena el cierre de su parte, enviamos FIN y
Ack=647454325 Win=16320 Len=0 pasamos a LAST_ACK.

Envío
1229 > smtp [FIN, 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.
T=6) Al recibir el ACK del FIN, pasamos al estado
Recibo

1229 > smtp [FIN, ACK] Seq=396871408 CLOSED

Ack=647454325 Win=16320 Len=0
Recibo

smtp > 1229 [ACK] Seq=647454325

Envío

smtp > 1229 [ACK] Seq=647454325 Ack=396871409 Win=24648 Len=0

Ack=396871409 Win=24648 Len=0

Permanece en TIME_WAIT hasta asegurarse de que el ACK enviado ha llegado al Si T=6 no se produce, después de un t/o se aborta la conexión (se pasa a CLOSED)
otro extremo, se considera válida una espera de 2 veces Maximun Segment informando a la aplicación de este hecho.
Lifetime
 Opciones TCP
PROBLEMA: La fragmentación representa un problema de rendimiento. 1 Ethernet Sólo se ve en segmentos
[SYN], xxx, SYN, obliga al que lo recibe
MSS=4460 a enviar como máximo ese
MSS (Maximun Segment Size) OPTION: Indica el tamaño máximo del
temaño.
segmento (es como una MTU respecto a la aplicación). Se suele tomar 802.5
como MTU-40. Por defecto 536. Pertenece a la especificación original 2
[SYN,ACK], Evita la fragmentación
xxx, MSS=1460

Velocidad
SOLUCIÓN: Usar ventanas mayores.
PROBLEMA: En comunicación por Máxima
satélite, el tamaño de ventana posible
WinMAX WINDOW SCALE OPTION (RFC1323): Especifica que la
máximo (216) es muy pequeño para  ventana original tiene un shift left indicado por un campo de un
tanta latencia (RTT=500ms). RTT
byte. NOTA: Máximo valor 14.
 131Kbytes / s

TIMESTAMP OPTION (RFC1323): Indica (dos palabras

PROBLEMA: Medir correctamente
el RTT es crítico para establecer
los temporizadores.
Dato1, Tsopt = (12, 50)
de 32-bits), dos temporizadores; el primero es el de ese
ACK (Dato1), Tsopt = (52, 12) segmento; el segundo es un eco del segmento anterior del
otro lado. Por ejemplo: 12 es el eco.

PROBLEMA: El tiempo de En redes a 10Gbps, SOLUCIÓN: Usar la opción Timestamp

reutilización de números de 1,25GBytes/s, el tiempo PAWS (Protecion Against Wrapped Sequence Numbers)
secuencia es 232 bytes = 4GBytes. de reutilización es: 3,2 (RFC1323): Utiliza la opción timestamp para detectar
En los años 80 era suficiente. seg segmentos antiguos.

La ventana permite
transmitir A-B-C, sólo El siguiente SACK (Selective ACK) OPTION (RFC2018): Se permite
PROBLEMA: El sistema de B se pierde. que espera es
vuelta atrás-N definido en TCP indicar un rango de números de secuencia recibidos
B (incluso si C
es ineficiente para redes con alto llegó bien) correctamente, aunque haya un hueco sin recibir.
C B A
índice de errores y latencia El campo ACK sigue
elevada (con ventanas grandes). 21-25 16-20 1-15 indicando una confirmación
ACK (B)
acumulativa, pero la opción
Se tiene que ACK (16), Sack, determina que los
C B
transmitir B y C Sack=(21,25) bytes 21 a 25 si se han
recibido bien
 Protocolo UDP
• Definido en el RFC 768 es una
alternativa de transporte a TCP.
• Es un protocolo no fiable, no
Fuente: W. Stallings, Data and Computer Comunications, 7ed. (Developed by Adrian J Pullin )
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.