chap2_2ed_5July02

1
Capa de aplicaciones
NOTA esta presentación es adaptada deComputer
Networking A Top Down Approach Featuring the
Internet, 2nd edition. Jim Kurose, Keith
RossAddison-Wesley.
2
Capa de aplicaciones

• Metas
• Aspectos conceptuales de la implementación de los
  protocolos para las aplicaciones de red
• Modelos de servicio de la capa de transporte
• Paradigma cliente-servidor
• Paradigma peer-to-peer

• Aprender sobre protocolos al examinar los
  protocolos de aplicaciones comunes de Internet
• SMTP / POP3 / IMAP
• HTTP
• FTP
• XMPP
• DNS
• LDAP
• Programar aplicaciones de red
• El API socket

3
Contenido

• Principios de los protocolos de la capa de
  aplicaciones
• Clientes y servidores
• Requerimientos de las aplicaciones
• Correo electrónico
• SMTP, POP3 e IMAP
• Web
• HTTP
• Transferencia de archivos
• FTP
• Mensajería instantánea
• XMPP

• Servicio de nombres de dominio
• DNS
• Servicio de directorio
• LDAP
• Programación con Sockets
• TCP
• UDP
• Construyendo un servidor Web

4
Aplicaciones de red algunos términos

• Proceso instancia de un programa que se ejecuta
  dentro de un nodo o contexto de ejecución de un
  programa que está corriendo.
• Dentro del mismo host, dos procesos se comunican
  utilizando comunicación entre procesos (definido
  por el sistema operativo).
• Los procesos que se ejecutan entre diferentes
  nodos lo hacen mediante un protocolo de la capa
  de aplicación

• Agente de usuario interfaces con el usuario
  arriba y la red abajo.
• Implementa la interfaz de usuario y el protocolo
  de la capa de aplicación
• Cliente Web browser
• Cliente E-mail lector de correo
• Cliente de mensajería instantánea IM client
• Cliente streaming audio/video media player

5
Aplicaciones y protocolos de la capa de
aplicaciones

• Aplicaciones procesos distribuidos, procesos que
  se comunican
• Por ejemplo, e-mail, Web, compartir archivos P2P,
  mensajería instantanea
• Se ejecutan en end systems (hosts)
• Intercambian mensajes para implementar la
  aplicación
• Protocolos de la capa de aplicación
• Son una parte de una aplicación
• define los mensajes que se intercambian por las
  aplicaciones y las acciones que deben realizar
• Utilizan los servicios de comunicación
  proporcionados por los protocolos de la capa
  inferior (TCP, UDP)

6
Un protocolo de la capa de aplicaciones define

• Los tipos de mensajes intercambiados, es decir
  los mensajes de solicitud y los de respuesta
• La sintáxis de los tipos de mensaje qué campos
  tendrá el mensaje y cómo se delimitan los campos
• La semántica de los campos, es decir, el
  significado de la información colocada en los
  campos
• Las reglas de cuándo y cómo los procesos envían o
  reciben mensajes

• Protocolos de dominio público
• Definidos en RFCs
• Buscan interoperabilidad
• ejemplos, HTTP, SMTP
• Protocolos proprietarios
• ejemplo, KaZaA

7
Paradigma cliente-servidor

• Las aplicaciones de red típicas tienen dos
  partes el cliente y el servidor

• Cliente
• Inicia el contacto con el servidor (habla
  primero)
• Normalmente solicita servicios desde el servidor,
  
• Web el cliente está implementado en el browser
  e-mail en el lector de correo

• Servidor
• Proporciona el servicio solicitado por el cliente
• ejemplo, el servidor Web envía la página web
  solicitada, el servidor de correo entrega el
  mensaje de correo

8
Los procesos se comunican a través de la red

• Los procesos envían/reciben mensajes hacia/desde
  su socket
• Un socket es análogo a una puerta
• El proceso que envía empuja el mensaje hacia
  afuera
• El proceso que envía asume que existe una
  infraestructura de transporte al otro lado de la
  puerta que llevará el mensaje hasta el socket del
  proceso que lo recibirá

Controlado por el desarrollador
Internet
controlado por OS

• API (1) selección del protocolo de la capa de
  transporte (2) habilidad para fijar unos pocos
  parámetros (se estudiará luego)

9
Direccionamiento de procesos

• Para que un proceso reciba mensajes, este debe
  tener un identificador
• Cualquier nodo en Internet tiene una dirección IP
  única (32 bits en IPv4, 128 bits en IPv6)
• Pregunta es suficiente con la dirección IP para
  identificar los procesos?
• Respuesta No. Muchos procesos pueden ejectutarse
  en el mismo host

• El identificador de un proceso en Internet
  incluye tanto la dirección IP como el número de
  puerto asociado con el proceso dentro del host.
• Ejemplos de números de puerto bien conocidos
• Servidor HTTP 80
• Servidor de correo 25
• Se estudiará luego

10
Qué servicios de transporte requiere una
aplicación?

• Pérdida de datos
• Algunas aplicaciones (por ejemplo, audio) pueden
  tolerar alguna pérdida
• otras aplicaciones (ftp, telnet) requieren una
  confiabilidad del 100 al transferir datos

• Ancho de Banda
• Algunas aplicaciones (multimedia) requieren un
  mínimo en la cantidad de ancho de banda para ser
  efectivas
• otras aplicaciones (aplicaciones elásticas)
  utilizan el ancho de banda que encuentren

• Control preciso de tiempo
• Algunas aplicaciones (telefonía Internet, juegos
  interactivos) requieren poco retardo para que
  sean efectivas

11
Requerimientos de servicios de transporte de
aplicaciones comunes
Sensitivo al tiempo no no no sí, 100s ms sí,
pocos s sí, 100s ms sí y no
Pérdida de Datos No No No Tolerante Tolerante T
olerante No
Aplicación Transferencia de archivos Correo Docum
entos web audio/video en tiempo real audio/video
almacenado Juegos interactivos Mensajería
instantánea
Ancho de Banda elástico elástico elástico audio
5kbps-1Mbps video10kbps-5Mbps El mismo
anterior Algunos kbps elástico
12
Servicios de los protocolos de transporte de
Internet

• Servicio de UDP
• Transferencia de datos no confiable entre el
  proceso emisor y el receptor
• NO ofrece establecimiento de conexión,
  confiabilidad, control de flujo, control de
  congestión, control de tiempo, o garantía de
  ancho de banda mínimo

• Servicio de TCP
• Orientado a conexión se debe establecer una
  conexión entre los procesos cliente y servidor
• Transporte confiable entre el proceso emisor y el
  proceso receptor
• Control de flujo el emisor no debe saturar al
  receptor
• Control de congestión el emisor debe moderarse
  cuando la red esté sobrecargada
