Capítulo 2

Capa de Aplicación

Nota sobre el uso de estas diapositivas ppt:

Proporcionamos estas diapositivas de forma gratuita para todos (profesores,
estudiantes, lectores). Se encuentran en formato PowerPoint, por lo que
puede añadir, modificar y borrar diapositivas (incluida la presente) y su
Redes de
contenido según sus necesidades. Evidentemente, significan un gran computadores: un
trabajo por nuestra parte. A cambio, sólo pedimos para su uso:
q que mencione la fuente si usa estas diapositivas (por ejemplo, en clase), enfoque descendente
sin alterar su contenido de forma considerable (¡nos gustaría que la gente basado en Internet,
usara nuestro libro!).
q que indique que dichas diapositivas son una adaptación o copia de las 2ª edición.
nuestras y que muestre el copyright de nuestro material si cuelga las Jim Kurose, Keith Ross
mismas en un sitio web, sin alterar su contenido de forma considerable.
¡Gracias y disfrute! JFK/KWR

Copyright 1996-2002.
J.F Kurose y K.W. Ross.
Todos los derechos reservados.
Capítulo 2: Capa de aplicación
Nuestros objetivos: r Aprendizaje de
r Aspectos conceptuales protocolos por medio
y de implementación de del estudio de
los protocolos de las protocolos a nivel de
aplicaciones de red. aplicación.
m Modelos de servicio m HTTP.
m FTP.
de la capa de
m SMTP / POP3 / IMAP.
transportes
m DNS.
m Paradigma cliente-
servidor. r Programación de
m Paradigma entre iguales. aplicaciones de red.
m Socket de API.
Capítulo 2: Tabla de contenidos
r 2.6 Programación de
r 2.1 Principios de los sockets con TCP.
protocolos de la capa r 2.7 Programación de
de aplicación.
r 2.2 La Web y HTTP.
sockets con UDP.
r 2.8 Construcción de un
r 2.3 Transferencia de
archivos: FTP. servidor web sencillo.
r 2.4 Correo electrónico r 2.9 Distribución de
en Internet. contenidos:
m SMTP, POP3, IMAP. m Caché web.
r 2.5 DNS: el servicio de m Redes de distribución de
contenidos.
directorio de m Compartición de archivos
Internet. entre iguales.
Aplicaciones de red: jerga
Proceso: programa que se Agentes de usuario:
ejecuta en un host. interfaces con un
r En el mismo host, dos usuario “por encima” y
una red “por debajo”.
procesos se comunican
r Implementa interfaces
utilizando comunicación
de usuario y protocolos
interproceso (definidos
a nivel de aplicación.
por un sistema m Web: navegador.
operativo). m Correo electrónico:
r Los procesos que se lector de correo.
m Transmisión de
ejecutan en diferentes
audio/vídeo:
hosts se comunican con reproductor multimedia.
un protocolo de capa de
aplicación.
Aplicaciones y protocolos de la capa de aplicación
Aplicación: comunicación,
procesos distributivos. Aplicación
Transporte
Red
m Por ejemplo: correo electrónico, Enlace de datos
Física
web, compartición de archivos
entre iguales, mensajería
instantánea.
m Funcionamiento en sistemas finales
(hosts).
m Intercambio de mensajes para la
implementación de aplicaciones.
Protocolos de capa de aplicación
m Una “parte” de la aplicación. Aplicación
Aplicación
Transporte
Transporte
m Definición de mensajes Red
Red
Enlace de datos

intercambiados entre las Enlace de datos

Física
Física

aplicaciones y las acciones

tomadas.
m Uso de servicios de comunicación
proporcionados por los protocolos
de capas inferiores (TCP, UDP).
Características de los
protocolos de capa de aplicación
r Los tipos de mensajes
Protocolos de dominio
intercambiados, por
ejemplo, mensajes de público:
petición y de respuesta. r Definidos en RFC.
r Sintaxis de los tipos de
r Permiten
mensajes: qué campos hay
en los mensajes y cómo interoperabilidad.
están delineados estos r Por ejemplo: HTTP,
campos.
r Semántica de los campos, SMTP.
por ejemplo, significado de Protocolos de propietarios:
la información en los
campos. r Por ejemplo: KaZaA.
r Reglas que determinan
cuándo y cómo los procesos
envían y responden a los
mensajes.
Paradigma del cliente-servidor
La aplicación de red típicamente
Aplicación
tiene dos partes: el cliente y el Transporte
servidor Red
Enlace de datos
Física

Cliente: Petición
r Inicia el contacto con el servidor
(“habla primero”).
r Normalmente solicita un servicio
del servidor.
r Web: cliente implementado en el Respuesta
navegador; correo electrónico: en
Aplicación
el lector de correo. Transporte
Red
Servidor: Enlace de datos
Física

r Proporciona el servicio solicitado al cliente.

r Por ejemplo, el servidor de Web envía la
página Web solicitada, el servidor de
correo entrega el correo electrónico.
 Procesos que se comunican a través de la red
r El proceso envía/recibe
Host o Host
mensajes a/de su socket. servidor o servidor
r El socket es análogo a una
controlado por
puerta: el desarrollador
m El proceso emisor empuja el proceso de la aplicación proceso
mensaje por su puerta. socket socket
m Este proceso asume la
TCP con TCP con
existencia de una búferes, Internet búferes,
infraestructura de transporte variables variables
al otro lado de la puerta que
transportará el mensaje al
socket en el proceso receptor. controlado
por el sistema
operativo
r API: (1) elección del protocolo de transporte; (2)
posibilidad de fijar algunos parámetros (más adelante se
tratará este tema con mucha más profundidad).
Direccionamiento de procesos:
r Para que un proceso r El identificador incluye
reciba mensajes debe tanto la dirección IP
tener un identificador.
r Cada host tiene una única
como los números de
dirección IP de 32 bits. puerto asociados con el
r Pregunta: ¿Basta con la proceso del host.
dirección IP del host, en r Ejemplos de números
el que el proceso se de puerto:
ejecuta, para identificar m Servidor HTTP: 80.
el proceso?
r Respuesta: No, ya que
m Servidor de correo: 25.
muchos procesos r Más adelante se
diferentes pueden estar tratará este tema con
ejecutándose en el mismo más profundidad.
host.
¿Qué servicio de transporte necesita una
aplicación?
Pérdida de datos Ancho de banda
r Ciertas aplicaciones (por r Algunas aplicaciones (por
ejemplo, audio) pueden tolerar ejemplo, multimedia)
algunas pérdidas.
requieren un mínimo de
r Otras aplicaciones (por
ancho de banda para ser
ejemplo, transferencia de
archivos, Telnet) requieren el “efectivas”.
100 por ciento de r Otras aplicaciones
transferencia fiable de datos. (“aplicaciones flexibles”)
Temporización hacen uso de cualquier
r Algunas aplicaciones (por
ancho de banda que tengan
ejemplo, telefonía de a su disposición.
Internet, juegos
interactivos) requieren un
retardo lento para ser
“efectivas”.
 Requisitos de los servicios de transporte para
aplicaciones comunes
Sensible al tiempo
Aplicación Pérdida de datos Ancho de banda

Transferencia de archivos No pérdida flexible No

