Transcript chap2_2ed_5July02

Capa de aplicaciones
NOTA: esta presentación es
adaptada de:
Computer Networking: A Top Down
Approach Featuring the Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley.
Capa de Aplicaciones
1
Capa de aplicaciones
Metas:
 Aspectos conceptuales de
la implementación de los
protocolos para las
aplicaciones de red
 Modelos de servicio
de la capa de
transporte
 Paradigma clienteservidor

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
Capa de Aplicaciones
2
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
 Servicio de nombres de
dominio

DNS
 Servicio de directorio

LDAP
 Programación con Sockets


TCP
UDP
 Construyendo un servidor
Web
 Mensajería instantánea

XMPP
Capa de Aplicaciones
3
Aplicaciones de red: algunos
términos
Proceso: instancia de un
Agente de usuario: interfaces
programa que se ejecuta
con el usuario “arriba” y la
dentro de un nodo o
red “abajo”.
contexto de ejecución de un  Implementa la interfaz de
programa que está corriendo.
usuario y el protocolo de la
 Dentro del mismo host, dos
capa de aplicación
procesos se comunican
 Cliente Web: browser
utilizando comunicación
 Cliente E-mail: lector de
entre procesos (definido por
correo
el sistema operativo).
 Cliente de mensajería
 Los procesos que se ejecutan
instantánea: IM client
entre diferentes nodos lo
 Cliente streaming
hacen mediante un protocolo
audio/video: media player
de la capa de aplicación
Capa de Aplicaciones
4
Aplicaciones y protocolos de la capa de
aplicaciones
Aplicaciones: 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
aplicación
transporte
red
enlace
física
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
transporte
red
enlace
física
aplicación
transporte
red
enlace
física
Capa de Aplicaciones
5
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, SMTP
Protocolos proprietarios:
 ejemplo, KaZaA
Capa de Aplicaciones
6
Paradigma cliente-servidor
Las aplicaciones de red típicas
tienen dos partes: el cliente y
el servidor
Cliente:
aplicación
transporte
red
enlace
física
 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
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
solicitud
respuesta
aplicación
transporte
red
enlace
física
Capa de Aplicaciones
7
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á
host o
servidor
host o
servidor
proceso
Controlado por
el desarrollador
proceso
socket
socket
TCP con
buffers,
variables
Internet
TCP con
buffers,
variables
controlado
por OS
 API: (1) selección del protocolo de la capa de transporte; (2)
habilidad para fijar unos pocos parámetros (se estudiará luego)
Capa de Aplicaciones
8
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
Capa de Aplicaciones
9
¿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
Capa de Aplicaciones
10
Requerimientos de servicios de transporte de
aplicaciones comunes
Pérdida
Aplicación de Datos Ancho de Banda
Transferencia de archivos
Correo
Documentos web
audio/video en tiempo real
elástico
elástico
elástico
audio: 5kbps-1Mbps
video:10kbps-5Mbps
audio/video almacenado Tolerante El mismo anterior
Juegos interactivos Tolerante Algunos kbps
Mensajería instantánea No
elástico
No
No
No
Tolerante
Sensitivo al
tiempo
no
no
no
sí, 100’s ms
sí, pocos s
sí, 100’s ms
sí y no
Capa de Aplicaciones
11
Servicios de los protocolos de
transporte de Internet
Servicio de TCP:
Servicio de UDP:

 Transferencia de datos no




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
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
Capa de Aplicaciones
12
Aplicaciones de Internet: aplicación, protocolos de
transporte
Aplicación
e-mail
Acceso remoto
Web
Transferencia de archivos
streaming multimedia
Telefonía Internet
Protocolo de la
capa de aplicación
Protocolo de la
capa de transporte
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietario
(RealNetworks)
proprietary
(Dialpad)
TCP
TCP
TCP
TCP
TCP o UDP
normalmente UDP
Capa de Aplicaciones
13
Correo electrónico
Cola de
mensajes salientes
Agente de
usuario
Tres componentes principales:
 Agentes de usuario
 Servidores de correo
servidor de
correo
 Protocolo simple de
 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
