Arquitecturas y Protocolos Clave en Aplicaciones de Red

Arquitectura de las aplicaciones para redes

Las aplicaciones son la razón de ser de la telemática, por ello se diseñan protocolos de redes de computadoras que las apoyen. Mientras que en las telecomunicaciones las redes telefónicas están diseñadas para que los usuarios se puedan comunicar cómodamente a través de largas distancias, en la telemática las redes de computadoras están construidas para que los usuarios utilicen aplicaciones que se comunican datos e información entre sí a través de largas distancias.

Las aplicaciones de la telemática son esencialmente software. Es importante recordar que en el capítulo previo se mencionó que el software de las aplicaciones de la Internet está distribuido entre los sistemas terminales o hosts, al conjunto de éstas se les llama sistema distribuido.

La forma en la que se distribuye el software determina la arquitectura y las características de las aplicaciones para redes de computadoras o sistema distribuido. Por ejemplo, en la arquitectura cliente/servidor siempre hay un host encendido, llamado servidor, en el cual hay una aplicación que recibe las solicitudes de servicios por parte de las aplicaciones clientes, las cuales están alojadas en otros hosts. A diferencia del servidor, los clientes no siempre deben estar encendidos.

Tal vez el lector podría considerar que es una cuestión trivial llamar cliente o servidor a un host o al software, sin embargo, en el presente documento se tendrá en cuenta el criterio de Kurose [Kurose 2005], donde llaman cliente al host que aloja a la aplicación cliente, y servidor al host donde se ejecuta la aplicación servidor.

Las primeras aplicaciones de la Internet tienen la arquitectura cliente/servidor, por ejemplo, en la WWW, el navegador Web es una aplicación cliente que solicita objetos a un servidor Web, tales objetos son páginas HTML usualmente, y dicho servidor Web es la aplicación servidor. En este ejemplo, las aplicaciones clientes podrían ser Mozilla Firefox, Microsoft Internet Explorer, IceWeasel y Google Chrome; en cuanto a las aplicaciones servidor, hay disponible Microsoft Information Server, Apache y Jakarta Tomcat.

De todas las primeras aplicaciones de la Internet, la WWW es la que más impacto ha tenido hasta hoy, lo cual se puede apreciar porque todas las organizaciones quieren tener sus aplicativos, recursos y servicios disponibles a través de sitios Web. Además, la mayoría de las personas lo primero que hacen al sentarse frente a un sistema terminal de la Internet es ejecutar un navegador Web. Incluso los usuarios de esta red de computadoras confunden a la misma con la WWW, la cual es uno de sus servicios como se mencionó el capítulo previo.

En cuanto a las arquitecturas que hacen parte del estado del arte de las aplicaciones para redes de computadoras se encuentra la p2p (peer – to – peer o igual – a – igual), el Cluster Computer (grupo de computadoras o también conocida como granja de computadoras) y la malla de computadoras (o Grid Computing).

En las aplicaciones p2p los sistemas terminales no asumen los roles de clientes y servidores de manera excluyente, todo lo contrario, asumen ambos simultáneamente. Por lo tanto, cada uno de estos hosts son iguales entre sí, de allí el nombre de la arquitectura (igual – a – igual o p2p), la cual no debe confundirse con el del protocolo PPP (o protocolo punto – a – punto).

Clúster Computing es una arquitectura de sistemas distribuidos apropiada para ejecutar aplicaciones de alto rendimiento, y provisión de servicios de administración y almacenamiento de datos. No solo es un sistema distribuido, también es un sistema de computación en paralelo que consiste de una colección de computadoras conectadas a través de una red, que son utilizadas como un recurso de cómputo unificado e individual [Jia 2005].

Así, los desafíos propios de los sistemas distribuidos superados con el Cluster Computing son [Jia 2005]:

• Tolerancia a fallos: El cual es implementada mediante técnicas de replicación.
• Alta disponibilidad: Este es implementada con mecanismos de cómputo en paralelo (paralelismo).
• Escalabilidad: Dicho obstáculo es superado mediante técnicas de balanceo de carga.
• Consistencia de los datos, en caso de que proporcione servicios de administración y almacenamiento de datos: Este reto es superado mediante el uso de bitácoras y la implementación de una imagen única del sistema (Single System Image o SSI).

Es por esto que los Clúster de servidores son utilizados en organizaciones para superar los desafíos previamente mencionados. Por ejemplo, para el caso de sitios de comercio electrónico basados en Clúster de servidores Web, si uno de estos deja de funcionar, otro tomará su lugar, y si éste falla también, otro tomará su lugar, y así sucesivamente.

De otra parte, el paralelismo de un Clúster de servidores incrementa el rendimiento en la atención a los clientes, porque las tareas inherentes a sus solicitudes pueden ser resueltas por varios de los servidores que componen el Clúster.

Conforme las organizaciones comenzaron a utilizar sistemas de Cluster distribuidos para el soporte de aplicaciones a gran escala en sus investigaciones, surge el paradigma de computación en malla con el objeto de aglomerar estos sistemas usualmente aislados, de tal manera, que puedan ser utilizados como recursos de cómputo único, similar a una malla eléctrica, que es para el usuario un recurso único al cual conecta sus electrodomésticos para hacer uso del servicio de corriente eléctrica.

La computación en malla, concepto inicialmente enunciado por Ian Foster y Carl Kesselman en 1998 [Maozhen 2005], es uno de los desarrollos recientes y el más impactante y prometedor de los sistemas distribuidos en redes de área extensa [Borja 2006, Jia 2005, Maozhen 2005, Prodan 2007]. Antes de la aparición de esta tecnología, el sistema distribuido utilizado para cómputo de alto desempeño era el Cluster Computing, no obstante, éste también es un desarrollo reciente en aplicaciones de redes de computadoras.

Concerniente a las aplicaciones para redes, el principal problema a resolver con la computación en malla consiste en compartir recursos en redes de área extensa, estableciendo organizaciones virtuales, y estas últimas a su vez permiten la colaboración multi – disciplinaria y multi – institucional. De allí, que los participantes en las organizaciones virtuales pueden compartir sus recursos para completar metas comunes. Para este fin, la malla emplea la capacidad de cómputo de recursos heterogéneos tales como Clusters de computadoras, supercomputadoras o los procesadores inactivos de las estaciones de trabajo de un departamento en una organización. Además, emplea la capacidad de almacenamiento de los recursos previamente mencionados.

