Capa de Aplicacin

Este material est basado en :

Material preparado como apoyo al texto Computer
Networking: A Top Down Approach Featuring the Internet, 3rd
edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Capa de Aplicacin
Objetivos:
Aspectos
conceptuales y de
implementacin de
los protocolos de
aplicacin
Modelo de
servicio de la
capa transporte
Paradigma
cliente-servidor
Paradigma peerto-peer (par-apar)

Aprendizaje de
protocolos
examinando
protocolos de
aplicacin populares

HTTP
FTP
SMTP / POP3 / IMAP
DNS

Algunas aplicaciones de
red
E-mail
Web
Mensajera
instantnea
Login remoto
Comparticin de
archivos P2P
Juegos de red multiusuarios
Reproduccin de
clips de video
almacenados

Telefona Internet
Conferencias de
video en tiempo real
Computacin
paralela masiva.

Caractersticas de una aplicacin

de red
Son programas que
Corren en diferentes
sistemas terminales.
Se comunican por la red.
Ejemplo: Programa de
servidor web que se
comunica con el programa
del navegador web

No se necesita escribir
software para los
dispositivos intermedios
de red
Los dispositivos
intermedios no ejecutan
aplicaciones de usuario
Las aplicaciones en
sistemas terminales

network
data link
physical

Principios de las
aplicaciones de red

Arquitecturas de
Aplicacin
Las aplicaciones de red pueden
utilizar una de las siguientes
arquitecturas:
Cliente-servidor
Peer-to-peer (P2P)
Hbridos de cliente-servidor y P2P

Arquitectura Clienteservidor
Servidor:
Computador siempre
encendido
Direccin IP
permanente
Granja de servidores
por escalamiento

Cliente:
Se comunica con
servidor
Puede ser conectado
intermitentemente
Puede tener
direcciones IP
dinmicas
No se comunican
directamente entre s
(dos clientes puros)

ARQUITECTURA CLIENTESERVIDOR
Servidor iterativo
no orientado a la
conexin:

Procesa una peticin a

la vez.
Los datagramas se
almacenan en una
cola a la espera de ser
atendidos en orden de
llegada
El servidor utiliza un
nico puerto
Utilizan UDP como
protocolo.

ARQUITECTURA CLIENTESERVIDOR
Servidor concurrente
orientado a la
conexin

Puede atender a
mltiples clientes a la
vez
Se establece una
conexin entre el
servidor y cada cliente y
esta permanece activa
hasta que el flujo
completo es procesado
y se cierra la conexin.
Utiliza un puerto bien
conocido y crea puertos

Arquitectura P2P Pura

Servidor no siempre
encendido
Sistemas terminales
arbitrarios se
comunican
directamente
Pares se conectan
intermitentemente y
cambian sus
direcciones IP
Ejemplo: BitTorrent
Altamente escalable,
pero difcil de
administrar

Hbridos de cliente-servidor y
P2P
Skype
Aplicacin P2P de Voz sobre IP
Servidor centralizado: bsqueda de direcciones de
partes remotas
Conexin cliente cliente: directa (no a travs del
servidor)

Mensajera Instantnea
Dilogo entre dos usuarios es P2P
Servicio centralizado: Deteccin/localizacin de
presencia de cliente:
Usuario registra su direccin IP en un servidor central
cuando ingresa al sistema
Usuarios contactan servidor central para encontrar las
direcciones IP de sus amigos.

Procesos que se
comunican
Proceso Cliente:
Proceso: programa que
corre en un host.
Dentro de la mquina
dos procesos se
comunican usando
comunicacin entre
proceso (definida por
OS).
Procesos en diferentes
hosts se comunican
va intercambio de
mensajes

proceso que inicia la

comunicacin

Proceso Servidor:
proceso que espera
por ser contactado

Nota: las aplicaciones con

arquitectura P2P tienen
procesos clientes y
procesos servidores

Sockets
Los procesos envan y reciben mensajes a
travs de sus socket

Sockets
Los socket son anlogos a puertas
Proceso transmisor saca mensajes por la puerta
Proceso transmisor confa en la infraestructura de
transporte al otro lado de la puerta la cual lleva los
mensajes al socket en el proceso receptor

DIRECCIONAMIENTO DE PROCESOS
Para que un proceso reciba un mensaje, ste
debe tener un identificar
Un host tiene una direccin IP nica de 32 bits.
El identificador incluye la direccin IP y un nmero
de puerto asociado con el proceso en el host.
Ejemplo de nmeros de puertos:
Servidor HTTP: 80
Servidor de Mail: 25

Para enviar un mensaje HTTP al servidor

www.concytec.gob.pe
Direccin IP: 190.12.64.4
Nmero de puerto: 80

LOS PROTOCOLOS DE CAPA DE APLICACIN

DEFINEN
Tipos de mensajes
intercambiados
e.g., mensajes de requerimiento
y respuesta

Sintaxis de los tipos de

mensajes:
Qu campos en los mensajes y
cmo stos son delineados.

Semntica de los campos

Significado de la informacin en
los campos

Reglas sobre cundo y

cmo los procesos envan y
responden a mensajes

Protocolos de dominio
pblico:
Definidos en RFCs
Permite
interoperabilidad
Eg: HTTP, SMTP
Protocolos propietarios:
Eg: KaZaA, Skype

SERVICIOS DE TRANSPORTE REQUERIDOS POR UNA