Agente de
usuario
SMTP
transferencia de correo: SMTP
Agente de usuario
Buzón del
usuario
SMTP
SMTP
Servidor de
correo
Servidor de
correo
Agente de
usuario
Agente de
usuario
Agente de
usuario
Agente de
usuario
Capa de Aplicaciones
14
Correo electrónico: servidores de
correo
Agente de
usuario
Servidores 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 de
correo
Agente de
usuario
SMTP
SMTP
SMTP
Servidor de
correo
Servidor de
correo
Agente de
usuario
Agente de
usuario
Agente de
usuario
Agente de
usuario
Capa de Aplicaciones
15
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
Capa de Aplicaciones
16
Escenario: Alicia envía un mensaje a
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
1) 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
1
Agente de
usuario
2
Servidor de
correo
Servidor de
correo
3
4
5
6
Agente de
usuario
Capa de Aplicaciones
17
Ejemplo de la interacción SMTP
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
¿Te gusta la salsa de tomate?
¿y los pepinillos?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Capa de Aplicaciones
18
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
Capa de Aplicaciones
19
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”
Capa de Aplicaciones
20
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,



header
Línea en
blanco
body
To:
From:
Subject:
¡Son diferentes a los
comandos SMTP!
 Cuerpo (body)

Es el “mensaje”, sólo
permite caracteres ASCII
Capa de Aplicaciones
21
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
Versión de MIME
Método utilizado
para codificar datos
Tipo de dato
multimedia, subtipo,
parámetro de
declaración
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
Datos codificados
Capa de Aplicaciones
22
Tipos MIME
Content-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
Capa de Aplicaciones
23
Tipo Multipart
From: [email protected]
To: [email protected]
Subject: Imagen de un crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--StartOfNextPart
Hola Beto, por favor encuentra la imagen de un crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNextPart
¿te gustaría tener la receta?
Capa de Aplicaciones
24
Protocolos de acceso al correo
SMTP
Agente de
usuario
Servidor de correo
del remitente
SMTP
Protocolo de
Agente de
Acceso
usuario
Servidor de correo
del destinatario
 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.
Capa de Aplicaciones
25
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
S:
C:
S:
C:
S:
+OK POP3 server ready
user beto
+OK
pass goloso
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
Capa de Aplicaciones
on
26
POP3 e IMAP
Má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
Capa de Aplicaciones
27
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
Capa de Aplicaciones
28
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 ejecutando
IE Explorer
Servidor
ejecutando
El servidor Web
Apache
Mac ejecutando
Netscape Navigator
Capa de Aplicaciones
29
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
NOTA
¡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”
Capa de Aplicaciones
30
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
Capa de Aplicaciones
31
HTTP No persistente
Supongamos que el usuario ingresa el URL
www.algunsitio.edu/algunaFacultad/index.html
(contiene texto,
referencia a 10
imágenes jpeg)
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
tiempo
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
Capa de Aplicaciones
32
HTTP No persistente (cont.)
4. El servidor HTTP cierra la
5. El cliente HTTP recibe el
conexión TCP.
mensaje de repuesta que
contiene el archivo html,
muestra el html. Al recorrer
el archivo html encuentra 10
objetos jpeg referenciados
tiempo 6. Los pasos 1 a 5 se repiten
para cada uno de los 10
objetos jpeg
Capa de Aplicaciones
33
Modelamiento del tiempo de
respuesta
Definició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
Inicia Conexión
TCP
RTT
solicita
archivo
tiempo para
transmitir
archivo
RTT
archivo
recibido
tiempo
tiempo
Capa de Aplicaciones
34
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
Capa de Aplicaciones
35
Mensaje de solicitud HTTP
 HTTP tiene dos tipos de mensajes:
response
request,
 Mensaje de solicitud:
 ASCII (formato legible para nosotros)
