4.

1 La capa de transporte del modelo OSI

Los procesos descriptos en la capa de Transporte aceptan los datos procedentes de las aplicaciones y los
prepara su direccionamiento en la capa IP.
La capa de Transporte es responsable de la transferencia de extremo a extremo de los archivos de la capa
de Aplicación.
Funciones de la capa de transporte:
- Permite aplicaciones múltiples para comunicarse en la red al mismo tiempo que en un dispositivo sencillo
- Asegura que, si es necesario, la aplicación correcta reciba todos los datos de forma confiable y en orden
- Emplea mecanismos de manejo de errores
Objetivos del estudio de la capa de transporte:
- Transferencia de datos de extremo a extremo entre las aplicaciones.
- Descripción de las funciones de los protocolos TCP/IP de la capa de transporte: TCP y UDP.
- Explicación de las funciones confiabilidad, direccionamiento de puerto y segmentación.
- Indicar cuando es adecuado el uso del protocolo TCP o UDP.

Cap. 4 La capa de transporte página 1

4.2 Propósitos de la capa de transporte

Permite la segmentación de los datos y brinda el control necesario para el re-ensamblaje de los distintos
flujos de comunicaciones. Las responsabilidades que debe cumplir esta capa son:
4.2.1 Rastreo de conversaciones individuales
Cualquier host puede tener múltiples aplicaciones que se comunican a través de la red. Cada una de
estas aplicaciones se comunicará con una o más aplicaciones en hosts remotos. Es responsabilidad de la
capa de transporte mantener los flujos de comunicación múltiple entre estas aplicaciones.
4.2.2 Segmentación de datos
Así como cada aplicación crea flujos de datos para enviarse a una aplicación remota, estos datos se
pueden preparar para enviarse a través de los medios en partes manejables. Los protocolos de la capa
de transporte describen los servicios que segmentan estos datos de la capa de aplicación. Esto incluye la
encapsulación necesaria en cada sección de datos. Cada sección de datos de aplicación requiere que se
agreguen encabezados en la capa de transporte para indicar la comunicación a la cual está asociada.

Cap. 4 La capa de transporte página 2

 4.4 Segmentación y multiplexación

La desventaja del uso de la segmentación y multiplexación consiste en el nivel de complejidad que se

agrega a la red.
Inconveniente: Cada segmento debe ser etiquetado con los datos del destinatario y del remitente. Esto
ocasiona una sobrecarga en la red con información ubicada en la cabecera del segmento.
El mensaje etiquetado permite la entrega del segmento en el destino correcto.
Al enviar partes más pequeñas de un mensaje del origen hacia el destino, se puede intercalar diversas
conversaciones en una red.
El proceso que se utiliza para intercalar piezas separadas de conversaciones en una red se denomina
multiplexación.
Multiplexación: transmisión de la información procedentes desde diferentes fuentes sobre un mismo medio
de transmisión de una manera entrelazada o intercalada.

Cap. 4 La capa de transporte página 3

 4.5 Propósitos de la capa de transporte

4.5.1 Re-ensamble 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 flujo 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 re-ensamblar las partes de los datos en flujos para pasarlos a
la capa de aplicación.
4.5.2 Identificación de las aplicaciones
La capa de Transporte asigna un identificador a cada una de las aplicaciones. Este identificador se
denomina número de puerto.
La capa de transporte es el enlace entre la capa de Aplicación y las capas inferiores para la transmisión de
cada uno de los segmentos o datagramas. Los datos son multiplexados para su transmisión en la red.
Las aplicaciones no necesitan conocer los detalles operativos de la red sobre la cual va a ser enviada la
información como por ejemplo: la clase de host de destino, el tipo de medio de transmisión de la red, la
congestión en la red ect.
Las capas inferiores no tienen conocimiento que existen varias aplicaciones que envían información a la red.
La capa de transporte clasifica los fragmentos de los datos para su envío a la red conforme a las prioridades
establecidas para el envío del flujo de datos a través de los medios.
Los requisitos de los datos varían:
Cada una de las aplicaciones tiene diferentes requisitos. Algunas aplicaciones permiten la pérdida de datos.
Los protocolos tienen distintas reglas para el intercambio de información entre el originador y el destino.

Cap. 4 La capa de transporte página 4

 4.6 Propósitos de la capa de transporte

4.4.1 Separación de las comunicaciones múltiples

Cada una de las aplicaciones envía o recibe sus datos independientemente de las otras aplicaciones y de
manera simultánea.
Los datos correspondientes a las aplicaciones de correo electrónico y el acceso a los portales pueden
funcionar con retardos debido a la congestión de la red o a la repetición de los contenidos.
Los datos correspondientes a las aplicaciones de voz y video son susceptibles a los retardos. La red no
gestiona la retransmisión de estos contenidos.
Para el caso de algún retardo o contenido faltante en un mensaje de voz, el interlocutor interpreta el contenido
por el contexto del dialogo o solicita la repetición del contenido. La red no realiza gestión alguna tendiente a la
recuperación de los contenidos faltantes.

Cap. 4 La capa de transporte página 5

 4.7 Propósito de la capa de transporte

Multiplexación: Es necesario evitar que una aplicación use toda red sin permitirle el acceso a las otras
aplicaciones aun cuando le pertenezcan mismo usuario.
La capa de transporte realiza la segmentación de los datos procedentes de cada una de las aplicaciones.
La multiplexación permite que los datos de cada uno de los usuarios puedan ser intercalados para la
transmisión.
Esto permite que las aplicaciones puedan funcionar de manera concurrente.
En la capa de transporte, cada conjunto de piezas que fluye entre una misma aplicación desde el origen
hasta el destino se denomina conversación.
La multiplexación permite que un usuario pueda leer sus archivos mientras tiene un dialogo interactivo a
través de una comunicación de voz y video IP.
Para identificar cada pieza fraccionada de información, la capa de transporte le agrega unos campos de
cabecera con un objetivo definido.