Las diferencias entre las arquitecturas de aplicaciones distribuidas en Clúster y en malla son:

• Un Clúster requiere un SSI mientras que una malla no, aunque se le podría implementar esta última.
• El énfasis en el Clúster Computing es el procesamiento en paralelo, mientras que la computación en malla se enfoca en compartir recursos.
• Normalmente, las computadoras de un Clúster tienen una arquitectura homogénea en hardware y software, pero en una malla de computadoras, éstas y otros recursos son de arquitectura heterogénea.
• Por último, un Clúster de computadoras se distribuye en redes de área local, mientras que una malla se distribuye en redes de área extensa.

Otro aspecto importante en la computación en malla es que las funciones básicas y necesarias para que las aplicaciones se puedan ejecutar en ésta son:

• Descubrimiento de recursos.
• Medición y contabilidad.
• Compartir datos.
• Administración de recursos.
• Seguridad.
• Confiabilidad y disponibilidad.
• Organizaciones virtuales.
• Monitoreo.
• Implementación y ejecución de políticas.

Adicionalmente, es importante mencionar una variante de la computación en malla, conocida como malla de datos (data grid), que gestiona el acceso a recursos de datos distribuidos en bases de datos, bodegas de datos o servidores de archivos como una serie de archivos.

Finalmente, de todo esto se colige que una malla de computadora es un sistema distribuido y paralelo que sirve como infraestructura de cómputo de alto desempeño, aún más potente que un Cluster de computadoras, porque permite el acceso a recursos disponibles en una red de área extensa como la Internet.

Comunicación de procesos

En la jerga de los sistemas operativos, un programa de computadoras, o una aplicación en ejecución es denominado proceso.

Los sistemas operativos proporcionan los mecanismos de comunicación entre los procesos de una computadora, pero en la telemática lo concerniente es la comunicación de procesos alojados en diferentes computadoras (o hosts) conectadas por una red, incluso cuando tienen instalados diversos sistemas operativos.

Los procesos distribuidos por los hosts conectados a través de una red de computadoras se comunican intercambiando mensajes. De allí, que el mensaje es la PDU de la capa de aplicación. Además, es importante mencionar que a todo esto visto en su totalidad se le llama sistema distribuido según Coulouris, quien lo define como “aquel en el que los componentes localizados en computadoras (procesos) conectadas en red, se comunican y coordinan sus acciones únicamente mediante el paso de mensajes” [Coulouris 2001].

Por lo general, el sistema operativo proporciona una interfaz de programación para construir aplicaciones para redes de computadoras, de tal forma, que los procesos invocan primitivas del sistema operativo que abstraen el concepto de conectores (o sockets), los cuales se enchufan a la red para proporcionar un servicio o hacer uso de uno, de la misma forma en la que una persona conecta un dispositivo electrónico a la red eléctrica.

Lo anterior condujo a que tradicionalmente las aplicaciones para redes de computadoras se escribieran en el lenguaje de programación C, dada su estrecha relación con los sistemas operativos. Sin embargo, éste ciñe las aplicaciones a la interfaz de programación del sistema. Por ejemplo, si este último es Microsoft Windows, la interfaz es WinSock [Chapman 1998], pero si el sistema operativo es un Unix FreeBSD, la interfaz son los sockets de Berkeley [FreeBSD 2009, Chapman 1998].

Adicionalmente, no hubo un esfuerzo o trabajo para estandarizar una biblioteca que permitiera el uso de sockets en diversos sistemas operativos sin tener que hacer modificaciones al código fuente, a diferencia de otras bibliotecas como las de funciones matemáticas, o la de gestión y cómputo de ficheros, las cuales sí fueron estandarizadas.

Debido a ésto un lenguaje de programación como Java, en el que el interés de sus creadores fue construir un lenguaje similar a C, pero con características incorporadas en el mismo que lo hicieran idóneo para la escritura de programas que se comunicaran a través de redes de computadoras, e independiente de los sistemas operativos subyacentes mas sus características de seguridad, ha popularizado y gestado una pléyade de aplicaciones en el campo de la telemática. Aun así muchas están escritas en C, pero el número de expertos y aplicaciones en el área se ha incrementado debido a que Java disminuyó la curva de aprendizaje en la construcción de aplicaciones para redes de computadoras [Caicedo 2007, Knudsen 2005, Elliotte 2004].

Teniendo en cuenta los argumentos previamente expresados, en la presente obra los ejemplos de aplicaciones para redes de computadoras se escriben en el lenguaje de programación Java, y los relativos a la comunicación entre procesos se explican empleando la biblioteca de clases del mismo lenguaje.

Para empezar, se mostrará la forma en la que se construye un servidor y un cliente en la cima del protocolo TCP, el cual es orientado a conexión. Luego, la forma en la que se construye un servidor y un cliente en la cima del protocolo UDP, el cual no es orientado a conexión.

La figura 2.4 muestra el código fuente de un proceso servidor basado en el protocolo de transporte UDP, el cual recibe un mensaje con un paquete que contiene un número entero y una cadena de texto proveniente de un proceso cliente, y lo muestra en pantalla.

Tal vez el lector podría considerar que es una cuestión trivial llamar cliente o servidor a un host o al software, sin embargo, en el presente documento se tendrá en cuenta el criterio de Kurose [Kurose 2005], donde llaman cliente al host que aloja a la aplicación cliente, y servidor al host donde se ejecuta la aplicación servidor.

Las primeras aplicaciones de la Internet tienen la arquitectura cliente/servidor, por ejemplo, en la WWW, el navegador Web es una aplicación cliente que solicita objetos a un servidor Web, tales objetos son páginas HTML usualmente, y dicho servidor Web es la aplicación servidor. En este ejemplo, las aplicaciones clientes podrían ser Mozilla Firefox, Microsoft Internet Explorer, IceWeasel y Google Chrome; en cuanto a las aplicaciones servidor, hay disponible Microsoft Information Server, Apache y Jakarta Tomcat.