• No ofrece ni control de tiempos, ni garantiza un
  mínimo ancho de banda

13
Aplicaciones de Internet aplicación, protocolos
de transporte
Protocolo de la capa de aplicación SMTP RFC
2821 Telnet RFC 854 HTTP RFC 2616 FTP RFC
959 proprietario (RealNetworks) proprietary (Dial
pad)
Protocolo de la capa de transporte TCP TCP TCP TC
P TCP o UDP normalmente UDP
Aplicación e-mail Acceso remoto Web
Transferencia de archivos streaming
multimedia Telefonía Internet
14
Correo electrónico

• Tres componentes principales
• Agentes de usuario
• Servidores de correo
• Protocolo simple de transferencia de correo SMTP
• Agente de usuario
• Conocido como lector de correo
• Permite elaborar, editar y leer mensajes de
  correo.
• Ejemplos Eudora, Outlook, elm, Netscape
  Messenger
• Recupera los mensajes colocados en el servidor

15
Correo electrónico servidores de correo

• Servidores de correo
• buzón contiene los mensajes que han llegado para
  el usuario
• Cola de mensajes mensajes de correo salientes
  (para ser enviados)
• Protocolo SMTP usado entre los servidores de
  correo para enviar los mensajes
• Se comporta como cliente SMTP cuando envia
  correo a otro servidor de correo
• Se comporta como servidor cuando recibe correo
  de otro servidor de correo

16
Correo electrónico SMTP RFC 2821

• Utiliza TCP para transferir confiablemente
  mensajes de correo desde el cliente al servidor,
  utiliza el puerto 25
• Transferencia directa entre el servidor que
  envía y el servidor que recibe
• La transferencia tiene tres fases
• handshaking (saludo)
• Transferencia del los mensajes
• cierre
• Interacción comando/respuesta
• comandos texto ASCII
• respuesta códigos de estado y frase
• Los mensajes deben estar en ASCII de 7 bits

17
Escenario Alicia envía un mensaje a Beto

• 4) El lado cliente de SMTP envía el mensaje de
  alicia sobre la conexión TCP
• 5) El servidor de correo de Beto coloca el
  mensaje en el buzón de Beto
• 6) Beto invoca su agente de usuario para leer los
  mensajes

• 1) Alicia utiliza su agente de usuario para
  elaborar un mensaje para beto_at_algunsitio.edu
• 2) El agente de usuario de Alicia envía el
  mensaje a su servidor de correo el mensaje es
  colocado en la cola de mensajes
• 3) El lado Cliente de SMTP abre una conexión
  TCP con el servidor de correo de Beto

1
2
6
3
4
5
18
Ejemplo de la interacción SMTP
S 220 hamburger.edu C HELO crepes.fr
S 250 Hello crepes.fr, pleased to meet
you C MAIL FROM ltalicia_at_crepes.frgt
S 250 alicia_at_crepes.fr... Sender ok C
RCPT TO ltbeto_at_hamburger.edugt S 250
beto_at_hamburger.edu ... Recipient ok C DATA
S 354 Enter mail, end with "." on a line
by itself C Te gusta la salsa de tomate?
C y los pepinillos? C . S
250 Message accepted for delivery C QUIT
S 221 hamburger.edu closing connection
19
Interacción SMTP hecha a mano

• telnet nombre_servidor 25
• Se observa el código 220 como respuesta del
  servidor
• Se digitan los comandos HELO, MAIL FROM, RCPT TO,
  DATA, QUIT
• Lo anterior le permite enviar un mensaje de
  correo electrónico sin utilizar el cliente de
  correo

20
SMTP palabras finales

• SMTP utiliza conexiones persistentes (como el
  HTTP persistente)
• SMTP obliga a que el mensaje (encabezado
  cuerpo) estén en ASCII de 7 bits
• El servidor SMTP utiliza CRLF.CRLF para decir
  donde está el final del mensaje

• Comparación con HTTP
• HTTP protocolo pull (halar)
• SMTP protocolo push (empujar)
• Los dos protocolos interactuan mediante
  comandos/respuestas en ASCII y códigos de status
• HTTP cada objeto se encapsula en su propio
  mensaje de respuesta
• SMTP multiples objectos se envían en un mensaje
  multiparte

21
Formato del mensaje de correo

• SMTP protocolo para intercambio de mensajes de
  correo
• RFC 822 estándar para el formato de mensajes de
  texto
• Líneas de header, es decir,
• To
• From
• Subject
• Son diferentes a los comandos SMTP!
• Cuerpo (body)
• Es el mensaje, sólo permite caracteres ASCII

header
Línea en blanco
body
22
Formato del mensaje extensiones para multimedia

• MIME Multimedia Internet Mail Extension, RFC
  2045, 2056
• Líneas adicionales en el header del mensaje
  declaran contenido tipo MIME

Versión de MIME
Método utilizado para codificar datos
Tipo de dato multimedia, subtipo, parámetro de
declaración
Datos codificados
23
Tipos MIMEContent-Type tipo/subtipo parámetros

• Text
• Ejemplo de subtipos plain, html
• Image
• Ejemplo de subtipos jpeg, gif
• Audio
• Ejemplo de subtipos basic (codificación 8-bit
  mu-law), 32kadpcm (codificación 32 kbps)

• Video
• Ejemplo de subtipos mpeg, quicktime
• Application
• Datos que deben ser procesados por el cliente
  antes de poderse ver
• Ejemplo de subtipos msword, octet-stream

24
Tipo Multipart
From alicia_at_crepes.fr To beto_at_hamburger.edu
Subject Imagen de un crepe. MIME-Version 1.0
Content-Type multipart/mixed
boundaryStartOfNextPart --StartOfNextPart Hola
Beto, por favor encuentra la imagen de un
crepe. --StartOfNextPart Content-Transfer-Encoding
base64 Content-Type image/jpeg base64 encoded
data ..... .........................
......base64 encoded data --StartOfNextPart te
gustaría tener la receta?
25
Protocolos de acceso al correo
SMTP
Protocolo de Acceso
Servidor de correo del remitente
Servidor de correo del destinatario

• SMTP entrega al servidor de correo del receptor
• Protocolo de acceso al correo recupera los
  mensajes desde el servidor
• POP Post Office Protocol RFC 1939
• autorización (agente lt--gtservidor) y descarga los
  mensajes
• IMAP Internet Mail Access Protocol RFC 1730
• Más características (más complejo)
• manipulación de los mensajes almacenados en el
  servidor
• HTTP Hotmail , Yahoo! Mail, etc.

26
Protocolo POP3
S OK POP3 server ready C user beto S OK
C pass goloso S OK user successfully logged
on

• Fase de autorización
• Comandos del cliente
• user nombre de usuario
• pass la clave
• Respuestas del servidor
• OK
• -ERR
• Fase de transacción, cliente
• list lista los números de los mensajes
• retr recupera el mensaje por el número
• dele borra el mensaje
• quit termina la sesión

