Está en la página 1de 4

3- La capa de transporte

Entre las capas de aplicación y de red se encuentra la capa de transporte,


una pieza fundamental de la arquitectura de red en capas. Desempeña el
papel crítico de proporcionar directamente servicios de comunicación a
los procesos de aplicación que se ejecutan en hosts diferentes.
Un protocolo de la capa de transporte proporciona una comunicación
lógica entre procesos de aplicación que se ejecutan en hosts diferentes.
Los protocolos de la capa de transporte están implementados en los
sistemas terminales, pero no en los routers de la red.
La capa de transporte se encuentra justo encima de la capa de red
dentro de la pila de protocolos. Mientras que un protocolo de la capa de
transporte proporciona una comunicación lógica entre procesos que se
ejecutan en hosts diferentes, un protocolo de la capa de red proporciona
una comunicación lógica entre hosts. Esta distinción es sutil, pero
importante.
Si el protocolo de la capa de red no proporciona garantías acerca del
retardo ni del ancho de banda para los segmentos de la capa de
transporte enviados entre hosts, entonces el protocolo de la capa de
transporte no puede proporcionar ninguna garantía acerca del retardo o
del ancho de banda a los mensajes de aplicación enviados entre
procesos. No obstante, el protocolo de transporte puede ofrecer ciertos
servicios incluso cuando el protocolo de red subyacente no ofrezca el
servicio correspondiente en la capa de red.
El protocolo de la capa de red de Internet es el protocolo IP (Internet
Protocol). IP proporciona una comunicación lógica entre hosts. El modelo
de servicio de IP es un servicio de entrega de mejor esfuerzo (best
effort). Esto quiere decir que IP hace todo lo que puede por entregar los
segmentos entre los hosts que se están comunicando, pero no garantiza
la entrega. En particular, no garantiza la entrega de los segmentos, no
garantiza que los segmentos se entreguen en orden y no garantiza la
integridad de los datos contenidos en los segmentos. Por estas razones,
se dice que IP es un servicio no fiable. Además, sabemos que todos los
hosts tienen al menos una dirección de capa de red, que se conoce como
dirección IP.
La multiplexación y demultiplexación de la capa de transporte; es decir, la
ampliación del servicio de entrega host a host proporcionado por la capa
de red a un servicio de entrega proceso a proceso para las aplicaciones
que se ejecutan en los hosts.
Esta tarea de entregar los datos contenidos en un segmento de la capa
de transporte al socket correcto es lo que se denomina demultiplexación.
Para crear los segmentos y pasarlos a la capa de red es lo que se
denomina multiplexación.
UDP hace casi lo mínimo que un protocolo de transporte debe hacer.
Además de la función de multiplexación/demultiplexación y de algún
mecanismo de comprobación de errores, no añade nada a IP. De hecho,
si el desarrollador de la aplicación elige UDP en lugar de TCP, entonces
prácticamente es la aplicación la que se comunica directamente con IP.
El campo de datos contiene un mensaje de consulta o un mensaje de
respuesta. En el caso de una aplicación de flujo de audio, las muestras
del audio llenarán el campo de datos. La cabecera UDP sólo tiene cuatro
campos, y cada uno de ellos tiene una longitud de dos bytes. Como se ha
explicado en la sección anterior, los números de puerto permiten al host
de destino pasar los datos de la aplicación al proceso apropiado que está
ejecutándose en el sistema terminal de destino (es decir, realizar la
función de demultiplexación). El host receptor utiliza la suma de
comprobación para detectar si se han introducido errores en el segmento.
En realidad, la suma de comprobación también se calcula para unos
pocos campos de la cabecera IP, además de para el segmento UDP. El
campo longitud especifica la longitud del segmento UDP en bytes,
incluyendo la cabecera.
La suma de comprobación de UDP proporciona un mecanismo de
detección de errores. Es decir, se utiliza para determinar si los bits
contenidos en el segmento UDP han sido alterados según se desplazaban
desde el origen hasta el destino (por ejemplo, a causa de la existencia de
ruido en los enlaces o mientras estaban almacenados en un router). UDP
en el lado del emisor calcula el complemento a 1 de la suma de todas las
palabras de 16 bits del segmento, acarreando cualquier desbordamiento
obtenido durante la operación de suma sobre el bit de menor peso. Este
resultado se almacena en el campo suma de comprobación del segmento
UDP.
Es la responsabilidad de un protocolo de transferencia de datos fiable
implementar esta abstracción del servicio. Esta tarea es complicada por el
hecho de que la capa que hay por debajo del protocolo de transferencia
de datos puede ser no fiable. Por ejemplo, TCP es un protocolo de
transferencia de datos fiable que se implementa encima de una capa de
red terminal a terminal no fiable (IP).
Es un protocolo funcionalmente correcto, pero es muy improbable que
haya alguien a quien satisfaga su rendimiento, especialmente en las
redes de alta velocidad actuales. La base del problema del rendimiento de
rdt3.0 se encuentra en el hecho de que es un protocolo de parada y
espera.
El retardo de propagación de ida y vuelta, RTT, a la velocidad de la luz
entre estos dos sistemas terminales es aproximadamente igual a 30
milisegundos. Suponga que están conectados mediante un canal cuya
velocidad de transmisión, R, es de 1 Gbps (109 bits por segundo). Con un
tamaño de paquete, L, de 1.000 bytes (8.000 bits) por paquete.
TCP, un protocolo de la capa de transporte de Internet, fiable y orientado
a la conexión. para proporcionar una transferencia de datos fiable, TCP
confía en muchos de los principios básico incluyendo los mecanismos de
detección de errores, las retransmisiones, los reconocimientos
acumulativos, los temporizadores y los campos de cabecera para los
números de secuencia y de reconocimiento.
Una conexión TCP proporciona un servicio full-duplex: si existe una
conexión TCP entre el proceso A que se ejecuta en un host y el proceso B
que se ejecuta en otro host, entonces los datos de la capa de aplicación
pueden fluir desde el proceso A al proceso B en el mismo instante que los
datos de la capa de aplicación fluyen del proceso B al proceso A.
Una conexión TCP casi siempre es una conexión punto a punto, es decir,
entre un único emisor y un único receptor.
La cantidad máxima de datos que pueden cogerse y colocarse en un
segmento está limitada por el tamaño máximo de segmento (MSS,
Maximum Segment Size). Normalmente, el MSS queda determinado en
primer lugar por la longitud de la trama más larga de la capa de enlace
que el host emisor local puede enviar [que es la unidad máxima de
transmisión, (MTU, Maximum Transmission Unit)], y luego el MSS se
establece de manera que se garantice que un segmento TCP (cuando se
encapsula en un datagrama IP) se ajuste a una única trama de la capa de
enlace.
El segmento TCP consta de campos de cabecera y un campo de datos. El
campo de datos contiene un fragmento de los datos de la aplicación.
Como hemos mencionado anteriormente, el MSS limita el tamaño máximo
del campo de datos de un segmento. Cuando TCP envía un archivo
grande, como por ejemplo una imagen como parte de una página web,
normalmente divide el archivo en fragmentos de tamaño MSS (excepto el
último fragmento, que normalmente será más pequeño que MSS). Sin
embargo, las aplicaciones interactivas suelen transmitir fragmentos de
datos que son más pequeños que el MSS.
la cabecera incluye los número de puerto de origen y de destino, que se
utilizan para multiplexar y demultiplexar los datos de y para las
aplicaciones de la capa superior. También, al igual que UDP, la cabecera
incluye un campo de suma de comprobación.
TCP, utiliza un mecanismo de fin de temporización/retransmisión para
recuperarse de la pérdida de segmentos. Evidentemente, el intervalo de
fin de temporización debería ser mayor que el tiempo de ida y vuelta
(RTT) de la conexión; es decir, mayor que el tiempo que transcurre desde
que se envía un segmento hasta que se recibe su reconocimiento.
Cómo estima TCP el tiempo de ida y vuelta entre el emisor y el receptor.
Esto se lleva a cabo de la siguiente manera: el RTT de muestra,
expresado como RTTMuestra, para un segmento es la cantidad de tiempo
que transcurre desde que se envía el segmento (es decir, se pasa a IP)
hasta que se recibe el correspondiente paquete de reconocimiento del
segmento.
TCP crea un servicio de transferencia de datos fiable sobre el servicio de
mejor esfuerzo pero no fiable de IP. El servicio de transferencia de datos
fiable de TCP garantiza que el flujo de datos que un proceso extrae de su
buffer de recepción TCP no está corrompido, no contiene huecos, ni
duplicados y está en orden; es decir, el flujo de bytes es exactamente el
mismo flujo que fue enviado por el sistema terminal existente en el otro
extremo de la conexión.
TCP proporciona un servicio de control de flujo a sus aplicaciones para
eliminar la posibilidad de que el emisor desborde el buffer del receptor. El
control de flujo es por tanto un servicio de adaptación de velocidades.
En el mecanismo de control de congestión asistido por la red, la
información acerca de la congestión suele ser realimentada de la red al
emisor de una de dos formas. La realimentación directa puede hacerse
desde un router de la red al emisor. Esta forma de notificación,
normalmente, toma la forma de un paquete de asfixia o bloqueo (choke
packet). La segunda forma de notificación tiene lugar cuando un router
marca/actualiza un campo de un paquete que se transmite del emisor al
receptor para indicar que existe congestión. Después de recibir un
paquete marcado, el receptor notifica al emisor la existencia de
congestión.
ATM emplea para la conmutación de paquetes una técnica basada en
circuitos virtuales que esto significa que cada dispositivo de conmutación
a lo largo de la ruta mantiene el estado del circuito virtual existente entre
el origen y el destino.
La información del estado de cada VC conservada en los conmutadores
de la red hace que las redes ATM estén idealmente adaptadas para
realizar un control de congestión asistido por la red.
ABR ha sido diseñado como un servicio de transferencia de datos elástico
de una forma que recuerda a TCP. Cuando la red está poco cargada, el
servicio ABR debería poder aprovecharse del ancho de banda de reserva
disponible; si la red está congestionada, el servicio ABR debería reducir
su velocidad de transmisión a un valor mínimo predeterminado.
El mecanismo de control de congestión del servicio ABR de ATM es un
método basado en la velocidad. Es decir, el emisor calcula de forma
explícita una velocidad máxima a la que puede transmitir y se autorregula
de acuerdo con ello. ABR proporciona tres mecanismos para señalizar la
información relativa a la congestión transmitida desde los dispositivos de
conmutación al receptor.
Un emisor ABR de una red ATM ajusta la velocidad a la que puede enviar
las celdas en función de los valores de CI, NI y ER contenidos en las
celdas RM devueltas. Las reglas para llevar a cabo este ajuste de
velocidad son bastante complejas y algo tediosas.
TCP tiene que utilizar un control de congestión terminal a terminal en
lugar de un control de congestión asistido por la red, ya que la capa IP no
proporciona una realimentación explícita a los sistemas terminales en lo
tocante a la congestión de la red.
El método empleado por TCP consiste en que cada emisor limite la
velocidad a la que transmite el tráfico a través de su conexión en función
de la congestión de red percibida. Si un emisor TCP percibe que en la
ruta entre él mismo y el destino apenas existe congestión, entonces
incrementará su velocidad de transmisión; por el contario, si el emisor
percibe que existe congestión a lo largo de la ruta, entonces reducirá su
velocidad de transmisión.

También podría gustarte