De todas las primeras aplicaciones de la Internet, la WWW es la que más impacto ha tenido hasta hoy, lo cual se puede apreciar porque todas las organizaciones quieren tener sus aplicativos, recursos y servicios disponibles a través de sitios Web. Además, la mayoría de las personas lo primero que hacen al sentarse frente a un sistema terminal de la Internet es ejecutar un navegador Web. Incluso los usuarios de esta red de computadoras confunden a la misma con la WWW, la cual es uno de sus servicios como se mencionó el capítulo previo.

En cuanto a las arquitecturas que hacen parte del estado del arte de las aplicaciones para redes de computadoras se encuentra la p2p (peer – to – peer o igual – a – igual), el Cluster Computer (grupo de computadoras o también conocida como granja de computadoras) y la malla de computadoras (o Grid Computing).

En las aplicaciones p2p los sistemas terminales no asumen los roles de clientes y servidores de manera excluyente, todo lo contrario, asumen ambos simultáneamente. Por lo tanto, cada uno de estos hosts son iguales entre sí, de allí el nombre de la arquitectura (igual – a – igual o p2p), la cual no debe confundirse con el del protocolo PPP (o protocolo punto – a – punto).

Cluster Computing es una arquitectura de sistemas distribuidos apropiada para ejecutar aplicaciones de alto rendimiento, y provisión de servicios de administración y almacenamiento de datos. No solo es un sistema distribuido, también es un sistema de computación en paralelo que consiste de una colección de computadoras conectadas a través de una red, que son utilizadas como un recurso de cómputo unificado e individual [Jia 2005].

Así, los desafíos propios de los sistemas distribuidos superados con el Cluster Computing son [Jia 2005]:

• Tolerancia a fallos: El cual es implementada mediante técnicas de replicación.
• Alta disponibilidad: Este es implementada con mecanismos de cómputo en paralelo (paralelismo).
• Escalabilidad: Dicho obstáculo es superado mediante técnicas de balanceo de carga.
• Consistencia de los datos, en caso de que proporcione servicios de administración y almacenamiento de datos: Este reto es superado mediante el uso de bitácoras y la implementación de una imagen única del sistema (Single System Image o SSI).

Es por esto que los Clúster de servidores son utilizados en organizaciones para superar los desafíos previamente mencionados. Por ejemplo, para el caso de sitios de comercio electrónico basados en Clúster de servidores Web, si uno de estos deja de funcionar, otro tomará su lugar, y si éste falla también, otro tomará su lugar, y así sucesivamente.

De otra parte, el paralelismo de un Clúster de servidores incrementa el rendimiento en la atención a los clientes, porque las tareas inherentes a sus solicitudes pueden ser resueltas por varios de los servidores que componen el Clúster.

Conforme las organizaciones comenzaron a utilizar sistemas de Cluster distribuidos para el soporte de aplicaciones a gran escala en sus investigaciones, surge el paradigma de computación en malla con el objeto de aglomerar estos sistemas usualmente aislados, de tal manera, que puedan ser utilizados como recursos de cómputo único, similar a una malla eléctrica, que es para el usuario un recurso único al cual conecta sus electrodomésticos para hacer uso del servicio de corriente eléctrica.

La computación en malla, concepto inicialmente enunciado por Ian Foster y Carl Kesselman en 1998 [Maozhen 2005], es uno de los desarrollos recientes y el más impactante y prometedor de los sistemas distribuidos en redes de área extensa [Borja 2006, Jia 2005, Maozhen 2005, Prodan 2007]. Antes de la aparición de esta tecnología, el sistema distribuido utilizado para cómputo de alto desempeño era el Cluster Computing, no obstante, éste también es un desarrollo reciente en aplicaciones de redes de computadoras.

Concerniente a las aplicaciones para redes, el principal problema a resolver con la computación en malla consiste en compartir recursos en redes de área extensa, estableciendo organizaciones virtuales, y estas últimas a su vez permiten la colaboración multi – disciplinaria y multi – institucional. De allí, que los participantes en las organizaciones virtuales pueden compartir sus recursos para completar metas comunes. Para este fin, la malla emplea la capacidad de cómputo de recursos heterogéneos tales como Clusters de computadoras, supercomputadoras o los procesadores inactivos de las estaciones de trabajo de un departamento en una organización. Además, emplea la capacidad de almacenamiento de los recursos previamente mencionados.

Las diferencias entre las arquitecturas de aplicaciones distribuidas en Cluster y en malla son:

• Un Clúster requiere un SSI mientras que una malla no, aunque se le podría implementar esta última.
• El énfasis en el Clúster Computing es el procesamiento en paralelo, mientras que la computación en malla se enfoca en compartir recursos.
• Normalmente, las computadoras de un Clúster tienen una arquitectura homogénea en hardware y software, pero en una malla de computadoras, éstas y otros recursos son de arquitectura heterogénea.
• Por último, un Clúster de computadoras se distribuye en redes de área local, mientras que una malla se distribuye en redes de área extensa.

Otro aspecto importante en la computación en malla es que las funciones básicas y necesarias para que las aplicaciones se puedan ejecutar en ésta son:

• Descubrimiento de recursos.
• Medición y contabilidad.
• Compartir datos.
• Administración de recursos.
• Seguridad.
• Confiabilidad y disponibilidad.
• Organizaciones virtuales.
• Monitoreo.
• Implementación y ejecución de políticas.

Adicionalmente, es importante mencionar una variante de la computación en malla, conocida como malla de datos (data grid), que gestiona el acceso a recursos de datos distribuidos en bases de datos, bodegas de datos o servidores de archivos como una serie de archivos.

Finalmente, de todo esto se colige que una malla de computadora es un sistema distribuido y paralelo que sirve como infraestructura de cómputo de alto desempeño, aún más potente que un Cluster de computadoras, porque permite el acceso a recursos disponibles en una red de área extensa como la Internet.

Transferencia de ficheros (FTP)

