TEMA 3: CAPA DE TRANSPORTE EN INTERNET

1. INTRODUCCIÓN

La función principal del nivel de transporte es aceptar los datos de las capas superiores,
dividirlos si es necesario, en unidades más pequeñas y pasarlos al nivel de red
garantizando que lleguen a su destino de una forma económica y segura,
independientemente la red o redes físicas que se encuentren en uso.

Entidades de transporte: hardware y/o software que se encargan de realizar este

trabajo. El dialogo entre entidades de transporte es extremo a extremo.

El nivel de transporte mejora la calidad ofrecida por el nivel de red mediante:

• La multiplexación/demultiplexación.
• La introducción de redundancia en la información

La capa de transporte es el enlace entre la capa de aplicación y la capa inferior que es

responsable de la transmisión de la red. Esta capa acepta los datos de diferentes
conversaciones y las pasa a las capas inferiores como partes manejables que se pueden
multiplexar de forma eventual en la red.
NOTA: en la capa de transporte “conversación” se conoce como cada conjunto de datos
que fluye entre una aplicación de origen y una de destino.
El protocolo de transporte proporciona un servicio de transferencia de datos extremo-a-
extremo.
Própositos de la capa de transporte:
La capa de transporte permite la segmentación de datos y brinda el control necesario
para reensamblar las partes dentro de los distintos flujos de datos.
Las responsabilidades principales que debe cumplir son:
 Rastreo de comunicación individual entre origen y destino
 Segmentación de datos y manejo de cada parte
 Reensamble de segmentos
 Identificación de diferentes aplicaciones
Rastreo de comunicación individual entre origen y destino
Un host puede tener varias aplicaciones que se comunican a través de la red de forma
simultánea. Cada una de estas aplicaciones se comunica con una o más aplicaciones
en uno o más hosts remotos. Es responsabilidad de la capa de transporte mantener y
hacer un seguimiento de todas estas conversaciones.

Segmentación de datos y manejo de cada parte

Se deben preparar los datos para el envío a través de los medios en partes manejables.
La mayoría de las redes tienen un límite de la cantidad de datos que se puede incluir en
un solo paquete. Los protocolos de la capa de transporte tienen servicios que
segmentan los datos de aplicación en bloques de un tamaño apropiado. Estos servicios
incluyen el encapsulamiento necesario en cada porción de datos. Se agrega un
encabezado a cada bloque de datos para el rearmado. Este encabezado se utiliza para
hacer un seguimiento del flujo de datos.
Reensamble de segmentos:
En el host de recepción, cada sección de datos se puede direccionar a la aplicación
adecuada. Además, estas secciones de datos individuales también deben reconstruirse
para generar un stream completo de datos que sea útil para la capa de aplicación. Los
protocolos en la capa de transporte describen cómo se utiliza la información del
encabezado de la capa para reensamblar las partes de los datos en streams para
pasarlos a la capa de aplicación.
Identificación de diferentes aplicaciones:
Para pasar los flujos a las aplicaciones adecuadas, la capa de transporte asigna un
identificador a cada aplicación, llamado número de puerto. A todos los procesos de
software que requieran acceso a la red se les asigna un número de puerto exclusivo
para ese host.

A diferencia de lo que ocurre en la capa red, donde solo existe el protocolo IP para llevar
a cabo las funcionalidades de direccionamiento y encaminamiento, para la capa de
transporte se especifican dos alternativas: UDP y TCP. El primer protocolo se
caracteriza por ofrecer, al igual que IP, un servicio no fiable y no orientado a conexión.
Por el contrario, TCP ofrece un servicio orientado a conexión que incluye el control de
flujo, control de errores y control de congestión.

Multiplexación: varias conexiones de transporte en una conexión red. Se utiliza cuando

el coste por conexión de servicio de red es elevado
 2. PROTOCOLO DE DATAGRAMA DE USUARIO (UDP)

