RESUMEN

TEMA: Protocolos

1.- Introducción

Internet no es un nuevo tipo de red física, sino un conjunto de tecnologías que permiten interconectar redes muy distintas entre sí. Internet no es dependiente de la máquina ni del sistema operativo utilizado. De esta manera, podemos transmitir información entre un servidor Unix y un ordenador que utilice Windows 98. O entre plataformas completamente distintas como Macintosh, Alpha o Intel. Es más: entre una máquina y otra generalmente existirán redes distintas: redes Ethernet, redes Token Ring e incluso enlaces vía satélite. Como vemos, está claro que no podemos utilizar ningún protocolo que dependa de una arquitectura en particular. Lo que estamos buscando es un método de interconexión general que sea válido para cualquier plataforma, sistema operativo y tipo de red. La familia de protocolos que se eligieron para permitir que Internet sea una Red de redes es TCP/IP. Nótese aquí que hablamos de familia de protocolos ya que son muchos los protocolos que la integran, por lo tanto mencionaremos algunos de ellos.

2.- ¿Qué son los Protocolos?

La base de Internet, y razón principal de su éxito, son sus protocolos. Dentro de cada nivel se utilizan distintas normas o protocolos, llegando incluso a depender, dentro de un nivel,  la norma utilizada del servicio a prestar A continuación se ilustran los Protocolos de comunicación por Capas, los mismos que serán descritos más adelante:

                                                                                                                                                                                         Fig. 1

3.- ¿Clasificación?

3.1 Protocolos a Nivel de Transporte

El protocolo de nivel de transporte original era el Network Control Protocol, NCP, diseñado para ARPANET, funcionó hasta que el sucesivo crecimiento con otras redes dio lugar a ARPA Internet y además provocó que se fuera degradando la fiabilidad extremo a extremo de la red, forzando la necesidad de un nuevo protocolo para el nivel de transporte, el Protocolo de Control de transmisión,  TCP, diseñado especialmente para tolerar subredes no fiables. Los servicios como correo electrónico, transferencia de ficheros o acceso remoto, necesitan que los caracteres que se van tecleando en un extremo vayan llegando al otro extremo conservando el orden en que se han introducido, o que el fichero que estamos transfiriendo no pierda o duplique partes del mismo. Necesitamos un protocolo que nos proporcione un flujo de bytes fiable para los dos sentido de la conexión. Nuestro protocolo es el TCP, que nos garantiza que los bytes que salen del nodo origen son entregados en el nodo destino en el mismo orden y sin duplicados es un protocolo orientado a conexión. Cuando lo que se necesita transmitir es voz o vídeo en tiempo real, es más importante transmitir con una alta velocidad que el garantizar que llegan absolutamente todos los paquetes, con el orden adecuado y sin duplicados. En esta situación, nuestras necesidades son mejor satisfechas por el protocolo de nivel de transporte llamado Protocolo de Datagramas de Usuario, UDP, que se caracteriza por ser un protocolo no orientado a conexión, es decir, puede que algunos de los paquetes enviados con este protocolo no lleguen nunca, lo hagan varias veces o lleguen en desorden. Cada paquete lleva suficiente información como para alcanzar el destino, reencaminándose el flujo en el caso de que falle algún nodo o enlace. Entre los inconvenientes, simplemente recordar que no se está a salvo de pérdidas, repeticiones y desordenes de los paquetes, por lo que los procesos que usen este protocolo pueden tener una carga adicional de trabajo.

3.2 Protocolos a Nivel de Interret

A principios de los ochenta se introdujo un nuevo protocolo de nivel de interred, el Protocolo de Internet, IP. Se trata de un protocolo no orientado a conexión, encargado de las cuestiones relativas a direccionamiento de los paquetes que le suministra la capa de transporte. De esta forma, el protocolo que principalmente se identifica con Internet es el Transmission Control Protocol / Internet Protocol,  TCP/IP, si bien la parte fundamental de la estructura, en la que se basan todas las aplicaciones, es la establecida por la norma IP, encargado de determinar los procedimientos de direccionamiento y encaminamiento que deben seguir todas las informaciones transmitidas, independientemente de la red física que se utilice para la conexión. Como cada servicio  tiene sus propias necesidades, existen diferentes protocolos de niveles superiores que usan IP. Aunque el protocolo IP establece las normas para que los paquetes alcancen su destino, lo que no se garantiza es cuándo lo van a alcanzar, cuántos o en qué orden, es decir, ofrece un servicio no orientado a conexión.

3.3 Protocolos a Nivel de red/enlace

En  los protocolos usados en Internet, según nos acercamos al medio físico, la diversidad de los mismos provoca que existan varios protocolos a nivel de red/enlace para adaptarse a las peculiaridades de cada medio físico.

