Chapter 2 Capa de Aplicación

(1)

2: Application Layer 1

Chapter 2 Capa de Aplicación

Chapter 2: Capa de Aplicación

2.1 Principios de las

aplicaciones de red

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

2.6 Aplicaciones P2P

Chapter 2: Application Layer

Objetivos:

Conceptos,

implementación y

aspectos de los

protocolos de

aplicaciones de red

transport-layer

service models

client-server

paradigm

peer-to-peer

paradigm

Aprender acerca de

los protocolos

mediante la

examinación de los

protocolos populares

de nivel de aplicación

HTTP FTP

(2)

Algunas aplicaciones de red

e-mail

web

instant messaging

remote login

P2P file sharing

multi-user network

games

streaming stored video

clips

voice over IP

real-time video

conferencing

grid computing

Creando una network app

Escribir programas que Corran en (diferentes) end

systems

Se comunican a través de la

red

Ejemplo., 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 usuario

Las aplicaciones en los end

systems permiten un desarrollo y propagación rápida de las aplicaciones

application

transport network data link physical

application

Chapter 2: Capa de Aplicación

2.1 Principios de las

aplicaciones de red

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

(3)

Arquitectura de Aplicaciones

Cliente-Servidor

Peer-to-peer (P2P)

Híbrido de cliente-servidor y P2P

Arquitectura Cliente-servidor

servidor:

Siempre en un host

IP address

permanente

Para escalamiento se

usan server farms

clientes:

Se comunica con el server Pueden estar conectados

intermitentemente

Puede tener direcciones IP

dinámicas

No se comunica

directamente con otro cliente

cliente/servidor

Arquitectura pura P2P

No siempre en un servidor end systems arbitrarios

directamente comunicados peers se conectan

intermitentemente y cambian de IP addresses

Altamente escalable pero dificil de manejar

(4)

Hybrido de cliente-servidor y P2P

Skype

Voz sobre IP P2P application

Server centralizado: encontrando direcciones de las

partes remotas

En la conexión cliente-cliente: directo (no a través de un

servidor) Mensajería Instántanea

Chateando entre dos usuarios es P2P

Servicio centralizado: Detección de la presencia del

cliente/localización

• Los usuarios registran su dirección IP en el servidor central cuando entran en línea

• Los usuarios contactan al servidor central para encontrar las direcciones IP de los buddies

Processes communicating

Procesos:

programa

corriendo en un host.

Dentro del mismo host,

dos procesos se pueden

comunicar usando

inter-process

communication

(definido

por el Sistema

Operativo).

Procesos en diferentes

hosts se comunican

intercambiando

messages

Proceso Cliente:

proceso

que inicia la

comunicación

Proceso servidor:

Proceso que espera

para ser contactado

Nota: Aplicaciones con

arquitectura P2P tienen

procesos cliente y

procesos servidor

Sockets

Los procesos envían y reciben mensajes desde y hacia sus socket

socket análogo a una puerta Procesos enviándose empujan

mensajes por la puerta

Procesos enviándose recae en

la infraestructura de transporte de el otro lado de

process

TCP with buffers, variables

socket host or server

process

TCP with buffers, variables

socket host or server

(5)

Direccionamiento de los procesos

Para recibir mensajes el

proceso debe tener

identifier

El dispositivo host tiene

una única dirección IP de

32-bit

Q:

Es suficiente la

dirección IP del Host

para identificar el

Proceso?

Direccionamiento de los procesos

Para recibir mensajes

el proceso debe tener

identifier

Los dispositivos host

tiene una unica

dirección IP de 32 bits

Q:

Es la dirección IP

del host donde el

proceso corre

suficiente para

identificar el proceso?

A:

No,

algunos

procesos pueden

correr en el mismo

host

identifier

incluye ambos

dirección IP y número de

puerto

asociado con el

proceso del host.

Ejemplo port numbers:

HTTP server: 80 Mail server: 25