El protocolo UDP se encapsula sobre IP, tomando el campo “protocolo” del datagrama IP el valor
17. UDP
utiliza la funcionalidad ‘best effort’ (intenta lo mejor pero no lo asegura). RFC es un manual para
saber cómo funcionan las reglas de comunicación de UDP.
Sus principales características son:
 Servicio no orientado a conexión
 Servicio no fiable
 No hay garantías de entrega ordenada: esto implica que si has basado tu programa en
UDP, hay que programar que se ordenen los paquetes. Se programa en la capa de
aplicación con sockets.
 No hay control de congestión: entrega tan rápida como se pueda.
 Hace comprobaciones de errores, luego si un paquete está mal, lo desecha.
 Multiplexación/demultiplexación: transporta las TDPU al proceso correcto

Suele usarse para aplicaciones multimedia, ya que son tolerantes a fallos y sensibles a retardos.

La TDPU de UDP se denomina datagrama de usuario, datagrama UDP o paquete UDP.

Cada datagrama UDP se envía con un único datagrama IP y tiene los siguientes componentes:

 Porigen: campo de 16 bits que especifica el puerto del proceso que envía.
 Pdestino: campo de 16 bits que identifica el puerto del proceso destino.
 Longitud UDP: 16 bits que indican el número de octetos de que consta el datagrama
UDP completo.
 Comprobación (checksum): campo redundante que contiene la suma de comprobación
usual, es decir, el complemento a uno de la suma en complemento a uno de todo el
datagrama y de una pseudo-cabecera que contiene los siguientes cuatro campos:
dirección IP origen, dirección IP destino, protocolo del paquete IP y campo longitudUDP
del datagrama.

 Datos: este campo contiene la PDU de capa superior.

En general, un protocolo se denomina cross-layer cuando considera información de otras capas

como por ejemplo la pseudo-cabecera UDP En este caso, el considerar en el cálculo del campo
comprobación las direcciones IP tiene como objetivo proporcionar una garantía extra de fiabilidad
para evitar que información no deseada llegue a direcciones IP equivocadas.
Sobre el servicio ofrecido por IP, UDP solo añade multiplexación, es decir, introduce un esquema
de direccionamiento extra basado en los puertos que permite identificar las aplicaciones origen
y destino del datagrama, es decir, en lugar de considerar los identificadores de proceso para
indicar el destino de una comunicación TCP/IP, se recurre al concepto de puerto.

ASIGNACIÓN DE PUERTOS UDP

Los números de puertos se pueden asignar de dos formas:
- Asignación estática: existe una autoridad central que asigna los números de puerto
conforme se necesitan y publica la lista de todas las asignaciones. Este enfoque se
conoce como enfoque universal y las asignaciones de puerto especificada se conocen
como asignaciones bien conocidas.

- Asignación dinámica: siempre que un proceso necesita un puerto el software de red

le asignará uno.

El campo de puerto tiene una longitud de 16 bits, lo que permite un rango que va desde 0 a
65535, pero no todos estos puertos son de libre uso:
- El puerto 0 es un puerto reservado, pero es un puerto permitido si el emisor no permite
respuestas del receptor.
- Los puertos 1 a 1023 reciben el nombre de Puertos bien conocidos, y en sistemas Unix,
para enlazar con ellos, es necesario tener acceso como superusuario.
- Los puertos 1024 a 49151 son los llamados puertos registrados, y son los de libre
utilización.
- Los puertos del 491552 al 65535 son puertos efímeros, de tipo temporal, y se utilizan
sobre todo por los clientes al conectar con el servidor.

3. PROTOCOLO DE CONTROL DE TRANSMISIÓN (TCP)

