1. Capa de Transporte OSI
El modelo de referencia de Interconexión de Sistemas Abiertos (OSI,
Open System Interconnection) es el modelo de red descriptivo
creado por la Organización Internacional para la Estandarización
lanzado en 1984. Es decir, es un marco de referencia para la
definición de arquitecturas de interconexión de sistemas de
comunicación.
El nivel de transporte o capa transporte es el cuarto nivel del
modelo OSI encargado de la transferencia libre de errores de los
datos entre el emisor y el receptor, aunque no estén directamente
conectados, así como de mantener el flujo de la red.
La tarea de esta capa es proporcionar un transporte de datos
confiable y económico de la máquina de origen a la máquina
destino, independientemente de la red de redes física en uno. Sin la
capa transporte, el concepto total de los protocolos en capas
tendría poco sentido.
Capa encargada de efectuar el transporte de los datos (que se
encuentran dentro del paquete) de la máquina origen a la de
destino, independizándolo del tipo de red física que se esté
utilizando. La PDU de la capa 4 se llama Segmento o Datagrama,
dependiendo de si corresponde a TCP o UDP. Sus protocolos son
TCP y UDP; el primero orientado a conexión y el otro sin conexión.
Trabajan, por lo tanto, con puertos lógicos y junto con la capa red
dan forma a los conocidos como Sockets IP:Puerto
(192.168.1.1:80).

2. Servicios
Hay dos tipos de servicio en la capa transporte, orientado y no
orientado a la conexión.
En el servicio orientado a la conexión consta de tres partes:
establecimiento, transferencia de datos, y liberación.
En el servicio no orientado a la conexión se tratan los paquetes de
forma individual.
Es la primera capa que lleva a cabo la comunicación extremo a
extremo, y esta condición ya se mantendrá en las capas superiores.
Primitivas del servicio de transporte
Para permitir que los usuarios accedan al servicio de transporte, la
capa de transporte debe proporcionar algunas operaciones a los
programas de aplicación, es decir, una interfaz del servicio de
transporte. Cada servicio de transporte tiene su propia interfaz.
Con el propósito de ver los aspectos básicos, en esta sección
examinaremos primero un servicio de transporte sencillo y su
interfaz.
El servicio de transporte es parecido al servicio en red, pero hay
algunas diferencias importantes.
La principal, es que, el propósito del servicio de red es modelar el
servicio ofrecido por las redes reales, con todos sus problemas. Las
redes reales pueden perder paquetes, por lo que generalmente el
servicio no es confiable.
En cambio, el servicio de transporte (orientado a la conexión) si es
confiable.

3. Claro que las redes reales no están libres de errores, pero ése es
precisamente el propósito de la capa de transporte: ofrecer un
servicio confiable en una red no confiable.
Otra diferencia entre la capa transporte y la de red es a quien van
dirigidos sus servicios. El servicio de red lo usan únicamente las
entidades de transporte. Pocos usuarios escriben sus entidades de
transporte y pocos usuarios o programas llegan a ver los aspectos
internos del servicio de red. En cambio, muchos programas ven
primitivas de transporte.
En consecuencia el servicio de transporte debe ser adecuado y fácil
de usar.
Las primitivas de un transporte sencillo serían:
LISTEN: Se bloquea hasta que algún proceso intenta el
contacto.
CONNECT: Intenta activamente establecer una conexión.
SEND: Envía información.
RECEIVE: Se bloque hasta que llegue una TPDU de DATOS.
DISCONNECT: Este lado quiere liberar la conexión.
Y con estas primitivas podemos hacer un esquema sencillo de
manejo de conexiones. Las transiciones escritas en cursiva son
causadas por llegadas de paquetes. Las líneas continuas muestran
la secuencia de estados del cliente y las líneas punteadas muestran
la secuencia del servidor.

4. Elementos de los protocolos de transporte
El servicio de transporte se implementa mediante un protocolo de
transporte entre dos entidades de transporte. En ciertos aspectos,
los protocolos de transporte se parecen a los protocolos de red.
Ambos se encargan del control de errores, la secuenciación y el
control del flujo.
Pero también existen diferencias importantes entre ambas, como
los entornos en que operan, la capa transporte necesita el
direccionamiento explícito de los destinos, mientras que la capa de
red no, otra diferencia es la cantidad de datos, mucho mayor en la
capa de transporte que en la de enlace de datos.
DIRECCIONAMIENTO
Cuando un proceso desea establecer una conexión con un proceso
de aplicación remoto, debe especificar a cuál se conectará. (¿A
quién mando el mensaje?) El método que normalmente se emplea
es definir direcciones de transporte en las que los procesos pueden
estar a la escucha de solicitudes de conexión. En Internet, estos
puntos terminales se denominan puertos, pero usaremos el
término genérico de TSAP (Punto de Acceso al Servicio de
Transporte). Los puntos terminales análogos de la capa de red se
llaman NSAP (Punto de Acceso al Servicio de Red). Las direcciones
IP son ejemplos de NSAPs.