Cap. 4 La capa de transporte página 6

 4.8 Control de las conversaciones

Segmentación y reensamble: la mayoría de las redes tienen una limitación en la cantidad de datos que se
pueden incluir en una simple PDU. La capa de transporte divide los datos de aplicación en bloques de
datos de un tamaño adecuado. En el destino, la capa de transporte reensambla los datos antes de
enviarlos a la aplicación o servicio de destino.
Multiplexación de conversación: puede haber aplicaciones o servicios que se ejecutan en cada host de la
red. A cada una de estas aplicaciones o servicios se les asigna una dirección conocida como puerto, de
manera que la capa de transporte determina con qué aplicación o servicio se identifican los datos.
Además de utilizar la información contenida en los encabezados, para las funciones básicas de
segmentación y re-ensamble de datos algunos protocolos en la capa de transporte proporcionan:
- Conversaciones orientadas a la conexión
- Entrega confiable
- Reconstrucción de datos ordenada
- Control del flujo

Cap. 4 La capa de transporte página 7

 4.9 Control de las conversaciones

Establecimiento de una sesión

La capa de transporte puede brindar esta orientación a la conexión creando una sesión entre las aplicaciones.
Estas conexiones preparan las aplicaciones para que se comuniquen entre sí antes de que se transmitan los
datos. Dentro de estas sesiones, se pueden gestionar de cerca los datos para la comunicación entre dos
aplicaciones.
Entrega confiable
Por varias razones, es posible que una sección de datos se corrompa o se pierda por completo a medida que
se transmite a través de la red. La capa de transporte puede asegurar que todas las partes alcancen su
destino haciendo que el dispositivo origen retransmita todos los datos perdidos.

Cap. 4 La capa de transporte página 8

4.10 Control de las conversaciones

Entrega en el mismo orden

Los datos pueden llegar en el orden equivocado, debido a que las redes pueden proporcionar múltiples rutas
que pueden tener diferentes tiempos de transmisión. Al numerar y secuenciar los segmentos, la capa de
transporte puede asegurar que los mismos se reensamblen en el orden adecuado.
Control del flujo
Los hosts de la red cuentan con recursos limitados, como memoria o ancho de banda. Cuando la capa de
transporte advierte que estos recursos están sobrecargados, algunos protocolos pueden solicitar que la
aplicación que envía reduzca la velocidad del flujo de datos. Esto se lleva a cabo en la capa de transporte
regulando la cantidad de datos que el origen transmite como grupo. El control de flujo puede evitar la
pérdida de segmentos en la red y evitar la necesitad de la retransmisión.

Cap. 4 La capa de transporte página 9

 4.11 Soporte de una comunicación confiable

Cada una de las aplicaciones tiene sus propios requisitos para la transmisión y recepción de sus datos. Se han
desarrollado diferentes clases de protocolos que cumplan con los requisitos de cada una de las aplicaciones.
El protocolo debe permitir el envío confiable de los datos de extremo a extremo de la comunicación.
Las tres operaciones básicas para un envío confiable son:
- Rastreo de los datos transmitidos.
- Acuse de recibo de los datos recibidos.
- Retransmisión de cualquier dato sin acuse de recibo.
La confiabilidad requiere que el host emisor realice un rastreo de todas las partes de datos de una conversación
y proceda a la retransmisión de cualquier dato que el host de destino no acusó recibo.
La confiabilidad también requiere que el host de destino realice un rastreo de todas las partes de datos de una
conversación y reconozca la recepción de cada parte por medio de un acuse de recibo.
Estos procesos de confiabilidad generan un uso adicional de los recursos de la red para el rastreo y
retransmisión de los datos. Es necesario un incremento en el volumen de los datos de control de extremo a
extremo. Esta información de control se encuentra en la cabecera de cada parte de un mensaje.
La confiabilidad crea una sobrecarga en la red. Los desarrolladores de aplicaciones deben determinar el tipo de
protocolo requerido para cada tipo de aplicación.
Existen protocolos de entrega confiable y protocolos de entrega no confiable de los datos.
El envío de la información con el mejor esfuerzo está clasificado como no confiable debido a que no hay un
acuse de recibo de la información enviada hacia el destino.

Cap. 4 La capa de transporte página 10

 4.10 Soporte de una comunicación confiable

Determinación de la necesidad de la confiabilidad

Las aplicaciones tales como correo electrónico, páginas web y en general bases de datos necesitan que
todos los datos enviados lleguen a destino para que sean útiles.
Si la información se recibe incompleta, algunas partes de una aplicación dejan de funcionar
adecuadamente.
En este caso se debe utilizar un protocolo que garantice la entrega integral de la información sin error
alguno.
Existen otras aplicaciones como la transmisión de voz y video en la cual no tiene transcendencia la
pérdida de algunos fragmentos del contenido transmitido. El usuario final lo puede interpretar del
contexto o no detecta esta situación.
En este caso se utiliza un protocolo que no sobrecargue la red.

Cap. 4 La capa de transporte página 11

4.11 TCP y UDP