Características del “Transmission Control Protocol” (las especificaciones de TCP se

encuentran detalladas en el RFC 793):
- Servicio punto a punto: no sirve para comunicaciones multicast (de uno a muchos).
- Servicio orientado a conexión, permitiendo el envío secuencial de los datos, es decir,
estos se reciben en el mismo orden en que fueron transmitidos, se conoce como envio
orientado a flujo (“stream oriented”). Exige un estado común entre el emisor y el receptor:
“hand-shaking”.
- Entrega ordenada de las secuencias de bytes generadas por la aplicación (“stream
oriented”).
- Transmisión full-duplex, es decir, hay dos sentidos en la comunicación: cliente-servidor
y servidor-cliente. Ambos sentidos se tratan de forma independiente.
- Mecanismo de detección y recuperación de errores (ARQ) con confirmaciones
positivas ACKs (acumulativas) y “timeouts” adaptables.
- Servicio extremo a extremo fiable que incluye control de congestión y control de flujo
con ventanas deslizantes con tamaño máximo adaptable.
- Incorporación de confirmaciones (“piggybacking”).
Piggybacking: en vez de enviar ACK en un paquete individual, éste es incluido dentro del
próximo paquete a enviar, por lo que se minimizan la cantidad de paquetes a enviar.

A diferencia de UDP, TCP implementa todas las funciones necesarias para llevar a cabo un
control de transmisión extremo a extremo entre dos estaciones finales.

SEGMENTO TCP

La TPDU de TCP denominada “segmento TCP” es más compleja que la cabecera de UDP.
Tiene más metadatos (los necesitamos para mantener la comunicación entre origen y
destino). Se definen los siguientes campos:

• Puerto origen: También estaba en UDP.

• Puerto destino: También estaba en UDP.
• Número de secuencia: Permite al receptor saber a qué elemento corresponde ese
paquete.
• Número de “acuse” de recibo (ACK): Está muy relacionado con el número de secuencia,
pero en la otra dirección. El ACK es el número de secuenica del siguiente paquete que se
espera recibir, quedando confirmados los anteriores. Por ejemplo, supongamos que los
números de secuencia empiezan en 25. Si el servidor recibe los bytes del 25 al 30, emite un
ACK=31 confirmando que se han recibido los bytes anteriores a 31. A continuación el
receptor enviará los bytes a partir del 31.
• HLEN: La cabecera TCP tiene un tamaño variable, y por eso existe este campo. Muestra
la longitud de la cabecera.
• Reservado: campo de 3 bits sin uso específico (normalmente con valor 000).
• UAPRSF: Son flags TCP. Si están a 0 no implica nada, pero si están a 1 es que el paquete
contiene “cosas” especiales:
o A: El paquete lleva ACK con Piggybacking. Si la A está puesto a 0, ni se mira el
campo de “acuse” de recibo, ya que el receptor no nos envía nada.
 o P: Es push. Se utiliza para decir que el paquete es urgente.
o R: Reset. Se utiliza para resetear la comunicación.
o S: Sincronización. Se utiliza para designar qué paquete es el que inicia el three-way
handshake (la comunicación).
o F: De finalizar. Se utiliza para designar qué paquete es el que acaba la
comunicación.
• “Ventana” del receptor: Se utiliza para hacer control de flujo. El mecanismo consiste en
que el emisor envía paquetes de tres en tres (ventana). Envía los paquetes 1, 2, 3. Cuando
reciba la confirmación por parte del receptor que ha recibido el paquete 1, ya puede enviar
el paquete 4. Y así sucesivamente. Es más eficiente ya que no tiene que esperar en cada
paquete que envía, los envía por conjunto y espera la confirmación de uno de ellos. TCP va
a agrandar y disminuir la ventana usando una heurística según la congestión de la red. Si el
receptor va bien, aumenta la ventana. Un problema de esto es que pueden llegar los
paquetes desordenados, pero como están ordenados por el número de secuencia, no habría
problema.
• Puntero: Es un puntero que se utiliza para apuntar los paquetes urgentes. Este puntero
apunta a partir de qué paquete deja de ser urgente.
• Datos: campo en el que se transporta el mensaje generado por la aplicación. Aunque la
longitud de este campo no se especifica explícitamente se puede calcular a partir de la
siguiente sencilla operación:
tlenIP - hlenIP*4 - hlenTCP*4, donde tlenIP es el número total de octetos del datagrama IP
(cabecera IP + segmento TCP) y hlenIP y hlenTCP, las longitudes en palabras de 32 octetos,
de la cabecera IP y de la cabecera TCP, respectivamente.
• Opciones: Este campo de longitud variable puede presentar dos formatos distintos: a) un
único octeto que define el tipo de opción o b) un octeto de tipo de opción más un octeto que
indica la longitud de los datos correspondientes a la opción seguida de los datos como tales.
Inicialmente solo existen especificados tres tipos de opciones:
- 0: fin de la lista de opciones.
- 1: sin operación, utilizado como relleno para hacer que la longitud de la cabecera del
segmento TCP sea múltiplo de 32 bits.
- 2: tamaño máximo del segmento.