Correo electrónico No pérdida flexible No
Documentos Web No pérdida flexible No
Audio/vídeo de Tolerante Audio: 5Kbps-1Mbps Sí, 100 mseg
tiempo real Vídeo:10Kbps-5Mbp
Audio/vídeo almacenado s
Tolerante Sí, pocos seg
Juegos interactivos Igual que el anterior
Tolerante Sí, 100 mseg
Mensajería instantánea Pocos Kbps-10Kbps
No pérdida Sí y no
Flexible
Servicios de los protocolos de
transporte de Internet
Servicio TCP: Servicio UDP:
r Transferencia de datos no
r Orientado a la conexión:
fiable entre el proceso
Sistema requerido entre el
emisor y el receptor.
cliente y el servidor.
r No proporciona: sistema
r Transporte fiable entre el de conexión, fiabilidad,
proceso emisor y el receptor. control de flujo, control
r Control de flujo: el emisor no de congestión,
debe sobrecargar al receptor. temporización y garantía
de ancho de banda.
r Control de congestión:
regulación del emisor si la red
se sobrecarga. PREGUNTA: ¿Por qué
tomarse la molestia? ¿Por
r No proporciona: qué existe un UDP?
temporización, garantías de
un ancho de banda mínimo.
 Aplicaciones de Internet: aplicación, protocolos de
transporte
Protocolo de la capa Protocolo de ransporte
Aplicaciones de aplicación subyacente

Correo electrónico SMTP [RFC 2821] TCP

Acceso a terminales remotos Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
Transferencia de archivos FTP [RFC 959] TCP
Flujo de multimedia Propietario TCP o UDP
(por ejemplo, Real Networks)
Telefonía Internet Propietario
(por ejemplo, Dialpad) Típicamente UDP
Capítulo 2: Tabla de contenidos
r 2.1 Principios de los r 2.6 Programación de
protocolos de la capa sockets con TCP.
de aplicación. r 2.7 Programación de
r 2.2 La Web y HTTP. sockets con UDP.
r 2.3 Transferencia de r 2.8 Construcción de un
archivos: FTP. servidor web sencillo.
r 2.4 Correo electrónico r 2.9 Distribución de
en Internet. contenidos:
m Caché web.
m SMTP, POP3, IMAP.
m Redes de distribución de
r 2.5 DNS: el servicio de contenidos.
directorio de m Compartición de archivos
Internet. entre iguales.
La Web y HTTP
En primer lugar, un poco de jerga
r Una página web consta de objectos.
r Un objeto puede ser un archivo HTML, una imagen
JPEG,un applet Java, un archivo de audio, etc.
r Una página web está formada por un archivo HTML
base, que incluye diversos objetos referenciados.
r Cada objeto es direccionable por un URL.
r Ejemplo de URL:

www.escuela.edu/departamento/imagen.gif

nombre de host nombre de ruta

Introducción a HTTP
HTTP: protocolo de
transferencia de
hipertexto: Pet
r Protocolo de la capa de ició
nH
R
PC ejecutando esp TT
aplicación de la Web. u P
el Explorer es ta
r Modelo cliente/servidor: HT
TP
m cliente: navegador que
solicita, recibe y
“descarga” objetos Web. T TP
iónH TP Servidor
m servidor: servidor Web ti c HT
Pe s ta ejecutando
que envía los objetos e
e spu el servidor Web
correspondientes en R Apache
respuesta a las
peticiones.
Mac ejecutando
r HTTP 1.0: RFC 1945
el Navigator
r HTTP 1.1: RFC 2068
Introducción a HTTP
Usos de TCP:
r El cliente inicia la conexión
TCP (crea un socket) al
servidor, puerto 80.
r El servidor accepta la
conexión TCP del cliente.
r Los mensajes HTTP
(mensajes de protocolo de la
capa de aplicación)
intercambiados entre el
navegador ( cliente HTTP) y
el servidor Web (servidor
HTTP)
r La conexión TCP se cierra.
HTTP está “sin estado”
r El servidor no conserva
ninguna información sobre
las peticiones previas de
clientes.
aparte
Los protocolos que conservan
“estado” son complicados
r La historia previa (estado)
debe conservarse.
r Si el servidor/cliente se
bloquea, sus visiones del
“estado” pueden ser
inconsistentes y deben ser
recompuestas.
Conexiones HTTP
Conexiones HTTP no Conexiones HTTP
persistentes persistentes
r Se envía un objeto r Se pueden enviar
como máximo con una múltiples objetos con
conexión TCP. una sola conexión TCP
r HTTP/1.0 utiliza entre el cliente y el
conexiones HTTP no servidor.
persistentes. r HTTP/1.1 utiliza
conexiones
persistentes en su
modo por defecto.
 Conexiones HTTP no persistentes
(consta de texto
Supongamos que el usuario entra en el URL:
y referencias a 10
www.escuela.edu/departamento/home.index
imágenes jpeg)

1a. El cliente HTTP inicia la

conexión TCP con el servidor
HTTP (proceso) de 1b. El servidor HTTP en el host
www.escuela.edu en el puerto www.escuela.edu espera la
80. conexión TCP del puerto 80 y
“acepta” la conexión,
2. El cliente HTTP envía un notificando al cliente.
mensaje HTTP de petición
(que contiene el URL) a
3. El servidor HTTP recibe el
través del socket de la
mensaje de petición,
conexión TCP. El mensaje
compone un mensaje de
indica que el cliente quiere el
respuesta que contiene el
objeto
objeto solicitado, y lo envía
departamento/home.index.
al socket.
Tiempo
 Conexiones HTTP no persistentes

4. El servidor HTTP cierra la

conexión TCP.
5. El cliente HTTP recibe el
mensaje de respuesta que
contiene el archivo html y
descarga el html. Analizando
el archivo html, se encuentran
referenciados 10 objetos jpeg.
Tiempo
6. Se repiten los pasos del 1 al 5
para cada uno de los 10
objetos jpeg.
 Modelo del tiempo de respuesta
Definición de RRT: tiempo
necesario para enviar un
paquete pequeño desde el
cliente hasta el servidor y
después de vuelta al cliente. Inicio de
la conexión
Tiempo de respuesta: TCP RTT
r Un RTT para iniciar la Petición
conexión TCP. de archivo
Tiempo de
r Un RTT para la petición RTT
transmisión
HTTP y los primeros bytes del archivo
Archivo
de respuesta HTTP de recibido
vuelta.
r Tiempo de transmisión del
Tiempo Tiempo
archivo:
total = 2RTT+tiempo de transmisión
Conexiones HTTP persistentes
Particularidades de HTTP no
persistente:
r Requieren dos RTT por objeto.
r El sistema operativo debe
funcionar y asignar los
recursos del host para cada
conexión TCP.
r Sin embargo, los navegadores
suelen abrir conexiones TCP
paralelas para traer los objetos
referenciados.
HTTP persistente:
r El servidor deja la conexión
abierta tras enviar la
respuesta.
r Los mensajes HTTP posteriores
entre el mismo cliente/servidor
se envían por la misma conexión.
Conexiones persistentes sin
entubamiento:
r El cliente sólo emite una
nueva petición una vez que
ha recibido la anterior
respuesta.
r Un RTT por cada objeto
referenciado.
Conexiones persistentes con
entubamiento:
r Por defecto en HTTP/1.1
r El cliente hace su petición
tan pronto como encuentra
un objeto referenciado.
r Tan sólo un RTT para todos
los objetos referenciados.
 Mensaje HTTP de petición

r Hay dos tipos de mensajes HTTP: de petición, de

respuesta.
r Mensaje HTTP de petición:
m ASCII (formato leído por personas )
Línea de petición
(GET, POST, GET /dir/pagina.html HTTP/1.1
comandos HEAD) Host: www.escuela.edu
User-agent: Mozilla/4.0
Líneas de Connection: close
cabecera Accept-language:fr

Retorno de carro y
avance de línea (Retorno de carro extra, avance de línea)
que indican el final
del mensaje
Mensaje HTTP de petición: formato general

