El documento trata sobre la capa de aplicación en redes. Explica conceptos como las arquitecturas cliente-servidor y punto a punto, los protocolos populares como HTTP, FTP y correo electrónico, y cómo los procesos se comunican a través de sockets utilizando direcciones IP y números de puerto. También describe los requisitos de servicios de transporte para diferentes aplicaciones y los protocolos TCP y UDP.

1. 1
2: Application Layer 1
Chapter 2
Capa de Aplicación
2: Application Layer 2
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
2: Application Layer 3
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
SMTP / POP3 / IMAP
DNS

2. 2
2: Application Layer 4
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
2: Application Layer 5
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
transport
network
data link
physical
application
transport
network
data link
physical
2: Application Layer 6
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 P2P applications

3. 3
2: Application Layer 7
Arquitectura de Aplicaciones
Cliente-Servidor
Peer-to-peer (P2P)
Híbrido de cliente-servidor y P2P
2: Application Layer 8
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
2: Application Layer 9
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
peer-peer

4. 4
2: Application Layer 10
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
2: Application Layer 11
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
2: Application Layer 12
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
la puerta el cual trae el
mensaje a un socket del
proceso de recepción
process
TCP with
buffers,
variables
socket
host or
server
process
TCP with
buffers,
variables
socket
host or
server
Internet
controlled
by OS
controlled by
app developer

5. 5
2: Application Layer 13
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?
2: Application Layer 14
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
2: Application Layer 15
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
interoperabilidad
e.g., HTTP, SMTP
Protocolos propietarios:
e.g., Skype

6. 6
2: Application Layer 16
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, …
2: Application Layer 17
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
2: Application Layer 18
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
transmisor cuando la red esta
sobre cargada
No provee: temporización,
throughput mínimo
garantizado, 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. 7
2: Application Layer 19
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
2: Application Layer 20
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
2: Application Layer 21
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 HTML el
cual incluye algunos objetos referenciados.
Cada objeto esta direccionado por un URL Localizador
de recursos uniforme
Ejemplo URL:
www.someschool.edu/someDept/pic.gif
host name path name

8. 8
2: Application Layer 22
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 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 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
2: Application Layer 24
Conexiones HTTP
Nonpersistent HTTP
Cada objeto debe ser
enviado por una
conexion TCP
individual establecida.
Persistent HTTP
Objetos múltiples
pueden ser enviados
sobre una única
conexión TCP entre el
cliente y el servidor.

9. 9
2: Application Layer 25
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
puerto 80
2. El cliente HTTP enví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 HTTP en el host
www.someSchool.edu
esperando por una conexion
TCP al puerto 80. “acepta” la
conexión, notificando al
cliente
3. El servidor HTTP recibe 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)
2: Application Layer 26
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 HTTP server
cierra la conexión TCP.
tiempo
2: Application Layer 27
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
time time

10. 10
2: Application Layer 28
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
2: Application Layer 29
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
2: Application Layer 30
Mensaje de requerimiento HTTP :
formato general

11. 11
2: Application Layer 31
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
2: Application Layer 32
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
2: Application Layer 33
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
data, e.g.,
requested
HTML file

12. 12
2: Application Layer 34
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:
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.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!
2: Application Layer 36
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
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 accesa
Internet desde su PC
Visita un sitio específico
de e-commerce por
primera vez
Cuando el requerimiento
inicial HTTP llega al
sitio, el sitio crea:
Un unico ID
Una entrada para el
ID en la base de
datos backend

13. 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 msg
cookie: 1678 cookie-
specific
action
acceso
ebay 8734
usual http request msg
Amazon server
creates ID
1678 for user crea
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
2: Application Layer 38
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
2: Application Layer 39
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
original, luego retorna
el objeto al cliente
Objetivo: Satisfacer el requerimento del cliente sin involucrar al
servidor original
client
Proxy
server
client
HTTP request
HTTP response
HTTP request HTTP request
origin
server
origin
server
HTTP response HTTP response

14. 14
2: Application Layer 40
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 )
2: Application Layer 41
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
2: Application Layer 42
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 +
access delay + LAN delay
= 2 sec + msecs + msecs
Los upgrade por lo general son
costosos
origin
servers
public
Internet
institutional
network
10 Mbps LAN
10 Mbps
access link
institutional
cache

15. 15
2: Application Layer 43
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
origin
servers
public
Internet
institutional
network
10 Mbps LAN
1.5 Mbps
access link
institutional
cache
2: Application Layer 44
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
If-modified-since:
<date>
HTTP response
HTTP/1.0
304 Not Modified
objeto
no
modificado
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.0 200 OK
<data>
objeto
modificado
2: Application Layer 45
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

16. 16
2: Application Layer 46
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
2: Application Layer 47
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
FTP
servidor
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
2: Application Layer 48
FTP Comandos, respuestas
Ejemplo de comandos:
Envío de un texto ASCII
sobre el canal de control
USER username
PASS password
LIST retorna la lista de los
archivos en el directorio
corriente
RETR filename recupera
(gets) archivo
STOR filename guarda
(puts) archivo en el host
remoto
Ejemplo de codigos de
retorno
Código de estado y frases
(como HTTP)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file

