Chapter 2: Capa de Aplicación - Armando ツ · 1 2: Application Layer 1 Chapter 2 Capa de...
Transcript of Chapter 2: Capa de Aplicación - Armando ツ · 1 2: Application Layer 1 Chapter 2 Capa de...
1
2: Application Layer 1
Chapter 2Capa de Aplicación
2: Application Layer 2
Chapter 2: Capa de Aplicación
2.1 Principios de lasaplicaciones de red2.2 Web and HTTP2.3 FTP 2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 Aplicaciones P2P
2: Application Layer 3
Chapter 2: Application LayerObjetivos:
Conceptos, implementación y aspectos de los protocolos de aplicaciones de red
transport-layer service modelsclient-server paradigmpeer-to-peer paradigm
Aprender acerca de los protocolosmediante la examinación de los protocolos popularesde nivel de aplicación
HTTPFTPSMTP / POP3 / IMAPDNS
2
2: Application Layer 4
Algunas aplicaciones de red
e-mailwebinstant messagingremote loginP2P file sharingmulti-user network gamesstreaming stored video clips
voice over IPreal-time video conferencinggrid computing
2: Application Layer 5
Creando una network appEscribir programas que
Corran en (diferentes) end systemsSe comunican a través de la redEjemplo., web server software comunicándose con browser software
No se necesita escribir software para dispositivos network-core
Dispositivos de Network-core no corren aplicaciones de usuarioLas aplicaciones en los end systems permiten un desarrollo y propagaciónrápida de las aplicaciones
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
2: Application Layer 6
Chapter 2: Capa de Aplicación
2.1 Principios de lasaplicaciones de red2.2 Web and HTTP2.3 FTP 2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 P2P applications
3
2: Application Layer 7
Arquitectura de Aplicaciones
Cliente-ServidorPeer-to-peer (P2P)Híbrido de cliente-servidor y P2P
2: Application Layer 8
Arquitectura Cliente-servidorservidor:
Siempre en un hostIP address permanentePara escalamiento se usan server farms
clientes:Se comunica con el serverPueden estar conectadosintermitentementePuede tener direcciones IP dinámicasNo se comunicadirectamente con otrocliente
cliente/servidor
2: Application Layer 9
Arquitectura pura P2P
No siempre en un servidorend systems arbitrariosdirectamente comunicadospeers se conectanintermitentemente y cambiande IP addresses
Altamente escalable pero dificilde manejar
peer-peer
4
2: Application Layer 10
Hybrido de cliente-servidor y P2PSkype
Voz sobre IP P2P applicationServer centralizado: encontrando direcciones de laspartes remotasEn la conexión cliente-cliente: directo (no a través de un servidor)
Mensajería InstántaneaChateando entre dos usuarios es P2PServicio centralizado: Detección de la presencia del cliente/localización
• Los usuarios registran su dirección IP en el servidorcentral cuando entran en línea
• Los usuarios contactan al servidor central paraencontrar las direcciones IP de los buddies
2: Application Layer 11
Processes communicatingProcesos: programa
corriendo en un host.Dentro del mismo host, dos procesos se puedencomunicar usandointer-process communication (definidopor el SistemaOperativo).Procesos en diferenteshosts se comunicanintercambiandomessages
Proceso Cliente: procesoque inicia la comunicación
Proceso servidor:Proceso que esperapara ser contactado
Nota: Aplicaciones con arquitectura P2P tienenprocesos cliente y procesos servidor
2: Application Layer 12
Sockets
Los procesos envían y recibenmensajes desde y hacia sussocketsocket análogo a una puerta
Procesos enviándose empujanmensajes por la puertaProcesos enviándose recae en la infraestructura de transporte de el otro lado de la puerta el cual trae el mensaje a un socket del proceso de recepción
process
TCP withbuffers,variables
socket
host orserver
process
TCP withbuffers,variables
socket
host orserver
Internet
controlledby OS
controlled byapp developer
5
2: Application Layer 13
Direccionamiento de los procesosPara recibir mensajes el proceso debe teneridentifierEl dispositivo host tieneuna única dirección IP de 32-bitQ: Es suficiente la dirección IP del Host para identificar el Proceso?
2: Application Layer 14
Direccionamiento de los procesosPara recibir mensajesel proceso debe teneridentifierLos dispositivos host tiene una unicadirección IP de 32 bitsQ: Es la dirección IP del host donde el proceso corresuficiente paraidentificar el proceso?
A: No, algunosprocesos puedencorrer en el mismohost
identifier incluye ambos dirección IP y número de puerto asociado con el proceso del host.Ejemplo port numbers:
HTTP server: 80Mail server: 25
Para enviar un mensajeHTTP al web server gaia.cs.umass.edu :
IP address: 128.119.245.12Port number: 80
2: Application Layer 15
Definiciones de los protocoloscapa-aplicación
Tipos de mensajesintercambiados
e.g., requerimiento, respuesta
Syntaxis del mensaje:Que campo en el mensaje y como los campos estándelimitados
Semántica del mensajeSignificado de la información que va en los campos
Reglas de cuando y como los procesos son enviados & respuestas a mensajes.
Protocolos de domain-public:Definidos en RFCsPermiten la interoperabilidade.g., HTTP, SMTP
Protocolos propietarios:e.g., Skype
6
2: Application Layer 16
Que servicios de transporte necesita unaaplicación?
Pérdida de datosAlgunas apli. (e.g., audio) pueden tolerar algo de pérdidaOtras aplicaciones (e.g., file transfer, telnet) requieren el 100% de fiabilidad para la transferencia de datos
TemporizaciónAlgunas apli. (e.g., Internet telephony, interactive games) requieren un bajodelay para ser “efectivas”
ThroughputAlgunas aplicaciones (e.g., multimedia) requieren unacantidad de throughput mínima para ser “efectivas”Otras apli. (“elastic apps”) pueden usar cualquierthroughput que ellasobtengan
SeguridadEncryption, data integridad, …
2: Application Layer 17
Requerimientos de servicios de Transporte de aplicaciones comunes
Aplicaciones
file transfere-mail
Web documentsreal-time audio/video
stored audio/videointeractive gamesinstant messaging
Perdida datos
no lossno lossno lossloss-tolerant
loss-tolerantloss-tolerantno loss
Throughput
elasticelasticelasticaudio: 5kbps-1Mbpsvideo:10kbps-5Mbpssame as above few kbps upelastic
Time Sensitive
nononoyes, 100’s msec
yes, few secsyes, 100’s msecyes and no
2: Application Layer 18
Servicios de Protocolo de transporte de InternetServicios TCP :
connection-oriented: se requiere setup entre los procesos cliente y servidorreliable transport entre los procesos de envío y recepciónflow control: el transmisor no inunde al receptor congestion control: ahogar al transmisor cuando la red estasobre cargadaNo provee: temporización, throughput mínimogarantizado, seguridad
Sevicios UDP:Transferencia de datos no confiable entre los procesos de envío y recepción.No provee setup de conexión, confiabilidad, control de flujo/congestion, temporización, throughput garantizado, seguridaddoes
Q: Porque hay UDP?
7
2: Application Layer 19
Internet apps: application, transport protocols
Aplicación
e-mailremote terminal access
Web file transfer
streaming multimedia
Internet telephony
Protocolo de la capaDe aplicación
SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]HTTP (eg Youtube), RTP [RFC 1889]SIP, RTP, proprietary(e.g., Skype)
Protocolo de transporte debajo
TCPTCPTCPTCPTCP or UDP
typically UDP
2: Application Layer 20
Chapter 2: Application layer
2.1 Principles of network applications
app architecturesapp requirements
2.2 Web and HTTP2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 P2P applications
2: Application Layer 21
Web and HTTP
Primero algo comúnLa Página Web consiste de objectosObjetos pueden ser archivos HTML file, imagenesJPEG, Java applet, archivo de audio ,..La página Web consiste de un archivo base HTML el cual incluye algunos objetos referenciados.Cada objeto esta direccionado por un URL Localizadorde recursos uniformeEjemplo URL:www.someschool.edu/someDept/pic.gif
host name path name
8
2: Application Layer 22
HTTP overview
HTTP: Protocolo de transferencia de hypertextoProtocolo de capa de aplicación de los Web’sModelo cliente/servidor
cliente: browser quesolicita y recibe“mostrando” objetosWebservidor: servidor Web envía objetos en respuesta a un requerimiento
PC runningExplorer
Server running
Apache Webserver
Mac runningNavigator
HTTP request
HTTP request
HTTP response
HTTP response
2: Application Layer 23
HTTP overview (continued)Usa TCP:
El cliente inicia la conexión TCP (creando el socket) al servidor, puerto 80El servidor acepta la conexiónTCP que viene del clienteMensajes HTTP (application-layer protocol messages) son intercambiados entre el browser (cliente HTTP) y el servidor Web (HTTP server)Conexión TCP cerrada
HTTP es “stateless”El servidor no mantieneinformación acerca de requerimientos de clientes pasados
Protocolos que mantienen“state” son complejos!La historia pasada (state) puede ser mantenidaSi el servidor/clientecrashes, sus vistas de “state” pueden ser inconsistentes
aside
2: Application Layer 24
Conexiones HTTP
Nonpersistent HTTP Cada objeto debe ser enviado por unaconexion TCP individual establecida.
Persistent HTTPObjetos múltiples
pueden ser enviadossobre una únicaconexión TCP entre el cliente y el servidor.
9
2: Application Layer 25
Nonpersistent HTTPSupongamos que el usario ingresa el URL
www.someSchool.edu/someDepartment/home.index
1a. El cliente HTTP inicia unaconexionTCP al HTTP server (proceso) a www.someSchool.edu en el puerto 80
2. El cliente HTTP envía un mensaje de requerimientoHTTP (conteniendo URL) dentro del socket de la conexión TCP. El Mensajeindica que ese cliente quierealgun objetoDepartment/home.index
1b. El servidor HTTP en el host www.someSchool.edu esperando por una conexionTCP al puerto 80. “acepta” la conexión, notificando al cliente
3. El servidor HTTP recibe el mensaje de requerimiento y forma , mensaje de respuestaconteniendo el objetorequerido, y envía el mensajedentro de su socket
tiempo
(contains text, references to 10
jpeg images)
2: Application Layer 26
Nonpersistent HTTP (cont.)
5. EL cliente HTTP recibe el mensaje de respuesta quecontiene el archivo html , muestra el html. Analizandola estructura del archivo html, encontrando 10 objetosreferenciados jpeg.
6. Pasos del 1-5 son repetidospara cada uno de los 10 objetos
4. El servidor HTTP server cierra la conexión TCP.
tiempo
2: Application Layer 27
Non-Persistent HTTP: Tiempo de respuestaDefinición RTT: tiempo que le
toma a un paquete pequeñoviajar desde el cliente al servidor y retornar
Tiempo de Respuesta:Un RTT para iniciar la conexión TCPUn RTT para que el requerimiento HTTP y unospocos primeros bytes de la respuesta HTTP retornenTiempo de transmisión del archivo
total = 2RTT+transmit time
time to transmit file
initiate TCPconnection
RTTrequestfile
RTT
filereceived
time time
10
2: Application Layer 28
Persistent HTTP
Nonpersistent HTTP issues:Requiere 2 RTTs porobjectoOverhead del SistemaOperativo para cadaconexión TCPLos browsers con frecuencia suelen abrir en paralelo conexiones TCP para traer objetosreferenciados
Persistent HTTPEl servidor deja conexionesabiertas despues de enviarla respuestaMensajes HTTP subsiguientes entre el mismo cliente/servidor son enviados sobre la conexiónabiertaEl cliente envíarequerimientos tan pronto como el encuentra un objeto referenciadoTan poco como un RTT esusado para todos los objetos referenciados
2: Application Layer 29
Mensaje de requerimiento HTTP
Dos tipos de mensajes HTTP : requerimiento, respuestaMensaje de requerimiento HTTP :
ASCII (human-readable format)
GET /somedir/page.html HTTP/1.1Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr
(extra carriage return, line feed)
Línea de requerimiento(GET, POST,
HEAD comandos)
Lineas de encabezado
Carriage return, line feed
Indica el final del mensaje
2: Application Layer 30
Mensaje de requerimiento HTTP : formato general
11
2: Application Layer 31
Uploading form input
Post method:Las páginas web frecuentementeincluyen form inputEl Input es subido al servidor en el campo entity body
URL method:Utiliza el método GETEl Input es subido en el campo URL de la línea de requerimiento:
www.somesite.com/animalsearch?monkeys&banana
2: Application Layer 32
Tipos de métodos
HTTP/1.0GETPOSTHEAD
Pregunta al servidorpara dejar los objetosrequeridos fuera de la respuesta
HTTP/1.1GET, POST, HEADPUT
Sube el archivo en el campo entity body paraespecificar el path en el campo URL
DELETEBorra el archivoespecificado en el campo URL
2: Application Layer 33
Mensaje de respuesta HTTP
HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html
data data data data data ...
Status line(protocol,
status code,status phrase)
headerlines
data, e.g., requestedHTML file
12
2: Application Layer 34
Codigos de Estado de la respuestaHTTP
200 OKRequerimiento exitoso, objeto requerido luego en estemensaje
301 Moved PermanentlyObjeto requerido ha sido movido, la nueva localización estaespecificada luego en este mensaje (Location:)
400 Bad RequestMensaje de requerimiento no entendido por el servidor
404 Not FoundDocumento requerido no encontrado en este servidor
505 HTTP Version Not Supported
Esta en la primera línea en el mensaje de respuesta server->client.
Ejemplos:
2: Application Layer 35
Probando HTTP (lado cliente) for yourself
1. Telnet to your favorite Web server:Opens TCP connection to port 80(default HTTP server port) at cis.poly.edu.Anything typed in sent to port 80 at cis.poly.edu
telnet cis.poly.edu 80
2. Type in a GET HTTP request:GET /~ross/ HTTP/1.1Host: cis.poly.edu
By typing this in (hit carriagereturn twice), you sendthis minimal (but complete) GET request to HTTP server
3. Look at response message sent by HTTP server!
2: Application Layer 36
User-server state: cookies
La mayoría de sitiosWeb usan cookies
Cuatro componentes:1) cookie header line en el
mensaje HTTP respuesta
2) cookie header line en el mensaje HTTP requerimiento
3) cookie file mantiene en el host de usuario, administrado por el browser del usuario
4) Base de datos back-end en el sitio Web
Ejemplo:Susan siempre accesaInternet desde su PCVisita un sitio específicode e-commerce porprimera vezCuando el requerimientoinicial HTTP llega al sitio, el sitio crea:
Un unico IDUna entrada para el ID en la base de datos backend
13
2: Application Layer 37
Cookies: manteniendo el “state” (cont.)cliente servidor
usual http response msg
usual http response msg
cookie file
Una semana despues:
usual http request msgcookie: 1678 cookie-
specificaction
acceso
ebay 8734usual http request msg Amazon server
creates ID1678 for user crea
la entrada
usual http response Set-cookie: 1678
ebay 8734amazon 1678
usual http request msgcookie: 1678 cookie-
spectificaction
accesoebay 8734amazon 1678
backenddatabase
2: Application Layer 38
Cookies (continuación)Que pueden llevar los cookies:
Autorizaciónshopping cartsRecomendacionesEstado de la sesión del usuario (Web e-mail)
Cookies y la privacidad:cookies permiten que los sitios aprendan bastanteacerca de unoUsted debe proporcionar sunombe y su e-mail a los sitios
aside
Como mantenerse en “state”:Los protocolos de los endpoints: mantienen el estado del sender/receiver sobre multiples transaccionescookies: Mensaje http lleva state
2: Application Layer 39
Web caches (proxy server)
El usuario debeconfigurar su browser: Acceso al web via cacheEl browser envia todoslos requerimientosHTTP al cache
El objeto en la cache: El cache retorna el objectoSi no el cache solicita el objeto al servidororiginal, luego retornael objeto al cliente
Objetivo: Satisfacer el requerimento del cliente sin involucrar al servidor original
client
Proxyserver
client
HTTP request
HTTP response
HTTP request HTTP request
origin server
origin server
HTTP response HTTP response
14
2: Application Layer 40
Más acerca de Web caching
cache actua comoambos cliente y servidorTipicamente el cache es instalado por el ISP (university, company, residential ISP)
Por que Web caching?Reduce los tiempos de respuesta para los requerimientos clienteReduce el tráfico en el enlace de acceso de unainstitución.Cuando el Internet estadenso con los caches: habilita un contenido“poor”para entregarefectivamente contenido(tambien para la comparticion de archivosP2P )
2: Application Layer 41
Ejemplos de Caching Asunciones
average object size = 100,000 bitsavg. request rate from institution’s browsers to origin servers = 15/secdelay desde el router institucionalhacia algun servidor origen y de regreso al router = 2 sec
ConsecuenciasUtilización de la LAN = 15%Utilización del enlace de acceso = 100%total delay = Internet delay + access delay + LAN delay
= 2 sec + minutes + milliseconds
originservers
publicInternet
institutionalnetwork 10 Mbps LAN
1.5 Mbps access link
institutionalcache
2: Application Layer 42
Ejemplo de Caching (cont)Solución posible
Incrementar el ancho de banda del enlace de acceso, 10 Mbps
consecuenciasUtilización de la LAN = 15%Utilización del enlace de acceso = 15%Total delay = Internet delay + access delay + LAN delay
= 2 sec + msecs + msecsLos upgrade por lo general son costosos
originservers
publicInternet
institutionalnetwork 10 Mbps LAN
10 Mbps access link
institutionalcache
15
2: Application Layer 43
Ejemplo de Caching (cont)
Posibles soluciones: instalar un cacheSupongamos un hit rate de 0.4
Consecuencia40% de los requerimientos son satisfechos casiinmediatamente60% de los requerimientos son satisfechos por el origin serverLa utilización del enlace de acceso se reduce al 60%, resultando en delays insignificantes (aprox 10 msec)total avg delay = Internet delay + access delay + LAN delay = .6*(2.01) secs + .4*milliseconds < 1.4 secs
originservers
publicInternet
institutionalnetwork 10 Mbps LAN
1.5 Mbps access link
institutionalcache
2: Application Layer 44
GET Condicional
Objetivo: no envie el obeto siel cache tiene una version actualizada cacheadacache: especifica la fecha en que la copia fue cacheada en el requerimiento HTTP If-modified-since:
<date>
servidor: respuesta no contiene objetos si la copiacacheada esta actualizada: HTTP/1.0 304 Not
Modified
cache servidorHTTP request msgIf-modified-since:
<date>
HTTP responseHTTP/1.0
304 Not Modified
objetono
modificado
HTTP request msgIf-modified-since:
<date>
HTTP responseHTTP/1.0 200 OK
<data>
objetomodificado
2: Application Layer 45
Chapter 2: Application layer
2.1 Principles of network applications2.2 Web and HTTP2.3 FTP2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 P2P applications
16
2: Application Layer 46
FTP: Protocolo de transferencia de archivo
Transferencia de archivo hacia/desde host remotoModelo cliente/servidor
cliente: Lado que inicia la transferencia (ya sea hacia/desde el remoto)servidor: host remoto
ftp: RFC 959ftp server: puerto 21
file transfer FTPserver
FTPuser
interface
FTPclient
local filesystem
remote filesystem
Usuarioen el host
2: Application Layer 47
FTP: separado control, y conexiones de datos
FTP cliente contacta al FTP server por el puerto 21, TCP esel protocolo de transporteEl cliente es autorizado sobrela conexión de controlEL cliente mira el directorioremoto mediante el envió de comandos sobre la control de conexión.Cuando el servidor recibe un comando de transferencia de archivos, el servidor abre una s 2nd TCP conexión (para el file) al clienteDespués de la transferencia de un archivo, el servidor cierra la conexión de datos.
FTPcliente
FTPservidor
TCP control connectionpuerto 21
TCP data connectionpuerto 20
El servidor abre otraconexión TCP de datos paratransferir otro archivo.La conexión de control: “out of band”El servidor FTP mantiene“state”: el directoriocorriente, y la autenticaciónprevia
2: Application Layer 48
FTP Comandos, respuestas
Ejemplo de comandos:Envío de un texto ASCII sobre el canal de controlUSER usernamePASS password
LIST retorna la lista de los archivos en el directoriocorrienteRETR filename recupera(gets) archivoSTOR filename guarda(puts) archivo en el host remoto
Ejemplo de codigos de retornoCódigo de estado y frases(como HTTP)331 Username OK, password required125 data connection already open; transfer starting425 Can’t open data connection452 Error writing file
17
2: Application Layer 49
Chapter 2: Application layer
2.1 Principles of network applications2.2 Web and HTTP2.3 FTP 2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 P2P applications2.7 Socket programming with TCP2.8 Socket programming with UDP
2: Application Layer 50
Correo ElectrónicoTres principales
componentes:Agentes de usuarioServidores mail simple mail transfer protocol: SMTP
Agente de usuarioalias. “mail reader”redactar, editar, leer mensajesde correoe.g., Eudora, Outlook, elm, Mozilla ThunderbirdLos mensajes de entrada y salida son guardados en el servidor
user mailbox
outgoing message queue
mailserver
useragent
useragent
useragent
mailserver
useragent
useragent
mailserver
useragent
SMTP
SMTP
SMTP
2: Application Layer 51
Correo Electrónico: mail servers
Mail ServersBuzón (mailbox) Contiene los mensajes entrantes del usuariomessage queue de los mensajes de correo saliente(a ser enviados) SMTP protocol entre los mail servers para enviar los mensajes de correo
cliente: enviando mail server“servidor”: recibiendomail server
mailserver
useragent
useragent
useragent
mailserver
useragent
useragent
mailserver
useragent
SMTP
SMTP
SMTP
18
2: Application Layer 52
Correo Electrónico: SMTP [RFC 2821]
Usa TCP para una transferencia fiable de los mensajesde correo desde el cliente al servidor, puerto 25Transferencia directa: enviando desde el servidor y recibiendo por el servidorTres fases para la transferencia
handshaking (saludo)Transferencia del mensajecierre
Interacción comando/respuestacomandos: ASCII textrespuesta: código de estado y frase
Mensaje debe ser en ASCII 7 bit
2: Application Layer 53
Escenario: Alicia envía un mensaje a Bob1) Alicia usa agente de usuario
para redactar un [email protected]
2) El agente de usuario de Alicia envía el mensaje a sumail server; mensaje espuesto en una cola de mensajes
3) EL lado cliente de SMTP abre una conexión TCP con el mail server de Bob
4) Cliente SMTP envia el mensaje de Alice sobre la conexiónTCP
5) El mail server de Bob coloca el mensaje en el buzón de Bob
6) Bob invoca su agente de usuario para leer el mensaje.
useragent
mailserver
mailserver user
agent
1
2 3 4 56
2: Application Layer 54
Ejemplo de interacción SMTPS: 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: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
19
2: Application Layer 55
SMTP: palabras finales
SMTP usa conexionespersistentesSMTP requiere mensajes(header & body) tienen queser en ASCII 7 bitEl servidor SMTP usaCRLF.CRLF paradeterminar el final del mensaje
Comparasión con HTTP:HTTP: jala (pull)SMTP: empuja (push)
Ambos tienen interacciónde comandos/repuestasASCII, codigos de estao
HTTP: cada objeto estáencapsulado en su propiomensaje de respuestaSMTP: Multiples objetosson enviados en mensajesde multiples partes
2: Application Layer 56
Formato del mensaje de correoSMTP: Protocolo para el
intercambio de mensajesde correo
RFC 822: estandard para el formato del mensaje de texto:Encabezado (header lines), e.g.,
To:From:Subject:
different from SMTP commands!
Cuerpo (body)El “mensaje”, caractaresASCII unicamente
header
body
blankline
2: Application Layer 57
Formato mensaje: extensiones multimedia
MIME: Extensión de correo multimedia, RFC 2045, 2056Líneas adicionales en el mensaje de cabecera especificanel tipo de contenido MIME
From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data
Tipo de dato multimedia, subtipo, declaración
de parámetros
Metodo usado paraCodificar el dato
MIME version
Dato codificado
20
2: Application Layer 58
Protocolos de acceso de correo
SMTP: entrega/almacena hasta el servidor receptor serverProtocolo de acceso al correo: recupera del servidor
POP: Post Office Protocol [RFC 1939]• autorización (agente <-->servidor) y bajada (download)
IMAP: Internet Mail Access Protocol [RFC 1730]• Más características (más complejo)• manipulación de los mensajes guardados en el servidor
HTTP: gmail, Hotmail, Yahoo! Mail, etc.
useragent
sender’s mail server
useragent
SMTP SMTP accessprotocol
receiver’s mail server
2: Application Layer 59
Protocolo POP3Fase autorización
Comandos cliente: user: declarar el usernamepass: password
Respuestas del servidor+OK
-ERR
Fase transacción, cliente:list: lista los números de mensajesretr: recupera los mensajes por númerodele: borrarquit
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
2: Application Layer 60
POP3 e IMAPMás acerca de POP3
Los ejemplos previosusan el modo“download and delete”Bob no puede volver a leer sus correos si el cambia de cliente“Download-and-keep”: copia los mensajes en diferentes clientesPOP3 es stateless através de las sesiones
IMAPMantiene todos los mensajes en un lugar: el servidorPerimete a los usuariosorganizar los mensajes en carpetasIMAP mantiene el state del usuario a través de lassesiones:
Nombres de las carpeta y los mapeos entre los IDs de los mensajes y el nombre de carpeta
21
2: Application Layer 61
Chapter 2: Application layer
2.1 Principles of network applications2.2 Web and HTTP2.3 FTP 2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 P2P applications
2: Application Layer 62
DNS: Sistema de Dominio de NombresPersonas: algunos
identificadores:Cédula de identidad, nombre, número de pasaporte
Internet hosts, routers:Dirección IP (32 bit) –usado paradireccionamiento de los datagramas“nombre”, e.g., ww.yahoo.com – usado porlos humanos
Q: Existe algun mapeo enttrela dirección IP y el nombre?
Sistema de Dominio de nombres:Base de datos distribuida:implementado en jerarquía de algunos name serversProtocolo de la capa de aplicaciónhost, routers, name servers para comunicarse necesitanresolver nombres(address/name translation)
nota: la función core de Internet implementadocomo un protocolo de la capa de aplicaciónComplejidad en las puntasde la red
2: Application Layer 63
DNS Por que no centralizar
DNS?Unico punto de fallaAlto volumen de tráficoBase de datos distantecentralizadaMantenimiento
No escalable!
Servicios DNSTraducción de nombres de hosts a direcciones IPhost aliasing
Alias de nombresServidores de correoaliasingDistribución de carga
Replicación de servidores Web: Conjunto de direccionesIP para un nombre
22
2: Application Layer 64
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
poly.eduDNS servers
umass.eduDNS serversyahoo.com
DNS serversamazon.comDNS servers
pbs.orgDNS servers
Base de datos distribuída y Jerarquica
El cliente quiere la IP para www.amazon.com; El cliente pregunta al root server para encontrarDNS server comEl cliente pregunta al DNS server com para obtenerel amazon.com DNS serverEl cliente pregunta amazon.com DNS server paraobtener la dirección IP para www.amazon.com
2: Application Layer 65
DNS: Root name serversContactado por el servidor de nombres local que no sabe como resolver el nombreroot name server:
Al menos proporciona el nombre y dirección del servidor autorizado de la zona de más alto nivel para el dominio buscadoExisten 13 servidores raíz en toda Internet (7 no son servidoresúnicos)
b USC-ISI Marina del Rey, CAl ICANN Los Angeles, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA (and 36 other locations)
i Autonomica, Stockholm (plus 28 other locations)
k RIPE London (also 16 other locations)
m WIDE Tokyo (also Seoul, Paris, SF)
a Verisign, Dulles, VAc Cogent, Herndon, VA (also LA)d U Maryland College Park, MDg US DoD Vienna, VAh ARL Aberdeen, MDj Verisign, ( 21 locations)
2: Application Layer 66
TLD and Authoritative Servers
Top-level domain (TLD) servers:Responsable para com, org, net, edu, etc, y todo los top-
level country domains uk, fr, ca, jp.Authoritative DNS servers:
Son los servidores DNS organizacionales, entregan el authoritative hostname con la IP mapeado para los servidores organizacionales (e.g., Web, mail).Pueden ser mantenidos por la organización o por el service providerEl solamente retorna respuestas a los requerimientos acerca de dominios de nombres que están instalados en su sistema de configuración
23
2: Application Layer 67
Local Name Server
No pertenecen estrictamente a la jerarquiaCada ISP (ISP residencial, compañía, universidad) tienen uno.
También llamado “default name server”Cuando el host hace un requerimiento DNS, la pregunta es enviada a su servidor local DNS
Actua como un proxy, envía la pregunta dentrode la jerarquía.
2: Application Layer 68
requesting hostcis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS serverdns.poly.edu
1
23
4
5
6
authoritative DNS serverdns.cs.umass.edu
78
TLD DNS server
Ejemplo de resolución de nombresDNS
Un Host en cis.poly.edu quiere la dirección IP paragaia.cs.umass.edu
Consultas iterativas:El servidorcontactado contestacon el nombre del server a ser contactado“Yo no conozco el nombre, peropregunte a esteservidor”
2: Application Layer 69
requesting hostcis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS serverdns.poly.edu
1
2
45
6
authoritative DNS serverdns.cs.umass.edu
7
8
TLD DNS server
3Consulta recursiva:Pone la carga en el servidor de nombrescontactado
Ejemplo de resolución de nombreDNS
24
2: Application Layer 70
DNS: caching y actualización de and updating registros
Una vez que (cada) name server aprende el mapping, el caches mapping
Las entradas en el cache tienen un tiemout, desaparecen luego de cierto tiempoLos servidoresTLD servers son tipicamentecacheado en los servidores locales de nombres
• De este modo el root name servers no es visitado a menudo
actualización/notificaciones son mecanismos queestan bajo el diseño de IETF (Internet Engineering Task Force)
RFC 2136http://www.ietf.org/html.charters/dnsind-charter.html
2: Application Layer 71
Registros DNSDNS: La base de datos distribuida guarda los registros fuente (RR)
Type=NSname es el dominio (e.g. foo.com)value es el hostname del servidor de nombresautoritativo para estedominio
RR format: (name, value, type, ttl)Type=A
Name es el hostnamevalue es la direcciónIP
Type=CNAMEname es el nombre alias paraalguien realwww.ibm.com es realmenteservereast.backup2.ibm.com
value es el nombre real
Type=MXvalue es el nombre del mailserver asociado con el nombre
2: Application Layer 72
Protocolo y mensajes DNSProtocolo DNS: preguntas y respuestas , ambos con el
mismo formato de mensaje
msg headeridentificacion: 16 bit # para preguntas, para lasrespuesta se usa el mismo #Flags (banderas):
Pregunta o respuestaRecursion deseadaRecursion disponibleRespuesta esautoritativa
25
2: Application Layer 73
Protocolo y mensajes DNS
Nombre, campos tipoPara una pregunta
RRs en respuesta a una
preguntaRegistros para los
servidores autoritativos
Información util adicionalQue puede ser usada
2: Application Layer 74
Insertando registros dentro de un DNS
ejemplo: Nuevo inicio “Network Utopia”Nombre registrado networkuptopia.com en el DNS registrar (e.g., Network Solutions)
Provee nombres, direcciones IP del servidor autoritativo(primary and secondary)registrar inserta dos RRs en el servidor TLD com:
(networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)
Crear en el servidor autoritativo: Ingrese el registroA para www.networkuptopia.com; Tipee el registroMX para networkutopia.com
2: Application Layer 75
Chapter 2: Application layer
2.1 Principles of network applications
app architecturesapp requirements
2.2 Web and HTTP2.4 Electronic Mail
SMTP, POP3, IMAP2.5 DNS
2.6 P2P applications
26
2: Application Layer 76
Arquitectura Pura P2P
no siempre en un serverSistemas finales arbitrarios se comunicandirectamenteLos peers conectadosson intermitentes y cambian de dirección IP
Tres tópicos:Distribución de archivosBuscando InformaciónCaso de estudio: Skype
peer-peer
2: Application Layer 77
Distribución de archivos: Servidor-Cliente vs P2PPregunta : Cuanto tiempo toma distribuir un
archivo desde un servidor a N peers?
us
u2d1 d2u1
uN
dN
Server
Network (with abundant bandwidth)
File, size F
us: bandwidth subidadel serverui: bandwidth subidadel peer i
di: bandwidth de bajada del peer i
2: Application Layer 78
Tiempo de distribución de archivo: servidor-cliente
us
u2d1 d2u1
uN
dN
Server
Network (with abundant bandwidth)
FEl servidor enviasecuencialmente las N copias:
NF/us time El cliente i le toma el tiempo F/di parabajar
Incremento linear en N
= dcs = max { NF/us, F/min(di) }i
Tiempo para distribuir Fa N clientes usando
el enfoque cliente/servidor
27
2: Application Layer 79
Tiempo de distribución de archivo: P2P
us
u2d1 d2u1
uN
dN
Server
Network (with abundant bandwidth)
F
El servidor debe enviaruna copia en el tiempo : F/usEl clinte i toma el tiempoF/di en bajarNF bits deben ser bajados (agregado)
Velocidad más rapida posible de subida : us + Σui
dP2P = max { F/us, F/min(di) , NF/(us + Σui) }i
2: Application Layer 80
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
Min
imum
Dis
tribu
tion
Tim
e P2PClient-Server
Ejemplo: Servidor-cliente vs. P2P
2: Application Layer 81
Distribución de archivos: BitTorrent
tracker: rastrear los peers Participantes en eltorrent
torrent: grupo de peers que intercambianPedazos de un archivo
obtain listof peers
trading chunks
peer
Distribución de archivosP2P
28
2: Application Layer 82
BitTorrent (1)El archivo es dividido en pedazos chunks de 256KB.peer uniendose al torrent:
No tiene pedazos (chunks), pero los acumulará a través del tiempoRegistros con los rastreos para obtener la lista de peers, conectados a un subset de peers (vecinos)
Mientras se baja, el peer sube pedazos (chunks) a otros peers. Los peers pueden ir y venirUna vez que el peer tiene el archivo entero, el puede(egoistamente) dejar o (desinteresado) permanecer.
2: Application Layer 83
BitTorrent (2)Halando pedazos Chunks
En cualquier momento, peers diferentes tienen diferentessubcojuntos de pedazos de archivosperiódicamente, un peer (Alice) pregunta a cadavecino por una lista de los pedazos chunks que ellostengan.Alice envia el requerimientopara sus pedazos faltantes
Los raros primero
Enviando Chunks: tit-for-tatAlice envía pedazos a 4 vecinos a la más altavelocidad
re-evalua los top 4 cada10 secs
cada 30 secs: aleatoriamentese selecciona otro peer, empieza a enviar chunks
Los peer recientementeescogidos se unen al top 4“optimista nunca se obstruye”
2: Application Layer 84
BitTorrent: Tit-for-tat(1) Alice “no obstruye” Bob(2) Alice se convierte en uno de los top 4 de Bob’s(3) Bob se convierte en uno de los top 4 de Alice`s
Con velocidades altas de subida se puede encontrarmejores partner y obtener el archivo mas rapido
29
2: Application Layer 85
P2P: Buscando información
Compartición archivos (eg e-mule)El indice dinámicamenterastrea la ubicación de los archivos que comparten los peers.Los peers necesitan deciral indice que es lo quetienen.Los peers buscan el indicepara determinar donde los archivos pueden ser encontrados
Mensajería instántaneaEl indice mapea el nombrede usuario con la ubicación.Cuando el usuario inicia la aplicación de IM, el necesita informar el indicede su ubicaciónLos Peers buscan el indicepara determinar la dirección IP del usuario.
Indices en sistemas P2P: mapea la información a la ubicación peer (ubicación = Dirección IP & número de puerto)
2: Application Layer 86
P2P: indice centralizado
Diseño original de “Napster”
1) Cuando el peer se conecta, el informa a un servidor central:
Dirección IPcontenido
2) Alice pregunta por“Hey Jude”
3) Archivo solicitado porAlice desde BoB
centralizeddirectory server
peers
Alice
Bob
1
1
1
12
3
2: Application Layer 87
P2P: Problemas con los directorioscentralizados
Unico punto de fallaDesempeño: cuellos de botellaIncumplimiento de los derechos de copia(copyright): juicio
La transferencia de archivos esdescentralizada, pero la forma de localizar el contenido es altamentecentralizada
30
2: Application Layer 88
Inundación de consultas
Totalmente distribuidono servidor central
Usado por GnutellaCada peer indexa los archivos que va tenerdisponible paracompartición (no otrosarchivos)
Overlay de red: graficoBorde entre el peer X y Y , si existe una conexionTCPTodos los peer activos y bordes forman un formato de red Borde: enlace virtual (nofísico)Un peer dado estatipicamente conectadocon < 10 vecinos del overlay
2: Application Layer 89
Inundación de consultas
Query
QueryHit
Query
Query
QueryHit
Query
Query
QueryHit
File transfer:HTTPMensaje de consulta
enviado sobre una conexionTCP existenteLos peers envian
mensajes de consultaQueryHit
enviados sobre el Camino de reverso
Escalabilidad:Alcanse limitadode la inundación
2: Application Layer 90
Gnutella: Peer joining
1. Uniéndose el peer Alice puede encontrar otrospeer en la red Gnutella
2. Alice intenta secuencialmente conexiones TCP con los candidatos a peer hasta realizar el setup con Bob
3. Inundación: Alice envia un mensaje Ping a Bob; Bob envia el mensjae Ping a sus vecinos de overlay (quien a su vez envía a sus vecinos.)
Los peers que reciben el mensaje Ping responden a Alice con un mensaje Pong
4. Alice recibe algunos mensajes Pong, y puedehacer el setup de conexiones adicionales TCP
31
2: Application Layer 91
Overlay Jerarquico
Entre indices centralizados, enfoque de inundación de consultasCada peer es ya sea un super nodo o asignado a un super nodo
ConexionesTCP entre peer y su super nodo.ConexionesTCP entre algúnpar de super nodos.
El super nodo rastresa el contenido en sus hijos
ordinary peer
group-leader peer
neighoring relationshipsin overlay network