Capa de Aplicaciones1 Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer...

Capa de Aplicaciones 1

Capa de aplicaciones

NOTA: esta presentación es adaptada de:

Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith RossAddison-Wesley.


Capa de aplicacionesMetas: Aspectos conceptuales

de la implementación de los protocolos para las aplicaciones de red Modelos de servicio

de la capa de transporte

Paradigma cliente-servidor

Paradigma peer-to-peer

Aprender sobre protocolos al examinar los protocolos de aplicaciones comunes de Internet SMTP / POP3 / IMAP HTTP FTP XMPP DNS LDAP

Programar aplicaciones de red El API socket


Contenido

Principios de los protocolos de la capa de aplicaciones Clientes y servidores Requerimientos de las

aplicaciones Correo electrónico

SMTP, POP3 e IMAP Web

HTTP Transferencia de archivos

FTP Mensajería instantánea

XMPP

Servicio de nombres de dominio DNS

Servicio de directorio LDAP

Programación con Sockets TCP UDP

Construyendo un servidor Web


Aplicaciones de red: algunos términosProceso: instancia de un

programa que se ejecuta dentro de un nodo o contexto de ejecución de un programa que está corriendo.

Dentro del mismo host, dos procesos se comunican utilizando comunicación entre procesos (definido por el sistema operativo).

Los procesos que se ejecutan entre diferentes nodos lo hacen mediante un protocolo de la capa de aplicación

Agente de usuario: interfaces con el usuario “arriba” y la red “abajo”.

Implementa la interfaz de usuario y el protocolo de la capa de aplicación Cliente Web: browser Cliente E-mail: lector de

correo Cliente de mensajería

instantánea: IM client Cliente streaming

audio/video: media player


Aplicaciones y protocolos de la capa de aplicacionesAplicaciones: procesos distribuidos,

procesos que se comunican Por ejemplo, e-mail, Web,

compartir archivos P2P, mensajería instantanea

Se ejecutan en end systems (hosts)

Intercambian mensajes para implementar la aplicación

Protocolos de la capa de aplicación Son “una parte” de una

aplicación define los mensajes que se

intercambian por las aplicaciones y las acciones que deben realizar

Utilizan los servicios de comunicación proporcionados por los protocolos de la capa inferior (TCP, UDP)

aplicación

transportered

enlacefísica

aplicación

transportered

enlacefísica

aplicación

transportered

enlacefísica


Un protocolo de la capa de aplicaciones define… Los tipos de mensajes

intercambiados, es decir los mensajes de solicitud y los de respuesta

La sintáxis de los tipos de mensaje: qué campos tendrá el mensaje y cómo se delimitan los campos

La semántica de los campos, es decir, el significado de la información colocada en los campos

Las reglas de cuándo y cómo los procesos envían o reciben mensajes

Protocolos de dominio público:

Definidos en RFCs Buscan

interoperabilidad ejemplos, HTTP,

SMTPProtocolos

proprietarios: ejemplo, KaZaA


Paradigma cliente-servidorLas aplicaciones de red típicas tienen

dos partes: el cliente y el servidor aplicación

transportered

enlacefísica

aplicación

transportered

enlacefísica

Cliente: Inicia el contacto con el servidor

(“habla primero”) Normalmente solicita servicios

desde el servidor, Web: el cliente está

implementado en el browser; e-mail: en el lector de correo

solicitud

respuesta

Servidor: Proporciona el servicio solicitado por el cliente ejemplo, el servidor Web envía la página web

solicitada, el servidor de correo entrega el mensaje de correo


Los procesos se comunican a través de la red

Los procesos envían/reciben mensajes hacia/desde su socket

Un socket es análogo a una puerta El proceso que envía empuja

el mensaje hacia afuera El proceso que envía asume

que existe una infraestructura de transporte al otro lado de la puerta que llevará el mensaje hasta el socket del proceso que lo recibirá

proceso

TCP conbuffers,variables

socket

host oservidor

proceso

TCP conbuffers,variables

socket

host oservidor

Internet

controladopor OS

Controlado porel desarrollador

API: (1) selección del protocolo de la capa de transporte; (2) habilidad para fijar unos pocos parámetros (se estudiará luego)


Direccionamiento de procesos: Para que un proceso

reciba mensajes, este debe tener un identificador

Cualquier nodo en Internet tiene una dirección IP única (32 bits en IPv4, 128 bits en IPv6)

Pregunta: ¿es suficiente con la dirección IP para identificar los procesos?

Respuesta: No. Muchos procesos pueden ejectutarse en el mismo host

El identificador de un proceso en Internet incluye tanto la dirección IP como el número de puerto asociado con el proceso dentro del host.

Ejemplos de números de puerto “bien conocidos”: Servidor HTTP: 80 Servidor de correo: 25

Se estudiará luego


¿Qué servicios de transporte requiere una aplicación?Pérdida de datos Algunas aplicaciones (por

ejemplo, audio) pueden tolerar alguna pérdida

otras aplicaciones (ftp, telnet) requieren una confiabilidad del 100% al transferir datos

Control preciso de tiempo Algunas aplicaciones

(telefonía Internet, juegos interactivos) requieren poco retardo para que sean “efectivas”

Ancho de Banda Algunas aplicaciones

(multimedia) requieren un mínimo en la cantidad de ancho de banda para ser “efectivas”

otras aplicaciones (“aplicaciones elásticas”) utilizan el ancho de banda que encuentren


Requerimientos de servicios de transporte de aplicaciones comunes

Aplicación

Transferencia de archivosCorreo

Documentos webaudio/video en tiempo real

audio/video almacenadoJuegos interactivos

Mensajería instantánea

Pérdida de Datos

NoNoNoTolerante

ToleranteToleranteNo

Ancho de Banda

elásticoelásticoelásticoaudio: 5kbps-1Mbpsvideo:10kbps-5MbpsEl mismo anteriorAlgunos kbpselástico

Sensitivo al tiempo

nononosí, 100’s ms

sí, pocos ssí, 100’s mssí y no


Servicios de los protocolos de transporte de Internet

Servicio de TCP: Orientado a conexión: se debe

establecer una conexión entre los procesos cliente y servidor

Transporte confiable entre el proceso emisor y el proceso receptor

Control de flujo: el emisor no debe “saturar” al receptor

Control de congestión: el emisor debe moderarse cuando la red esté “sobrecargada”

No ofrece: ni control de tiempos, ni garantiza un mínimo ancho de banda

Servicio de UDP: Transferencia de datos

no confiable entre el proceso emisor y el receptor

NO ofrece: establecimiento de conexión, confiabilidad, control de flujo, control de congestión, control de tiempo, o garantía de ancho de banda mínimo


Aplicaciones de Internet: aplicación, protocolos de transporte

Aplicación

e-mailAcceso remoto

Web Transferencia de archivos