Línea de solicitud
(comandos GET, POST,
HEAD)
GET /algundir/pagina.html HTTP/1.1
Host: www.algunsitio.edu
Líneas de User-agent: Mozilla/4.0
Connection: close
encabezado
Accept-language:fr
“Carriage return,
line feed”
Indica el final
del mensaje
(“carriage return, line feed” adicional)
Capa de Aplicaciones
36
Mensaje de solicitud HTTP: formato
general
Capa de Aplicaciones
37
Enviando datos al servidor desde un
formulario HTML
Usando 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
Capa de Aplicaciones
38
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
Capa de Aplicaciones
39
Mensaje de respuesta de HTTP
Línea de estado
(código de
estado del
Protocolo,
frase de estado)
Líneas
de encabezado
datos, es decir,
archivo HTML
solicitado
HTTP/1.1 200 OK
Connection close
Date: 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 ...
Capa de Aplicaciones
40
Códigos de estado de HTTP
Se usan en la primera línea del mensaje de respuesta
del servidor->cliente. Ejemplos:
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
Capa de Aplicaciones
41
Conexión HTTP (cliente) hecha “a mano”
1. Conéctese, a través de telnet al puerto 80, a su sitio Web favorito:
telnet www.arcesio.net 80 Abre una conexión TCP al puerto 80
(puerto “bien conocido” de HTTP) en
www.arcesio.net.
Cualquier cosa que se digite será enviada
Al puerto 80 en www.arcesio.net
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!
Capa de Aplicaciones
42
Interacción usuario-servidor:
autorización
Autorización : control de acceso
servidor
cliente
al contenido del servidor
Solicitud http usual
 Credenciales de autorización:
normalmente un nombre y una
401: authorization req.
WWW authenticate:
clave (password)
 stateless: el cliente debe
presentar la autorización
Solicitud http usual
cada vez que haga una
+ Autorización: <cred>
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 header
WWW authenticate:
En respuesta
Respuesta http usual
Solicitud http usual
+ Autorización: <cred>
Respuesta http usual
tiempo
Capa de Aplicaciones
43
Cookies: guardando el “estado”
Muchos sitios Web utilizan
cookies
Cuatro 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 ecommerce 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
Capa de Aplicaciones
44
Cookies: guardando el “estado” (cont.)
cliente
Archivo
Cookie
ebay: 8734
Archivo
Cookie
amazon: 1678
ebay: 8734
servidor
Solicitud http usual
Respuesta http usual +
Set-cookie: 1678
Solicitud http usual
cookie: 1678
Respuesta http usual
El servidor
crea el ID
1678 para
el usuario
Acción
específica
para cookie
Una semana después:
Archivo
Cookie
amazon: 1678
ebay: 8734
Solicitud http usual
cookie: 1678
Respuesta http usual
Acción
específica
para cookie
Capa de Aplicaciones
45
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)
NOTA
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
Capa de Aplicaciones
46
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
HTTP
If-modified-since:
<fecha>
 servidor: La respuesta no
lleva el objeto si la copia en
cache está actualizada:
HTTP/1.0 304 Not
Modified
servidor
cliente
Solicitud HTTP
If-modified-since:
<fecha>
Respuesta HTTP
objeto
no
modificado
HTTP/1.0
304 Not Modified
Solicitud HTTP
If-modified-since:
<fecha>
Respuesta HTTP
objecto
modificado
HTTP/1.0 200 OK
<datos>
Capa de Aplicaciones
47
FTP: protocolo de transferencia de
archivos
Interface
Cliente
para
FTP
usuario FTP
usuario
Transferencia del
archivo
Sistema de
archivos local
Servidor
FTP
Sistema de
archivos remoto
 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
Capa de Aplicaciones
48
FTP: control separado de la conexión
para datos
Puerto 21, conexión
TCP de control
 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.
Cliente
FTP
Puerto 20, conexión
TCP para datos Servidor
FTP
 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
Capa de Aplicaciones
49
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
Capa de Aplicaciones
50
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).
Capa de Aplicaciones
51
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.
Capa de Aplicaciones
52
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.
Capa de Aplicaciones
53
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 (clientto-server)
 Puerto 5269/TCP (serverto-server)
Cliente
XMPP

Servidor
XMPP
Servidor
XMPP
Cliente
XMPP
Cliente
XMPP
Gateway
Traduce entre
XMPP y NO-XMPP
Cliente
NO- XMPP
Servidor IM
NO-XMPP
Capa de Aplicaciones
54
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.
Capa de Aplicaciones
55
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
Capa de Aplicaciones
56
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

Capa de Aplicaciones
57
DNS: Domain Name System
Las personas: tienen muchos
identificacdores:

Cédula, nombre, pasaporte
Identificadores 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
Capa de Aplicaciones
58
Servidores de nombres DNS
¿Por qué no un DNS
centralizado?
 Un solo punto de falla
 Alto volumen de tráfico
 Base de datos
centralizada distante
 mantenimiento
 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:

¡ NO PUEDE ESCALAR !

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
Capa de Aplicaciones
59
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
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
13 servidores
raíz en el mundo
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
Capa de Aplicaciones
60
Ejemplo Simple de DNS
surf.eurecom.fr
desea saber la
dirección IP de
gaia.cs.umass.edu
DNS raíz
2
4
5
1. Contacta su servidor DNS
local, dns.eurecom.fr
DNS local
2. dns.eurecom.fr contacta
dns.eurecom.fr
el servidor de nombres
1
raíz, si es necesario
6
3. El servidor de nombres raíz
contacta el servidor de
nombres autoritativo,
Nodo que consulta
dns.umass.edu, si es
surf.eurecom.fr
necesario
3
DNS autoritativo
dns.umass.edu
gaia.cs.umass.edu
Capa de Aplicaciones
61
Ejemplo de DNS
DNS Raíz
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
6
2
7
DNS local
dns.eurecom.fr
1
8
Nodo que consulta
3
DNS intermedio
dns.umass.edu
4
5
DNS autoritativo
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
Capa de Aplicaciones
62
DNS: consultas iterativas
Consulta recursiva:
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”
Consulta
iterada
2
 Coloca un bloque de
consultas de resolución
de nombres sobre el
servidor de nombres
contactado
 ¿demasiada carga?
DNS raíz
3
4
7
DNS local
dns.eurecom.fr
1
8
Nodo que consulta
DNS intermedio
dns.umass.edu
5
6
DNS autoritativo
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
Capa de Aplicaciones
63
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
Capa de Aplicaciones
64
Registros del DNS
DNS: registros de recursos (RR) almacenados en una base de datos distribuida
Fromato RR: (name,
value, type, ttl)
 Type=A
 Type=CNAME
 name es un nombre de
 name es un alias para algún
hosts
nombre “canónico” (el nombre
real)
 value es una dirección IP
www.ibm.com es realmente
 Type=NS
servereast.backup2.ibm.com
 name es un dominio (por
 value es el nombre canónico
ejmplo. sitio.com)
 Type=MX
 value es una dirección IP
 value es el nombre de un