C list S 1 498 S 2 912
S . C retr 1 S ltmessage 1
contentsgt S . C dele 1 C retr
2 S ltmessage 1 contentsgt S .
C dele 2 C quit S OK POP3 server
signing off
27
POP3 e IMAP

• Más sobre POP3
• El ejemplo anterior utiliza el modo descargue y
  borre.
• Beto no puede volver a leer un mensaje si se
  cambia de cliente
• Descargue y guarde copias de los mensajes en
  diferentes clientes
• POP3 no mantiene información de sesiones
  anteriores (stateless)

• IMAP
• Mantiene todos los mensajes en el mismo lugar el
  servidor
• Permite al usuario que organice sus mensajes en
  fólderes
• IMAP mantiene información de estado de sesiones
  anteriores
• Nombres de fólderes y mapeo entre la
  identificación de los mensajes y el nombre de los
  fólderes

28
Web y HTTP

• Algunos términos
• Una página Web consta de objetos
• Los objetos pueden ser un archivo HTML, una
  imagen JPEG, un applet Java, un archivo de
  audio,
• Una página Web consta de un archivo HTML base que
  incluye diversos objetos referenciados
• Cada objeto se direcciona con un URL
• Ejemplo de un URL

29
Panorámica de HTTP

• HTTP protocolo de transferencia de hipertexto
• Es el protocolo de la capa de aplicación para el
  Web
• Usa el modelo cliente/servidor
• cliente browser o navegador que solicita, recibe
  y muestra los objetos Web
• servidor Servidor www que envía objetos en
  respuesta a las solicitudes del browser
• HTTP 1.0 RFC 1945
• HTTP 1.1 RFC 2068

Solicitud HTTP
PC ejecutando IE Explorer
Respuesta HTTP
Solicitud HTTP
Servidor ejecutando El servidor Web Apache
Respuesta HTTP
Mac ejecutando Netscape Navigator
30
Panorámica de HTTP (continuación)

• HTTP es stateless
• El servidor no mantiene información sobre las
  solicitudes anteriores del cliente

• Utiliza TCP
• El cliente inicia la conexión TCP (crea el
  socket) al servidor, puerto 80
• El servidor acepta la conexión TCP solicitada por
  cliente
• Los mensajes HTTP (mensajes del protocolo de la
  capa de aplicación) se intercambian entre el
  browser (cliente HTTP) y el servidor Web
  (servidor HTTP)
• Se cierra la conexión TCP

NOTA

• Los protocolos que mantienen información de
  estado son complejos!
• La historia pasada (estado) debe guardarse
• Si el servidor o el cliente fallan, sus
  imágenes del estado de la sesión pueden ser
  inconsistentes y deben reconciliarlas

31
Conexiones HTTP

• HTTP no persistente
• Al menos un objeto es enviado sobre una conexión
  TCP.
• HTTP/1.0 utiliza HTTP no persistente

• HTTP persistente
• Multiples objetos pueden ser enviados sobre una
  misma conexión TCP entre el cliente y el
  servidor.
• HTTP/1.1, por omisión, utiliza conexiones
  persistentes

32
HTTP No persistente
(contiene texto, referencia a 10 imágenes jpeg)

• Supongamos que el usuario ingresa el URL
  www.algunsitio.edu/algunaFacultad/index.html

• 1a. El cliente HTTP inicia la conexión TCPal
  servidor HTTP (el proceso) en www.algunsitio.edu
  en el puerto 80

1b. El servidor HTTP en el host
www.algunsitio.edu espera conexiones TCP en el
puerto 80. Cuando acepta una conexión, notifica
al cliente
2. El cliente HTTP envía un request message (que
contiene el URL) hacia su socket de conexión TCP.
El mensaje indica que el cliente desea el objeto
algunaFacultad/index.html
3. El servidor HTTP recibe el mensaje de
solicitud, construye un response message que
contiene el objeto solicitado, y envía el mensaje
hacia su socket
tiempo
33
HTTP No persistente (cont.)
4. El servidor HTTP cierra la conexión TCP.

• 5. El cliente HTTP recibe el mensaje de repuesta
  que contiene el archivo html, muestra el html.
  Al recorrer el archivo html encuentra 10 objetos
  jpeg referenciados

tiempo
6. Los pasos 1 a 5 se repiten para cada uno de
los 10 objetos jpeg
34
Modelamiento del tiempo de respuesta

• Definición de RRT tiempo para enviar un pequeño
  paquete y que este viaje desde el cliente hasta
  el servidor y que regrese.
• Tiempo de respuesta
• Un RTT para iniciar la conexión TCP
• Un RTT para la solicitud HTTP y para que los
  primeros bytes de la respuesta HTTP regresen
• Tiempo de transmisión del archivo
• total 2RTTtiempo de transmisión

35
HTTP Persistente

• Persistencia sin pipelining
• El cliente emite una nueva solictud sólo cuando
  la respuesta anterior ha sido recibida
• Se requiere un RTT para cada objeto referenciado
• Persistencia con pipelining
• Por omisión en HTTP/1.1
• El cliente envía una solicitud tan pronto como
  encuentra un objeto referenciado
• Se requiere apenas como un RTT para TODOS los
  objetos referenciados

• Aspectos de HTTP No persistente
• requiere 2 RTTs por objeto
• El OS debe trabajar y asignar los recursos del
  host para cada conexión TCP
• En ocasiones un browser abre conexiones TCP
  paralelas para traer los objetos referenciados
• HTTP persistente
• El servidor deja la conexión abierta después de
  enviar el mensaje de respuesta
• Los mensajes HTTP que siguen entre el
  cliente/servidor son enviados sobre la misma
  conexión TCP

36
Mensaje de solicitud HTTP

• HTTP tiene dos tipos de mensajes request,
  response
• Mensaje de solicitud
• ASCII (formato legible para nosotros)

Línea de solicitud (comandos GET, POST, HEAD)
GET /algundir/pagina.html HTTP/1.1 Host
www.algunsitio.edu User-agent
Mozilla/4.0 Connection close Accept-languagefr
(carriage return, line feed adicional)
Líneas de encabezado
Carriage return, line feed Indica el final
del mensaje
37
Mensaje de solicitud HTTP formato general
38
Enviando datos al servidor desde un formulario
HTML

• Usando el método POST
• Las páginas web incluyen a menudo formularios
  para ingresar datos
• Los datos ingresados en el formulario son
  subidos o enviados al servidor a través del
  cuerpo del mensaje (Entity Body)

• Usando el URL
• Utiliza el método GET
• Los datos ingresados son enviados en el campo del
  URL de la línea de solicitud

www.algunsitio.com/busqueda?nombrearcesioapellid
onet
39
Tipos de métodos