5. Establecimiento de una conexión
El establecimiento de una conexión parece fácil, pero en realidad es
sorprendentemente difícil. A primera vista, parecería que es
suficiente con mandar una TPDU (Unidad de Datos del Protocolo de
Transporte) con la petición de conexión y esperar a que el otro
acepte la conexión. El problema viene cuando la red puede perder,
almacenar, o duplicar paquetes. El principal problema es la
existencia de duplicados retrasados. Esto puede solucionarse de
varias maneras (ninguna es muy satisfactoria). Una es utilizar
direcciones de transporte desechables. En este enfoque cada vez
que necesitemos una dirección la creamos. Al liberarse la conexión
descartamos la dirección y no se vuelve a utilizar. O también
asignar una secuencia dentro de los datos transmitidos, pero estos
plantean los problemas de que si se pierde la conexión perdemos el
orden del identificador y ya no funciona. Pero la solución sería más
fácil si los paquetes viejos se eliminaran de la subred cada cierto
tiempo de vida. Para ello podemos utilizar las siguientes técnicas:
Un diseño de subred Restringido. Colocar un contador de saltos en
cada paquete. Marcar el tiempo de cada paquete. Pero en la
práctica no vale solo con hacer esto sino que tenemos que
garantizar que todas las confirmaciones de los paquetes también se
eliminan.
Liberación de una conexión
La liberación de una conexión es más fácil que su establecimiento.
No obstante, hay más escollos de los que uno podría imaginar. Hay
dos estilos de terminación de una conexión: liberación asimétrica y
liberación simétrica. La liberación asimétrica es la manera en que
funciona el mecanismo telefónico: cuando una parte cuelga, se
interrumpe la conexión. La liberación simétrica trata la conexión
como dos conexiones unidireccionales distintas, y requiere que

6. cada una se libere por separado. La liberación asimétrica es abrupta
y puede resultar en la perdida de datos. Por lo que es obvio que se
requiere un protocolo de liberación más refinado para evitar la
pérdida de datos. Una posibilidad es usar la liberación simétrica, en
la que cada dirección se libera independientemente de la otra.
Aquí, un host puede continuar recibiendo datos aun tras haber
enviado una TPDU de desconexión.
La liberación simétrica es ideal cuando un proceso tiene una
cantidad fija de datos por enviar y sabe con certidumbre cuándo los
ha enviado. En otras situaciones, la determinación de si se ha
efectuado o no todo el trabajo y se debe terminarse o no la
conexión no es tan obvia. Podríamos pensar en un protocolo en el
que el host 1 diga:”Ya termine, ¿Terminaste también?”. Si el host 2
responde “Ya termine también. Adiós”, la conexión puede liberarse
con seguridad.
Pero no es tan fiable por el problema de que siempre tendremos
que esperar la confirmación de los mensajes recibidos y si esta
confirmación no llega no libera la conexión y después puede que
necesite la confirmación de que llego la confirmación y entraríamos
en un bucle del que no podemos salir.
Podemos hacer que al host 1 si no le llega la confirmación después
de N intentos (es que quiere la desconexión), se libere. Esto
produce una conexión semiabierta en la que el host 1 está
desconectado pero el host 2 no como no le llega la confirmación no
se desconecta nunca. Para solucionar esto creamos una regla por la
cual si al host 2 no le llega ninguna TPDU durante cierta cantidad de
segundos, se libera automáticamente.

7. CONTROL DE FLUJO Y ALMACENAMIENTO EN BUFFER
Ya examinamos la conexión y la desconexión, veamos la manera en
que se manejan las conexiones mientras están en uso. Uno de los
aspectos clave es el control de flujo. Necesitamos un esquema para
evitar que un emisor rápido desborde a un receptor lento. La
diferencia principal es que un enrutador por lo regular tiene
relativamente pocas líneas, y un host puede tener numerosas
conexiones. Esta diferencia hace poco práctico emplear la
implementación que se hace en la capa de enlace
En esta capa lo que se hace es, si el servicio de red no es confiable,
el emisor debe almacenar en un buffer todas las TPDUs enviadas,
igual que en la capa enlace de datos. Sin embargo, con un servicio
de red confiable son posibles otros arreglos. En particular, si el
emisor sabe que el receptor siempre tiene espacio de buffer, no
necesita tener copias de las TPDUs que envía. Sin embargo, si el
receptor no garantiza que se aceptará cada TPDU que llegue, el
emisor tendrá que usar buffers de todas maneras. En el último
caso, el emisor no puede confiar en la confirmación de recepción
de la capa red porque esto sólo significa que ha llegado la TPDU, no
que ha sido aceptada.
Los Buffers pueden ser de tres tipos, y usaremos cada uno de ellos
cuando más nos convenga.
El equilibrio óptimo entre el almacenamiento del buffer en el
origen y en el destino depende del tipo de trafico transportado por
la conexión.