streaming multimedia

Telefonía Internet

Protocolo de la capa de aplicación

SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]proprietario(RealNetworks)proprietary(Dialpad)

Protocolo de la capa de transporte

TCPTCPTCPTCPTCP o UDP

normalmente UDP


Correo electrónico

Tres componentes principales:

Agentes de usuario Servidores de correo Protocolo simple de

transferencia de correo: SMTP

Agente de usuario Conocido como “lector de

correo” Permite elaborar, editar y leer

mensajes de correo. Ejemplos: Eudora, Outlook,

elm, Netscape Messenger Recupera los mensajes

colocados en el servidor

Buzón del usuario

Cola de mensajes salientes

Servidor decorreo

Agente de usuario

Agente de usuario

Agente deusuario

Servidor de correo

Agente deusuario

Agente deusuario

servidor decorreo

Agente de usuario

SMTP

SMTP

SMTP


Correo electrónico: servidores de correoServidores de correo buzón contiene los mensajes

que han llegado para el usuario

Cola de mensajes mensajes de correo salientes (para ser enviados)

Protocolo SMTP usado entre los servidores de correo para enviar los mensajes Se comporta como cliente

SMTP: cuando envia correo a otro servidor de correo

Se comporta como “servidor”: cuando recibe correo de otro servidor de correo

Servidor decorreo

Agente de usuario

Agente de usuario

Agente deusuario

Servidor de correo

Agente deusuario

Agente deusuario

servidor decorreo

Agente de usuario

SMTP

SMTP

SMTP


Correo electrónico: SMTP [RFC 2821]

Utiliza TCP para transferir confiablemente mensajes de correo desde el cliente al servidor, utiliza el puerto 25

Transferencia directa: entre el servidor que envía y el servidor que recibe

La transferencia tiene tres fases handshaking (saludo) Transferencia del los mensajes cierre

Interacción comando/respuesta comandos: texto ASCII respuesta: códigos de estado y frase

Los mensajes deben estar en ASCII de 7 bits


Escenario: Alicia envía un mensaje a Beto1) Alicia utiliza su agente de

usuario para elaborar un mensaje para [email protected]

2) El agente de usuario de Alicia envía el mensaje a “su servidor de correo”; el mensaje es colocado en la cola de mensajes

3) El lado “Cliente” de SMTP abre una conexión TCP con el servidor de correo de Beto

4) El lado “cliente” de SMTP envía el mensaje de alicia sobre la conexión TCP

5) El servidor de correo de Beto coloca el mensaje en el buzón de Beto

6) Beto invoca su agente de usuario para leer los mensajes

Agente deusuario

Servidor decorreo

Servidor decorreo Agente de

usuario

1

2 3 4 56


Ejemplo de la 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 la salsa de tomate? C: ¿y los pepinillos? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection


Interacción SMTP hecha “a mano” :

telnet nombre_servidor 25 Se observa el código 220 como respuesta del

servidor Se digitan los comandos HELO, MAIL FROM,

RCPT TO, DATA, QUIT

Lo anterior le permite enviar un mensaje de correo electrónico sin utilizar el cliente de correo


SMTP: palabras finales

SMTP utiliza conexiones persistentes (como el HTTP persistente)

SMTP obliga a que el mensaje (encabezado & cuerpo) estén en ASCII de 7 bits

El servidor SMTP utiliza CRLF.CRLF para “decir” donde está el final del mensaje

Comparación con HTTP:

HTTP: protocolo pull (halar)

SMTP: protocolo push (empujar)

Los dos protocolos interactuan mediante comandos/respuestas en ASCII y códigos de status

HTTP: cada objeto se “encapsula” en su propio mensaje de respuesta

SMTP: multiples objectos se envían en un mensaje “multiparte”


Formato del mensaje de correo

SMTP: protocolo para intercambio de mensajes de correo

RFC 822: estándar para el formato de mensajes de texto:

Líneas de header, es decir, To: From: Subject:¡Son diferentes a los

comandos SMTP! Cuerpo (body)

Es el “mensaje”, sólo permite caracteres ASCII

header

body

Línea enblanco


Formato del mensaje: extensiones para multimedia MIME: Multimedia Internet Mail Extension, RFC 2045,

2056 Líneas adicionales en el header del mensaje

declaran contenido tipo MIME

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

base64 encoded data ..... ......................... ......base64 encoded data

Tipo de dato multimedia, subtipo,

parámetro de declaración

Método utilizadopara codificar datos

Versión de MIME

Datos codificados


Tipos MIMEContent-Type: tipo/subtipo; parámetros

Text Ejemplo de subtipos:

plain, html

Image Ejemplo de subtipos :

jpeg, gif

Audio Ejemplo de subtipos:

basic (codificación 8-bit mu-law), 32kadpcm (codificación 32 kbps)

Video Ejemplo de subtipos:

mpeg, quicktime

Application Datos que deben ser

procesados por el cliente antes de “poderse ver”

Ejemplo de subtipos: msword, octet-stream


Tipo Multipart

From: [email protected] To: [email protected] Subject: Imagen de un crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPartHola Beto, por favor encuentra la imagen de un crepe.--StartOfNextPartContent-Transfer-Encoding: base64Content-Type: image/jpegbase64 encoded data ..... ......................... ......base64 encoded data --StartOfNextPart¿te gustaría tener la receta?


Protocolos de acceso al correo

SMTP: entrega al servidor de correo del receptor Protocolo de acceso al correo: recupera los mensajes desde el servidor

POP: Post Office Protocol [RFC 1939]• autorización (agente <-->servidor) y descarga los mensajes

IMAP: Internet Mail Access Protocol [RFC 1730]• Más características (más complejo)• manipulación de los mensajes almacenados en el servidor

HTTP: Hotmail , Yahoo! Mail, etc.

Agente deusuario

Servidor de correodel remitente

Agente deusuario

SMTP SMTP Protocolo deAcceso

Servidor de correodel destinatario


Protocolo POP3

Fase de autorización Comandos del cliente:

user: nombre de usuario

pass: la clave Respuestas del servidor

+OK -ERR

Fase de transacción, cliente:

list: lista los números de los mensajes

retr: recupera el mensaje por el número

dele: borra el mensaje quit: termina la sesión

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 beto S: +OK C: pass goloso S: +OK user successfully logged on


POP3 e IMAPMás sobre POP3 El ejemplo anterior utiliza

el modo “descargue y borre”.

Beto no puede volver a leer un mensaje si se cambia de cliente

“Descargue y guarde”: copias de los mensajes en diferentes clientes

POP3 no mantiene información de sesiones anteriores (stateless)

IMAP Mantiene todos los

mensajes en el mismo lugar: el servidor

Permite al usuario que organice sus mensajes en fólderes

IMAP mantiene información de estado de sesiones anteriores: Nombres de fólderes y