Para enviar un mensaje

HTTP al web server

gaia.cs.umass.edu :

IP address:128.119.245.12 Port number:80

Definiciones de los protocolos

capa-aplicación

Tipos de mensajes intercambiados

e.g., requerimiento,

respuesta

Syntaxis del mensaje: Que campo en el mensaje y

como los campos están delimitados

Semántica del mensaje Significado 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 RFCs Permiten la

(6)

Que servicios de transporte necesita una

aplicación?

Pérdida de datos

Algunas apli. (e.g., audio) pueden tolerar algo de pérdida Otras aplicaciones (e.g., file

transfer, telnet) requieren el 100% de fiabilidad para la transferencia de datos

Temporización

Algunas apli. (e.g.,

Internet telephony,

interactive games)

requieren un bajo

delay para ser

“efectivas”

Throughput

Algunas aplicaciones (e.g.,

multimedia) requieren una

cantidad de throughput

mínima para ser

“efectivas”

Otras apli. (“elastic apps”)

pueden usar cualquier

throughput que ellas

obtengan

Seguridad

Encryption, data

integridad, …

Requerimientos de servicios de Transporte de

aplicaciones comunes

Aplicaciones

file transfer e-mail Web documents real-time audio/video

stored audio/video interactive games instant messaging

Perdida datos

no loss no loss no loss loss-tolerant

loss-tolerant loss-tolerant no loss

Throughput

elastic elastic elastic

audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic

Time Sensitive

no no no

yes, 100’s msec

yes, few secs yes, 100’s msec yes and no

Servicios de Protocolo de transporte de

Internet

Servicios TCP :

connection-oriented:se requiere setup entre los procesos cliente y servidor reliable transport entre los

procesos de envío y recepción flow control: el transmisor no

inunde al receptor congestion control:ahogar al

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

(7)

Internet apps: application, transport protocols

Aplicación

e-mail remote terminal access Web file transfer streaming multimedia

Internet telephony

Protocolo de la capa De 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

TCP TCP TCP TCP TCP or UDP

typically UDP

Chapter 2: Application layer

2.1 Principles of

network applications

app architectures app requirements

2.2 Web and HTTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

2.6 P2P applications

Web and HTTP

Primero algo común

La Página Web consiste de objectos

Objetos pueden ser archivos HTML file, imagenes

JPEG, Java applet, archivo de audio ,..

La página Web consiste de un archivo base HTMLel

cual incluye algunos objetos referenciados.

Cada objeto esta direccionado por un URL Localizador de recursos uniforme

Ejemplo URL:

www.someschool.edu/someDept/pic.gif

(8)

HTTP overview

HTTP: Protocolo de

transferencia de

hypertexto

Protocolo de capa de aplicación de los Web’s Modelo cliente/servidor

cliente:browser que

solicita y recibe “mostrando” objetos Web

servidor:servidor Web

envía objetos en respuesta a un requerimiento

PC running Explorer

Server running Apache Web

server

Mac running Navigator

HTTP r_equest

HTTP reques

t

HTTP r_espons e

HTTP respon

se

HTTP overview (continued)

Usa TCP:

El cliente inicia la conexión TCP (creando el socket) al servidor, puerto 80

El servidor acepta la conexión TCP que viene del cliente Mensajes 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 mantiene información acerca de requerimientos de clientes pasados

Protocolos que mantienen “state” son complejos! La historia pasada (state)

puede ser mantenida Si el servidor/cliente

crashes, sus vistas de “state” pueden ser inconsistentes

aside

Conexiones HTTP

Nonpersistent HTTP

Cada objeto debe ser

enviado por una

conexion TCP

individual establecida.

Persistent HTTP

(9)

Nonpersistent HTTP

Supongamos que el usario ingresa el URL

www.someSchool.edu/someDepartment/home.index

1a.El cliente HTTP inicia una conexionTCP al HTTP server (proceso) a

