El modelo de referencia de Interconexión de Sistemas Abiertos (OSI, Open System Interconnection)

lanzado en 1984 fue el modelo de red descriptivo creado por ISO; esto es, un marco de referencia
para la definición de arquitecturas de interconexión de sistemas de comunicaciones.
El modelo en sí mismo no puede ser considerado una arquitectura, ya que no especifica el
protocolo que debe ser usado en cada capa, sino que suele hablarse de modelo de referencia. Este
modelo está dividido en siete capas:

 Capa de aplicación (capa 7)

 Capa de presentación (capa 6)
 Capa de sesión (capa 5)
 Capa de transporte (capa 4)
 Capa de red (capa 3)
 Capa de enlace de datos (capa 2)
 Capa física (capa 1)

Entre los protocolos (refiriéndose a protocolos genéricos, no a protocolos de la capa de

aplicación de OSI) más conocidos destacan:

1. HTTP (HyperText Transfer Protocol) el protocolo bajo la www

2. FTP (File Transfer Protocol) ( FTAM, fuera de TCP/IP) transferencia de ficheros
3. SMTP (Simple Mail Transfer Protocol) (X.400 fuera de tcp/ip) envío y distribución de correo
electrónico.
4. POP (Post Office Protocol)/IMAP: reparto de correo al usuario final.
5. SSH (Secure SHell) principalmente terminal remoto, aunque en realidad cifra casi cualquier
tipo de transmisión.
6. Telnet otro terminal remoto, ha caído en desuso por su inseguridad intrínseca, ya que las
claves viajan sin cifrar por la red.

Hay otros protocolos de nivel de aplicación que facilitan el uso y administración de la red:
1. SNMP (Simple Network Management Protocol)
2. DNS (Domain Name System)

CAPA DE TRANPORTE – CAPA 4

Capa de 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.

Es la base de toda la jerarquía de protocolo. 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.

1. SERVICIOS

1.1. Servicios que se proporcionan a las capas superiores

La meta final de la capa transporte es proporcionar un servicio eficiente, confiable y económico

a sus usuarios, que normalmente son procesos de la capa aplicación. Para lograr este objetivo,
la capa transporte utiliza los servicios proporcionados por la capa de red.

El hardware o software de la capa transporte que se encarga del trabajo se llama entidad de

transporte, la cual puede estar en el núcleo del sistema operativo, en un proceso
independiente, en un paquete de biblioteca o en la tarjeta de red.

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.

figura 6-1 se ilustra la relación (lógica) entre las capas de red, transporte y aplicación

Los usuarios no tienen un control real sobre la capa de red, por lo que no pueden resolver los
problemas de un mal servicio usando mejores enrutadores o incrementando el manejo de errores
en la capa de enlace de datos, puesto que no son dueños de los enrutadores. La única posibilidad
es poner encima de la capa de red otra capa que mejore la calidad del servicio. Si en una red sin
conexión se pierden paquetes o se rompen, la entidad de transporte puede detectar el problema y
compensarlo mediante el uso de retransmisiones. Si, en una red orientada a conexión, se informa a
la entidad de transporte a la mitad de una transmisión extensa que su conexión de red ha sido
terminada de manera abrupta, sin indicación de lo que ha sucedido a los datos actualmente en
tránsito, la entidad puede establecer una nueva conexión de red con la entidad de transporte
remota. A través de esta nueva conexión de red, la entidad puede enviar una solicitud a su igual
para preguntarle cuáles datos llegaron y cuáles no, y como sabe en dónde se encontraba, puede
reiniciar a partir de donde se originó la interrupción.
En esencia, la existencia de la capa de transporte hace posible que el servicio de transporte sea
más confiable que la red subyacente. Además, las primitivas de transporte se pueden implementar
como llamadas a procedimientos de biblioteca para que sean independientes de las primitivas de
red. Gracias a la capa de transporte, los programadores de aplicaciones pueden escribir código de
acuerdo con un conjunto estándar de primitivas; estos programas pueden funcionar en una amplia
variedad de redes sin necesidad de preocuparse por lidiar con diferentes interfaces de red y
distintos niveles de confiabilidad.
1.2. 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.

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. 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:

