Clase 20 Capa de Aplicacion v.1

Capa de Aplicación

Copyright 1996-2002.J.F Kurose y K.W. Ross.Todos los derechos reservados.

Redes de computadores: un enfoque descendente basado en Internet, 2ª edición.Jim Kurose, Keith Ross

Capa de aplicaciónNuestros objetivos: Aspectos

conceptuales y de implementación de los protocolos de las aplicaciones de red. Modelos de servicio

de la capa de transportes

Paradigma cliente-servidor.

Paradigma entre iguales (peer to peer).

Aprendizaje de protocolos por medio del estudio de protocolos a nivel de aplicación. HTTP. FTP. SMTP / POP3 / IMAP. DNS.

Programación de aplicaciones de red. Socket de API.

Tabla de contenidos

2.1 Principios de los protocolos de la capa de aplicación.

2.2 La Web y HTTP. 2.3 Transferencia de

archivos: FTP. 2.4 Correo

electrónico en Internet. SMTP, POP3, IMAP.

2.5 DNS: el servicio de directorio de Internet.

2.6 Programación de sockets con TCP.

2.7 Programación de sockets con UDP.

2.8 Construcción de un servidor web sencillo.

2.9 Distribución de contenidos: Caché web. Redes de distribución de

contenidos. Compartición de archivos

entre iguales.

Aplicaciones de red: jerga

Proceso: programa que se ejecuta en un host.

En el mismo host, dos procesos se comunican utilizando comunicación interproceso (definidos por un sistema operativo).

Los procesos que se ejecutan en diferentes hosts se comunican con un protocolo de capa de aplicación.

Agentes de usuario: interfaces con un usuario “por encima” y una red “por debajo”.

Implementa interfaces de usuario y protocolos a nivel de aplicación. Web: navegador. Correo electrónico:

lector de correo. Transmisión de

audio/vídeo: reproductor multimedia.

Aplicaciones y protocolos de la capa de aplicaciónAplicación: comunicación,

procesos distributivos. Por ejemplo: correo electrónico,

web, compartición de archivos entre iguales, mensajería instantánea.

Funcionamiento en sistemas finales (hosts).

Intercambio de mensajes para la implementación de aplicaciones.

Protocolos de capa de aplicación Una “parte” de la aplicación. Definición de mensajes

intercambiados entre las aplicaciones y las acciones tomadas.

Uso de servicios de comunicación proporcionados por los protocolos de capas inferiores (TCP, UDP).

Aplicación

TransporteRed

Enlace de datos

Física

Aplicación

TransporteRed

Enlace de datos

Física

Aplicación

TransporteRed

Enlace de datos

Física

Características de los protocolos de capa de aplicación Los tipos de mensajes

intercambiados, por ejemplo, mensajes de petición y de respuesta.

Sintaxis de los tipos de mensajes: qué campos hay en los mensajes y cómo están delineados estos campos.

Semántica de los campos, por ejemplo, significado de la información en los campos.

Reglas que determinan cuándo y cómo los procesos envían y responden a los mensajes.

Protocolos de dominio público:

Definidos en RFC. Permiten

interoperabilidad. Por ejemplo: HTTP,

SMTP.Protocolos de

propietarios: Por ejemplo:

KaZaA,ARES, LimeWire.

Paradigma del cliente-servidorLa aplicación de red típicamente

tiene dos partes: el cliente y el servidor

Aplicación

TransporteRed

Enlace de datos

Física

Aplicación

TransporteRed

Enlace de datos

Física

Cliente: Inicia el contacto con el servidor

(“habla primero”). Normalmente solicita un servicio

del servidor. Web: cliente implementado en

el navegador; correo electrónico: en el lector de correo.Servidor:

Proporciona el servicio solicitado al cliente.

Por ejemplo, el servidor de Web envía la página Web solicitada, el servidor de correo entrega el correo electrónico.

Petición

Respuesta

Procesos que se comunican a través de la red

El proceso envía/recibe mensajes a/de su socket.

El socket es análogo a una puerta: El proceso emisor empuja el

mensaje por su puerta. Este proceso asume la

existencia de una infraestructura de transporte al otro lado de la puerta que transportará el mensaje al socket en el proceso receptor.

Socket: interfeaz entre el proceso de aplicación y la capa de transporte

proceso

TCP con búferes,variables

socket

Host o servidor

proceso

TCP conbúferes,variables

socket

Host o servidor

Internet

controlado por el sistema operativo

controlado porel desarrollador de la aplicación

Tambien se le denomina API: (1) elección del protocolo de transporte; (2) posibilidad de fijar algunos parámetros.

Direccionamiento de procesos: Para que un proceso

reciba mensajes debe tener un identificador.

Cada host tiene una única dirección IP de 32 bits.

Pregunta: ¿Basta con la dirección IP del host, en el que el proceso se ejecuta, para identificar el proceso?

Respuesta: No, ya que muchos procesos diferentes pueden estar ejecutándose en el mismo host.

El identificador incluye tanto la dirección IP como los números de puerto asociados con el proceso del host.

Ejemplos de números de puerto: Servidor HTTP: 80. Servidor de correo: 25. Telnet : 23. FTP: 20.

Más adelante se tratará este tema con más profundidad.

¿Qué servicio de transporte necesita una aplicación?Pérdida de datos Ciertas aplicaciones (por

ejemplo, audio) pueden tolerar algunas pérdidas.

Otras aplicaciones (por ejemplo, transferencia de archivos, Telnet) requieren el 100 por ciento de transferencia fiable de datos.

Temporización Algunas aplicaciones

(por ejemplo, telefonía de Internet, juegos interactivos) requieren un retardo lento para ser “efectivas”.

Ancho de banda Algunas aplicaciones

(por ejemplo, multimedia) requieren un mínimo de ancho de banda para ser “efectivas”.

Otras aplicaciones (“aplicaciones flexibles”) hacen uso de cualquier ancho de banda que tengan a su disposición.

Requisitos de los servicios de transporte para aplicaciones comunes

Aplicación

Transferencia de archivos

Correo electrónicoDocumentos Web

Audio/vídeo de tiempo real

Audio/vídeo almacenado

Juegos interactivosMensajería instantánea

Pérdida de datos

No pérdidaNo pérdidaNo pérdidaTolerante

ToleranteTolerante

No pérdida

Ancho de banda

flexibleflexibleflexibleAudio: 5Kbps-1MbpsVídeo:10Kbps-5MbpsIgual que el anteriorPocos Kbps-10KbpsFlexible

Sensible al tiempo

NoNoNoSí, 100 mseg