www.someSchool.edu en el puerto80

2.El cliente HTTPenvía un

mensaje de requerimiento HTTP(conteniendo URL) dentro del socket de la conexión TCP. El Mensaje indica que ese cliente quiere algun objeto

Department/home.index

1b.El servidor HTTPen el host

www.someSchool.edu

esperando por una conexion TCP al puerto 80. “acepta” la conexión, notificando al cliente

3.El servidor HTTPrecibe el mensaje de requerimiento y forma , mensaje de respuesta

conteniendo el objeto requerido, y envía el mensaje dentro de su socket

tiempo

(contains text, references to 10

jpeg images)

Nonpersistent HTTP (cont.)

5.EL cliente HTTP recibe el mensaje de respuesta que contiene el archivo html , muestra el html. Analizando la estructura del archivo html, encontrando 10 objetos referenciados jpeg.

6.Pasos del 1-5 son repetidos para cada uno de los 10 objetos

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

tiempo

Non-Persistent HTTP: Tiempo de

respuesta

Definición RTT:tiempo que le toma a un paquete pequeño viajar desde el cliente al servidor y retornar Tiempo de Respuesta: Un RTT para iniciar la

conexión TCP Un RTT para que el

requerimiento HTTP y unos pocos primeros bytes de la respuesta HTTP retornen Tiempo de transmisión del

archivo

total = 2RTT+transmit time

time to transmit file initiate TCP

connection

RTT

request file

RTT

file received

(10)

Persistent HTTP

Nonpersistent HTTP issues: Requiere 2 RTTs por

objecto

Overhead del Sistema Operativo para cada conexión TCP Los browsers con

frecuencia suelen abrir en paralelo conexiones TCP para traer objetos referenciados

Persistent HTTP

El servidor deja conexiones abiertas despues de enviar la respuesta

Mensajes HTTP subsiguientes entre el mismo cliente/servidor son enviados sobre la conexión abierta

El cliente envía

requerimientos tan pronto como el encuentra un objeto referenciado Tan poco como un RTT es

usado para todos los objetos referenciados

Mensaje de requerimiento HTTP

Dos tipos de mensajes HTTP : requerimiento

,

respuesta

Mensaje de requerimiento HTTP :

ASCII (human-readable format)

GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: 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

(11)

Uploading form input

Post method:

Las páginas web

frecuentemente

incluyen form input

El Input es subido al

servidor en el campo

entity body

URL method:

Utiliza el método GET

El Input es subido en

el campo URL de la

línea de requerimiento:

www.somesite.com/animalsearch?monkeys&banana

Tipos de métodos

HTTP/1.0

GET

POST

HEAD

Pregunta al servidor

para dejar los objetos requeridos fuera de la respuesta

HTTP/1.1

GET, POST, HEAD

PUT

Sube el archivo en el

campo entity body para especificar el path en el campo URL

DELETE

Borra el archivo

especificado en el campo URL

Mensaje de respuesta HTTP

HTTP/1.1 200 OK Connection close

Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821

Content-Type: text/html

data data data data data ... Status line

(protocol, status code, status phrase)

header lines

(12)

Codigos de Estado de la respuesta

HTTP

200 OK

Requerimiento exitoso, objeto requerido luego en este

mensaje

301 Moved Permanently

Objeto requerido ha sido movido, la nueva localización esta

especificada luego en este mensaje (Location:)

400 Bad Request

Mensaje de requerimiento no entendido por el servidor

404 Not Found

Documento 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:

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.1 Host: cis.poly.edu

By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server

3. Look at response message sent by HTTP server!

User-server state: cookies

La mayoría de sitios

Web usan cookies

Cuatro componentes:

1) cookie header line en el mensaje HTTP

respuesta

2) cookie header line en el mensaje HTTP

requerimiento

Ejemplo:

Susan siempre accesa

Internet desde su PC

Visita un sitio específico

de e-commerce por