17. 17
2: Application Layer 49
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
2: Application Layer 50
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
SMTP
SMTP
2: Application Layer 51
Correo Electrónico: mail servers
Mail Servers
Buzón (mailbox) Contiene los
mensajes entrantes del
usuario
message 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”: recibiendo
mail server
mail
server
user
agent
user
agent
user
agent
mail
server
user
agent
user
agent
mail
server
user
agent
SMTP
SMTP
SMTP

18. 18
2: Application Layer 52
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
2: Application Layer 53
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 3 4 5
6
2: Application Layer 54
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
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. 19
2: Application Layer 55
SMTP: palabras finales
SMTP usa conexiones
persistentes
SMTP requiere mensajes
(header & body) tienen que
ser en ASCII 7 bit
El servidor SMTP usa
CRLF.CRLF para
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
2: Application Layer 56
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:
different from SMTP
commands!
Cuerpo (body)
El “mensaje”, caractares
ASCII unicamente
header
body
blank
line
2: Application Layer 57
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
Dato codificado

20. 20
2: Application Layer 58
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 SMTP access
protocol
receiver’s mail
server
2: Application Layer 59
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: +OK user successfully logged on
2: Application Layer 60
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”:
copia los mensajes en
diferentes clientes
POP3 es stateless
através de las sesiones
IMAP
Mantiene todos los
mensajes en un lugar: el
servidor
Perimete a los usuarios
organizar los mensajes en
carpetas
IMAP mantiene el state del
usuario a través de las
sesiones:
Nombres de las carpeta y
los mapeos entre los IDs
de los mensajes y el
nombre de carpeta

21. 21
2: Application Layer 61
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: Application Layer 62
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
algunos name servers
Protocolo de la capa de
aplicación
host, routers, name servers
para comunicarse necesitan
resolver nombres
(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
2: Application Layer 63
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
servidores Web:
Conjunto de direcciones
IP para un nombre

22. 22
2: Application Layer 64
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
2: Application Layer 65
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)
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
provider
El solamente retorna respuestas a los requerimientos acerca
de dominios de nombres que están instalados en su sistema
de configuración

23. 23
2: Application Layer 67
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.
2: Application Layer 68
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”
2: Application Layer 69
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
45
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS server
3Consulta recursiva:
Pone la carga en el
servidor de nombres
contactado
Ejemplo de resolución de
nombreDNS

24. 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 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
2: Application Layer 71
Registros DNS
DNS: La base de datos distribuida guarda los registros fuente (RR)
Type=NS
name es el dominio (e.g.
foo.com)
value es el hostname del
servidor de nombres
autoritativo para este
dominio
RR format: (name, value, type, ttl)
Type=A
Name es el
hostname
value es la direcciónIP
Type=CNAME
name es el nombre alias para
alguien real
www.ibm.com es realmente
servereast.backup2.ibm.com
value es el nombre real
Type=MX
value es el nombre del
mailserver asociado con el
nombre
2: Application Layer 72
Protocolo y mensajes DNS
Protocolo DNS: preguntas y respuestas , ambos con el
mismo formato de mensaje
msg header
identificacion: 16 bit #
para preguntas, para las
respuesta se usa el
mismo #
Flags (banderas):
Pregunta o respuesta
Recursion deseada
Recursion disponible
Respuesta es
autoritativa

25. 25
2: Application Layer 73
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
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 registro
A para www.networkuptopia.com; Tipee el registro
MX para networkutopia.com
2: Application Layer 75
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

26. 26
2: Application Layer 76
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
2: Application Layer 77
Distribución de archivos: Servidor-
Cliente vs P2P
Pregunta : Cuanto tiempo toma distribuir un
archivo desde un servidor a N peers?
us
u2d1
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
2: Application Layer 78
Tiempo de distribución de archivo:
servidor-cliente
us
u2d1 d2
u1
uN
dN
Server
Network (with
abundant bandwidth)
F
El servidor envia
secuencialmente las N
copias:
NF/us time
El cliente i le toma el
tiempo F/di para
bajar
Incremento linear en N
= dcs = max { NF/us, F/min(di) }
i
Tiempo para distribuir F
a N clientes usando
el enfoque cliente/servidor

27. 27
2: Application Layer 79
Tiempo de distribución de archivo: P2P
us
u2d1 d2
u1
uN
dN
Server
Network (with
abundant bandwidth)
F
El servidor debe enviar
una copia en el tiempo :
F/us
El clinte i toma el tiempo
F/di en bajar
NF 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
MinimumDistributionTime
P2P
Client-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 intercambian
Pedazos de un archivo
obtain list
of peers
trading
chunks
peer
Distribución de archivos
P2P

28. 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 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.
2: Application Layer 83
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”
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 encontrar
mejores partner y obtener el
archivo mas rapido

29. 29
2: Application Layer 85
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)
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 IP
contenido
2) Alice pregunta por
“Hey Jude”
3) Archivo solicitado por
Alice desde BoB
centralized
directory server
peers
Alice
Bob
1
1
1
12
3
2: Application Layer 87
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
descentralizada, pero la
forma de localizar el
contenido es altamente
centralizada

30. 30
2: Application Layer 88
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
2: Application Layer 89
Inundación de consultas
Query
QueryHit
Query
Query
QueryHit
Query
Query
QueryHit
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
2: Application Layer 90
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;
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 puede
hacer el setup de conexiones adicionales TCP

31. 31
2: Application Layer 91
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
neighoring relationships
in overlay network