“mapeo” entre la identificación de los mensajes y el nombre de los fólderes


Web y HTTP

Algunos términos Una página Web consta de objetos Los objetos pueden ser un archivo HTML, una

imagen JPEG, un applet Java, un archivo de audio,…

Una página Web consta de un archivo HTML base que incluye diversos objetos referenciados

Cada objeto se direcciona con un URL Ejemplo de un URL:

www.algunsitio.edu/algunaFacultad/pic.gif

Nombre del host Nombre del path


Panorámica de HTTP

HTTP: protocolo de transferencia de hipertexto

Es el protocolo de la capa de aplicación para el Web

Usa el modelo cliente/servidor cliente: browser o

navegador que solicita, recibe y muestra los objetos Web

servidor: Servidor www que envía objetos en respuesta a las solicitudes del browser

HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068

PC ejecutandoIE Explorer

Servidorejecutando

El servidor WebApache

Mac ejecutandoNetscape Navigator

Solicitud HTTP

Solicitud HTTP

Respuesta HTTP

Respuesta HTTP


Panorámica de HTTP (continuación)Utiliza TCP: El cliente inicia la

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

El servidor acepta la conexión TCP solicitada por cliente

Los mensajes HTTP (mensajes del protocolo de la capa de aplicación) se intercambian entre el browser (cliente HTTP) y el servidor Web (servidor HTTP)

Se cierra la conexión TCP

HTTP es “stateless” El servidor no

mantiene información sobre las solicitudes anteriores del cliente

¡Los protocolos que mantienen información de estado son complejos!

La historia pasada (estado) debe guardarse

Si el servidor o el cliente fallan, sus “imágenes” del estado de la sesión pueden ser inconsistentes y deben “reconciliarlas”

NOTA


Conexiones HTTP

HTTP no persistente Al menos un objeto

es enviado sobre una conexión TCP.

HTTP/1.0 utiliza HTTP no persistente

HTTP persistente Multiples objetos

pueden ser enviados sobre una misma conexión TCP entre el cliente y el servidor.

HTTP/1.1, por omisión, utiliza conexiones persistentes


HTTP No persistente Supongamos que el usuario ingresa el URL www.algunsitio.edu/algunaFacultad/index.html

1a. El cliente HTTP inicia la conexión TCPal servidor HTTP (el proceso) en www.algunsitio.edu en el puerto 80

2. El cliente HTTP envía un request message (que contiene el URL) hacia su socket de conexión TCP. El mensaje indica que el cliente desea el objeto algunaFacultad/index.html

1b. El servidor HTTP en el host www.algunsitio.edu espera conexiones TCP en el puerto 80. Cuando “acepta” una conexión, notifica al cliente

3. El servidor HTTP recibe el mensaje de solicitud, construye un response message que contiene el objeto solicitado, y envía el mensaje hacia su socket

tiempo

(contiene texto, referencia a 10 imágenes jpeg)


HTTP No persistente (cont.)

5. El cliente HTTP recibe el mensaje de repuesta que contiene el archivo html, muestra el html. Al recorrer el archivo html encuentra 10 objetos jpeg referenciados

6. Los pasos 1 a 5 se repiten para cada uno de los 10 objetos jpeg

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

tiempo


Modelamiento del tiempo de respuestaDefinición de RRT: tiempo para

enviar un pequeño paquete y que este viaje desde el cliente hasta el servidor y que regrese.

Tiempo de respuesta: Un RTT para iniciar la

conexión TCP Un RTT para la solicitud HTTP

y para que los primeros bytes de la respuesta HTTP regresen

Tiempo de transmisión del archivo

total = 2RTT+tiempo de transmisión

tiempo para transmitir archivo

Inicia Conexión TCP

RTT

solicitaarchivo

RTT

archivorecibido

tiempo tiempo


HTTP Persistente

Aspectos de HTTP No persistente:

requiere 2 RTTs por objeto El OS debe trabajar y asignar

los recursos del host para cada conexión TCP

En ocasiones un browser abre conexiones TCP paralelas para traer los objetos referenciados

HTTP persistente El servidor deja la conexión

abierta después de enviar el mensaje de respuesta

Los mensajes HTTP que siguen entre el cliente/servidor son enviados sobre la misma conexión TCP

Persistencia sin pipelining: El cliente emite una

nueva solictud sólo cuando la respuesta anterior ha sido recibida

Se requiere un RTT para cada objeto referenciado

Persistencia con pipelining: Por omisión en HTTP/1.1 El cliente envía una

solicitud tan pronto como encuentra un objeto referenciado

Se requiere apenas como un RTT para TODOS los objetos referenciados


Mensaje de solicitud HTTP

HTTP tiene dos tipos de mensajes: request, response

Mensaje de solicitud: ASCII (formato legible para nosotros)

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

(“carriage return, line feed” adicional)

Línea de solicitud(comandos GET, POST,

HEAD)

Líneas deencabezado

“Carriage return, line feed”

Indica el final del mensaje


Mensaje de solicitud HTTP: formato general


Enviando datos al servidor desde un formulario HTMLUsando el método POST: Las páginas web incluyen

a menudo formularios para ingresar datos

Los datos ingresados en el formulario son “subidos” o enviados al servidor a través del cuerpo del mensaje (Entity Body)

Usando el URL: Utiliza el método GET Los datos ingresados son

enviados en el campo del URL de la línea de solicitud

www.algunsitio.com/busqueda?nombre=arcesio&apellido=net


Tipos de métodos

HTTP/1.0 GET POST HEAD

Hace una consulta al servidor sobre las características del objeto, pero no transfiere el objeto

HTTP/1.1 GET, POST, HEAD PUT

Envía un archivo en el cuerpo del mensaje al path especificado en el URL

DELETE Borra el archivo

especificado en el URL


Mensaje de respuesta de HTTP

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 estado(código deestado delProtocolo,

frase de estado)

Líneas de encabezado

datos, es decir, archivo HTML

solicitado


Códigos de estado de HTTP

200 OK Solicitud exitosa, el objeto solicitado va en este mensaje

301 Moved Permanently El objeto solicitado fue movido, la nueva ubicación se

especifica posteriormente en este mensaje (Location:)

400 Bad Request El mensaje de solicitud no fue entendido por el servidor

404 Not Found El documento solicitado no se encontró en este servidor

505 HTTP Version Not Supported

Se usan en la primera línea del mensaje de respuesta del servidor->cliente. Ejemplos:


Conexión HTTP (cliente) hecha “a mano”

1. Conéctese, a través de telnet al puerto 80, a su sitio Web favorito:

Abre una conexión TCP al puerto 80(puerto “bien conocido” de HTTP) enwww.arcesio.net.Cualquier cosa que se digite será enviadaAl puerto 80 en www.arcesio.net

telnet www.arcesio.net 80