primera vez

(13)

Cookies: manteniendo el “state” (cont.)

cliente

_servidor

usual http response msg

cookie file

Una semana despues:

usual http request msg

cookie: 1678

cookie-specific action

acceso

ebay 8734

usual http request msg _{Amazon server}

creates ID 1678 for usercrea

la entrada usual http response

Set-cookie: 1678 ebay 8734

amazon 1678

usual http request msg

cookie: 1678

cookie-spectific action

acceso

ebay 8734 amazon 1678

backend database

Cookies (continuación)

Que pueden llevar los cookies: Autorización

shopping carts Recomendaciones Estado de la sesión del

usuario (Web e-mail)

Cookies y la privacidad: cookies permiten que los

sitios aprendan bastante acerca de uno

Usted debe proporcionar su nombe 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

transacciones

cookies: Mensaje http lleva state

Web caches (proxy server)

El usuario debe

configurar su browser:

Acceso al web via

cache

El browser envia todos

los requerimientos

HTTP al cache

El objeto en la cache:

El cache retorna el objecto

Si no el cache solicita el

objeto al servidor

Objetivo:Satisfacer el requerimento del cliente sin involucrar al servidor original

client

Proxy server

client HTTP req

uest

HTTP respon

se

HTTP r_equest

HTTP re quest

origin server origin server

HTTP r

(14)

Más acerca de Web caching

cache actua como

ambos cliente y

servidor

Tipicamente el cache

es instalado por el ISP

(university, company,

residential ISP)

Por que Web caching? Reduce los tiempos de

respuesta para los requerimientos cliente Reduce el tráfico en el

enlace de acceso de una institución.

Cuando el Internet esta denso con los caches: habilita un contenido“poor” para entregar

efectivamente contenido (tambien para la comparticion de archivos P2P )

Ejemplos de Caching

Asunciones

average object size = 100,000 bits

avg. request rate from institution’s browsers to origin servers = 15/sec

delay desde el router institucional hacia algun servidor origen y de regreso al router = 2 sec

Consecuencias

Utilización de la LAN = 15% Utilización del enlace de acceso =

100%

total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds

origin servers public

Internet

institutional

network _{10 Mbps LAN} 1.5 Mbps access link

institutional cache

Ejemplo de Caching (cont)

Solución posible

Incrementar el ancho de banda del enlace de acceso, 10 Mbps

consecuencias

Utilización de la LAN = 15% Utilización del enlace de acceso =

15%

Total delay = Internet delay +

Internet

institutional network

(15)

Ejemplo de Caching (cont)

Posibles soluciones: instalar un cache

Supongamos un hit rate de 0.4

Consecuencia

40% de los requerimientos son satisfechos casi

inmediatamente

60% de los requerimientos son satisfechos por el origin server La 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

Internet

institutional

network _{10 Mbps LAN} 1.5 Mbps access link

institutional cache

GET Condicional

Objetivo:no envie el obeto si el cache tiene una version actualizada cacheada cache: especifica la fecha en

que la copia fue cacheada en el requerimiento HTTP

If-modified-since: <date>

servidor: respuesta no contiene objetos si la copia cacheada esta actualizada:

HTTP/1.0 304 Not Modified

cache

servidor

HTTP request msg

HTTP response

HTTP/1.0 304 Not Modified

objeto no modificado

HTTP request msg

HTTP response

HTTP/1.0 200 OK

<data>

objeto modificado

Chapter 2: Application layer

2.1 Principles of

network applications

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

(16)

FTP: Protocolo de transferencia de

archivo

Transferencia de archivo hacia/desde host remoto Modelo cliente/servidor

cliente:Lado que inicia la transferencia (ya sea

hacia/desde el remoto)

servidor:host remoto

ftp: RFC 959 ftp server: puerto 21

file transfer _FTP

server FTP

user interface

FTP client

local file system

remote file system Usuario

en el host