Sí, pocos segSí, 100 msegSí y no

Servicios de los protocolos de transporte de Internet

Servicio TCP: Orientado a la conexión:

Sistema requerido entre el cliente y el servidor.

Transporte fiable entre el proceso emisor y el receptor.

Control de flujo: el emisor no debe sobrecargar al receptor.

Control de congestión: regulación del emisor si la red se sobrecarga.

No proporciona: temporización, garantías de un ancho de banda mínimo.

Servicio UDP: Transferencia de datos

no fiable entre el proceso emisor y el receptor.

No proporciona: sistema de conexión, fiabilidad, control de flujo, control de congestión, temporización y garantía de ancho de banda.

PREGUNTA: ¿Por qué tomarse la molestia? ¿Por qué existe un UDP?

Aplicaciones de Internet: aplicación, protocolos de transporte

Aplicaciones

Correo electrónicoAcceso a terminales remotos

Web Transferencia de archivos

Flujo de multimedia

Telefonía Internet

Protocolo de la capa de aplicación

SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]Propietario(por ejemplo, Real Networks)Propietario(por ejemplo, Dialpad, xLite)

Protocolo de ransporte subyacente

TCPTCPTCPTCP

TCP o UDP

Típicamente UDP

Capítulo 2: Tabla de contenidos 2.1 Principios de los

protocolos de la capa de aplicación.










entre iguales.

La Web y HTTPEn primer lugar, un poco de jerga Una página web consta de objectos. Un objeto puede ser un archivo HTML, una

imagen JPEG,un applet Java, un archivo de audio, etc.

Una página web está formada por un archivo HTML base, que incluye diversos objetos referenciados.

Cada objeto es direccionable por un URL. Ejemplo de URL:www.escuela.edu/departamento/imagen.gif

nombre de host nombre de ruta

Introducción a HTTPHTTP: protocolo de

transferencia de hipertexto:

Protocolo de la capa de aplicación de la Web.

Modelo cliente/servidor: cliente: navegador que

solicita, recibe y “descarga” objetos Web.

servidor: servidor Web que envía los objetos correspondientes en respuesta a las peticiones.

HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068

PC ejecutandoel Explorer

Servidor ejecutando

el servidor Web Apache

Mac ejecutando el Navigator

Petición HTTP

Petición HTTP

Respuesta HTTP

Respuesta HTTP

Introducción a HTTP

Usos de TCP: El cliente inicia la

conexión TCP (crea un socket) al servidor, puerto 80.

El servidor accepta la conexión TCP del cliente.

Los mensajes HTTP (mensajes de protocolo de la capa de aplicación) intercambiados entre el navegador ( cliente HTTP) y el servidor Web (servidor HTTP)

La conexión TCP se cierra.

HTTP está “sin estado” El servidor no conserva

ninguna información sobre las peticiones previas de clientes.

Los protocolos que conservan “estado” son complicados

La historia previa (estado) debe conservarse.

Si el servidor/cliente se bloquea, sus visiones del “estado” pueden ser inconsistentes y deben ser recompuestas.

aparte

Conexiones HTTP

Conexiones HTTP no persistentes

Se envía un objeto como máximo con una conexión TCP.

HTTP/1.0 utiliza conexiones HTTP no persistentes.

Conexiones HTTP persistentes

Se pueden enviar múltiples objetos con una sola conexión TCP entre el cliente y el servidor.

HTTP/1.1 utiliza conexiones persistentes en su modo por defecto.


Supongamos que el usuario entra en el URL: www.escuela.edu/departamento/home.index

1a. El cliente HTTP inicia la conexión TCP con el servidor HTTP (proceso) de www.escuela.edu en el puerto 80.

2. El cliente HTTP envía un mensaje HTTP de petición (que contiene el URL) a través del socket de la conexión TCP. El mensaje indica que el cliente quiere el objeto departamento/home.index.

1b. El servidor HTTP en el host www.escuela.edu espera la conexión TCP del puerto 80 y “acepta” la conexión, notificando al cliente.

3. El servidor HTTP recibe el mensaje de petición, compone un mensaje de respuesta que contiene el objeto solicitado, y lo envía al socket.

Tiempo

(consta de texto y referencias a 10

imágenes jpeg)


5. El cliente HTTP recibe el mensaje de respuesta que contiene el archivo html y descarga el html. Analizando el archivo html, se encuentran referenciados 10 objetos jpeg.

6. Se repiten los pasos del 1 al 5 para cada uno de los 10 objetos jpeg.

4. El servidor HTTP cierra la conexión TCP.

Tiempo

Modelo del tiempo de respuesta

Definición de RRT: tiempo necesario para enviar un paquete pequeño desde el cliente hasta el servidor y después de vuelta al cliente.

Tiempo de respuesta: Un RTT para iniciar la

conexión TCP. Un RTT para la petición HTTP

y los primeros bytes de respuesta HTTP de vuelta.

Tiempo de transmisión del archivo:

total = 2RTT+tiempo de transmisión

Tiempo de transmisión del archivo

Inicio de la conexión TCP RTT

Petición de archivo

RTT

Archivo recibido

Tiempo Tiempo

Conexiones HTTP persistentesParticularidades de HTTP no

persistente: Requieren dos RTT por objeto. El sistema operativo debe

funcionar y asignar los recursos del host para cada conexión TCP.

Sin embargo, los navegadores suelen abrir conexiones TCP paralelas para traer los objetos referenciados.

HTTP persistente: El servidor deja la conexión

abierta tras enviar la respuesta.

Los mensajes HTTP posteriores entre el mismo cliente/servidor se envían por la misma conexión.

Conexiones persistentes sin entubamiento:

El cliente sólo emite una nueva petición una vez que ha recibido la anterior respuesta.

Un RTT por cada objeto referenciado.

Conexiones persistentes con entubamiento:

Por defecto en HTTP/1.1 El cliente hace su petición

tan pronto como encuentra un objeto referenciado.

Tan sólo un RTT para todos los objetos referenciados.

Mensaje HTTP de petición

Hay dos tipos de mensajes HTTP: de petición, de respuesta.

Mensaje HTTP de petición: ASCII (formato leído por personas )

GET /dir/pagina.html HTTP/1.1Host: www.escuela.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr

(Retorno de carro extra, avance de línea)

Línea de petición(GET, POST,

comandos HEAD)

Líneas de cabecera

Retorno de carro y avance de línea

que indican el final del mensaje

Mensaje HTTP de petición: formato general

Línea de petición

Cuerpo de entidad

Líneas de cabecera

método

versiónLínea de petición

valor