2. Digite una solicitud de HTTP con el método GET:

GET /index.html HTTP/1.0 Al digitar esto (y oprimir <ENTER>dos veces), se enviará esta solicitud HTTP mínima (pero completa) al servidor HTTP

3. ¡Observe el mensaje de respuesta enviado por el servidor HTTP!


Interacción usuario-servidor: autorización

Autorización : control de acceso al contenido del servidor

Credenciales de autorización: normalmente un nombre y una clave (password)

stateless: el cliente debe presentar la autorización cada vez que haga una solicitud autorización: línea del header en

cada solicitud Si no tiene la línea autorización:

el servidor rechaza el acceso, y envía la línea de headerWWW authenticate: En respuesta

cliente servidor

Solicitud http usual

401: authorization req.

WWW authenticate:

Solicitud http usual+ Autorización: <cred>

Respuesta http usual

Solicitud http usual+ Autorización: <cred>

Respuesta http usual tiempo


Cookies: guardando el “estado”Muchos sitios Web utilizan

cookiesCuatro componentes:

1) Línea de header “cookie:” en el mensaje de respuesta HTTP

2) Línea de header “cookie:” en el mensaje de solicitud

3) El archivo de la “cookie” es almacenado en el nodo del usuario y es administrado por el browser del usuario

4) La base de datos está en el back-end del sitio Web

Ejemplo: Susana siempre accede

Internet desde el mismo PC

Ella visita un sitio de e-commerce específico por primera vez

Cuando la solicitud HTTP inicial llega al sitio, el sitio crea un identificador único y crea un registro en la base de datos backend para esa identificación


Cookies: guardando el “estado” (cont.)

cliente servidor

Solicitud http usual

Respuesta http usual +

Set-cookie: 1678

Solicitud http usualcookie: 1678


Solicitud http usualcookie: 1678


Acciónespecífica para cookie

Acciónespecífica para cookie

El servidorcrea el ID

1678 para el usuario

Registro en la

Base de datos

backend

acceso

acce

so

Archivo Cookie

amazon: 1678ebay: 8734

Archivo Cookie

ebay: 8734

Archivo Cookie

amazon: 1678ebay: 8734

Una semana después:


Cookies (continuación)

Qué se puede hacer con cookies:

autorización Carros de compras recomendaciones Estado de la sesión

de usuario (Web e-mail)

Cookies y privacidad: Las cookies permiten a

los sitios aprender muchas cosas sobre usted

Usted puede suministrar su nombre y su e-mail a los sitios web

Las motores de búsqueda utilizan redireccionamiento & las cookies para aprender aún más

Las compañías de publicidad obtienen información a través de los sitios web

NOTA


GET condicional: caching del lado del cliente

Meta: no enviar objetos si el cliente tiene una versión actualizada en cache

cliente: El cliente especifica la fecha de la copia en cache en el mensaje de solicitud HTTPIf-modified-since:

<fecha> servidor: La respuesta no

lleva el objeto si la copia en cache está actualizada: HTTP/1.0 304 Not

Modified

cliente servidor

Solicitud HTTPIf-modified-since:

<fecha>

Respuesta HTTPHTTP/1.0

304 Not Modified

objeto no

modificado

Solicitud HTTPIf-modified-since:

<fecha>

Respuesta HTTPHTTP/1.0 200 OK

<datos>

objecto modificado


FTP: protocolo de transferencia de archivos

Transfiere archivos hacia y desde el host remoto Usa el modelo cliente/servidor

client: quien inicia la transferencia (para transferir hacia/desde el host remoto)

server: host remoto ftp: RFC 959, RFC1123 Servidor ftp: puertos 21 y 20

Transferencia del archivo

ServidorFTP

Interface para

usuario FTP

ClienteFTP

Sistema de archivos local

Sistema de archivos remoto

usuario


FTP: control separado de la conexión para datos

El cliente FTP contacta el servidor FTP en el puerto 21, especificamdo TCP como protocolo de transporte

El cliente obtiene autorización sobre la conexión de control

El cliente permite listar el directorio remoto al enviar comandos sobre la conexión de control.

Cuando el servidor recibe una comando para transferir un archivo, el servidor abre una conexión TCP para datos con el cliente

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

ClienteFTP

ServidorFTP

Puerto 21, conexión TCP de control

Puerto 20, conexión TCP para datos

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

Conexión de control: “out of band”

El servidor FTP mantiene información “de estado”: directorio actual, la autenticación inicial, etcétera


Comandos y respuestas FTP

Algunos comandos: Envíados como testo

ASCII sobre el canal de control

USER username PASS password LIST retorna una lista de

los archivos en el directorio actual

RETR filename recupera (trae) el archivo

STOR filename almacena (coloca) el archivo en el host remoto

Ejemplo de códigos de retorno

Utiliza un código de estado y una 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


Mensajería instantánea y XMPP La mensajería instantánea (Instant Messaging o IM) es

una forma de comunicación en tiempo real entre dos o más personas con base en texto digitado.

Requiere el uso de un programa cliente para conectarse al servicio de mensajería instantánea y se diferencia del correo electrónico porque las conversaciones ocurren en tiempo real

Servicios de IM populares en Internet .NET Messenger Service, AOL Instant Messenger,

Excite/Pal, Gadu-Gadu, Google Talk, iChat, ICQ, Jabber, Qnext, QQ, Meetro, Skype, Trillian, Yahoo! Messenger y Rediff Bol Instant Messenger.

Estos servicios utilizan los principios de un antiguo servicio de charla interactivo (que aún es popular) conocido Internet Relay Chat (IRC).


Mensajería instantánea y XMPP Los clientes con interfaz gráfica despegaron a finales de 1990

con ICQ (1996) y AOL Instant Messenger (AIM, 1997) . Luego AOL adquirió a Mirabilis, los creadores de ICQ.

Pocos años después, AOL logró dos patentes para mensajería instantánea en los EE.UU.

Otras compañías desarrollaron sus propias aplicaciones (Yahoo, MSN, Excite, Ubique, IBM), cada una con su protocolo y su cliente propietario. Si una persona quería utilizar diferentes servicios debía usar diferentes clientes.

En el año 2000, se liberó una aplicación y un protocolo abierto llamado Jabber. Este fue formalizado como el Extensible Messaging and Presence Protocol (XMPP) por la IETF en los RFCs 3920 y 3921.

Los servidores de Jabber pueden actuar como gateways a otros protocolos de IM, reduciendo la necesidad de tener varios clientes.

Clientes de IM multi-protocolos, como Gaim, Trillian y Miranda, pueden utilizar cualquiera de los protocolos de IM populares sin necesidad de un servidor que haga de gateway.


Mensajería instantánea

Recientemente, muchos servicios de mensajería instantánea han comenzado a ofrecer características de video conferencia, Voz sobre IP (VoIP) y web conferencing. Los servicios de Web conferencing integran video