8. Multiplexión
La multiplexión de varias conversaciones en conexiones, circuitos
virtuales o enlaces físicos desempeña un papel importante en
diferentes capas de la arquitectura de red. En la capa de transporte
puede surgir la necesidad de multiplexión por varias razones. Por
ejemplo, si en un host sólo se dispone de una dirección de red,
todas la conexiones de transporte de esa máquina tendrán que
utilizarla. Cuando llega una TPDU, se necesita algún mecanismo
para saber a cuál proceso asignarla. Esta situación se conoce como
multiplexión hacia arriba.
La multiplexión también puede ser útil en la capa transporte para la
utilización de circuitos virtuales, que dan más ancho de banda
cuando se reasigna a cada circuito una tasa máxima de datos. La
solución es abrir múltiples conexiones de red y distribuir el tráfico
entre ellas. Esto se denomina multiplexión hacia abajo.
RECUPERACIÓN DE CAÍDAS
Si los hosts y los enrutadores están sujetos a caídas, la recuperación
es fundamental. Si la entidad de transporte está por entero dentro
de los hosts, la recuperación de caídas de red y de enrutadores es
sencilla. Si la capa de red proporciona servicio de datagramas, las
entidades de transporte esperan pérdida de algunas TPDUs todo el
tiempo, y saben cómo manejarla. Si la capa de red proporciona
servicio orientado a la conexión, entonces la pérdida de un circuito
virtual se maneja estableciendo otro nuevo y sondeando la entidad
de transporte remota para saber cuáles TPDUs ha recibido y cuáles
no.

9. Un problema más complicado es la manera de recuperarse de
caídas del host. Al reactivarse, sus tablas están en el estado inicial y
no sabe con precisión donde estaba.
En un intento por recuperar su estado previo, el servidor podría
enviar una TPDU de difusión a todos los demás host, anunciando
que se acaba de caer y solicitando a todos sus clientes que le
informen el estado de todas la conexiones abiertas.

11. Funciones de la Capa De Trasporte
• Esta capa debe proporcionar un transporte de datos confiable y
económico desde la máquina origen a la máquina de destino,
independientemente de la red o redes físicas en uso.
• La capa de transporte es el corazón de la jerarquía de protocolos.
• 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.
• Define los mecanismos para mantener la confiabilidad de las
comunicaciones en la red.
• Su función es regular el flujo de mensajes, retransmisión de
paquetes, inicio y término de sesiones entre nodos.
Protocolo TCP
El protocolo TCP es el encargado de dividir el mensaje original en
segmentos de menor tamaño, más manejables, que serán luego
empaquetados en datagramas o paquetes y dirigidos a través del
protocolo IP de forma individual, y añade a cada uno de los
datagramas información necesaria para su manejo, envío y control
de errores en la transmisión.

12. Comunicación con Confiabilidad
La diferencia clave entre TCP y UDP es la confiabilidad
La confiabilidad de la comunicación TCP se lleva a cabo utilizando
sesiones orientadas a la conexión. Antes de que un host que utiliza
TCP envíe datos a otro host, la capa de Transporte inicia un proceso
para crear una conexión con el destino. Esta conexión permite el
rastreo de una sesión o stream de comunicación entre los hosts.
Este proceso asegura que cada host tenga conocimiento de la
comunicación y se prepare. Una conversación TCP completa
requiere el establecimiento de una sesión entre los hosts en ambas
direcciones.
Luego de establecida la sesión, el destino envía acuses de recibo al
origen por los segmentos que recibe. Estos acuses de recibo forman
la base de la confiabilidad dentro de la sesión TCP. Cuando el origen
recibe un acuse de recibo, reconoce que los datos se han entregado
con éxito y puede dejar de rastrearlos. Si el origen no recibe el
acuse de recibo dentro de un tiempo predeterminado, retransmite
esos datos al destino.
Parte de la carga adicional que genera el uso de TCP es el tráfico de
red generado por los acuses de recibo y las retransmisiones. El
establecimiento de las sesiones genera cargas en forma de
segmentos adicionales intercambiados. También existen cargas
adicionales en los hosts individuales, generadas por la necesidad de
mantener un seguimiento de los segmentos que esperan acuse de
recibo y por el proceso de retransmisión.