Línea de
método versión
petición
Nombre del campo de
cabecera
valor
Líneas de
cabecera
Nombre del campo de valor
cabecera

Cuerpo de
entidad
Descarga de la entrada de formulario

Método POST:
r La página Web suele Método URL:
r Utiliza el método GET.
incluir una entrada de
r La entrada se descarga en
formulario.
el campo URL de la línea de
r La entrada se petición:
descarga al servidor
en el cuerpo de
entidad.
www.somesite.com/animalsearch?monkeys&banana
Tipos de métodos
HTTP/1.0 HTTP/1.1
r GET. r GET, POST, HEAD.
r POST. r PUT:
r HEAD. m Descarga el archivo en
el cuerpo de entidad a
m Pide al servidor que
la ruta especificada en
excluya el objeto
el campo URL.
solicitado de la
respuesta. r DELETE:
m Borra el archivo
especificado en el
campo URL.
 Mensaje HTTP de respuesta
Línea de estatus
(protocolo del
código de estatus
HTTP/1.1 200 OK
y la frase
Connection close
de estatus) Date: Thu, 06 Aug 1998 12:00:15 GMT
Líneas de Server: Apache/1.3.0 (Unix)
cabecera Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html

Datos, por ejemplo, datos datos datos datos datos ...

el archivo
HTML solicitado
Código de estatus HTTP de respuesta
En la primera línea en el mensaje de respuesta servidor -> cliente.
Algunos ejemplos de códigos:

200 OK
m petición exitosa, el objeto requerido aparece
posteriormente en este mensaje.
301 Moved Permanently
m el objeto demandado ha sido movido, su nueva localización
se especifica posteriormente en este mensaje (Location:).
400 Bad Request
m el servidor no comprendió el mensaje de petición.
404 Not Found
m el documento pedido no existe en este servidor.
505 HTTP Version Not Supported
 Ponga a prueba el HTTP (como cliente)
usted mismo
1. Telnet a su servidor web favorito:
telnet www.eurecom.fr 80 Abre la conexión TCP al puerto 80.
(por defecto puerto servidor HTTP) en
www.eurecom.fr.
Cualquier cosa que se escriba es enviada a
www.eurecom.fr
2. Escriba una petición HTTP tipo GET:
GET /~ross/index.html HTTP/1.0 Escribiendo esto (con doble retorno
de carro), está enviando esta petición
GET mínima (pero completa) al servidor
HTTP.

3. Mire el mensaje de respuesta enviado por el servidor

HTTP.
 Interacción usuario-servidor: autorización

Autorización : control al acceso del cliente servidor

contenido del servidor. Típico mensaje http de petición
r Credenciales de autorización,
normalmente son: nombre, 401: autorización solic.
contraseña. WWW authenticate:
r Sin estado: el cliente debe
presentar la autorización para
Típico mensaje http de petición
cada petición:
+ Autorización: <cred>
m Autorización: línea de
cabecera en cada petición. Típico mensaje de respuesta
m Si no hay autorización:
cabecera, el servidor rechaza
el acceso y envía Típico mensaje http de petición +
WWW authenticate: Autorización: <cred>
línea de cabecera en
respuesta. Típico mensaje de respuesta Tiempo
Cookies: mantenimiento del “estado”
Muchos sitios web importantes
utilizan cookies.
Cuatro componentes:
1) Línea de cabecera de cookie en
el mensaje HTTP de respuesta.
2) Línea de cabecera de cookie en
el mensaje HTTP de petición.
3) Archivo de cookie que se
almacena en el host del usuario
y que es gestionado por el
navegador del usuario.
4) Base de datos de respaldo en
el sitio Web.
Ejemplo:
m Susana siempre accede
a Internet desde el
mismo PC.
m Visita un sitio de
comercio electrónico
por primera vez.
m Cuando la petición HTTP
inicial llega al sitio, éste
crea un número de
identificación único y
también crea en su base
de datos una entrada
indexada por el número
de identificación.
 Cookies: mantenimiento del “estado”

cliente servidor
en
Archivo Típico msj http de petición de trad
el servidor dat a en
de cookie os
Típico mensaje de crea un número de la ba
res se
ebay: 8734 respuesta + de identificación pa
ldo
Set-cookie: 1678 1678 para el usuario
Archivo
de cookie Típico mensaje http de
amazon: 1678 petición Acción
so
ebay: 8734 cookie: 1678 específica acce
Típico mensaje de respuesta
cookie

so
una semana más tarde:

ce
ac
Típico mensaje http de
Archivo Acción
petición
de cookie
amazon: 1678 cookie: 1678 específica
Típico mensaje de respuesta
ebay: 8734 cookie
Cookies aparte
Cookies y privacidad:
Qué aportan las cookies: r Las cookies permiten que
r Autorización. los sitios sepan mucho
sobre usted.
r Carro de la compra.
r Puede proporcionar su
r Recomendaciones. nombre y correo
r Sesión de usuario con electrónico a los sitios.
r Los motores de búsqueda
estado (correo
utilizan el redirección y las
electrónico web) cookies para saber aún más.
r Las empresas de publicidad
consiguen información a
través de los sitios.
 GET condicional: caché por parte del cliente

cliente servidor
r Objetivo: no enviar objetos si
el cliente tiene una versión mensaje HTTP de
caché actualizada. petición objeto
If-modified-since:
r Cliente: especifica la fecha no
<date>
de la copia en caché en la modificado
respuesta HTTP
petición HTTP:
HTTP/1.0
If-modified-since: 304 Not Modified
<date>
r Servidor: su respuesta no
contiene ningún objeto si la mensaje HTTP de
copia en caché está petición
actualizada: If-modified-since: objeto
HTTP/1.0 304 Not
<date> modificado
Modified respuesta HTTP
HTTP/1.0 200 OK
<data>
Capítulo 2:Tabla de contenidos
r 2.6 Programación de
r 2.1 Principios de los
sockets con TCP.
protocolos de la capa
r 2.7 Programación de
de aplicación.
sockets con UDP.
r 2.2 La Web y HTTP.
r 2.8 Construcción de un
r 2.3 Transferencia de
servidor de web sencillo.
archivos: FTP.
r 2.9 Distribución de
r 2.4 Correo electrónico
contenidos:
en Internet. m Caché web.
m SMTP, POP3, IMAP. m Redes de distribución de
r 2.5 DNS: el servicio de contenidos.
directorio de m Compartición de archivos
entre iguales.
Internet.
FTP: El protocolo de transferencia de archivos

Interfaz Transferencia de
Cliente Servidor
de usuario archivo
FTP FTP
FTP
usuario
o host Sistema Sistema
local de remoto de
archivos archivos

r Transferencia de archivo a/desde un host remoto.

