REDES Y COMUNICACIONES
CAPÍTULO 2: CAPA DE APLICACIÓN
DAVID RODRÍGUEZ HERNÁNDEZ FECHA DE REVISIÓN: 1 – Diciembre ‐ 2007 ZAMORA (CURSO 2007/2008) [email protected]
Nota importante:
Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Redes y Comunicaciones.
Su finalidad es presentar de una forma esquematizada los contenidos de la asignatura, para facilitar el estudio de la misma. Es conveniente disponer de la bibliografía propuesta por la Universidad para su estudio completo.
Cualquier sugerencia, comentario o corrección sobre este documento, envíelo a [email protected] para poder realizar los cambios necesarios.
David Rguez. Hdez. Alumno de 2º ciclo Ingeniería Informática (UNED)
PRINCIPIOS DE LOS PROTOCOLOS DE LA CAPA DE APLICACIÓN
El sistema central sigue siendo el software, a pesar de la importancia de los componentes de la red. Lo que se comunica entre sí a través de la red son procesos, que puede considerarse como programas en ejecución. Aunque los procesos pueden estar en el mismo host (comunicación interproceso) lo que nos interesa en este documento es la comunicación entre procesos de hosts diferentes. Esta comunicación se realiza a base de mensajes, que son enviados por el emisor y recogidos (y, probablemente, respondidos) por el receptor.
El formato y orden de estas comunicaciones vienen definidos por los protocolos de red.
Protocolos de la capa de aplicación
No es lo mismo la aplicación de red que el protocolo de la capa de aplicación. Lo segundo forma parte de lo primero. Por ejemplo, la Web es una aplicación de red, que tiene varios componentes, como estándares de documentos, navegadores web, servidores web…. mientras que HTTP es un protocolo de la capa de aplicación de Web. HTTP define el formato y secuencia de mensajes que se intercambian entre el cliente y el servidor. Otro ejemplo es el correo web (aplicación de red) y el SMTP (protocolo de la capa de aplicación de correo (entre otros)). Pero entonces ¿qué es lo que define un protocolo? • El tipo de mensajes intercambiados (petición, respuesta…). • La sintaxis de los tipos de mensajes (campos, límites de los campos…). • El significado de la información (semántica) de los campos. • Las reglas que indican cuándo y cómo se envían los mensajes y sus respuestas. Algunos protocolos son públicos (ej: HTTP) y se especifican en una RFC, otros son propietarios.
Partes cliente y servidor de una aplicación
En la figura 2.2 del libro se puede ver la comunicación cliente‐servidor de las aplicaciones de red. A veces, un mismo host implementa el servidor y el cliente, como sucede en el Telnet o el FTP. Sin embargo, se suele etiquetar como cliente a aquel host que haya iniciado la sesión.
Procesos que se comunican a través de una red
El envío y recepción de mensajes se realiza a través de sockets. Los sockets son puertas a través de la cual se empujan (y llegan) los mensajes. Aquí se está asumiendo que al otro lado del socket hay una infraestructura de transporte. La figura 2.3 muestra este proceso, utilizando como protocolo de transporte TCP.
El socket también se denomina API (interfaz de programación de aplicaciones) entre la aplicación y la red, ya que es la interfaz entre éstas. El programador tiene un amplio control sobre la capa de aplicación, pero no tanto sobre la de transporte (sobre ésta únicamente la elección del protocolo de transporte y quizá algunos parámetros (ej: tamaño del buffer)).
Direccionamiento de procesos
En el envío de mensajes, el emisor tiene que poder identificar al receptor. Para ello se requiere el nombre o dirección del host y un identificador para referirse al proceso del host destino.
En las aplicaciones en Internet, la dirección del host se especifica mediante la dirección IP, que es un conjunto de 32 bits que identifica inequívocamente al host. Esta dirección debe ser única en términos globales, con lo que su asignación ha de ser cuidadosa.
Por otra parte, se requiere identificar el proceso. En Internet, esto se realiza con los números de puerto. Las aplicaciones más comunes tienen puertos fijos (HTTP – 80, SMTP – 20….), mientras que para aplicaciones nuevas desarrolladas, el programador debe asignarle un número de puerto.
Agentes de usuario
El agente de usuario es una interfaz entre el usuario y la aplicación de red. Un ejemplo es un navegador web para la Web con el protocolo HTTP, o un cliente de correo para el Correo Web con los protocolos SMTP (para la salida de mensajes) y el POP3 y IMAP (para la entrada de mensajes).
¿Qué servicios necesita una aplicación?
La elección del tipo de transporte a utilizar por una aplicación implica analizar los servicios que ofrece cada uno y ver cuáles son los más apropiados. Los requisitos de servicios pueden clasificarse en pérdida de datos, banda ancha y temporización.
Transferencia fiable de datos
Algunas aplicaciones deben funcionar sin que se produzcan pérdidas de datos; por ejemplo, las aplicaciones bancarias. Otras aplicaciones, como puede ser la transmisión de vídeo a tiempo real tienen una cierta tolerancia a pérdidas de datos, que aunque suponga una peor calidad, no es algo crítico.
Ancho de banda
Algunas aplicaciones necesitan transmitir a una cierta tasa de transferencia (por ejemplo, una aplicación de VoIP). Si no se dispone del ancho de banda necesario, la aplicación tendría que cambiar su transferencia o abandonar. Se denominan aplicaciones sensibles al ancho de banda a aquellas que requieren un ancho de banda determinado y aplicaciones flexibles a aquellas que hacen uso del ancho de banda que tengan disponible.
Temporización
Muchas aplicaciones (juegos, telefonía…) requieren tener retardos muy bajos (del orden de milisegundos o menos). Retardos más altos disminuyen la eficacia, como retardos en la transmisión de voz o la pérdida de realismo en juegos online.
La figura 2.4 muestra una tabla que identifica algunos de los ejes más importantes a lo largo de los cuales se pueden clasificar los requisitos de aplicaciones en red.
Servicios proporcionados por los protocolos de transporte de Internet
Internet proporciona dos protocolos de transporte: UDP y TCP. La decisión sobre uno u otro es de las primeras que debe tomar un desarrollador.
Servicios TCP (Transmission Control Protocol)
Incluye un servicio orientado a la conexión y un servicio fiable de transferencia de datos.
El primero indica que, antes de transmitir los datos, el origen y destino intercambian unos paquetes de control (handshacking). Se establece una conexión TCP que es full‐duplex (se puede transmitir simultáneamente en ambas direcciones). Cuando termina la transmisión, hay que romper la conexión. El segundo indica que los datos se envían en orden y sin errores.
Además, incluye un mecanismo de control de congestión, que regula el proceso emisor cuando la red está congestionada (limita su tasa de envío). En las aplicaciones a tiempo real, esta regulación es perjudicial, por lo que los desarrolladores suelen utilizar para ellas UDP en vez de TCP.
TCP no garantiza una tasa de transmisión mínima y tampoco proporciona garantías de retardo (garantiza que se entregará, pero no en cuánto tiempo).
Servicios UDP (User Datagram Protocol)
Funciona sin conexión (al contrario que TCP) y su transferencia de datos es no fiable. Es decir, los mensajes pueden llegar desordenados e, incluso, pueden no llegar. Tampoco incluye ningún mecanismo de control de la congestión, por lo que suele usarse para los sistemas a tiempo real (una limitación en la transferencia supone una pérdida importante).
Al igual que TCP, UDP no garantiza el retardo del envío.
En la figura 2.5 se muestran los protocolos usados por algunas aplicaciones concretas.
Aunque ni UDP ni TCP garantizan el retardo, las aplicaciones sensibles a los tiempos están diseñadas para (hasta cierto punto) hacer frente a esa falta de garantía.
LA WEB Y HTTP
Antes, Internet era usada por investigadores, académicos y estudiantes; y era desconocida fuera de esos ámbitos. Cuando, a principios de los 90’s, apareció la World Wide Web, la situación comenzó a cambiar. Ahora, la Web funciona bajo demanda; es decir, cada usuario solicita lo que quiera cuando quiera (no ocurre lo mismo en otras redes, como la radio o la TV, donde lo que se transmite no depende de lo que quiera el usuario).
Introducción a HTTP
Es el protocolo de transferencia de hipertexto y es el protocolo de aplicación de la Web. El cliente y el servidor intercambian mensajes HTTP.
Una página web es un conjunto de objetos (HTML base + imágenes, sonidos, applets de Java…). El HTML hace referencia al resto de objetos mediante la URL. La URL consta del nombre del host (ej: www.uned.es) y del nombre de ruta (/portal/). El navegador es un agente de usuario que muestra la página web y que implementan el lado cliente de HTTP.
Un servidor web es un host que aloja archivos web y que implementan el lado servidor de HTTP. HTTP define cómo los clientes piden páginas y cómo se les transmiten. Es decir, el cliente solicita una página con un mensaje HTTP y el servidor responde con otro mensaje HTTP que contiene la página.
Tenemos las versiones HTTP/1.0 y HTTP/1.1. Un servidor con la 1.1 puede comunicarse con un cliente con la 1.0 y un cliente con la 1.1 puede hablar con un servidor con la 1.0. Ambas versiones usan TCP. Así pues, HTTP no tiene que preocuparse por la pérdida de datos (recuérdese que TCP garantiza la ausencia de dicha pérdida). Una vez que el mensaje ha sido lanzado a través del socket, queda en manos del TCP. HTTP es un protocolo sin estado; es decir, no guarda información sobre los clientes (si un cliente pide dos veces la misma página, el servidor no advierte que ya la pidió antes).
Conexiones no persistentes y persistentes
La versión 1.0 utiliza conexiones no persistentes (con las que sólo se puede enviar un objeto web) y 1.1 puede utilizar ambas (aunque por defecto usará las persistentes).
Conexiones no persistentes
En las conexiones no persistentes, cada vez que se envíe un objeto web, se cierra la conexión TCP (si una página consta de 4 JPEG’s, se creará y cerrará la conexión 4 veces. Téngase en cuenta que los navegadores pueden abrir conexiones paralelas.
El RTT (Round‐Trip Time) es el tiempo de ida y vuelta. Incluye los retardos de propagación de paquetes, los de las colas en los routers y switches y los de procesamiento de paquete.
Cuando un usuario pulsa un hiperenlace, el cliente envía una petición de conexión al servidor y éste responde aceptándola (podría rechazarla, pero supongamos una conexión exitosa): Ha pasado un RTT. Seguidamente, el cliente solicita la página en cuestión y el servidor se la envía. El segundo RTT termina cuando se comienza a recibir la página.
Así pues, la duración ha sido de 2 RTT más la duración de la transferencia de la página. Esto se puede ver en la figura 2.7.
Conexiones persistentes
El anterior planteamiento tenía problemas, como es la necesidad de establecer una conexión por cada objeto (lo que supone dos RTT por cada uno (uno de conexión y otro de petición de la página). Además, por cada vez se deben reservar buffers y variables TCP.
En las conexiones persistentes, la conexión TCP queda abierta (no se cierra al recibir el objeto). Esto permite transmitir todos los objetos por una única conexión (con su consiguiente ahorro). HTTP cierra una conexión si no se ha usado en un determinado tiempo.
• Sin entubamiento: El cliente sólo lanza una petición nueva cuando la respuesta anterior se haya recibido., con lo que hay 1 RTT por cada objeto pedido y recibido. Cuando se ha enviado un objeto, el servidor se queda esperando a por otra conexión, con lo que se desaprovechan recursos.
• Con entubamiento: Es el modo por defecto de la versión 1.1. El cliente realiza una petición en cuanto encuentre una referencia, lo que supone que puede hacer peticiones seguidas sin esperar a la respuesta anterior. Asimismo, el servidor puede enviar objetos seguidos (si las peticiones le llegan seguidas). Un entubamiento con varios objetos puede suponer un solo RTT. La inactividad es menor que sin entubamiento.
Formato del mensaje HTTP
Hay 2 tipos de mensajes: mensajes de petición y mensajes de respuesta.
Mensaje HTTP de petición
A continuación un mensaje HTTP de petición típico:
GET /dir/pagina.html HTTP/1.1
Host: www.escuela.edu
Connection: close
User‐agent: Mozilla/4.0
Accept‐language: fr
Un mensaje de petición puede contener muchas más líneas, o simplemente tener 1. La primera línea es la línea de petición, que consta de 3 campos: el método, la URL y la versión de HTTP. El método puede ser GET, POST o HEAD, aunque en los mensajes de petición suele ser GET; que es cuando el navegador pide un objeto designado por el campo de URL. El campo de versión es autoexplicativo.
La línea host especifica el host en que reside el objeto. La línea Connection con el valor close indica que el navegador no quiere usar conexiones persistentes. La línea user‐agent indica el agente de usuario (navegador) que se usa. Por último, la línea accept‐language indica la preferencia de lenguaje del objeto que se pide (si es que existe en dicho lenguaje.
En la figura 2.8 del libro se puede ver la estructura de un mensaje HTTP de petición. Tras las líneas de cabecera (y el retorno de carro y salto de línea final) hay un cuerpo de entidad, que se utiliza con el método POST.
Un formulario no tiene por qué usar el método POST, puede ir directamente en la URL y usar el método GET. En caso de usar POST, el cuerpo de entidad contiene los datos del formulario.
El método HEAD suele usarse para depuraciones. Es similar al GET, pero no incluye el objeto solicitado en la respuesta.
La especificación HTTP/1.1 incluye además otros dos posibles métodos: PUT, que permite cargar un objeto en una URL y DELETE, que permite borrar un objeto alojado en una URL.
Mensaje HTTP de respuesta
Al ejemplo dado anteriormente, le correspondería esta respuesta:
HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:45 GMT
Server: Apache/1.3.0 (Unix)
Last‐Modified: Mon, 22 Aug 1998 09:23:24 GMT
Content‐Length: 6821
Content‐Type: text/html
(DATOS)
Comienza con una línea inicial de estatus, que contiene 3 campos: la versión del protocolo, el código de estatus y el propio estatus. Después hay 6 líneas de cabecera, que indican (por este orden) que no habrá conexión persistente (es decir, el cliente cerrará la conexión TCP cuando reciba la respuesta), la fecha de la creación y envío de la respuesta, el servidor que la emitió, la fecha y hora de la última modificación del objeto pedido, el tamaño (en bytes) del objeto y el tipo de objeto que hay en el cuerpo de entidad. A continuación, está dicho cuerpo, que contiene el objeto solicitado.
Si el cliente envía una petición HTTP/1.0 y el servidor es HTTP/1.1; el servidor cerrará la conexión TCP tras enviar la respuesta, ya que el cliente cuenta con ello. Los códigos y estados más comunes son los siguientes: • 200 OK: La información se devuelve en la respuesta exitosamente. • 301 Moved Permanently: El objeto se mueve de una URL a otra que se indica en la respuesta. • 400 Bad Request: El servidor no entiende la petición. • 404 Not Found: A la que más acostumbramos estamos. El objeto no existe. • 505 HTTP Version not supported: El servidor no soporta la versión de HTTP de la petición. En la figura 2.9 se puede ver la estructura de un ejemplo de mensaje HTTP de respuesta. Un mensaje puede tener más líneas de cabecera (sobre todo en la versión 1.1). En los siguientes apartados se verán más líneas posibles.
Interacción usuario‐servidor: autorización y cookies
Antes dijimos que HTTP no tiene estado. Pero, en ocasiones, será necesario identificar a los usuarios (seguridad, seguimiento…). Para ello, tenemos los mecanismos de autorización y cookies.
Autorización
Si un cliente envía una petición HTTP a un servidor que requiere autentificación, el servidor responde con un mensaje vacío y un estatus: 401 AuthorizationRequired. Además, incluye una cabecera WWW‐ Authenticate que indica las instrucciones para identificarse. Entonces el navegador pide al usuario los datos requeridos (normalmente un nombre de usuario y una contraseña). Cuando los introduce, el
cliente reenvía la petición, pero incluyendo la línea de cabecera Authorization, con los datos introducidos. En las sucesivas peticiones, el cliente reenvía esos datos de identificación. Pero esto sólo dura hasta que se cierre el navegador, pues se descarga la cache.
Cookies
Las cookies son archivos de texto con información de sesión que se almacenan en el cliente. Si un cliente que no tenga la cookie adecuada envía una petición al servidor que las requiera, éste devuelve una respuesta con la línea Set‐cookie y un número de identificación único que previamente ha generado. El cliente registra esa identificación en sus archivos de cookies, junto con el host que lo asignó. Así pues, cada vez que envíe una petición, incorporará la línea Cookie junto con el número de identificación.
Esto permite al servidor hacer un seguimiento completo de un usuario sin necesidad de requerir información adicional, como el nombre. Las cookies pueden usarse para identificar usuarios. Pero el uso de cookies es polémico, porque puede considerarse una intromisión en la privacidad, reunir datos y vendérselos a terceros… El GET condicional El almacenamiento de objetos ya recuperados en la cache del cliente, puede reducir los retardos en caso de que se requiera de nuevo dicho objeto. Pero he aquí el problema: el objeto almacenado puede estar obsoleto. Para paliar este obstáculo, se utiliza el llamado GET condicional, que es un mensaje del método GET que contiene la línea de cabecera If‐Modified‐Since.
Si un objeto no está en la cache, la petición se realiza de forma normal, tal y como vimos anteriormente. Cuando recibe la respuesta, se almacena en la cache junto con la fecha de su última modificación. Si, más adelante, vuelve a pedir el mismo objeto, incluirá la siguiente línea (por ejemplo) en la cabecera:
If‐modified‐since: Mon, 22 Jun 1998 09:28:47
Si el objeto ha sido modificado posteriormente, el servidor ¡envía el objeto de forma normal. Pero si no ha sido modificado, envía un mensaje vacío con el estatus 304 Not Modified.
Contenido HTTP
Hasta ahora hemos supuesto que el contenido de los mensajes era una página web. Pero puede haber más contenidos. Puede contener archivos XML, que contienen datos estructurados (por ejemplo, datos bancarios). También se puede transferir WML (el lenguaje de marcado WAP), VoiceXML y otros tipos de documentos XML.
TRANSFERENCIA DE ARCHIVOS: FTP
El usuario utiliza un agente de usuario FTP (no el navegador HTTP) para realizar la transferencia de archivos. Primero, el cliente establece una conexión TCP con el host al que se quiere transferir (o recibir)
y, acto seguido, el usuario introduce los datos de identificación. Éstos se envían como parte del comando FTP, el servidor lo identifica y luego se realiza la transmisión de datos.
Aunque FTP y HTTP utilizan conexiones TCP, FTP utiliza dos de ellas paralelamente: una para la conexión de control y otra para la conexión de datos. La primera envía datos de control, como la identificación del usuario, comandos de cambio de directorio… La segunda se usa para enviar propiamente los archivos. Como la conexión de control es separada, se dice que envía su información de control fuera de banda (HTTP se dice que la envía en banda, porque utiliza la misma conexión TCP que para los datos). La conexión de control establecida entre el cliente y el servidor se realiza por el puerto 21. Por la conexión de control, el servidor recibe los datos de autentificación y los distintos comandos y órdenes (cambiar un directorio, transferir un fichero…). Cuando el servidor recibe la orden de transferir un fichero, lo envía por la conexión de datos y, seguidamente, cierra dicha conexión. Si se vuelve requerir otra transferencia, la vuelve a abrir; es decir, las conexiones de datos son no persistentes. Para realizar el seguimiento del usuario, el servidor asocia la conexión de control a la cuenta de usuario. El seguimiento limita el número máximo de sesiones que el servidor puede mantener simultáneamente. Comandos y respuestas FTP Los comandos y las respuestas sobre la conexión de control tienen un formato ASCII de 7 bits. Cada comando se compone de 4 caracteres ASCII en mayúsculas. Podemos citar algunos ejemplos, como USER (para indicar el nombre de usuario), PASS (para indicar la contraseña), LIST (para listar los archivos del directorio), RETR (para recuperar un archivo) o STOR (para almacenar un archivo).
Hay una correspondencia uno‐a‐uno entre los comandos y las respuestas (que se componen de un número de 3 dígitos y un mensaje opcional).
CORREO ELECTRÓNICO EN INTERNET
El correo electrónico es un medio de comunicación asíncrono, es decir, se envía cuando la persona en cuestión quiere. En la figura 2.12 se puede ver un esquema a alto nivel del funcionamiento del correo electrónico. Pueden verse 3 elementos diferenciados: los agentes de usuario, el servidor de correo y el protocolo simple de transferencia de correo (SMTP). Los primeros (comúnmente conocidos como lectores de correo) permiten leer, recibir, enviar y almacenar correos electrónicos. El segundo es el punto de contacto con el exterior, al cual el agente envía los mensajes a enviar y del cual se leen los mensajes recibidos (dispone de una cola de mensajes para su gestión). El tercero es el protocolo principal para el correo electrónico en Internet y utiliza el servicio TCP. Como la mayoría de protocolos, el SMTP tiene un lado cliente y un lado servidor, que se implementan en todos los servidores de correo (cliente para enviar y servidor para recibir).
SMTP
Transfiere mensajes entre servidores de correo y es mucho más antiguo que el HTTP. Aunque tiene numerosas cualidades, también posee algunas restricciones que actualmente no tienen razón de ser, como la limitación de ASCII de 7 bits para el cuerpo del mensaje (actualmente, en la era multimedia, los datos binarios deben ser codificados a ASCII y posteriormente decodificados por el destinatario).
Los pasos realizados para enviar un correo de A a B serían los siguientes:
1. El mensaje se envía desde el agente de usuario de A a la cola de mensajes del servidor de correo de A.
2. El servidor ve el mensaje y establece una conexión TCP con un servidor SMTP que está ejecutándose en el servidor de correo de B.
3. Tras una sincronización SMTP inicial, el mensaje se envía al servidor de correo B sobre dicha conexión TCP. El mensaje se deposita en el buzón de correo de B.
4. El servidor de B envía el mensaje al agente de usuario de B cuando éste se lo solicite.
Esto mismo se puede ver gráficamente en la figura 2.13. No se suelen utilizar servidores intermedios, aunque la distancia entre ambos sea grande. El puerto utilizado para el SMTP es el puerto 25. Después de la mencionada figura 2.13 puede encontrarse en el libro un ejemplo de transcripción de mensajes intercambiados entre un cliente SMTP y un servidor SMTP. En los mensajes se pueden encontrar comandos (autoexplicativos) como HELO, FROM, RCPT, TO, DATA o QUIT. El servidor emite respuestas para cada comando, con su respectivo código y una frase opcional.
SMTP utiliza conexiones persistentes; es decir, pueden enviarse varios mensajes consecutivos sobre la misma conexión TCP.
Se podría enviar un correo electrónico a un servidor SMTP directamente (sin agente de usuario) a través de Telnet.
Comparación con HTTP
Ambos protocolos se usan para enviar archivos: HTTP transfiere objetos web y SMTP mensajes de correo electrónico. Sin embargo, HTTP es un protocolo de demanda; es decir, el archivo se envía cuando el receptor lo solicite; mientras que SMTP es un protocolo de oferta; es decir, el archivo se envía cuando quiere el emisor. Además, SMTP requiere que los mensajes se codifiquen en ASCII de 7 bits, mientras que HTTP no tiene dicha restricción.
Por último, HTTP encapsula cada objeto (texto, imágenes…) en su propio mensaje HTTP; mientras que SMTP reúne todos los objetos en un solo mensaje.
Formatos de mensajes de correo y MIME
Los correos electrónicos incluyen una cabecera con información adicional. Cada línea de cabecera contiene texto legible (que es una clave seguida de dos puntos (:) y un valor). Algunas claves son obligatorias y otras opcionales. Debe incluir las líneas From: y To:, además puede incluir (opcionalmente) Subject:.
Tras la cabecera, hay una línea en blanco, y seguidamente el cuerpo del mensaje en ASCII.
La extensión MIME para datos no ASCII
Cuando se intentan enviar mensajes con caracteres especiales o con contenido (por ejemplo) multimedia, las cabeceras anteriores (indicadas por la RFC 882) no son suficientes. Hay que utilizar líneas adicionales de cabecera, descritas en RFC 2045 y RFC 2046. Son las extensiones MIME (Multipurpose Internet Mail Extensions).
Para el soporte multimedia, las dos cabeceras clave son Content‐Type:, que permite que el receptor tome las acciones oportunas respecto al mensaje; y Content‐Transfer‐Encoding:, que indica al receptor que el mensaje ha sido codificado a ASCII e indica el tipo de codificación que se ha usado. Este último es usado por el receptor para saber cómo debe devolverlo a su formato original.
El campo Content‐Type indica un tipo (general) y un subtipo (más específico) (ej: image/jpeg). Además, puede haber parámetros que son modificadores del subtipo, pero sin afectar a su naturaleza.
Actualmente, hay 7 tipos de alto nivel definidos, cada uno de los cuales tiene un conjunto de subtipos, de los cuales describiremos tres:
• Text: Información textual. Un ejemplo muy común es text/plain, que indica que contiene texto plano (no requiere software específico, se lee tal cual). Puede tener parámetros indicando el juego de caracteres usado. Otro tipo común es text/html, que indica que el texto debe ser interpretado como código html.
• Image: Imagen. Dos habituales son image/jpeg y image/gif.
• Application: Datos que no se ajustan en ninguna otra categoría. Requieren ser procesados por una aplicación completa antes de poder visualizarse. Un ejemplo es application/msword, que requiere el Microsoft Word.
Existe un tipo importante llamado multipart. Un ejemplo es multipart/mixed, que indica que el mensaje contiene varios objetos (por ejemplo, una imagen seguida de un texto ASCII). En el libro puede encontrarse un ejemplo de este tipo de mensajes.
El mensaje recibido
El servidor SMTP destino añade algunas líneas de cabecera más al mensaje. Añade una línea Received: que contiene el remitente, el nombre del servidor receptor y la fecha/hora de la recepción (ej: Received: From crepes.fr by hamburguer.edu; 12 Oct 98 15:32:51 GMT).
En ocasiones pueden aparecer múltiples líneas Received. Esto ocurre cuando un mensaje se produce por un “reenvío”.
Protocolos de acceso al correo
Hasta comienzos de los 90’s, lo más normal era acceder directamente al host para leer los mensajes contenidos en el buzón de entrada. Pero, hoy en día, se utilizan agentes de usuario para acceder a dichos mensajes. Lo habitual (por comodidad y facilidad) es que el servidor esté en un servidor compartido que siempre está encendido (no en el ordenador del destinatario final) y mantenido generalmente por el ISP, por lo que el agente de usuario se conecta a dicho servidor. Pero ¿cómo se comunican?
Como SMTP es un protocolo de oferta, no puede utilizarse para recibir esos mensajes (puesto que sería bajo demanda). Para ello tenemos algunos protocolos especiales, como POP3 (Post Office Protocol – versión 3), IMAP (Internet Mail Access Protocol) o HTTP.
POP3
Es un protocolo de acceso al correo bastante simple. Utiliza una conexión TCP por el puerto 110. El protocolo realiza 3 fases: autorización, en que el agente de usuario envía el nombre de usuario y la contraseña; transacción, en que se recuperan los mensajes; y actualización, que se ejecuta cuando el cliente envía el comando quit y el servidor de correo borra los mensajes marcados para ello.
El cliente emite comandos y el servidor puede responder con +OK, que indica que el comando era el adecuado; o –ERR, que indica algo erróneo en el comando. La respuesta +OK puede ir seguida de datos adicionales (por ejemplo, un mensaje para indicar que la identificación se ha realizado correctamente). Los mensajes leídos pueden ser borrados o mantenidos. Cuando se borra, el cliente envía los comandos list (listar la lista de tamaños de los mensajes), retr (recupera el mensaje) y dele (borra el mensaje). Cuando ha realizado la operación para todos, ejecuta quit. El problema es que los mensajes quedarán almacenados en un ordenador concreto y sólo se podrá acceder desde ahí.
En el caso de mantenerse el mensaje en el servidor; puede ser “releído” desde cualquier otro ordenador.
POP3 mantiene información sobre los mensajes marcados para borrarse, pero no guarda información sobre sesiones de POP3.
IMAP
Es un protocolo más complejo y con más funcionalidades de POP. Un servidor IMAP asigna cada mensaje a un buzón. Inicialmente se almacena en el buzón INBOX, pero puede ser movido seguidamente a un buzón creado por el usuario, leer el mensaje, borrarlo… IMAP proporciona comandos para realizar estas operaciones y también para buscar en los buzones remotos mensajes que cumplan con ciertos criterios.
IMAP mantiene información de estado de los usuarios entre sesiones IMAP (ej: nombres de buzones y qué mensajes se asocian).
Además, pueden recuperarse componentes de mensajes únicamente (por ejemplo, las cabeceras o una parte de un MIME multiparte), que puede ser útil, por ejemplo, con conexiones lentas entre el agente de usuario y el servidor de correo.
Correo electrónico basado en web
Se trata de acceder al correo a través de la Web, concepto que fue introducido a mediados de los 90’s con Hotmail. Cuando se solicitan los mensajes, éstos se envían mediante HTTP. Esto abre muchas posibilidades, ya que el correo puede ser consultado desde cualquier ordenador que disponga de un navegador web común. Estos correos suelen implementar un servidor IMAP, a fin de poder organizar los buzones remotos.
DNS: EL SERVICIO DE DIRECTORIO DE INTERNET
Los host de Internet tienen un sistema para identificarlos inequívocamente. Este sistema puede ser los nombres de host (ej: www.uned.es); pero da muy poca información (prácticamente ninguna) acerca de su localización en Internet; aunque resulta cómodo para los usuarios. Además, tienen longitudes variables, lo que dificulta al router su procesamiento.
Por ello se utilizan las direcciones IP, que se compone de 4 octetos (bytes) representados por su equivalente decimal (de 0 a 255) y separados por un punto (.). Las direcciones IP son jerárquicas, ya que cada byte ofrece una información más específica que el anterior (de izquierda a derecha), al igual que una dirección postal.
Servicios proporcionados por DNS
DNS significa Domain Name Service, y su principal tarea es traducir los nombres de host a sus correspondientes direcciones IP. Es decir, es una BBDD distribuida. Se ejecuta sobre UDP en servidores UNIX (normalmente) por el puerto 53.
DNS es usado por protocolos de la capa de aplicación (HTTP, FTP, SMTP…). Cuando un usuario teclea una URL, el cliente DNS contacta con el servidor DNS y le envía la URL. Éste le responde con la IP correspondiente, la cual es utilizada para establecer la conexión HTTP por TCP final.
Además, proporciona otros servicios:
• Alias de hosts: Un nombre de host puede ser demasiado largo de recordar (se denomina nombre canónico). Entonces existen alias que simplifican el acceso a dicho host. Si un cliente proporciona un alias, el servidor puede responder con el nombre canónico y la IP.
• Alias de servidores de correo: De la misma forma, si nosotros enviamos un email a [email protected], probablemente “Hotmail.com” no sea el nombre canónico del servidor. La aplicación de correo puede invocar al DNS para averiguar el nombre canónico para enviar el email.
• Distribución de carga: Un sitio web puede estar replicado en varios servidores (cada uno con su IP). El servidor DNS envía el conjunto de IP’s pero rotándolas a cada petición, lo que provoca que las peticiones hacia dicha web se repartan entre todos los hosts.
Resumen de cómo trabaja el DNS
Cuando el servidor DNS recibe una petición de traducción, el servidor busca el nombre solicitado en su BBDD. Pero el DNS no es un solo servidor. Podría serlo, pero se plantearían los siguientes problemas:
• Único punto de fallo: Si el servidor falla, falla todo Internet.
• Volumen de tráfico: El ratio de peticiones es demasiado alto para un solo servidor.
• BBDD centralizada distante: Habría muchos clientes lejos del servidor, lo que provocaría retardos.
• Mantenimiento: La BBDD sería gigantesca y debería estar en constante actualización. También hay un problema de identificación.
Por ello, DNS tiene un gran número de servidores distribuidos por el mundo, organizados jerárquicamente. Así, los nombres de hosts están repartidos entre los servidores. Hay 3 tipos:
• Servidores locales de nombres: Cada ISP tiene un servidor de nombres, que contiene los hosts de dicho ISP. Así, si el usuario pide un host de la misma ISP (que suele situarse cerca del cliente), la traducción es directa y rápida.
• Servidores raíz de nombres: Existen cerca de una docena de ellos en el mundo, que se muestran en la figura 2.15. Si el servidor local no dispone del host, hace las veces de cliente DNS y pregunta a su vez al servidor raíz. Si éste dispone del host, se lo enviará al local, que a su vez se lo envía al cliente. Si no dispone de él, consultará al servidor autorizado. • Servidores autorizados de nombres: Todo host está registrado obligatoriamente al menos en 2 servidores autorizados (para el caso de fallos). Un servidor de nombres está autorizado para un host si contiene su IP correspondiente. Recibe las consultas de un servidor raíz y le responde con la IP (a su vez, el raíz responde al local, el cual responde al cliente). En la figura 2.16 se puede encontrar un ejemplo de este proceso. Puede ocurrir que el servidor raíz no conozca la IP del servidor autorizado adecuado; pero sí conozca la IP de un servidor intermedio que sí tiene la IP del servidor autorizado. En tal caso, reenvía la petición al servidor intermedio, que actúa de puente para establecer la comunicación (véase ejemplo en la figura 2.17).
Estos procesos vistos hasta ahora son recursivos. Pero también pueden producirse consultas iterativas, en las que, si el servidor preguntado no dispone de la IP; en lugar de preguntar al siguiente servidor, informa al anterior de cuál es el siguiente. De esa forma, el servidor que preguntó al principio vuelve a preguntar, pero esta vez al servidor que se le ha indicado. Véase el ejemplo en la figura 2.18.
Pero hay otro elemento importante: la cache DNS. Cuando un servidor pregunta por una IP y le dan la respuesta, la almacena en una cache (memoria RAM), con el fin de poder servir dicha IP en futuras peticiones (aunque no esté autorizado para ese host). El periodo en que se mantiene suele ser corto (generalmente, dos días).
Registros DNS
Los servidores de nombres implementan registros de recursos (RR), que guarda las correspondencias entre nombres de host y sus direcciones IP. Un RR es una 4‐tupla con el nombre, el tipo, el valor y el tiempo de vida del RR.
Si el tipo es A, entonces el nombre es el nombre del host y el valor, su dirección IP.
Si el tipo es NS, entonces el nombre es un dominio y el valor, el nombre de host de un servidor autorizado para los host de ese dominio. Este RR permite redirigir las consultas a lo largo de la cadena. Si el tipo es CNAME, entonces el nombre es un alias y el valor, su nombre canónico.
Si el tipo es MX, entonces el nombre es un alias de correo y valor, su nombre canónico (es lo mismo que CNAME, pero para servidores de correo).
Si un servidor está autorizado para un host, tendrá un RR de tipo A para ese host. Si no, tendrá uno de tipo NS que le permita consultar a otro servidor.
Mensajes DNS
Hay dos tipos: de consulta y de respuesta. En la figura 2.19 se puede ver la estructura.
• La cabecera (12 bytes) contiene la identificación de la consulta (16 bits), un conjunto de señales (tipo de mensaje, servidor autorizado, consulta recursiva, recursión disponible) y cuatro campos número de, que indica el número de ocurrencias de cada tipo de datos que hay a continuación.
• Cuestiones: Información sobre la pregunta que se está haciendo (nombre consultado, tipo de consulta (A o MX)).
• Respuestas: En una respuesta, contiene los RR para el nombre que se consultó. Puede haber varios RR en una consulta (por ejemplo, para sitios web replicados).
• Autorización: Contiene registros de otros servidores autorizados.
• Información adicional: Tiene otros registros de ayuda. Por ejemplo, en la respuesta a una consulta MX, la sección de respuesta contiene el RR que da el nombre de host canónico de un servidor de correo y la sección adicional contiene un RR de tipo A con la dirección IP para dicho nombre de host canónico del servidor de correo.
Antiguamente, los contenidos del servidor eran configurados estáticamente (ej: con un fichero de configuración indicado por el administrador); pero recientemente se ha añadido un comando UPDATE al protocolo DNS para añadir o borrar dinámicamente de la BBDD.
PROGRAMACIÓN DE SOCKETS CON TCP
*** NOTA*** EN ESTE APARTADO Y LOS DOS SIGUIENTES SE HARÁ REFERENCIA A CÓDIGO FUENTE QUE SE INCLUYE EN EL LIBRO. POR MOTIVOS DE SIMPLICIDAD NO SE COPIARÁN EN ESTE DOCUMENTO. CONVIENE TENER EL LIBRO DISPONIBLE PARA CONSULTAR EL CÓDIGO Y SU EXPLICACIÓN.
Al crear una aplicación de red, el programador debe desarrollar dos programas que se comunicarán en red: un programa servidor y un programa cliente. Hay dos tipos de aplicaciones cliente‐servidor. Aquellas que implementan un protocolo estándar definido en una RFC (por ejemplo, el FTP), en cuyo caso deben ser conformes a las reglas definidas en dicha RFC; y las aplicaciones propietarias, en las que cliente y servidor no tienen por qué seguir ninguna RFC.
En las primeras, cualquier desarrollador independiente puede crear otro programa que interopere con el primero, si sigue correctamente la RFC; mientras que con el segundo no podría. En las aplicaciones propietarias, se debe tener especial cuidado en no usar algún número de puerto asignado a las aplicaciones conocidas.
Programación de redes con TCP
Cuando un cliente contacta con un servidor, establece una comunicación con él. Para que el servidor pueda atender dicha comunicación, debe estar ejecutando el proceso y tener un socket (podríamos compararlo con una puerta).
El cliente crea un socket, especificando la dirección del proceso del servidor e intenta establecer la conexión TCP; realizando una sincronización en 3 pasos. El servidor, al recibir la señal, crea un socket que se dedicará a ese cliente concreto. Cuando el cliente contacta con éste último socket, el servidor inicia la orden accept() que creará un nuevo socket (es decir, el anterior únicamente servía para establecer la conexión). Entre este último socket y el del cliente se establece finalmente la conexión TCP. Esta conexión, que es directa entre ambos sockets, permitirá el envío garantizado de datos en ambas direcciones.
Se denomina flujo a la secuencia de datos que se envían desde o hacia un proceso (flujo de salida o flujo de entrada respectivamente). La conexión TCP resulta ser una tubería entre ambos sockets. El apartado 2.6.3 muestra un ejemplo en Java desarrollado para establecer dicha conexión TCP. Conviene leerlo.
PROGRAMACIÓN DE SOCKETS CON UDP
UDP permite que se comuniquen dos o más procesos en distintos hosts. Sin embargo, UDP es un servicio sin conexión(al contrario que TCP). Es decir, no hay una conexión dedicada, sino que cada paquete enviado incluye la dirección IP y el número de puerto del proceso de destino. No se garantiza la entrega del paquete en destino.
En el libro aparece (y conviene leer) la versión para UDP del programa mencionado anteriormente. Nótese que no hay fase de sincronización (por lo que no se requiere ningún socket de acogida), a los sockets no se les conecta ningún flujo, el host emisor añade la dirección IP y número de puerto al paquete y el proceso receptor debe desempaquetar lo recibido para poder leer los datos.
CONSTRUCCIÓN DE UN SERVIDOR WEB SENCILLO
La tarea es bastante más sencilla de lo que en principio pueda parecer. El ejemplo se realizará en Java.
Funciones del servidor web
El servidor que queremos recibirá peticiones HTTP y responderá con el objeto solicitado. Para simplificar, supondremos que el objeto solicitado siempre existe en el servidor.
Véase el código java del apartado 2.8.1 (WebServidor.java). En él se puede ver cómo el servidor crea un socket que escuche en un puerto TCP (similar a los códigos vistos anteriormente). Este socket aceptará peticiones por el puerto 6789 y, al recibir una, creará un nuevo socket que se dedique a ese cliente. Se crean dos flujos (uno de entrada y otro de salida)
Al servidor le llega la petición HTTP por el flujo de entrada (a través del socket de conexión (el último que hemos creado)) y lee la primera línea, que le indicará el archivo que ha solicitado (recuérdese la
línea de cabecera GET {archivo} {versión}). El sistema “troceará” la cadena para poder extraer el nombre del archivo.
Entonces, el servidor crea un flujo asociado al archivo y lee dicho archivo, colocando sus bytes en el flujo. Por último, se prepara en el flujo de salida la cabecera HTTP que se enviará, seguido del archivo que hemos almacenado en el flujo de entrada.
Por último, una vez enviado, el servidor cierra la conexión TCP (cierra el socket).
DISTRIBUCIÓN DE CONTENIDOS
Los contenidos de Internet están distribuidos por todo el mundo. Sin embargo, HTTP permite a los usuarios recuperar cualquier objeto; aunque esto puede incidir a veces en los tiempos de respuesta; debido a posibles bajas tasas de transferencia en el camino, congestiones, sobrecargas del servidor… Para reducir estos problemas, los objetos se replican por la Web, de forma que el usuario pueda acceder al servidor que más rápidamente se lo pueda servir. Esto se conoce como distribución de contenidos. Existen muchos esquemas para este fin, pero se pueden englobar en 3 categorías: cache web, redes de distribución de contenidos y compartición de archivos entre iguales.
Cualquier persona u organización que ponga algún archivo a disposición del resto de usuarios es un proveedor de contenidos. Se considera servidor de origen a aquel servidor que contiene la copia original del archivo.
Cache Web
También se llama servidor proxy. Satisface las peticiones HTTP en nombre de un servidor original. Almacena copias de los archivos que más recientemente han sido pedidos. El navegador del cliente realiza una conexión TCP con el proxy y le manda una petición HTTP. Si el proxy dispone del objeto, se lo envía como respuesta. Si no dispone de él, abrirá una nueva conexión TCP contra el servidor original para solicitarle el objeto. Una vez que lo ha recibido, se lo reenvía al cliente por la primera conexión, manteniendo una copia por si hay más peticiones similares. Así pues, un proxy (o cache) es a la vez servidor y cliente.
Generalmente, cuando introducimos una URL en nuestro navegador, la petición se redirige al proxy o cache del ISP con quien tengamos contratada la conexión. La cache permite reducir el tiempo de respuesta (si dispone del objeto), ya que generalmente la conexión entre el cliente y la cache del ISP es de alta velocidad. Además, permite reducir el tráfico de Internet, lo cual ahorra costes a las instituciones y se mejora el rendimiento de todas las aplicaciones. Además, la jerarquía de caches permite una distribución rápida de contenidos.
Pero veamos un ejemplo: la figura 2.28 muestra una red que está conectada a Internet. Los servidores de origen están distribuidos por todo el mundo. El enlace que conecta ambas redes tiene una tasa de 1.5 Mbps. La tasa media de peticiones de los clientes a los servidores de origen será de 15 por segundo. El retardo Internet (desde que envía la petición hasta que recibe la respuesta) será de 2 segundos. El tamaño medio de los objetos será de 100.000 bits.
Así pues, la intensidad de tráfico en la LAN (vimos este concepto en el capítulo 1) es el siguiente: (15 peticiones/seg) ∙ (100 kbits/petición) / (10Mbps) = 0.15
Y la intensidad de tráfico en el enlace de acceso (entre los dos routers) es de (15 peticiones/seg) ∙ (100 kbits/petición) / (1.5Mbps) = 1
Se puede ver claramente la diferencia de intensidades en ambos lugares. El tiempo de respuesta medio puede crecer rápidamente. Podría solucionarse aumentando la tasa de acceso en el enlace de acceso, pero sería demasiado costoso.
Otra solución es utilizar una cache dentro de la red institucional (figura 2.29). Generalmente, las tasas de acierto de la cache están entre 0.2 y 0.7. Supongamos en este caso que es 0.4. El 40% de las peticiones se podrán servir en 10 ms. Así pues, la intensidad de tráfico en Internet se reduciría de 1 a 0.6.
Por tanto, el retardo medio es: 0.4 ∙ (0.01 segundos) + 0.6 ∙ (2.01 segundos) = 1.2 segundos.
El coste de comprar e instalar la cache es mucho más barato (puede instalarse sobre PC’s baratos) que aumentar la tasa del enlace de acceso.
Cache cooperativa
Las caches pueden cooperar entre sí para mejorar el rendimiento. Si la cache local no dispone del objeto, puede reenviar la petición a la cache del ISP, que le responderá con el objeto si lo tiene; y si no, consultará al servidor de origen. Además, la cache local hará una copia del objeto cuando pase por ella. Una cache de alto nivel suele tener una gran tasa de aciertos, debido a que es usada por muchos usuarios.
Un ejemplo es Janet Web Cache Service (JWCS).
Alternativamente, se puede tener un grupo de caches en una misma LAN, cuando una única no pueda llevar todo el tráfico. Para que el cliente sepa a qué cache debe solicitar el objeto, se usa un rutado por dispersión.
Redes de distribución de contenidos (CDN)
Se hicieron populares a finales de los 90’s. Las compañías CDN instala cientos de servidores CDN por Internet, en los cuales se replica los contenidos de sus clientes (empresas que contratan los servicios de estas compañías), manteniendo las réplicas actualizadas ante las actualizaciones que haga el cliente (nótese que hablamos de cliente como empresa, no como host). Cuando un usuario solicite un objeto, se lo servirá el servidor CDN que más rápido pueda hacerlo (más cercanía, menos congestión…).
Muchas compañías independientes, como Yahoo!, utilizan este servicio. Cuando el cliente actualiza un contenido, un nodo de distribución envía la actualización a los servidores CND (figura 2.30).
Cuando el proveedor de contenidos recibe la petición de un objeto que debería servirse desde un CDN, envía, en la respuesta, la referencia adecuada al servidor al que tiene que consultar. El cliente (navegador) consulta al servidor DNS acerca de la nueva URL y, acto seguido, solicita el objeto al servidor CND indicado.
Las compañías CND almacenan para cada ISP qué servidor es el mejor, basándose en el conocimiento de las tablas de rutado en Internet (BGP).
Compartición de archivos entre iguales
Un usuario puede recuperar información de otro PC de la red. Esta es la base de las llamadas redes P2P (Peer To Peer).
Cuando un usuario busca un archivo en estas redes, se le muestra una lista de iguales (otros PC’s que en ese momento están conectados a la red) que disponen de dicho archivo. Cada registro de esta lista puede ir acompañado de otra información, como por ejemplo el ancho de banda de acceso. Cuando selecciona un igual, se establece una conexión TCP por la que se transmite el fichero. Si el que hace de proveedor se desconecta, el software P2P puede buscar otro igual del que seguir descargando el fichero.
A la vez que un equipo descarga archivos, puede servir los suyos propios. Es decir, todos los iguales son simultáneamente consumidores y proveedores (distribuidores) de contenidos.
Estas redes no utilizan terceros (servidores cache, servidores de origen…), sino que el archivo se transfiere de forma directa. Estas redes son escalables, ya que aprovechan los recursos de todos los
iguales conectados (a veces, millones). Sin embargo, podría considerarse como tercero a otro cliente (es decir, Pedro descarga un mp3 de Juan pero yo, a la vez, lo voy descargando del equipo de Pedro). Vamos a ver 3 arquitecturas para que un igual pueda conocer las direcciones IP de aquellos iguales que contienen el objeto deseado (teniendo en cuenta que se conectan y desconectan con frecuencia).
Directorio centralizado
Napster fue la primera compañía que ofreció un servicio de distribución de MP3 de igual a igual a gran escala. Su arquitectura se basa en un servidor central que contenía un directorio de contenidos actualizado.
Cuando un igual se conecta, envía al servidor una lista actualizada de los objetos que puede compartir, que se añade a una BBDD en el servidor que relaciona cada objeto con un conjunto de direcciones. Los iguales envían información actualizada cada vez que hay cambios (nuevos archivos o se borran). Además, el servidor puede reconocer cuándo un igual se desconecta, para actualizar el conjunto de IP’s disponibles. Para ello, puede mandar mensajes periódicos (si no responde, se ha desconectado) o mantener una conexión TCP para cada igual, que se cerrará cuando se desconecte).
Pero tiene inconvenientes: si el servidor falla, falla toda la red. Además, supone un cuello de botella debido a la gran cantidad de información que tiene que pasar por ese punto. Además, está el tema del
copyright. Un directorio centralizado es más fácil de detener por motivos del copyright que uno descentralizado.
Directorio descentralizado
Cierto número de iguales son nombrados líderes de grupo; es decir, harán las veces de directorio. Cuando se conecta un igual, envía al líder del grupo el listado de objetos (igual que vimos antes), que la guarda en una BBDD, manteniendo información sólo de las conexiones de su grupo.
Estas redes lógicas de cada grupo se denominan redes de superposición. En estas redes existe un arco entre cada igual y el líder del grupo. Y también hay un arco entre cada par de líderes. Estos enlaces no son físicos, sino virtuales.
En el sistema P2P existe uno o más nodos de arranque, con los cuales contacta un terminal nuevo que quiere incorporarse. El nodo de arranque le responde con la IP del grupo, para establecer un arco entre dicho líder y el nuevo terminal.
De esta forma, no se centraliza la BBDD en un servidor dedicado, sino que está distribuida. Cada líder hace un seguimiento de la información de su grupo. Además, es más complicado paralizar la red de esta forma.
Sin embargo, tiene sus inconvenientes. El protocolo necesario para construir y mantener las redes de superposición es bastante complejo. Si un líder se desconecta, el resto de los nodos deben ser asignados a otros líderes. Debido a la carga y responsabilidad que recaen en los líderes, éstos pueden suponer cuellos de botella. Además, aún no es completamente un sistema sin servidor, ya que los nodos de arranque deben estar siempre activos.
Inundación de consultas
Es característica de la aplicación de compartición de archivos P2P Gnutella. En esta caso, no existen líderes, aunque sigue habiendo una organización en redes de superposición. Un terminal se accede a la misma red igual que antes, pero la IP que recibe para conectarse es cualquiera de los iguales de la red (proporcionada, igualmente, por un nodo de arranque).
Para solicitar un archivo, un nodo envía por inundación de consultas su consulta a todos sus vecinos de la red. Cada uno de estos reenvía la consulta también por inundación. Si un nodo posee el archivo, envía una respuesta al que la solicitó.
Aquí, todos los iguales tienen la misma carga y, al no haber ninguna BBDD, se simplifica el sistema. Sin embargo, existe un gran tráfico de consultas, con lo que se suele limitar el número de saltos que puede dar la consulta, aunque esta medida disminuye las posibilidades de encontrar el nodo adecuado. Las aplicaciones P2P, junto con la Web y la mensajería instantánea; son las aplicaciones que más aceptación y difusión han tenido. Otras aplicaciones, como la conferencia multimedia o la retransmisión de multimedia, están difundidas a una escala mucho menor.