Un usuario conectándose por una línea serie, tenemos la posibilidad de que se trata de una línea de la red telefónica conmutada (RTC) o una línea punto a punto. Ambos casos fueron contemplados, definiéndose sendos estándares para cada uno de ellos. Así, se definió el protocolo de Internet para líneas serie (Serial Line Internet Protocol, SLIP) y el protocolo para líneas punto a punto (Point to Point Protocol, PPP) destinados a implementar la funcionalidad del nivel de red y enlace sobre los citados medios físicos. De estos dos protocolos el primero de ellos, SLIP.

Si bien el protocolo SLIP está específicamente diseñado para el transporte de tráfico TCP/IP, la tendencia actual es hacia el uso cada vez mayor del protocolo PPP, ya que, aunque su nombre pueda despistarnos, también es apto para líneas telefónicas conmutadas, las normales en nuestra casa u oficina, siempre que nuestro proveedor de Internet disponga de un servidor PPP para atender nuestra llamada.

El protocolo PPP posee algunas características que lo hacen más interesante:
 

·         Negociación de la configuración : al utilizar SLIP, es necesario conocer tanto nuestra dirección IP como la de nuestro proveedor, lo que puede causarnos problemas en el caso de que este asigne dinámicamente las direcciones. Igualmente, existe la posibilidad de tener que configurar algunos parámetros un tanto “oscuros”, como pueden ser máxima unidad de transmisión (MTU), máxima unidad de recepción (MRU), el uso de cabeceras de compresión, etc. Algo que puede ser un tanto tedioso, aunque no imposible. Todos estos pasos se simplifican notablemente con el protocolo PPP gracias a mecanismos de negociación  durante la conexión.

·         Login automático : casi todos los programas SLIP/PPP pueden llamar y hacer login de forma automática, siguiendo un fichero de comandos. Sin embargo, es conveniente que el sistema del proveedor de servicio envíe prompts estándar de cara a facilitar el proceso. Por ejemplo, debería enviar un “login :” cuando espere que nuestro sistema la envíe nuestro identificador y “password :” para pedir la clave, algo que no siempre ocurre, teniéndose que recurrir entonces a escribir un fichero de conexión específico (script) o realizarla de forma manual. PPP considera la posibilidad de que se utilicen dos posibles métodos de automatización, el protocolo de autentificación de claves, (Password Authentication Protocol, PAP) y el protocolo de autentificación por Challenge-Handshake, (Challenge-Handshake Authentication Protocol, CHAP). Ambos aportan un mecanismo, para enviar la pareja login/clave de forma transparente al sistema remoto.

·         Capacidad de transporte multiprotocolo: al ser PPP más reciente se le ha dotado de una mayor potencia, aunque a efectos de conectarse a Internet, donde sólo se usa el protocolo TCP/IP no es significativa..

4.- Descripción de Protocolos más comunes:

4.1 Protocolo IP

IP es el principal protocolo de la capa de red. Este protocolo define la unidad básica de transferencia de datos entre el origen y el destino, atravesando toda la red de redes. Además, el software IP es el encargado de elegir la ruta más adecuada por la que los datos serán enviados en paquetes a través de Datagramas IP, los cuales tienen las siguientes características:

·         Es no orientado a conexión debido a que cada uno de los paquetes puede seguir rutas distintas entre el origen y el destino. Entonces pueden llegar duplicados o desordenados.

·         Es no fiable porque los paquetes pueden perderse, dañarse o llegar retrasados.

Nota: El protocolo IP está definido en la RFC 791 (en inglés, en español).

4.2 Protocolo TCP

El protocolo TCP (Transmission Control Protocol, protocolo de control de transmisión) está basado en IP que es no fiable y no orientado a conexión, y sin embargo es:

·         Orientado a conexión. Es necesario establecer una conexión previa entre las dos máquinas antes de poder transmitir ningún dato. A través de esta conexión los datos llegarán siempre a la aplicación destino de forma ordenada y sin duplicados. Finalmente, es necesario cerrar la conexión.

·         Fiable. La información que envía el emisor llega de forma correcta al destino.

El flujo de datos entre una aplicación y otra viajan por un circuito virtual. Sabemos que los datagramas IP pueden seguir rutas distintas, dependiendo del estado de los encaminadores intermedios, para llegar a un mismo sitio. Esto significa que los datagramas IP que transportan los mensajes siguen rutas diferentes aunque el protocolo TCP logré la ilusión de que existe un único circuito por el que viajan todos los bytes uno detrás de otro (algo así como una tubería entre el origen y el destino). Para que esta comunicación pueda ser posible es necesario abrir previamente una conexión. Esta conexión garantiza que los todos los datos lleguen correctamente de forma ordenada y sin duplicados. La unidad de datos del protocolo es el byte, de tal forma que la aplicación origen envía bytes y la aplicación destino recibe estos bytes.

El protocolo TCP envía un flujo de información no estructurado. Esto significa que los datos no tienen ningún formato, son únicamente los bytes que una aplicación envía a otra. Ambas aplicaciones deberán ponerse de acuerdo para comprender la información que se están enviando.