FTP: separado control, y conexiones de

datos

FTP cliente contacta al FTP server por el puerto 21, TCP es el protocolo de transporte El cliente es autorizado sobre

la conexión de control EL cliente mira el directorio

remoto 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 cliente

Después de la transferencia de un archivo, el servidor cierra la conexión de datos.

FTP

cliente servidorFTP

TCP control connection puerto 21

TCP data connection puerto 20

El servidor abre otra conexión TCP de datos para transferir otro archivo. La conexión de control: “out

of band”

El servidor FTP mantiene “state”: el directorio corriente, y la autenticación previa

FTP Comandos, respuestas

Ejemplo de comandos:

Envío de un texto ASCII sobre el canal de control USER username

PASS password

LISTretorna la lista de los

archivos en el directorio corriente

Ejemplo de codigos de

retorno

Código de estado y frases (como HTTP)

331 Username OK, password required

(17)

Chapter 2: Application layer

2.1 Principles of

network applications

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

2.6 P2P applications

2.7 Socket programming

with TCP

2.8 Socket programming

with UDP

Correo Electrónico

Tres principales

componentes:

Agentes de usuario Servidores mail simple mail transfer

protocol: SMTP Agente de usuario

alias. “mail reader” redactar, editar, leer mensajes

de correo

e.g., Eudora, Outlook, elm, Mozilla Thunderbird Los mensajes de entrada y

salida son guardados en el servidor user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent

SMTP

Correo Electrónico: mail servers

Mail Servers

Buzón (mailbox)Contiene los mensajes entrantes del usuario

message queuede los mensajes de correo saliente (a ser enviados)

SMTP protocolentre los mail servers para enviar los mensajes de correo

cliente: enviando mail

server

“servidor”: recibiendo

(18)

Correo Electrónico: SMTP

[RFC

2821]

Usa TCP para una transferencia fiable de los mensajes de correo desde el cliente al servidor, puerto 25 Transferencia directa: enviando desde el servidor y

recibiendo por el servidor Tres fases para la transferencia

handshaking (saludo) Transferencia del mensaje cierre

Interacción comando/respuesta

comandos:ASCII text

respuesta:código de estado y frase

Mensaje debe ser en ASCII 7 bit

Escenario: Alicia envía un mensaje a

Bob

1) Alicia usa agente de usuario para redactar un mensaje para

bob@someschool.edu 2) El agente de usuario de

Alicia envía el mensaje a su mail server; mensaje es puesto 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.

user agent

mail server

mail

server user

agent 1

2 ₃

4 ₅ 6

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: <alice@crepes.fr>

S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu>

S: 250 bob@hamburger.edu ... Recipient ok C: DATA

(19)

SMTP: palabras finales

SMTP usa conexiones persistentes

SMTP requiere mensajes (header & body) tienen que ser en ASCII 7 bit El servidor SMTP usa

CRLF.CRLFpara determinar el final del mensaje

Comparasión con HTTP:

HTTP: jala (pull) SMTP: empuja (push) Ambos tienen interacción

de comandos/repuestas ASCII, codigos de estao HTTP: cada objeto está

encapsulado en su propio mensaje de respuesta SMTP: Multiples objetos

son enviados en mensajes de multiples partes

Formato del mensaje de correo

SMTP: Protocolo para el intercambio de mensajes de correo

RFC 822: estandard para el formato del mensaje de texto:

Encabezado (header lines), e.g.,

To: From: Subject: differentfrom SMTP

commands!

Cuerpo (body)

El “mensaje”, caractares

ASCII unicamente

header

body

blank line

Formato mensaje: extensiones multimedia

MIME: Extensión de correo multimedia, RFC 2045, 2056 Líneas adicionales en el mensaje de cabecera especifican

el tipo de contenido MIME

From: alice@crepes.fr To: bob@hamburger.edu

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 para Codificar el dato MIME version

(20)

Protocolos de acceso de correo