A. MULTIPLEXACIÓN Y DEMULTIPLEXACIÓN

El servicio de multiplexación permite que varias aplicaciones ejecutadas en el mismo host

(origen o destino) puedan comunicarse entre sí usando TCP. La conexión TCP se identifica por
puerto e IP origen y puerto e IP destino (y opcionalmente protocolo).

Existen puertos preasignados con servicios normalizados:

B. CONTROL DE CONEXIÓN

TCP ofrece un servicio fiable orientado a conexión, es decir, previo al intercambio de los datos,
entre las dos aplicaciones finales se establece una conexión y una vez finalizada la transmisión
se procederá al cierre de la conexión.
Para establecer una conexión TCP es necesario acoplar las entidades origen y destino mediante
la definición de un estado común a ambas. La conexión puede explicarse como una “tubería”
(full-duplex) establecida entre las dos aplicaciones a través de la cual todos los segmentos que
entran por uno de los extremos salen por el otro. Para establecer dicha conexión es necesario
una fase previa al intercambio de datos denominada establecimiento de la conexión donde se
define el estado común de ambas entidades y mediante la que se reservan recursos del sistema.
Tras el intercambio, debe haber una fase de cierre de conexión, en la que se liberan los recursos
reservados del sistema, tanto en el emisor como en el receptor. Ambos procedimientos se llevan
a cabo usando los bits R, S y F del campo control definidos en el segmento TCP.

- Establecimiento de la conexión: debido a que en la capa de red contamos con un

servicio no fiable que ofrece IP, por tanto, el establecimiento de la conexión no es
fiable ya que se pueden perder los segmentos intercambiados. Para reducir este
problema, el establecimiento de la conexión se lleva a cabo en tres pasos (“three-
way handshake”) que consiste en el intercambio de tres segmentos entre la entidad
de origen y destino:

a) Solicitud de conexión: uno de los extremos envía un segmento con el flag S

activado indicando el deseo de iniciar una conexión y en ese mismo segmento,
en el campo secuencia se especifica un número arbitrario (de 32 bits) a partir del
cual se numeran los segmentos.
b) Aceptación de conexión y solicitud en el otro sentido: Cuando llega el
paquete al destino, lo recibe y si tiene recursos para hacer la conexión, confirma
la conexión. El servidor responde con un paquete SYN-ACK (SYN porque el
servidor también quiere conectarse y ACK porque está confirmando la recepción
del primer paquete). El servidor, a su vez, genera otro número de secuencia
aleatorio. En el número de “acuse” de recibo manda el mismo que ha recibido
sumándole 1 (el número de acuse es el siguiente byte que espera del receptor,
 no el último que ha leído.). El número de secuencia es el número que identifica
al primer byte.
c) Conexión establecida: El tercer paquete ya no tiene el flag S. Pero sí el flag A.
El número de secuencia es X+1. Y el número de acuse de recibo de Y+1 para
que empiece a mandarnos los bytes correspondientes.

NÚMEROS DE SECUENCIA

MSL: tiempo de vida de segmento máximo

- Cierre de la conexión: el procedimiento de cierre de conexión es análogo al seguido
en su establecimiento con la diferencia que ahora el flag del campo control no es
SYN sino FIN. La desconexión puede realizarla tanto el cliente como el servidor y
una vez efectuada la desconexión el host que inició el proceso está un cierto tiempo
a la espera por si aparecen segmentos retrasados.

AUTÓMATA DE ESTADOS FINITOS TCP (Explicado en el libro págs: 337,338)

 C. CONTROL DE ERRORES Y DE FLUJO

El control de errores utiliza el esquema ARQ con confirmaciones positivas y acumulativas, es de

decir, requiere de confirmaciones positivas por parte del receptor. Se denominan acumulativas
porque no es necesario confirmar uno a uno todos los segmentos recibidos, sino que es posible
confirmar más de uno de forma simultánea. Esto significa que si recibo un ACK = 28, quiero decir
que todo lo anterior al 28 me ha llegado bien y estoy esperando el 28.

Los campos del segmento TCP involucrados en el control de errores son los siguientes:
• Campo secuencia: Offset (en bytes) dentro del mensaje que indica la posición que ocupa el
primer octeto del campo datos. Permite la entrega ordenada.
• Campo de “acuse” de recibo: indica el número de byte que se espera recibir en el destino.
Dado su carácter acumulativo, recibe un determinado valor en el campo acuse que confirma
todos los bytes pendientes de confirmación hasta justo el anterior (Si A=1, el campo acuse debe
ser tenido en cuenta por el receptor, mientras que si A=0 no).
• Bit A (ACK) del campo de control: este bit indica la validez o no de la confirmación de acuse.
• Campo comprobación: checksum (se calcula igual que en UDP) de todo el segmento y eso
de pseudo-cabecera. Permite al receptor determinar si el segmento se ha recibido correctamente
o no.

ESCENARIOS DE RETRANSMISIÓN

1. Pérdida de ack:
Host A le quiere mandar un mensaje a Host B. En un determinado momento, Host A manda un
segmento con el campo de secuencia a 92 (esto significa que el primer byte de este segmento
tiene el número de secuencia 92). Se manda el 92 con 8 bytes de datos, es decir, se está
mandando hasta el byte 99. El host B le responde con un ACK = 100, que es el siguiente que
espera. En este caso, el ACK se pierde. El host A no puede eliminar los paquetes que ha enviado
de su buffer hasta que reciba el ACK. Como se ha perdido el ACK, el temporizador que tiene el
host A se activa y lo tiene que volver a enviar. Como el host B ya había recibido el paquete que
le ha vuelto a mandar el host A, tira el segmento a la basura porque ya lo tenía y, simplemente,
vuelve a enviar el ACK = 100.
2. Timeout prematuro y ACK acumulativo.
El host A manda dos segmentos a la vez, el 92 con 8 bytes (hasta el 99), y el segundo segmento
con número de secuencia 100 con 20 bytes de datos (hasta el 119). En cuanto le llega el primer
segmento al host B, manda un ACK = 100 (correspondiente al primer paquete) y cuando recibe
el segundo segmento, manda otro ACK = 120 (correspondiente al segundo paquete). El ACK =
100 se retrasa y se le expira el time out, entonces el host A vuelve a enviar el segmento 92 con
8 bytes y el host B, como ya lo había recibido y también ha recibido el 100 con 20 bytes de datos,
le manda un ACK = 120.
En la siguiente tabla se identifican diferentes eventos que pueden ocurrir cuando un receptor
recibe paquetes (ordenados o no según su número de secuencia), detallándose cómo el receptor
debe devolver las confirmaciones:

CÓMO ESTIMAR LOS TIMEOUTS

Para completar el estudio de control de errores de TCP, la eficacia o prestaciones del
procedimiento dependerán de la correcta estimación del temporizador (timeout):

• Tiene que ser mayor que el tiempo de ida y vuelta (RTT, Round Trip Time). No puede ser
menor de lo que se tarda en enviar un paquete y recibirlo.
• Si es demasiado pequeño, se producen timeouts prematuros y por tanto, se desperdiciarían
recursos en la red.
• Si es demasiado grande, reacción lenta a pérdida de segmentos (el emisor tardaría mucho
tiempo en darse cuenta de posibles problemas).
La mejor solución es que sea adaptable. El método para a estimación del timeout en TCP:

CONTROL DEL FLUJO