Los dos protocolos más comunes en la capa de transporte son el Protocolo de Control de Transmisión TCP
y el protocolo de Datagrama del Usuario UDP. Ambos protocolos gestionan la comunicación de la capa de
aplicación.
4.11.1 Protocolo de control de transmisión TCP
Es un protocolo orientado a la conexión.
Garantiza la entrega de la información: secuenciamiento, control de flujo, retransmisión ect.
Las porciones de información se denominan segmentos. Ejemplos de aplicaciones TCP.
- Exploradores Web.
- Correo electrónico.
- Transferencia de archivos.
- La cabecera utiliza 20 octetos.

4.11.2 Protocolo de datagrama del usuario UDP

Es un protocolo sin conexión.
No garantiza la entrega de la información en el destino: mejor esfuerzo o mejor intento.
Las porciones de información se denominan datagramas. Ejemplos de aplicaciones UDP:
- Sistemas de nombre de dominio: DNS
- Streaming de video.
- Voz sobre IP.
- La cabecera utiliza ocho octetos.

Cap. 4 La capa de transporte página 12

4.12 Segmentación y reensamblaje

Los datos de la capa de aplicación deben ser segmentados y multiplexados para su transmisión.
Esto evita que un archivo con una gran cantidad de octetos ocupe la red por un tiempo largo, sin compartirlo
con otros usuarios.
En caso de algún error en la transmisión del archivo no segmentado, debe de retransmitirse desde el
principio.
Los dispositivos de red no están equipados con una gran cantidad de memoria para el almacenamiento
temporal de un gran volumen de datos que ingrese a la red.
La división de los datos de aplicación en partes permite la multiplexación.
Segmentación diferente para TCP y UDP
En el protocolo TCP cada encabezado de un segmento contiene un número de secuencia que identifica al
segmento transmitido. Los segmentos pueden llegar desordenados al host de destino. El número de
secuencia permite el reensamblaje de los segmentos desordenados y la recuperación de los segmentos
faltantes. La cabecera consta de 20 octetos.
Las cabeceras de los datagramas de un protocolo UDP no contiene un número de secuencia que permita el
reensamblaje de los datagramas desordenados o faltantes. La cabecera consta de ocho octetos.

Cap. 4 La capa de transporte página 13

4.13 Segmentación y reensamblaje

La diferencia entre TCP y UDP es la confiabilidad en la transferencia de la información.

Cap. 4 La capa de transporte página 14

4.14 Cabecera de un segmento TCP

Longitud del encabezado: longitud del encabezado del segmento en octetos.

Reservado: se establece en cero.
Señaladores: administración de sesiones y el tratamiento de segmentos, compuesto por seis bits
Tamaño de la ventana: cantidad de octetos que deben enviarse antes de esperar el acuse de recibo.
Checksum de TCP: verificación de errores en el encabezado y en los datos.
Señalador urgente: utilizado con una señalización urgente.
Opciones: información opcional.
Datos: datos de aplicación.

Cap. 4 La capa de transporte página 15

4.15 TCP - Números de puertos

- Puerto de origen: contiene 16 bits. Este número de puerto es usado para la identificación de la sesión
responsable del envío de datos en el host de origen.
- Puerto de destino: contiene 16. Este número de puerto es usado para la identificación la sesión de comunicación
en el receptor y distingue la aplicación que debe responder en el host de destino.
Existen tres rangos de números de puertos: los puertos denominados bien conocidos están numerados desde el 0
hasta el 1023. Los puertos denominados registrados están numerados desde el 1024 hasta el 49151. Los puertos
privados están numerados desde el 49152 hasta el 65535.
Los puertos son usados en el protocolo TCP o UDP como una interfaz para la capa de aplicación.
En la conexión de un cliente con un servidor se usan identificadores que deben ser únicos para cada
comunicación. El socket debe identificar cada conexión para que la entrega de la información sea correcta.
Un socket en un dispositivo está compuesta por la dirección IP de un dispositivo, el número de puerto asignado a
ese dispositivo y el protocolo usado para la transferencia de la información.
En el lado del cliente, el socket del cliente es creado para el inicio de una comunicación TCP con el servidor.
En cada servidor, el socket del servidor permanece abierto y espera las solicitudes de los clientes. Cuando se
recibe una solicitud de un cliente, el servidor crea un socket para atender la petición de un cliente y mantiene al
socket del servidor libre para la recepción de más peticiones.
En el cliente, el número de puerto es asignado aleatoriamente con un número mayor que 1023.
En los servidores, el número de puerto asignado a una aplicación es un número establecido denominado bien
conocido, menor que 1023.

Cap. 4 La capa de transporte página 16

4.16 Direccionamiento del puerto

Asignados por la IANA, organismo responsable de garantizar el direccionamiento.

Existen diversos tipos de números de puertos.
Puertos bien conocidos
Números de puerto desde el 0 hasta el 1023. Se utilizan en los servidores para los protocolos HTTP,
SMTP/POP3, Telnet entre otros.
Las aplicaciones de cliente pueden ser diseñadas para que soliciten una conexión con estos puertos.
Puertos registrados
Números de puertos desde el 1024 hasta el 49151. El usuario puede seleccionar uno de estos números
para una determinada aplicación de cliente. Estos números también se usan seleccionados
aleatoriamente en el cliente.
Puertos dinámicos o privados
Números de puerto desde el 49152 hasta el 65535. Usados en el cliente. Conocidos como puertos
efímeros y asignados de forma dinámica cuando se establece una conexión temporal con otro proceso.
Su uso es poco común.

Cap. 4 La capa de transporte página 17

4.17 TCP - número de secuencia