SMTP: entrega/almacena hasta el servidor receptor server Protocolo 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.

user agent

sender’s mail server user

agent

SMTP

_access

protocol

receiver’s mail server

Protocolo POP3

Fase autorización

Comandos cliente:

user:declarar el

username

pass:password

Respuestas del servidor

+OK

-ERR

Fase transacción,

cliente: list:lista los números de

mensajes retr:recupera los

mensajes por número dele:borrar

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: +OKuser successfully logged on

POP3 e IMAP

Más acerca de POP3

Los ejemplos previos

usan el modo

“download and delete”

Bob no puede volver a

leer sus correos si el

cambia de cliente

“Download-and-keep”:

IMAP

Mantiene todos los mensajes en un lugar: el servidor

Perimete a los usuarios organizar los mensajes en carpetas

(21)

Chapter 2: Application layer

2.1 Principles of

network applications

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

2.6 P2P applications

DNS: Sistema de Dominio de

Nombres

Personas:algunos

identificadores: Cédula de identidad,

nombre, número de pasaporte

Internet hosts, routers: Dirección IP (32 bit) –

usado para

direccionamiento de los datagramas

“nombre”, e.g.,

ww.yahoo.com – usado por los humanos

Q:Existe algun mapeo enttre la dirección IP y el nombre?

Sistema de Dominio de

nombres:

Base de datos distribuida:

implementado en jerarquía de algunosname servers

Protocolo de la capa de

aplicación

host, routers, name servers para comunicarse necesitan

resolvernombres

(address/name translation)

nota: la función core de

Internet implementado como un protocolo de la capa de aplicación

Complejidad en las puntas

de la red

DNS

Por que no centralizar

DNS?

Unico punto de falla

Alto volumen de tráfico

Base de datos distante

centralizada

Mantenimiento

No escalable

!

Servicios DNS

Traducción de

nombres de hosts a

direcciones IP

host aliasing

Alias de nombres

Servidores de correo

aliasing

Distribución de carga

Replicación de

(22)

Root DNS Servers

com DNS servers org DNS servers edu DNS servers poly.edu DNS servers

umass.edu DNS servers yahoo.com

DNS servers

amazon.com DNS servers

pbs.org DNS servers

Base de datos distribuída y

Jerarquica

El cliente quiere la IP para www.amazon.com;

El cliente pregunta al root server para encontrar

DNS server com

El cliente pregunta al DNS server com para obtener

el amazon.com DNS server

El cliente pregunta amazon.com DNS server para

obtener la dirección IP para www.amazon.com

DNS: Root name servers

Contactado por el servidor de nombres local que no sabe como resolver el nombre

root name server:

Al menos proporciona el nombre y dirección del servidor autorizado de

la zona de más alto nivel para el dominio buscado

Existen 13 servidores raíz en toda Internet (7 no son servidores

únicos)

b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f 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, VA

c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations)

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).

(23)

Local Name Server

No pertenecen estrictamente a la jerarquia

Cada 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 dentro

de la jerarquía.

requesting host

cis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS server

dns.poly.edu

1 2

3

4

5

6

authoritative DNS server

dns.cs.umass.edu 7

8

TLD DNS server

Ejemplo de resolución de nombres

DNS

Un Host en

cis.poly.edu quiere la

dirección IP para

gaia.cs.umass.edu

Consultas iterativas:

El servidor contactado contesta con el nombre del server a ser contactado “Yo no conozco el

nombre, pero pregunte a este servidor”

requesting host

cis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS server

dns.poly.edu

1 2

4 5 6

authoritative DNS server

dns.cs.umass.edu 7

8

TLD DNS server

3

Consulta recursiva:

Pone la carga en el servidor de nombres contactado

(24)

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 tiempo

Los servidoresTLD servers son tipicamente

cacheado en los servidores locales de nombres

• De este modo el root name servers no es visitado a

menudo

actualización/notificaciones son mecanismos que