de un DNS autoritativo para
servidor de correo asociado con
este dominio
name
Capa de Aplicaciones
65
Protocolo DNS y mensajes DNS
Protocolo DNS: mensajes de query y reply, juntos
tienen el mismo formato de mensaje
identificación
flags
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
número de consultas
número de RRs respondidos
Número de RRs autoritativos
Número de RRs adicionales
12 bytes
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)
Capa de Aplicaciones
66
Protocolo DNS y mensajes DNS
Nombre, campos tipo
Para una consulta
RRs en respuesta
A una consulta
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
Registros para
servidores autoritativos
Información adicional
útil que puede usarse
(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)
Capa de Aplicaciones
67
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).
Capa de Aplicaciones
68
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.
Capa de Aplicaciones
69
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.
Capa de Aplicaciones
70
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).
Capa de Aplicaciones
71
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
Capa de Aplicaciones
72
Programación con sockets
Meta: aprender cómo construir aplicaciones
cliente/servidor que se comuniquen utilizando 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)
socket
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
Capa de Aplicaciones
73
Programación con sockets
utilizando TCP
Socket: 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
controlado por
el desarrollador
de la aplicación
controlado por
el sistema
operativo
proceso
proceso
socket
TCP con
buffers,
variables
host o
servidor
internet
socket
TCP con
buffers,
variables
controlado por
el desarrollador
de la aplicación
controlado por
el sistema
operativo
host o
servidor
Capa de Aplicaciones
74
Programando sockets con TCP
El 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)
Para la aplicación…
TCP permite transferir bytes
de manera confiable, en orden
(“un tubo”), entre el cliente
Y el servidor
Capa de Aplicaciones
75
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.
Capa de Aplicaciones
76
Programando sockets con TCP
output
stream
inFromUser
Proceso
Process
cliente
input
stream
outToServer
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)
monitor
inFromServer
Ejemplo de una aplicación
cliente-servidor:
keyboard
input
stream
Socket
TCP
clientSocket
del cliente
to netw ork
TCP
socket
from netw ork
Capa de Aplicaciones
77
Interacción de sockets en
cliente/servidor: TCP
Servidor (ejecutando en hostid)
Cliente
crea socket,
port=x, para
recibir solicitudes:
welcomeSocket =
ServerSocket()
establece conexión
TCP
espera solicitudes
de conexión
connectionSocket =
welcomeSocket.accept()
envía solicitudes usando
clientSocket
lee solicitudes desde
connectionSocket
escribe las respuestas en
connectionSocket
cierra
connectionSocket
crea socket,
se conecta a hostid, port=x
clientSocket =
Socket()
cierra conexión
TCP
lee respuestas de
clientSocket
cierra
clientSocket
Capa de Aplicaciones
78
Ejemplo: Cliente Java (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
Crea
input stream
asociado al teclado
Crea socket
para el cliente,
conecta al servidor
Crea
output stream
asociado al socket
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());
Capa de Aplicaciones
79
Ejemplo: Cliente Java (TCP), cont.
Crea
input stream
asociado al socket
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
Envía la línea
al servidor
outToServer.writeBytes(sentence + '\n');
Lee la línea
desde el servidor
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Capa de Aplicaciones
80
Ejemplo: Servidor Java (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
Crea
socket de bienvenida
en el puerto 6789
Espera,
crea un socket
para ser contactado
por el cliente
Crea un input
stream, asociado
al socket
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()));
Capa de Aplicaciones
81
Ejemplo: Servidor Java (TCP), cont.
Crea output
stream, asociado
al socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Lee la línea
desde el socket
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Escribe la línea
al socket
outToClient.writeBytes(capitalizedSentence);
}
}
}
Fin del ciclo while,
regresa al inicio del ciclo y espera
otra conexión de cliente
Capa de Aplicaciones
82
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
Capa de Aplicaciones
83
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
Para la aplicación…
UDP transfiere de manera
no confiable grupos de bytes
(“datagramas”) entre el
cliente y el servidor
UDP: los datos transmitidos
pueden ser recibidos fuera
de orden o pueden ser
perdidos
Capa de Aplicaciones
84
Interacción de sockets en
cliente/servidor: UDP
Servidor (ejecutando en hostid)
crea socket,
port=x, para
recibir solicitudes:
serverSocket =
DatagramSocket()
Lee la solicitud desde
serverSocket
Escribe la respuesta en
serverSocket
Especificando la dirección
IP del cliente y el
número de puerto
Cliente
crea socket,
clientSocket =
DatagramSocket()
Crea, asocia dirección (hostid, port=x)
envía datagrama de solicitud
usando clientSocket
Lee la respuesta desde
clientSocket
cierra
clientSocket
Capa de Aplicaciones
85
Ejemplo: Cliente Java (UDP)
input
stream
Proceso
cliente
monitor
inFromUser
keyboard
Process
Input: recibe
paquetes (TCP
recibe “byte
stream”)
UDP
packet
receivePacket
paquetes (TCP
envía “byte
stream”)
sendPacket
Output: envía
client
UDP
clientSocket
socket
to netw ork
UDP
packet
UDP
socket
f rom netw ork
Capa de Aplicaciones
86
Ejemplo: Cliente Java (UDP)
import java.io.*;
import java.net.*;
Crea
input stream
Crea
socket para
el client
Traslada
nombre de host
a dirección IP
utilizando el DNS
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();
Capa de Aplicaciones
87
Ejemplo: Cliente Java (UDP), cont.
Crea datagrama con
la longitud de datosa-enviar, dirección
IP, puerto
Envía datagrama
al servidor
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
Lee datagrama
desde el servidor
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
Capa de Aplicaciones
88
Ejemplo: Servidor Java (UDP)
import java.io.*;
import java.net.*;
Crea socket tipo
Datagrama en el
puerto 9876
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)
{
Crea espacio para
recibir datagrama
Recibe
datagrama
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Capa de Aplicaciones
89
Ejemplo: Servidor Java (UDP), cont
String sentence = new String(receivePacket.getData());
Consigue le
dirección IP
puerto #, del
solicitante
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Crea datagrama
para envíar
al cliente
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
Escribe el
datagrama
en el socket
serverSocket.send(sendPacket);
}
}
}
Fin del ciclo while,
regresa al inicio y espera
otro datagrama
Capa de Aplicaciones
90
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:

 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
