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.