estan bajo el diseño de IETF (Internet

Engineering Task Force)

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html

Registros DNS

DNS:La base de datos distribuida guarda los registros fuente(RR)

Type=NS

namees el dominio (e.g.

foo.com)

valuees el hostname del

servidor de nombres autoritativo para este dominio

RR format:

(name, value, type, ttl)

Type=A

Name es el hostname

valuees la direcciónIP

Type=CNAME

namees el nombre alias para

alguien real

www.ibm.com es realmente servereast.backup2.ibm.com

valuees el nombre real

Type=MX

valuees el nombre del

mailserver asociado con el nombre

Protocolo y mensajes DNS

Protocolo DNS:

preguntas y respuestas ,

ambos con el

mismo

formato de mensaje

msg header

(25)

Protocolo y mensajes DNS

Nombre, campos tipo Para una pregunta RRs en respuesta a una

pregunta Registros para los servidores autoritativos Información util adicional Que puede ser usada

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 registro

A para www.networkuptopia.com; Tipee el registro

MX para networkutopia.com

Chapter 2: Application layer

2.1 Principles of

network applications

app architectures app requirements

2.2 Web and HTTP

2.4 Electronic Mail

SMTP, POP3, IMAP

2.5 DNS

(26)

Arquitectura Pura P2P

no

siempre en un server

Sistemas finales

arbitrarios se comunican

directamente

Los peers conectados

son intermitentes y

cambian de dirección IP

Tres tópicos:

Distribución de archivos Buscando Información Caso de estudio: Skype

peer-peer

Distribución de archivos:

Servidor-Cliente vs P2P

Pregunta

: Cuanto tiempo toma distribuir un

archivo desde un servidor a N peers?

us

u2 d1

d2 u1

uN dN

Server

Network (with abundant bandwidth) File, size F

us:bandwidth subida

del server

ui:bandwidth subida

del peer i

di:bandwidth de

bajada del peer i

Tiempo de distribución de archivo:

servidor-cliente

us

u2

d1 _d

2 u1

uN dN

Server

Network (with abundant bandwidth)

F

El servidor envia

secuencialmente las N

copias:

NF/u

_s

time

El cliente i le toma el

(27)

Tiempo de distribución de archivo: P2P

us

u2

d1 _d2

u1

uN dN

Server

Network (with abundant bandwidth)

F El servidor debe enviar

una copia en el tiempo : F

/u

s

El clinte i toma el tiempo

F/dien bajar NF bits deben ser

bajados (agregado)

Velocidad más rapida posible de subida :

u

s

+

Σ

u

i

d

P2P

= max

{

F/u

s

, F/min(d

i

)

_i

, NF/(u

s

+

Σ

u

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

M

inim

u

m

D

is

tr

ibut

io

n

T

im

e P2P

Client-Server

Ejemplo: Servidor-cliente vs. P2P

Distribución de archivos:

BitTorrent

tracker:

rastrear los peers

Participantes en eltorrent

torrent:

peers que intercambian

grupo de

Pedazos de un archivo

obtain list of peers

trading chunks

peer Distribución de archivos

(28)

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 tiempo

Registros 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 venir

Una vez que el peer tiene el archivo entero, el puede

(egoistamente) dejar o (desinteresado) permanecer.

BitTorrent (2)

Halando pedazos Chunks En cualquier momento, peers

diferentes tienen diferentes subcojuntos de pedazos de archivos

periódicamente, un peer (Alice) pregunta a cada vecino por una lista de los pedazos chunks que ellos tengan.

Alice envia el requerimiento para sus pedazos faltantes

Los raros primero

Enviando Chunks: tit-for-tat

Alice envía pedazos a 4

vecinos a la más alta velocidad

re-evalua los top 4 cada

10 secs

cada 30 secs: aleatoriamente

se selecciona otro peer, empieza a enviar chunks

Los peer recientemente

escogidos se unen al top 4

“optimista nunca se

obstruye”

BitTorrent: Tit-for-tat

(1) Alice “no obstruye” Bob

(29)

P2P: Buscando información

Compartición archivos (eg e-mule)

El indice dinámicamente rastrea la ubicación de los archivos que comparten los peers.

Los peers necesitan decir al indice que es lo que tienen.

Los peers buscan el indice para determinar donde los archivos pueden ser encontrados

Mensajería instántanea El indice mapea el nombre

de usuario con la ubicación. Cuando el usuario inicia la

aplicación de IM, el necesita informar el indice de su ubicación

Los Peers buscan el indice para 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)

P2P: indice centralizado

Diseño original de

“Napster”

1) Cuando el peer se