• HTTP/1.0
• GET
• POST
• HEAD
• Hace una consulta al servidor sobre las
  características del objeto, pero no transfiere el
  objeto

• HTTP/1.1
• GET, POST, HEAD
• PUT
• Envía un archivo en el cuerpo del mensaje al path
  especificado en el URL
• DELETE
• Borra el archivo especificado en el URL

40
Mensaje de respuesta de HTTP
Línea de estado (código de estado
del Protocolo, frase de estado)
HTTP/1.1 200 OK Connection close Date Thu, 06
Aug 1998 120015 GMT Server Apache/1.3.0
(Unix) Last-Modified Mon, 22 Jun 1998 ...
Content-Length 6821 Content-Type text/html
datos datos datos datos datos ...
Líneas de encabezado
datos, es decir, archivo HTML solicitado
41
Códigos de estado de HTTP
Se usan en la primera línea del mensaje de
respuesta del servidor-gtcliente. Ejemplos

• 200 OK
• Solicitud exitosa, el objeto solicitado va en
  este mensaje
• 301 Moved Permanently
• El objeto solicitado fue movido, la nueva
  ubicación se especifica posteriormente en este
  mensaje (Location)
• 400 Bad Request
• El mensaje de solicitud no fue entendido por el
  servidor
• 404 Not Found
• El documento solicitado no se encontró en este
  servidor
• 505 HTTP Version Not Supported

42
Conexión HTTP (cliente) hecha a mano

• 1. Conéctese, a través de telnet al puerto 80, a
  su sitio Web favorito

Abre una conexión TCP al puerto 80 (puerto bien
conocido de HTTP) en www.arcesio.net. Cualquier
cosa que se digite será enviada Al puerto 80 en
www.arcesio.net
telnet www.arcesio.net 80

• 2. Digite una solicitud de HTTP con el método
  GET

Al digitar esto (y oprimir ltENTERgt dos veces), se
enviará esta solicitud HTTP mínima (pero
completa) al servidor HTTP
GET /index.html HTTP/1.0
3. Observe el mensaje de respuesta enviado por
el servidor HTTP!
43
Interacción usuario-servidor autorización

• Autorización control de acceso al contenido del
  servidor
• Credenciales de autorización normalmente un
  nombre y una clave (password)
• stateless el cliente debe presentar la
  autorización cada vez que haga una solicitud
• autorización línea del header en cada solicitud
• Si no tiene la línea autorización el servidor
  rechaza el acceso, y envía la línea de header
• WWW authenticate
• En respuesta

servidor
cliente
Solicitud http usual
401 authorization req. WWW authenticate
44
Cookies guardando el estado

• Muchos sitios Web utilizan cookies
• Cuatro componentes
• 1) Línea de header cookie en el mensaje de
  respuesta HTTP
• 2) Línea de header cookie en el mensaje de
  solicitud
• 3) El archivo de la cookie es almacenado en el
  nodo del usuario y es administrado por el browser
  del usuario
• 4) La base de datos está en el back-end del sitio
  Web

• Ejemplo
• Susana siempre accede Internet desde el mismo PC
• Ella visita un sitio de e-commerce específico por
  primera vez
• Cuando la solicitud HTTP inicial llega al sitio,
  el sitio crea un identificador único y crea un
  registro en la base de datos backend para esa
  identificación

45
Cookies guardando el estado (cont.)
El servidor crea el ID 1678 para el usuario
Registro en la Base de datos backend
acceso
acceso
Una semana después
46
Cookies (continuación)
NOTA

• Cookies y privacidad
• Las cookies permiten a los sitios aprender
  muchas cosas sobre usted
• Usted puede suministrar su nombre y su e-mail a
  los sitios web
• Las motores de búsqueda utilizan
  redireccionamiento las cookies para aprender
  aún más
• Las compañías de publicidad obtienen información
  a través de los sitios web

• Qué se puede hacer con cookies
• autorización
• Carros de compras
• recomendaciones
• Estado de la sesión de usuario (Web e-mail)

47
GET condicional caching del lado del cliente
servidor
cliente

• Meta no enviar objetos si el cliente tiene una
  versión actualizada en cache
• cliente El cliente especifica la fecha de la
  copia en cache en el mensaje de solicitud HTTP
• If-modified-since ltfechagt
• servidor La respuesta no lleva el objeto si la
  copia en cache está actualizada
• HTTP/1.0 304 Not Modified

Solicitud HTTP If-modified-since ltfechagt
objeto no modificado
Solicitud HTTP If-modified-since ltfechagt
objecto modificado
Respuesta HTTP HTTP/1.0 200 OK ltdatosgt
48
FTP protocolo de transferencia de archivos
Transferencia del archivo
usuario
Sistema de archivos remoto

• Transfiere archivos hacia y desde el host remoto
• Usa el modelo cliente/servidor
• client quien inicia la transferencia (para
  transferir hacia/desde el host remoto)
• server host remoto
• ftp RFC 959, RFC1123
• Servidor ftp puertos 21 y 20

49
FTP control separado de la conexión para datos

• El cliente FTP contacta el servidor FTP en el
  puerto 21, especificamdo TCP como protocolo de
  transporte
• El cliente obtiene autorización sobre la conexión
  de control
• El cliente permite listar el directorio remoto al
  enviar comandos sobre la conexión de control.
• Cuando el servidor recibe una comando para
  transferir un archivo, el servidor abre una
  conexión TCP para datos con el cliente
• Después de transferir el archivo, el servidor
  cierra la conexión.

• El servidor abre una segunda conexión de datos
  para transferir otro archivo.
• Conexión de control out of band
• El servidor FTP mantiene información de estado
  directorio actual, la autenticación inicial,
  etcétera

50
Comandos y respuestas FTP

• Algunos comandos
• Envíados como testo ASCII sobre el canal de
  control
• USER username
• PASS password
• LIST retorna una lista de los archivos en el
  directorio actual
• RETR filename recupera (trae) el archivo
• STOR filename almacena (coloca) el archivo en el
  host remoto

• Ejemplo de códigos de retorno
• Utiliza un código de estado y una frase (como en
  HTTP)
• 331 Username OK, password required
• 125 data connection already open transfer
  starting
• 425 Cant open data connection
• 452 Error writing file

51
Mensajería instantánea y XMPP

• La mensajería instantánea (Instant Messaging o
  IM) es una forma de comunicación en tiempo real
  entre dos o más personas con base en texto
  digitado.
• Requiere el uso de un programa cliente para
  conectarse al servicio de mensajería instantánea
  y se diferencia del correo electrónico porque las
  conversaciones ocurren en tiempo real