APLICACIN
Prdida de Datos
Algunas aplicaciones (e.g.,
audio) pueden tolerar
prdida
otras (e.g., transferencia de
archivos, telnet) requieren
transferencia 100% confiable

Retardo
Algunas Aplicaciones (e.g.,
Telefona Internet, juegos
interactivos) requieren bajo
retardo para ser efectivas

Ancho de banda
Algunas aplicaciones (por
ejemplo, multimedia)
requieren una cantidad
mnima de ancho de
banda para ser
efectivas
Otras (aplicaciones
elsticas) hacen uso del
ancho de banda que
obtengan

REQUERIMIENTOS DE SERVICIO DE
TRANSPORTE DE APLICACIONES COMUNES
Aplicacin
Transferencia
de archivos
e-mail
Documentos
Web
audio/video en
tiempo real
audio/video
lmacenado
Juegos
interactivos
Mensajera
instantnea

Soporta
Prdidas

Ancho de
banda

Sensible a
retardo

no

Elastico

No

no

elastico

no

no

elastico

no

tolerante

audio: 5Kbps-1Mbps
video: 10Kbps-5Mbps

si, 100s msec

tolerante

Igual al de arriba

si, pocos secs

Tolerante

Pocos Kbps a mas

si, 100s msec

no

elstico

Si y no

SERVICIOS DE LOS PROTOCOLOS DE

TRANSPORTE EN INTERNET
Servicio UDP:

Transferencia de datos no confiable entre proceso Tx y Rx.

No provee: acuerdo entre los procesos, confiabilidad,
control de flujo, control de congestin, garantas de
retardo o ancho de banda

SERVICIOS DE LOS PROTOCOLOS DE TRANSPORTE

EN INTERNET
Servicio TCP:

Orientado a la conexin acuerdo requerido entre procesos cliente y

servidor antes de transferencia
Transporte confiable entre proceso Tx y Rx
Control de flujo: Tx no sobrecargar al Rx
Control de congestin: frena al Tx cuando la red est sobrecargada
No provee: garantas de retardo ni ancho de banda mnimos

Aplicaciones Internet: aplicacin, protocolo de

transporte
Aplicacin
e-mail
remote terminal access
Web
file transfer
Streaming
multimedia
Internet
telephony

Protocolo capa
Aplicacin
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (youtube),
RTP, propietario
SIP, RTP, propietario
(e.g.,Skype)

Protocolo de
transporte que lo
sustenta
TCP
TCP
TCP
TCP
TCP or UDP
Tipicamente UDP

Web y HTTP

World Wide Web y HTTP

Propuesta por Tim Berners-Lee en 1989.

Revolucion la forma de usar Internet.

Consiste de documentos almacenados en servidores que

pueden ser accedidos desde equipos clientes.

Estos documentos se escriben utilizando HTML (Hyper Text

Markup Language) que es un lenguaje de etiquetas

Los documentos web pueden contener referencias a otros

documentos u objetos, tanto en el propio servidor como en
otros. Tales referencias se denominan hiperenlaces.

La ubicacin de un objeto web se define por su URL que se

especifica utilizando el formato:

protocolo://host/ruta

protocolo://host:puerto/ruta

World Wide Web y HTTP

Los documentos web pueden ser:

Estticos

Documentos de contenido fijo que no se modifica y

que solo puede ser recuperado por el cliente.

Se redactan en HTML, XML, XSL, XHTML

Dinmicos

Documentos de contenido dinmico que se crean a

peticin del cliente.

Se construyen utilizando CGI, JSP, ASP

Activos

Programa o script que se ejecuta en el cliente

Se construye utilizando Java Applets, Javascript.

World Wide Web y HTTP

Una pgina Web est

compuesta de objetos

Objetos pueden ser

archivos HTML, imgenes,
applets, archivos de audio,
vdeo, etc.

Las pginas Web consisten

generalmente de un
archivo HTML base que
incluye referencias a
objetos.

Cada objeto es
direccionable por un
Ejemplo URL: www.uandina.edu.pe/dais/index.html
Universal Resource
Nombre de camino
Locator (URL) Nombre de la mquina

(path name)

HTTP Generalidades

HTTP: HyperText Transfer

Protocol
Protocolo de la capa
aplicacin de la Web
Modelo cliente/servidor

cliente: browser que

solicita, recibe, y
despliega objetos Web
servidor: Servidor Web
enva objetos en
respuesta a
requerimientos

HTTP 1.0: RFC 1945 (1996)

HT
TP
req
ues
HT
TP
t
res
pon
se

PC ejecutando
Explorer

st
e
u
eq
r
se
P
n
T
o
p
HT
es
r
TP
T
H

Mac ejecutando
Navigator

Servidor
ejecutando
Apache Web
server

HTTP generalidades
Usa TCP:
Cliente inicia conexin TCP
(crea socket) al servidor,
puerto 80
Servidor acepta conexin
TCP del cliente
Mensajes HTTP (mensajes
del protocolo de capa
aplicacin) son
intercambiados entre
browser (cliente HTTP) y
servidor Web (servidor
HTTP)
Se cierra la conexin TCP

HTTP no tiene estado

El servidor no mantiene
informacin sobre los
requerimientos del
cliente
Protocolos que mantienen
estado son complejos!
Historia pasada (estado)
debe ser mantenida
Si servidor o cliente se
cae, las vistas del estado
pueden ser
inconsistentes, deben
ser sincronizadas