- Numero de secuencia: este campo está compuesto por un número de 32 bits que define el número de secuencia del
primer octeto correspondiente al campo de datos de un segmento en particular.
Cada octeto en el flujo de datos. La numeración de cada segmento le permite al host receptor la posibilidad de reubicar
los segmentos que sean recibidos fuera de secuencia y asegurar la confiabilidad con el número de asentimiento o
confirmación de recepción.
En la siguiente gráfica se representa un archivo segmentado.

Cap. 4 La capa de transporte página 18

4.18 Confirmación de los segmentos recibidos en el servidor

Número de asentimiento o confirmación: el campo del número de asentimiento o número de confirmación contiene 32 bits,
el cual define el número del siguiente octeto que espera recibir por el emisor del segmento actual.
Cada dispositivo ubicado en los extremos de la comunicación tiene su propio número de secuencia para los datos que
debe transferir. El dispositivo receptor ubicado en cualquiera de los extremos debe reportar el número de octetos recibidos
más uno. El uso de este mecanismo le permitirá al receptor determinar si algún segmento está perdido.
En este ejemplo se representan los valores de confirmación Ack de los segmentos recibidos en el servidor.
Esta es una representación unidireccional del Ack, con un propósito didáctico.
Los contenidos de Ack funcionan en los dos extremos de la conexión, en las dos direcciones.

Cap. 4 La capa de transporte página 19

4.19 Confirmación de los segmentos recibidos en el cliente

En este ejemplo se representan los valores de confirmación Ack de los segmentos recibidos en el servidor.
Esta es una representación unidireccional del Ack.
Esta es una representación unidireccional del Ack, con un propósito didáctico.
Los contenidos de Ack funcionan en los dos extremos de la conexión, en las dos direcciones.

Cap. 4 La capa de transporte página 20

4.20 TCP - número de asentimiento

- Ejemplo: el cliente A tiene un número de secuencia inicial de 1000 y transmite 500 octetos de datos en cada
segmento. El campo de Ack_c tiene un valor inicial de 8000. La transferencia de información se estaba efectuando
cuando se detectó esta secuencia.

Cap. 4 La capa de transporte página 21

4.21 TCP - longitud de la cabecera.

- Longitud de la cabecera: cuya abreviatura es HLEN o Header Length en un segmento TCP, este campo está
compuesto por cuatro bits el cual indica la longitud de la cabecera de un segmento TCP. La longitud de la cabecera
está medida en múltiplos de 32 bits.
El valor mínimo que pueden representar los cuatro bits es cinco. Si los cuatro bits representan el valor de 5, la
longitud de la cabera representa 5 x 32 bits en total. Esta longitud puede ser calculada en octetos por medio de la
expresión .

- Reservado: este campo está compuesto por seis bits y está reservado para algún uso en el futuro. Está
compuesto por una secuencia de seis ceros consecutivos.

- Control: este campo está compuesto por seis bits.

Cada uno de los campos funciona independientemente para los siguientes propósitos:
. Puntero urgente: abreviado URG. Cuando este bit está activo, el contenido del campo puntero urgente debe
ser interpretado en el receptor. Indica que los datos urgentes empiezan en el primer octeto de datos de cada
segmento.
. Asentimiento o confirmación: abreviado ACK. Cuando este bit está activo, el campo de asentimiento o
confirmación en el segmento TCP es válido.
. Función Push: abreviado PSH. Cuando este bit está activo, el receptor es obligado a la entrega de este
segmento a la aplicación de recepción en la brevedad posible.
. Reinicio de la conexión Reset: abreviado RST. Cuando este bit esta activo, el receptor es informado que el
emisor interrumpe la conexión y todos los datos almacenados en la memoria temporal de recepción deben ser
eliminados.
. Sincronización SYN: cuando este bit está activo, se le informa al receptor que el emisor intenta la
sincronización de los números de secuencia. Esta función es requerida para el inicio de la conexión entre el
emisor y el receptor. Después de la creación de la conexión, se le indica al otro extremo el primer número de
secuencia que se usará para la transferencia de información.
. Finalización FIN: este bit le informa al receptor que el emisor ha transmitido el final del flujo de octetos para la
actual conexión TCP. El receptor no espera más datos.

Cap. 4 La capa de transporte página 22

4.22 TCP - Ventana

- Ventana: el campo ventana es usado para indicar el número de octetos de este segmento que el receptor esté
dispuesto a aceptar. Usualmente este número es escogido basado en el tamaño de memoria libre, número de
mensajes perdidos recientemente y el número de segmentos recibidos con error recientemente.
Este campo se usa para el mecanismo del control de flujo del TCP. Este campo define cuantos octetos el emisor debe
enviar antes de una pausa y espera de un asentimiento del nodo de destino.

- Checksum: el originador usa el campo de la cabecera y los datos para la obtención de un resumen lógico con esos
contenidos el cual es enviado al receptor. El receptor recalcula los contenidos recibidos y determina si existe algún
error en el contenido recibido.
Si existe un error en la comparación del checksum enviado por el emisor y el calculado en el receptor, el segmento es
eliminado y el emisor retransmite el segmento.

- Puntero urgente: este campo apunta al octeto final del dato urgente enviado al receptor. El emisor le informa al
receptor la existencia de datos urgentes que necesitan ser entregados a la aplicación inmediatamente.
El contenido de este campo urgente es un número el cual cuando es agregado por el receptor al número de secuencia
del mismo segmento, apuntará al último octeto del dato urgente. Este campo es efectivo solamente cuando el bit URG
del campo de control está activo.

Cap. 4 La capa de transporte página 23

4.23 TCP - campo de opciones