r Modelo cliente/servidor:
m Cliente: es el que inicia la tranferencia (bien a o desde
el host remoto).
m Servidor: host remoto.
r FTP: RFC 959.
r Servidor FTP: puerto 21.
FTP: control separado, conexiones de datos
r El cliente FTP contacta con el
servidor FTP en el puerto 21,
especificando el TCP como
protocolo de transporte.
r El cliente consigue la
autorización sobre la conexión de
control.
r El cliente navega por el
directorio remoto enviando
comandos sobre la conexión de
control.
r Cuando el servidor recibe un
comando para la transferencia
de archivos, el servidor abre la
conexión TCP de datos con el
cliente.
r Después de transferir un
archivo, el servidor cierra la
conexión.
Conexión TCP de control
sobre el puerto 21
Conexión TCP de control
Cliente sobre el puerto 20 Servidor
FTP
FTP
r El servidor abre una segunda
conexión FTP de datos para
transferir otro archivo.
r Conexión de control: “fuera
de banda”
r El servidor FTP mantiene el
“estado”: directorio actual,
autentificación anterior.
Comandos y respuestas FTP
Ejemplo de comandos:
r Enviado como texto ASCII
por el canal de control.
r USER nombre del
usuario.
r PASS palabra clave.
r LIST devuelve la lista del
archivo al directorio en
curso.
r RETR nombre de
archivo recupera el
archivo.
r STOR nombre de
archivo almacena el
archivo en el host remoto.
Ejemplo de códigos de
respuesta:
r Códigos de estatus y frase
(como en HTTP).
r 331 Username OK,
password required
r 125 data connection
already open; transfer
starting
r 425 Can’t open data
connection
r 452 Error writing file
Capítulo 2: Tabla de contenidos
r 2.6 Programación de
r 2.1 Principios de los
sockets con TCP.
protocolos de la capa
r 2.7 Programación de
de aplicación.
sockets con UDP.
r 2.2 La Web y HTTP.
r 2.8 Construcción de un
r 2.3 Transferencia de
servidor web sencillo.
archivos: FTP.
r 2.9 Distribución de
r 2.4 Correo electrónico
contenidos:
en Internet. m Caché Web.
m SMTP, POP3, IMAP. m Redes de distribución de
r 2.5 DNS: el servicio de contenidos.
directorio de m Compartición de archivos
entre iguales.
Internet.
 Cola de
Correo electrónico mensajes
de salida
Buzón de correo
Los tres componentes de usuario
agente
principales: de usuario
r Agentes de usuario.
servidor
r Servidores de correo. de correo agente
r Protocolo simple de de usuario

transferencia de correo: SMTP

servidor
SMTP. de correo

Agente usuario
SMTP agente
de usuario

r También conocido como

SMTP
“lector de correo”.
r Composición, edición y lectura servidor
agente
de usuario
de mensajes de correo. de correo
r Por ejemplo, Eudora, Outlook,
elm, Netscape Messenger. agente
de usuario
r Salida y entrada del los
mensajes almacenados en el
agente
servidor. de usuario
Correo electrónico: servidores de correo

Servidores de correo:
agente
r Buzón de correo: contiene los de usuario
servidor agente
mensajes de entrada del de correo de usuario
usuario.
r Cola de mensajes: mensajes SMTP
servidor
de correo de salida (para ser de correo agente
enviados). SMTP de usuario
r Protocolo SMTP: entre
servidores para mandar SMTP
mensajes de correo servidor
electrónico. de correo agente
de usuario
m Cliente: envía correo al
servidor. agente
de usuario
m “Servidor”: recibe correo
de otro servidor. agente
de usuario
Correo electrónico: SMTP [RFC 2821]
r Utiliza TCP para transferir con seguridad el mensaje de
correo electrónico del cliente al servidor, puerto 25.
r Transferencia directa: del servidor que envía al servidor
que recibe.
r Las tres fases de la transferencia son:
m “Acuerdo” (saludo).
m Transferencia de mensajes.
m Cierre.
r Interacción comando/respuesta:
m Comandos: texto ASCII.
m Respuesta: código de estatus y frase.

r Los mensajes deben tener siete bits en ASCII.

Ejemplo: Alicia le envía un mensaje a Roberto
1) Alicia utiliza su agente usuario
para componer el mensaje “a”
bob@escuela.edu
2) El agente de usuario de Alicia
envía un mensaje a su servidor
de correo; y el mensaje es
ubicado en la cola de
mensajes.
3) El lado cliente del SMTP abre
una conexión TCP con el
servidor de correo de
Roberto.
4) El cliente SMTP envía el
mensaje de Alicia sobre la
conexión TCP.
5) El servidor de correo de
Roberto deposita el mensaje
en el buzón de correo de
Roberto.
6) Roberto recurre a su agente
de usuario para leer el
mensaje.

1
servidor servidor
2 de correo
3 de correo 6 agente
agente 4 5 de usuario
de usuario
Ejemplo de interacción SMTP
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alicia@crepes.fr>
S: 250 alicia@crepes.fr... Sender ok
C: RCPT TO: <roberto@hamburger.edu>
S: 250 roberto@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: ¿Te gusta el ketchup?
C: ¿Y los encurtidos?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
Ponga a prueba la interacción SMTP por
usted mismo:
r Telnet nombreServidor 25.
r Mire la respuesta 220 del servidor.
r Introduzca los comandos HELO, MAIL FROM,
RCPT TO, DATA, QUIT.
Lo arriba mencionado le permite enviar el correo
electrónico sin utilizar el cliente de correo
electrónico (lector).
SMTP: últimos comentarios
r SMTP utiliza conexiones Comparación con HTTP:
persistentes.
r HTTP: demanda.
r SMTP requiere que el
r SMTP: oferta.
mensaje (cabecera y
cuerpo) esté contenido en r Ambos utilizan interacción
siete bits de ASCII.
ASCII comando/respuesta
r El servidor SMTP utiliza y códigos de estatus.
CRLF.CRLF para
determinar el final del r HTTP: encapsula cada
mensaje. objeto en su propio
mensaje de respuesta.
r SMTP: envía múltiples
objetos en mensajes
multipart.
Formato de los mensajes de correo
SMTP: protocolo para
intercambiar mensajes de
correo electrónico. cabecera
RFC 822: estándar para el Línea en
formato de texto del blanco
mensaje:
r Líneas de cabecera, por
ejemplo: cuerpo
m Para:
m De:
m Asunto:
diferentes de los comandos
SMTP
r Cuerpo:
m el “mensaje”, sólo
caracteres ASCII.
Formato del mensaje: extensiones multimedia
r MIME: extensiones de correo multimedia, RFC 2045,
2056
r Las líneas adicionales en la cabecera del mensaje
declaran el tipo de contenido MIME.
From: alicia@crepes.fr
Versión MIME To: roberto@hamburger.edu
Subject: Imagen de un delicioso
Método utilizado crepe.
de datos codificados MIME-Version: 1.0
Content-Transfer-Encoding: base64
Datos multimedia Content-Type: image/jpeg
tipo, subtipo,
declaración de parámetros datos codificados
base64........ ...................
Datos codificados .…........... .... datos
codificados base64
Tipos de MIME
Content-Type: tipo/subtipo; parametros
Texto
r Ejemplos de subtipos:
plain, html
Imagen
r Ejemplos de subtipos:
jpeg, gif
Audio
r Ejemplos de subtipos:
basic (codificados en ocho
bits mu-law), 32kadpcm
(32 kbps codificado).
Vídeo
r Ejemplos de subtipos:
mpeg, quicktime
Aplicación
r Otros datos que deben ser
procesados por el lector
antes de ser “visionados”.
r Ejemplos de subtipos:
msword, octet-stream
Tipo multipart
From: alicia@crepes.fr
To: roberto@hamburger.edu
Subject: Imagen de un delicioso crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart

--StartOfNextPart
Querido Roberto, Te envío una imagen de un crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
datos codificados base64 .....
.........................
...…datos codificados base64
--StartOfNextPart
Dime si quieres tener la receta
Protocolos de acceso al correo
SMTP SMTP Protocolo
Agente de acceso Agente
de usuario de usuario

Servidor de correo Servidor de correo