13. Esta confiabilidad se logra contando con campos en el segmento
TCP, cada uno con una función específica.
Procesos del servidor TCP
Como se explicó en el capítulo anterior, los procesos de aplicación
se ejecutan en servidores. Estos procesos esperan hasta que un
cliente inicie comunicación con una solicitud de información o de
otros servicios.
Cada proceso de aplicación que se ejecuta en el servidor es
configurado por el administrador del sistema para utilizar un
número de puerto, de forma predeterminada o manual. Un
servidor individual no puede tener dos servicios asignados al mismo
número de puerto dentro de los mismos servicios de la capa de
Transporte.

14. Un host que ejecuta una aplicación de servidor Web y una de
transferencia de archivos no puede configurar ambas para utilizar
el mismo puerto (por ejemplo, el puerto TCP 8.080). Cuando una
aplicación de servidor activa se asigna a un puerto específico, este
puerto se considera "abierto" para el servidor. Esto significa que la
capa de Transporte acepta y procesa segmentos direccionados a
ese puerto. Toda solicitud entrante de un cliente direccionada al
socket correcto es aceptada y los datos se envían a la aplicación del
servidor. Pueden existir varios puertos simultáneos abiertos en un
servidor, uno para cada aplicación de servidor activa. Es común que
un servidor provea más de un servicio, como un servidor Web y un
servidor FTP, al mismo tiempo.

15. Una manera de mejorar la seguridad en un servidor es restringir el
acceso al servidor a sólo aquellos puertos asociados con los
servicios y aplicaciones accesibles a solicitantes autorizados. La
figura muestra la asignación típica de puertos de origen y destino
en operaciones de cliente o servidor TCP.

16. Establecimiento y finalización de la conexión TCP
Cuando dos hosts se comunican utilizando TCP, se establece una
conexión antes de que puedan intercambiarse los datos. Luego de
que se completa la comunicación, se cierran las sesiones y la
conexión finaliza. Los mecanismos de conexión y de sesión habilitan
la función de confiabilidad de TCP.
Ver la figura para observar los pasos para establecer y finalizar una
conexión TCP.
El host rastrea cada segmento de datos dentro de una sesión e
intercambia información sobre los datos recibidos por cada host a
través de la información del encabezado TCP.
Cada conexión representa dos streams de comunicación de una vía
o sesiones. Para establecer la conexión los hosts realizan un
intercambio de señales de tres vías. Los bits de control en el
encabezado TCP indican el progreso y estado de la conexión. Enlace
de tres vías:
• Establece que el dispositivo de destino esté presente en la
red.
• Verifica que el dispositivo de destino tenga un servicio activo
y esté aceptando las peticiones en el número de puerto de
destino que el cliente que lo inicia intente usar para la sesión.
• Informa al dispositivo de destino que el cliente de origen
intenta establecer una sesión de comunicación en ese
número de puerto.

17. En conexiones TCP, el host que brinde el servicio como cliente inicia
la sesión al servidor. Los tres pasos para el establecimiento de una
conexión TCP son:
1. El cliente que inicia la conexión envía un segmento que
contiene un valor de secuencia inicial, que actúa como
solicitud para el servidor para comenzar una sesión de
comunicación.
2. El servidor responde con un segmento que contiene un valor
de reconocimiento igual al valor de secuencia recibido más 1,
además de su propio valor de secuencia de sincronización. El
valor es uno mayor que el número de secuencia porque el
ACK es siempre el próximo Byte u Octeto esperado. Este valor
de reconocimiento permite al cliente unir la respuesta al
segmento original que fue enviado al servidor.
3. El cliente que inicia la conexión responde con un valor de
reconocimiento igual al valor de secuencia que recibió más
uno. Esto completa el proceso de establecimiento de la
conexión.
Para entender el proceso de enlace de tres vías, es importante
observar los distintos valores que intercambian los dos hosts.
Dentro del encabezado del segmento TCP, existen seis campos de 1
bit que contienen información de control utilizada para gestionar
los procesos de TCP. Estos campos son los siguientes:
URG: Urgente campo de señalizador significativo.
ACK: Campo significativo de acuse de recibo.
PSH: Función de empuje.
RST: Reconfiguración de la conexión.

18. SYN: Sincronizar números de secuencia.
FIN: No hay más datos desde el emisor.
A estos campos se los denomina señaladores porque el valor de
uno de estos campos es sólo de 1 bit, entonces tiene sólo dos
valores: 1 ó 0. Si el valor del bit se establece en 1, indica la
información de control que contiene el segmento.
Si se utiliza un proceso de cuatro pasos, los señalizadores se
intercambian para finalizar la conexión TCP