conferencia y mensajería instantánea. Las compañías de mensajería instantánea más

nuevas están ofreciendo escritorio compartido, IP radio, e IPTV para las características de voz y video.

NOTA: el término "instant messenger" es una marca de servicio [SM] de Time Warner y no puede ser utilizado en software no afiliado con AOL en los EE.UU.


XMPP (Extensible Messaging and Presence Protocol) XMPP es un protocolo

para el intercambio de información en tiempo real, estructurada con XML (Extensible Markup Language).

Aunque XMPP provee un ambiente generalizado para el intercambio de datos XML, es utilizado en mensajería instantánea.

Puerto 5222/TCP (client-to-server)

Puerto 5269/TCP (server-to-server)

ClienteXMPP

GatewayTraduce entre XMPP y NO-XMPP

ClienteXMPP

ServidorXMPP

ServidorXMPP

ClienteXMPP

Servidor IMNO-XMPP

ClienteNO- XMPP


XMPP (Extensible Messaging and Presence Protocol) El servidor XMPP:

Maneja las sesiones con otras entidades en forma de XML streams hacia y desde clientes, servidores y otros sistemas autorizados

Enruta stanzas XML direccionadas apropiadamente entre los sistemas autorizados sobre XML streams

La mayoría de los servidores también asumen la resposabilidadpara almacenar los datos que utilizan los clientes (por ejemplo, las listas de contactos)

El cliente XMPP La mayoría de los clientes se conectan directamente

al servidor sobre una conexión TCP y utilizan XMPP para utilizar las facilidades ofrecidas por el servidor y cualquier servicio asociado.

El puerto recomendado para la conexión entre un cliente y un servidor es el 5222.


XMPP (Extensible Messaging and Presence Protocol) El gateway XMPP:

Es un servicio especial -del lado del servidor- cuya función es traducir XMPP a protocolos NO-XMPP de otros sistemas de mensajería y viceversa. Ejemplos son los gateways para e-mail (SMTP), Internet Relay Chat (IRC), SIMPLE, Short Message Service (SMS) y sistemas como AIM, ICQ, MSN Messenger, y Yahoo! Instant Messenger.

La red XMPP Como cada servidor es identificado por una dirección de red y

las comunicaciones server-to-server son una extensión directa al protocolo client-to-server, en la práctica, el sistema consta de una red de servidores que se intercomunican entre sí.

• Por ejemplo, <[email protected]> puede intercambiar mensajes, presencia y otra información con <[email protected]> (como en el servicio de correo).

Las comunicaciones entre cualesquier dos servidores es opcional. Si se habilita, dicha comunicación debe ocurrir sobre XML streams que estén asociados a conexiones TCP. El puerto recomendado para conexiones entre servidores es el 5269


Esquema de direccionamiento de XMPP Por razones históricas, las dirección de

una entidad XMPP se llama Jabber Identifier o JID.

Un JID válido contiene un conjunto ordenado de elementos formados por un identificador de dominio, un identificador de nodo y un identificador de recurso.

JID = nodo@dominio/recurso [email protected] [email protected]/pinocho


DNS: Domain Name System

Las personas: tienen muchos identificacdores: Cédula, nombre,

pasaporteIdentificadores de host y

routers de Internet: La dirección IP (32 bits) –

utilizada para direccionar datagramas

El “nombre”, por ejemplo, gaia.cs.umass.edu – utilizado por los humanos

Pregunta: ¿quién asocia las direcciones IP y los nombres?

Domain Name System: Base de datos distribuida

implementada un una jerarquía de muchos servidores de nombres

Protocolo de la capa de aplicación utilizado por hosts, routers, y servidores de nombres para resolver nombres (traducción entre dirección y nombre) nota: función central de

Internet, implementada como un protocolo de la capa de aplicaciones


Servidores de nombres DNS

Ningún servidor tiene todas las asociaciones nombre a IP

Servidores de nombres locales: cada ISP o compañía tiene un

local (default) name server Las consultas que realizan los

nodos primero se hacen con el local name server

Servidor de nombres autorizado: Para un host: almacena la

dirección IP y el nombre de ese host

Puede hacer la traducción de nombre a dirección IP para ese host

¿Por qué no un DNS centralizado?

Un solo punto de falla Alto volumen de tráfico Base de datos

centralizada distante mantenimiento

¡ NO PUEDE ESCALAR !


DNS: Servidores raíz (root servers)

Contactado por el servidor de nombres local que no puede resolver el nombre

Servidor de nombres raíz: Contacta el servidor de nombres autoritativo si el mapeo de

nombre no es conocido Consigue el mapeo Retorna el mapeo al servidor de nombres 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

13 servidores raíz en el mundo


Ejemplo Simple de DNS

surf.eurecom.fr desea saber la dirección IP de gaia.cs.umass.edu

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

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

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

Nodo que consultasurf.eurecom.fr

gaia.cs.umass.edu

DNS raíz

DNS autoritativodns.umass.edu

DNS local dns.eurecom.fr

1

23

4

5

6


Ejemplo de DNS

DNS raíz: Podría no conocer el

servidor de nombres autoritativo

Podría conocer el DNS intermedio: el que se contacta para encontrar el DNS autoritativo


gaia.cs.umass.edu

DNS Raíz

DNS localdns.eurecom.fr

1

23

4 5

6

DNS autoritativodns.cs.umass.edu

DNS intermediodns.umass.edu

7

8


DNS: consultas iterativas

Consulta recursiva: Coloca un bloque de

consultas de resolución de nombres sobre el servidor de nombres contactado

¿demasiada carga?

Consulta iterada: El servidor contactado

responde con el nombre del servidor que se debe contactar

“Yo no conozco ese nombre, pero pregúntele a éste servidor”


gaia.cs.umass.edu

DNS raíz

DNS localdns.eurecom.fr

1

23

4

5 6

DNS autoritativodns.cs.umass.edu

DNS intermediodns.umass.edu

7

8

Consulta iterada


DNS: caching y actualización de registros Cuando el DNS aprende el mapeo, el hace

una copia en cache Los datos colocados en el cache tienen un

tiempo de vigencia, al pasar dicho tiempo los datos desaparecen

El mecanismo de actualización/notificación está en diseño por la IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html


Registros del DNSDNS: registros de recursos (RR) almacenados en una base de datos

distribuida

Type=NS name es un dominio (por

ejmplo. sitio.com) value es una dirección IP de

un DNS autoritativo para este dominio

Fromato RR: (name, value, type, ttl)

Type=A name es un nombre de hosts value es una dirección IP

Type=CNAME name es un alias para algún

nombre “canónico” (el nombre real)

www.ibm.com es realmente servereast.backup2.ibm.com value es el nombre canónico

Type=MX value es el nombre de un

servidor de correo asociado con name