del emisor del destinatario
r SMTP: envío/almacenamiento a/en el servidor del destinatario.
r Protocolo de acceso al correo: recuperación desde el servidor.
m POP: Protocolo de Oficina Postal [RFC 1939]
• Autorización (agente <-->servidor) y descarga.
m IMAP: Protocolo de Acceso al Correo Internet [RFC 1730]
• Más características (más complejo).
• Manipulación de los mensajes almacenados en el servidor.
m HTTP: Hotmail , Yahoo! Mail, etc.
Protocolo POP3 S: +OK POP3 server ready
Fase de autorización C: user bob
S: +OK
r Comandos del cliente:
C: pass hungry
m user: declaración del S: +OK user successfully logged on
nombre de usuario.
m pass: contraseña. C: list
S: 1 498
r Respuestas del servidor:
S: 2 912
m +OK S: .
m -ERR C: retr 1
S: <message 1 contents>
Fase de transacción, cliente: S: .
r list: enumera los números C: dele 1
de mensaje. C: retr 2
r retr: recupera un mensaje S: <message 1 contents>
determinado por su número. S: .
r dele: borra. C: dele 2
r quit C: quit
S: +OK POP3 server signing off
POP3 e IMAP
Más información sobre IMAP:
POP3: r Guarda todos los mensajes
r El ejemplo anterior en un mismo lugar: el
utiliza el modo servidor.
“descargar y borrar”. r Permite al usuario
r Roberto no puede volver organizar sus mensajes en
a leer el correo carpetas.
electrónico si cambia de r IMAP mantiene el estado
cliente. de usuario entre sesiones:
r “Descargar y guardar”: m Los nombres de las carpetas
y la correspondencia entre
copias de mensajes en los números de identificación
diferentes clientes. de los mensajes y el nombre
r POP3 está sin estado de la carpeta.
entre sesiones.
Capítulo 2: Tabla de contenidos
r 2.1 Principios de los r 2.6 Programación de
protocolos de la capa sockets con TCP.
de aplicación. r 2.7 Programación de
r 2.2 La Web y HTTP. sockets con UDP.
r 2.3 Transferencia de r 2.8 Construcción de un
archivos: FTP. servidor web Sencillo.
r 2.4 Correo electrónico r 2.9 Distribución de
en Internet. contenidos:
m Caché web.
m SMTP, POP3, IMAP.
m Redes de distribución de
r 2.5 DNS: el servicio de contenidos.
directorio de m Compartición de archivos
Internet. entre iguales.
DNS: sistema de nombres de dominio
Personas: muchos
identificadores:
m SSN, nombre, pasaporte #
Hosts de Internet, routers:
m Dirección IP (32 bits) -
utilizada para direccionar
datagramas.
m “Nombre”, por ejemplo,
gaia.cs.umass.edu -
utilizado por personas.
Pregunta: ¿Existe una
correspondencia entre
direcciones IP y nombres?
Sistema de nombres de dominio:
r Base de datos distribuida:
implementada en jerarquía de
muchos servidores de nombre.
r Protocolo de capa de aplicación:
host, routers, servidores de
nombre comunicándose para
resolver nombres
(direcciones/traducción de
nombres).
m Nota: función esencial de
Internet, implementada como
protocolo de capa de
aplicación.
m Complejidad en el “límite” de
la red.
Servidores de nombre DNS
¿Por qué no centralizar el
DNS ?
r Único punto de fallo.
r Volumen de tráfico.
r Base de datos
distanciada centralizada.
r Mantenimiento. Servidor autorizado de nombre:
No es escalable.
r Ningún servidor contiene
todas las correspondencias
para direccionar los nombres
IP.
Servidores de nombre locales:
m Cada ISP, cada empresa tiene un
servidor de nombre local (por
defecto).
m La pregunta del host DNS
primero va al servidor de nombre
local.
m Para un host: almacena la
dirección IP de ese host y el
nombre.
m Puede representar la traducción
del nombre/dirección para el
nombre de ese host.
 DNS: servidores raíz de nombres.
r Contactados por los servidores de nombre locales que no pueden resolver
un nombre.
r Servidores de raíz de nombres:
m Contacta el servidor autorizado de nombre si la correspondencia del
nombre no se conoce.
m Obtiene correspondencia.
m Devuelve la correspondencia al servidor de nombre local.

a NSI Herndon, VA
c PSInet Herndon, VA k RIPE London
d U Maryland College Park, MD i NORDUnet Stockholm
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA m WIDE Tokyo

e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
Los 13 servidores de
raíz de nombres del
mundo
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
 Ejemplo sencillo de DNS servidor raíz de
nombres

host surf.eurecom.fr 2 4
quiere la dirección IP de 5 3
gaia.cs.umass.edu
1. Contacta con su servidor DNS
local, dns.eurecom.fr.
2. dns.eurecom.fr contacta servidor local de Servidor autorizado
nombres de nombres
con el servidor raíz de dns.umass.edu
dns.eurecom.fr
nombres, si es necesario.
1 6
3. El servidor raíz de nombres
contacta con el servidor
autorizado de nombres,
Host peticionario
dns.umass.edu, si es surf.eurecom.fr
gaia.cs.umass.edu
necesario.
Ejemplo DNS servidor raíz de
nombres
Servidor raíz de 2 6
nombres: 7 3
r Puede que no conozca
el servidor autorizado
de nombres.
r Puede que conozca el servidor local de servidor intermedio
servidor de nombres de nombres
nombres
intermedio: con el que dns.eurecom.fr 4 5
dns.umass.edu
1 8
contactará para
encontrar al servidor Servidor autorizado
autorizado de de nombres
nombres. dns.umass.edu
Host peticionario
surf.eurecom.fr

gaia.cs.umass.edu
DNS: consultas iterativas servidor raíz de
nombres
Consulta recursiva: 2 Consulta
r Pone el peso de la 3 iterativa
resolución del nombre en
4
el servidor de nombre
contactado. 7
r ¿Demasiada
responsabilidad? servidor local de servidor intermedio
de nombres
nombres dns.umass.edu
Consulta iterativa: dns.eurecom.fr
1 8
5 6
r El servidor contactado
responde con el nombre Servidor autorizado
al servidor que contacta. de nombres
r “No conozco ese dns.umass.edu
nombre, pero puedo Host peticionario
surf.eurecom.fr
consultar ese servidor.”
gaia.cs.umass.edu
DNS: caché y actualización de registros
r Una vez que un servidor de nombres (cualquiera)
conoce la correspondencia, hace una copia caché.
m La copia caché se queda en punto muerto
(desaparece) tras un cierto tiempo.
r Mecanismos de actualización/notificación bajo
diseño de IETF.
m RFC 2136
m http://www.ietf.org/html.charters/dnsind-charter.html
Registros DNS
DNS: Base de datos distribuida que almacena registros de
recursos (RR).

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

r Tipo=A r Tipo=CNAME
m nombre es un nombre de m nombre es el alias de un nombre

host. “canónico” (verdadero).

m valor es la dirección IP. www.ibm.com en realidad es
servereast.backup2.ibm.com
r Tipo=NS
m valor es el nombre canónico.
m nombre es un dominio (por
ejemplo foo.com). r Tipo=MX
m valor es la dirección IP
m valor es el nombre de un
de un servidor de nombre
servidor de correo asociado a
autorizado para ese
nombre.
dominio.
 Protocolo y mensajes DNS
Protocolo DNS: mensajes de consulta y respuesta, ambos con el
mismo formato de mensaje.

Identificación Señales
Cabecera del mensaje: Número de RR de
número de cuestiones respuesta
r Identificación: 16 bits
Número de RR de
Número de RR
para la consulta, que se autorización adicionales
repiten en la respuesta a la
Cuestiones
consulta. (número variable de cuestiones)
r Flags (señales):
Respuestas
m consulta o respuesta. (número variable de registros de recurso )
m recursión deseada.
Autorización
m recursión disponible. (número variable de registros de recurso)

m respuesta es Información adicional