HTTP Generalidades: Arquitectura del

Browser
El controlador recibe una entrada desde el teclado

o el mouse y utiliza los programas del cliente para

acceder al documento.
Una vez accedido al documento, el controlador

utiliza uno de los interpretes para mostrar el

documento en pantalla

Conexiones HTTP
HTTP Nopersistente

A lo ms un objeto es
enviado por una
conexin TCP.

Es como hacer una

llamada por objeto.

HTTP/1.0 utiliza HTTP

no-persistente

HTTP Persistente

Mltiples objetos pueden

ser enviados por una
nica conexin TCP entre
el cliente y servidor.

HTTP/1.1 usa conexiones

persistentes en su modo
por defecto

HTTP no-persistente
Supongamos que el usuario ingresa URL
www.someSchool.edu/someDepartment/home/
index

(contiene texto y
referencia a 10
imgenes jpeg )

HTTP no persistente: tiempo de

Respuesta
Definicin de RTT(round-trip
time): tiempo ocupado en
enviar un paquete pequeo
desde el cliente al servidor y Iniciar conexin
su regreso.
TCP
RTT

Tiempo de respuesta:

Un RTT para iniciar la

conexin TCP
Un RTT por requerimiento
HTTP y primeros bytes de la
respuesta
Tiempo de transmisin del
archivo

total = 2RTT + tiempo de

transmisin

solicitar
archivo

Tiempo
para
transmi
tir
archivo

RTT
archivo
recibido
tiempo

tiempo

HTTP no persistente

En caso de tener que recuperar mltiples objetos, la

penalidad puede ser alta

HTTP Persistente
Problemas de HTTP nopersistente:
Requiere 2 RTTs por objeto
El navegador abre
conexiones paralelas
generalmente para traer
objetos referenciados. =>
el OS debe trabajar y
dedicar recursos para
cada conexin TCP
HTTP Persistente
Servidor deja las
conexiones abiertas
despus de enviar la
respuesta
Mensajes HTTP
subsecuentes entre los
mismos cliente/servidor

Persistencia sin pipelining:

Cliente enva nuevo
requerimiento slo
cuando el previo ha sido
recibido
Un RTT por cada objeto
referenciado
Persistencia con pipelining:
Por defecto en HTTP/1.1
Cliente enva
requerimientos tan
pronto ste encuentra un
objeto referenciado
Tan poco como un RTT
para todas las
referencias

HTTP Persistente

Mas eficiente, pues permite la transferencia de mltiples objetos a

travs de una sola conexin

Mensaje HTTP de requerimiento

Dos tipos de mensajes HTTP: requerimiento, respuesta

Mensaje de requerimiento HTTP:

ASCII (es decir, formato legible)

nea de requerimiento
request line) (comandos
GET, POST, HEAD)GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Lneas de
Accept-language:fr
encabezado
(carriage return, line feed extra)
Carriage return,
line feed
Indica fin de mensaje

Mensaje HTTP de requerimiento: formato

general

Subiendo input de formulario

Mtodo POST:

Pginas Web
usualmente incluyen
entradas de
formularios
Los datos son subidos
al servidor en el
cuerpo del mensaje

Mtodos URL:

Usa mtodo GET

Entrada es subida en
campos URL de la lnea
de requerimiento:

www.somesite.com/animalsearch?monkeys&banana

Tipos de Mtodos
HTTP/1.0

HTTP/1.1

GET

GET, POST, HEAD

POST

HEAD: Pide al servidor que

deje el objeto requerido
afuera de la respuesta.
Respuesta incluye slo el
encabezado.

PUT: Sube archivos en

cuerpo del requerimiento en
localizacin indicada por el
campo URL

DELETE: Borra archivo

especificado en el campo
ACCION
URL

METODO
GET
Solicitar un documento del servidor
Solicitar informacin sobre un documento pero no el propio
HEAD
documento
PUT
Enva un documento del cliente al servidor
POST
Envia alguna informacin del cliente al servidor
TRACE
Repite y devuelve la solicitud entrante
DELETE
Elimina un objeto web
CONNECT Reservado
OPTIONS Consulta sobre opciones disponibles

Nombres de Headers de
peticin
HEADER
User-agent
Accept
Acceptcharset
Acceptencoding
Acceptlanguage
Authorization
Host
Date
Upgrade
Cookie
If-ModifiedSince

DESCRIPCION
Identifica al programa cliente
Muestra el formato del medio que el cliente puede
aceptar
Muestra el juego de caracteres que el cliente puede
manejar
Muestra el esquema de codificacin que el icliente
puede manejar
Muestra el lenguaje que el cliente puede aceptar
Muestra los permisos que tiene el cliente
Muestra el nmero de puerto y host del cliente
Muestra la fecha actual
Especifica el protocolo de comunicacin preferido
Devuelve el cookie al servidor
Si el archivo se modific desde una fecha especfica

Mensajes HTTP de respuesta

Lnea de estados
(cdigo de estado
del protocolo
Frase de estado)

HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Lneas de Server: Apache/1.3.0 (Unix)
encabezado Last-Modified: Mon, 22 Jun 1998 ...
Content-Length: 6821
Content-Type: text/html

data, e.g.,
archivo
HTML solicitado

data data data data data ...

Mensajes HTTP de respuesta:

formato general

Nombres de Headers de
respuesta
HEADER
Date
Upgrade
Server
Set-Cookie
ContentEncoding
ContentLanguage
Content-Length
Content-Type
Location