Como se mencionó en el primer capítulo, la telemática aborda el problema de transmitir a larga distancia información computarizada. Particularmente, los usuarios de la informática usualmente necesitan transferir ficheros de un lugar a otro en el sistema de ficheros de una computadora, y también necesitan transferir ficheros entre los sistemas de ficheros de diversas computadoras. Por ejemplo, sería deseable para un estudiante acceder desde su computadora localizada en su casa, a un fichero almacenado en una computadora remota, es decir, en la universidad en la que estudia, ya que dicho fichero contiene la descripción de un curso que desea tomar.

Por esta razón en la Internet se implementó un protocolo para la capa de aplicación llamado FTP (File Transfer Protocol o Protocolo de Transferencia de Ficheros), el cual se establece en la cima del protocolo de la capa de transporte TCP y está especificado en el RFC 959 [Rfc 959].

En una sesión FTP se establece entre el cliente y el servidor dos conexiones, una para la transmisión de información de control y otra para la transferencia de datos.

La conexión de control se utiliza para la transmisión de información como la identidad de un usuario, su contraseña e instrucciones para la modificación de directorios remotos o para la descarga y subida de ficheros. De otra parte, la conexión de datos es utilizada para la transmisión de un fichero.

Cuando se inicia una sesión FTP con un host remoto, la aplicación cliente establece una conexión de control en la cima TCP con la aplicación servidor identificada (según el estándar [Rfc 959]) con el puerto 21. Después, sobre esta conexión el proceso cliente envía la identificación y contraseña del usuario.

Luego, el usuario puede enviar, a través de la aplicación cliente, instrucciones como la solicitud de un fichero, en cuyo evento el servidor inicia una conexión de datos sobre TCP, en el puerto 20, para enviar el fichero a la aplicación cliente. Una vez termine de enviarlo, la conexión de datos se cierra, y si el usuario en la misma sesión (o bien, con la misma conexión de control) solicita otro, se vuelve a establecer la conexión de datos.

En [Kurose 2005, Rfc 959] se presenta un examen completo del protocolo FTP.

Correo electrónico sobre la Internet

El servicio de correo electrónico de la Internet se basa en varios protocolos a saber: SMTP (Simple Mail Transfer Protocol o Protocolo Simple para la Transferencia de Correo) para el envío y transmisión de mensajes de correo electrónico; y POP3 (Post Office Protocol version 3 o Protocolo de Oficina de Correo) e IMAP (Internet Mail Access Protocol o Protocolo de acceso al Correo de la Internet) para acceder mensajes de correo electrónico.

SMTP es definido en el RFC 2821 [Rfc 2821]. Es el principal protocolo de la mensajería en la Internet, es más antiguo que HTTP, y por esta razón tiene problemas de seguridad inherentes. Es representativo de la evolución que ha tenido la red de redes o Internet. A diferencia del protocolo HTTP, éste admite servicios push, lo que significa que un servidor puede enviar información a otro host sin que este último lo haya solicitado previamente. El modelo tradicional se conoce como pull, donde hay la solicitud de un servicio por parte de un cliente, antes que la aplicación servidor lo proporcione.

Servidor:   220 dominioficticio.com ESMTP Postfix
Cliente:    helo otrodominioficticio.com
Servidor:   250 dominioficticio.com
Cliente:    mail from: <[email protected]>
Servidor:   250 2.1.0 Ok
Cliente:    rcpt to: <[email protected]>
Servidor:   250 2.1.5 Ok
Cliente:    data
Servidor:   354 End data with <CR><LF>.<CR><LF>
Cliente:    subject: Te invito a comer
Cliente:    Después de la clase del profesor Caicedo, que está muy
Cliente:    interesante, nos vamos a comer
Cliente:    .
Servidor:   250 2.0.0 Ok: queued as 9821D14AC001
Cliente:    quit
Servidor:   221 2.0.0 Bye

En la figura 2.8 se aprecia una sesión SMTP para el envío de un mensaje de correo electrónico. En esta se envía un mensaje de correo a [email protected] en nombre de [email protected]. El puerto que identifica al servidor SMTP es el 25 y se ejecuta en la cima de TCP.

Cuando se inicia la sesión, el servidor SMTP le envía al cliente un mensaje con el código 220 más una frase de presentación, que según el ejemplo podría interpretarse como: Hola, mi dominio es dominioficticio.com y soy una aplicación servidor de mensajería llamado Postfix.

Postfix y Sendmail son las aplicaciones servidoras de correo utilizadas en el mundo del software libre, y en el mundo comercial Microsoft Exchange es un ejemplar.

Luego de presentarse la aplicación servidora, la aplicación cliente se presenta también con la instrucción helo seguido por el nombre de su dominio, a lo cual el proceso servidor le responde con un mensaje de reconocimiento, identificado con el código 250 y seguido del nombre de su dominio.

Después, con la instrucción mail from el proceso cliente le indica al proceso servidor cual es el emisor del mensaje, y con la instrucción rcpt to le indica cual es el receptor.

Finalmente, la aplicación cliente le envía al proceso servidor la instrucción data para indicarle que a continuación le enviará el cuerpo del mensaje, y éste se indica el asunto del mismo. El mensaje concluye con un punto entre el juego de caracteres cr lf, y la sesión concluye con la instrucción quit.

Por otro lado, POP3 e IMAP están definidos en los RFCs 1939 [Rfc 1939] y 2060 [Rfc 2060] respectivamente.

POP3 es un protocolo de acceso a mensajes de correo electrónico muy fácil de aprender, pero también es limitado. POP3 utiliza TCP como protocolo de transporte subyacente y el servidor se identifica con el puerto 110.

A diferencia de SMTP, POP3 incluye una fase de autenticación, lo cual lo hace más seguro que el primero. Sin embargo, la fase de autenticación no incluye el cifrado del nombre de usuario y contraseña, lo cual también lo hace inseguro ante un analizador de protocolos. Este protocolo también incluye una fase de transacción y una de actualización.

La fase de transacción involucra la obtención de mensajes, la marca de éstos para borrado y la eliminación de marcas.

La última fase consiste en la finalización de la sesión con la instrucción quit (al igual que con SMTP), y cuando esto sucede, el servidor elimina los mensajes que fueron marcados para tal fin.

