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 clienteservidor
Paradigma peer-topeer (par-a-par)

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 permiten desarrollo y
despliegue rpido

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 Cliente-servidor
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 CLIENTE-SERVIDOR
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 CLIENTE-SERVIDOR
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
efmeros para cada conexin.
Se crea una cola por conexin.

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

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 Universal Resource Locator
(URL)

Ejemplo URL: www.uandina.edu.pe/dais/index.html

Nombre de la mquina

Nombre de camino
(path name)

HTTP Generalidades

HTTP: HyperText Transfer Protocol

Protocolo de la capa aplicacin de

la Web

Modelo cliente/servidor

PC ejecutando
Explorer

cliente: browser que solicita,

recibe, y despliega objetos
Web

Servidor
ejecutando
Apache Web
server

servidor: Servidor Web enva

objetos en respuesta a
requerimientos

HTTP 1.0: RFC 1945 (1996)

HTTP 1.1: RFC 2068 (1997)

Mac ejecutando
Navigator

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 No-persistente

HTTP Persistente

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

Es como hacer una llamada

por objeto.

Mltiples objetos pueden ser

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

HTTP/1.0 utiliza HTTP nopersistente

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 su regreso.
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

Iniciar conexin
TCP
RTT
solicitar
archivo

Tiempo
para
transmitir
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 no-persistente:
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 son enviados
por la conexin abierta

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)

Lnea de requerimiento
(request line) (comandos
GET, POST, HEAD)

Lneas de
encabezado

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr

(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 URL

METODO
GET
HEAD
PUT
POST
TRACE
DELETE
CONNECT
OPTIONS

ACCION
Solicitar un documento del servidor
Solicitar informacin sobre un documento pero no el propio documento
Enva un documento del cliente al servidor
Envia alguna informacin del cliente al servidor
Repite y devuelve la solicitud entrante
Elimina un objeto web
Reservado
Consulta sobre opciones disponibles

Nombres de Headers de peticin

HEADER

DESCRIPCION

User-agent

Identifica al programa cliente

Accept

Muestra el formato del medio que el cliente puede aceptar

Accept-charset

Muestra el juego de caracteres que el cliente puede manejar

Accept-encoding Muestra el esquema de codificacin que el icliente puede manejar

Accept-language Muestra el lenguaje que el cliente puede aceptar
Authorization

Muestra los permisos que tiene el cliente

Host

Muestra el nmero de puerto y host del cliente

Date

Muestra la fecha actual

Upgrade

Especifica el protocolo de comunicacin preferido

Cookie

Devuelve el cookie al servidor

If-Modified-Since Si el archivo se modific desde una fecha especfica

Mensajes HTTP de respuesta

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

data, e.g.,
archivo
HTML solicitado

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

Mensajes HTTP de respuesta: formato general

Nombres de Headers de respuesta

HEADER

DESCRIPCION
Date
Muestra la fecha actual
Upgrade
Especifica el protocolo de comunicacin preferido
Server
Brinda informacin sobre el servidor
Set-Cookie
El servidor solicita al cliente guardar una cookie
Content-Encoding Especifica el esquema de codificacin
Content-Language Especifica el lenguaje
Content-Length
Muestra la longitud del documento
Content-Type
Especifica el tipo de medio
Location
Para pedir al cliente que enve la peticin a otro sitio
Last-Modified
Indica la fecha y hora del ltimo cambio

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 qenqo.uandina.edu.pe 80
Obs: www es un alias para qenqo

Telnet abre una conexin TCP al

puerto 80 (puerto servidor HTTP por
omisin) en qenqo.uandina.edu.pe
Cualquier cosa ingresada es enviada
al puerto 80 de qenqo

2. Escribir un requerimiento GET HTTP:

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:

Susana 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
Cookie file
ebay: 8734

Cookie file
amazon: 1678
ebay: 8734

servidor
Requerimiento http
Respuesta http +

Set-cookie: 1678
requerimiento http

cookie: 1678
respuesta http usual

Servidor crea
ID 1678
para usuario

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

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.)
Al margen
Qu pueden transportar las
cookies:

Autorizacin

Carrito de compras

Sugerencias

Estado de la sesin del usuario

(Web e-mail)

Cookies y privacidad:
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 en forma
efectiva.

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

= + +

= + + 2

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

Servidores
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
= 0.6*(2.01) s + 0.4*0.01 < 1.3 s

Esta solucin es ms econmica que la 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

servidor

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

HTTP response

objeto
no
modificado

HTTP/1.0
304 Not Modified

If-modified-since: <date>

Servidor: responde sin el

objeto si la copia de la cache
es la ltima. :
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.

Definido en el RFC 959
Sigue modelo cliente/servidor
Cliente: Sitio que inicia la sesin
Servidor: Host remoto
Puerto del servidor ftp: 21
Puerto del cliente ftp: cualquier puerto

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 de un
archivo, el servidor cierra la
conexin de datos.

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

user
agent
mail
server

Agente Usuario
SMTP
Tambin conocido como lector de
correo
mail
Escritura, edicin, lectura de
server
mensajes de correos
e.g., Eudora, Outlook, elm, Mozilla
Thunderbird
Mensajes de salida y entrada son
user
almacenados en servidor
agent

user
agent

SMTP

mail
server

user
agent

SMTP
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

SMTP: Protocolo entre servidores de

correo para enviar mensajes e-mail

cliente: servidor que enva el

correo
servidor: servidor que recibe el
correo

user
agent
mail
server

SMTP
SMTP
SMTP
mail
server
user
agent
user
agent