DESCRIPCION
Muestra la fecha actual
Especifica el protocolo de comunicacin
preferido
Brinda informacin sobre el servidor
El servidor solicita al cliente guardar una
cookie
Especifica el esquema de codificacin
Especifica el lenguaje
Muestra la longitud del documento
Especifica el tipo de medio
Para pedir al cliente que enve la peticin a
otro sitio

Cdigos HTTP de respuesta

Son devueltos en primera lnea de respuesta del servidor al
cliente.
Algunos cdigos de muestra:

200 OK

solicitud exitosa, objeto requerido es incluido luego en

mensaje
301 Moved Permanently

Se movi el objeto requerido, nueva ubicacin es

especificada luego en el mensaje (Location:)
400 Bad Request

Requerimiento no entendido por el servidor

404 Not Found

Documento no encontrado en servidor

505 HTTP Version Not Supported

Probando HTTP (lado cliente)

1. Telnet a nuestro servidor favorito:

Telnet abre una conexin TCP

telnet qenqo.uandina.edu.pe 80
al puerto 80 (puerto servidor
HTTP por omisin) en
Obs: www es un alias para qenqo
qenqo.uandina.edu.pe
Cualquier cosa ingresada es
enviada al puerto 80 de
2. Escribir un requerimiento GET HTTP:
qenqo
GET /index.html HTTP/1.1
Host: qenqo.uandina.edu.pe
NOTA: Campo Host: obligatorio
En encabezado, requerido por
proxy

Tecleando esto, enviamos un

requerimiento GET mnimo
(pero completo) al servidor
HTTP

3. Observar el mensaje de respuesta enviado por el servidor HTTP

Probando HTTP

Interaccin usuario-servidor:
cookies
Muchos sitios Web importantes usan cookies
Las cookies fueron implementadas para permitir
personalizar la informacin Web.
Cookie es informacin generada por un servidor
web y almacenada en el computador del usuario
para acceso futuro.
Las cookies son trasportadas entre el
computador del usuario y el servidor.
Por ejemplo, cookies son usadas para almacenar
tems en un carro de compra mientras se recorre
un mall virtual.

Estado usuario-servidor: cookies

Cuatro Componentes:
1) Lnea encabezado cookie
en el mensaje respuesta
HTTP
2) Lnea de encabezado
cookie en requerimiento
HTTP
3) Archivo cookie es
almacenado en la mquina
del usuario y administrada
por su navegador.
4) Base de datos en sitio
Web

Ejemplo:

Susan accede a
Internet siempre desde
el mismo PC
Ella visita un sitio de ecommerce especfico
por primera vez.
Cuando el
requerimiento HTTP
inicial llega al sitio,
ste crea un ID nico y
crea una entrada en la
base de datos para ese
ID.

Cookies: conservando el estado

(cont.)
cliente

ebay: 8734
Cookie file
amazon: 1678
ebay: 8734

Requerimiento http
Respuesta http +

Set-cookie: 1678
requerimiento http

cookie: 1678
respuesta http usual

En
Servidor creaba tra
se da
ID 1678
de en
da
para usuario
to
s

Accin
especfica
de la cookie

Un semana despus:
Cookie file
amazon: 1678
ebay: 8734

requerimiento http

cookie: 1678
respuesta http usual

Accin
especfica
de la cookie

eso
c
c
a
ac
ce
so

Cookie file

servidor

Cookies: conservando el estado

(cont.)
Ejemplo del
uso de cookies
para almacenar
los datos
necesarios de
un usuario,
para realizar
una
transaccin
comercial a
travs de
Internet

Cookies (cont.)
Qu pueden transportar las
cookies:

Al margen
Cookies y privacidad:

Autorizacin

Carrito de compras

Sugerencias

Estado de la sesin del

usuario (Web e-mail)

Cookies permiten que el

sitio aprenda mucho
sobre uno.
Podramos proveer
nombre y correo al sitio.
Motores de bsqueda
usan redirecciones y
cookies para aprender
an ms
Compaas de avisos
obtienen informacin de
los sitios WEB

Web caches (tambin servidores

proxy)

Objetivo: satisfacer el requerimiento del cliente sin involucrar

al servidor destino.

Usuario configura el
browser: Acceso Web
va cache
Browser enva todos
los requerimientos
HTTP al cache
Si objeto est en
cache: cache
retorna objeto
Si no, cache
requiere los objetos
desde el servidor
Web, y retorna el
objeto al cliente

Caches v/s proxy

La idea del cache es almacenar localmente datos ya
solicitados y as poder acceder a los mismos datos ms
rpidamente en el futuro.
Un problema que debe atender el cache es la
obsolescencia que puede tener los datos locales.
El cache puede usar tiempos de expiracin, o
consultar a la fuente por vigencia del dato local.
Un proxy es un servicio que consiste en realizar una
solicitud a pedido de otro.
Les ha pasado que para algunas cosas ustedes desean
enviar a otro a hacer el trabajo por ustedes?
Por ejemplo podemos usar proxy para acceder a
servicios externos de una intranet, para que desde fuera
no se sepa que computadores hay dentro. El origen es
siempre el mismo.

Ms sobre Web caching

Cache actan

como clientes y
servidores
Tpicamente el

cache est
instalado por ISP
(universidad,
compaa ISP
residencial)

Por qu Web caching?

Reduce tiempo de