valor

Nombre del campo de cabecera

Nombre del campo de cabecera

Descarga de la entrada de formulario

Método POST: La página Web suele

incluir una entrada de formulario.

La entrada se descarga al servidor en el cuerpo de entidad.

Método URL: Utiliza el método GET. La entrada se descarga

en el campo URL de la línea de petición:

www.somesite.com/animalsearch?monkeys&banana

Tipos de métodos

HTTP/1.0 GET. POST. HEAD.

Pide al servidor que excluya el objeto solicitado de la respuesta.

HTTP/1.1 GET, POST, HEAD. PUT:

Descarga el archivo en el cuerpo de entidad a la ruta especificada en el campo URL.

DELETE: Borra el archivo

especificado en el campo URL.

Mensaje HTTP de respuesta

HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html datos datos datos datos datos ...

Línea de estatus(protocolo del

código de estatusy la frase

de estatus)

Líneas de cabecera

Datos, por ejemplo, el archivo

HTML solicitado

Código de estatus HTTP de respuesta

200 OK petición exitosa, el objeto requerido aparece

posteriormente en este mensaje.

301 Moved Permanently el objeto demandado ha sido movido, su nueva

localización se especifica posteriormente en este mensaje (Location:).

400 Bad Request el servidor no comprendió el mensaje de petición.

404 Not Found el documento pedido no existe en este servidor.

505 HTTP Version Not Supported

En la primera línea en el mensaje de respuesta servidor -> cliente.

Algunos ejemplos de códigos:

Ponga a prueba el HTTP (como cliente) usted mismo

1. Telnet a su servidor web favorito:

Abre la conexión TCP al puerto 80.(por defecto puerto servidor HTTP) en www.eurecom.fr.Cualquier cosa que se escriba es enviada a www.eurecom.fr

telnet www.eurecom.fr 80

2. Escriba una petición HTTP tipo GET:

GET /~ross/index.html HTTP/1.0Escribiendo esto (con doble retorno de carro), está enviando esta petición GET mínima (pero completa) al servidorHTTP.

3. Mire el mensaje de respuesta enviado por el servidor HTTP.

Interacción usuario-servidor: autorización

Autorización : control al acceso del contenido del servidor.

Credenciales de autorización, normalmente son: nombre, contraseña.

Sin estado: el cliente debe presentar la autorización para cada petición: Autorización: línea de

cabecera en cada petición. Si no hay autorización:

cabecera, el servidor rechaza el acceso y envíaWWW authenticate: línea de cabecera en

respuesta.

cliente servidorTípico mensaje http de petición

401: autorización solic.WWW authenticate:

Típico mensaje http de petición

+ Autorización: <cred>

Típico mensaje de respuesta

Típico mensaje http de petición + Autorización: <cred>

Típico mensaje de respuesta

Tiempo

Cookies: mantenimiento del “estado”Muchos sitios web importantes

utilizan cookies.Cuatro componentes:

1) Línea de cabecera de cookie en el mensaje HTTP de respuesta.

2) Línea de cabecera de cookie en el mensaje HTTP de petición.

3) Archivo de cookie que se almacena en el host del usuario y que es gestionado por el navegador del usuario.

4) Base de datos de respaldo en el sitio Web.

Ejemplo: Susana siempre

accede a Internet desde el mismo PC.

Visita un sitio de comercio electrónico por primera vez.

Cuando la petición HTTP inicial llega al sitio, éste crea un número de identificación único y también crea en su base de datos una entrada indexada por el número de identificación.

Cookies: mantenimiento del “estado”

cliente servidorTípico msj http de petición

Típico mensaje de respuesta +

Set-cookie: 1678


cookie: 1678Típico mensaje de

respuesta


cookie: 1678Típico mensaje de

respuesta

Acción específica

cookie

Acciónespecífica

cookie

el servidorcrea un númerode identificación

1678 para el usuario

entrada en la base

de datos de respaldo

acceso

acce

so

Archivo de cookie

amazon: 1678ebay: 8734

Archivo de cookie

ebay: 8734

Archivo de cookie

amazon: 1678ebay: 8734

una semana más tarde:

Cookies

Qué aportan las cookies:

Autorización. Carro de la compra. Recomendaciones. Sesión de usuario

con estado (correo electrónico web)

Cookies y privacidad: Las cookies permiten que

los sitios sepan mucho sobre usted.

Puede proporcionar su nombre y correo electrónico a los sitios.

Los motores de búsqueda utilizan el redirección y las cookies para saber aún más.

Las empresas de publicidad consiguen información a través de los sitios.

aparte

GET condicional: caché por parte del cliente

Objetivo: no enviar objetos si el cliente tiene una versión caché actualizada.

Cliente: especifica la fecha de la copia en caché en la petición HTTP:If-modified-since:

<date> Servidor: su respuesta no

contiene ningún objeto si la copia en caché está actualizada: HTTP/1.0 304 Not

Modified

cliente servidor

mensaje HTTP de petición

If-modified-since: <date>

respuesta HTTP HTTP/1.0

304 Not Modified

objeto no

modificado

mensaje HTTP de petición

If-modified-since: <date>

respuesta HTTPHTTP/1.0 200 OK

<data>

objeto modificado

Capítulo 2:Tabla de contenidos 2.1 Principios de los








2.8 Construcción de un servidor de web sencillo.



entre iguales.

Servidor FTP

Interfaz de

usuario FTP

Cliente FTP

FTP: El protocolo de transferencia de archivos

Transferencia de archivo a/desde un host remoto. Modelo cliente/servidor:

Cliente: es el que inicia la tranferencia (bien a o desde el host remoto).

Servidor: host remoto. FTP: RFC 959. Servidor FTP: puerto 21.

Transferencia de archivo

Sistema local de archivos

Sistema remoto de archivos

usuario o host

FTP: control separado, conexiones de datos

El cliente FTP contacta con el servidor FTP en el puerto 21, especificando el TCP como protocolo de transporte.

El cliente consigue la autorización sobre la conexión de control.

El cliente navega por el directorio remoto enviando comandos sobre la conexión de control.

Cuando el servidor recibe un comando para la transferencia de archivos, el servidor abre la conexión TCP de datos con el cliente.

Después de transferir un archivo, el servidor cierra la conexión.

Cliente FTP

ServidorFTP

Conexión TCP de control sobre el puerto

21

Conexión TCP de control sobre el puerto

20

El servidor abre una segunda conexión FTP de datos para transferir otro archivo.

Conexión de control: “fuera de banda”

El servidor FTP mantiene el “estado”: directorio actual, autentificación anterior.