• Servicios de IM populares en Internet
• .NET Messenger Service, AOL Instant Messenger,
  Excite/Pal, Gadu-Gadu, Google Talk, iChat, ICQ,
  Jabber, Qnext, QQ, Meetro, Skype, Trillian,
  Yahoo! Messenger y Rediff Bol Instant Messenger.
• Estos servicios utilizan los principios de un
  antiguo servicio de charla interactivo (que aún
  es popular) conocido Internet Relay Chat (IRC).

52
Mensajería instantánea y XMPP

• Los clientes con interfaz gráfica despegaron a
  finales de 1990 con ICQ (1996) y AOL Instant
  Messenger (AIM, 1997) . Luego AOL adquirió a
  Mirabilis, los creadores de ICQ.
• Pocos años después, AOL logró dos patentes para
  mensajería instantánea en los EE.UU.
• Otras compañías desarrollaron sus propias
  aplicaciones (Yahoo, MSN, Excite, Ubique, IBM),
  cada una con su protocolo y su cliente
  propietario. Si una persona quería utilizar
  diferentes servicios debía usar diferentes
  clientes.
• En el año 2000, se liberó una aplicación y un
  protocolo abierto llamado Jabber. Este fue
  formalizado como el Extensible Messaging and
  Presence Protocol (XMPP) por la IETF en los RFCs
  3920 y 3921.
• Los servidores de Jabber pueden actuar como
  gateways a otros protocolos de IM, reduciendo la
  necesidad de tener varios clientes.
• Clientes de IM multi-protocolos, como Gaim,
  Trillian y Miranda, pueden utilizar cualquiera de
  los protocolos de IM populares sin necesidad de
  un servidor que haga de gateway.

53
Mensajería instantánea

• Recientemente, muchos servicios de mensajería
  instantánea han comenzado a ofrecer
  características de video conferencia, Voz sobre
  IP (VoIP) y web conferencing.
• Los servicios de Web conferencing integran video
  conferencia y mensajería instantánea.
• Las compañías de mensajería instantánea más
  nuevas están ofreciendo escritorio compartido, IP
  radio, e IPTV para las características de voz y
  video.
• NOTA el término "instant messenger" es una marca
  de servicio SM de Time Warner y no puede ser
  utilizado en software no afiliado con AOL en los
  EE.UU.

54
XMPP (Extensible Messaging and Presence Protocol)
Cliente XMPP

• XMPP es un protocolo para el intercambio de
  información en tiempo real, estructurada con XML
  (Extensible Markup Language).
• Aunque XMPP provee un ambiente generalizado para
  el intercambio de datos XML, es utilizado en
  mensajería instantánea.
• Puerto 5222/TCP (client-to-server)
• Puerto 5269/TCP (server-to-server)

Servidor XMPP
Servidor XMPP
Cliente XMPP
Gateway Traduce entre XMPP y NO-XMPP
Cliente XMPP
Cliente NO- XMPP
Servidor IM NO-XMPP
55
XMPP (Extensible Messaging and Presence Protocol)

• El servidor XMPP
• Maneja las sesiones con otras entidades en forma
  de XML streams hacia y desde clientes, servidores
  y otros sistemas autorizados
• Enruta stanzas XML direccionadas apropiadamente
  entre los sistemas autorizados sobre XML streams
• La mayoría de los servidores también asumen la
  resposabilidadpara almacenar los datos que
  utilizan los clientes (por ejemplo, las listas de
  contactos)
• El cliente XMPP
• La mayoría de los clientes se conectan
  directamente al servidor sobre una conexión TCP y
  utilizan XMPP para utilizar las facilidades
  ofrecidas por el servidor y cualquier servicio
  asociado.
• El puerto recomendado para la conexión entre un
  cliente y un servidor es el 5222.

56
XMPP (Extensible Messaging and Presence Protocol)

• El gateway XMPP
• Es un servicio especial -del lado del servidor-
  cuya función es traducir XMPP a protocolos
  NO-XMPP de otros sistemas de mensajería y
  viceversa. Ejemplos son los gateways para e-mail
  (SMTP), Internet Relay Chat (IRC), SIMPLE, Short
  Message Service (SMS) y sistemas como AIM, ICQ,
  MSN Messenger, y Yahoo! Instant Messenger.
• La red XMPP
• Como cada servidor es identificado por una
  dirección de red y las comunicaciones
  server-to-server son una extensión directa al
  protocolo client-to-server, en la práctica, el
  sistema consta de una red de servidores que se
  intercomunican entre sí.
• Por ejemplo, ltjulieta_at_ejemplo.comgt puede
  intercambiar mensajes, presencia y otra
  información con ltromeo_at_otroejemplo.netgt (como en
  el servicio de correo).
• Las comunicaciones entre cualesquier dos
  servidores es opcional. Si se habilita, dicha
  comunicación debe ocurrir sobre XML streams que
  estén asociados a conexiones TCP. El puerto
  recomendado para conexiones entre servidores es
  el 5269

57
Esquema de direccionamiento de XMPP

• Por razones históricas, las dirección de una
  entidad XMPP se llama Jabber Identifier o JID.
• Un JID válido contiene un conjunto ordenado de
  elementos formados por un identificador de
  dominio, un identificador de nodo y un
  identificador de recurso.
• JID nodo_at_dominio/recurso
• oscar_at_imserver.arcesio.net
• saladechat_at_200.10.20.30/pinocho

58
DNS Domain Name System

• Las personas tienen muchos identificacdores
• Cédula, nombre, pasaporte
• Identificadores de host y routers de Internet
• La dirección IP (32 bits) utilizada para
  direccionar datagramas
• El nombre, por ejemplo, gaia.cs.umass.edu
  utilizado por los humanos
• Pregunta quién asocia las direcciones IP y los
  nombres?

• Domain Name System
• Base de datos distribuida implementada un una
  jerarquía de muchos servidores de nombres
• Protocolo de la capa de aplicación utilizado por
  hosts, routers, y servidores de nombres para
  resolver nombres (traducción entre dirección y
  nombre)
• nota función central de Internet, implementada
  como un protocolo de la capa de aplicaciones

59
Servidores de nombres DNS

• Ningún servidor tiene todas las asociaciones
  nombre a IP
• Servidores de nombres locales
• cada ISP o compañía tiene un local (default) name
  server
• Las consultas que realizan los nodos primero se
  hacen con el local name server
• Servidor de nombres autorizado
• Para un host almacena la dirección IP y el
  nombre de ese host
• Puede hacer la traducción de nombre a dirección
  IP para ese host

• Por qué no un DNS centralizado?
• Un solo punto de falla
• Alto volumen de tráfico
• Base de datos centralizada distante
• mantenimiento
• NO PUEDE ESCALAR !

60
DNS Servidores raíz (root servers)

• Contactado por el servidor de nombres local que
  no puede resolver el nombre
• Servidor de nombres raíz
• Contacta el servidor de nombres autoritativo si
  el mapeo de nombre no es conocido