En cuanto al protocolo IMAP, este está basado en TCP, es más complejo que POP3 y también tiene más prestaciones que este último. Por ejemplo, permite la administración de directorios remotos con mensajes de correo electrónico, lo cual lo hace más agradable para los usuarios que acceden a sus mensajes de correo desde diversas computadoras. Una descripción completa de IMAP se encuentra en el sitio Web de dicho protocolo[Imap 2009].

Por último, en la figura 2.9 se muestra un panorama completo del funcionamiento del servicio de mensajería de la Internet, donde un usuario envía a través de un cliente SMTP un mensaje de correo electrónico a un servidor SMTP, y este último lo reenvía mediante el mecanismo de push a otro servidor. En última instancia, un el usuario al que le enviaron el mensaje lo puede acceder utilizando una aplicación cliente basada en el protocolo POP3 o el IMAP, el cual se conecta al último servidor que recibió el mensaje SMTP.

El servicio de directorio de la Internet (DNS)

En las redes de computadoras basadas en el paquete de protocolos TCP/IP, y particularmente en la Internet, los hosts se identifican por una dirección IP (Internet Protocol), la cual está compuesta por cuatro octetos de bits, o bien, cuatro bytes.

En la práctica, los usuarios manipulan cada octeto (o byte) en formato decimal, de tal manera que manejan cuatro números que oscilan entre cero y doscientos cincuenta y cinco (0 y 255).

En el cuarto capítulo se abordará este tema en mayor profundidad, pero en lo que concierne a DNS (Domain Name System o Sistema de Nombres de Dominios), este protocolo proporciona un servicio que permite a los usuarios identificar a los hosts por un nombre y no por un número como la dirección IP.

El servicio de DNS se implementa en la cima de UDP, y es prestado por un servidor con una base de datos no relacional identificado con el puerto 53. Usualmente el tipo de aplicación servidor que se utiliza es el Berkeley Internet Name Domain (BIND) que funciona en máquinas UNIX y Linux [Bind 2009].

Los procesos servidores DNS de la Internet proporcionan una base de datos distribuida, de tal manera, que el protocolo en sí mismo hace uso de un gran número de aplicaciones servidoras para contestar a la consulta de una aplicación cliente. Una consulta consiste en solicitar la traducción de un nombre a una dirección IP, permitiéndose a los usuarios utilizar nombres, en vez de direcciones IP, y a las computadoras utilizar éstas últimas.

En el mejor de los casos, si el nombre que pasa la aplicación cliente en la solicitud tiene una dirección IP equivalente, entonces la aplicación servidora le responde indicándole cual es tal dirección. En caso contrario, la consulta se extiende a otros procesos servidores hasta responder al proceso cliente con la dirección IP correspondiente al nombre incluido en la consulta, o le indica que no hay una dirección asociada a tal nombre.

La razón para que DNS funcione así radica en que sería inverosímil que un solo proceso servidor tuviera una base de datos con todas los nombres y sus respectivas direcciones IP asociadas. En otras palabras, el problema que se desea resolver es de escalibilidad, que es una característica de las aplicaciones y otros sistemas de cómputo de admitir la inclusión de más usuarios y servicios, en este caso más servidores con sus nombres propios.

En vez de tener una base de datos con todos los nombres, DNS se podría considerar como un protocolo que permite consultar una base de datos distribuida de manera jerárquica, donde hay tres clase de servidores DNS:

• Servidores DNS raíces: En la Internet hay 13 Clusters de servidores DNS de este tipo, etiquetados de la A hasta la M.
• Servidores DNS de alto nivel: Este tipo de servidores son los que almacenan dominios de alto nivel como com, org, net, edu y gov, y de todos los países, como co, uk, fr, ca y jp.
• Servidores DNS autorizados: Los servidores DNS autorizados son instalados en todas las organizaciones que tienen sus redes de computadoras conectadas con la Internet.

Una descripción completa del protocolo DNS se encuentra en los RFCs 1934 y 1935 [Rfc 1934, Rfc 1935].

Redes P2P

Las redes P2P son un área de investigación fascinante de la telemática. De hecho, según Kurose es la aplicación más importante de las redes de computadoras [Kurose 2005].

En cuanto su arquitectura, una red P2P puede ser estructurada o no. En arquitecturas no estructuradas se encuentran: Napster, Gnutela, Freenet, y se llaman así, porque hay una estructura estocástica para organizar a los nodos o iguales (peers). Por otro lado, los de arquitectura estructurada son aquellos en los que los iguales se estructuran de manera determinística, como CAN, Chord, Pastry, Tapestry y Tornado.

En lo concerniente a sus aplicaciones, las redes P2P pueden ser utilizadas en ámbitos como:

• Servicio financieros: En una organización donde se necesita computación de alto rendimiento para el cálculo de operaciones financieras, se podría utilizar el poder de cómputo de las computadoras pertenecientes a la organización, en vez de adquirir una costosa supercomputadora.
• Aplicaciones militares: Las aplicaciones militares no deben tener un único punto de fallo, y el modelo P2P se apropiado para tal fin porque carece de éste.
• En el área de la salud: Las organizaciones de la salud necesitan el poder de almacenamiento de una red P2P para compartir información sin tenerla en un repositorio central.
• Neurociencia: Muchos problemas de esta área de estudio requieren gran capacidad de almacenamiento y rendimiento, y un sistema de software que supla esta necesidad va más allá del alcance de un grupo de investigación en particular, mientras que las redes P2P mucho más fáciles y menos costosas de implantar para conseguir dicho propósito.
• Sistema educativo y compañías de investigación: En la educación a distancia, las redes P2P ponen a disposición de sus usuarios material de aprendizaje. De la misma manera en el ámbito de la investigación, no solo proporciona material didáctico una red P2P, sino la capacidad de cómputo necesaria para cálculos complejos que exigen infraestructura de alto rendimiento.

Por último, es importante mencionar que las redes P2P se pueden construir con sistemas como JXTA, y actualmente se investiga en la forma de fusionar esta tecnología con otras, como los sistema de base de datos, la minería de datos, la computación móvil y ubicua, entre muchas otras.

Protocolos de la capa de aplicación

En esta sección se presentarán algunos de los protocolos de aplicación importantes actualmente y ampliamente utilizados por los usuario de las aplicaciones de la telemática.