19. Terminación de la sesión TCP
Para cerrar la conexión se debe establecer el señalizador de control
FIN (Finalizar) en el encabezado del segmento. Para finalizar todas
las sesiones TCP de una vía, se utiliza un enlace de dos vías, que
consta de un segmento FIN y un segmento ACK. Por lo tanto, para
terminar una conversación simple admitida por TCP, se requieren
cuatro intercambios para finalizar ambas sesiones.
Nota: En esta explicación se usan los términos cliente y servidor
como referencia por simplicidad
Pero la finalización del proceso puede ser iniciada por cualquiera de
los dos hosts que completen la sesión:
1. Cuando el cliente no tiene más datos para enviar al stream,
envía un segmento con el señalizador FIN establecido.
2. El servidor envía un ACK para acusar recibo de Fin y terminar
la sesión del cliente al servidor.
3. El servidor envía un FIN al cliente para finalizar la sesión del
servidor al cliente.
4. El cliente responde con un ACK para dar acuse de recibo de
FIN desde el servidor.
Cuando la finalización de sesión del cliente no tiene más datos para
transferir, establece el señalizador FIN en el encabezado de un
segmento. Luego, el servidor finaliza la conexión y envía un
segmento normal que contiene datos con el señalizador ACK
establecido utilizando el número de acuse de recibo, confirmando
así que se han recibido todos los bytes de datos.

20. Cuando se produce el acuse de recibo de todos los segmentos, se
cierra la sesión.
La sesión en la otra dirección se cierra mediante el mismo proceso.
El receptor indica que no existen más datos para enviar
estableciendo el señalizador FIN en el encabezado del segmento
enviado al origen. Un acuse de recibo de retorno confirma que
todos los bytes de datos han sido recibidos y, por lo tanto, se ha
cerrado la sesión.
Como se muestra en la figura, los señalizadores de control FIN y
ACK se establecen en el encabezado del segmento, cerrando por
lo tanto la sesión HTTP.
También es posible terminar la conexión mediante 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
ACK.
Actividad con Packet Tracer
En esta actividad, estudiará el protocolo de enlace de tres vías de
TCP para el establecimiento de sesión y el proceso TCP para la
terminación de la sesión. Muchos protocolos de aplicación utilizan
TCP y visualizar el establecimiento de la sesión y los procesos de
terminación con el Packet Tracer profundizará sus conocimientos.

21. Administración de sesiones TCP
Cuando los servicios envían datos utilizando TCP, los segmentos
pueden llegar a destinos desordenados. Para que el receptor
comprenda el mensaje original, los datos en estos segmentos se
reensamblan en el orden original. Para lograr esto, se asignan
números de secuencia en el encabezado de cada paquete.
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. A medida que se transmiten los datos
durante la sesión, el número de secuencia se incrementa en el
número de bytes que se han transmitido. Este rastreo de bytes de
datos permite que cada segmento se identifique y se envíe acuse
de recibo de manera exclusiva. Se pueden identificar segmentos
perdidos.
Los números de secuencia de segmento permiten la confiabilidad
indicando cómo reensamblar y reordenar los segmentos recibidos,
como se muestra en la figura.
El proceso TCP receptor coloca los datos del segmento en un búfer
de recepción. Los segmentos se colocan en el orden de número de
secuencia adecuado y se pasa a la capa de Aplicación cuando son
reensamblados. Todos los segmentos que llegan con números de
secuencia no contiguos se mantienen para su procesamiento
posterior. Luego, se procesan los segmentos cuando llegan con los
bytes perdidos.

22. Acuse de recibo de TCP con uso de ventanas
Una de las funciones de TCP es asegurar que cada segmento llegue
a su destino. Los servicios TCP en el host de destino envían a la
aplicación de origen un acuse de recibo de los datos recibidos.
El número de secuencia y el número de acuse de recibo del
encabezado del segmento se utilizan para confirmar la recepción de
los bytes de datos contenidos en los segmentos. El número de
secuencia es el número relativo de bytes que ha sido transmitido en
esta sesión más 1 (que es el número del primer byte de datos en el
segmento actual). TCP utiliza el número de reconocimiento en
segmentos que se vuelven a enviar al origen para indicar el próximo
byte de esta sesión que espera el receptor. Esto se llama acuse de
recibo de expectativa.