- Opciones: la longitud de este campo es variable en algunos casos. Usualmente no se utiliza y en algunas ocasiones se
agregan dos o más octetos. El objetivo de este campo es la expansión de la cabecera para nuevas aplicaciones en caso
necesario.

- Relleno: está compuesto por un grupo de ceros que se agrega al campo de opciones para que el número de bits en la
cabecera sea un múltiplo de 32.

El protocolo TCP emplea un mecanismo de asentimiento o confirmación positiva. Solamente los segmentos en buena
condición, sin error alguno, con confirmados por el receptor. No se tiene confirmación ni notificación alguna por los
segmentos perdidos o recibidos con error.
El originador del segmento fija o establece un temporizador decreciente por cada segmento enviado. Si el temporizador del
emisor expira antes de la recepción de una confirmación o asentimiento del receptor, el emisor retransmite el segmento.

Cap. 4 La capa de transporte página 24

 4.24 Establecimiento de la conexión TCP

Antes del inicio de la transferencia de la información se establece la conexión entre el cliente y el servidor.
Este es un proceso de tres vías.
Dos sockets intercambian información aun cuando el socket no forma parte del segmento TCP.
El número de secuencia se inicializa aleatoriamente en ambos extremos.
En este proceso el cliente activa solamente el bit de SYN=1, para el establecimiento de una comunicación
desde el cliente hasta el servidor.
Se considera que cada uno de los flujos de inicialización tiene solamente un octeto de datos.
Campos de un bit:

Urg Ack Psh Rst Syn Fin

0 0 0 0 1 0

Cap. 4 La capa de transporte página 25

4.25 Establecimiento de una conexión TCP

Si el servidor no tiene activado el correspondiente puerto, envía un mensaje de rechazo de la conexión por
medio de RST=1.
Si el receptor tiene activado el número de puerto:
- Inicializa el número de secuencia con un valor arbitrario.
- Activa los bits de SYN=1 y ACK=1. El bit de SYN se utiliza para el establecimiento de una
comunicación entre el servidor y el cliente. El bit de ACK se usa para la indicación del asentimiento o
confirmación del número de octetos recibidos y hace referencia al último octeto más uno.
El valor del campo del número de secuencia es un número que excede en un byte al número de bytes
recibidos. Esto número de ACK + 1 le corresponde al número del siguiente octeto esperado.
El señalizador SYN=1 del receptor indica que se tiene un número de secuencia inicial asignado en el
servidor.
Este valor del número de secuencia se utiliza para el rastreo de la cantidad de datos que salen del
servidor e ingresan al cliente.

Urg Ack Psh Rst Syn Fin

0 0 0 0 1 0
Urg Ack Psh Rst Syn Fin
0 1 0 0 1 0

Cap. 4 La capa de transporte página 26

4.26 Establecimiento de una conexión TCP

El cliente contesta un segmento ACK cuyo valor es igual al número de secuencia inicial más uno
procedente del servidor.
La etapa de conexión se denomina SYN,SYN/ACK,ACK.
Después de haberse cumplido el proceso de tres vías, se inicia la transferencia de información entre el
cliente y el servidor.
Después de finalizar el proceso de establecimiento de la conexión de tres vías, al valor de ACK+1 que se
reciba hace referencia al número de secuencia inicial más uno establecido en cada equipo de transmisión
de datos.
Se considera que cada segmento de SYN transporta un octeto de datos.

Cap. 4 La capa de transporte página 27

4.28 Finalización de la comunicación

El receptor le informa a la aplicación activa la solicitud de finalización enviada por el emisor.

El receptor contesta con un mensaje de asentimiento.

Cap. 4 La capa de transporte página 28

4.29 Finalización de la comunicación

El receptor también inicia el proceso de desconexión, para que la conexión no quede abierta en uno de
los sentidos del flujo de tráfico.
Se hace referencia a estos campos por medio de señaladores, porque el valor de uno de estos campos
es sólo 1 bit y, por lo tanto, sólo tiene dos valores: 1 o 0. Cuando el valor de un bit se establece en 1,
indica qué información de control se incluye en el segmento.

Cap. 4 La capa de transporte página 29

4.27 Finalización de una comunicación TCP

La desconexión es un proceso de cuatro vías. Uno de los extremos inicia el proceso de finalización por
medio del bit FIN=1.
El proceso de finalización de la comunicación lo puede iniciar cualquiera de los equipos terminales de
datos.

Cap. 4 La capa de transporte página 30

4.30 Finalización de la comunicación

Cada uno de los extremos debe finalizar la comunicación.

El extremo que ha finalizado la comunicación no puede continuar enviado datos.
Si uno de los extremos no ha finalizado la comunicación, puede continuar enviado datos.

Cap. 4 La capa de transporte página 31

4.31 Transferencia de datos durante la finalización de una
comunicación.

En caso de retardo en el proceso de finalización de una comunicación, es posible la transferencia de

información durante el proceso de finalización de una comunicación.
El NS_S: 3000 es debido a los números de segmentos anteriores en el servidor.

Cap. 4 La capa de transporte página 32

4.32 Finalización de tres vías

El servidor contesta con los bits de ACK y FIN activos en el mismo segmento.

Cap. 4 La capa de transporte página 33

4.33 Protocolo TCP de enlace de tres vías

Paso 1.
Dirección de origen: [Link] , dirección de destino [Link]
Activación del control de SYN=1 e inicialización del número de secuencia con un valor aleatorio ISN=0.
Puerto de origen: 1069 , puerto de destino: 80, HTTP.

Cap. 4 La capa de transporte página 34

4.34 Protocolo TCP de enlace de tres vías