• Consigue el mapeo
• Retorna el mapeo al servidor de nombres local

13 servidores raíz en el mundo
61
Ejemplo Simple de DNS
DNS raíz

• surf.eurecom.fr desea saber la dirección IP de
  gaia.cs.umass.edu
• 1. Contacta su servidor DNS local, dns.eurecom.fr
• 2. dns.eurecom.fr contacta el servidor de nombres
  raíz, si es necesario
• 3. El servidor de nombres raíz contacta el
  servidor de nombres autoritativo, dns.umass.edu,
  si es necesario

2
4
3
5
DNS autoritativo dns.umass.edu
1
6
Nodo que consulta surf.eurecom.fr
gaia.cs.umass.edu
62
Ejemplo de DNS
DNS Raíz

• DNS raíz
• Podría no conocer el servidor de nombres
  autoritativo
• Podría conocer el DNS intermedio el que se
  contacta para encontrar el DNS autoritativo

6
2
3
7
5
4
1
8
DNS autoritativo dns.cs.umass.edu
Nodo que consulta surf.eurecom.fr
gaia.cs.umass.edu
63
DNS consultas iterativas
DNS raíz

• Consulta recursiva
• Coloca un bloque de consultas de resolución de
  nombres sobre el servidor de nombres contactado
• demasiada carga?
• Consulta iterada
• El servidor contactado responde con el nombre del
  servidor que se debe contactar
• Yo no conozco ese nombre, pero pregúntele a éste
  servidor

Consulta iterada
2
3
4
7
5
6
1
8
DNS autoritativo dns.cs.umass.edu
Nodo que consulta surf.eurecom.fr
gaia.cs.umass.edu
64
DNS caching y actualización de registros

• Cuando el DNS aprende el mapeo, el hace una copia
  en cache
• Los datos colocados en el cache tienen un tiempo
  de vigencia, al pasar dicho tiempo los datos
  desaparecen
• El mecanismo de actualización/notificación está
  en diseño por la IETF
• RFC 2136
• http//www.ietf.org/html.charters/dnsind-charter.h
  tml

65
Registros del DNS

• DNS registros de recursos (RR) almacenados en
  una base de datos distribuida

• TypeA
• name es un nombre de hosts
• value es una dirección IP

• TypeCNAME
• name es un alias para algún nombre canónico (el
  nombre real)
• www.ibm.com es realmente
• servereast.backup2.ibm.com
• value es el nombre canónico

• TypeNS
• name es un dominio (por ejmplo. sitio.com)
• value es una dirección IP de un DNS autoritativo
  para este dominio

• TypeMX
• value es el nombre de un servidor de correo
  asociado con name

66
Protocolo DNS y mensajes DNS

• Protocolo DNS mensajes de query y reply, juntos
  tienen el mismo formato de mensaje

• Header del mensaje
• identificación 16 bits que identifican la
  consulta (query), la respuesta a la consulta
  utiliza el mismo identificador
• flags
• Consulta o respuesta
• recursión deseada
• recursión disponible
• La respuesta es autoritativa

identificación flags
número de consultas número de RRs respondidos
Número de RRs autoritativos Número de RRs adicionales
Consultas Consultas
(número variable de consultas) (número variable de consultas)
Respuestas Respuestas
(número variable de registros de resursos) (número variable de registros de resursos)
Autoritativas Autoritativas
(número variable de registros de recursos) (número variable de registros de recursos)
Información adicional Información adicional
(Número variable de registros de recursos) (Número variable de registros de recursos)
12 bytes
67
Protocolo DNS y mensajes DNS
identificación flags
número de consultas número de RRs respondidos
Número de RRs autoritativos Número de RRs adicionales
Consultas Consultas
(número variable de consultas) (número variable de consultas)
Respuestas Respuestas
(número variable de registros de resursos) (número variable de registros de resursos)
Autoritativas Autoritativas
(número variable de registros de recursos) (número variable de registros de recursos)
Información adicional Información adicional
(Número variable de registros de recursos) (Número variable de registros de recursos)
Nombre, campos tipo Para una consulta
RRs en respuesta A una consulta
Registros para servidores autoritativos
Información adicional útil que puede usarse
68
Servicio de directorio y LDAP

• Permite consolidar los servicios existentes en un
  solo directorio que puede ser accedido mediante
  clientes (pueden ser web browsers, clientes de
  correo electrónico, servidores de correo,
  etcétera.)
• Los sercicios de directorio de red no son nuevos.
  Nosotros ya estamos familiarizados con el DNS.
• Un servicio de directorio
• Está optimizado para leer
• Implementa un modelo distribuido para almacenar
  información
• Puede extender el tipo de información que
  almacena.
• Tiene capacidades de búsqueda avanzadas.
• Tiene replicación entre servidores de directorio
• El servidio de directorio (que se accede mediante
  LDAP) no es un reemplazo de directorio
  especializados (como los filesystems o DNS) y no
  está diseñado para almacenar todo tipo de
  archivos (en un directorio es útil almacenar
  fotos en formato JPEG, pero no está hecho para
  eso).

69
LDAP (Lightweight Directory Access Protocol)

• LDAP (Versión 3) está definido en el RFC 3377 (y
  ocho RFCs más mencionados en este)
• El origen de LDAP está relacionado con el
  servicio de directorio X.500 LDAP fue diseñado
  originalmente como un protocolo para equipos de
  escritorio más liviavo para hacer solicitudes a
  los servidores X.500 (X.500 es un conjunto de
  estándares)
• LDAP es un protocolo (un conjunto de mensajes
  para acceder a cierta clase de datos) liviano en
  comparación con X.500 pues utiliza mensajes con
  poco overhead que son colocados directamente
  sobre TCP (en el puerto 389) mientras que x.500
  requieren que los clientes y el servidor se
  comuniquen sobre el modelo OSI
• Como protocolo, LDAP no dice nada sobre el lugar
  donde se almacenarán los datos. Un proveedor de
  software que implemente un servidor LDAP es libre
  de usar lo que quiera para guardar los datos
  desde archivos de texto plano hasta un motor de
  bases de datos relacional escalable.

70
LDAP protocolo de acceso

• Hablar de los servicios de directorio hace que se
  olvide que LDAP es un protocolo (algunos utilizan
  términos como LDAP server o árbol LDAP)
• LDAP ofrece un vista de datos en forma de árbol,
  y este es el árbol al que las personas se
  refieren.
• LDAP es un protocolo cliente/servidor definido en
  el RFC 2251. LDAP es asincrónico, queriendo decir
  que un cliente puede emitir múltiples solicitudes
  y que las respuestas a estas solicitudes pueden
  llegar en un orden diferente al que fueron
  emitidas.

71
Modelos de LDAP