Líneas de header + archivo
 Envía la respuesta al cliente
Capa de Aplicaciones
91
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-12sockets.html
 “Socket Programming in Java: a tutorial,”
http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html
Capa de Aplicaciones
92
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
Capa de Aplicaciones
93
Cache en Web (servidor proxy)
Meta: satisfacer las solicitudes del cliente sin involucrar
el servidor origen
 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
Servidor
origen
cliente
cliente
Servidor
Proxy
Servidor
origen
Capa de Aplicaciones
94
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
Capa de Aplicaciones
95
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
Servidores
origen
Internet
pública
Enlace de acceso
1.5 Mbps
Red
institucional
LAN a 10 Mbps
Capa de Aplicaciones
96
Ejemplo de Caching (2)
Posible solución
 Incrementar ancho de banda
del enlace de acceso, digamos
a 10 Mbps
Consecuencias
Servidores
origen
Internet
pública
 Utilización de la LAN = 15%
Enlace de acceso
10 Mbps
 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
Red
institucional
LAN a 10 Mbps
Capa de Aplicaciones
97
Ejemplo de Caching (3)
Servidores
origen
Instalando servidor cahe

Supongamos que la tasa de hits es
.4
Consecuencia




=
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
Internet
pública
Enlace de acceso
Red
institucional
1.5 Mbps
10 Mbps LAN
Cache
institucional
Capa de Aplicaciones
98
Redes de distribución de contenido
(CDNs)
 Los proveedores de contenido
Servidor origen
en Norteamérica
son los clientes de las CDN.
Replicación de contenido
 Las CDN instalan cientos de
Nodo de distribución CDN
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 Servidor CDN
Servidor CDN
En Suarmérica
proveedor actualiza el
Servjdor CDN en Asia
contenido, la CDN actualiza
en Europa
los servidores
Capa de Aplicaciones
99
Ejemplo de CDN
Solicitud HTTP para
www.foo.com/sports/sports.html
Servidor origen
1
2
3
Consulta DNS para www.cdn.com
Servidor DNS autoritativo
Para las CDNs
Solicitud HTTP para
www.cdn.com/www.foo.com/sports/ruth.gif
Servidor CDN cercano
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
Compañía CDN
 cdn.com
 distribuye archivos gif
 Utiliza su servidor
DNS autoritativo para
enrutar y redirigir las
solicitudes
Capa de Aplicaciones 100
Más sobre CDNs
Solicitudes 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 “realtime”

Los nodos CDN
construyen una overlay
network sobre la capa
de aplicaciones
Capa de Aplicaciones
101
Compartiendo archivos P2P
 Alicia selecciona uno de los
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.
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! Capa de Aplicaciones
102
P2P: directorio centralizado
Diseño original de
Servidor de directorio
centralizado
“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
2
Beto
1
PCs (peers)
1
3
1
1
Alicia
Capa de Aplicaciones
103
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
Capa de Aplicaciones
104
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 relationships
in overlay network
Capa de Aplicaciones
105
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 virtuales
Nodo 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
Capa de Aplicaciones
106
P2P: inundación de consultas
 Gnutella
 Envía la consulta a sus vecinos
 No existen jerarquías
 Los vecinos reenvían la
 Utiliza un nodo bootstrap
para aprender sobre los
otros
 Mensaje de asociación (
join message)
consulta
 Si el PCs consultado tiene el
objeto, este envía el mensaje
de regreso al PC que hizo la
consulta
join
Capa de Aplicaciones
107
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
Capa de Aplicaciones
108
Capítulo 2: resumen
Nuestro estudio de aplicaciones de red se ha
terminado!
 Requerimientos de
 Protocolos específicos:
servicio de las
 HTTP
aplicaciones:
 FTP

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


SMTP, POP, IMAP
DNS
 Programación con
sockets
 Distribución de
contenido


caches, CDNs
P2P
Capa de Aplicaciones
109
Capítulo 2: resumen
Más importante: aprender sobre protocolos
 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
 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 Aplicaciones
110