Nivel de transporte

El nivel IP no realiza ningún tipo de control de errores. Es el nivel de transporte el que se encarga de que la comunicación entre extremos se realice de forma correcta. El protocolo principal de este nivel es TCP.

De todos modos, hay que mencionar que la división sel trabajo en dos niveles permitía a algunas aplicaciones utilizar el nivel IP directamente. Realmente eso no es del todo cierto ya que existe un inconveniente para ello. Por eso, las aplicaciones que no quieran la fiabilidad de TCP deberá utilizar otro protocolo del nivel de transporte: UDP. Este protocolo es muy sencillo y básicamente sólo añade dos campos a un datagrama IP: puerto de origen y puerto destino.

Los puertos

El término puerto es utilizado para varias cosas en informática por lo que su uso es a veces confuso. De todos modos el contexto suele aclarar a que clase de puerto nos referimos. En el contexto de las redes, y en concreto el del nivel de transporte, un puerto es un valor de 16 bits que se utiliza para identificar procesos que utilizan el nivel de transporte de la arquitectura TCP/IP.

La necesidad de los puertos se puede ver claramente con un ejemplo. Supón una máquina en la que se ejecutan un servidor web y un servidor de correo electrónico. Cada vez que llega un datagrama con información a esa máquina ¿cómo sabe el nivel de transporte a cuál de las dos aplicaciones ha de pasar los datos? Para ello, previamente habrá identificado a cada una de las aplicaciones (mejor dicho, procesos) con un valor de 16 bits: el puerto.

Algo parecido pasa en un ordenador normal. ¿Cuántas veces has navegado mientras leías el correo? Estamos en la misma situación, cuando llega algo de Internet ¿cómo sabe el nivel de transporte de tu máquina si darselo al navegador a o al cliente de correo?

Por lo tanto, cada vez que queremos comunicarnos con una máquina no basta con indicar su dirección IP, también hay que indicar el puerto que identifica al proceso con el que queremos comunicarmos. Y bien, ¿cómo podemos saber el puerto de un proceso?

El problema se reduce normalmente a conocer el puerto de los servidores. ¿Y el de los clientes? Como normalmente son los clientes quienes inician la comunicación con el servidor, en el primer paquete ya le indican cuál es su puerto. El servidor, por lo tanto, cuando ha de responder ya conoce el puerto del cliente. Por ello, los puertos de los clientes los suele asignar dinámicamente el nivel de transporte.

Para conocer el puerto del servidor existen dos aproximaciones. La primera pasa por que el administrador del servidor nos informe del puerto del servidor. Evidentemente esto no es práctico, pero se utiliza para realizar pruebas o con servidores de aplicaciones propias. La segunda aproximación, y la que es realmente práctica, pasa por asignar un puerto a cada aplicación. Para ello, hay una lista de aplicaciones muy usadas con sus respectivos puertos. De esta asignación se encarga la IANA (Internet Assigned Numbers Authority), una entidad operada por la ICANN. La IANA divide la lista en tres tipos de puertos: los puertos bien conocidos (del 0 al 1023), los puertos registrados (del 1024 al 49151) y los privados o dinámicos (a pàrtir de 49152). Los puertos de los dos primeros grupos no se debrían asignar a aplicaciones no registradas por la IANA. El último grupo se puede usar libremente y se utiliza normalmente para asignar puertos a los clientes.

Como ejemplo el servidor web tiene asignado el puerto 80, el de DNS el 53 y el de Telnet el 23. Puedes encontrar la lista completa en la web de la IANA.

TCP