Protocolo DNS y mensajes DNSProtocolo DNS: mensajes de query y reply, juntos tienen el mismo formato de

mensaje

Header del mensaje identificación: 16 bits que

identifican la consulta (query), la respuesta a la consulta utiliza el mismo identificador

flags: Consulta o respuesta recursión deseada recursión disponible La respuesta es

autoritativa

identificación flags

número de consultas número de RRs respondidos

Número de RRs autoritativos Número de RRs adicionales

Consultas

(número variable de consultas)

Respuestas

(número variable de registros de resursos)

Autoritativas

(número variable de registros de recursos)

Información adicional

(Número variable de registros de recursos)

12 bytes


Protocolo DNS y mensajes DNS

Nombre, campos tipo Para una consulta

RRs en respuestaA una consulta

Registros paraservidores autoritativos

Información adicionalútil que puede usarse

identificación flags

número de consultasnúmero de RRs

respondidos

Número de RRs autoritativos

Número de RRs adicionales

Consultas

(número variable de consultas)

Respuestas

(número variable de registros de resursos)

Autoritativas

(número variable de registros de recursos)

Información adicional

(Número variable de registros de recursos)


Servicio de directorio y LDAP

Permite consolidar los servicios existentes en un solo directorio que puede ser accedido mediante clientes (pueden ser web browsers, clientes de correo electrónico, servidores de correo, etcétera.)

Los sercicios de directorio de red no son nuevos. Nosotros ya estamos familiarizados con el DNS.

Un servicio de directorio: Está optimizado para leer Implementa un modelo distribuido para almacenar

información Puede extender el tipo de información que almacena. Tiene capacidades de búsqueda avanzadas. Tiene replicación entre servidores de directorio

El servidio de directorio (que se accede mediante LDAP) no es un reemplazo de directorio especializados (como los filesystems o DNS) y no está diseñado para almacenar todo tipo de archivos (en un directorio es útil almacenar fotos en formato JPEG, pero no está hecho para eso).


LDAP (Lightweight Directory Access Protocol) LDAP (Versión 3) está definido en el RFC 3377 (y ocho

RFCs más mencionados en este) El origen de LDAP está relacionado con el servicio de

directorio X.500; LDAP fue diseñado originalmente como un protocolo para equipos de escritorio más liviavo para hacer solicitudes a los servidores X.500 (X.500 es un conjunto de estándares)

LDAP es un protocolo (un conjunto de mensajes para acceder a cierta clase de datos) liviano en comparación con X.500 pues utiliza mensajes con poco overhead que son colocados directamente sobre TCP (en el puerto 389) mientras que x.500 requieren que los clientes y el servidor se comuniquen sobre el modelo OSI Como protocolo, LDAP no dice nada sobre el lugar donde

se almacenarán los datos. Un proveedor de software que implemente un servidor LDAP es libre de usar lo que quiera para guardar los datos: desde archivos de texto plano hasta un motor de bases de datos relacional escalable.


LDAP: protocolo de acceso

Hablar de los servicios de directorio hace que se olvide que LDAP es un protocolo (algunos utilizan términos como LDAP server o árbol LDAP)

LDAP ofrece un vista de datos en forma de árbol, y este es el árbol al que las personas se refieren.

LDAP es un protocolo cliente/servidor definido en el RFC 2251. LDAP es asincrónico, queriendo decir que un cliente puede emitir múltiples solicitudes y que las respuestas a estas solicitudes pueden llegar en un orden diferente al que fueron emitidas.


Modelos de LDAP

Los modelos de LDAP representan los servicios ofrecidos por un servidor, como son vistos por un cliente.

Se definen cuatro modelos Modelo de información: estructuras y tipos de datos

necesarios para construir un árbol de directorio LDAP Modelo de nombres: define como las entradas y y los

datos son refernciados de manera única en el DIT (Directory Information Tree)

Modelo funcional: Es el protocolo LDAP Modelo de seguridad: provee los mecanismos para

que los clientes demuestren su identidad (se autentiquen) y para que el servidor controle el acceso a la información por parte del cliente autenticado (autorización).


Capítulo 2: contenido

2.1 Principios de los protocolos de la capa de aplicaciones Clientes y servidores Requerimientos de las

aplicaciones

2.2 Web y HTTP 2.3 FTP 2.4 Correo

electrónico SMTP, POP3 e IMAP

2.5 DNS

2.6 Programación con Sockets de TCP

2.7 Programación con Sockets de UDP

2.8 Construyendo un servidor Web

2.9 Distribución de contenido Caching de web en la red Redes de distribución de

contenido Archivos compartidos

P2P


Programación con sockets

El API Socket Distribuido en el UNIX BSD4.1,

1981 Creado explicitamente, usado

y liberado por las aplicaciones Paradigma cliente/servidor Dos tipos de transporte a

través del socket: Datagrama, no confiable No confiable, orientado a

flujo de bytes (byte stream-oriented)

Una interface local al host, creado por la

aplicación, controlado por el OS (una “puerta”)

hacia la cual los procesos de las

aplicaciones pueden enviar y recibir

mensajes hacia/desde otro proceso de

aplicación

socket

Meta: aprender cómo construir aplicaciones cliente/servidor que se comuniquen utilizando sockets


Programación con sockets utilizando TCPSocket: una puerta entre el proceso de la aplicación y

el protocolo de la capa de transporte (UDP o TCP)Servicio TCP: transferencia confiable de bytes desde

un proceso a otro

proceso

TCP conbuffers,

variables

socket

controlado porel desarrolladorde la aplicación

controlado porel sistemaoperativo

host oservidor

proceso

TCP conbuffers,

variables

socket

controlado porel desarrolladorde la aplicación

controlado porel sistemaoperativo

host oservidor

internet


Programando sockets con TCPEl cliente debe contactar al

servidor: El proceso del servidor debe

estar corriendo desde antes El servidor debe haber creado

un socket (puerta) que acepte la solicitud del cliente

El cliente contacta al servidor: Creando un socket TCP local Especificando la dirección IP y

el número de puerto del proceso del servidor

Cuando el cliente crea el socket: el cliente TCP establece una conexión al servidor TCP

Cuando es contactado por el cliente, el servidro TCP crea un nuevo socket para que el proceso servidor se comunique con el cliente Permite al servidor

comunicarse con múltiples clientes

Los númerso de puerto origen son utilizados para identificar los clientes (más en el cap. 3)

TCP permite transferir bytesde manera confiable, en orden (“un tubo”), entre el cliente

Y el servidor

Para la aplicación…


Términos utilizados en streaming Un stream es una

secuencia de caracteres que fluye hacia/desde un proceso.

Un input stream se asocia a alguna fuente de entrada de datos para el procesos, por ejemplo, el teclado o un socket.

Un output stream se asocia a una fuente de salida, por ejemplo, la pantalla o un socket.