Comandos y respuestas FTP Ejemplo de comandos: Enviado como texto ASCII

por el canal de control. USER nombre del

usuario. PASS palabra clave. LIST devuelve la lista del

archivo al directorio en curso.

RETR nombre de archivo recupera el archivo.

STOR nombre de archivo almacena el archivo en el host remoto.

Ejemplo de códigos de respuesta:

Códigos de estatus y frase (como en HTTP).

331 Username OK, password required

125 data connection already open; transfer starting

425 Can’t open data connection

452 Error writing file










2.9 Distribución de contenidos: Caché Web. Redes de distribución de


entre iguales.

Correo electrónicoLos tres componentes

principales: Agentes de usuario. Servidores de correo. Protocolo simple de

transferencia de correo: SMTP.

Agente usuario También conocido como

“lector de correo”. Composición, edición y lectura

de mensajes de correo. Por ejemplo, Eudora, Outlook,

elm, Netscape Messenger. Salida y entrada del los

mensajes almacenados en el servidor.

Buzón de correo de usuario

Cola de mensajes de salida

servidor de correo

agente de usuario

SMTP

SMTP

SMTP

agente de usuario

agente de usuario

agente de usuario

agente de usuario

agente de usuario

servidor de correo

servidor de correo

Correo electrónico: servidores de correo

Servidores de correo: Buzón de correo: contiene

los mensajes de entrada del usuario.

Cola de mensajes: mensajes de correo de salida (para ser enviados).

Protocolo SMTP: entre servidores para mandar mensajes de correo electrónico. Cliente: envía correo al

servidor. “Servidor”: recibe

correo de otro servidor.

SMTP

SMTP

SMTP

agente de usuario

agente de usuario

servidor de correo

servidor de correo

servidor de correo

agente de usuario

agente de usuario

agente de usuario

agente de usuario

Correo electrónico: SMTP [RFC 2821]

Utiliza TCP para transferir con seguridad el mensaje de correo electrónico del cliente al servidor, puerto 25.

Transferencia directa: del servidor que envía al servidor que recibe.

Las tres fases de la transferencia son: “Acuerdo” (saludo). Transferencia de mensajes. Cierre.

Interacción comando/respuesta: Comandos: texto ASCII. Respuesta: código de estatus y frase.

Los mensajes deben tener siete bits en ASCII.

servidor de correo

servidor de correo

Ejemplo: Alicia le envía un mensaje a Roberto

1) Alicia utiliza su agente usuario para componer el mensaje “a” [email protected]

2) El agente de usuario de Alicia envía un mensaje a su servidor de correo; y el mensaje es ubicado en la cola de mensajes.

3) El lado cliente del SMTP abre una conexión TCP con el servidor de correo de Roberto.

4) El cliente SMTP envía el mensaje de Alicia sobre la conexión TCP.

5) El servidor de correo de Roberto deposita el mensaje en el buzón de correo de Roberto.

6) Roberto recurre a su agente de usuario para leer el mensaje.

1

2 3 4 56agente

de usuario

agente de usuario

Ejemplo de interacción SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: ¿Te gusta el ketchup? C: ¿Y los encurtidos? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection

Ponga a prueba la interacción SMTP por usted mismo:

Telnet nombreServidor 25. Mire la respuesta 220 del servidor. Introduzca los comandos HELO, MAIL FROM,

RCPT TO, DATA, QUIT. Lo arriba mencionado le permite enviar el correo

electrónico sin utilizar el cliente de correo electrónico (lector).

SMTP: últimos comentarios

SMTP utiliza conexiones persistentes.

SMTP requiere que el mensaje (cabecera y cuerpo) esté contenido en siete bits de ASCII.

El servidor SMTP utiliza CRLF.CRLF para determinar el final del mensaje.

Comparación con HTTP: HTTP: demanda. SMTP: oferta.

Ambos utilizan interacción ASCII comando/respuesta y códigos de estatus.

HTTP: encapsula cada objeto en su propio mensaje de respuesta.

SMTP: envía múltiples objetos en mensajes multipart.

Formato de los mensajes de correoSMTP: protocolo para

intercambiar mensajes de correo electrónico.

RFC 822: estándar para el formato de texto del mensaje:

Líneas de cabecera, por ejemplo: Para: De: Asunto:diferentes de los comandos

SMTP Cuerpo:

el “mensaje”, sólo caracteres ASCII.

cabecera

cuerpo

Línea en blanco

Formato del mensaje: extensiones multimedia

MIME: extensiones de correo multimedia, RFC 2045, 2056

Las líneas adicionales en la cabecera del mensaje declaran el tipo de contenido MIME.

From: [email protected] To: [email protected] Subject: Imagen de un delicioso crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

datos codificados base64........ ....................…........... .... datos codificados base64

Datos multimediatipo, subtipo,

declaración de parámetros

Método utilizadode datos codificados

Versión MIME

Datos codificados

Tipos de MIME Content-Type: tipo/subtipo; parametros

Texto Ejemplos de subtipos:

plain, html

Imagen Ejemplos de subtipos:

jpeg, gif

Audio Ejemplos de subtipos:

basic (codificados en ocho bits mu-law), 32kadpcm (32 kbps codificado).

Vídeo Ejemplos de subtipos:

mpeg, quicktime

Aplicación Otros datos que deben

ser procesados por el lector antes de ser “visionados”.

Ejemplos de subtipos: msword, octet-stream

Tipo multipart

From: [email protected] To: [email protected] Subject: Imagen de un delicioso crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPartQuerido Roberto, Te envío una imagen de un crepe.--StartOfNextPartContent-Transfer-Encoding: base64Content-Type: image/jpegdatos codificados base64 ..... ......................... ...…datos codificados base64 --StartOfNextPartDime si quieres tener la receta

Servidor de correodel emisor

Protocolos de acceso al correo

SMTP: envío/almacenamiento a/en el servidor del destinatario. Protocolo de acceso al correo: recuperación desde el servidor.

POP: Protocolo de Oficina Postal [RFC 1939]• Autorización (agente <-->servidor) y descarga.

IMAP: Protocolo de Acceso al Correo Internet [RFC 1730]• Más características (más complejo).• Manipulación de los mensajes almacenados en el servidor.

HTTP: Hotmail , Yahoo! Mail, etc.

SMTP SMTP Protocolo de acceso

Servidor de correodel destinatario

Agente de usuario

Agente de usuario

Protocolo POP3Fase de autorización Comandos del cliente:

user: declaración del nombre de usuario.

pass: contraseña. Respuestas del servidor:

+OK -ERR

Fase de transacción, cliente: list: enumera los números

de mensaje. retr: recupera un mensaje

determinado por su número. dele: borra. quit

C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off

S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

POP3 e IMAPMás información sobre

POP3: El ejemplo anterior

utiliza el modo “descargar y borrar”.

Roberto no puede volver a leer el correo electrónico si cambia de cliente.

“Descargar y guardar”: copias de mensajes en diferentes clientes.

POP3 está sin estado entre sesiones.

IMAP: Guarda todos los

mensajes en un mismo lugar: el servidor.

Permite al usuario organizar sus mensajes en carpetas.

IMAP mantiene el estado de usuario entre sesiones: Los nombres de las

carpetas y la correspondencia entre los números de identificación de los mensajes y el nombre de la carpeta.









2.8 Construcción de un servidor web Sencillo.



entre iguales.

DNS: sistema de nombres de dominio

Personas: muchos identificadores: SSN, nombre, pasaporte

#

Hosts de Internet, routers: Dirección IP (32 bits) -

utilizada para direccionar datagramas.

“Nombre”, por ejemplo, gaia.cs.umass.edu - utilizado por personas.

Pregunta: ¿Existe una correspondencia entre direcciones IP y nombres?

Sistema de nombres de dominio:

Base de datos distribuida: implementada en jerarquía de muchos servidores de nombre.

Protocolo de capa de aplicación: host, routers, servidores de nombre comunicándose para resolver nombres (direcciones/traducción de nombres). Nota: función esencial de

Internet, implementada como protocolo de capa de aplicación.

Complejidad en el “límite” de la red.

Servidores de nombre DNS Ningún servidor contiene

todas las correspondencias para direccionar los nombres IP.

Servidores de nombre locales: Cada ISP, cada empresa tiene un

servidor de nombre local (por defecto).

La pregunta del host DNS primero va al servidor de nombre local.

Servidor autorizado de nombre: Para un host: almacena la

dirección IP de ese host y el nombre.

Puede representar la traducción del nombre/dirección para el nombre de ese host.

¿Por qué no centralizar el DNS ?

Único punto de fallo. Volumen de tráfico. Base de datos

distanciada centralizada.

Mantenimiento.

No es escalable.

DNS: servidores raíz de nombres. Contactados por los servidores de nombre locales que no pueden

resolver un nombre. Servidores de raíz de nombres:

Contacta el servidor autorizado de nombre si la correspondencia del nombre no se conoce.

Obtiene correspondencia. Devuelve la correspondencia al servidor de nombre local.

b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA

e NASA Mt View, CAf Internet Software C. Palo Alto, CA

i NORDUnet Stockholm

k RIPE London

m WIDE Tokyo

a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA

Los 13 servidores de raíz de nombres del mundo

Ejemplo sencillo de DNS

host surf.eurecom.fr quiere la dirección IP de gaia.cs.umass.edu

1. Contacta con su servidor DNS local, dns.eurecom.fr.

2. dns.eurecom.fr contacta con el servidor raíz de nombres, si es necesario.

3. El servidor raíz de nombres contacta con el servidor autorizado de nombres, dns.umass.edu, si es necesario.

Host peticionariosurf.eurecom.fr

gaia.cs.umass.edu

servidor raíz de nombres

Servidor autorizado de nombres

dns.umass.edu

servidor local de nombres

dns.eurecom.fr

1

23

4

5

6

Ejemplo DNS

Servidor raíz de nombres:

Puede que no conozca el servidor autorizado de nombres.

Puede que conozca el servidor de nombres intermedio: con el que contactará para encontrar al servidor autorizado de nombres.

gaia.cs.umass.edu

1

23

4 5

6

servidor intermediode nombres

dns.umass.edu

7

8



dns.eurecom.fr



dns.umass.edu

DNS: consultas iterativas

Consulta recursiva: Pone el peso de la

resolución del nombre en el servidor de nombre contactado.

¿Demasiada responsabilidad?

Consulta iterativa: El servidor contactado

responde con el nombre al servidor que contacta.

“No conozco ese nombre, pero puedo consultar ese servidor.”

gaia.cs.umass.edu

1

23

4

5 6

7

8

Consulta iterativa



dns.eurecom.fr

servidor intermediode nombres

dns.umass.edu



dns.umass.edu

DNS: caché y actualización de registros

Una vez que un servidor de nombres (cualquiera) conoce la correspondencia, hace una copia caché. La copia caché se queda en punto muerto

(desaparece) tras un cierto tiempo. Mecanismos de actualización/notificación

bajo diseño de IETF. RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html

Registros DNSDNS: Base de datos distribuida que almacena registros de recursos (RR).

Tipo=NS nombre es un dominio (por

ejemplo foo.com). valor es la dirección IP de

un servidor de nombre autorizado para ese dominio.

Formato RR : (nombre, valor, tipo,ttl)

Tipo=A nombre es un nombre

de host. valor es la dirección

IP.

Tipo=CNAME nombre es el alias de un

nombre “canónico” (verdadero).

www.ibm.com en realidad es servereast.backup2.ibm.com valor es el nombre

canónico. Tipo=MX valor es el nombre de un

servidor de correo asociado a nombre.

Protocolo y mensajes DNSProtocolo DNS: mensajes de consulta y respuesta, ambos con el mismo

formato de mensaje.

Cabecera del mensaje: Identificación: 16 bits

para la consulta, que se repiten en la respuesta a la consulta.

Flags (señales): consulta o respuesta. recursión deseada. recursión disponible. respuesta es

autorizada.

Identificación Señales

número de cuestiones

Número de RR de respuesta

Número de RR de autorización

Número de RR

adicionales Cuestiones

(número variable de cuestiones)

Respuestas

(número variable de registros de recurso )

Autorización

(número variable de registros de recurso)

Información adicional


Protocolo y mensajes DNS

Nombre, campos de tipo para una consulta.

RR en respuestaa una consulta.

Registros paraservidores autorizados.

Información adicional“de ayuda” que puede

ser utilizada.

Identificación Señales

Número de cuestiones Número de RR de respuesta

Número de RR autorización

Número de RR adicionales

Cuestiones

(número variable de cuestiones)

Respuestas


Autorización


Información adicional

(número variable de registros de recurso )

Diagrama una Solución de DNS

April 18, 2023

ENTERPRISE 220R

500 GB HD 4 GB RAM

SUNFire V240 500 GB HD 4 GB RAM

ENTERPRISE 220R 500 GB HD 4 GB RAM

ENTERPRISE 220R 500 GB HD 4 GB RAM