respuesta de las
peticiones del cliente.
Reduce trfico en el

enlace de acceso al
ISP.
Internet densa con

caches permite a
proveedores de
contenido pobres (no
$$) entregar contenido

Ejemplo de Cache
Suposiciones

Tamao promedio de objetos: 1Mb

Tasa de requerimientos promedio desde browsers de la

institucin al servidor WEB: 15 por segundo

Retardo desde el enrutador institucional a cualquier

servidor web y su retorno: 2s (retardo de Internet)
Consecuencias

Utilizacin de la LAN:
(15 peticiones/s)*(1Mb/peticin)/100Mbps = 0.15 (15%)

Utilizacin del enlace de acceso(enrutador de Internet

enrutador institucional):
(15 peticiones/s)*(1Mb/peticin)/15Mbps = 1 (100%)

Ejemplo de Cache
Posible solucin
Aumentar ancho de banda del
enlace a, por ejemplo, 100
Mbps
Consecuencias
Utilizacin de la LAN = 15%
Utilizacin del enlace de
acceso = 15%
Retardo Total = Retardo
Internet + retardo de acceso
+ retardo LAN
= 2 sec + msecs + msecs
A menudo un upgrade caro.

Internet
pblica

Servidor
es
web

100 Mbps
Enlace se acceso
Red
institucional

10 Mbps LAN

Sin cache
institucional

Ejemplo de cache (cont)

Instalar un web Cache
Supongamos tasa de xito (acierto) de
0.4
Consecuencias
40% de los requerimientos sern
satisfechos en forma casi inmediata por
el servidor cache (~10 ms)
60% de los requerimientos satisfechos
por los servidores WEB de origen
Utilizacin del enlace de acceso es
reducido al 60%, resultando en retardo
despreciable (digamos 10 ms)
Retardo total = Retardo Internet +
retardo acceso + retardo LAN
= solucin
0.6*(2.01)
+ 0.4*0.01
< 1.3
Esta
es sms
econmica
quesla alternativa previa
y garantiza menor retardo

Get Condicional

Objetivo: no enviar
objetos si el cache
tiene la versin
actualizada
Cache: especifica la
fecha de la copia en el
requerimiento HTTP
If-modified-since:
<date>

Servidor: responde sin

el objeto si la copia de
la cache es la ltima. :
HTTP/1.0 304 Not
Modified

servidor

cache
HTTP request msg
If-modified-since:
<date>

HTTP response

objeto
no
modificado

HTTP/1.0
304 Not Modified

HTTP request msg

If-modified-since:
<date>

HTTP response
HTTP/1.0 200 OK

<data>

objeto
modificado

FTP
File Transfer Protocol

FTP: El protocolo de transferencia de

archivos

Transferencia de archivos con servidor remoto.

Sigue modelo cliente/servidor

Cliente: Sitio que inicia la sesin

Servidor: Host remoto

Definido en el RFC 959

FTP: La capa de aplicacin se apoya en las

inferiores.

FTP: Ejemplo de sesin

FTP: Conexiones separadas de

control y datos

Cliente FTP contacta

servidor FTP en puerto 21,
especificando TCP como
protocolo de transporte
El cliente obtiene
autorizacin sobre el control
de la conexin
El cliente explora el
directorio remoto enviando
comandos sobre la conexin
de control.
Cuando el servidor recibe
una peticin de
transferencia de archivo, el
servidor abre una conexin
de datos hacia el cliente.
ste es Modo Activo.
Despus de la transferencia

TCP conexin de control

puerto 21 en servidor

Cliente
FTP

TCP conexin de datos

puerto 20 en servidor

Servidor
FTP

El servidor abre una segunda

conexin TCP de datos para
transferir otro archivo.
Conexin de control: out of
band (fuera de banda)
Servidor FTP mantiene
estado: directorio actual,
cuenta de usuario conectado.
Existe modo activo y pasivo

FTP - Modelo

FTP: Modo Activo

FTP: Modo Pasivo

FTP comandos y respuestas

Muestra de comandos:

Algunos cdigos retornados

Son enviados como texto ASCII

va el canal de control

Cdigos de estado y frases:

USER username
PASS password
LIST Retorna la lista de

archivos del
directorio
actual
RETR archivo baja un archivo
STOR archivo almacena un
archivo
en el host
remoto

331 Username OK,

password
required
125 Data connection
already open; transfer
starting
425 Cant open data
connection
452 Error writing file

Correo Electrnico:
SMTP, POP3 e IMAP

Correo Electrnico
Tres mayores componentes:
Agente usuario o cliente de
correo
Servidor de correo
Simple Mail Transfer
Protocol: SMTP
Agente Usuario
Tambin conocido como
lector de correo
Escritura, edicin, lectura
de mensajes de correos
e.g., Eudora, Outlook, elm,
Mozilla Thunderbird
Mensajes de salida y
entrada son almacenados
en servidor

user
agent
mail
server

user
agent

SMTP
SMTP

mail
server

user
agent

SMTP
user
agent

mail
server
user
agent
user
agent

Cola de
mensajes de
salida
Casilla
usuario

Correo Electrnico: Servidor de

correo
Servidor de Correo
Casilla contiene

mensajes de
entrada para el
usuario

Cola de mensajes

de los correos de
salida

Correo Electrnico: SMTP [RFC

2821]

Usa TCP para transferir confiablemente mensajes e-mail