Programando sockets con TCP

Ejemplo de una aplicación cliente-servidor:

1) El cliente lee una línea desde el dispositivo de entrada estándar (stream inFromUser) , envía al servidor a través de un socket (stream outToServer)

2) El servidor lee la línea desde un socket

3) El servidor convierte la línea a mayúsculas, y la regresa al cliente

4) El cliente lee la línea modificada que lee desde el socket y la imprime en la pantalla (stream inFromServer)

outT

oSer

ver

to network from network

inFr

omS

erve

r

inFr

omU

ser

keyboard monitor

Process

clientSocket

inputstream

inputstream

outputstream

TCPsocket

Procesocliente

Socket TCP del cliente


Interacción de sockets en cliente/servidor: TCP

espera solicitudes de conexiónconnectionSocket =welcomeSocket.accept()

crea socket,port=x, pararecibir solicitudes:welcomeSocket =

ServerSocket()

crea socket,se conecta a hostid, port=xclientSocket =

Socket()

cierraconnectionSocket

lee respuestas declientSocket

cierraclientSocket

Servidor (ejecutando en hostid) Cliente

envía solicitudes usandoclientSocketlee solicitudes desde

connectionSocket

escribe las respuestas enconnectionSocket

establece conexiónTCP

cierra conexiónTCP


Ejemplo: Cliente Java (TCP)

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

public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence;

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

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());

Creainput stream

asociado al teclado

Crea socketpara el cliente,

conecta al servidor

Creaoutput stream

asociado al socket


Ejemplo: Cliente Java (TCP), cont.

BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close(); } }

Creainput stream

asociado al socket

Envía la líneaal servidor

Lee la líneadesde el servidor


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

class TCPServer {

public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence;

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

BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));

Creasocket de bienvenida

en el puerto 6789Espera,

crea un socket para ser contactado

por el clienteCrea un input

stream, asociado al socket


Ejemplo: Servidor Java (TCP), cont.

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence); } } }

Lee la líneadesde el socket

Crea outputstream,

asociado al socket

Escribe la líneaal socket

Fin del ciclo while,regresa al inicio del ciclo y esperaotra conexión de cliente




aplicaciones



2.5 DNS






P2P


Programando sockets con UDP

UDP: no establece una “conexión” entre el cliente y el servidor

No hace handshaking El emisor explícitamente

asocia la dirección IP y el puerto destino a cada paquete

El servidor debe extraer la dirección IP y el puerto del emisor a partir del paquete enviado

UDP: los datos transmitidos pueden ser recibidos fuera de orden o pueden ser perdidos

Para la aplicación…

UDP transfiere de manera no confiable grupos de bytes

(“datagramas”) entre el cliente y el servidor


Interacción de sockets en cliente/servidor: UDP

cierraclientSocket

Servidor (ejecutando en hostid)

Lee la respuesta desdeclientSocket

crea socket,clientSocket = DatagramSocket()

Cliente

Crea, asocia dirección (hostid, port=x)envía datagrama de solicitudusando clientSocket

crea socket,port=x, para recibir solicitudes:serverSocket = DatagramSocket()

Lee la solicitud desdeserverSocket

Escribe la respuesta enserverSocketEspecificando la direcciónIP del cliente y elnúmero de puerto


Ejemplo: Cliente Java (UDP)

sendP

ack

et

to network from network

rece

iveP

ack

et

inF

rom

Use

r

keyboard monitor

Process

clientSocket

UDPpacket

inputstream

UDPpacket

UDPsocket

Output: envía paquetes (TCP envía “byte stream”)

Input: recibe paquetes (TCP recibe “byte stream”)

Procesocliente

client UDP socket


Ejemplo: Cliente Java (UDP)

import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Creainput stream

Crea socket para

el client

Trasladanombre de host

a dirección IP utilizando el DNS


Ejemplo: Cliente Java (UDP), cont.

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); }

}

Crea datagrama con la longitud de

datos-a-enviar, dirección IP,

puertoEnvía datagrama

al servidor

Lee datagramadesde el servidor


Ejemplo: Servidor Java (UDP)

import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Crea socket tipoDatagrama en el

puerto 9876

Crea espacio pararecibir datagrama

Recibedatagram

a


Ejemplo: Servidor Java (UDP), cont

String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } }

}

Consigue le dirección IP

puerto #, del solicitante

Escribe eldatagrama

en el socket

Fin del ciclo while,regresa al inicio y espera otro datagrama

Crea datagramapara envíar

al cliente


Construyendo un servidor Web simple Maneja sólo una solicitud

HTTP Acepta la solicitud Analiza el header Obtiene el archivo

solicitado desde el sistema de archivos del servidor

Crea el mensaje de respuesta HTTP: Líneas de header +

archivo Envía la respuesta al

cliente

Después de construir el servidor, usted puede solicitar el archivo urilizando un browser (Internet Explorer o Netscape Navigator)

Vea el texto para más detalles


Programando sockets: referencias

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

Tutoriales 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




aplicaciones



2.5 DNS






P2P


Cache en Web (servidor proxy)

El usuario debe configurar el browser: Los accesos web se realizan a través del cache

El browser envía todas las solicitudes HTTP al cache

Si el objeto está en el cache: el cache retorna el objeto

Si el objeto no está en el cache, el servidor de cache lo solicita desde el servidor origen y entonces envía el objeto al cliente

Meta: satisfacer las solicitudes del cliente sin involucrar el servidor origen

cliente

ServidorProxy

cliente

Solicitud HTTP

Solicitud HTTP

Respuesta HTTP

RespuestaHTTP re

sponse

Solicitud HTTP

Respuesta HTTP

Servidororigen

Servidororigen


Más sobre Web caching

El servidor de cache actua tanto como cliente y como servidor

El servidor de cache puede hacer actualizaciones de su contenido utilizando el header HTTP If-modified-since

Probelma: ¿el servidor de cache debería tomar el riesgo y entregar el objeto copiado en su disco sin hacer ninguna revisión?

Se utilizan métodos heurísticos.

Un servidor de cache típico se instala en un ISP (universidad, compañía, ISP residencial)

¿Por qué utilizar Web caching?

Reduce el tiempo de respuesta de las solicitudes del cliente.

Reduce el tráfico sobre el canal de acceso a Internet de una institución.

Internet con muchos servidores cache permite que los proveedores de contenido “pobre” entreguen contenido de manera efectiva


Ejemplo de Caching (1)Supuestos Tamaño promedio del objeto =

100,000 bits Tasa de solicitudes promediodesde

el browser de la institucióna los servidores origen = 15/seg

Retardo desde el router institucional a cualquier servidor origen y de regreso al router = 2 seg

Consecuencias utilización sobre la LAN = 15% utilización sobre el enlace de

acceso = 100% Retardo total = retardo en Internet