Para evitar que el emisor sature al receptor con el envío de demasiada información y/o
demasiado rápido se utiliza un esquema crediticio donde el receptor informa el emisor sobre los
bytes autorizados a emitir sin esperar respuesta (se envíen de forma consecutiva). Para ello se
utiliza el campo “ventana” (window) en el segmento TCP. Así, si un emisor recibe un segmento
con un valor de ventana igual a 0 significa que el receptor no autoriza a enviar más datos hasta
nueva orden. para establecer la ventana ofertada.
• El receptor especifica al emisor un tamaño de ventana máximo (en bytes) autorizado para
transmitir → ventana ofertada. Cada vez que el receptor manda un ACK, también manda en un
parámetro llamado window la proporción de ventana ofertada.
• El emisor almacena la ventana ofertada del receptor en todo momento, pudiendo así calcular
la ventana útil como ventana útil= ventana ofertada – bytes en tránsito, donde los bytes en tránsito
se refieren a los octetos ya transmitidos hacia el receptor y de los cuales aún no se ha recibido
confirmación.

Hay que tener en cuenta que cuando ventana ofertada = 0 por parte del receptor, el emisor se
bloqueará. Si la aplicación receptora consume más segmentos se genera un nuevo segmento
ACK anunciando la nueva ventana ofertada con tamaño >0.
Posible problema: síndrome de la ventana tonta. Este problema se da cuando el emisor,
receptor o ambos son muy lentos (se utilizan segmentos muy pequeños).
Posible mejora: método de la ventana optimista que consiste en el envío por parte del emisor
de una cantidad de datos mayor a la realmente ofertada por el receptor, es decir,

ventana útil > (ventana ofertada – bytes en tránsito)

Los segmentos que son urgentes (flag U), el receptor los manda a capa de aplicación del tirón,
no espera a que la capa de aplicación los extraiga. Al igual que los segmentos que tengan el flag
P activado (push).

D. CONTROL DE CONGESTIÓN

Por medio del tamaño de ventana el receptor puede dosificar al emisor en función del buffer
disponible: control de flujo.
Pero puede que el receptor tenga espacio de sobra, pero la red esta congestionada. En este
caso el TCP debe regularse para no inyectar demasiado tráfico, a pesar de que la ventana
disponible sea muy grande: control de congestión.

Para controlar la velocidad, TCP adopta una aproximación de prueba y error que consiste en
aumentar la ventana_de_congestión (implica aumentar la tasa de transmisión) mientras no se
produzca congestión (esta situación se identifica al producirse un timeout).
La ventana_de_congestión se adapta dependiendo la zona en la que se encuentre (inicio lento,
prevención de congestión, decremento multiplicativo).

Este procedimiento corresponde a una de las primeras especificaciones (denominadas sabores).

En concreto, se identifica como TCP-Tahoe. También se han ido proponiendo diferentes
“sabores”, cabe destacar TCP-Reno que incliye el procedimiento “fast retransmit”. En este caso,
si el emisor recibe 3 ACK repetidos se concluye que se está experimentando cierta congestión.

4. EXTENSIONES TCP

TCP se define como múltiples “sabores”, cada uno de los cuales no afectan a la interoperabilidad
entre los extremos.
En el RFC 1323 se recogen algunas mejoras a TCP que persiguen aumentar la eficiencia de este
protocolo cuando se implementa sobre redes de mayor velocidad a las existentes cuando fue
diseñado:
• Ventana escalada: Opcion TCP → factor de escala en segmentos SYN de inicio de conexión
(hasta 214 × 216 = 1GB autorizados). Frente a los 65.535 bytes que un receptor TCP autoriza a
transmitir a un emisor sin esperar confirmación.
• Estimación RTT: Opción TCP de cálculo del RTT para cada segmento enviado mediante un
sello de tiempo, de forma que cuando se genera un segmento TCP se incluye dicha opción, que
será devuelta en un paquete ACK.
• PAWS (“Protect Against Wrapped Sequence numbers”): Protección contra números de
secuencia ya recibidos, que hace uso del sello de tiempo de TCP para el rechazo de segmentos
duplicados que podrían corromper una conexión TCP abierta.
• SACK: Confirmaciones selectivas. Dice que paquetes reenviar ante la pérdida aislada de un
segmento.