TCP se encarga de aportar fiabilidad a las comunicaciones ofrecidas por el nivel IP. En particular TCP se encarga de las siguientes cuestiones:

  • Control de errores: TCP detecta los posibles errores en la comunicación y los corrige. Los errores que pueden surgir son de dos tipos:
    1. Datagramas eliminados: En Internet puede ocurrir que algunos datagramas no lleguen a su destino. TCP numera todos los paquetes para poder detectar estas pérdidas. Para corregir estas pérdidas TCP utiliza un sistema de retransmisiones de ventanas deslizantes. De este modo, cuando el receptor recibe un paquete responde al emisor con un acuse de recibo (ACK). Si el ACK no llega dentro del plazo estipulado el emisor vuelve a enviar el mismo paquete (retransmisión). Las razones principales de la eliminación de datagramas son los siguientes:
      • Error de transmisión: Hoy en día la mayoría de protocolos a nivel de enlace realizan una detección de errores de transmisión mucho más potente y eficiente del que pueda realizar TCP. Si una trama llega con un error de transmisión lo habitual es que el nivel de enlace lo elimine, de forma que el datagrama que lleva dentro no llega ni a IP, ni por lo tanto a TCP. Por ello, a nivel de transporte un error de transmisión se suele reflejar como un paquete perdido.
      • Congestión: Ya se ha mencionado antes que el punto débil de las comunicaciones en Internet son los encaminadores. Es posible que en ciertos momentos de mucho tráfico algunos encaminadores se vean desbordados y no tengan otro remedio que eliminar algunos datagramas. La inmensa mayoría de pérdida de datagramas en Internet se da por esta razón.
    2. Errores de secuenciamiento; Las tablas de encaminamiento de la red troncal de Internet suelen ser dinámicas y por lo tanto es posible que los paquetes que se intercambian dos máquinas sigan distintos caminos. Este hecho puede provocar que los paquetes lleguen desordenados. Gracias al sistema de numeración de paquetes mencionado TCP puede reordenar los paquetes en su orden original.
  • Control de congestión: Como se acaba de comentar los encaminadores pueden congestionarse provocando la pérdida de datagramas. Esta pérdida provoca la retransmisión de los paquetes perdidos (e incluso la de paquetes llegados a destino, pero cuyos ACKs han sido eliminados en encaminadores congestionados). De este modo, una congestión provoca una respuesta que sobrealimenta la congestión. Por ello, TCP está provisto de un sistema de autocontrol que limita la tasa de emisión cuando detecta una congestión.
  • Control de flujo: En una comunicación en Internet los encaminadores no son los únicos que pueden ver desbordados sus buffers. El extremo final de la comunicación también puede recibir información a mayor velocidad de la que lo consume por lo que TCP se encarga de evitar ese problema. La solución pasa por que cada extremo informe en cada ACK emitido el tamaño de su buffer de entrada (crédito). La otra parte nunca enviará una cantidad mayor que el crédito recibido hasta recibir un nuevo crédito. De este modo se evita la pérdida de datos por desbordamiento de buffer en los extremos. Fíjate que esta solución no es válida para los encaminadores ya que estos no ejecutan TCP.

UDP

Como se decía al principio UDP se utiliza cuando una aplicación prefiere usar el nivel IP directamente sin pasar por la sobrecarga añadida por TCP. Dado que utilizar datagramas IP directamente no permite el uso de puertos para identificar procesos no queda otro remedio que utilizar UDP. Este protocolo básicamente añade los campos de “puerto de origen” y “puerto destino” a un datagrama haciendo posible el uso casi directo del nivel IP.A continuación se enumeran y describen brevemente una serie de tipos de aplicaciones que habitualmente utilizan UDP:

  • Aplicaciones transaccionales: Son aplicaciones donde cliente y servidor alternan mensajes cortos. En este caso el desordenamiento de paquetes no es posible ya que cada mensaje suele ir en un único paquete. La pérdida de información se puede controlar en la propia aplicación reenviando el mensaje si no se ha recibido respuesta en un periodo de tiempo razonable. Una aplicación de este tipo es el DNS.
  • Aplicaciones en tiempo real: Hay ciertas aplicaciones para las cuales el retardo y la velocidad de transmisión son mucho más importantes que la pérdida de algún dato. Este tipo de aplicaciones suelen ser los que trabajan en tiempo real como la telefonía IP, videoconferencias, juegos on-line… Para estos casos es prefereible la agilidad de UDP a pesar de sus posibles errores.
  • Aplicaciones en redes fiables: En determinados entornos la red ya nos da una fiabilidad suficiente por lo que utilizar TCP es innecesario. Para evitar los retardos introducidos por TCP en estos entornos podemos utilizar UDP. Un caso típico es el de una aplicación que solamente se utiliza en una red local donde las pérdidas por errores son mínimas y el desordenamiento de paquetes imposible.

Por otra parte, las aplicaciones que pueden intercambiar ficheros de cierto tamaño y donde la ausencia de errores es más importante que los posibles retardos utilizan TCP. Aplicaciones típicas son la web, el correo electrónico, FTP…

Anuncios

Acerca de mitch

Quiero compartir mis experiencias y mis humildes conocimientos
Esta entrada fue publicada en Nivel de transporte. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s