La Web y HTTP

Como se dijo previamente, WWW, o simplemente Web, es el sistema distribuido más utilizado de la Internet. Ésta está basado en el protocolo HTTP (HyperText Transfer Protocol o Protocolo de Transferencia de HiperTexto) definido en los RFC 1945, 2068 y 2616 [Rfc 1945, Rfc 2068, Rfc 2616].

La Web tiene una estructura cliente/servidor, donde el servidor se identifica por los puertos 80 y 443 para solicitudes HTTP y HTTPS respectivamente. Este último protocolo utiliza SSL para proteger el canal de comunicación y se describirá en el último capítulo.

Respecto a la terminología propia de la Web, un objeto es un fichero, tal como un documento o página Web, una imagen en formato GIF o JPEG, un applet Java, un clip de audio o video o una película flash, etc., los cuales son identificados mediante una URL (Universal Resource Locator o Localizador de Recursos Universal).

Las páginas Web usualmente están compuestas por un fichero HTML (o XHTML actualmente) base y varios objetos referenciados.

Las referencias en HTML son URLs de los objetos, donde cada una tiene

dos

componentes, el nombre del host que almacena los objetos y el nombre de la ruta del

objeto. Por ejemplo:

        http://www.algundominio.com/directorio1/directorio2/dibujito.gif

        Donde www.algundominio.com es el nombre del host donde está alojado el objeto,

y el nombre de la ruta es /direcorio1/directorio2/dibjujito.gif.

        Como se dijo previamente, el navegador Web es la aplicación cliente HTTP, su

función consiste en mostrar las páginas Web solicitadoas por el usuario. HTTP define la

forma en la que los clientes Web solicitan las páginas a los servidores Web y la forma en

que éstos las transfieren a los clientes.

        HTTP utiliza TCP como protocolo de transporte, así, el cliente HTTP o navegador

inicia una conexión con el servidor, luego envía un mensaje de solicitud a éste, y el servidor

envía el fichero solicitado al cliente. Finalmente se cierra la conexión entre éstos.

        Dado que el servidor no almacena información acerca del estado del cliente, se dice

que HTTP es un protocolo sin estado (o stateless), dicho de otro modo, el servidor no tiene

forma de tomar en cuenta las solicitudes previas para atender una solicitud actual, lo cual

conlleva que los programadores de aplicaciones Web utilicen variables de sesión o cookies

para llevar un historial de las acciones de los clientes en una transacción.

        Otro concepto importante son las conexiones persistentes y no persistentes. Las

primeras son disponibles en la versión 1.1 del protocolo [Rfc 2616], pero las conexiones no

persistentes era el método utilizado en las versiones anteriores.

        Cuando una conexión no es persistente, el navegador tiene que establecer una

conexión nueva por cada objeto referenciado en un fichero HTML, mientras que una

persistente con la misma conexión establecida para descargar el fichero, también se

solicitan y obtienen del cliente los objetos referenciados.

               Figura 2.6 PDU de una solicitud HTTP, donde EB es el carácter de espacio en blanco.

        Por otro lado, la PDU de solicitud del protocolo HTTP, o bien, el formato de un

mensaje de solicitud HTTP [Rfc 2616] se aprecia en la figura 2.6, donde éste está formado

por texto en formato ASCII y está compuestos por varias líneas, y cada una finaliza con los

caracteres avance de línea y retorno de carro (Carriage Return and Line Feed o cr y lf).

        La primera línea es llamada la de solicitud, y las siguientes son llamadas líneas de

encabezado. La línea de solicitud tiene tres campos: el campo del método, el campo de la

URL y el de la versión del protocolo.

        El campo del método puede tener los siguientes valores: GET, POST y HEAD. El

método GET es el más utilizado, y sirve para solicitar un objeto al servidor Web, con el

objeto solicitado identificado por el campo URL. El campo de la versión puede ser HTTP/

1.1 o HTTP/1.0.

        Por lo general se incluye en un mensaje de solicitud la línea de encabezado Host, la

cual especifica el sistema terminal en el reside el objeto solicitado. La primera impresión

de un neófito en telemática es que tal línea es innecesaria, porque el host se puede conocer

en la misma conexión TCP, sin embargo, ésta la utilizan los servidores Proxy Web Caché

(es un servidor especial en el protocolo que proporciona alta disponibilidad), para más

información sobre este tipo se servidores, se puede consultar [Rfc 2616, Kurose 2005].

        Hay otras líneas de encabezados, pero son opcionales en la solicitud y después de

éstas, se incluye el cuerpo de la entidad, el cual va vacío si el método es GET, pero lleva

datos si el método es POST.

        La PDU de una respuesta HTTP proveniente del servidor se puede observar en la

figura 2.7 y está compuesta por tres secciones: La línea que indica el estado de la respuesta,

seis líneas de encabezado y la que contiene el cuerpo de la entidad. Esta última línea

contiene el objeto solicitado por el navegador Web.

        La línea de estado contiene tres campos, los cuales indican la versión del protocolo,

el código de estado y un mensaje de estado correspondiente con el código.

        Las líneas de encabezado indican al navegador información pertinente al navegador

Web, como si la conexión se cerró después de devolverle el objeto solicitado, la fecha y

hora en la que la respuesta fue creada y enviada por el servidor, etc.

        Para un análisis y comprensión más profundo del protocolo HTTP se puede revisar

[Kurose 2005, Rfc 2616].

2.4.2 Transferencia de ficheros (FTP)

Como se mencionó en el primer capítulo, la telemática aborda el problema de transmitir a

larga distancia información computarizada, y particularmente, los usuarios de la

informática usualmente necesitan transferir ficheros de un lugar a otro en el sistema de

ficheros de una computadora, y también necesitan transferir ficheros entre los sistemas de

ficheros de diversas computadoras, por ejemplo, sería deseable para un estudiante acceder

desde su computadora localizada en su casa, a un fichero almacenado en una computadora

remota, es decir, en la universidad en la que estudia, ya que dicho fichero contiene la

descripción de un curso que desea tomar.

        Por esta razón en la Internet se implementó un protocolo para la capa de aplicación

llamado FTP (File Transfer Protocol o Protocolo de Transferencia de Ficheros), el cual se

establece en la cima del protocolo de la capa de transporte TCP y está especificado en el

RFC 959 [Rfc 959].

        En una sesión FTP se establece entre el cliente y el servidor dos conexiones, una

para la transmisión de información de control y otra para la transferencia de datos.

        La conexión de control se utiliza para la transmisión de información como la

identidad de un usuario, su contraseña e instrucciones para la modificación de directorios

remotos o para la descarga y subida de ficheros. De otra parte, la conexión de datos es

utilizada para la transmisión de un fichero.

        Cuando se inicia una sesión FTP con un host remoto, la aplicación cliente establece

una conexión de control en la cima TCP con la aplicación servidor identificada (según el

estándar [Rfc 959]) con el puerto 21; después, sobre esta conexión el proceso cliente envía

la identificación y contraseña del usuario.

        Luego, el usuario puede enviar, a través de la aplicación cliente, instrucciones como

la solicitud de un fichero, en cuyo evento el servidor inicia una conexión de datos sobre

TCP, en el puerto 20, para enviar el fichero a la aplicación cliente. Una vez termine de

enviarlo, la conexión de datos se cierra, y si el usuario en la misma sesión (o bien, con la

misma conexión de control) solicita otro, se vuelve a establecer la conexión de datos.

        En [Kurose 2005, Rfc 959] se presenta un examen completo del protocolo FTP.

2.4.3 Correo electrónico sobre la Internet

El servicio de correo electrónico de la Internet se basa en varios protocolos a saber: SMTP

(Simple Mail Transfer Protocol o Protocolo Simple para la Transferencia de Correo) para

el envío y transmisión de mensajes de correo electrónico; y POP3 (Post Office Protocol

version 3 o Protocolo de Oficina de Correo) e IMAP (Internet Mail Access Protocol o

Protocolo de acceso al Correo de la Internet) para acceder mensajes de correo electrónico.

        SMTP es definido en el RFC 2821 [Rfc 2821]. Es el principal protocolo de la

mensajería en la Internet, es más antiguo que HTTP, y por esta razón tiene problemas de

seguridad inherentes, es representativo de la evolución que ha tenido la red de redes o

Internet. A diferencia del protocolo HTTP, éste admite servicios push, lo que significa que

un servidor puede enviar información a otro host sin que este último lo haya solicitado

previamente. El modelo tradicional se conoce como pull, donde hay la solicitud de un

servicio por parte de un cliente, antes que la aplicación servidor lo proporcione.

 Servidor:    220 dominioficticio.com ESMTP Postfix

 Cliente:     helo otrodominioficticio.com

 Servidor:    250 dominioficticio.com

 Cliente:     mail from:

 Servidor:    250 2.1.0 Ok

 Cliente:     rcpt to:

 Servidor:    250 2.1.5 Ok

 Cliente:     data

 Servidor:    354 End data with .

 Cliente:     subject: Te invito a comer

 Cliente:     Después de la clase del profesor Caicedo, que está muy

 Cliente:     interesante, nos vamos a comer

 Cliente:     .

 Servidor:    250 2.0.0 Ok: queued as 9821D14AC001

 Cliente:     quit

 Servidor:    221 2.0.0 Bye

                           Figura 2.8 Sesión SMTP entre un cliente y un servidor

        En la figura 2.8 se aprecia una sesión SMTP para el envío de un mensaje de correo

electrónico.         En      esta     se      envía      a       un       mensaje  de correo  a

                                                            en              nombre           de

[email protected]

[email protected]. El puerto que identifica al servidor SMTP

es el 25 y se ejecuta en la cima de TCP.

        Cuando se inicia la sesión, el servidor SMTP le envía al cliente un mensaje con el

código 220 más una frase de presentación, que según el ejemplo podría interpretarse como:

Hola, mi dominio es dominioficticio.com y soy una aplicación servidor de mensajería

llamado Postfix.

        Postfix y Sendmail son las aplicaciones servidoras de correo utilizadas en el mundo

del software libre, y en el mundo comercial Microsoft Exchange es un ejemplar.

        Luego de presentarse la aplicación servidora, la aplicación cliente se presenta

también con la instrucción helo seguido por el nombre de su dominio, a lo cual el proceso

servidor le responde con un mensaje de reconocimiento, identificado con el código 250 y

seguido del nombre de su dominio.

        Después, con la instrucción mail from el proceso cliente le indica al proceso

servidor cual es el emisor del mensaje, y con la instrucción rcpt to le indica cual es el

receptor.

        Finalmente, la aplicación cliente le envía al proceso servidor la instrucción data

para indicarle que a continuación le enviará el cuerpo del mensaje, y éste se indica el asunto

del mismo. El mensaje concluye con un punto entre el juego de caracteres cr lf, y la sesión

concluye con la instrucción quit.

        Por otro lado, POP3 e IMAP están definidos en los RFCs 1939 [Rfc 1939] y 2060

[Rfc 2060] respectivamente.

        POP3 es un protocolo de acceso a mensajes de correo electrónico muy fácil de

aprender, pero también es limitado. POP3 utiliza TCP como protocolo de transporte

subyacente y el servidor se identifica con el puerto 110.

        A diferencia de SMTP, POP3 incluye una fase de autenticación, lo cual lo hace más

seguro que el primero. Sin embargo, la fase de autenticación no incluye el cifrado del

nombre de usuario y contraseña, lo cual también lo hace inseguro ante un analizador de

protocolos. Este protocolo también incluye una fase de transacción y una de actualización.

        La fase de transacción involucra la obtención de mensajes, la marca de éstos para

borrado y la eliminación de marcas.

        La última fase consiste en la finalización de la sesión con la instrucción quit (al

igual que con SMTP), y cuando esto sucede, el servidor elimina los mensajes que fueron

marcados para tal fin.

        En cuanto al protocolo IMAP, este está basado en TCP, es más complejo que POP3

y también tiene más prestaciones que este último, por ejemplo, permite la administración de

directorios remotos con mensajes de correo electrónico, lo cual lo hace más agradable para

los usuarios que acceden a sus mensajes de correo desde diversas computadoras. Una