autorizada. (número variable de registros de recurso)
 Protocolo y mensajes DNS
Identificación Señales

Nombre, campos de tipo Número de cuestiones

Número de RR de
respuesta
para una consulta. Número de RR Número de RR
autorización adicionales

Cuestiones
RR en respuesta (número variable de cuestiones)
a una consulta. Respuestas
(número variable de registros de recurso)
Registros para Autorización
servidores autorizados. (número variable de registros de recurso)

Información adicional
(número variable de registros de recurso )
Información adicional
“de ayuda” que puede
ser utilizada.
Capítulo 2: Tabla de Contenidos
r 2.6 Programación de
r 2.1 Principios de los
protocolos de la capa sockets con TCP.
de aplicación. r 2.7 Programación de
r 2.2 La Web y HTTP. sockets con UDP.
r 2.8 Construcción de un
r 2.3 Transferencia de
archivos: FTP. servidor web sencillo.
r 2.9 Distribución de
r 2.4 Correo electrónico
en Internet. contenidos:
m Caché web.
m SMTP, POP3, IMAP. m Redes de distribución de
r 2.5 DNS: el servicio de contenidos.
directorio de m Compartición de archivos
entre iguales.
Internet.
Programación de sockets
Objetivo: aprender cómo se construye una aplicación
cliente/servidor que se comunique utilizando sockets.

Socket API socket

r Introducido por BSD4.1
UNIX, 1981
r Creado, utilizado y puesto en
circulación explícitamente
por aplicaciones.
r Paradigma cliente/servidor.
r Dos tipos de transporte de
servicio vía socket API:
m Datagrama poco fiable.
m Orientación del flujo de
bytes fiable.
Una interfaz controlada
por un sistema operativo,
creada por una aplicación
y con un host local,
(una “puerta”) por la cual
el proceso de aplicación
puede tanto enviar como
recibir mensajes de otro
proceso de aplicación.
 Programación de sockets usando TCP
Socket: una puerta entre el proceso de aplicación y el
protocolo de transporte final (UCP o TCP).
Servicio TCP: transferencia fiable de bytes de un
proceso a otro.

Controlado por el
Controlado por el Proceso desarrollador de
desarrollador de Proceso
la aplicación
la aplicación Socket Socket
TCP con TCP con
Controlado por el
Controlado por el búferes y búferes y sistema operativo
Internet variables
sistema operativo variables

Host o Host o
servidor servidor
 Programación de sockets con TCP
El cliente debe contactar con el
servidor:
r El proceso del servidor en
principio debe estar funcionando.
r El servidor debe haber creado un
socket (puerta) para dar la
bienvenida al contacto del
cliente.
El cliente contacta con el servidor:
r Creando un socket TCP local del
cliente.
r Especificando la dirección IP y el
número de puerto del proceso del Punto de vista de la aplicación
servidor.
r Cuando el cliente crea un socket:
el cliente establece una conexión
TCP con el servidor.
r Cuando el cliente contacta con
él, el servidor TCP crea un
nuevo socket para que el
proceso servidor se comunique
con el cliente.
m Permite al servidor hablar
con múltiples clientes.
m Fuente de los números de
puerto utilizados para
distinguir a los clientes (más
en el Capítulo 3).
TCP propociona una transferencia
de bytes en orden y fiable
(“tubería”) entre cliente y servidor.
Jerga relacionada con el flujo
r Un flujo es una secuencia
de caracteres que fluye
hacia o desde un proceso.
r Un flujo de entrada está
relacionado con una fuente
de entrada del proceso, por
ejemplo, el teclado o un
socket.
r Un flujo de salida está
relacionado con una fuente
de salida, por ejemplo, el
monitor o un socket.
Programación de sockets con TCP
Teclado Monitor
Ejemplo de aplicación
cliente-servidor:

entradaDesdeUsuario
1) El cliente lee una línea de su Flujo de
entrada
entrada estándar (flujo
inFromUser) , y se la envía al Proceso
Proceso
servidor por su socket (flujo cliente
outToServer).
2) El servidor lee una línea en su

entradaDesdeServidor
socket.

salidaAServidor
3) El servidor convierte la línea a Flujo de Flujo de
mayúsculas y se la envía de salida entrada

vuelta al cliente.
4) El cliente lee e imprime la Socketcliente
línea modificada de su socket TCP Socket
TCP
(flujo inFromServer).
Hacia la red Desde la red
 Interacción socket cliente/servidor: TCP
Servidor (ejecutándose en hostid) Cliente
crear socket,
port=x, para petición
de entrada:
socketAcogida =
ServerSocket()

Establecimiento de conexión Crear socket

Esperar a la petición TCP
de conexión de entrada conectado a hostid, port=x
socketCliente =
socketConexion=
Socket()
socketAcogida.accept()

Enviar petición utilizando

Leer petición de socketCliente
socketConexion

Escribir respuesta a
socketConexion Leer respuesta de
socketCliente
Cerrar
socketConexion Cerrar
socketCliente
 Ejemplo: Cliente Java (TCP)