desde el cliente al servidor, puerto 25 en servidor.
Transferencia directa: servidor enva correos al servidor
receptor
Tres fases de la transferencia
Handshaking
Transferencia de mensajes
Cierre
Interaccin comandos/respuestas
comandos: Texto ASCII
respuesta: cdigo de estatus y frase.
Los mensajes deben ser enviados en ASCII de 7-bits
Qu pasa con las fotografas y archivos binarios?

Escenario: Alicia enva mensaje a

Bob
1) Alicia usa agente usuario
para componer el mensaje
para bob@someschool.edu

4) El cliente SMTP enva el

mensaje de Alicia por la
conexin TCP

2) El agente de Alicia enva

en mensaje a su servidor
de correo; el mensaje es
puesto en cola de salida

5) El servidor de correo de
Bob pone el mensaje en
su casilla

3) Lado cliente de SMTP abre

una conexin TCP con el
servidor de correo de Bob

6) Bob invoca su agente

usuario para leer el
mensaje

Ejemplo de Interaccin SMTP

Luego de: $telnet hamburger.edu 25 <enter>
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

Prueben la interaccin SMTP :

telnet servername 25
Ver respuesta 220 desde el servidor
Ingresar los comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT
Lo de arriba nos permite enviar correo sin usar el
cliente de correo.
/* Equivalentemente, si usted sabe cmo escribir
una aplicacin que maneje sockets, usted sabe
cmo enviar e-mail desde su aplicacin.*/
Hoy muchos servidores estn configurados para
aceptar slo conexiones seguras que no permiten el
uso de telnet para envo de correo. La USM usa TLS
(Transport Layer Security)

SMTP: palabras finales

Comparacin con HTTP:

SMTP usa conexiones

persistentes

SMTP requiere que el

mensaje (encabezado y
cuerpo) sean en ASCII de
7-bits

Servidor SMTP usa

CRLF.CRLF para terminar
el mensaje; es decir, una
lnea con slo un punto
en ella.

HTTP: pull (saca contenido

desde servidor)

SMTP: push (pone

contenido en servidor)

Ambos tienen interaccin

comando/respuesta en
ASCII, y tienen cdigos de
estatus

HTTP: cada objeto es

encapsulado en su propio
mensaje

SMTP: mltiples objetos son

enviados en un mensaje
multiparte

Formato de mensajes de correo (comando

DATA)
SMTP: protocolo para
intercambio de mensajes
de correo
RFC 822: Estndar para el
formato de los
mensajes:
E.g. lneas de encabezado
(opcional), entre otros:
To:
From:
Subject:
diferente a los comandos
SMTP!

Cuerpo
El mensaje, slo

encabezado
Lnea
en blanco

cuerpo

Formato de mensaje: extensiones

multimedia

MIME: multimedia mail extension, RFC 2045, 2056

Lneas adicionales en el encabezado del mensaje declaran el
tipo de contenido MIME
La codificacin Base64 usa slo los caracteres: A-Z, a-z, 0-9 y
+/=
Versin MIME
Mtodo de
Codificacin usado

Tipo datos multimedia,

subtipo, declaracin
de parmetros
Datos binarios
codificados en base64

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

Protocolos de acceso de
correo
SMTP

SMTP

user
agent
Puerto 25

Servidor mail
de la fuente

protocolo
user
de acceso: agent
POP3 (110)
IMAP (143)
Servidor mail o HTTP
del receptor

SMTP: permite envo y almacenamiento de correo en servidor

del destinatario
Protocolo de acceso a correo: permite extraer correo desde el
servidor

POP: Post Office Protocol [RFC 1939]

autenticacin (agent <-->server) y bajada
IMAP: Internet Mail Access Protocol [RFC 1730]
Ms caractersticas (ms complejo)
Permite manipulacin de los mensajes almacenados en el
servidor
HTTP: Hotmail , Yahoo! Mail, etc.

Protocolo POP3
Fase de autorizacin

Comandos del cliente:

user: declara username
pass: password
Respuestas del servidor:
+OK
-ERR
Fase transaccional, cliente:
list: lista nmeros de
mensajes
retr: extrae mensajes por su
nmero
dele: borra
quit

S:
C:
S:
C:
S:

+OK POP3 server ready

user bob
+OK
pass hungry
+OK user successfully logged

C: list Tamao del mensaje

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

on

POP3 (ms) e IMAP

Ms sobre POP3

Ejemplo previo usa modo

bajar y borrar.
Bob no puede releer el
correo si cambia el
cliente
bajada y conserva:
obtiene copia de los
mensajes en diferentes
clientes.
POP3 no mantiene el
estado de una sesin a
otra (stateless)

IMAP

Mantiene todos los

mensajes en un lugar: el
servidor
Permite que el usuario
organice sus correos en
carpetas
IMAP mantiene el estado
del usuario de una sesin a
otra:
Nombre de carpetas
Mapeo entre Ids
(identificadores) de
mensajes y nombres de
carpetas.

DNS

DNS: Domain Name System

Personas:
muchos
identificadores:

DNI, Nro de seguro,

nombre, # pasaporte,
etc.

Host y router en
Internet:

Direccin IP (32 bit)

usada para direccionar
datagramas (ideal para
router)
nombre, e.g.,
www.yahoo.com son
usados por humanos

Domain Name System:

Base de datos distribuida