user
agent
mail
server

user
agent

user
agent

Correo Electrnico: Servidor de correo

Servidor de Correo

Casilla contiene mensajes de

entrada para el usuario

Cola de mensajes de los correos

de salida

SMTP: Protocolo entre

servidores de correo para enviar
mensajes e-mail

cliente: servidor que enva el

correo
servidor: servidor que recibe
el correo

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
2) El agente de Alicia enva en
mensaje a su servidor de correo;
el mensaje es puesto en cola de
salida
3) Lado cliente de SMTP abre una
conexin TCP con el servidor de
correo de Bob

4) El cliente SMTP enva el mensaje

de Alicia por la conexin TCP
5) El servidor de correo de Bob
pone el mensaje en su casilla
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 caracteres ASCII

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
user
agent
Puerto 25

Servidor mail
de la fuente

SMTP

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

user
agent

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:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:

Tamao del mensaje

list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off

on

POP3 (ms) e IMAP

Ms sobre POP3

IMAP

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)

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.

Domain Name System:

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

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

Por qu no centralizar 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.west-coast.amazon.com),
servidor DNS rota entre
direcciones IP

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

Acta como proxy, re-enva consulta dentro de la jerarqua.

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
Servidor DNS TLD

Puerto 53

4
5

Servidor DNS local

dns.poly.edu

Yo no conozco este
nombre, pero pregunta a
este servidor

Consulta iterativa
Servidor DNS autorizado
dns.cs.umass.edu

Host que consulta

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

Qu pasa en

situaciones de alta
carga?

Consultas Recursivas

4
Servidor DNS
autorizado
dns.cs.umass.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/dnsind-charter.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

value es una direccin IP

Type=CNAME

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).
Esta informacin puede estar almacenada en un archivo local,
pero no siempre es posible (estaciones terminales sin disco)
Antes a DHCP se utilizaba RARP y BOOTP

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 requiere
mas datos.

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

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

1.

2.
3.

El servidor DHCP emite un comando open pasivo en el puerto UDP 67 y

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

DHCP: C/S en redes diferentes

1.
2.
3.

La peticin DHCP se difunde porque el cliente no conoce la direccin

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

DHCP: C/S en redes diferentes

1.
2.
3.
4.

El Agente de reenvo conoce la direccin unicast de un servidor DHCP y

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

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
2. 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.
4. Si Ha y Hb estn ejecutando clientes DHCP, los mensajes se
diferenciarn por el campo Transaction ID que es nica para cada
conexin DHCP

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
comenz el arranque

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

TELNET

TELNET: TErminaL NETwork

Definido en el RFC 97 (1969)

Aplicacin de acceso remoto.

Opera en el puerto 23
Enva mensajes en texto claro (sin encriptacin)

Su uso es limitado por problemas de seguridad.

Se apoya en tres conceptos:
Network Virtual Terminal (NVT)
Opciones y negociacin de opciones
Operaciones simtricas

TELNET
NVT resuelve el problema de heterogeneidad de los host de red

al implementar una interfaz universal.

Mediante esta interfaz, el cliente TELNET convierte caracteres
(datos o comandos) de un host local a formato NVT y los entrega
a la red.
El servidor TELNET convierte los datos y comandos NVT a un
formato aceptable por el host

TELNET
NVT usa dos grupos de caracteres, uno para datos y otro para

control.

Algunos comandos para TELNET se muestran a continuacin

TELNET
Algunas opciones de TELNET:

SSH Secure SHell

SSH: Secure SHell

Diseado para reemplazar a TELNET
Comprende tres componentes:
SSH TRANS: protocolo SSH de capa de transporte
SSH AUTH: Protocolo de autenticacin SSH
SSH CONN: Protocolo de conexin SSH

SSH - TRANS
Ofrece un canal seguro sobre TCP
Inicialmente se establece una conexin TCP insegura y

luego el cliente y el servidor negocian un canal seguro

Los servicios ofrecidos por este protocolo son:
Privacidad o confidencialidad del mensaje
intercambiado
Integridad de datos (los datos no seran alterados
por un intruso)
Autenticacin de servidor (as el cliente tiene la
seguridad que interacta con el servidor correcto)
Compresin de mensajes.

SSH - AUTH
Autentica al cliente frente al servidor.
Se utiliza despus de establecer un canal

seguro y haber autenticado al servidor.

El cliente enva una peticin al servidor,
incluyendo el nombre de usuario, nombre
de servidor, el mtodo de autenticacin y
los datos requeridos
El servidor responde con un mensaje de
xito que confirma que el cliente esta
autenticado o un mensaje de fracaso lo que
significa que el proceso debe repetirse con
un nuevo mensaje de peticin.

SSH - CONN
Despus de establecer un canal seguro y

autenticar al cliente y al servidor SSH invoca al

protocolo SSH CONN
SSH CONN ofrece servicios de multiplexado.
Pueden crearse mltiples canales lgicos entre
el cliente y el servidor
Cada canal puede utilizarse para diferentes
propsitos como acceso remoto, transferencia
de archivos y otros.

USOS DE SSH
Acceso remoto
Transferencia de archivos
sftp transferencia de archivos segura
scp copia de archivos segura
Reenvo de puerto: permite establecer un canal seguro

entre aplicaciones que no proveen servicios de

seguridad

FORMATO DE PAQUETE SSH

Lenght: Longitud de paquete sin incluir el padding
Padding: Se agrega para mejorar el nivel seguridad del

paquete
Type: Tipo de paquete enviado
CRC : Se usa para control de errores