conecta, el informa a un

servidor central:

Dirección IP contenido

2) Alice pregunta por

“Hey Jude”

3) Archivo solicitado por

Alice desde BoB

centralized directory server

peers

Alice Bob 1

1 1 1 2

3

P2P: Problemas con los directorios

centralizados

Unico punto de falla Desempeño: cuellos de

botella

Incumplimiento de los derechos de copia (copyright): juicio

La transferencia de archivos es

(30)

Inundación de consultas

Totalmente distribuido

no servidor central

Usado por Gnutella

Cada peer indexa los

archivos que va tener

disponible para

compartición (no otros

archivos)

Overlay de red: grafico Borde entre el peer X y

Y , si existe una conexion TCP

Todos los peer activos y

bordes forman un formato de red

Borde: enlace virtual (

no

físico)

Un peer dado esta

tipicamente conectado con < 10 vecinos del overlay

Inundación de consultas

Query QueryHit

Query

Qu ery

QueryHit

Que ry

Q ue_ry Que ryHi

t

File transfer: HTTP

Mensaje de consulta

enviado sobre una conexion TCP existente

Los peers envian

mensajes de consulta

QueryHit

enviados sobre el Camino de reverso

Escalabilidad:

Alcanse limitado

de la inundación

Gnutella: Peer joining

1.

Uniéndose el peer Alice puede encontrar otros

peer 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;

(31)

Overlay Jerarquico

Entre indices

centralizados, enfoque de

inundación de consultas

Cada peer es ya sea un

super nodo o asignado a un

super nodo

ConexionesTCP entre peer y

su super nodo.

ConexionesTCP entre algún

par de super nodos.

El super nodo rastresa el

contenido en sus hijos

ordinary peer

group-leader peer

Chapter 2 Capa de Aplicación

Chapter 2

Capa de Aplicación

Chapter 2: Capa de Aplicación

2.1 Principios de las

aplicaciones de red

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

2.5 DNS

2.6 Aplicaciones P2P

Chapter 2: Application Layer

Objetivos:

Conceptos,

implementación y

aspectos de los

protocolos de

aplicaciones de red

transport-layer

service models

client-server

paradigm

peer-to-peer

paradigm

Aprender acerca de

los protocolos

mediante la

examinación de los

protocolos populares

de nivel de aplicación

Algunas aplicaciones de red

e-mail

web

instant messaging

remote login

P2P file sharing

multi-user network

games

streaming stored video

clips

voice over IP

real-time video

conferencing

grid computing

Creando una network app

Chapter 2: Capa de Aplicación

2.1 Principios de las

aplicaciones de red

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail

2.5 DNS

Arquitectura de Aplicaciones



Cliente-Servidor



Peer-to-peer (P2P)



Híbrido de cliente-servidor y P2P

Arquitectura Cliente-servidor

servidor:

Siempre en un host

IP address

permanente

Para escalamiento se

usan server farms

clientes:

Arquitectura pura P2P

Hybrido de cliente-servidor y P2P

Processes communicating

Procesos:

programa

corriendo en un host.

Dentro del mismo host,

dos procesos se pueden

comunicar usando

inter-process

communication

(definido

por el Sistema