Con estas primitivas se puede 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.
2. 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.

(a) Entorno de la capa de enlace de datos. (b) Entorno de la capa de transporte.

2.1. 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. Usaremos el término genérico TSAP
(Punto de Acceso al Servicio de Transporte, del inglés Transport Service Access Point) para
indicar un punto terminal específico en la capa de transporte. Así, no es sorpresa que los puntos
terminales análogos en la capa de red (es decir, direcciones de capa de red) se llamen NSAP
(Punto de Acceso al Servicio de Red, del inglés Network Service Access Points). Las direcciones
IP son ejemplos de NSAP.
 Los puntos TSAP y NSAP, junto con las conexiones de transporte

2.2. 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 suficiente con que una entidad de transporte enviara tan sólo un segmento
CONNECTION REQUEST al destino y esperara una respuesta CONNECTION ACCEPTED. El
problema ocurre cuando la red puede perder, retrasar, corromper y duplicar paquetes. Este
comportamiento causa complicaciones serias.

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 seria 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.

Necesitamos un enfoque diferente para simplificar el problema. En lugar de permitir que los
paquetes vivan eternamente dentro de la red, debemos idear un mecanismo para eliminar a los
paquetes viejos que aún andan vagando por ahí. Con esta restricción, el problema se vuelve algo
más manejable.
El tiempo de vida de un paquete puede restringirse a un máximo conocido mediante el uso de una
(o más) de las siguientes técnicas:
1. Un diseño de red restringido.
2. Colocar un contador de saltos en cada paquete.
3. Marcar el tiempo en cada paquete.
2.3. 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 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 perdida 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.

Desconexión abrupta con pérdida de datos

La liberación simétrica es ideal cuando cada proceso tiene una cantidad fija de datos por enviar y
sabe con certeza cuándo los ha enviado. En otras situaciones, el proceso de determinar si se ha
efectuado o no todo el trabajo y si debe terminar o no la conexión no es tan obvio. Podríamos
pensar en un protocolo en el que el host 1 diga: “Ya terminé. ¿Terminaste también?” Si el host 2
responde: “Ya terminé también. Adiós”, la conexión se puede liberar sin problemas.

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.
Cuatro escenarios de un protocolo para liberar una conexión. (a) Caso normal del acuerdo de tres vías.
(b) Pérdida del último ACK. (c) Respuesta perdida. (d) Respuesta perdida y pérdida de los segmentos DR subsecuentes.

2.4. Control de errores y almacenamiento en búfer

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 practico 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.