SUNFire V440 500 GB HD 4 GB RAM

2 Servidores HP Proliant1T HD 8 GB RAM

2 Servidores SUNFire V240 500 GB HD 4 GB RAM2 Balanceadores Brocade ADX

1000

Capítulo 2: Tabla de Contenidos 2.1 Principios de los











entre iguales.

Programación de sockets

Socket API Introducido por BSD4.1

UNIX, 1981 Creado, utilizado y puesto en

circulación explícitamente por aplicaciones.

Paradigma cliente/servidor. Dos tipos de transporte de

servicio vía socket API: Datagrama poco fiable. Orientación del flujo de

bytes fiable.

Una interfaz controlada por un sistema

operativo, creada por una aplicación y con un

host local, (una “puerta”) por la

cual el proceso de aplicación puede tanto

enviar como recibir mensajes de otro

proceso de aplicación.

socket

Objetivo: aprender cómo se construye una aplicación cliente/servidor que se comunique utilizando sockets.

Programación de sockets usando TCPSocket: una puerta entre el proceso de aplicación

y el protocolo de transporte final (UCP o TCP).Servicio TCP: transferencia fiable de bytes de un

proceso a otro.

Proceso

TCP conbúferes yvariables

Socket

Controlado por el desarrollador de

la aplicación

Controlado por el sistema operativo

Host o servidor

Proceso

TCP conbúferes yvariables

Socket

Controlado por el desarrollador de la aplicación

Controlado por el sistema operativo

Host o servidor

Internet

Programación de sockets con TCP

El cliente debe contactar con el servidor:

El proceso del servidor en principio debe estar funcionando.

El servidor debe haber creado un socket (puerta) para dar la bienvenida al contacto del cliente.

El cliente contacta con el servidor: Creando un socket TCP local del

cliente. Especificando la dirección IP y el

número de puerto del proceso del servidor.

Cuando el cliente crea un socket: el cliente establece una conexión TCP con el servidor.

Cuando el cliente contacta con él, el servidor TCP crea un nuevo socket para que el proceso servidor se comunique con el cliente. Permite al servidor hablar

con múltiples clientes. Fuente de los números de

puerto utilizados para distinguir a los clientes (más en el Capítulo 3).

TCP propociona una transferencia de bytes en orden y fiable

(“tubería”) entre cliente y servidor.

Punto de vista de la aplicación

Jerga relacionada con el flujo

Un flujo es una secuencia de caracteres que fluye hacia o desde un proceso.

Un flujo de entrada está relacionado con una fuente de entrada del proceso, por ejemplo, el teclado o un socket.

Un flujo de salida está relacionado con una fuente de salida, por ejemplo, el monitor o un socket.

Programación de sockets con TCPEjemplo de aplicación

cliente-servidor:1) El cliente lee una línea de

su entrada estándar (flujo inFromUser) , y se la envía al servidor por su socket (flujo outToServer).

2) El servidor lee una línea en su socket.

3) El servidor convierte la línea a mayúsculas y se la envía de vuelta al cliente.

4) El cliente lee e imprime la línea modificada de su socket (flujo inFromServer).

salid

aAS

ervi

dor

Hacia la red Desde la red

entr

adaD

esde

Ser

vido

r

entr

adaD

esde

Usu

ario

Teclado Monitor

Proceso

Flujo deentrada

Flujo deentrada

Flujo desalida

SocketTCP

Proceso cliente

Socketcliente TCP

Interacción socket cliente/servidor: TCP

Esperar a la petición de conexión de entradasocketConexion=socketAcogida.accept()

crear socket,port=x, para petición de entrada:socketAcogida =

ServerSocket()

Crear socket conectado a hostid, port=x

socketCliente = Socket()

Cerrar socketConexion

Leer respuesta desocketCliente

CerrarsocketCliente

Servidor (ejecutándose en hostid) Cliente

Enviar petición utilizandosocketClienteLeer petición de

socketConexion

Escribir respuesta asocketConexion

Establecimiento de conexión TCP

Ejemplo: Cliente Java (TCP)