23. Se le informa al origen que el destino ha recibido todos los bytes de
este stream de datos, pero sin incluir, el byte especificado por el
número de acuse de recibo. Se espera que el host emisor envíe un
segmento que utiliza un número de secuencia igual al número de
acuse de recibo.
Recuerde que cada conexión se representa en realidad por dos
sesiones de una vía. Los números de secuencia y de acuse de recibo
se intercambian en ambas direcciones.
En el ejemplo de la figura, el host en la izquierda envía datos al host
de la derecha. Envía un segmento que contiene 10 bytes de datos
para esta sesión y un número de secuencia igual a 1 en el
encabezado.
El host receptor de la derecha recibe el segmento en la Capa 4 y
determina que el número de secuencia es 1 y que posee 10 bytes
de datos. Luego el host envía un segmento de vuelta al host de la
izquierda para acusar recibo de estos datos. En este segmento, el
host establece el número de acuse de recibo en 11 para indicar que
el próximo byte de datos que espera recibir en esta sesión es el
byte número 11.
Cuando el host emisor de la izquierda recibe este acuse de recibo,
puede enviar el próximo segmento que contiene datos para esta
sesión a partir del byte 11.
Observando este ejemplo, si el host emisor tuviera que esperar el
acuse de recibo por la recepción de cada uno de los 10 bytes, la red
estaría demasiado sobrecargada. Para reducir la sobrecarga de
estos acuses de recibo, los segmentos de datos múltiples pueden
enviarse previamente y ser reconocidos con un mensaje TCP simple
en la dirección opuesta. Este reconocimiento contiene un número

24. de acuse de recibo en base al número total de bytes recibidos en la
sesión.
Por ejemplo, si se comienza con un número de secuencia 2000, si se
reciben 10 segmentos de 1000 bytes cada uno, se devolverá al
origen un número de reconocimiento igual a 12001.
La cantidad de datos que un origen puede transmitir antes de que
un acuse de recibo deba ser recibido se denomina tamaño de la
ventana. El tamaño de la ventana es un campo en el encabezado
TCP que permite la administración de datos perdidos y el control
del flujo.

25. Retransmisión de TCP
Manejo de la pérdida de segmentos
Por óptimo que sea el diseño de una red, siempre se producirán
pérdidas ocasionales de datos. Por lo tanto, TCP cuenta con
métodos para gestionar dichas pérdidas de segmentos. Entre los
mismos existe un mecanismo para retransmitir segmentos con
datos no reconocidos.
Un servicio de host de destino que utiliza TCP, por lo general sólo
reconoce datos para secuencias de bytes contiguas. Si uno o más
segmentos se pierden, sólo se acusa recibo de los datos de los
segmentos que completan el stream.
Por ejemplo, si se reciben los segmentos con números de secuencia
de 1500 a 3000 y de 3400 a 3500, el número de acuse de recibo
será 3001. Esto sucede porque existen segmentos con números de
secuencia de 3001 a 3399 que no se recibieron.
Cuando TCP en el host de origen no recibe un acuse de recibo
pasado un tiempo predeterminado, volverá al último número de
acuse de recibo que recibió y retransmitirá los datos a partir de
éste.
El proceso de retransmisión no es especificado por RFC, sino que
depende de la implementación de TCP en particular.
Para una implementación de TCP típica, un host puede transmitir
un segmento, colocar una copia del segmento en una cola de
retransmisión e iniciar un temporizador. Cuando se recibe el acuse
de recibo de los datos, se elimina el segmento de la cola. Si no se
recibe el acuse de recibo antes de que el temporizador venza, el
segmento es retransmitido.

26. Los hosts actuales también suelen emplear una función opcional
llamada Acuses de recibo selectivos. Si ambos hosts admiten el
Acuse de recibo selectivo, es posible que el destino reconozca los
bytes de segmentos discontinuos y el host sólo necesitará
retransmitir los datos perdidos.
Control de congestión de TCP: Cómo minimizar la pérdida de
segmentos
Control del flujo
TCP si provee mecanismos para el control del flujo. El control del
flujo contribuye con la confiabilidad de la transmisión TCP
ajustando la tasa efectiva de flujo de datos entre los dos servicios
de la sesión. Cuando el origen advierte que se recibió la cantidad de
datos especificados en los segmentos, puede continuar enviando
más datos para esta sesión.
El campo Tamaño de la ventana en el encabezado TCP especifica la
cantidad de datos que puede transmitirse antes de que se reciba el
acuse de recibo. El tamaño de la ventana inicial se determina
durante el comienzo de la sesión a través del enlace de tres vías.
El mecanismo de retroalimentación de TCP ajusta la tasa de
transmisión de datos efectiva al flujo máximo que la red y el
dispositivo de destino pueden soportar sin sufrir pérdidas. TCP
intenta gestionar la tasa de transmisión de manera que todos los
datos se reciban y se reduzcan las retransmisiones.
Ver la figura para obtener una representación simplificada del
tamaño de la ventana y los acuses de recibo. En este ejemplo, el
tamaño de la ventana inicial para una sesión TCP representada se
establece en 3000 bytes. Cuando el emisor transmite 3000 bytes,