implementada en una
jerarqua de muchos
servidores de nombres
Protocolo de capa aplicacin
permite a host, routers, y
servidores de nombre
comunicarse para resolver
nombres (traduccin
direccin/nombre)
No est orientado al uso
directo de los usuarios.

DNS
Servicios DNS

Traduccin de nombre de host

a direccin IP
Alias para host
Nombre cannico o alias
Nombre cannico: CNAME
en RFC 1035
Alias para servidor de correo
Distribucin de carga
Servidores Web replicados:
conjunto de direcciones IP
para un nombre cannico
(e.g. relay1.westcoast.amazon.com),
servidor DNS rota entre
direcciones IP

Por qu no centralizar DNS?

nico punto de falla

Volumen de trfico, muchos
necesitan el DNS
Sera una base de datos
centralizada distante con grandes
retardos de acceso.
Mantenimiento: Es mejor que cada
dominio gestione sus nombres
Porque no es escalable!

Base de datos jerrquica y

distribuida

Cliente desea IP de www.amazon.com; 1ra aprox. :

Cliente consulta al servidor raz para encontrar servidor DNS de

com
Cliente consulta servidor DNS TLD (Top Level Domain) de com
para obtener servidor DNS de amazon.com
Cliente consulta servidor DNS amazon.com para obtener
direccin IP de www.amazon.com

DNS: servidores de nombre raz

Son contactados por servidor de nombre local cuando no puede

resolver un nombre
Servidor nombre raz:
Contacta servidor de nombre autorizado de la zona superior (por
ejemplo COM) si mapeo del nombre es desconocido para l
Obtiene mapeo (propio o desde otro servidor raz)
Retorna mapeo al servidor de nombre local

TLD y Servidores Autoritarios

Top-level domain (TLD) servers:responsable por com, org,

net, edu, etc., y todos los dominios superiores de cada
pas: uk, fr, ca, jp, pe, etc..
Network solutions mantiene servidores para el TLD de
com
Educause para el TLD de edu

Nic (network information center) para el TLD de pe

(www.nic.pe)

Servidores DNS autorizados: son servidores DNS de las

organizaciones y proveen mapeo autorizado entre el
nombre de host y su direccin IP.
stos pueden ser mantenidos por la organizacin o el
proveedor de servicio

Servidor de nombre local

No pertenece estrictamente a la

jerarqua

Cada ISP (ISP residencial, compaa,

universidad) tiene uno.

Tambin son llamados servidor de
nombre por omisin (default name
server)
Cuando un host hace una consulta DNS,

sta es enviada a su servidor DNS local

Ejemplo 1
Servidor DNS
raz

Consulta iterativa:

Host en cis.poly.edu
quiere la direccin
IP de
gaia.cs.umass.edu
Servidor contactado
responde con el
nombre del servidor
a contactar

2
Puerto 53

3
4

Servidor DNS
TLD

5
Servidor DNS local
dns.poly.edu

Yo no conozco este
Consulta
nombre, pero
iterativa
pregunta a este
servidor

Host que consulta

Servidor DNS autorizado

dns.cs.umass.edu

cis.poly.edu
gaia.cs.umass.edu

Ejemplo 2
Servidor local, aquel que
hace las consultas por mi
aplicacin

Consulta iterativa
Servidor autorizado, aquel
que define el mapeo nombre
<-> IP

Consultas
Recursivas

root DNS server

Consulta recursiva :
2
Pone la carga de la

resolucin de
nombre al servidor
contactado.

3
7

TLD DNS
server

Servidor
DNS local
dns.poly.ed
u

Qu pasa en

5
8

situaciones de alta
Consultas
carga?
Recursivas

4
Servidor DNS
autorizado
dns.cs.umas
s.edu

Host cliente
cis.poly.edu
gaia.cs.umass.edu

Ejemplo
Hacer algo del tipo:
$ nslookup www.uandina.edu.pe

Ejemplo

Luego:
$ nslookup 200.37.189.196

Finalmente:
$nslookup www.google.com

Y
$ nslookup 74.125.67.104

DNS: Cache y actualizacin de

registros

Una vez que un servidor de nombre conoce un mapeo, ste

guarda el mapeo
Las entradas del cache expiran (desaparecen) despus
de algn tiempo
Servidores TLD tpicamente estn en cache de los
servidores de nombre locales
As los servidores de nombre raz no son visitados con
frecuencia

Mecanismos de Actualizacin/notificacin estn bajo diseo

por el IETF (Internet Engineering Task Force)
RFC 2136
http://www.ietf.org/html.charters/dnsindcharter.html

Registros DNS
DNS: es una base de datos distribuida que almacena registros de
recursos (resource records, RR)
Formato RR: (name, value, type, ttl)

Type=A

name es un hostname

Type=CNAME

value es una direccin IP

Type=NS

name es un dominio (e.g.

foo.com)
value es la direccin IP
(nombre) del servidor
autoritario que sabe cmo
obtener las direcciones IP de
este dominio.

name es un alias para algn

nombre real

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

value es el nombre real

Type=MX
value es el nombre del servidor de
correo asociado con name

Insercin de registros en DNS

Ejemplo: Recin se crea una empresa Network Utopia

Debemos registrar el nombre networkuptopia.com en un
administrador de dominio (e.g., Network Solutions)
Necesitamos proveer el nombre y la direccin IP de
nuestro servidor de nombre autoritario (primario y
segundario)
Administrador del dominio inserta dos RRs en el
servidor TLD com:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