• Los modelos de LDAP representan los servicios
  ofrecidos por un servidor, como son vistos por un
  cliente.
• Se definen cuatro modelos
• Modelo de información estructuras y tipos de
  datos necesarios para construir un árbol de
  directorio LDAP
• Modelo de nombres define como las entradas y y
  los datos son refernciados de manera única en el
  DIT (Directory Information Tree)
• Modelo funcional Es el protocolo LDAP
• Modelo de seguridad provee los mecanismos para
  que los clientes demuestren su identidad (se
  autentiquen) y para que el servidor controle el
  acceso a la información por parte del cliente
  autenticado (autorización).

72
Capítulo 2 contenido

• 2.1 Principios de los protocolos de la capa de
  aplicaciones
• Clientes y servidores
• Requerimientos de las aplicaciones
• 2.2 Web y HTTP
• 2.3 FTP
• 2.4 Correo electrónico
• SMTP, POP3 e IMAP
• 2.5 DNS

• 2.6 Programación con Sockets de TCP
• 2.7 Programación con Sockets de UDP
• 2.8 Construyendo un servidor Web
• 2.9 Distribución de contenido
• Caching de web en la red
• Redes de distribución de contenido
• Archivos compartidos P2P

73
Programación con sockets
Meta aprender cómo construir aplicaciones
cliente/servidor que se comuniquen utilizando
sockets

• El API Socket
• Distribuido en el UNIX BSD4.1, 1981
• Creado explicitamente, usado y liberado por las
  aplicaciones
• Paradigma cliente/servidor
• Dos tipos de transporte a través del socket
• Datagrama, no confiable
• No confiable, orientado a flujo de bytes (byte
  stream-oriented)

74
Programación con sockets utilizando TCP

• Socket una puerta entre el proceso de la
  aplicación y el protocolo de la capa de
  transporte (UDP o TCP)
• Servicio TCP transferencia confiable de bytes
  desde un proceso a otro

controlado por el desarrollador de la aplicación
controlado por el desarrollador de la aplicación
controlado por el sistema operativo
controlado por el sistema operativo
internet
host o servidor
host o servidor
75
Programando sockets con TCP

• El cliente debe contactar al servidor
• El proceso del servidor debe estar corriendo
  desde antes
• El servidor debe haber creado un socket (puerta)
  que acepte la solicitud del cliente
• El cliente contacta al servidor
• Creando un socket TCP local
• Especificando la dirección IP y el número de
  puerto del proceso del servidor
• Cuando el cliente crea el socket el cliente TCP
  establece una conexión al servidor TCP

• Cuando es contactado por el cliente, el servidro
  TCP crea un nuevo socket para que el proceso
  servidor se comunique con el cliente
• Permite al servidor comunicarse con múltiples
  clientes
• Los númerso de puerto origen son utilizados para
  identificar los clientes (más en el cap. 3)

76
Términos utilizados en streaming

• Un stream es una secuencia de caracteres que
  fluye hacia/desde un proceso.
• Un input stream se asocia a alguna fuente de
  entrada de datos para el procesos, por ejemplo,
  el teclado o un socket.
• Un output stream se asocia a una fuente de
  salida, por ejemplo, la pantalla o un socket.

77
Programando sockets con TCP

• Ejemplo de una aplicación cliente-servidor
• 1) El cliente lee una línea desde el dispositivo
  de entrada estándar (stream inFromUser) , envía
  al servidor a través de un socket (stream
  outToServer)
• 2) El servidor lee la línea desde un socket
• 3) El servidor convierte la línea a mayúsculas, y
  la regresa al cliente
• 4) El cliente lee la línea modificada que lee
  desde el socket y la imprime en la pantalla
  (stream inFromServer)

Proceso cliente
Socket TCP del cliente
78
Interacción de sockets en cliente/servidor TCP
Servidor (ejecutando en hostid)
Cliente
lee respuestas de clientSocket
79
Ejemplo Cliente Java (TCP)
import java.io. import java.net. class
TCPClient public static void main(String
argv) throws Exception String
sentence String modifiedSentence
BufferedReader inFromUser new
BufferedReader(new InputStreamReader(System.in))
Socket clientSocket new
Socket("hostname", 6789)
DataOutputStream outToServer new
DataOutputStream(clientSocket.getOutputStream())

Crea input stream asociado al teclado
Crea socket para el cliente, conecta al servidor
Crea output stream asociado al socket
80
Ejemplo Cliente Java (TCP), cont.
Crea input stream asociado al socket
BufferedReader inFromServer
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()))
sentence inFromUser.readLine()
outToServer.writeBytes(sentence '\n')
modifiedSentence inFromServer.readLine()
System.out.println("FROM SERVER "
modifiedSentence) clientSocket.close()

Envía la línea al servidor
Lee la línea desde el servidor
81
Ejemplo Servidor Java (TCP)
import java.io. import java.net. class
TCPServer public static void main(String
argv) throws Exception String
clientSentence String capitalizedSentence
ServerSocket welcomeSocket new
ServerSocket(6789) while(true)
Socket connectionSocket
welcomeSocket.accept()
BufferedReader inFromClient new
BufferedReader(new
InputStreamReader(connectionSocket.getInputStream(
)))
Crea socket de bienvenida en el puerto 6789
Espera, crea un socket para ser contactado por
el cliente
Crea un input stream, asociado al socket
82
Ejemplo Servidor Java (TCP), cont.
DataOutputStream outToClient
new DataOutputStream(connectionSocket.get
OutputStream()) clientSentence
inFromClient.readLine()
capitalizedSentence clientSentence.toUpperCase()
'\n' outToClient.writeBytes(capit
alizedSentence)
Crea output stream, asociado al socket
Lee la línea desde el socket
Escribe la línea al socket
Fin del ciclo while, regresa al inicio del ciclo
y espera otra conexión de cliente
83
Capítulo 2 contenido

• 2.1 Principios de los protocolos de la capa de
  aplicaciones
• Clientes y servidores
• Requerimientos de las aplicaciones
• 2.2 Web y HTTP
• 2.3 FTP
• 2.4 Correo electrónico
• SMTP, POP3 e IMAP
• 2.5 DNS

• 2.6 Programación con Sockets de TCP
• 2.7 Programación con Sockets de UDP
• 2.8 Construyendo un servidor Web
• 2.9 Distribución de contenido
• Caching de web en la red
• Redes de distribución de contenido
• Archivos compartidos P2P

84
Programando sockets con UDP

• UDP no establece una conexión entre el cliente
  y el servidor
• No hace handshaking
• El emisor explícitamente asocia la dirección IP y
  el puerto destino a cada paquete
• El servidor debe extraer la dirección IP y el
  puerto del emisor a partir del paquete enviado
• UDP los datos transmitidos pueden ser recibidos
  fuera de orden o pueden ser perdidos

