Upload
delia-karina-sanchez-l
View
234
Download
1
Embed Size (px)
DESCRIPTION
explicacion
Citation preview
Capa de Aplicación
Copyright 1996-2002.J.F Kurose y K.W. Ross.Todos los derechos reservados.
Redes de computadores: un enfoque descendente basado en Internet, 2ª edición.Jim Kurose, Keith Ross
Capa de aplicaciónNuestros objetivos: Aspectos
conceptuales y de implementación de los protocolos de las aplicaciones de red. Modelos de servicio
de la capa de transportes
Paradigma cliente-servidor.
Paradigma entre iguales (peer to peer).
Aprendizaje de protocolos por medio del estudio de protocolos a nivel de aplicación. HTTP. FTP. SMTP / POP3 / IMAP. DNS.
Programación de aplicaciones de red. Socket de API.
Tabla de contenidos
2.1 Principios de los protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
Aplicaciones de red: jerga
Proceso: programa que se ejecuta en un host.
En el mismo host, dos procesos se comunican utilizando comunicación interproceso (definidos por un sistema operativo).
Los procesos que se ejecutan en diferentes hosts se comunican con un protocolo de capa de aplicación.
Agentes de usuario: interfaces con un usuario “por encima” y una red “por debajo”.
Implementa interfaces de usuario y protocolos a nivel de aplicación. Web: navegador. Correo electrónico:
lector de correo. Transmisión de
audio/vídeo: reproductor multimedia.
Aplicaciones y protocolos de la capa de aplicaciónAplicación: comunicación,
procesos distributivos. Por ejemplo: correo electrónico,
web, compartición de archivos entre iguales, mensajería instantánea.
Funcionamiento en sistemas finales (hosts).
Intercambio de mensajes para la implementación de aplicaciones.
Protocolos de capa de aplicación Una “parte” de la aplicación. Definición de mensajes
intercambiados entre las aplicaciones y las acciones tomadas.
Uso de servicios de comunicación proporcionados por los protocolos de capas inferiores (TCP, UDP).
Aplicación
TransporteRed
Enlace de datos
Física
Aplicación
TransporteRed
Enlace de datos
Física
Aplicación
TransporteRed
Enlace de datos
Física
Características de los protocolos de capa de aplicación Los tipos de mensajes
intercambiados, por ejemplo, mensajes de petición y de respuesta.
Sintaxis de los tipos de mensajes: qué campos hay en los mensajes y cómo están delineados estos campos.
Semántica de los campos, por ejemplo, significado de la información en los campos.
Reglas que determinan cuándo y cómo los procesos envían y responden a los mensajes.
Protocolos de dominio público:
Definidos en RFC. Permiten
interoperabilidad. Por ejemplo: HTTP,
SMTP.Protocolos de
propietarios: Por ejemplo:
KaZaA,ARES, LimeWire.
Paradigma del cliente-servidorLa aplicación de red típicamente
tiene dos partes: el cliente y el servidor
Aplicación
TransporteRed
Enlace de datos
Física
Aplicación
TransporteRed
Enlace de datos
Física
Cliente: Inicia el contacto con el servidor
(“habla primero”). Normalmente solicita un servicio
del servidor. Web: cliente implementado en
el navegador; correo electrónico: en el lector de correo.Servidor:
Proporciona el servicio solicitado al cliente.
Por ejemplo, el servidor de Web envía la página Web solicitada, el servidor de correo entrega el correo electrónico.
Petición
Respuesta
Procesos que se comunican a través de la red
El proceso envía/recibe mensajes a/de su socket.
El socket es análogo a una puerta: El proceso emisor empuja el
mensaje por su puerta. Este proceso asume la
existencia de una infraestructura de transporte al otro lado de la puerta que transportará el mensaje al socket en el proceso receptor.
Socket: interfeaz entre el proceso de aplicación y la capa de transporte
proceso
TCP con búferes,variables
socket
Host o servidor
proceso
TCP conbúferes,variables
socket
Host o servidor
Internet
controlado por el sistema operativo
controlado porel desarrollador de la aplicación
Tambien se le denomina API: (1) elección del protocolo de transporte; (2) posibilidad de fijar algunos parámetros.
Direccionamiento de procesos: Para que un proceso
reciba mensajes debe tener un identificador.
Cada host tiene una única dirección IP de 32 bits.
Pregunta: ¿Basta con la dirección IP del host, en el que el proceso se ejecuta, para identificar el proceso?
Respuesta: No, ya que muchos procesos diferentes pueden estar ejecutándose en el mismo host.
El identificador incluye tanto la dirección IP como los números de puerto asociados con el proceso del host.
Ejemplos de números de puerto: Servidor HTTP: 80. Servidor de correo: 25. Telnet : 23. FTP: 20.
Más adelante se tratará este tema con más profundidad.
¿Qué servicio de transporte necesita una aplicación?Pérdida de datos Ciertas aplicaciones (por
ejemplo, audio) pueden tolerar algunas pérdidas.
Otras aplicaciones (por ejemplo, transferencia de archivos, Telnet) requieren el 100 por ciento de transferencia fiable de datos.
Temporización Algunas aplicaciones
(por ejemplo, telefonía de Internet, juegos interactivos) requieren un retardo lento para ser “efectivas”.
Ancho de banda Algunas aplicaciones
(por ejemplo, multimedia) requieren un mínimo de ancho de banda para ser “efectivas”.
Otras aplicaciones (“aplicaciones flexibles”) hacen uso de cualquier ancho de banda que tengan a su disposición.
Requisitos de los servicios de transporte para aplicaciones comunes
Aplicación
Transferencia de archivos
Correo electrónicoDocumentos Web
Audio/vídeo de tiempo real
Audio/vídeo almacenado
Juegos interactivosMensajería instantánea
Pérdida de datos
No pérdidaNo pérdidaNo pérdidaTolerante
ToleranteTolerante
No pérdida
Ancho de banda
flexibleflexibleflexibleAudio: 5Kbps-1MbpsVídeo:10Kbps-5MbpsIgual que el anteriorPocos Kbps-10KbpsFlexible
Sensible al tiempo
NoNoNoSí, 100 mseg
Sí, pocos segSí, 100 msegSí y no
Servicios de los protocolos de transporte de Internet
Servicio TCP: Orientado a la conexión:
Sistema requerido entre el cliente y el servidor.
Transporte fiable entre el proceso emisor y el receptor.
Control de flujo: el emisor no debe sobrecargar al receptor.
Control de congestión: regulación del emisor si la red se sobrecarga.
No proporciona: temporización, garantías de un ancho de banda mínimo.
Servicio UDP: Transferencia de datos
no fiable entre el proceso emisor y el receptor.
No proporciona: sistema de conexión, fiabilidad, control de flujo, control de congestión, temporización y garantía de ancho de banda.
PREGUNTA: ¿Por qué tomarse la molestia? ¿Por qué existe un UDP?
Aplicaciones de Internet: aplicación, protocolos de transporte
Aplicaciones
Correo electrónicoAcceso a terminales remotos
Web Transferencia de archivos
Flujo de multimedia
Telefonía Internet
Protocolo de la capa de aplicación
SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]Propietario(por ejemplo, Real Networks)Propietario(por ejemplo, Dialpad, xLite)
Protocolo de ransporte subyacente
TCPTCPTCPTCP
TCP o UDP
Típicamente UDP
Capítulo 2: Tabla de contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
La Web y HTTPEn primer lugar, un poco de jerga Una página web consta de objectos. Un objeto puede ser un archivo HTML, una
imagen JPEG,un applet Java, un archivo de audio, etc.
Una página web está formada por un archivo HTML base, que incluye diversos objetos referenciados.
Cada objeto es direccionable por un URL. Ejemplo de URL:www.escuela.edu/departamento/imagen.gif
nombre de host nombre de ruta
Introducción a HTTPHTTP: protocolo de
transferencia de hipertexto:
Protocolo de la capa de aplicación de la Web.
Modelo cliente/servidor: cliente: navegador que
solicita, recibe y “descarga” objetos Web.
servidor: servidor Web que envía los objetos correspondientes en respuesta a las peticiones.
HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068
PC ejecutandoel Explorer
Servidor ejecutando
el servidor Web Apache
Mac ejecutando el Navigator
Petición HTTP
Petición HTTP
Respuesta HTTP
Respuesta HTTP
Introducción a HTTP
Usos de TCP: El cliente inicia la
conexión TCP (crea un socket) al servidor, puerto 80.
El servidor accepta la conexión TCP del cliente.
Los mensajes HTTP (mensajes de protocolo de la capa de aplicación) intercambiados entre el navegador ( cliente HTTP) y el servidor Web (servidor HTTP)
La conexión TCP se cierra.
HTTP está “sin estado” El servidor no conserva
ninguna información sobre las peticiones previas de clientes.
Los protocolos que conservan “estado” son complicados
La historia previa (estado) debe conservarse.
Si el servidor/cliente se bloquea, sus visiones del “estado” pueden ser inconsistentes y deben ser recompuestas.
aparte
Conexiones HTTP
Conexiones HTTP no persistentes
Se envía un objeto como máximo con una conexión TCP.
HTTP/1.0 utiliza conexiones HTTP no persistentes.
Conexiones HTTP persistentes
Se pueden enviar múltiples objetos con una sola conexión TCP entre el cliente y el servidor.
HTTP/1.1 utiliza conexiones persistentes en su modo por defecto.
Conexiones HTTP no persistentes
Supongamos que el usuario entra en el URL: www.escuela.edu/departamento/home.index
1a. El cliente HTTP inicia la conexión TCP con el servidor HTTP (proceso) de www.escuela.edu en el puerto 80.
2. El cliente HTTP envía un mensaje HTTP de petición (que contiene el URL) a través del socket de la conexión TCP. El mensaje indica que el cliente quiere el objeto departamento/home.index.
1b. El servidor HTTP en el host www.escuela.edu espera la conexión TCP del puerto 80 y “acepta” la conexión, notificando al cliente.
3. El servidor HTTP recibe el mensaje de petición, compone un mensaje de respuesta que contiene el objeto solicitado, y lo envía al socket.
Tiempo
(consta de texto y referencias a 10
imágenes jpeg)
Conexiones HTTP no persistentes
5. El cliente HTTP recibe el mensaje de respuesta que contiene el archivo html y descarga el html. Analizando el archivo html, se encuentran referenciados 10 objetos jpeg.
6. Se repiten los pasos del 1 al 5 para cada uno de los 10 objetos jpeg.
4. El servidor HTTP cierra la conexión TCP.
Tiempo
Modelo del tiempo de respuesta
Definición de RRT: tiempo necesario para enviar un paquete pequeño desde el cliente hasta el servidor y después de vuelta al cliente.
Tiempo de respuesta: Un RTT para iniciar la
conexión TCP. Un RTT para la petición HTTP
y los primeros bytes de respuesta HTTP de vuelta.
Tiempo de transmisión del archivo:
total = 2RTT+tiempo de transmisión
Tiempo de transmisión del archivo
Inicio de la conexión TCP RTT
Petición de archivo
RTT
Archivo recibido
Tiempo Tiempo
Conexiones HTTP persistentesParticularidades de HTTP no
persistente: Requieren dos RTT por objeto. El sistema operativo debe
funcionar y asignar los recursos del host para cada conexión TCP.
Sin embargo, los navegadores suelen abrir conexiones TCP paralelas para traer los objetos referenciados.
HTTP persistente: El servidor deja la conexión
abierta tras enviar la respuesta.
Los mensajes HTTP posteriores entre el mismo cliente/servidor se envían por la misma conexión.
Conexiones persistentes sin entubamiento:
El cliente sólo emite una nueva petición una vez que ha recibido la anterior respuesta.
Un RTT por cada objeto referenciado.
Conexiones persistentes con entubamiento:
Por defecto en HTTP/1.1 El cliente hace su petición
tan pronto como encuentra un objeto referenciado.
Tan sólo un RTT para todos los objetos referenciados.
Mensaje HTTP de petición
Hay dos tipos de mensajes HTTP: de petición, de respuesta.
Mensaje HTTP de petición: ASCII (formato leído por personas )
GET /dir/pagina.html HTTP/1.1Host: www.escuela.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr
(Retorno de carro extra, avance de línea)
Línea de petición(GET, POST,
comandos HEAD)
Líneas de cabecera
Retorno de carro y avance de línea
que indican el final del mensaje
Mensaje HTTP de petición: formato general
Línea de petición
Cuerpo de entidad
Líneas de cabecera
método
versiónLínea de petición
valor
valor
Nombre del campo de cabecera
Nombre del campo de cabecera
Descarga de la entrada de formulario
Método POST: La página Web suele
incluir una entrada de formulario.
La entrada se descarga al servidor en el cuerpo de entidad.
Método URL: Utiliza el método GET. La entrada se descarga
en el campo URL de la línea de petición:
www.somesite.com/animalsearch?monkeys&banana
Tipos de métodos
HTTP/1.0 GET. POST. HEAD.
Pide al servidor que excluya el objeto solicitado de la respuesta.
HTTP/1.1 GET, POST, HEAD. PUT:
Descarga el archivo en el cuerpo de entidad a la ruta especificada en el campo URL.
DELETE: Borra el archivo
especificado en el campo URL.
Mensaje HTTP de respuesta
HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html datos datos datos datos datos ...
Línea de estatus(protocolo del
código de estatusy la frase
de estatus)
Líneas de cabecera
Datos, por ejemplo, el archivo
HTML solicitado
Código de estatus HTTP de respuesta
200 OK petición exitosa, el objeto requerido aparece
posteriormente en este mensaje.
301 Moved Permanently el objeto demandado ha sido movido, su nueva
localización se especifica posteriormente en este mensaje (Location:).
400 Bad Request el servidor no comprendió el mensaje de petición.
404 Not Found el documento pedido no existe en este servidor.
505 HTTP Version Not Supported
En la primera línea en el mensaje de respuesta servidor -> cliente.
Algunos ejemplos de códigos:
Ponga a prueba el HTTP (como cliente) usted mismo
1. Telnet a su servidor web favorito:
Abre la conexión TCP al puerto 80.(por defecto puerto servidor HTTP) en www.eurecom.fr.Cualquier cosa que se escriba es enviada a www.eurecom.fr
telnet www.eurecom.fr 80
2. Escriba una petición HTTP tipo GET:
GET /~ross/index.html HTTP/1.0Escribiendo esto (con doble retorno de carro), está enviando esta petición GET mínima (pero completa) al servidorHTTP.
3. Mire el mensaje de respuesta enviado por el servidor HTTP.
Interacción usuario-servidor: autorización
Autorización : control al acceso del contenido del servidor.
Credenciales de autorización, normalmente son: nombre, contraseña.
Sin estado: el cliente debe presentar la autorización para cada petición: Autorización: línea de
cabecera en cada petición. Si no hay autorización:
cabecera, el servidor rechaza el acceso y envíaWWW authenticate: línea de cabecera en
respuesta.
cliente servidorTípico mensaje http de petición
401: autorización solic.WWW authenticate:
Típico mensaje http de petición
+ Autorización: <cred>
Típico mensaje de respuesta
Típico mensaje http de petición + Autorización: <cred>
Típico mensaje de respuesta
Tiempo
Cookies: mantenimiento del “estado”Muchos sitios web importantes
utilizan cookies.Cuatro componentes:
1) Línea de cabecera de cookie en el mensaje HTTP de respuesta.
2) Línea de cabecera de cookie en el mensaje HTTP de petición.
3) Archivo de cookie que se almacena en el host del usuario y que es gestionado por el navegador del usuario.
4) Base de datos de respaldo en el sitio Web.
Ejemplo: Susana siempre
accede a Internet desde el mismo PC.
Visita un sitio de comercio electrónico por primera vez.
Cuando la petición HTTP inicial llega al sitio, éste crea un número de identificación único y también crea en su base de datos una entrada indexada por el número de identificación.
Cookies: mantenimiento del “estado”
cliente servidorTípico msj http de petición
Típico mensaje de respuesta +
Set-cookie: 1678
Típico mensaje http de petición
cookie: 1678Típico mensaje de
respuesta
Típico mensaje http de petición
cookie: 1678Típico mensaje de
respuesta
Acción específica
cookie
Acciónespecífica
cookie
el servidorcrea un númerode identificación
1678 para el usuario
entrada en la base
de datos de respaldo
acceso
acce
so
Archivo de cookie
amazon: 1678ebay: 8734
Archivo de cookie
ebay: 8734
Archivo de cookie
amazon: 1678ebay: 8734
una semana más tarde:
Cookies
Qué aportan las cookies:
Autorización. Carro de la compra. Recomendaciones. Sesión de usuario
con estado (correo electrónico web)
Cookies y privacidad: Las cookies permiten que
los sitios sepan mucho sobre usted.
Puede proporcionar su nombre y correo electrónico a los sitios.
Los motores de búsqueda utilizan el redirección y las cookies para saber aún más.
Las empresas de publicidad consiguen información a través de los sitios.
aparte
GET condicional: caché por parte del cliente
Objetivo: no enviar objetos si el cliente tiene una versión caché actualizada.
Cliente: especifica la fecha de la copia en caché en la petición HTTP:If-modified-since:
<date> Servidor: su respuesta no
contiene ningún objeto si la copia en caché está actualizada: HTTP/1.0 304 Not
Modified
cliente servidor
mensaje HTTP de petición
If-modified-since: <date>
respuesta HTTP HTTP/1.0
304 Not Modified
objeto no
modificado
mensaje HTTP de petición
If-modified-since: <date>
respuesta HTTPHTTP/1.0 200 OK
<data>
objeto modificado
Capítulo 2:Tabla de contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor de web sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
Servidor FTP
Interfaz de
usuario FTP
Cliente FTP
FTP: El protocolo de transferencia de archivos
Transferencia de archivo a/desde un host remoto. Modelo cliente/servidor:
Cliente: es el que inicia la tranferencia (bien a o desde el host remoto).
Servidor: host remoto. FTP: RFC 959. Servidor FTP: puerto 21.
Transferencia de archivo
Sistema local de archivos
Sistema remoto de archivos
usuario o host
FTP: control separado, conexiones de datos
El cliente FTP contacta con el servidor FTP en el puerto 21, especificando el TCP como protocolo de transporte.
El cliente consigue la autorización sobre la conexión de control.
El cliente navega por el directorio remoto enviando comandos sobre la conexión de control.
Cuando el servidor recibe un comando para la transferencia de archivos, el servidor abre la conexión TCP de datos con el cliente.
Después de transferir un archivo, el servidor cierra la conexión.
Cliente FTP
ServidorFTP
Conexión TCP de control sobre el puerto
21
Conexión TCP de control sobre el puerto
20
El servidor abre una segunda conexión FTP de datos para transferir otro archivo.
Conexión de control: “fuera de banda”
El servidor FTP mantiene el “estado”: directorio actual, autentificación anterior.
Comandos y respuestas FTP Ejemplo de comandos: Enviado como texto ASCII
por el canal de control. USER nombre del
usuario. PASS palabra clave. LIST devuelve la lista del
archivo al directorio en curso.
RETR nombre de archivo recupera el archivo.
STOR nombre de archivo almacena el archivo en el host remoto.
Ejemplo de códigos de respuesta:
Códigos de estatus y frase (como en HTTP).
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
Capítulo 2: Tabla de contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web sencillo.
2.9 Distribución de contenidos: Caché Web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
Correo electrónicoLos tres componentes
principales: Agentes de usuario. Servidores de correo. Protocolo simple de
transferencia de correo: SMTP.
Agente usuario También conocido como
“lector de correo”. Composición, edición y lectura
de mensajes de correo. Por ejemplo, Eudora, Outlook,
elm, Netscape Messenger. Salida y entrada del los
mensajes almacenados en el servidor.
Buzón de correo de usuario
Cola de mensajes de salida
servidor de correo
agente de usuario
SMTP
SMTP
SMTP
agente de usuario
agente de usuario
agente de usuario
agente de usuario
agente de usuario
servidor de correo
servidor de correo
Correo electrónico: servidores de correo
Servidores de correo: Buzón de correo: contiene
los mensajes de entrada del usuario.
Cola de mensajes: mensajes de correo de salida (para ser enviados).
Protocolo SMTP: entre servidores para mandar mensajes de correo electrónico. Cliente: envía correo al
servidor. “Servidor”: recibe
correo de otro servidor.
SMTP
SMTP
SMTP
agente de usuario
agente de usuario
servidor de correo
servidor de correo
servidor de correo
agente de usuario
agente de usuario
agente de usuario
agente de usuario
Correo electrónico: SMTP [RFC 2821]
Utiliza TCP para transferir con seguridad el mensaje de correo electrónico del cliente al servidor, puerto 25.
Transferencia directa: del servidor que envía al servidor que recibe.
Las tres fases de la transferencia son: “Acuerdo” (saludo). Transferencia de mensajes. Cierre.
Interacción comando/respuesta: Comandos: texto ASCII. Respuesta: código de estatus y frase.
Los mensajes deben tener siete bits en ASCII.
servidor de correo
servidor de correo
Ejemplo: Alicia le envía un mensaje a Roberto
1) Alicia utiliza su agente usuario para componer el mensaje “a” [email protected]
2) El agente de usuario de Alicia envía un mensaje a su servidor de correo; y el mensaje es ubicado en la cola de mensajes.
3) El lado cliente del SMTP abre una conexión TCP con el servidor de correo de Roberto.
4) El cliente SMTP envía el mensaje de Alicia sobre la conexión TCP.
5) El servidor de correo de Roberto deposita el mensaje en el buzón de correo de Roberto.
6) Roberto recurre a su agente de usuario para leer el mensaje.
1
2 3 4 56agente
de usuario
agente de usuario
Ejemplo de interacción SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: ¿Te gusta el ketchup? C: ¿Y los encurtidos? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
Ponga a prueba la interacción SMTP por usted mismo:
Telnet nombreServidor 25. Mire la respuesta 220 del servidor. Introduzca los comandos HELO, MAIL FROM,
RCPT TO, DATA, QUIT. Lo arriba mencionado le permite enviar el correo
electrónico sin utilizar el cliente de correo electrónico (lector).
SMTP: últimos comentarios
SMTP utiliza conexiones persistentes.
SMTP requiere que el mensaje (cabecera y cuerpo) esté contenido en siete bits de ASCII.
El servidor SMTP utiliza CRLF.CRLF para determinar el final del mensaje.
Comparación con HTTP: HTTP: demanda. SMTP: oferta.
Ambos utilizan interacción ASCII comando/respuesta y códigos de estatus.
HTTP: encapsula cada objeto en su propio mensaje de respuesta.
SMTP: envía múltiples objetos en mensajes multipart.
Formato de los mensajes de correoSMTP: protocolo para
intercambiar mensajes de correo electrónico.
RFC 822: estándar para el formato de texto del mensaje:
Líneas de cabecera, por ejemplo: Para: De: Asunto:diferentes de los comandos
SMTP Cuerpo:
el “mensaje”, sólo caracteres ASCII.
cabecera
cuerpo
Línea en blanco
Formato del mensaje: extensiones multimedia
MIME: extensiones de correo multimedia, RFC 2045, 2056
Las líneas adicionales en la cabecera del mensaje declaran el tipo de contenido MIME.
From: [email protected] To: [email protected] Subject: Imagen de un delicioso crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg
datos codificados base64........ ....................…........... .... datos codificados base64
Datos multimediatipo, subtipo,
declaración de parámetros
Método utilizadode datos codificados
Versión MIME
Datos codificados
Tipos de MIME Content-Type: tipo/subtipo; parametros
Texto Ejemplos de subtipos:
plain, html
Imagen Ejemplos de subtipos:
jpeg, gif
Audio Ejemplos de subtipos:
basic (codificados en ocho bits mu-law), 32kadpcm (32 kbps codificado).
Vídeo Ejemplos de subtipos:
mpeg, quicktime
Aplicación Otros datos que deben
ser procesados por el lector antes de ser “visionados”.
Ejemplos de subtipos: msword, octet-stream
Tipo multipart
From: [email protected] To: [email protected] Subject: Imagen de un delicioso crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPartQuerido Roberto, Te envío una imagen de un crepe.--StartOfNextPartContent-Transfer-Encoding: base64Content-Type: image/jpegdatos codificados base64 ..... ......................... ...…datos codificados base64 --StartOfNextPartDime si quieres tener la receta
Servidor de correodel emisor
Protocolos de acceso al correo
SMTP: envío/almacenamiento a/en el servidor del destinatario. Protocolo de acceso al correo: recuperación desde el servidor.
POP: Protocolo de Oficina Postal [RFC 1939]• Autorización (agente <-->servidor) y descarga.
IMAP: Protocolo de Acceso al Correo Internet [RFC 1730]• Más características (más complejo).• Manipulación de los mensajes almacenados en el servidor.
HTTP: Hotmail , Yahoo! Mail, etc.
SMTP SMTP Protocolo de acceso
Servidor de correodel destinatario
Agente de usuario
Agente de usuario
Protocolo POP3Fase de autorización Comandos del cliente:
user: declaración del nombre de usuario.
pass: contraseña. Respuestas del servidor:
+OK -ERR
Fase de transacción, cliente: list: enumera los números
de mensaje. retr: recupera un mensaje
determinado por su número. dele: borra. quit
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on
POP3 e IMAPMás información sobre
POP3: El ejemplo anterior
utiliza el modo “descargar y borrar”.
Roberto no puede volver a leer el correo electrónico si cambia de cliente.
“Descargar y guardar”: copias de mensajes en diferentes clientes.
POP3 está sin estado entre sesiones.
IMAP: Guarda todos los
mensajes en un mismo lugar: el servidor.
Permite al usuario organizar sus mensajes en carpetas.
IMAP mantiene el estado de usuario entre sesiones: Los nombres de las
carpetas y la correspondencia entre los números de identificación de los mensajes y el nombre de la carpeta.
Capítulo 2: Tabla de contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web Sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
DNS: sistema de nombres de dominio
Personas: muchos identificadores: SSN, nombre, pasaporte
#
Hosts de Internet, routers: Dirección IP (32 bits) -
utilizada para direccionar datagramas.
“Nombre”, por ejemplo, gaia.cs.umass.edu - utilizado por personas.
Pregunta: ¿Existe una correspondencia entre direcciones IP y nombres?
Sistema de nombres de dominio:
Base de datos distribuida: implementada en jerarquía de muchos servidores de nombre.
Protocolo de capa de aplicación: host, routers, servidores de nombre comunicándose para resolver nombres (direcciones/traducción de nombres). Nota: función esencial de
Internet, implementada como protocolo de capa de aplicación.
Complejidad en el “límite” de la red.
Servidores de nombre DNS Ningún servidor contiene
todas las correspondencias para direccionar los nombres IP.
Servidores de nombre locales: Cada ISP, cada empresa tiene un
servidor de nombre local (por defecto).
La pregunta del host DNS primero va al servidor de nombre local.
Servidor autorizado de nombre: Para un host: almacena la
dirección IP de ese host y el nombre.
Puede representar la traducción del nombre/dirección para el nombre de ese host.
¿Por qué no centralizar el DNS ?
Único punto de fallo. Volumen de tráfico. Base de datos
distanciada centralizada.
Mantenimiento.
No es escalable.
DNS: servidores raíz de nombres. Contactados por los servidores de nombre locales que no pueden
resolver un nombre. Servidores de raíz de nombres:
Contacta el servidor autorizado de nombre si la correspondencia del nombre no se conoce.
Obtiene correspondencia. Devuelve la correspondencia al servidor de nombre local.
b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA
Los 13 servidores de raíz de nombres del mundo
Ejemplo sencillo de DNS
host surf.eurecom.fr quiere la dirección IP de gaia.cs.umass.edu
1. Contacta con su servidor DNS local, dns.eurecom.fr.
2. dns.eurecom.fr contacta con el servidor raíz de nombres, si es necesario.
3. El servidor raíz de nombres contacta con el servidor autorizado de nombres, dns.umass.edu, si es necesario.
Host peticionariosurf.eurecom.fr
gaia.cs.umass.edu
servidor raíz de nombres
Servidor autorizado de nombres
dns.umass.edu
servidor local de nombres
dns.eurecom.fr
1
23
4
5
6
Ejemplo DNS
Servidor raíz de nombres:
Puede que no conozca el servidor autorizado de nombres.
Puede que conozca el servidor de nombres intermedio: con el que contactará para encontrar al servidor autorizado de nombres.
gaia.cs.umass.edu
1
23
4 5
6
servidor intermediode nombres
dns.umass.edu
7
8
servidor raíz de nombres
servidor local de nombres
dns.eurecom.fr
Host peticionariosurf.eurecom.fr
Servidor autorizado de nombres
dns.umass.edu
DNS: consultas iterativas
Consulta recursiva: Pone el peso de la
resolución del nombre en el servidor de nombre contactado.
¿Demasiada responsabilidad?
Consulta iterativa: El servidor contactado
responde con el nombre al servidor que contacta.
“No conozco ese nombre, pero puedo consultar ese servidor.”
gaia.cs.umass.edu
1
23
4
5 6
7
8
Consulta iterativa
servidor raíz de nombres
servidor local de nombres
dns.eurecom.fr
servidor intermediode nombres
dns.umass.edu
Host peticionariosurf.eurecom.fr
Servidor autorizado de nombres
dns.umass.edu
DNS: caché y actualización de registros
Una vez que un servidor de nombres (cualquiera) conoce la correspondencia, hace una copia caché. La copia caché se queda en punto muerto
(desaparece) tras un cierto tiempo. Mecanismos de actualización/notificación
bajo diseño de IETF. RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html
Registros DNSDNS: Base de datos distribuida que almacena registros de recursos (RR).
Tipo=NS nombre es un dominio (por
ejemplo foo.com). valor es la dirección IP de
un servidor de nombre autorizado para ese dominio.
Formato RR : (nombre, valor, tipo,ttl)
Tipo=A nombre es un nombre
de host. valor es la dirección
IP.
Tipo=CNAME nombre es el alias de un
nombre “canónico” (verdadero).
www.ibm.com en realidad es servereast.backup2.ibm.com valor es el nombre
canónico. Tipo=MX valor es el nombre de un
servidor de correo asociado a nombre.
Protocolo y mensajes DNSProtocolo DNS: mensajes de consulta y respuesta, ambos con el mismo
formato de mensaje.
Cabecera del mensaje: Identificación: 16 bits
para la consulta, que se repiten en la respuesta a la consulta.
Flags (señales): consulta o respuesta. recursión deseada. recursión disponible. respuesta es
autorizada.
Identificación Señales
número de cuestiones
Número de RR de respuesta
Número de RR de autorización
Número de RR
adicionales Cuestiones
(número variable de cuestiones)
Respuestas
(número variable de registros de recurso )
Autorización
(número variable de registros de recurso)
Información adicional
(número variable de registros de recurso)
Protocolo y mensajes DNS
Nombre, campos de tipo para una consulta.
RR en respuestaa una consulta.
Registros paraservidores autorizados.
Información adicional“de ayuda” que puede
ser utilizada.
Identificación Señales
Número de cuestiones Número de RR de respuesta
Número de RR autorización
Número de RR adicionales
Cuestiones
(número variable de cuestiones)
Respuestas
(número variable de registros de recurso)
Autorización
(número variable de registros de recurso)
Información adicional
(número variable de registros de recurso )
Diagrama una Solución de DNS
April 18, 2023
ENTERPRISE 220R
500 GB HD 4 GB RAM
SUNFire V240 500 GB HD 4 GB RAM
ENTERPRISE 220R 500 GB HD 4 GB RAM
ENTERPRISE 220R 500 GB HD 4 GB RAM
SUNFire V440 500 GB HD 4 GB RAM
2 Servidores HP Proliant1T HD 8 GB RAM
2 Servidores SUNFire V240 500 GB HD 4 GB RAM2 Balanceadores Brocade ADX
1000
Capítulo 2: Tabla de Contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
Programación de sockets
Socket API Introducido por BSD4.1
UNIX, 1981 Creado, utilizado y puesto en
circulación explícitamente por aplicaciones.
Paradigma cliente/servidor. Dos tipos de transporte de
servicio vía socket API: Datagrama poco fiable. Orientación del flujo de
bytes fiable.
Una interfaz controlada por un sistema
operativo, creada por una aplicación y con un
host local, (una “puerta”) por la
cual el proceso de aplicación puede tanto
enviar como recibir mensajes de otro
proceso de aplicación.
socket
Objetivo: aprender cómo se construye una aplicación cliente/servidor que se comunique utilizando sockets.
Programación de sockets usando TCPSocket: una puerta entre el proceso de aplicación
y el protocolo de transporte final (UCP o TCP).Servicio TCP: transferencia fiable de bytes de un
proceso a otro.
Proceso
TCP conbúferes yvariables
Socket
Controlado por el desarrollador de
la aplicación
Controlado por el sistema operativo
Host o servidor
Proceso
TCP conbúferes yvariables
Socket
Controlado por el desarrollador de la aplicación
Controlado por el sistema operativo
Host o servidor
Internet
Programación de sockets con TCP
El cliente debe contactar con el servidor:
El proceso del servidor en principio debe estar funcionando.
El servidor debe haber creado un socket (puerta) para dar la bienvenida al contacto del cliente.
El cliente contacta con el servidor: Creando un socket TCP local del
cliente. Especificando la dirección IP y el
número de puerto del proceso del servidor.
Cuando el cliente crea un socket: el cliente establece una conexión TCP con el servidor.
Cuando el cliente contacta con él, el servidor TCP crea un nuevo socket para que el proceso servidor se comunique con el cliente. Permite al servidor hablar
con múltiples clientes. Fuente de los números de
puerto utilizados para distinguir a los clientes (más en el Capítulo 3).
TCP propociona una transferencia de bytes en orden y fiable
(“tubería”) entre cliente y servidor.
Punto de vista de la aplicación
Jerga relacionada con el flujo
Un flujo es una secuencia de caracteres que fluye hacia o desde un proceso.
Un flujo de entrada está relacionado con una fuente de entrada del proceso, por ejemplo, el teclado o un socket.
Un flujo de salida está relacionado con una fuente de salida, por ejemplo, el monitor o un socket.
Programación de sockets con TCPEjemplo de aplicación
cliente-servidor:1) El cliente lee una línea de
su entrada estándar (flujo inFromUser) , y se la envía al servidor por su socket (flujo outToServer).
2) El servidor lee una línea en su socket.
3) El servidor convierte la línea a mayúsculas y se la envía de vuelta al cliente.
4) El cliente lee e imprime la línea modificada de su socket (flujo inFromServer).
salid
aAS
ervi
dor
Hacia la red Desde la red
entr
adaD
esde
Ser
vido
r
entr
adaD
esde
Usu
ario
Teclado Monitor
Proceso
Flujo deentrada
Flujo deentrada
Flujo desalida
SocketTCP
Proceso cliente
Socketcliente TCP
Interacción socket cliente/servidor: TCP
Esperar a la petición de conexión de entradasocketConexion=socketAcogida.accept()
crear socket,port=x, para petición de entrada:socketAcogida =
ServerSocket()
Crear socket conectado a hostid, port=x
socketCliente = Socket()
Cerrar socketConexion
Leer respuesta desocketCliente
CerrarsocketCliente
Servidor (ejecutándose en hostid) Cliente
Enviar petición utilizandosocketClienteLeer petición de
socketConexion
Escribir respuesta asocketConexion
Establecimiento de conexión TCP
Ejemplo: Cliente Java (TCP)
import java.io.*; import java.net.*; class TCPCliente {
public static void main(String argv[]) throws Exception { String frase; String fraseModificada;
BufferedReader entradaDesdeUsuario = new BufferedReader(new InputStreamReader(System.in));
Socket socketCliente = new Socket(”nombrehost", 6789);
DataOutputStream salidaAServidor = new DataOutputStream(socketCliente.getOutputStream());
Crea flujo de entrada
Crea socket cliente, conecta con
el servidor
Crea flujo de salida relacionado
con el socket
Ejemplo: Cliente Java (TCP)
BufferedReader entradaDesdeServidor = new BufferedReader(new InputStreamReader(socketCliente.getInputStream()));
frase = entradaDesdeUsuario.readLine();
salidaAServidor.writeBytes(frase + '\n');
fraseModificada= entradaDesdeServidor.readLine();
System.out.println(“DEL SERVIDOR: " + fraseModificada);
socketCliente.close(); } }
Crea un flujo de salidarelacionado con el
socket
Línea de envío al servidor
Línea de lectura del servidor
Ejemplo: Servidor Java (TCP)import java.io.*; import java.net.*;
class TCPServidor {
public static void main(String argv[]) throws Exception { String fraseCliente; String fraseMayusculas;
ServerSocket socketAcogida = new ServerSocket(6789); while(true) { Socket connectionSocket = socketAcogida.accept();
BufferedReader entradaDesdeCliente = new BufferedReader(new InputStreamReader(socketConexion.getInputStream()));
Creasocket de acogida
en puerto 6789
Espera en el socket de acogida al contacto
del cliente
Crea flujo de entrada relacionado
con el socket
Ejemplo: Servidor Java (TCP)
DataOutputStream salidaACliente= new DataOutputStream(socketConexion.getOutputStream());
fraseCliente = entradaDesdeCliente.readLine();
fraseMayusculas = fraseCliente.toUpperCase() + '\n';
salidaACliente.writeBytes(fraseMayusculas); } } }
Lee en línea desde el socket
Crea flujo de salida
relacionado con el socket
Escribe línea al socket
Acaba el bucle while y vuelve al principio del bucle a esperar otra conexión del cliente.
Capítulo 2: Tabla de contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
Programación de sockets con UDPUDP: no hay “conexión” entre
el cliente y el servidor. No hay sincronización. El remitente añade
explícitamente la dirección IP y el puerto de destino a cada paquete.
El servidor debe extraer la dirección IP y el puerto del remitente del paquete recibido.
UDP: Los datos transmitidos puede que se reciban desordenados o que se pierdan.
Punto de vista de la aplicación
UDP proporciona transferencia poco fiable de grupos de bytes
(“datagramas”) entre cliente y servidor
Interacción socket cliente/servidor: UDP
CerrarsocketCliente
Servidor (ejecutándose en hostid)
Leer respuesta desocketCliente
Crear socket,socketCliente = DatagramSocket()
Cliente
Crear dirección (hostid, port=x,enviar petición de datagrama utilizando socketCliente
Crear socket,port=x, para petición de entrada:
socketServidor= DatagramSocket()
Leer petición desocketServidor
Escribir respuesta asocketServidorespecificando dirección del hostcliente, número de puerto.
Ejemplo: Cliente Java (UDP)
Paq
uete
enví
o
Hacia la red Desde la red
paqu
eteR
ecib
ido
entr
adaD
esde
Usu
ario
Teclado Monitor
Proceso
clientSocket
PaqueteUDP
Flujo de
entrada
PaqueteUDP
socketUDP
Salida: envía paquete (TCP enviado por “flujo de bytes”)
Entrada: recibe paquete (TCP recibido por “flujo de bytes”)
Proceso Cliente
Socketcliente UDP
Ejemplo: Cliente Java (UDP)
import java.io.*; import java.net.*; class UDPCliente { public static void main(String args[]) throws Exception { BufferedReader entradaDesdeUsuario = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket socketCliente = new DatagramSocket(); InetAddress direccionIP = InetAddress.getByName(”nombrehost"); byte[] datosEnvio= new byte[1024]; byte[] datosRecepcion = new byte[1024]; String frase = entradaDesdeUsuario.readLine();
datosEnvio = frase.getBytes();
Creaflujo de entrada
Crea socket cliente
Traduce el nombre del host a una dirección
IP utilizando DNS
Ejemplo: Cliente Java (UDP)
DatagramPacket paqueteEnvio = new DatagramPacket(datosEnvio, datosEnvio.length, DirecciónIP, 9876); socketCliente.send(paqueteEnvio); DatagramPacket paqueteRecepcion = new DatagramPacket(datosRecepcion, datosRecepcion.length); socketCliente.receive(paqueteRecepcion); String fraseModificada = new String(paqueteRecepcion.getData()); System.out.println(”DEL SERVIDOR:" + fraseModificada); socketCliente.close(); }
}
Crea datagrama con los datos para enviar,longitud, dirección IP,
puerto
Envía datagrama al servidor
Lee datagrama del servidor
Ejemplo: Servidor Java (UDP)
import java.io.*; import java.net.*; class UDPServidor { public static void main(String args[]) throws Exception { DatagramSocket socketServidor = new DatagramSocket(9876); byte[] datosRecepcion = new byte[1024]; byte[] datosEnvio = new byte[1024]; while(true) { DatagramPacket paqueteRecepcion = new DatagramPacket(datosRecepcion, datosRecepcion.length);
socketServidor.receive(paqueteRecepcion);
Creasocket datagrama
en puerto 9876
Crea espacio para datagrama recibido
Recibe datagrama
Ejemplo: Servidor Java (UDP)
String frase = new String(paqueteRecepcion.getData()); InetAddress DireccionIP = paqueteRecepcion.getAddress(); int puerto = paqueteRecepcion.getPort(); String fraseMayusculas = frase.toUpperCase();
datosEnvio = fraseMayusculas.getBytes(); DatagramPacket paqueteEnvio = new DatagramPacket(datosEnvio, datosEnvio.length, DireccionIP, puerto); socketServidor.send(paqueteEnvio); } }
}
Obtiene dirección IP y
puertodel remitente
Escribe datagramaen el socket
Acaba el bucle while y vuelve al principio del bucle a esperar otro datagrama
Crea datagramapara envíar al cliente
Construcción de un servidor Web sencillo
Maneja sólo una petición HTTP.
Acepta la petición. Analiza la cabecera. Recupera el archivo
pedido del sistema de archivos del servidor.
Crea un mensaje HTTP de respuesta: líneas de cabecera +
archivo Envía la respuesta al
cliente.
Tras crear el servidor, puede solicitar el archivo utilizando un browser (por ejemplo, el explorador Internet Explorer).
Lea el libro de texto para más información.
Programación de sockets: referencias
Tutorial de C (audio/diapositivas): “Unix Network Programming” (J. Kurose),http://manic.cs.umass.edu/~amldemo/courseware/
Tutorial de Java: “All About Sockets” (Sun tutorial),
http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html
“Socket Programming in Java: a tutorial”, http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html
Capítulo 2: Tabla de contenidos 2.1 Principios de los
protocolos de la capa de aplicación.
2.2 La Web y HTTP. 2.3 Transferencia de
archivos: FTP. 2.4 Correo
electrónico en Internet. SMTP, POP3, IMAP.
2.5 DNS: el servicio de directorio de Internet.
2.6 Programación de sockets con TCP.
2.7 Programación de sockets con UDP.
2.8 Construcción de un servidor web sencillo.
2.9 Distribución de contenidos: Caché web. Redes de distribución de
contenidos. Compartición de archivos
entre iguales.
Caché Web (servidor proxy)
El usuario pone el navegador: accesos web vía caché.
El navegador envía todas las peticiones HTTP al caché. Objecto en caché: el
caché devuelve el objecto.
Otro caché solicita el objeto de su servidor de origen y luego devuelve el objeto al cliente.
Objetivo: satisfacer la solicitud del cliente sin involucrar al servidor de origen.
Cliente
Servidor proxy
Cliente
Petición HTTP
Petición HTTP
Respuesta HTTP
Respuesta HTTP
Petición HTTP
Respuesta HTTP
Servidor origen
Servidor origen
Más sobre el caché web El caché actúa tanto de
cliente como de servidor. El caché puede hacer
una revisión actualizada utilizando If-modified-since en la cabecera HTTP. Asunto: ¿Debería un
caché correr el riesgo de enviar objetos en caché sin revisar?
Se utiliza un método heurístico.
Normalmente, el caché se instala por ISP (universidad, empresa, ISP residencial).
¿Por qué usar caché web? Porque reduce el tiempo de
respuesta por petición del cliente.
Porque reduce el tráfico en el enlance de acceso de una institución.
Porque si Internet está poblada de cachés, permite que los proveedores “pobres” puedan efectivamente enviar contenido.
Ejemplo de cachéSupuestos Tamaño medio de los objetos =
100.000 bits. Tasa media por petición por parte
del browser de la institución a los servidores de origen = 15/seg.
Retraso del router de la institución a cualquier servidor origen y vuelta al router = 2 seg.
Consecuencias Uso del LAN = 15% Uso del enlace de acceso = 100% Retraso total = retraso de
Internet + retraso del acceso + retraso del LAN =
= 2 seg + minutos + milisegundos.
Servidores origen
Internet pública
Red institucional LAN de 10 Mbps
Enlace de acceso de 1.5 Mbps
Caché institucional
Ejemplo de caché
Solución posible Aumento del ancho de
banda del enlace de acceso a, digamos, 10 Mbps.
Consecuencias Uso del LAN = 15% Uso del enlace de acceso =
15% Retraso total = retraso de
Internet + retraso del acceso + retraso del LAN =
= 2 seg + msegs + msegs Suele suponer una mejora
costosa.
Servidoresorigen
Internet pública
Red institucional LAN de 10 Mbps
Enlace de acceso de 1.5 Mbps
Caché institucional
Ejemplo de cachéInstalación del caché Supongamos que la tasa de
acierto sea 0,4.Consecuencias 40% de las peticiones serán
satisfechas casi inmediatamente. 60% de las peticiones serán
satisfechas por el servidor de origen.
EL uso del enlace de acceso se reduce al 60%, lo cual tiene como resultado retrasos insignificantes (digamos 10 mseg).
Retraso total = retraso de Internet + retraso del acceso + retraso del LAN =
= 0,6*2 seg + 0,6*0,01 segs + milisegundos < 1,3 segs
Servidoresorigen
Internet pública
Red institucional LAN de 10 Mbps
Enlace de acceso de 1.5 Mbps
Caché institucional
Redes de distribución de contenidos (CDNs)
Los proveedores de contenido son los clientes CDN.
Réplica del contenido Una empresa CDN instala
cientos de servidores CDN a través de Internet. En ISP de capas bajas,
cerca de los usuarios. CDN contesta a los
contenidos de los clientes en servidores CDN. Cuando un proveedor actualiza el contenido, CDN actualiza los servidores.
Servidor origen en Norteamérica
Nodo CDN de distribución
Servidor CDNen Sudamérica Servidor CDN
en Europa
Servidor CDN en Asia
Ejemplo CDN
Servidor origen www.foo.com Distribuye HTML. Reemplaza: http://www.foo.com/sports.ruth.gif
por
http://www.cdn.com/www.foo.com/sports/ruth.gif
Petición HTTP para
www.foo.com/sports/sports.html
Consulta DNS para www.cdn.com
Petición HTTP para
www.cdn.com/www.foo.com/sports/ruth.gif
1
2
3
Servidor origen
Servidor DNS autorizado de la CDN
Servidor CDN cercano Empresa CDN
cdn.com Distribuye archivos gif. Utiliza su servidor DNS
autorizado para encaminar las peticiones redireccionadas.
Más sobre las CDNPeticiones dirigidas La CDN crea un “mapa”,
indicando las distancias entre las hojas ISP y los nodos CDN.
Cuando una consulta llega a un servidor DNS autorizado: El servidor determina el
ISP desde el que se origina la consulta.
Utiliza el “mapa” para determinar el mejor servidor CDN.
No sólo páginas Web Transmisión de
audio/vídeo almacenado.
Transmisión de audio/vídeo de tiempo real. Los nodos CDN crean
una red de revestimiento de capa de aplicación.
Compartición de archivos entre iguales
Ejemplo Alicia ejecuta su
aplicación cliente entre iguales en el bloc de notas de su computadora.
Intermitentemente, conecta a Internet; obtiene una nueva dirección IP para cada conexión.
Busca “Hey Jude”. La aplicación presenta
otros iguales que tienen copia de “Hey Jude”.
Alicia escoge uno de los iguales, Roberto.
El archivo se copia desde el PC de Roberto al bloc de notas de Alicia: HTTP.
Mientras Alicia hace la descarga, otros usuarios cargan desde el PC de Alicia.
El igual de Alicia es tanto un cliente Web como un servidor Web pasajero.
Todos los iguales son servidores = altamente escalable.
Directorio centralizado entre iguales
Diseño original del “Napster”.
1) Cuando un igual se conecta, informa al servidor central de: Su dirección IP. Su contenido.
2) Alicia pregunta por “Hey Jude”.
3) Alicia solicita un archivo de Roberto.
Servidor directorio centralizado
Iguales
Alicia
Roberto
1
1
1
12
3
Problemas con el directorio centralizado entre iguales
Único punto de fallo. Cuello de botella de
rendimiento. Infracción del
copyright.
La transferencia de archivos está descentralizada, pero el contenido localizado está altamente descentralizado.
Directorio descentralizado entre iguales
Cada igual es o un líder de su grupo o está asignado a un líder de grupo.
El líder del grupo rastrea el contenido de todos sus “hijos”.
Los iguales consultan al líder del grupo y este puede consultar a otros líderes de grupo.
Igual ordinario
Igual líder de grupo
Relaciones de vecindad
en la red de superposición
Más sobre el directorio descentralizado
Red de superposición Los iguales son nodos. Arcos entre los iguales
y sus líderes de grupo. Arcos entre algunas
parejas de líderes de grupo.
Vecinos virtuales.Nodo de arranque El igual conectado es
asignado a un líder de grupo o nombrado líder.
Ventajas del acercamiento No hay servidor de
directorio centralizado: El servicio de localización
distribuido entre los iguales. Más difícil de cerrar.
Inconvenientes del acercamiento
Es necesario el nodo de arranque.
Los líderes de grupo pueden sobrecargarse.
Inundación de consultas entre iguales
Aplicación Gnutella. No hay jerarquía. Utilización del nodo de
arranque para saber sobre los otros.
Conexión del mensaje.
Envío de consulta a los vecinos.
Los vecinos responden a la consulta.
Si el igual consultado tiene el objeto, manda mensaje de vuelta al igual que pregunta.
conexión
Más sobre la inundación de consultas entre igualesVentajas Los iguales tienen
responsabilidades similares: no hay líderes de grupo.
Altamente descentralizado.
Ningún igual mantiene un directorio de información.
Inconvenientes Tráfico de consultas
excesivo. Radio de consultas:
puede no tener contenido estando presente.
Nodo de arranque. Mantenimiento de la
red de superposición.
Capítulo 2: Resumen
Requerimientos de servicios de aplicación: Fiabilidad, ancho de banda,
retraso.
Paradigma cliente-servidor. Modelo de servicio de
transporte de Internet. Orientado a la conexión,
fiable: TCP Poco fiable, datagramas: UDP
Nuestro estudio sobre las aplicaciones de redes ahora está completo.
Protocolos específicos: HTTP. FTP. SMTP, POP, IMAP. DNS.
Programación de sockets.
Distribución de contenidos. Cachés, CDN. Entre iguales.
Capítulo 2: Resumen
Típico intercambio de mensajes petición/ respuesta. El cliente solicita una
información o un servicio. El servidor contesta con
datos y un código estatus. Formatos del mensaje:
Cabeceras: campos que dan la información sobre los datos.
Datos: información que se comunica.
Lo más importante: lo aprendido sobre protocolos
Mensajes de control frente a mensajes de datos. En banda, fuera de
banda. Centralizado frente a
descentralizado. Sin estado frente a en
estado. Transferencia de mensajes
fiable frente a poco fiable. “Complejidad al límite de la
red”. Seguridad: autentificación.