Paso 2.
En el servidor activa el bit de ACK=1 para indicar un asentimiento recibido.
El servidor activa el bit de SYN=1 para indicar una conexión con un puerto del cliente.
El valor de ACK es igual al número de secuencia inicial recibido más uno.
El número de secuencia inicial del servidor es aleatorio.

Cap. 4 La capa de transporte página 35

4.35 Protocolo TCP de enlace de tres vías

Paso 3.
Respuesta del cliente. Activación únicamente del bit ACK=1.

Cap. 4 La capa de transporte página 36

4.36 Finalización de la sesión TCP

Se utilizan dos procesos de dos vías.

El proceso lo puede iniciar cualquiera de los dos dispositivos, cliente o servidor.
Uno de los extremos envía una señal de FIN=1 y existe un valor de ACK.

Cap. 4 La capa de transporte página 37

 4.37 Finalización de la sesión TCP

El receptor envía un mensaje de ACK, con el bit ACK=1.

Este proceso se repite desde el receptor hacia el emisor, en la cual el receptor cierra el proceso con un bit
de FIN=1.
Finalmente el emisor contesta con el bit ACK=1.
También es posible terminar la conexión por medio de un enlace de tres vías. Cuando el cliente no posee
más datos para enviar, envía un señalizador FIN al servidor. Si el servidor tampoco tiene más datos para
enviar, puede responder con los señalizadores FIN y ACK, combinando dos pasos en uno. El cliente
responde con un mensaje ACK.

Cap. 4 La capa de transporte página 38

4.38 Reensamblaje de segmentos TCP

En la sesión, se establece un número secuencial inicial en la máquina del cliente. Una vez establecida la
conexión se procede al intercambio de información.
Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este número
de secuencia inicial representa el valor de inicio para los bytes de esta sesión que se transmitirán a la
aplicación receptora.
El número de secuencia se incrementa conforme al número de octetos transmitidos.
Durante la transmisión de la información, algunos segmentos pudieron haber sido recibidos
desordenados conforme al número secuencial de los mismos.
El receptor confirma la recepción de la cantidad de bytes recibidos, tomando como referencia los valores
que han tenido asentimiento.
El reensamblaje se efectúa conforme al número secuencial de cada segmento transmitido.
Los números de secuencia de segmento permiten la confiabilidad indicando cómo re-ensamblar y
reordenar los segmentos recibidos.
Uso de memorias de almacenamiento y procedimientos de clasificación u ordenamiento de los
contenidos en las memorias, antes de la entrega de los segmentos a la capa de aplicación.

Cap. 4 La capa de transporte página 39

4.39 Secuenciación para eliminar segmentos duplicados

La duplicación de segmentos puede presentarse si un transmisor defectuoso detecta una colisión en la trama
transmitida, en consecuencia procede retransmitir dicho segmento con el mismo número de secuencia.
El receptor pudo haber detectado a ambos segmentos como válidos, con el mismo número de secuencia.
El receptor examina los números de secuencia recibidos y detecta si el segmento ya ha sido entregado a la
aplicación con anterioridad o si es un segmento esperado.
Esto permite la eliminación del último segmento cuyo número de secuencia esta duplicado.
La retransmisión de segmentos puede ocasionar la aparición de segmentos duplicados en el receptor. El
transmisor no distingue entre los segmentos perdidos y los segmentos que tienen un gran retardo en su llegada
al receptor.

Cap. 4 La capa de transporte página 40

4.41 Retransmisión de paquetes perdidos

El protocolo TCP emplea un mecanismo denominado Confirmación Positiva con Retransmisión. Esto
significa que solamente los segmentos que han sido recibidos en buena condición, sin error, serán
confirmados. No existe confirmación ni tampoco el envío de notificaciones cuando un segmento está
perdido o el segmento es recibido con algún error. En vez de eso, el nodo emisor fijara un temporizador
con conteo descendente para cada segmento enviado. Si el temporizador del segmento expira antes de la
recepción de una confirmación de la recepción de este segmento, la retransmisión es invocada.
El transmisor es responsable de que cada paquete se transfiera con éxito. El protocolo transmisor inicia un
cronómetro al enviar un paquete. Si el acuse de recibo llega antes de la finalización del cronómetro, el
software lo cancela. Si el cronómetro expira antes de la llegada del asentimiento, el emisor envía otra
copia del paquete y reinicia el cronómetro.
La retransmisión no puede tener éxito si una falla de hardware ha desconectado la red o si la computadora
receptora se encuentra fuera de servicio. Por lo tanto, los protocolos que retransmiten mensajes suelen
limitar el número máximo de retransmisiones. Cuando se alcanza el límite, cesa la retransmisión y se
declara que la comunicación es imposible.
En la retransmisión puede generarse paquetes duplicados. Esto es debido a que el transmisor no puede
distinguir entre los paquetes perdidos y los paquetes que tienen un gran retardo. Es posible que ambas
copias lleguen al receptor.

Cap. 4 La capa de transporte página 41

4.42 Confirmación positiva con retransmisión

Si el vencimiento del temporizador ocurre en muy corto tiempo, numerosas respuestas de confirmación o
asentimiento Ack no son recibidas dentro del intervalo de tiempo establecido y el emisor vuelve a retransmitir la
misma trama. En la red se incrementa el número de segmentos transmitidos, con el mismo contenido, lo cual
implica la duplicidad de segmentos en el receptor.

Cap. 4 La capa de transporte página 42

4.43 Confirmación positiva con retransmisión

Cuando el segmento transmitido no llega al receptor, no existe acuse de recibo en el receptor.