85
Interacción de sockets en cliente/servidor UDP
Servidor (ejecutando en hostid)
86
Ejemplo Cliente Java (UDP)
Procesocliente
Input recibe paquetes (TCP recibe byte stream)
Output envía paquetes (TCP envía byte stream)
client UDP socket
87
Ejemplo Cliente Java (UDP)
import java.io. import java.net. class
UDPClient public static void main(String
args) throws Exception
BufferedReader inFromUser new
BufferedReader(new InputStreamReader(System.in))
DatagramSocket clientSocket new
DatagramSocket() InetAddress IPAddress
InetAddress.getByName("hostname")
byte sendData new byte1024 byte
receiveData new byte1024 String
sentence inFromUser.readLine() sendData
sentence.getBytes()
Crea input stream
Crea socket para el client
Traslada nombre de host a dirección IP
utilizando el DNS
88
Ejemplo Cliente Java (UDP), cont.
Crea datagrama con la longitud de datos-a-enviar,
dirección IP, puerto
DatagramPacket sendPacket new
DatagramPacket(sendData, sendData.length,
IPAddress, 9876) clientSocket.send(send
Packet) DatagramPacket receivePacket
new DatagramPacket(receiveData,
receiveData.length) clientSocket.receiv
e(receivePacket) String
modifiedSentence new
String(receivePacket.getData())
System.out.println("FROM SERVER"
modifiedSentence) clientSocket.close()

Envía datagrama al servidor
Lee datagrama desde el servidor
89
Ejemplo Servidor Java (UDP)
import java.io. import java.net. class
UDPServer public static void main(String
args) throws Exception
DatagramSocket serverSocket new
DatagramSocket(9876) byte
receiveData new byte1024 byte
sendData new byte1024 while(true)
DatagramPacket
receivePacket new
DatagramPacket(receiveData, receiveData.length)
serverSocket.receive(receivePacket)
Crea socket tipo Datagrama en el puerto 9876
Crea espacio para recibir datagrama
Recibe datagrama
90
Ejemplo Servidor Java (UDP), cont
String sentence new
String(receivePacket.getData())
InetAddress IPAddress receivePacket.getAddress()
int port receivePacket.getPort()
String
capitalizedSentence sentence.toUpperCase()
sendData capitalizedSentence.getBytes()
DatagramPacket sendPacket
new DatagramPacket(sendData,
sendData.length, IPAddress,
port) serverSocket.send(s
endPacket)
Consigue le dirección IP puerto , del
solicitante
Crea datagrama para envíar al cliente
Escribe el datagrama en el socket
Fin del ciclo while, regresa al inicio y espera
otro datagrama
91
Construyendo un servidor Web simple

• Después de construir el servidor, usted puede
  solicitar el archivo urilizando un browser
  (Internet Explorer o Netscape Navigator)
• Vea el texto para más detalles

• Maneja sólo una solicitud HTTP
• Acepta la solicitud
• Analiza el header
• Obtiene el archivo solicitado desde el sistema de
  archivos del servidor
• Crea el mensaje de respuesta HTTP
• Líneas de header archivo
• Envía la respuesta al cliente

92
Programando sockets referencias

• Tutorial para lenguaje C (audio/slides)
• Unix Network Programming (J. Kurose),
• http//manic.cs.umass.edu/amldemo/courseware/intr
  o.
• Tutoriales de Java
• All About Sockets (Sun tutorial),
  http//www.javaworld.com/javaworld/jw-12-1996/jw-1
  2-sockets.html
• Socket Programming in Java a tutorial,
  http//www.javaworld.com/javaworld/jw-12-1996/jw-1
  2-sockets.html

93
Capítulo 2 contenido

• 2.1 Principios de los protocolos de la capa de
  aplicaciones
• Clientes y servidores
• Requerimientos de las aplicaciones
• 2.2 Web y HTTP
• 2.3 FTP
• 2.4 Correo electrónico
• SMTP, POP3 e IMAP
• 2.5 DNS

• 2.6 Programación con Sockets de TCP
• 2.7 Programación con Sockets de UDP
• 2.8 Construyendo un servidor Web
• 2.9 Distribución de contenido
• Caching de web en la red
• Redes de distribución de contenido
• Archivos compartidos P2P

94
Cache en Web (servidor proxy)
Meta satisfacer las solicitudes del cliente sin
involucrar el servidor origen

• El usuario debe configurar el browser Los
  accesos web se realizan a través del cache
• El browser envía todas las solicitudes HTTP al
  cache
• Si el objeto está en el cache el cache retorna
  el objeto
• Si el objeto no está en el cache, el servidor de
  cache lo solicita desde el servidor origen y
  entonces envía el objeto al cliente

Servidor origen
Servidor Proxy
Solicitud HTTP
Solicitud HTTP
cliente
Respuesta HTTP
Respuesta HTTP
Solicitud HTTP
RespuestaHTTP response
cliente
Servidor origen
95
Más sobre Web caching

• El servidor de cache actua tanto como cliente y
  como servidor
• El servidor de cache puede hacer actualizaciones
  de su contenido utilizando el header HTTP
  If-modified-since
• Probelma el servidor de cache debería tomar el
  riesgo y entregar el objeto copiado en su disco
  sin hacer ninguna revisión?
• Se utilizan métodos heurísticos.
• Un servidor de cache típico se instala en un ISP
  (universidad, compañía, ISP residencial)

• Por qué utilizar Web caching?
• Reduce el tiempo de respuesta de las solicitudes
  del cliente.
• Reduce el tráfico sobre el canal de acceso a
  Internet de una institución.
• Internet con muchos servidores cache permite que
  los proveedores de contenido pobre entreguen
  contenido de manera efectiva

96
Ejemplo de Caching (1)

• Supuestos
• Tamaño promedio del objeto 100,000 bits
• Tasa de solicitudes promediodesde el browser de
  la institucióna los servidores origen 15/seg
• Retardo desde el router institucional a cualquier
  servidor origen y de regreso al router 2 seg
• Consecuencias
• utilización sobre la LAN 15
• utilización sobre el enlace de acceso 100
• Retardo total retardo en Internet retardo
  del canal de acceso retardo en la LAN
• 2 seg minutos milisegundos

Servidores origen
Internet pública
Enlace de acceso 1.5 Mbps
Red institucional
LAN a 10 Mbps
97
Ejemplo de Caching (2)
Servidores origen

• Posible solución
• Incrementar ancho de banda del enlace de acceso,
  digamos a 10 Mbps
• Consecuencias
• Utilización de la LAN 15
• Utilización sobre el enlace de acceso 15
• Retardo Total retardo en Internet retardo
  del canal de acceso retardo en la LAN
• 2 seg milisegundos milisegundos
• Generalmente una actualización costosa

Internet pública
Enlace de acceso