2.5. 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 maquina tendrán
que utilizarla. Cuando llega un segmento (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.

(a) Multiplexión. (b) Multiplexión inversa.

2.6. Recuperación de fallas

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 mediante el uso de
retransmisiones.

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
cuales TPDUs ha recibido y cuales no.

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 las conexiones abiertas.
 Distintas combinaciones de estrategias de cliente y servidor

3. SERVICIOS Y FUNCIONES 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 streams de comunicación. Las responsabilidades
principales que debe cumplir son:

 Rastreo de comunicación individual entre aplicaciones en los hosts de origen y destino

 Segmentación de datos y manejo de cada parte
 Reensamble de segmentos en streams de datos de aplicación
 Identificación de diferentes aplicaciones

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 streams de comunicación múltiple entre
estas aplicaciones.
Segmentación de Datos
Así como cada aplicación crea datos de stream 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.
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 Aplicaciones
Para pasar streams de datos a las aplicaciones adecuadas, la capa de transporte debe identificar la
aplicación meta. Para lograr esto, la capa de transporte asigna un identificador a la aplicación. Los
protocolos TCP/IP denominan a este identificador número de puerto. A todos los procesos de
software que requieran acceder a la red se les asigna un número de puerto exclusivo en ese host.
Este número de puerto se utiliza en el encabezado de la capa de transporte para indicar con qué
aplicación se asocia esa sección de datos.
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.
Las aplicaciones no necesitan saber los detalles operativos de la red en uso. Las aplicaciones
generan datos que se envían desde una aplicación a otra sin tener en cuenta el tipo de host destino,
el tipo de medios sobre los que los datos deben viajar, el paso tomado por los datos, la congestión
en un enlace o el tamaño de la red.
Además, las capas inferiores no tienen conocimiento de que existen varias aplicaciones que envían
datos en la red. Su responsabilidad es entregar los datos al dispositivo adecuado. La capa de
transporte clasifica entonces estas piezas antes de enviarlas a la aplicación adecuada.
Los requerimientos de datos varían
Debido a que las distintas aplicaciones poseen distintos requerimientos, existen varios protocolos
de la capa de Transporte. Para algunas aplicaciones, los segmentos deben llegar en una secuencia
específica de manera que puedan ser procesados en forma exitosa. En algunos casos, todos los
datos deben recibirse para ser utilizados por cualquiera de las mismas. En otros casos, una
aplicación puede tolerar cierta pérdida de datos durante la transmisión a través de la red.

Separación de comunicaciones múltiples

Considere una computadora conectada a una red que recibe y envía e-mails y mensajes
instantáneos, explora sitios Web y realiza una llamada telefónica de VoIP de manera simultánea.
Cada una de estas aplicaciones envía y recibe datos en la red al mismo tiempo. Sin embargo, los
datos de la llamada telefónica no se direccionan al explorador Web y el texto de un mensaje
instantáneo no aparece en el e-mail.
4. PROTOCOLOS DE LA CAPA DE TRANSPORTE
Tiene dos protocolos comunes:
TCP es un protocolo orientado a la conexión, descrito en la RFC 793; incurre en el uso adicional de
recursos para agregar funciones. Las funciones adicionales especificadas por TCP están en el
mismo orden de entrega, son de entrega confiable y de control de flujo. Cada segmento de TCP
posee 20 bytes de carga en el encabezado, que encapsulan los datos de la capa de Aplicación,
mientras que cada segmento UDP sólo posee 8 bytes de carga.
Protocolo de datagramas de usuario (UDP); es un protocolo simple, sin conexión, descrito en la
RFC 768. Cuenta con la ventaja de proveer la entrega de datos sin utilizar muchos recursos. Las
porciones de comunicación en UDP se llaman datagramas. Este protocolo de la capa de Transporte
envía estos datagramas como "mejor intento". 

4.1. PROTOCOLO UDP

La suite de protocolos de Internet soporta un protocolo de transporte sin conexión, conocido como
UDP (Protocolo de Datagrama de Usuario, del inglés Use Datagram Protocol).
UDP es un protocolo simple que provee las funciones básicas de la capa de transporte. Tiene una
sobrecarga mucho menor que el TCP, ya que no está orientado a la conexión y no proporciona
mecanismos sofisticados de retransmisión, secuenciamiento y flujo de control.
Esto no significa que las aplicaciones que utilizan UDP no son siempre poco confiables. Sólo quiere
decir que estas funciones no las contempla el protocolo de la capa de transporte y se deben
implementar aparte, si fuera necesario.
UDP transmite segmentos que consisten en un encabezado de 8 bytes seguido de la carga útil.
Los dos puertos sirven para identifcar los puntos terminales dentro de las máquinas de origen y
destino. Cuando llega un paquete UDP, su carga útil se entrega al proceso que está conectado al
puerto de destino.
De hecho, el valor principal de contar con UDP en lugar de simplemente utilizar IP puro es la adición
de los puertos de origen y destino. Sin los campos de puerto, la capa de transporte no sabría qué
hacer con cada paquete entrante. Con ellos, entrega el segmento incrustado a la aplicación
correcta.

El encabezado UDP

El campo Longitud UDP incluye el encabezado de 8 bytes y los datos. La longitud mínima es de 8
bytes, para cubrir el encabezado. La longitud máxima es de 65 515 bytes, lo cual es menor al
número que cabe en 16 bits debido al límite de tamaño en los paquetes IP.

Pese a que es relativamente baja la cantidad total de tráfico UDP que puede encontrarse en una red
típica, los protocolos clave de la capa de aplicación que utiliza UDP incluyen:

 Sistema de nombres de dominio (DNS)

 Protocolo simple de administración de red (SNMP, Simple Network Management Protocol)
 Protocolo de configuración dinámica de host (DHCP)
 Protocolo de información de enrutamiento (RIP)
 Protocolo de transferencia de archivos trivial (TFTP)
 Juegos en línea

Algunas aplicaciones, tales como los juegos en línea o VoIP, pueden tolerar la pérdida de algunos
datos. Si estas aplicaciones utilizaran TCP, experimentarían largas demoras, ya que TCP detecta la
pérdida de datos y los retransmite. Estas demoras serían más perjudiciales para la aplicación que
las pequeñas pérdidas de datos. Algunas aplicaciones, como DNS, simplemente vuelven a intentar
la solicitud si no reciben una respuesta y, por lo tanto, no necesitan el TCP para garantizar la
entrega del mensaje.

4.2. PROTOCOLO TCP

TCP (Protocolo de Control de Transmisión, del inglés Transmission Control Protocol) se diseñó
específicamente para proporcionar un flujo de bytes confiable de extremo a extremo a través de una
interred no confiable. Una interred difiere de una sola red debido a que sus diversas partes podrían
tener diferentes topologías, anchos de banda, retardos, tamaños de paquete y otros parámetros.
TCP se diseñó para adaptarse de manera dinámica a las propiedades de la interred y sobreponerse
a muchos tipos de fallas.
La entidad TCP emisora y receptora intercambian datos en forma de segmentos. Un segmento
TCP consiste en un encabezado fijo de 20 bytes (más una parte opcional), seguido de cero o más
bytes de datos. El software de TCP decide qué tan grandes deben ser los segmentos. Puede
acumular datos de varias escrituras para formar un segmento, o dividir los datos de una escritura en
varios segmentos.
Hay dos límites que restringen el tamaño de segmento. Primero, cada segmento, incluido el
encabezado TCP, debe caber en la carga útil de 65515 bytes del IP. Segundo, cada enlace tiene
una MTU (Unidad Máxima de Transferencia, del inglés Maximum Transfer Unit). Cada segmento
debe caber en la MTU en el emisor y el receptor, de modo que se pueda enviar y recibir en un solo
paquete sin fragmentar. En la práctica, la MTU es por lo general de 1500 bytes (el tamaño de la
carga útil en Ethernet) y, por tanto, define el límite superior en el tamaño de segmento.
El Modelo del servicio TCP
El servicio TCP se obtiene al hacer que tanto el servidor como el receptor creen puntos terminales,
llamados sockets. Cada socket tiene un número (dirección) que consiste en la dirección IP del host
y un número de 16 bits que es local para ese host, llamado puerto. Un puerto es el nombre TCP
para un TSAP. Para obtener el servicio TCP, hay que establecer de manera explícita una conexión
entre un socket en una máquina y un socket en otra máquina.
Podemos usar un socket para múltiples conexiones al mismo tiempo. En otras palabras, dos o más
conexiones pueden terminar en el mismo socket. Las conexiones se identifican mediante los
identificadores de socket de los dos extremos; esto es, (socket1, socket2). No se utilizan números
de circuitos virtuales u otros identificadores.

4.2.1. Aplicación y Fundamentos de los Mecanismos del Protocolo TCP

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 completa de TCP necesita establecer una sesión entre los hosts de ambas
direcciones.
Después de establecer una sesión, el destino envía un acuse 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. Hay también sobrecarga en los hosts individuales creada
por la necesidad de mantener un registro de los segmentos que esperan un acuse de recibo y por el
proceso de retransmisión.

4.2.2. Administración de Sesiones TCP

Re-secuenciamiento de Segmentos para Transmitir en Orden

Cuando los servicios envían datos mediante el TCP, los segmentos pueden llegar a su destino en
desorden. 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 de recepción del TCP 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 se reensamblan. Todos los segmentos que llegan con números de secuencia no
contiguos se mantienen para su procesamiento posterior. Luego, cuando llegan con los segmentos
con bytes perdidos, se procesan.
Confirmación de Recepción de Segmentos
Una de las funciones del 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 acuse de recibo
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.
Se le informa al origen que el destino ha recibido todos los bytes de este stream de datos, pero sin
incluir el byte que se especifica 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 que es igual al número de acuse de recibo.
Recuerde que cada conexión son realmente dos sesiones de una vía. Los números de secuencia y
los números de acuse de recibo se intercambian en ambas direcciones.
En el ejemplo de la figura, el host de 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. Nota, el valor de Ack. en el host de origen permanece en 1 para
indicar que el segmento es parte de una conversación continua y que el número en el campo de
número de acuse de recibo es válido.
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.

Manejo de Segmentos Perdidos

Por más ó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
estos está un mecanismo para retransmitir segmentos con datos sin acuse de recibo.
Un servicio de host de destino que utiliza TCP generalmente sólo da acuse de recibo de datos para
bytes de secuencia continuos. 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 recibieron los segmentos con números de secuencia de 1500 a 3000 y de 3400 a
3500, el número de acuse de recibo sería 3001. Esto es porque hay segmentos con números de
secuencia del 3001 al 3399 que no se han recibido.
Cuando el TCP en el host de origen no recibe un acuse de recibo luego de un determinado período
de tiempo, éste regresará al último número de acuse de recibo que recibió y volverá a transmitir los
datos desde dicho punto.
Para una implementación de TCP típica, un host puede transmitir un segmento, colocar una copia
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.

CAPA 4 DEL MODELO OSI – CAPA DE TRANSPORTE

RESUMEN
La capa de transporte es la clave para entender los protocolos en capas. Esta capa proporciona
varios servicios, siendo el más importante un flujo de bytes punto a punto, confiable y orientado a
conexión desde el emisor hasta el receptor. Para acceder a esta capa se utilizan primitivas de
servicio que permiten establecer, usar y liberar conexiones. Una interfaz común de la capa de
transporte es la que proporcionan los sockets de Berkeley.
Los protocolos de transporte deben ser capaces de administrar conexiones a través de redes no
confiables. El establecimiento de las conexiones se complica por la existencia de paquetes
duplicados retardados que pueden reaparecer en momentos inoportunos. Para lidiar con ellos, se
requieren acuerdos de tres vías para establecer las conexiones. Es más fácil liberar una conexión
que establecerla, pero aun así este proceso está lejos de ser trivial debido al problema de los dos
ejércitos.
Incluso cuando la capa de red es completamente confiable, la capa de transporte tiene mucho
trabajo
por hacer. Debe manejar todas las primitivas de servicio, administrar conexiones y temporizadores,
asignar ancho de banda con el control de congestión, y ejecutar una ventana deslizante de tamaño
variable para el control de flujo.
El control de la congestión debe asignar en forma equitativa todo el ancho de banda disponible
entre
los flujos que compiten entre sí; además debe rastrear los cambios en el uso de la red.
Internet tiene dos protocolos de transporte principales: UDP y TCP.
UDP es un protocolo sin conexión que actúa principalmente como una envoltura para los paquetes
IP con la característica adicional de multiplexar y de-multiplexar diversos procesos mediante el uso
de una sola dirección IP. UDP se puede emplear para interacciones cliente-servidor. También se
puede emplear para construir protocolos en tiempo real tales como RTP(Protocolo de Transporte en
Tiempo Real, del inglés Real Transport Control Protocol).
El protocolo de transporte principal de Internet es TCP. Proporciona un flujo de bytes confiable,
bidireccional y controlado por congestión, con un encabezado de 20 bytes en todos los segmentos.
Se ha invertido mucho trabajo en optimizar el desempeño de TCP, mediante algunos algoritmos.
Por lo general, el desempeño de las redes es dominado por la sobrecarga de procesamiento de los
protocolos y los segmentos; y esta situación empeora a mayores velocidades. Los protocolos
deberían diseñarse para reducir al mínimo la cantidad de segmentos y el trabajo para las
trayectorias con un producto ancho de banda-retardo grande. En las redes de gigabits se requieren
protocolos sencillos y un procesamiento modernizado.
Las redes tolerantes al retardo ofrecen un servicio de entrega a través de redes con una
conectividad ocasional o retardos largos entre los enlaces. Los nodos intermedios almacenan,
transportan y reenvían bundles de información para que se entregue en un momento dado, incluso
aunque no haya una trayectoria funcional del emisor al receptor en ningún momento.