Cada vez que se abre una conexión, se crea un canal de comunicación bidireccional en el que ambas aplicaciones pueden enviar y recibir información, es decir, una conexión es full-dúplex.

4.3 Protocolo ARP

Dentro de una misma red, las máquinas se comunican enviándose tramas físicas. Las tramas Ethernet contienen campos para las direcciones físicas de origen y destino (6 bytes cada una):

                                                                                                                                                                                  Fig. 2

El problema que se nos plantea es cómo podemos conocer la dirección física de la máquina destino. El único dato que se indica en los datagramas es la dirección IP de destino. ¿Cómo se pueden entregar entonces estos datagramas? Necesitamos obtener la dirección física de un ordenador a partir de su dirección IP. Esta es justamente la misión del protocolo ARP (Address Resolution Protocol, protocolo de resolución de direcciones).

Nota: El protocolo ARP está definido en la RFC 826 (en inglés)

                                                                                                                                                      Fig. 3

Vamos a retomar el ejemplo introductorio de este Capítulo. El host A envía un datagrama con origen 192.168.0.10 y destino 10.10.0.7 (B). Como el host B se encuentra en una red distinta al host A, el datagrama tiene que atravesar el router 192.168.0.1 (R1). Se necesita conocer la dirección física de R1.

Es entonces cuando entra en funcionamiento el protocolo ARP: A envía un mensaje ARP a todas las máquinas de su red preguntando "¿Cuál es la dirección física de la máquina con dirección IP 192.168.0.1?". La máquina con dirección 192.168.0.1 (R1) advierte que la pregunta está dirigida a ella y responde a A con su dirección física (00-E0-4C-AB-9A-FF). Entonces A envía una trama física con origen 00-60-52-0B-B7-7D y destino 00-E0-4C-AB-9A-FF conteniendo el datagrama (origen 192.168.0.10 y destino 10.10.0.7). Al otro lado del router R2 se repite de nuevo el proceso para conocer la dirección física de B y entregar finalmente el datagrama a B. El mismo datagrama ha viajado en dos tramas físicas distintas, una para la red 1 y otra para la red 2.

Observemos que las preguntas ARP son de difusión (se envían a todas las máquinas). Estas preguntas llevan además la dirección IP y dirección física de la máquina que pregunta. La respuesta se envía directamente a la máquina que formuló la pregunta.

4.4 Protocolo ICMP

Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol, protocolo de mensajes de control y error) se encarga de informar al origen si se ha producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de notificar los errores, sino que también transporta distintos mensajes de control.

Nota: El protocolo ICMP está definido en la RFC 792 (en inglés, en español)

El protocolo ICMP únicamente informa de incidencias en la red pero no toma ninguna decisión. Esto será responsabilidad de las capas superiores. Los mensajes ICMP viajan en el campo de datos de un datagrama IP, como se puede apreciar en el siguiente esquema:
 

                                                                                                                                                                    Fig. 4

Los mensajes ICMP comienzan con un campo de 8 bits que contiene el tipo de mensaje, según se muestra en la tabla siguiente. El resto de campos son distintos para cada tipo de mensaje ICMP. 

Nota: El formato y significado de cada mensaje ICMP está documentado en la RFC 792 (en inglés, en español). 

4.5 Protocolo UDP

El protocolo UDP (User Datagram Protocol, protocolo de datagrama de usuario) proporciona una comunicación muy sencilla entre las aplicaciones de dos ordenadores. Al igual que el protocolo IP, UDP es:

·         No orientado a conexión. No se establece una conexión previa con el otro extremo para transmitir un mensaje UDP. Los mensajes se envían sin más y éstos pueden duplicarse o llegar desordenados al destino.

·         No fiable. Los mensajes UDP se pueden perder o llegar dañados.

UDP utiliza el protocolo IP para transportar sus mensajes. Como vemos, no añade ninguna mejora en la calidad de la transferencia; aunque sí incorpora los puertos origen y destino en su formato de mensaje. Las aplicaciones (y no el protocolo UDP) deberán programarse teniendo en cuenta que la información puede no llegar de forma correcta.

                                                                                                                                                                                 Fig. 5

·         Puerto UDP de origen (16 bits, opcional). Número de puerto de la máquina origen.

·         Puerto UDP de destino (16 bits). Número de puerto de la máquina destino.

·         Longitud del mensaje UDP (16 bits). Especifica la longitud medida en bytes del mensaje UDP incluyendo la cabecera. La longitud mínima es de 8 bytes.

·         Suma de verificación UDP (16 bits, opcional). Suma de comprobación de errores del mensaje. Para su cálculo se utiliza una pseudo-cabecera que también incluye las direcciones IP origen y destino. Para conocer estos datos, el protocolo UDP debe interactuar con el protocolo IP.

·         Datos. Aquí viajan los datos que se envían las aplicaciones. Los mismos datos que envía la aplicación origen son recibidos por la aplicación destino después de atravesar toda la Red de redes.

[Infografía]     [HWCT]   [Principal]