import java.io.*;
import java.net.*;
class TCPCliente {

public static void main(String argv[]) throws Exception

{
String frase;
String fraseModificada;
Crea flujo
de entrada BufferedReader entradaDesdeUsuario =
new BufferedReader(new InputStreamReader(System.in));
Crea socket cliente,
conecta con Socket socketCliente = new Socket(”nombrehost", 6789);
el servidor

Crea flujo de DataOutputStream salidaAServidor =

salida relacionado new DataOutputStream(socketCliente.getOutputStream());
con el socket
Ejemplo: Cliente Java (TCP)

Crea un flujo de salida BufferedReader entradaDesdeServidor =

relacionado con el new BufferedReader(new
socket InputStreamReader(socketCliente.getInputStream()));

frase = entradaDesdeUsuario.readLine();
Línea de envío
al servidor salidaAServidor.writeBytes(frase + '\n');

Línea de lectura fraseModificada= entradaDesdeServidor.readLine();

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

socketCliente.close();

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

class TCPServidor {

public static void main(String argv[]) throws Exception

{
String fraseCliente;
Crea String fraseMayusculas;
socket de acogida
ServerSocket socketAcogida = new ServerSocket(6789);
en puerto 6789
while(true) {
Espera en el socket
de acogida al contacto Socket connectionSocket = socketAcogida.accept();
del cliente
BufferedReader entradaDesdeCliente =
Crea flujo de new BufferedReader(new
entrada relacionado InputStreamReader(socketConexion.getInputStream()));
con el socket
Ejemplo: Servidor Java (TCP)

Crea flujo de
salida relacionado DataOutputStream salidaACliente=
con el socket new DataOutputStream(socketConexion.getOutputStream());
Lee en línea desde
el socket fraseCliente = entradaDesdeCliente.readLine();

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

Escribe línea
salidaACliente.writeBytes(fraseMayusculas);
al socket
}
}
} Acaba el bucle while y vuelve
al principio del bucle a esperar
otra conexión del cliente.
Capítulo 2: Tabla de contenidos
r 2.6 Programación de
r 2.1 Principios de los sockets con TCP.
protocolos de la capa r 2.7 Programación de
de aplicación. sockets con UDP.
r 2.2 La Web y HTTP. r 2.8 Construcción de un
r 2.3 Transferencia de servidor web sencillo.
archivos: FTP. r 2.9 Distribución de
r 2.4 Correo electrónico contenidos:
en Internet. m Caché web.
m SMTP, POP3, IMAP. m Redes de distribución de
contenidos.
r 2.5 DNS: el servicio de m Compartición de archivos
directorio de entre iguales.
Internet.
Programación de sockets con UDP

UDP: no hay “conexión” entre

el cliente y el servidor.
r No hay sincronización.
r El remitente añade Punto de vista de la aplicación
explícitamente la dirección
IP y el puerto de destino a UDP proporciona transferencia
poco fiable de grupos de bytes
cada paquete.
(“datagramas”) entre cliente y servidor
r El servidor debe extraer la
dirección IP y el puerto del
remitente del paquete
recibido.
UDP: Los datos transmitidos
puede que se reciban
desordenados o que se
pierdan.
 Interacción socket cliente/servidor: UDP
Servidor (ejecutándose en hostid) Cliente

Crear socket, Crear socket,

port=x, para petición de entrada: socketCliente =
DatagramSocket()
socketServidor=
DatagramSocket()
Crear dirección (hostid, port=x,
enviar petición de datagrama
Leer petición de utilizando socketCliente
socketServidor

Escribir respuesta a
socketServidor Leer respuesta de
especificando dirección del host socketCliente
cliente, número de puerto.
Cerrar
socketCliente
Ejemplo: Cliente Java (UDP)
Teclado Monitor

entradaDesdeUsuario
Flujo de
entrada

Proceso
Proceso Entrada: recibe
Cliente
paquete (TCP
Salida: envía
recibido por “flujo
paquete (TCP de bytes”)

paqueteRecibido
Paqueteenvío
enviado por “flujo Paquete Paquete
UDP UDP
de bytes”)

Socketcliente
clientSocket
UDP socket
UDP

Hacia la red Desde la red

 Ejemplo: Cliente Java (UDP)
import java.io.*;
import java.net.*;

class UDPCliente {
public static void main(String args[]) throws Exception
{
Crea
flujo de entrada BufferedReader entradaDesdeUsuario =
new BufferedReader(new InputStreamReader(System.in));
Crea
socket cliente DatagramSocket socketCliente = new DatagramSocket();
Traduce el nombre del
host a una dirección
InetAddress direccionIP = InetAddress.getByName(”nombrehost");
IP utilizando DNS
byte[] datosEnvio= new byte[1024];
byte[] datosRecepcion = new byte[1024];

String frase = entradaDesdeUsuario.readLine();

datosEnvio = frase.getBytes();
Ejemplo: Cliente Java (UDP)
Crea datagrama con los
datos para enviar,
DatagramPacket paqueteEnvio =
longitud, dirección IP,
new DatagramPacket(datosEnvio, datosEnvio.length, DirecciónIP, 9876);
puerto
Envía datagrama socketCliente.send(paqueteEnvio);
al servidor
DatagramPacket paqueteRecepcion =
new DatagramPacket(datosRecepcion, datosRecepcion.length);
Lee datagrama
socketCliente.receive(paqueteRecepcion);
del servidor
String fraseModificada =
new String(paqueteRecepcion.getData());

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

socketCliente.close();
}
}
 Ejemplo: Servidor Java (UDP)
import java.io.*;
import java.net.*;

class UDPServidor {
public static void main(String args[]) throws Exception
Crea {
socket datagrama
DatagramSocket socketServidor = new DatagramSocket(9876);
en puerto 9876
byte[] datosRecepcion = new byte[1024];
byte[] datosEnvio = new byte[1024];

while(true)
{
Crea espacio para
DatagramPacket paqueteRecepcion =
datagrama recibido
new DatagramPacket(datosRecepcion, datosRecepcion.length);
Recibe socketServidor.receive(paqueteRecepcion);
datagrama
Ejemplo: Servidor Java (UDP)
String frase = new String(paqueteRecepcion.getData());
Obtiene dirección
InetAddress DireccionIP = paqueteRecepcion.getAddress();
IP y puerto
del remitente int puerto = paqueteRecepcion.getPort();

String fraseMayusculas = frase.toUpperCase();

datosEnvio = fraseMayusculas.getBytes();
Crea datagrama
DatagramPacket paqueteEnvio =
para envíar al cliente
new DatagramPacket(datosEnvio, datosEnvio.length, DireccionIP,
puerto);
Escribe datagrama
socketServidor.send(paqueteEnvio);
en el socket
}
}
} Acaba el bucle while y vuelve
al principio del bucle a esperar
otro datagrama
Construcción de un servidor Web sencillo
r Maneja sólo una petición
HTTP.
r Acepta la petición.
r Analiza la cabecera.
r Recupera el archivo pedido
del sistema de archivos del
servidor.
r Crea un mensaje HTTP de
respuesta:
m líneas de cabecera + archivo
r Envía la respuesta al cliente.
r Tras crear el servidor,
puede solicitar el
archivo utilizando un
browser (por ejemplo,
el explorador Internet
Explorer).
r Lea el libro de texto
para más información.
Programación de sockets: referencias
Tutorial de C (audio/diapositivas):
r “Unix Network Programming” (J. Kurose),
http://manic.cs.umass.edu/~amldemo/courseware/

Tutorial de Java:
r “All About Sockets” (Sun tutorial),
http://www.javaworld.com/javaworld/jw-12-1996/jw-12-
sockets.html
r “Socket Programming in Java: a tutorial”,
http://www.javaworld.com/javaworld/jw-12-1996/jw-12-
sockets.html
Capítulo 2: Tabla de contenidos
r 2.6 Programación de
r 2.1 Principios de los sockets con TCP.
protocolos de la capa r 2.7 Programación de
de aplicación. sockets con UDP.
r 2.2 La Web y HTTP. r 2.8 Construcción de un
r 2.3 Transferencia de servidor web sencillo.
archivos: FTP. r 2.9 Distribución de
r 2.4 Correo electrónico contenidos:
en Internet. m Caché web.
m Redes de distribución de
m SMTP, POP3, IMAP. contenidos.
r 2.5 DNS: el servicio de m Compartición de archivos
directorio de entre iguales.
Internet.
Caché Web (servidor proxy)
Objetivo: satisfacer la solicitud del cliente sin involucrar
al servidor de origen.
r El usuario pone el Servidor
navegador: accesos web origen
vía caché.
Pet Servidor
r El navegador envía todas i ció TTP
nH proxy H
las peticiones HTTP al R
Clienteespue TT ión P
P tic
Pe TT H
caché. sta
e sta
HT p u
m Objecto en caché: el P
TP Res
caché devuelve el H TT
ión TTP
objecto. ic
Pe
t
st aH
m Otro caché solicita el sp ue
objeto de su servidor de Re
origen y luego devuelve
Cliente
el objeto al cliente. Servidor
origen
Más sobre el caché web
r El caché actúa tanto de
cliente como de servidor.
r El caché puede hacer una
revisión actualizada
utilizando If-modified-
since en la cabecera
HTTP.
m Asunto: ¿Debería un caché
correr el riesgo de enviar
objetos en caché sin
revisar?
m Se utiliza un método
heurístico.
r Normalmente, el caché se
instala por ISP
(universidad, empresa, ISP
residencial).
¿Por qué usar caché web?
r Porque reduce el tiempo de
respuesta por petición del
cliente.
r Porque reduce el tráfico en el
enlance de acceso de una
institución.
r Porque si Internet está
poblada de cachés, permite
que los proveedores “pobres”
puedan efectivamente enviar
contenido.
Ejemplo de caché
Supuestos
Servidores
r Tamaño medio de los objetos = origen
100.000 bits. Internet
r Tasa media por petición por parte pública
del browser de la institución a los
servidores de origen = 15/seg.
r Retraso del router de la
institución a cualquier servidor Enlace de acceso
origen y vuelta al router = 2 seg. de 1.5 Mbps
Consecuencias
Red
r Uso del LAN = 15% institucional
LAN de 10 Mbps
r Uso del enlace de acceso = 100%
r Retraso total = retraso de
Internet + retraso del acceso +
retraso del LAN =
Caché
= 2 seg + minutos + milisegundos.
institucional
Ejemplo de caché
Servidores
Solución posible
origen
r Aumento del ancho de banda
Internet
del enlace de acceso a,
pública
digamos, 10 Mbps.
Consecuencias
r Uso del LAN = 15%
r Uso del enlace de acceso = 15%
Enlace de acceso
de 1.5 Mbps
r Retraso total = retraso de
Red
Internet + retraso del acceso +
institucional
retraso del LAN = LAN de 10 Mbps
= 2 seg + msegs + msegs
r Suele suponer una mejora
costosa.
Caché
institucional
Ejemplo de caché
Instalación del caché Servidores
r Supongamos que la tasa de origen
acierto sea 0,4.
Consecuencias Internet
pública
r 40% de las peticiones serán
satisfechas casi inmediatamente.
r 60% de las peticiones serán
satisfechas por el servidor de
origen. Enlace de acceso
r EL uso del enlace de acceso se de 1.5 Mbps
reduce al 60%, lo cual tiene como Red
resultado retrasos insignificantes institucional
(digamos 10 mseg). LAN de 10 Mbps
r Retraso total = retraso de
Internet + retraso del acceso +
retraso del LAN =
= 0,6*2 seg + 0,6*0,01 segs + Caché
milisegundos < 1,3 segs institucional
Redes de distribución de contenidos (CDNs)
Servidor origen
r Los proveedores de contenido en Norteamérica

son los clientes CDN.

Réplica del contenido
r Una empresa CDN instala
Nodo CDN de distribución
cientos de servidores CDN a
través de Internet.
m En ISP de capas bajas,
cerca de los usuarios.
r CDN contesta a los
contenidos de los clientes en
servidores CDN. Cuando un Servidor CDN Servidor CDN
proveedor actualiza el en Sudamérica Servidor CDN en Asia
contenido, CDN actualiza los en Europa
servidores.
 Petición HTTP para
Ejemplo CDN www.foo.com/sports/sports.html

1 Servidor origen

2 Consulta DNS para www.cdn.com

Servidor DNS
3 autorizado de la CDN

Petición HTTP para

www.cdn.com/www.foo.com/sports/ruth.gif
Servidor CDN
cercano
Empresa CDN
Servidor origen
r cdn.com
r www.foo.com
r Distribuye archivos gif.
r Distribuye HTML.
r Utiliza su servidor DNS
r Reemplaza: autorizado para
http://www.foo.com/sports.ruth.gif encaminar las peticiones
por http://www.cdn.com/www.foo.com/ redireccionadas.
sports/ruth.gif
Más sobre las CDN
Peticiones dirigidas
r La CDN crea un “mapa”, No sólo páginas Web
indicando las distancias r Transmisión de
entre las hojas ISP y los
audio/vídeo
nodos CDN.
r Cuando una consulta llega a
almacenado.
un servidor DNS r Transmisión de
autorizado: audio/vídeo de tiempo
m El servidor determina el real.
ISP desde el que se origina
la consulta.
m Los nodos CDN crean
una red de
m Utiliza el “mapa” para
determinar el mejor
revestimiento de capa
servidor CDN. de aplicación.
Compartición de archivos entre iguales
r Alicia escoge uno de los
Ejemplo
r Alicia ejecuta su iguales, Roberto.
aplicación cliente entre r El archivo se copia desde el
iguales en el bloc de PC de Roberto al bloc de
notas de su computadora. notas de Alicia: HTTP.
r Intermitentemente, r Mientras Alicia hace la
conecta a Internet; descarga, otros usuarios
obtiene una nueva cargan desde el PC de Alicia.
dirección IP para cada
conexión. r El igual de Alicia es tanto un
r Busca “Hey Jude”. cliente Web como un
r La aplicación presenta servidor Web pasajero.
otros iguales que tienen Todos los iguales son
copia de “Hey Jude”. servidores = altamente
escalable.
Directorio centralizado entre iguales
Roberto
Diseño original del “Napster”.Servidor directorio
centralizado
1) Cuando un igual se conecta, 1
informa al servidor central Iguales
1
de:
m Su dirección IP. 3
1
m Su contenido.
2 1
2) Alicia pregunta por “Hey
Jude”.
3) Alicia solicita un archivo de
Roberto.
Alicia
Problemas con el directorio centralizado entre iguales

r Único punto de fallo. La transferencia de

r Cuello de botella de archivos está
rendimiento. descentralizada, pero
r Infracción del el contenido
copyright. localizado está
altamente
descentralizado.
Directorio descentralizado entre iguales
r Cada igual es o un líder
de su grupo o está
asignado a un líder de
grupo.
r El líder del grupo
rastrea el contenido
de todos sus “hijos”.
r Los iguales consultan al
líder del grupo y este
Igual ordinario
puede consultar a
Igual líder de grupo
otros líderes de grupo. Relaciones de vecindad
en la red de superposición
Más sobre el directorio descentralizado
Red de superposición
r Los iguales son nodos. Ventajas del acercamiento
r Arcos entre los iguales r No hay servidor de
y sus líderes de grupo. directorio centralizado:
r Arcos entre algunas m El servicio de localización
parejas de líderes de distribuido entre los iguales.
grupo. m Más difícil de cerrar.
r Vecinos virtuales. Inconvenientes del
acercamiento
Nodo de arranque
r Es necesario el nodo de
r El igual conectado es
arranque.
asignado a un líder de
r Los líderes de grupo pueden
grupo o nombrado líder.
sobrecargarse.
Inundación de consultas entre iguales
r Envío de consulta a los vecinos.
r Aplicación Gnutella. r Los vecinos responden a la
consulta.
r No hay jerarquía. r Si el igual consultado tiene el
r Utilización del nodo de objeto, manda mensaje de
vuelta al igual que pregunta.
arranque para saber
sobre los otros.
r Conexión del mensaje.

conexión
Más sobre la inundación de
consultas entre iguales
Ventajas Inconvenientes
r Los iguales tienen r Tráfico de consultas
responsabilidades excesivo.
similares: no hay r Radio de consultas:
líderes de grupo. puede no tener
r Altamente contenido estando
descentralizado. presente.
r Ningún igual mantiene r Nodo de arranque.
un directorio de r Mantenimiento de la
información. red de superposición.
 Capítulo 2: Resumen
Nuestro estudio sobre las aplicaciones de redes
ahora está completo.

r Protocolos específicos:
r Requerimientos de
m HTTP.
servicios de aplicación:
m FTP.
m Fiabilidad, ancho de banda,
m SMTP, POP, IMAP.
retraso.
m DNS.
r Paradigma cliente-
servidor. r Programación de
r Modelo de servicio de sockets.
transporte de Internet. r Distribución de
m Orientado a la conexión, contenidos.
fiable: TCP m Cachés, CDN.
m Poco fiable, datagramas: m Entre iguales.
UDP
Capítulo 2: Resumen
Lo más importante: lo aprendido sobre protocolos
r Típico intercambio de
mensajes petición/
respuesta.
m El cliente solicita una
información o un servicio.
m El servidor contesta con
datos y un código estatus.
r Formatos del mensaje:
m Cabeceras: campos que dan
la información sobre los
datos.
m Datos: información que se
comunica.
r Mensajes de control frente a
mensajes de datos.
m En banda, fuera de banda.
r Centralizado frente a
descentralizado.
r Sin estado frente a en estado.
r Transferencia de mensajes
fiable frente a poco fiable.
r “Complejidad al límite de la
red”.
r Seguridad: autentificación.