Incorporar en el servidor autoritario un registro Tipo A para

www.networkuptopia.com y un registro Tipo MX para
networkutopia.com
Cmo obtiene la gente la direccin IP de nuestro Servidor
WEB?
En Per debemos acceder al NIC Per (
https://www.nic.pe/index.php) para arrendar un nombre de
dominio.

SERVICIO DE DOMINIOS EN EL
PERU

SERVICIO DE DOMINIOS EN EL
PERU

DHCP

DHCP Dynamic Host

Configuration Protocol

Establecido en el RFC 1531 (1993 ) y en el RFC 2131 (1997)

DHCP tiene como objetivo permitir la configuracin

automtica de hosts en red para que puedan obtener
informacin necesaria para operar sobre la misma.

La informacin que un host requiere es:

Direccin IP de host

Mscara de red.

Direccin IP del gateway de red

Direccin IP del Servidor de Nombres de Dominio (DNS).

RARP Reverse Address Resolution

Protocol
Proporciona la direccin IP a un

computador
Mientras que ARP mapea una direccin
IP a una direccin fsica, RARP mapea
una direccin fsica a una direccin IP.
RARP no se utiliza ms por dos razones:
Utilizaba el servicio de difusin de
capa de enlace, lo que significa que
se requiere un servidor RARP en cada
red.
Solo proporciona la direccin IP para
el computador, pero un computador

BOOTP Bootstrap Protocol

Protocolo cliente/servidor diseado para resolver
las dos limitaciones de RARP:
Al ser cliente/servidor, el servidor BOOTP puede
estar en cualquier lugar de Internet.
Puede proporcionar toda la informacin que
requiere un host.
Sin embargo BOOTP es un protocolo de
configuracin esttica.
Cuando un cliente solicita su direccin IP, el
servidor BOOTP consulta una tabla que asocia la
direccin fsica del host con su direccin IP.
Esto implica que el vnculo entre la direccin fsica
y la direccin IP del cliente ya existe. El vnculo es
predeterminado.

BOOTP Bootstrap Protocol

DHCP Dynamic Host Configuration

Protocol
DHCP es un protocolo cliente/servidor
Proporciona los cuatro datos que un

host sin disco o un equipo que arranca

por primera vez requieren.
DHCP es el sucesor de BOOTP y es
compatible con este.
El servidor DHCP escucha en el puerto
67.
El cliente DHCP escucha en el puerto
68.
Utiliza UDP como protocolo de

Funcionamiento de DHCP
Consideremos dos escenarios:
El cliente y el servidor DHCP estn en

la misma red
El cliente y el servidor DHCP estn
redes diferentes

DHCP: C/S en la misma red

El servidor DHCP emite un comando open pasivo en el

puerto UDP 67 y espera por un cliente.
2. Un cliente arrancado emite un comando open activo en
el puerto 68 .
3. El servidor responde con un mensaje de difusin o
unidifusin
1.

DHCP: C/S en redes diferentes

La peticin DHCP se difunde porque el cliente no conoce

la direccin del servidor DHCP.
2. Un datagrama IP de difusin no puede atravesar
enrutadores. Si un enrutador recibe un paquete de
difusin, lo descarta.
3. Para resolver este problema, se necesita de un agente de
reenvo (relay agent) que puede ser otro host o un
enrutador.
1.

DHCP: C/S en redes diferentes

El Agente de reenvo conoce la direccin unicast de un

servidor DHCP y escucha mensajes de difusin en el
puerto 67.
2. Cuando recibe este tipo de paquetes, encapsula el
mensaje en un datagrama unicast y enva la peticin al
servidor DHCP.
3. El servidor DHCP recibe el mensaje y devuelve su
respuesta al Agente de reenvo ,
1.

DHCP: puertos UDP

El cliente usa el puerto
68 en lugar de un
puerto efmero, para
prevenir problemas que
puedan presentarse al
recibir una respuesta
de difusin.
Problema:
1. Si Ha usa un cliente en el puerto efmero 2017
Supongamos que Hb, en la misma red utiliza el puerto
efmero 2017 para un cliente de DAYTIME.
3. Si el servidor DHCP enva un mensaje broadcast al
puerto 2017 con la direccin IP FFFFFFFF. Ha recibe un
mensaje correcto pero no Hb.
2.

4.

Si Ha y Hb estn ejecutando clientes DHCP, los mensajes

se diferenciarn por el campo Transaction ID que es

DHCP: formato de paquete

1.
2.
3.

4.

5.

6.

Operation Code: tipo de

paquete DHCP
Hardware type: define el
tipo de red fisica.
Hardware length:
longitud de la direccin
fsica.
Hop count: el mximo
nmero de saltos que
puede viajar un paquete
Transaction Id: es
establecido por el cliente
y se usa para comparar
la respuesta con la
peticin.
Number of seconds:
tiempo en segundos
desde que el cliente

TFTP

TFTP: Trivial File Transfer

Protocol
Protocolo de transferencia de

archivos simple.
Se define en el RFC 1350
Se utiliza para transferir archivos
de arranque y configuracin en
equipos sin disco, enrutadores y
otros similares.
TFTP se implementa sobre UDP y
utiliza el puerto 69.

TFTP: Trivial File Transfer

Protocol
TFTP solo permite la transferencia

de archivos
No permite crear ni borrar archivos
o carpetas
Comandos tftp:

get file
get remotefile localfile
put file
put localfile remotefile