import java.io.*; import java.net.*; class TCPCliente {

public static void main(String argv[]) throws Exception { String frase; String fraseModificada;

BufferedReader entradaDesdeUsuario = new BufferedReader(new InputStreamReader(System.in));

Socket socketCliente = new Socket(”nombrehost", 6789);

DataOutputStream salidaAServidor = new DataOutputStream(socketCliente.getOutputStream());

Crea flujo de entrada

Crea socket cliente, conecta con

el servidor

Crea flujo de salida relacionado

con el socket

Ejemplo: Cliente Java (TCP)

BufferedReader entradaDesdeServidor = new BufferedReader(new InputStreamReader(socketCliente.getInputStream()));

frase = entradaDesdeUsuario.readLine();

salidaAServidor.writeBytes(frase + '\n');

fraseModificada= entradaDesdeServidor.readLine();

System.out.println(“DEL SERVIDOR: " + fraseModificada);

socketCliente.close(); } }

Crea un flujo de salidarelacionado con el

socket

Línea de envío al servidor

Línea de lectura del servidor

Ejemplo: Servidor Java (TCP)import java.io.*; import java.net.*;

class TCPServidor {

public static void main(String argv[]) throws Exception { String fraseCliente; String fraseMayusculas;

ServerSocket socketAcogida = new ServerSocket(6789); while(true) { Socket connectionSocket = socketAcogida.accept();

BufferedReader entradaDesdeCliente = new BufferedReader(new InputStreamReader(socketConexion.getInputStream()));

Creasocket de acogida

en puerto 6789

Espera en el socket de acogida al contacto

del cliente

Crea flujo de entrada relacionado

con el socket

Ejemplo: Servidor Java (TCP)

DataOutputStream salidaACliente= new DataOutputStream(socketConexion.getOutputStream());

fraseCliente = entradaDesdeCliente.readLine();

fraseMayusculas = fraseCliente.toUpperCase() + '\n';

salidaACliente.writeBytes(fraseMayusculas); } } }

Lee en línea desde el socket

Crea flujo de salida

relacionado con el socket

Escribe línea al socket

Acaba el bucle while y vuelve al principio del bucle a esperar otra conexión del cliente.












entre iguales.

Programación de sockets con UDPUDP: no hay “conexión” entre

el cliente y el servidor. No hay sincronización. El remitente añade

explícitamente la dirección IP y el puerto de destino a cada paquete.

El servidor debe extraer la dirección IP y el puerto del remitente del paquete recibido.

UDP: Los datos transmitidos puede que se reciban desordenados o que se pierdan.

Punto de vista de la aplicación

UDP proporciona transferencia poco fiable de grupos de bytes

(“datagramas”) entre cliente y servidor

Interacción socket cliente/servidor: UDP

CerrarsocketCliente

Servidor (ejecutándose en hostid)

Leer respuesta desocketCliente

Crear socket,socketCliente = DatagramSocket()

Cliente

Crear dirección (hostid, port=x,enviar petición de datagrama utilizando socketCliente

Crear socket,port=x, para petición de entrada:

socketServidor= DatagramSocket()

Leer petición desocketServidor

Escribir respuesta asocketServidorespecificando dirección del hostcliente, número de puerto.

Ejemplo: Cliente Java (UDP)

Paq

uete

enví

o

Hacia la red Desde la red

paqu

eteR

ecib

ido

entr

adaD

esde

Usu

ario

Teclado Monitor

Proceso

clientSocket

PaqueteUDP

Flujo de

entrada

PaqueteUDP

socketUDP

Salida: envía paquete (TCP enviado por “flujo de bytes”)

Entrada: recibe paquete (TCP recibido por “flujo de bytes”)

Proceso Cliente

Socketcliente UDP


import java.io.*; import java.net.*; class UDPCliente { public static void main(String args[]) throws Exception { BufferedReader entradaDesdeUsuario = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket socketCliente = new DatagramSocket(); InetAddress direccionIP = InetAddress.getByName(”nombrehost"); byte[] datosEnvio= new byte[1024]; byte[] datosRecepcion = new byte[1024]; String frase = entradaDesdeUsuario.readLine();

datosEnvio = frase.getBytes();

Creaflujo de entrada

Crea socket cliente

Traduce el nombre del host a una dirección

IP utilizando DNS


DatagramPacket paqueteEnvio = new DatagramPacket(datosEnvio, datosEnvio.length, DirecciónIP, 9876); socketCliente.send(paqueteEnvio); DatagramPacket paqueteRecepcion = new DatagramPacket(datosRecepcion, datosRecepcion.length); socketCliente.receive(paqueteRecepcion); String fraseModificada = new String(paqueteRecepcion.getData()); System.out.println(”DEL SERVIDOR:" + fraseModificada); socketCliente.close(); }

}

Crea datagrama con los datos para enviar,longitud, dirección IP,

puerto

Envía datagrama al servidor

Lee datagrama del servidor

Ejemplo: Servidor Java (UDP)

import java.io.*; import java.net.*; class UDPServidor { public static void main(String args[]) throws Exception { DatagramSocket socketServidor = new DatagramSocket(9876); byte[] datosRecepcion = new byte[1024]; byte[] datosEnvio = new byte[1024]; while(true) { DatagramPacket paqueteRecepcion = new DatagramPacket(datosRecepcion, datosRecepcion.length);

socketServidor.receive(paqueteRecepcion);

Creasocket datagrama

en puerto 9876

Crea espacio para datagrama recibido

Recibe datagrama

Ejemplo: Servidor Java (UDP)

String frase = new String(paqueteRecepcion.getData()); InetAddress DireccionIP = paqueteRecepcion.getAddress(); int puerto = paqueteRecepcion.getPort(); String fraseMayusculas = frase.toUpperCase();

datosEnvio = fraseMayusculas.getBytes(); DatagramPacket paqueteEnvio = new DatagramPacket(datosEnvio, datosEnvio.length, DireccionIP, puerto); socketServidor.send(paqueteEnvio); } }

}

Obtiene dirección IP y

puertodel remitente

Escribe datagramaen el socket

Acaba el bucle while y vuelve al principio del bucle a esperar otro datagrama

Crea datagramapara envíar al cliente

Construcción de un servidor Web sencillo

Maneja sólo una petición HTTP.

Acepta la petición. Analiza la cabecera. Recupera el archivo

pedido del sistema de archivos del servidor.

Crea un mensaje HTTP de respuesta: líneas de cabecera +

archivo Envía la respuesta al

cliente.

Tras crear el servidor, puede solicitar el archivo utilizando un browser (por ejemplo, el explorador Internet Explorer).

Lea el libro de texto para más información.

Programación de sockets: referencias

Tutorial de C (audio/diapositivas): “Unix Network Programming” (J. Kurose),http://manic.cs.umass.edu/~amldemo/courseware/

Tutorial de Java: “All About Sockets” (Sun tutorial),

http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html

“Socket Programming in Java: a tutorial”, http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html












entre iguales.

Caché Web (servidor proxy)

El usuario pone el navegador: accesos web vía caché.

El navegador envía todas las peticiones HTTP al caché. Objecto en caché: el

caché devuelve el objecto.

Otro caché solicita el objeto de su servidor de origen y luego devuelve el objeto al cliente.

Objetivo: satisfacer la solicitud del cliente sin involucrar al servidor de origen.

Cliente

Servidor proxy

Cliente

Petición HTTP

Petición HTTP

Respuesta HTTP

Respuesta HTTP

Petición HTTP

Respuesta HTTP

Servidor origen

Servidor origen

Más sobre el caché web El caché actúa tanto de

cliente como de servidor. El caché puede hacer

una revisión actualizada utilizando If-modified-since en la cabecera HTTP. Asunto: ¿Debería un

caché correr el riesgo de enviar objetos en caché sin revisar?

Se utiliza un método heurístico.

Normalmente, el caché se instala por ISP (universidad, empresa, ISP residencial).

¿Por qué usar caché web? Porque reduce el tiempo de

respuesta por petición del cliente.

Porque reduce el tráfico en el enlance de acceso de una institución.

Porque si Internet está poblada de cachés, permite que los proveedores “pobres” puedan efectivamente enviar contenido.

Ejemplo de cachéSupuestos Tamaño medio de los objetos =

100.000 bits. Tasa media por petición por parte

del browser de la institución a los servidores de origen = 15/seg.

Retraso del router de la institución a cualquier servidor origen y vuelta al router = 2 seg.

Consecuencias Uso del LAN = 15% Uso del enlace de acceso = 100% Retraso total = retraso de

Internet + retraso del acceso + retraso del LAN =

= 2 seg + minutos + milisegundos.

Servidores origen

Internet pública

Red institucional LAN de 10 Mbps

Enlace de acceso de 1.5 Mbps

Caché institucional

Ejemplo de caché

Solución posible Aumento del ancho de

banda del enlace de acceso a, digamos, 10 Mbps.

Consecuencias Uso del LAN = 15% Uso del enlace de acceso =

15% Retraso total = retraso de

Internet + retraso del acceso + retraso del LAN =

= 2 seg + msegs + msegs Suele suponer una mejora

costosa.

Servidoresorigen

Internet pública




Ejemplo de cachéInstalación del caché Supongamos que la tasa de

acierto sea 0,4.Consecuencias 40% de las peticiones serán

satisfechas casi inmediatamente. 60% de las peticiones serán

satisfechas por el servidor de origen.

EL uso del enlace de acceso se reduce al 60%, lo cual tiene como resultado retrasos insignificantes (digamos 10 mseg).

Retraso total = retraso de Internet + retraso del acceso + retraso del LAN =

= 0,6*2 seg + 0,6*0,01 segs + milisegundos < 1,3 segs

Servidoresorigen

Internet pública




Redes de distribución de contenidos (CDNs)

Los proveedores de contenido son los clientes CDN.

Réplica del contenido Una empresa CDN instala

cientos de servidores CDN a través de Internet. En ISP de capas bajas,

cerca de los usuarios. CDN contesta a los

contenidos de los clientes en servidores CDN. Cuando un proveedor actualiza el contenido, CDN actualiza los servidores.

Servidor origen en Norteamérica

Nodo CDN de distribución

Servidor CDNen Sudamérica Servidor CDN

en Europa

Servidor CDN en Asia

Ejemplo CDN

Servidor origen www.foo.com Distribuye HTML. Reemplaza: http://www.foo.com/sports.ruth.gif

por

http://www.cdn.com/www.foo.com/sports/ruth.gif

Petición HTTP para

www.foo.com/sports/sports.html

Consulta DNS para www.cdn.com

Petición HTTP para

www.cdn.com/www.foo.com/sports/ruth.gif

1

2

3

Servidor origen

Servidor DNS autorizado de la CDN

Servidor CDN cercano Empresa CDN

cdn.com Distribuye archivos gif. Utiliza su servidor DNS

autorizado para encaminar las peticiones redireccionadas.

Más sobre las CDNPeticiones dirigidas La CDN crea un “mapa”,

indicando las distancias entre las hojas ISP y los nodos CDN.

Cuando una consulta llega a un servidor DNS autorizado: El servidor determina el

ISP desde el que se origina la consulta.

Utiliza el “mapa” para determinar el mejor servidor CDN.

No sólo páginas Web Transmisión de

audio/vídeo almacenado.

Transmisión de audio/vídeo de tiempo real. Los nodos CDN crean

una red de revestimiento de capa de aplicación.

Compartición de archivos entre iguales

Ejemplo Alicia ejecuta su

aplicación cliente entre iguales en el bloc de notas de su computadora.

Intermitentemente, conecta a Internet; obtiene una nueva dirección IP para cada conexión.

Busca “Hey Jude”. La aplicación presenta

otros iguales que tienen copia de “Hey Jude”.

Alicia escoge uno de los iguales, Roberto.

El archivo se copia desde el PC de Roberto al bloc de notas de Alicia: HTTP.

Mientras Alicia hace la descarga, otros usuarios cargan desde el PC de Alicia.

El igual de Alicia es tanto un cliente Web como un servidor Web pasajero.

Todos los iguales son servidores = altamente escalable.

Directorio centralizado entre iguales

Diseño original del “Napster”.

1) Cuando un igual se conecta, informa al servidor central de: Su dirección IP. Su contenido.

2) Alicia pregunta por “Hey Jude”.

3) Alicia solicita un archivo de Roberto.

Servidor directorio centralizado

Iguales

Alicia

Roberto

1

1

1

12

3

Problemas con el directorio centralizado entre iguales

Único punto de fallo. Cuello de botella de

rendimiento. Infracción del

copyright.

La transferencia de archivos está descentralizada, pero el contenido localizado está altamente descentralizado.

Directorio descentralizado entre iguales

Cada igual es o un líder de su grupo o está asignado a un líder de grupo.

El líder del grupo rastrea el contenido de todos sus “hijos”.

Los iguales consultan al líder del grupo y este puede consultar a otros líderes de grupo.

Igual ordinario

Igual líder de grupo

Relaciones de vecindad

en la red de superposición

Más sobre el directorio descentralizado

Red de superposición Los iguales son nodos. Arcos entre los iguales

y sus líderes de grupo. Arcos entre algunas

parejas de líderes de grupo.

Vecinos virtuales.Nodo de arranque El igual conectado es

asignado a un líder de grupo o nombrado líder.

Ventajas del acercamiento No hay servidor de

directorio centralizado: El servicio de localización

distribuido entre los iguales. Más difícil de cerrar.

Inconvenientes del acercamiento

Es necesario el nodo de arranque.

Los líderes de grupo pueden sobrecargarse.

Inundación de consultas entre iguales

Aplicación Gnutella. No hay jerarquía. Utilización del nodo de

arranque para saber sobre los otros.

Conexión del mensaje.

Envío de consulta a los vecinos.

Los vecinos responden a la consulta.

Si el igual consultado tiene el objeto, manda mensaje de vuelta al igual que pregunta.

conexión

Más sobre la inundación de consultas entre igualesVentajas Los iguales tienen

responsabilidades similares: no hay líderes de grupo.

Altamente descentralizado.

Ningún igual mantiene un directorio de información.

Inconvenientes Tráfico de consultas

excesivo. Radio de consultas:

puede no tener contenido estando presente.

Nodo de arranque. Mantenimiento de la

red de superposición.

Capítulo 2: Resumen

Requerimientos de servicios de aplicación: Fiabilidad, ancho de banda,

retraso.

Paradigma cliente-servidor. Modelo de servicio de

transporte de Internet. Orientado a la conexión,

fiable: TCP Poco fiable, datagramas: UDP

Nuestro estudio sobre las aplicaciones de redes ahora está completo.

Protocolos específicos: HTTP. FTP. SMTP, POP, IMAP. DNS.

Programación de sockets.

Distribución de contenidos. Cachés, CDN. Entre iguales.

Capítulo 2: Resumen

Típico intercambio de mensajes petición/ respuesta. El cliente solicita una

información o un servicio. El servidor contesta con

datos y un código estatus. Formatos del mensaje:

Cabeceras: campos que dan la información sobre los datos.

Datos: información que se comunica.

Lo más importante: lo aprendido sobre protocolos

Mensajes de control frente a mensajes de datos. En banda, fuera de

banda. Centralizado frente a

descentralizado. Sin estado frente a en

estado. Transferencia de mensajes

fiable frente a poco fiable. “Complejidad al límite de la

red”. Seguridad: autentificación.

Documents

Clase 20 Capa de Aplicacion v.1