27. espera por un acuse de recibo de los mismos antes de transmitir
más segmentos para esta sesión.
Una vez que el emisor ha recibido este acuse de recibo del
receptor, ya puede transmitir 3000 bytes adicionales.
Durante la demora en la recepción del acuse de recibo, el emisor no
enviará ningún segmento adicional para esta sesión. En los
períodos en los que la red está congestionada o los recursos del
host receptor están exigidos, la demora puede aumentar. A medida
que aumenta esta demora, disminuye la tasa de transmisión
efectiva de los datos para esta sesión. La disminución de la tasa de
datos ayuda a reducir la contención de recursos.

28. Reducción del tamaño de la ventana
Otra forma de controlar el flujo de datos es utilizar tamaños
dinámicos de ventana. Cuando los recursos de la red son limitados,
TCP puede reducir el tamaño de la ventana para lograr que los
segmentos recibidos sean reconocidos con mayor frecuencia. Esto
disminuye de manera efectiva la tasa de transmisión, ya que el
origen espera que los datos sean recibidos con más frecuencia.
El host receptor TCP envía el valor del tamaño de la ventana al TCP
emisor para indicar el número de bytes que está preparado para
recibir como parte de la sesión. Si el destino necesita disminuir la
tasa de comunicación debido a limitaciones de memoria del búfer,
puede enviar un valor de tamaño de la ventana menor al origen
como parte de un acuse de recibo.
Como se muestra en la figura, si un host de recepción sufre una
congestión, puede responder al host emisor con un segmento con
el tamaño de la ventana reducido. En este gráfico, se produjo la
pérdida de uno de los segmentos. El receptor cambió el campo
ventana en el encabezado de los mensajes devueltos en esta
conversación de 3000 a 1500. Esto hizo que el emisor redujera el
tamaño de la ventana a 1500.
Después de períodos de transmisión sin pérdidas de datos o
recursos limitados, el receptor comenzará a aumentar el tamaño de
la ventana. Esto reduce la sobrecarga de la red, ya que se requiere
enviar menos acuses de recibo. El tamaño de la ventana continuará
aumentando hasta que haya pérdida de datos, lo que producirá una
disminución del tamaño de la ventana.
Estas disminuciones y aumentos dinámicos del tamaño de la
ventana representan un proceso continuo en TCP, que determina el
tamaño de la ventana óptimo para cada sesión TCP. En redes

29. altamente eficientes, los tamaños de la ventana pueden ser muy
grandes porque no se pierden datos. En redes donde se está
estresando la infraestructura subyacente, el tamaño de la ventana
probablemente permanecerá pequeño.
Enlaces
Detalles de las varias características de administración de la
congestión de TCP se pueden encontrar en RFC 2581.

30. Protocolo UDP
El protocolo TCP tiene la robustez, la confiabilidad y las
funcionalidades propias de un protocolo de transporte orientado a
conexión, pero a veces resulta demasiado complejo. Por ejemplo,
cualquier transmisión de información TCP requiere como mínimo el
intercambio de seis mensajes para establecer la comunicación y
terminarla; además mientras una conexión existe ocupa una serie
de recursos en el host.
Para casos en los que no es necesario tanto control de los datos
enviados la Capa de Transporte implementa también el Protocolo
de Datagrama de Usuario (UDP), protocolo no confiable y no
orientado a conexión para la entrega de mensajes discretos. En este
caso los paquetes enviados mediante el protocolo IP reciben el
nombre específico de datagramas, y estos se envían y ya está; no se
realiza una conexión definida entre los host ni un control de los
paquetes enviados y recibidos. Los datagramas se rutean
independientemente, por lo que deben llevar las dirección
completa de destino.
UDP es un protocolo estándar con número 6 de STD. Este protocolo
se describe en el RFC 768 - Protocolo de Datagrama de Usuario. Es
simple, eficiente e ideal para aplicaciones como el TFTP y el DNS.
Una dirección IP sirve para dirigir el datagrama hacia una máquina
en particular, y el número de puerto de destino en la cabecera UDP
se utiliza para dirigir el datagrama UDP a un proceso específico en
dicha máquina. La cabecera UDP también contiene un número de
puerto origen que permite al proceso recibido conocer cómo
responder al datagrama.
Es una alternativa al TCP en aquellos casos en los que no sea
necesaria tanta complejidad en el envío, por lo que se usa cuando