Cuando el segmento transmitido llega al receptor, pero la respuesta no recibe el emisor, se presenta la posibilidad
de duplicidad de mensajes en el receptor.

Cap. 4 La capa de transporte página 43

 4.43 Retransmisión adaptativa

La selección de un tiempo de vencimiento fijo no permitirá tratar todos los casos en condiciones iguales. Por esta
razón el protocolo TCP está diseñado con un mecanismo adaptativo para determinar un tiempo límite apropiado
para una nueva transmisión. El protocolo TCP en consecuencia verifica la carga útil o los datos del usuario para
cada conexión. Este procedimiento mide el tiempo de ida del mensaje transmitido y el tiempo de regreso de la
respuesta completa recibida. Este procedimiento de medición es llevado a cabo para cada mensaje enviado y
cualquier desviación que aparezca en una conexión particular controlada es registrada y se distribuye en un
nuevo cálculo para el vencimiento del tiempo. Esta es una medición del tiempo de ida y regreso uniforme. Por
consiguiente en las situaciones de alta carga, el protocolo TCP puede elevar el tiempo de vencimiento y luego
subsecuentemente disminuirlo otra vez cuando la carga en la red retorna al nivel normal.
En contraste con otros mecanismos de verificación de averías, el protocolo TCP no le ofrece posibilidad alguna al
receptor para forzar la nueva transmisión de un segmento averiado, debido que no existe un mecanismo de
asentimiento negativo. Sobre la detección de error, el receptor simplemente no envía un asentimiento y espera
hasta que el tiempo límite fijado haya expirado, en el cual el originador automáticamente empieza con una nueva
transmisión.

Cap. 4 La capa de transporte página 44

4.44 Confirmación positiva con retransmisión

Cap. 4 La capa de transporte página 45

4.47 Confirmación positiva con retransmisión

Un cliente y un servidor HTTP intercambian información. Se representan los contenidos de algunos

campos. No existen segmentos perdidos en este ejemplo.

Cap. 4 La capa de transporte página 46

 4.48 Buffers, control de flujo y ventanas

El protocolo TCP controla el flujo de datos en una red por medio del mecanismo de ventana.
Una vez establecida la conexión entre dos dispositivos, cada lado asigna el tamaño del buffer de
almacenamiento de los datos y transmite este contenido al host opuesto.
A medida que se reciben los datos, el receptor regresa los acuses de recibo Ack y el tamaño de la ventana
disponible.
Si la aplicación receptora puede leer los datos a la misma velocidad a la cual llegan, transmitirá un anuncio de
ventana positiva con cada acuse de recibo Ack.
Control de flujo
Si el transmisor opera a una velocidad mayor que el receptor, los datos de entrada llenarán el buffer del
receptor, el cual enviará un anuncio de ventana cero.
El emisor debe interrumpir la transmisión de información hasta que el receptor anuncie una ventana con un
valor positivo.

Cap. 4 La capa de transporte página 47

 4.49 Fundamentos de la ventana deslizante

La ventana deslizante le permite al emisor el envío de numerosos segmentos sin esperar la confirmación de
la recepción de cada segmento en el dispositivo receptor.
En la gráfica se tiene una ventana deslizante compuesta por ocho segmentos, los cuales pueden ser
transmitidos sin esperar la confirmación de recepción de cada uno de los segmentos.
Cuando se recibe la confirmación de recepción del primer segmento transmitido, la ventana puede deslizarse
un segmento y transmitir el noveno segmento.
Cuando se recibe la confirmación del segundo segmento se envía el décimo segmento.

Si han sido transmitido los primeros ocho segmentos, sin haber recibido la confirmación de ningún segmento
desde el receptor, la ventana no avanza ninguna posición hacia otros segmentos que deben ser transmitidos.
Una ventana esta descripta por
- Ancho de la ventana: número de octetos que comprende la ventana.
- Indicador de la posición inicial del primer octeto de la ventana.
- Indicador de la posición final del último octeto de la ventana.
- Indicador de los segmentos cuya recepción está confirmada por el receptor.

Cap. 4 La capa de transporte página 48

4.50 Fundamentos de la ventana deslizante

Cuando el emisor transmite varias tramas consecutivamente conforme al valor de la ventana deslizante,
cada trama enviada tiene asignado un temporizador.
Si no se recibe una respuesta de confirmación del receptor antes de la expiración del temporizador, el
emisor vuelve a retransmitir la trama faltante en la forma de retransmisión simple.
Retransmisión simple: se retransmiten todas las tramas a partir de la trama faltante, incluso las tramas
posteriores que ya han sido confirmadas.
El intercambio de información entre dos hosts es bidireccional, en consecuencia los datos asignados a los
segmentos pueden presentarse en ambos extremos.

Cap. 4 La capa de transporte página 49

4.51 Fundamentos de la ventana deslizante

El emisor y el receptor determinan el número de octetos destinados a la transmisión y recepción de tramas.

Los segmentos recibidos en el receptor ocupan una cantidad de memoria.
La disponibilidad de memoria en el receptor se le reporta al emisor en cada respuesta del receptor.
Si la cantidad de memoria disponible en el receptor es cero, el emisor no continua transmitiendo mensajes.
Una vez que el receptor entregue los segmentos recibidos a la aplicación se libera espacio en la memoria
para continuar recibiendo más segmentos.
En el emisor, los segmentos enviados y no confirmados son retenidas en una memoria temporal para su
retransmisión en caso necesario.
Los mensajes de confirmación procedentes del receptor liberan espacio de memoria en el emisor para el
envío de nuevos segmentos.