descripción completa de IMAP se encuentra en el sitio Web de dicho protocolo[Imap 2009].

                    Figura 2.9 Sistema de mensajería de la Internet (SMTP, POP3 e IMAP)

        Por último, en la figura 2.9 se muestra un panorama completo del funcionamiento

del servicio de mensajería de la Internet, donde un usuario envía a través de un cliente

SMTP un mensaje de correo electrónico a un servidor SMTP, y este último lo reenvía

mediante el mecanismo de push a otro servidor. En última instancia, un el usuario al que le

enviaron el mensaje lo puede acceder utilizando una aplicación cliente basada en el

protocolo POP3 o el IMAP, el cual se conecta al último servidor que recibió el mensaje

SMTP.

2.4.4 El servicio de directorio de la Internet (DNS)

En las redes de computadoras basadas en el paquete de protocolos TCP/IP, y

particularmente en la Internet, los hosts se identifican por una dirección IP (Internet

Protocol), la cual está compuesta por cuatro octetos de bits, o bien, cuatro bytes.

        En la práctica, los usuarios manipulan cada octeto (o byte) en formato decimal, de

tal manera que manejan cuatro números que oscilan entre cero y doscientos cincuenta y

cinco (0 y 255).

        En el cuarto capítulo se abordará este tema en mayor profundidad, pero en lo que

concierne a DNS (Domain Name System o Sistema de Nombres de Dominios), este

protocolo proporciona un servicio que permite a los usuarios identificar a los hosts por un

nombre y no por un número como la dirección IP.

        El servicio de DNS se implementa en la cima de UDP, y es prestado por un servidor

con una base de datos no relacional identificado con el puerto 53, usualmente el tipo de

aplicación servidor que se utiliza es el Berkeley Internet Name Domain (BIND) que

funciona en máquinas UNIX y Linux [Bind 2009].

        Los procesos servidores DNS de la Internet proporcionan una base de datos

distribuida, de tal manera, que el protocolo en sí mismo hace uso de un gran número de

aplicaciones servidoras para contestar a la consulta de una aplicación cliente. Una consulta

consiste en solicitar la traducción de un nombre a una dirección IP, permitiéndose a los

usuarios utilizar nombres, en vez de direcciones IP, y a las computadoras utilizar éstas

últimas.

        En el mejor de los casos, si el nombre que pasa la aplicación cliente en la solicitud

tiene una dirección IP equivalente, entonces la aplicación servidora le responde indicándole

cual es tal dirección. En caso contrario, la consulta se extiende a otros procesos servidores

hasta responder al proceso cliente con la dirección IP correspondiente al nombre incluido

en la consulta, o le indica que no hay una dirección asociada a tal nombre.

        La razón para que DNS funcione así radica en que sería inverosímil que un solo

proceso servidor tuviera una base de datos con todas los nombres y sus respectivas

direcciones IP asociadas, en otras palabras, el problema que se desea resolver es de

escalibilidad, que es una característica de las aplicaciones y otros sistemas de cómputo de

admitir la inclusión de más usuarios y servicios, en este caso más servidores con sus

nombres propios.

        En vez de tener una base de datos con todos los nombres, DNS se podría considerar

como un protocolo que permite consultar una base de datos distribuida de manera

jerárquica, donde hay tres clase de servidores DNS:

    •   Servidores DNS raíces: En la Internet hay 13 Clusters de servidores DNS de este

        tipo, etiquetados de la A hasta la M.

    •   Servidores DNS de alto nivel: Este tipo de servidores son los que almacenan

        dominios de alto nivel como com, org, net, edu y gov, y de todos los países, como

        co, uk, fr, ca y jp.

    •   Servidores DNS autorizados: Los servidores DNS autorizados son instalados en

        todas las organizaciones que tienen sus redes de computadoras conectadas con la

        Internet.

        Una descripción completa del protocolo DNS se encuentra en los RFCs 1934 y 1935

[Rfc 1934, Rfc 1935].

2.4.5 Redes P2P

Las redes P2P son un área de investigación fascinante de la telemática, de hecho, según

Kurose es la aplicación más importante de las redes de computadoras [Kurose 2005].

        En cuanto su arquitectura, una red P2P puede ser estructurada o no. En

arquitecturas no estructuradas se encuentran: Napster, Gnutela, Freenet, y se llaman así,

porque hay una estructura estocástica para organizar a los nodos o iguales (peers). Por otro

lado, los de arquitectura estructurada son aquellos en los que los iguales se estructuran de

manera determinística, como CAN, Chord, Pastry, Tapestry y Tornado.

        En lo concerniente a sus aplicaciones, las redes P2P pueden ser utilizadas en

ámbitos como:

    •   Servicio financieros: En una organización donde se necesita computación de alto

        rendimiento para el cálculo de operaciones financieras, se podría utilizar el poder de

        cómputo de las computadoras pertenecientes a la organización, en vez de adquirir

        una costosa supercomputadora.

    •   Aplicaciones militares: Las aplicaciones militares no deben tener un único punto de

        fallo, y el modelo P2P se apropiado para tal fin porque carece de éste.

    •   En el área de la saludo: Las organizaciones de la salud necesitan el poder de

        almacenamiento de una red P2P para compartir información sin tenerla en un

        repositorio central.

    •   Neurociencia: Muchos problemas de esta área de estudio requieren gran capacidad

        de almacenamiento y rendimiento, y un sistema de software que supla esta

        necesidad va más allá del alcance de un grupo de investigación en particular,

        mientras que las redes P2P mucho más fáciles y menos costosas de implantar para

        conseguir dicho propósito.

    •   Sistema educativo y compañías de investigación: En la educación a distancia, las

        redes P2P ponen a disposición de sus usuarios material de aprendizaje, de la misma

        manera en el ámbito de la investigación, no solo proporciona material didáctico una

        red P2P, sino la capacidad de cómputo necesaria para cálculos complejos que exigen

        infraestructura de alto rendimiento.

        Por último, es importante mencionar que las redes P2P se pueden construir con

sistemas como JXTA, y actualmente se investiga en la forma de fusionar esta tecnología

con otras, como los sistema de base de datos, la minería de datos, la computación móvil y

ubicua, entre muchas otras.