31. una entrega rápida es más importante que una entrega
garantizada, o en los casos en que se desea enviar tan poca
información que cabe en un único datagrama. Así, una de sus
utilidades más comunes es el envío de mensajes entre aplicaciones
de dos host.
Es por ello un protocolo del tipo best-effort (máximo esfuerzo),
porque hace lo que puede para transmitir los datagramas hacia la
aplicación, pero no puede garantizar que la aplicación los reciba.
Tampoco utiliza mecanismos de detección de errores. Cuando se
detecta un error en un datagrama, en lugar de entregarlo a la
aplicación destino, se descarta.
Cuando una aplicación envía datos a través de UDP, éstos llegan al
otro extremo como una unidad. Por ejemplo, si una aplicación
escribe 5 veces en el puerto UDP, la aplicación al otro extremo hará

32. 5 lecturas del puerto UDP. Además, el tamaño de cada escritura
será igual que el tamaño de las lecturas.
AL igual que TCP, UDP usa al protocolo IP para transportar sus
segmentos. El formato del segmento UDP es el siguiente:
segmento UDP
0 10 20 30
0123456789012345678901234567890 1
Puerto UDP origen Puerto UDP destino
Longitud del datagrama Checksum UDP
Datos
...
Cuyos campos principales son:
• Puerto UDP de origen: campo opcional de 16 bits que
especifica el puerto del host origen remitente del datagrama.
• Puerto UDP de destino: campo obligatorio de 16 bits que
especifica el puerto del host destino al que se envía el
datagrama.
• Longitud del datagrama: campo obligatorio de 16 bits que
especifica la longitud en bytes del datagrama, incluyendo la
cabecera. La longitud mínima es de 8 bytes. En realidad es la
longitud del datagrama IP menos el tamaño de la cabecera IP.
Como la longitud máxima del datagrama IP es de 65.535 bytes
y la cabecera estándar de IP es de 20 bytes, la longitud
máxima de un datagrama UDP es de 65.515 bytes.
• Checksum UDP: campo de 16 bits opcional que almacena una
suma de comprobación de errores del datagrama, que se
calcula a partir de una pseudo-cabecera.

33. Si el checksum es cero, quiere decir que no se calculó el
checksum en el origen y que puede ser ignorado. Esto significa
que el módulo UDP del computador origen puede o no
generar checksums. Si Ethernet es el único tipo de red entre
los dos módulos UDP que se comunican, entonces puede que
no sea necesario calcular el checksum. Sin embargo, es
recomendable habilitar la generación de checksums porque
quizás en el futuro un cambio en la tabla de encaminamiento
puede enviar los datos a través de un medio menos fiable que
Ethernet.
Si el checksum es válido (o cero), se examina el número de
puerto destino y si hay una aplicación escuchando en ese
puerto, un mensaje de aplicación queda en la cola de lectura
de esa aplicación. Si no hay ninguna aplicación en ese puerto,
el datagrama UDP se descarta. Si los datagramas UDP llegan
más rápido de lo que la aplicación puede leerlos, la cola
comenzará a llenarse; si se sobrepasa un valor máximo, los
datagramas UDP siguientes serán descartados por UDP. UDP
seguirá descartando datagramas hasta que haya espacio en la
cola.
• Datos: campo obligatorio que contiene los datos que se
envían las aplicaciones con el datagrama.
Algunos ejemplos de situaciones en las que es más conveniente un
servicio no orientado a conexión, en los que es más útil un
protocolo del tipo UDP, son:
• Aplicaciones tiempo real como audio o video, donde no se
puede tolerar el retardo producido por los ACK.
• Consultas a servidores en que se requiere el envío de uno o
dos mensajes únicamente como es el caso del DNS.

34. • Situaciones en las que se necesita conectar con un ordenador
de la propia red, usando para ello el nombre del sistema. Para
ello hay que conectar primero con el servidor de red
apropiado para que transforme dicha dirección de red en una
dirección IP válida, siendo en este caso más apropiado el
protocolo UDP.
• Cuando queremos transmitir información en modo multicast
(a muchos destinos) o en modo broadcast (a todos los
destinos) pues no tiene sentido esperar la confirmación de
todos los destinos para continuar con la transmisión. También
es importante tener en cuenta que si en una transmisión de
este tipo los destinos enviarán confirmación, fácilmente el
emisor se vería colapsado, pues por cada paquete que envía
recibiría tantas confirmaciones como destinos hayan recibido
el paquete.
Entre los protocolos superiores que usan UDP se incluyen TFTP
(Trivial File Transfer Protocol), DNS (Domain Name Server), SNMP
(Simple Network Management Protocol), NTP (Network Time
Protocol), NFS (Network File System), etc.