Cap. 4 La capa de transporte página 50

4.52 Anuncios de ventana

Durante la transferencia de información el receptor y el emisor intercambian los valores de las ventanas
que representan el valor del buffer de almacenamiento. El receptor indica la cantidad de memoria
disponible y su utilización durante la recepción de los segmentos.
Cuando el valor de la ventana tiene el valor de cero, el emisor no continua con la transmisión hasta que
exista disponibilidad de memoria. La ventana contiene tres segmentos.

Cap. 4 La capa de transporte página 51

 4.53 Ejemplo de ventana deslizante

El emisor no espera la confirmación de recepción de cada segmento transmitido. La ventana contiene tres
segmentos. Este es un ejemplo sin errores en la trama enviada.

Cap. 4 La capa de transporte página 52

4.54 Error con rechazo simple - segmento no recibido

Solamente se confirma el primer segmento recibido. No se confirma el segmento no recibido ni tampoco los
segmentos posteriores.

Cap. 4 La capa de transporte página 53

4.55 Control de flujo

Se implementa para evitar que un host receptor sea inundado por un número de segmentos que supere su
capacidad de almacenamiento.
La implementación de la ventana deslizante conlleva a un dimensionamiento de la cantidad de memoria que
está asignada en el receptor para el almacenamiento de los octetos recibidos.
Una manera de reducir la cantidad de segmentos transmitidos desde el emisor hacia el receptor se realiza
con una disminución de la ventana deslizante, en la cual se reporta la cantidad de memoria disponible para
la recepción de los datos del emisor.
El ventana toma valores dinámicos crecientes o decrecientes en función de la cantidad de memoria
disponible en el receptor.

Cap. 4 La capa de transporte página 54

4.57 Ejemplo

Complete los números de secuencia o asentimiento en la siguiente gráfica.

Cliente Servidor
NSEC=92 ; Datos: 8 octetos

ACK = ?

NSEC= ? ; Datos: 20 octetos

ACK = ?
NSEC= ? ; Datos: ?

ACK = ?
NSEC= 130 ; Datos: 2 octetos
ACK = ?

Cap. 4 La capa de transporte página 55

 4.58 Protocolo UDP

Formato del datagrama UDP

Este protocolo está diseñado para el envío de los datos con un número reducido de contenidos en la cabecera.
La cabecera está compuesta por ocho octetos. La cabecera esta presentada en filas compuestas por 32 bits.

- El puerto de origen y el puerto de destino identifican los procesos que se manejan en la comunicación y distinguen
ellos de otras sesiones en el mismo host.
- La longitud indica el número de octetos en un datagrama UDP, incluyendo la cabecera y los datos. El valor mínimo
de la longitud es de ocho octetos, el cual le corresponde a la cabecera y sin contenido alguno en el campo de datos.
- El campo de verificación del checksum se calcula con el contenido de los campos de la cabecera y todos los octetos
del campo de datos, entre ellos las direcciones IP de los paquetes. El cálculo y rellenado de este campo es opcional,
no todos los nodos lo colocan.

Cap. 4 La capa de transporte página 56

 4.59 UDP: baja sobrecarga vs confiabilidad

El protocolo UDP es más simple que el protocolo TCP y proporciona mucho menos sobrecarga que el
protocolo TCP.
El protocolo UDP no proporciona el secuenciamiento de los datagramas transmitidos, no retransmite los
datagramas perdidos no realiza el control de flujo, tampoco el re-ensamblaje de los datagramas en el
receptor.
Numerosas redes presentan alta confiabilidad en la transferencia de datos con el protocolo UDP.
Protocolos que utilizan UDP
- Sistemas de nombres de dominio DNS, puerto 53.
- Protocolo simple de administración de red SNMP, puerto 161.
- Protocolo de configuración dinámica de host DHCP, servidor de inicio puerto 67 ; cliente de inicio
puerto 68.
- Protocolo de información de enrutamiento RIP.
- Protocolo de transferencia de archivo trivial TFTP, puerto 69.
- Voz sobre IP VoIP.
- Juegos en línea : transmisión de contenidos de audio y de video.
En el caso de la transferencia de voz e imagen es preferible que se presente pérdidas de contenidos antes
que la retransmisión y demoras en el procesamiento de las tramas.
Los servidores de DNS y DHCP usualmente se encuentran en redes cercanas al usuario, el contenido de
información de estos servidores no es extenso. El usuario puede volver a solicitar el acceso a estos
recursos en caso necesario.

Cap. 4 La capa de transporte página 57

4.60 Reensamblaje de datagramas de UDP

Los datos de la capa de aplicación son fragmentados en datagramas.

UDP no establece una sesión de conexión ni finalización para la transferencia de información.
UDP no numera secuencialmente los datagramas, ni realiza acuses de recibos, ni retransmite
datagramas perdidos, ni control de flujo de los datos transmitidos.
UDP no ordena los datagramas recibidos. Envía al puerto correspondiente a la aplicación en la
secuencia que fueron recibidos.
En caso necesario cuando se tratan de transacciones importantes, la aplicación debe proveer algún
procedimiento de seguridad en la transferencia de la información.

Cap. 4 La capa de transporte página 58

4.61 Procesos y solicitudes de UDP

UDP maneja números de puertos para las aplicaciones, de manera similar al protocolo TCP.
Ejemplos de puertos con protocolo UDP: DNS tiene asignado el puerto 53, SNMP tiene asignado el
puerto 161.
DHCP tiene asignado los puertos 67 y 68.

Cap. 4 La capa de transporte página 59