+ retardo del canal de acceso + retardo en la LAN

= 2 seg + minutos + milisegundos

Servidoresorigen

Internet pública

Red institucional LAN a 10 Mbps

Enlace de acceso1.5 Mbps


Ejemplo de Caching (2)

Posible solución Incrementar ancho de

banda del enlace de acceso, digamos a 10 Mbps

Consecuencias Utilización de la LAN = 15% Utilización sobre el enlace de

acceso = 15% Retardo Total = retardo en

Internet + retardo del canal de acceso + retardo en la LAN

= 2 seg + milisegundos + milisegundos

Generalmente una actualización costosa

Servidoresorigen

Internet pública

Red institucional LAN a 10 Mbps

Enlace de acceso10 Mbps


Ejemplo de Caching (3)

Instalando servidor cahe Supongamos que la tasa de hits

es .4Consecuencia 40% de las solicitudes serán

satisfechas casi inmediatamente El 60% de las solicitudes serán

satisfechas desde el servidor origen

La utilización del enlace de accesose reduce al 60%, lográndose retardos casi despreciables (diagmos 10 milisegundos)

Retardo total = Retardo en Internet + retardo en el enlace de acceso + retardo en la LAN

= .6*2 segundos + .6*.01 segundos + milisegundos < 1.3 segundos

Servidoresorigen

Internet pública

Red institucional 10 Mbps LAN

Enlace de acceso

1.5 Mbps

Cacheinstitucional


Redes de distribución de contenido (CDNs)

Los proveedores de contenido son los clientes de las CDN.

Replicación de contenido Las CDN instalan cientos de

servidores CDN sobre toda Internet En los ISPs que están más

cerca de los usuarios La CDN replica el contenido

de sus clientes en los servidores CDN. Cuando el proveedor actualiza el contenido, la CDN actualiza los servidores

Servidor origenen Norteamérica

Nodo de distribución CDN

Servidor CDNEn Suarmérica

Servjdor CDNen Europa

Servidor CDNen Asia


Ejemplo de CDN

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

con

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

Solicitud HTTP para

www.foo.com/sports/sports.html

Consulta DNS para www.cdn.com

Solicitud HTTP para

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

1

2

3

Servidor origen

Servidor DNS autoritativo Para las CDNs

Servidor CDN cercano

Compañía CDN cdn.com distribuye archivos gif Utiliza su servidor

DNS autoritativo para enrutar y redirigir las solicitudes


Más sobre CDNsSolicitudes de enrutamiento La CDN crea un mapa

indicando las distancias desde los ISP “hoja” y los nodos CDN

Cuando una consulta llega al servidor DNS autoritativo: El servidor determina el

ISP desde el cual se origina la consulta

Utiliza “mapeo” para determinar el mejor servidor CDN

No sólo páginas web Audio y video

“streaming stored” Audio y video en

“real-time” Los nodos CDN

construyen una overlay network sobre la capa de aplicaciones


Compartiendo archivos P2P

Ejemplo Alicia corre un cliente

para una aplicación P2P sobre su computador

Intermitentemente se conecta a Internet; consigue una dirección IP nueva para cada conexión

Pregunta por “Hey Jude” La aplicación muestra

otros PCs que tienenuna copia de Hey Jude.

Alicia selecciona uno de los PCs, Beto.

El archivo es copiado desde el PC de Beto al computador de Alicia: HTTP

Mientras Alicia descarga, otros usuarios descargan del computador de Alicia.

El PC de alicia ejecuta una plicación que es a la vez un cliente Web y uin servidor Web.

Todos los equipos (peers) se comportan como servidores = ¡servicio altamente escalable!


P2P: directorio centralizado

Diseño original de “Napster”

1) Cuando un PC se conecta, este informa al servidor central: Dirección IP contenido

2) Alicia pregunta por “Hey Jude”

3) Alicia solicita el archivo desde Beto

Servidor de directoriocentralizado

PCs (peers)

Alicia

Beto

1

1

1

12

3


P2P: problemas con directorio centralizado

Un solo punto de falla (fall el directorio, falla todo)

Cuello de botella para el desempeño

Problemas con derechos de autor (Copyright)

la transferencia de archivos es descentralizada, pero la localización de contenido es altamente centralizada


P2P: directorio descentralizado Cada PC o es un líder

de grupo a es asignado a un líder de grupo.

El líder de grupo debe mantener un seguimiento al contenido de todos “sus hijos”.

Un PC consulta a su líder de grupo; un líder de grupo puede consultar a otros líderes de grupo.

ordinary peer

group-leader peer

neighoring re la tionshipsin overlay network


Más sobre directorio descentralizado

overlay network Los PCs son los nodos Hay arcos entre los PCs y

sus líderes de grupo También hay arcos entre

parejas de líderes Vecinos virtualesNodo bootstrap Un PC que se conecte se

le asigna la tarea de ser un líder de grupo o es asignado a un líder

Ventajas del enfoque No hay servidor de

directorio centralizado El servicio de

localización se distribuye en entre los PCs

Más difícil de “derribar”

desventajas del enfoque Se necesita un nodo

de bootstrap Los líderes de grupo

pueden recibir sobrecarga de trabajo


P2P: inundación de consultas

Gnutella No existen jerarquías Utiliza un nodo bootstrap

para aprender sobre los otros Mensaje de asociación ( join

message)

Envía la consulta a sus vecinos Los vecinos reenvían la consulta Si el PCs consultado tiene el

objeto, este envía el mensaje de regreso al PC que hizo la consulta

join


P2P: más sobre inundación de consultas

Ventajas Tienen

responsabilidades similares: no hay líderes en el grupo

Altamente descentralizado

Ningún nodo mantiene información de directorio

Desventajas excesivo tráfico de

consultas query radius: may

not have content when present

bootstrap node maintenance of

overlay network


Capítulo 2: resumen

Requerimientos de servicio de las aplicaciones: confiabilidad, ancho de banda,

delay

Paragdima cliente-servidor

Modelo de servicio de transporte de Internet Orientado a conexión,

confiable: TCP No confiable, datagramas: UDP

Nuestro estudio de aplicaciones de red se ha terminado!

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

Programación con sockets

Distribución de contenido caches, CDNs P2P


Capítulo 2: resumen

Intercambio de mensajes solicitud/respuesta típico: El cliente solicita

información o el servicio El servidor responde con

datos, códigos de estado Formatos de mensaje:

Encabezados: campos que dan información sobre los datos

datos: la información que está siendo transmitida

Más importante: aprender sobre protocolos

control vs. mensajes de datos in-band, out-band

centralizado vs. descentralizado

stateless vs. stateful Transferencia de mensajes

confiables vs. no confiables “complejidad en el borde

de la red” seguridad: autenticación

Capa de Aplicaciones1 Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer...

Documents

Transcript of Capa de Aplicaciones1 Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer...