Capa de aplicaciones NOTA esta presentacin es adaptada
- Slides: 110
Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer Networking: A Top Down Approach Featuring the Internet, 2 nd edition. Jim Kurose, Keith Ross Addison-Wesley. Capa de Aplicaciones 1
Capa de aplicaciones Metas: r Aspectos conceptuales de la implementación de los protocolos para las aplicaciones de red m Modelos de servicio de la capa de transporte m Paradigma clienteservidor m Paradigma peer-to-peer r Aprender sobre protocolos al examinar los protocolos de aplicaciones comunes de Internet m m m SMTP / POP 3 / IMAP HTTP FTP XMPP DNS LDAP r Programar aplicaciones de red m El API socket Capa de Aplicaciones 2
Contenido r Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r Correo electrónico m SMTP, POP 3 e IMAP r Web m HTTP r Transferencia de archivos m FTP r Servicio de nombres de dominio m DNS r Servicio de directorio m LDAP r Programación con Sockets m m TCP UDP r Construyendo un servidor Web r Mensajería instantánea m XMPP Capa de Aplicaciones 3
Aplicaciones de red: algunos términos Proceso: instancia de un Agente de usuario: interfaces programa que se ejecuta con el usuario “arriba” y la dentro de un nodo o contexto red “abajo”. de ejecución de un programa r Implementa la interfaz de que está corriendo. usuario y el protocolo de la r Dentro del mismo host, dos capa de aplicación procesos se comunican m Cliente Web: browser utilizando comunicación entre m Cliente E-mail: lector de procesos (definido por el correo sistema operativo). m Cliente de mensajería r Los procesos que se ejecutan instantánea: IM client entre diferentes nodos lo m Cliente streaming hacen mediante un protocolo audio/video: media player de la capa de aplicación Capa de Aplicaciones 4
Aplicaciones y protocolos de la capa de aplicaciones Aplicaciones: procesos distribuidos, procesos que se comunican m m m Por ejemplo, e-mail, Web, compartir archivos P 2 P, mensajería instantanea Se ejecutan en end systems (hosts) Intercambian mensajes para implementar la aplicación transporte red enlace física Protocolos de la capa de aplicación m m m 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) aplicación transporte red enlace física Capa de Aplicaciones 5
Un protocolo de la capa de aplicaciones define… r Los tipos de mensajes intercambiados, es decir los mensajes de solicitud y los de respuesta r La sintáxis de los tipos de mensaje: qué campos tendrá el mensaje y cómo se delimitan los campos r La semántica de los campos, es decir, el significado de la información colocada en los campos r Las reglas de cuándo y cómo los procesos envían o reciben mensajes Protocolos de dominio público: r Definidos en RFCs r Buscan interoperabilidad r ejemplos, HTTP, SMTP Protocolos proprietarios: r ejemplo, Ka. Za. A Capa de Aplicaciones 6
Paradigma cliente-servidor Las aplicaciones de red típicas tienen dos partes: el cliente y el servidor Cliente: aplicación transporte red enlace física r Inicia el contacto con el servidor (“habla primero”) r Normalmente solicita servicios desde el servidor, r Web: el cliente está implementado en el browser; e-mail: en el lector de correo Servidor: r Proporciona el servicio solicitado por el cliente r ejemplo, el servidor Web envía la página web solicitada, el servidor de correo entrega el mensaje de correo solicitud respuesta aplicación transporte red enlace física Capa de Aplicaciones 7
Los procesos se comunican a través de la red r Los procesos envían/reciben mensajes hacia/desde su socket r Un socket es análogo a una puerta m m 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á host o servidor proceso Controlado por el desarrollador proceso socket TCP con buffers, variables Internet TCP con buffers, variables controlado por OS r API: (1) selección del protocolo de la capa de transporte; (2) habilidad para fijar unos pocos parámetros (se estudiará luego) Capa de Aplicaciones 8
Direccionamiento de procesos: r Para que un proceso reciba mensajes, este debe tener un identificador r Cualquier nodo en Internet tiene una dirección IP única (32 bits en IPv 4, 128 bits en IPv 6) r Pregunta: ¿es suficiente con la dirección IP para identificar los procesos? r Respuesta: No. Muchos procesos pueden ejectutarse en el mismo host r 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. r Ejemplos de números de puerto “bien conocidos”: m m Servidor HTTP: 80 Servidor de correo: 25 r Se estudiará luego Capa de Aplicaciones 9
¿Qué servicios de transporte requiere una aplicación? Pérdida de datos r Algunas aplicaciones (por ejemplo, audio) pueden tolerar alguna pérdida r otras aplicaciones (ftp, telnet) requieren una confiabilidad del 100% al transferir datos Control preciso de tiempo r Algunas aplicaciones (telefonía Internet, juegos interactivos) requieren poco retardo para que sean “efectivas” Ancho de Banda r Algunas aplicaciones (multimedia) requieren un mínimo en la cantidad de ancho de banda para ser “efectivas” r otras aplicaciones (“aplicaciones elásticas”) utilizan el ancho de banda que encuentren Capa de Aplicaciones 10
Requerimientos de servicios de transporte de aplicaciones comunes Pérdida Aplicación de Datos Ancho de Banda Transferencia de archivos Correo Documentos web audio/video en tiempo real elástico audio: 5 kbps-1 Mbps video: 10 kbps-5 Mbps audio/video almacenado Tolerante El mismo anterior Juegos interactivos Tolerante Algunos kbps Mensajería instantánea No elástico No No No Tolerante Sensitivo al tiempo no no no sí, 100’s ms sí, pocos s sí, 100’s ms sí y no Capa de Aplicaciones 11
Servicios de los protocolos de transporte de Internet Servicio de TCP: r Orientado a conexión: se debe r r 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 Servicio de UDP: r Transferencia de datos no confiable entre el proceso emisor y el receptor r 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 Capa de Aplicaciones 12
Aplicaciones de Internet: aplicación, protocolos de transporte Aplicación e-mail Acceso remoto Web Transferencia de archivos streaming multimedia Telefonía Internet Protocolo de la capa de aplicación Protocolo de la capa de transporte SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietario (Real. Networks) proprietary (Dialpad) TCP TCP TCP o UDP normalmente UDP Capa de Aplicaciones 13
Correo electrónico Cola de mensajes salientes Agente de usuario Tres componentes principales: r Agentes de usuario r Servidores de correo servidor de correo r Protocolo simple de r Conocido como “lector de correo” r Permite elaborar, editar y leer mensajes de correo. r Ejemplos: Eudora, Outlook, elm, Netscape Messenger r Recupera los mensajes colocados en el servidor Agente de usuario SMTP transferencia de correo: SMTP Agente de usuario Buzón del usuario SMTP Servidor de correo Agente de usuario Capa de Aplicaciones 14
Correo electrónico: servidores de correo Agente de usuario Servidores de correo r buzón contiene los mensajes que han llegado para el usuario r Cola de mensajes de correo salientes (para ser enviados) r Protocolo SMTP usado entre los servidores de correo para enviar los mensajes m Se comporta como cliente SMTP: cuando envia correo a otro servidor de correo m Se comporta como “servidor”: cuando recibe correo de otro servidor de correo Agente de usuario SMTP Servidor de correo Agente de usuario Capa de Aplicaciones 15
Correo electrónico: SMTP [RFC 2821] r Utiliza TCP para transferir confiablemente mensajes de correo desde el cliente al servidor, utiliza el puerto 25 r Transferencia directa: entre el servidor que envía y el servidor que recibe r La transferencia tiene tres fases m handshaking (saludo) m Transferencia del los mensajes m cierre r Interacción comando/respuesta m comandos: texto ASCII m respuesta: códigos de estado y frase r Los mensajes deben estar en ASCII de 7 bits Capa de Aplicaciones 16
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@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 Agente de usuario 2 Servidor de correo 3 4 5 6 Agente de usuario Capa de Aplicaciones 17
Ejemplo de la interacción SMTP S: C: S: C: C: C: S: 220 hamburger. edu HELO crepes. fr 250 Hello crepes. fr, pleased to meet you MAIL FROM: <alicia@crepes. fr> 250 alicia@crepes. fr. . . Sender ok RCPT TO: <beto@hamburger. edu> 250 beto@hamburger. edu. . . Recipient ok DATA 354 Enter mail, end with ". " on a line by itself ¿Te gusta la salsa de tomate? ¿y los pepinillos? . 250 Message accepted for delivery QUIT 221 hamburger. edu closing connection Capa de Aplicaciones 18
Interacción SMTP hecha “a mano” : r telnet nombre_servidor 25 r Se observa el código 220 como respuesta del servidor r 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 Capa de Aplicaciones 19
SMTP: palabras finales r SMTP utiliza conexiones persistentes (como el HTTP persistente) r SMTP obliga a que el mensaje (encabezado & cuerpo) estén en ASCII de 7 bits r El servidor SMTP utiliza CRLF para “decir” donde está el final del mensaje Comparación con HTTP: r HTTP: protocolo pull (halar) r SMTP: protocolo push (empujar) r Los dos protocolos interactuan mediante comandos/respuestas en ASCII y códigos de status r HTTP: cada objeto se “encapsula” en su propio mensaje de respuesta r SMTP: multiples objectos se envían en un mensaje “multiparte” Capa de Aplicaciones 20
Formato del mensaje de correo SMTP: protocolo para intercambio de mensajes de correo RFC 822: estándar para el formato de mensajes de texto: r Líneas de header, es decir, header Línea en blanco body To: m From: m Subject: ¡Son diferentes a los comandos SMTP! m r Cuerpo (body) m Es el “mensaje”, sólo permite caracteres ASCII Capa de Aplicaciones 21
Formato del mensaje: extensiones para multimedia r MIME: Multimedia Internet Mail Extension, RFC 2045, 2056 r 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 From: alicia@crepes. fr To: beto@hamburger. edu Subject: Imagen de un crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data Datos codificados Capa de Aplicaciones 22
Tipos MIME Content-Type: tipo/subtipo; parámetros Text r Ejemplo de subtipos: plain, html Image r Ejemplo de subtipos : jpeg, gif Audio r Ejemplo de subtipos: basic (codificación 8 -bit mu-law), 32 kadpcm (codificación 32 kbps) Video r Ejemplo de subtipos: mpeg, quicktime Application r Datos que deben ser procesados por el cliente antes de “poderse ver” r Ejemplo de subtipos: msword, octet-stream Capa de Aplicaciones 23
Tipo Multipart From: alicia@crepes. fr To: beto@hamburger. edu Subject: Imagen de un crepe. MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=Start. Of. Next. Part --Start. Of. Next. Part Hola Beto, por favor encuentra la imagen de un crepe. --Start. Of. Next. Part Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --Start. Of. Next. Part ¿te gustaría tener la receta? Capa de Aplicaciones 24
Protocolos de acceso al correo SMTP Agente de usuario Servidor de correo del remitente SMTP Protocolo de Agente de Acceso usuario Servidor de correo del destinatario r SMTP: entrega al servidor de correo del receptor r Protocolo de acceso al correo: recupera los mensajes desde el servidor m POP: Post Office Protocol [RFC 1939] • autorización (agente <-->servidor) y descarga los mensajes m IMAP: Internet Mail Access Protocol [RFC 1730] • Más características (más complejo) • manipulación de los mensajes almacenados en el servidor m HTTP: Hotmail , Yahoo! Mail, etc. Capa de Aplicaciones 25
Protocolo POP 3 Fase de autorización r Comandos del cliente: user: nombre de usuario m pass: la clave r Respuestas del servidor m +OK m -ERR m Fase de transacción, r r cliente: lista los números de los mensajes retr: recupera el mensaje por el número dele: borra el mensaje quit: termina la sesión S: C: S: +OK POP 3 server ready user beto +OK pass goloso +OK user successfully logged C: S: S: S: C: C: S: list 1 498 2 912. retr 1 <message 1 contents>. dele 1 retr 2 <message 1 contents>. dele 2 quit +OK POP 3 server signing off Capa de Aplicaciones 26 on
POP 3 e IMAP Más sobre POP 3 r El ejemplo anterior utiliza el modo “descargue y borre”. r Beto no puede volver a leer un mensaje si se cambia de cliente r “Descargue y guarde”: copias de los mensajes en diferentes clientes r POP 3 no mantiene información de sesiones anteriores (stateless) IMAP r Mantiene todos los mensajes en el mismo lugar: el servidor r Permite al usuario que organice sus mensajes en fólderes r IMAP mantiene información de estado de sesiones anteriores: m Nombres de fólderes y “mapeo” entre la identificación de los mensajes y el nombre de los fólderes Capa de Aplicaciones 27
Web y HTTP Algunos términos r Una página Web consta de objetos r Los objetos pueden ser un archivo HTML, una imagen JPEG, un applet Java, un archivo de audio, … r Una página Web consta de un archivo HTML base que incluye diversos objetos referenciados r Cada objeto se direcciona con un URL r Ejemplo de un URL: www. algunsitio. edu/alguna. Facultad/pic. gif Nombre del host Nombre del path Capa de Aplicaciones 28
Panorámica de HTTP: protocolo de transferencia de hipertexto r Es el protocolo de la capa de aplicación para el Web r Usa el modelo cliente/servidor m cliente: browser o navegador que solicita, recibe y muestra los objetos Web m servidor: Servidor www que envía objetos en respuesta a las solicitudes del browser r HTTP 1. 0: RFC 1945 r HTTP 1. 1: RFC 2068 Sol icit ud H PC ejecutando. Res pue sta IE Explorer TT P HT TP TP T H d u TP Servidor t i T c H li ejecutando ta So s e u El servidor Web sp e R Apache Mac ejecutando Netscape Navigator Capa de Aplicaciones 29
Panorámica de HTTP (continuación) Utiliza TCP: r El cliente inicia la conexión TCP (crea el socket) al servidor, puerto 80 r El servidor acepta la conexión TCP solicitada por cliente r 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) r Se cierra la conexión TCP HTTP es “stateless” r El servidor no mantiene información sobre las solicitudes anteriores del cliente NOTA ¡Los protocolos que mantienen información de estado son complejos! r La historia pasada (estado) debe guardarse r Si el servidor o el cliente fallan, sus “imágenes” del estado de la sesión pueden ser inconsistentes y deben “reconciliarlas” Capa de Aplicaciones 30
Conexiones HTTP no persistente r Al menos un objeto es enviado sobre una conexión TCP. r HTTP/1. 0 utiliza HTTP no persistente HTTP persistente r Multiples objetos pueden ser enviados sobre una misma conexión TCP entre el cliente y el servidor. r HTTP/1. 1, por omisión, utiliza conexiones persistentes Capa de Aplicaciones 31
HTTP No persistente Supongamos que el usuario ingresa el URL www. algunsitio. edu/alguna. Facultad/index. html (contiene texto, referencia a 10 imágenes jpeg) 1 a. El cliente HTTP inicia la conexión TCPal servidor HTTP (el proceso) en www. algunsitio. edu en el puerto 80 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 alguna. Facultad/index. html tiempo 1 b. El servidor HTTP en el host www. algunsitio. edu espera conexiones TCP en el puerto 80. Cuando “acepta” una conexión, notifica al cliente 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 Capa de Aplicaciones 32
HTTP No persistente (cont. ) 4. El servidor HTTP cierra la 5. El cliente HTTP recibe el conexión TCP. 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 Capa de Aplicaciones 33
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: r Un RTT para iniciar la conexión TCP r Un RTT para la solicitud HTTP y para que los primeros bytes de la respuesta HTTP regresen r Tiempo de transmisión del archivo total = 2 RTT+tiempo de transmisión Inicia Conexión TCP RTT solicita archivo tiempo para transmitir archivo RTT archivo recibido tiempo Capa de Aplicaciones 34
HTTP Persistente Aspectos de HTTP No persistente: r requiere 2 RTTs por objeto r El OS debe trabajar y asignar los recursos del host para cada conexión TCP r En ocasiones un browser abre conexiones TCP paralelas para traer los objetos referenciados HTTP persistente r El servidor deja la conexión abierta después de enviar el mensaje de respuesta r Los mensajes HTTP que siguen entre el cliente/servidor son enviados sobre la misma conexión TCP Persistencia sin pipelining: r El cliente emite una nueva solictud sólo cuando la respuesta anterior ha sido recibida r Se requiere un RTT para cada objeto referenciado Persistencia con pipelining: r Por omisión en HTTP/1. 1 r El cliente envía una solicitud tan pronto como encuentra un objeto referenciado r Se requiere apenas como un RTT para TODOS los objetos referenciados Capa de Aplicaciones 35
Mensaje de solicitud HTTP r HTTP tiene dos tipos de mensajes: request, response r Mensaje de solicitud: m ASCII (formato legible para nosotros) Línea de solicitud (comandos GET, POST, HEAD) GET /algundir/pagina. html HTTP/1. 1 Host: www. algunsitio. edu Líneas de User-agent: Mozilla/4. 0 encabezado Connection: close Accept-language: fr “Carriage return, line feed” Indica el final del mensaje (“carriage return, line feed” adicional) Capa de Aplicaciones 36
Mensaje de solicitud HTTP: formato general Capa de Aplicaciones 37
Enviando datos al servidor desde un formulario HTML Usando el método POST: r Las páginas web incluyen a menudo formularios para ingresar datos r Los datos ingresados en el formulario son “subidos” o enviados al servidor a través del cuerpo del mensaje (Entity Body) Usando el URL: r Utiliza el método GET r Los datos ingresados son enviados en el campo del URL de la línea de solicitud www. algunsitio. com/busqueda? nombre=arcesio&apellido=net Capa de Aplicaciones 38
Tipos de métodos HTTP/1. 0 r GET r POST r HEAD m Hace una consulta al servidor sobre las características del objeto, pero no transfiere el objeto HTTP/1. 1 r GET, POST, HEAD r PUT m Envía un archivo en el cuerpo del mensaje al path especificado en el URL r DELETE m Borra el archivo especificado en el URL Capa de Aplicaciones 39
Mensaje de respuesta de HTTP Línea de estado (código de estado del Protocolo, frase de estado) Líneas de encabezado datos, es decir, 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 datos datos. . . Capa de Aplicaciones 40
Códigos de estado de HTTP Se usan en la primera línea del mensaje de respuesta del servidor->cliente. Ejemplos: 200 OK m Solicitud exitosa, el objeto solicitado va en este mensaje 301 Moved Permanently m El objeto solicitado fue movido, la nueva ubicación se especifica posteriormente en este mensaje (Location: ) 400 Bad Request m El mensaje de solicitud no fue entendido por el servidor 404 Not Found m El documento solicitado no se encontró en este servidor 505 HTTP Version Not Supported Capa de Aplicaciones 41
Conexión HTTP (cliente) hecha “a mano” 1. Conéctese, a través de telnet al puerto 80, a su sitio Web favorito: telnet www. arcesio. net 80 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 2. Digite una solicitud de HTTP con el método GET: GET /index. html HTTP/1. 0 Al digitar esto (y oprimir <ENTER> dos veces), se enviará esta solicitud HTTP mínima (pero completa) al servidor HTTP 3. ¡Observe el mensaje de respuesta enviado por el servidor HTTP! Capa de Aplicaciones 42
Interacción usuario-servidor: autorización Autorización : control de acceso servidor cliente al contenido del servidor Solicitud http usual r Credenciales de autorización: normalmente un nombre y una 401: authorization req. WWW authenticate: clave (password) r stateless: el cliente debe presentar la autorización cada Solicitud http usual vez que haga una solicitud + Autorización: <cred> m m 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: Respuesta http usual Solicitud http usual + Autorización: <cred> Respuesta http usual tiempo En respuesta Capa de Aplicaciones 43
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: m m m Susana siempre accede Internet desde el mismo PC Ella visita un sitio de ecommerce 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 Capa de Aplicaciones 44
Cookies: guardando el “estado” (cont. ) cliente ebay: 8734 Archivo Cookie amazon: 1678 ebay: 8734 Solicitud http usual Respuesta http usual + Set-cookie: 1678 Solicitud http usual cookie: 1678 Respuesta http usual El servidor crea el ID 1678 para el usuario Acción específica para cookie amazon: 1678 ebay: 8734 so acce ac ce Una semana después: Archivo Cookie Re Ba gist ba se d ro e ck e n l en da a tos d so Archivo Cookie servidor Solicitud http usual cookie: 1678 Respuesta http usual Acción específica para cookie Capa de Aplicaciones 45
Cookies (continuación) Qué se puede hacer con cookies: r autorización r Carros de compras r recomendaciones r Estado de la sesión de usuario (Web e-mail) NOTA Cookies y privacidad: r Las cookies permiten a los sitios aprender muchas cosas sobre usted r Usted puede suministrar su nombre y su e-mail a los sitios web r Las motores de búsqueda utilizan redireccionamiento & las cookies para aprender aún más r Las compañías de publicidad obtienen información a través de los sitios web Capa de Aplicaciones 46
GET condicional: caching del lado del cliente r Meta: no enviar objetos si el cliente tiene una versión actualizada en cache r cliente: El cliente especifica la fecha de la copia en cache en el mensaje de solicitud HTTP If-modified-since: <fecha> r servidor: La respuesta no lleva el objeto si la copia en cache está actualizada: HTTP/1. 0 304 Not Modified servidor cliente Solicitud HTTP If-modified-since: <fecha> Respuesta HTTP objeto no modificado HTTP/1. 0 304 Not Modified Solicitud HTTP If-modified-since: <fecha> Respuesta HTTP objecto modificado HTTP/1. 0 200 OK <datos> Capa de Aplicaciones 47
FTP: protocolo de transferencia de archivos Interface Cliente para FTP usuario Transferencia del archivo Sistema de archivos local Servidor FTP Sistema de archivos remoto r Transfiere archivos hacia y desde el host remoto r Usa el modelo cliente/servidor client: quien inicia la transferencia (para transferir hacia/desde el host remoto) m server: host remoto r ftp: RFC 959, RFC 1123 r Servidor ftp: puertos 21 y 20 m Capa de Aplicaciones 48
FTP: control separado de la conexión para datos Puerto 21, conexión TCP de control r El cliente FTP contacta el r r 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. Cliente FTP Puerto 20, conexión TCP para datos Servidor FTP r El servidor abre una segunda conexión de datos para transferir otro archivo. r Conexión de control: “out of band” r El servidor FTP mantiene información “de estado”: directorio actual, la autenticación inicial, etcétera Capa de Aplicaciones 49
Comandos y respuestas FTP Algunos comandos: r Envíados como testo ASCII sobre el canal de control r USER username r PASS password r LIST retorna una lista de los archivos en el directorio actual Ejemplo de códigos de retorno r Utiliza un código de estado r r r RETR filename recupera r r STOR filename almacena r (trae) el archivo (coloca) el archivo en el host remoto y una frase (como en HTTP) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file Capa de Aplicaciones 50
Mensajería instantánea y XMPP r 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. r 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 r Servicios de IM populares en Internet m . NET Messenger Service, AOL Instant Messenger, Excite/Pal, Gadu-Gadu, Google Talk, i. Chat, ICQ, Jabber, Qnext, QQ, Meetro, Skype, Trillian, Yahoo! Messenger y Rediff Bol Instant Messenger. r Estos servicios utilizan los principios de un antiguo servicio de charla interactivo (que aún es popular) conocido Internet Relay Chat (IRC). Capa de Aplicaciones 51
Mensajería instantánea y XMPP r Los clientes con interfaz gráfica despegaron a finales de 1990 con r r r 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. Capa de Aplicaciones 52
Mensajería instantánea r Recientemente, muchos servicios de mensajería instantánea han comenzado a ofrecer características de video conferencia, Voz sobre IP (Vo. IP) y web conferencing. m m 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. r 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. Capa de Aplicaciones 53
XMPP (Extensible Messaging and Presence Protocol) r XMPP es un protocolo para el intercambio de información en tiempo real, estructurada con XML (Extensible Markup Language). r Aunque XMPP provee un ambiente generalizado para el intercambio de datos XML, es utilizado en mensajería instantánea. r Puerto 5222/TCP (client-to -server) r Puerto 5269/TCP (serverto-server) Servidor XMPP Cliente XMPP Gateway Traduce entre XMPP y NO-XMPP Cliente NO- XMPP Servidor IM NO-XMPP Capa de Aplicaciones 54
XMPP (Extensible Messaging and Presence Protocol) r El servidor XMPP: m Maneja las sesiones con otras entidades en forma de XML streams hacia y desde clientes, servidores y otros sistemas autorizados m Enruta stanzas XML direccionadas apropiadamente entre los sistemas autorizados sobre XML streams m La mayoría de los servidores también asumen la resposabilidadpara almacenar los datos que utilizan los clientes (por ejemplo, las listas de contactos) r El cliente XMPP m 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. m El puerto recomendado para la conexión entre un cliente y un servidor es el 5222. Capa de Aplicaciones 55
XMPP (Extensible Messaging and Presence Protocol) r El gateway XMPP: m 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. r La red XMPP m 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, <julieta@ejemplo. com> puede intercambiar mensajes, presencia y otra información con <romeo@otroejemplo. net> (como en el servicio de correo). m 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 Capa de Aplicaciones 56
Esquema de direccionamiento de XMPP r Por razones históricas, las dirección de una entidad XMPP se llama Jabber Identifier o JID. r 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. r JID = nodo@dominio/recurso m oscar@imserver. arcesio. net m saladechat@200. 10. 20. 30/pinocho Capa de Aplicaciones 57
DNS: Domain Name System Las personas: tienen muchos identificacdores: m Cédula, nombre, pasaporte Identificadores de host y routers de Internet: m m 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: r Base de datos distribuida implementada un una jerarquía de muchos servidores de nombres r 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) m nota: función central de Internet, implementada como un protocolo de la capa de aplicaciones Capa de Aplicaciones 58
Servidores de nombres DNS ¿Por qué no un DNS centralizado? r Un solo punto de falla r Alto volumen de tráfico r Base de datos centralizada distante r mantenimiento r Ningún servidor tiene todas las asociaciones nombre a IP Servidores de nombres locales: m m 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: m ¡ NO PUEDE ESCALAR ! m 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 Capa de Aplicaciones 59
DNS: Servidores raíz (root servers) r Contactado por el servidor de nombres local que no puede resolver el nombre r Servidor de nombres raíz: m Contacta el servidor de nombres autoritativo si el mapeo de nombre no es conocido m Consigue el mapeo m Retorna el mapeo al servidor de nombres local a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA 13 servidores raíz en el mundo Capa de Aplicaciones 60
Ejemplo Simple de DNS surf. eurecom. fr desea saber la dirección IP de gaia. cs. umass. edu DNS raíz 2 5 1. Contacta su servidor DNS local, dns. eurecom. fr DNS local 2. dns. eurecom. fr contacta dns. eurecom. fr el servidor de nombres 1 raíz, si es necesario 6 3. El servidor de nombres raíz contacta el servidor de nombres autoritativo, Nodo que consulta dns. umass. edu, si es surf. eurecom. fr necesario 3 4 DNS autoritativo dns. umass. edu gaia. cs. umass. edu Capa de Aplicaciones 61
Ejemplo de DNS Raíz DNS raíz: r Podría no conocer el servidor de nombres autoritativo r Podría conocer el DNS intermedio: el que se contacta para encontrar el DNS autoritativo 6 2 7 DNS local dns. eurecom. fr 1 8 Nodo que consulta 3 DNS intermedio dns. umass. edu 4 5 DNS autoritativo dns. cs. umass. edu surf. eurecom. fr gaia. cs. umass. edu Capa de Aplicaciones 62
DNS: consultas iterativas Consulta recursiva: 2 r Coloca un bloque de consultas de resolución de nombres sobre el servidor de nombres contactado r ¿demasiada carga? Consulta iterada: r El servidor contactado responde con el nombre del servidor que se debe contactar r “Yo no conozco ese nombre, pero pregúntele a éste servidor” DNS raíz Consulta iterada 3 4 7 DNS local dns. eurecom. fr 1 8 Nodo que consulta DNS intermedio dns. umass. edu 5 6 DNS autoritativo dns. cs. umass. edu surf. eurecom. fr gaia. cs. umass. edu Capa de Aplicaciones 63
DNS: caching y actualización de registros r Cuando el DNS aprende el mapeo, el hace una copia en cache m Los datos colocados en el cache tienen un tiempo de vigencia, al pasar dicho tiempo los datos desaparecen r El mecanismo de actualización/notificación está en diseño por la IETF m RFC 2136 m http: //www. ietf. org/html. charters/dnsind-charter. html Capa de Aplicaciones 64
Registros del DNS: registros de recursos (RR) almacenados en una base de datos distribuida Fromato RR: (name, value, type, ttl) r Type=A r Type=CNAME m name es un nombre de m name es un alias para algún hosts nombre “canónico” (el nombre real) m value es una dirección IP www. ibm. com es realmente r Type=NS servereast. backup 2. ibm. com m name es un dominio (por m value es el nombre canónico ejmplo. sitio. com) r Type=MX m value es una dirección IP de m value es el nombre de un un DNS autoritativo para servidor de correo asociado con este dominio name Capa de Aplicaciones 65
Protocolo DNS y mensajes DNS Protocolo DNS: mensajes de query y reply, juntos tienen el mismo formato de mensaje identificación flags Header del mensaje r identificación: 16 bits que identifican la consulta (query), la respuesta a la consulta utiliza el mismo identificador r flags: m Consulta o respuesta m recursión deseada m recursión disponible m La respuesta es autoritativa número de consultas número de RRs respondidos Número de RRs autoritativos Número de RRs adicionales 12 bytes Consultas (número variable de consultas) Respuestas (número variable de registros de resursos) Autoritativas (número variable de registros de recursos) Información adicional (Número variable de registros de recursos) Capa de Aplicaciones 66
Protocolo DNS y mensajes DNS Nombre, campos tipo Para una consulta RRs en respuesta A una consulta identificación flags número de consultas número de RRs respondidos Número de RRs autoritativos Número de RRs adicionales Consultas (número variable de consultas) Respuestas Registros para servidores autoritativos Información adicional útil que puede usarse (número variable de registros de resursos) Autoritativas (número variable de registros de recursos) Información adicional (Número variable de registros de recursos) Capa de Aplicaciones 67
Servicio de directorio y LDAP r 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. ) r Los sercicios de directorio de red no son nuevos. Nosotros ya estamos familiarizados con el DNS. r Un servicio de directorio: m m m 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 r 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). Capa de Aplicaciones 68
LDAP (Lightweight Directory Access Protocol) r LDAP (Versión 3) está definido en el RFC 3377 (y ocho RFCs más mencionados en este) r 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) r 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 m 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. Capa de Aplicaciones 69
LDAP: protocolo de acceso r 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) r LDAP ofrece un vista de datos en forma de árbol, y este es el árbol al que las personas se refieren. r 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. Capa de Aplicaciones 70
Modelos de LDAP r Los modelos de LDAP representan los servicios ofrecidos por un servidor, como son vistos por un cliente. r Se definen cuatro modelos m m 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). Capa de Aplicaciones 71
Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r 2. 2 Web y HTTP r 2. 3 FTP r 2. 4 Correo electrónico m SMTP, POP 3 e IMAP r 2. 5 DNS r 2. 6 Programación con Sockets de TCP r 2. 7 Programación con Sockets de UDP r 2. 8 Construyendo un servidor Web r 2. 9 Distribución de contenido m m m Caching de web en la red Redes de distribución de contenido Archivos compartidos P 2 P Capa de Aplicaciones 72
Programación con sockets Meta: aprender cómo construir aplicaciones cliente/servidor que se comuniquen utilizando sockets El API Socket r Distribuido en el UNIX BSD 4. 1, 1981 r Creado explicitamente, usado y liberado por las aplicaciones r Paradigma cliente/servidor r Dos tipos de transporte a través del socket: m Datagrama, no confiable m No confiable, orientado a flujo de bytes (byte stream-oriented) socket Una interface local al host, creado por la aplicación, controlado por el OS (una “puerta”) hacia la cual los procesos de las aplicaciones pueden enviar y recibir mensajes hacia/desde otro proceso de aplicación Capa de Aplicaciones 73
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 sistema operativo proceso socket TCP con buffers, variables host o servidor internet socket TCP con buffers, variables controlado por el desarrollador de la aplicación controlado por el sistema operativo host o servidor Capa de Aplicaciones 74
Programando sockets con TCP El cliente debe contactar al servidor: r El proceso del servidor debe estar corriendo desde antes r El servidor debe haber creado un socket (puerta) que acepte la solicitud del cliente El cliente contacta al servidor: r Creando un socket TCP local r Especificando la dirección IP y el número de puerto del proceso del servidor r Cuando el cliente crea el socket: el cliente TCP establece una conexión al servidor TCP r Cuando es contactado por el cliente, el servidro TCP crea un nuevo socket para que el proceso servidor se comunique con el cliente m Permite al servidor comunicarse con múltiples clientes m Los númerso de puerto origen son utilizados para identificar los clientes (más en el cap. 3) Para la aplicación… TCP permite transferir bytes de manera confiable, en orden (“un tubo”), entre el cliente Y el servidor Capa de Aplicaciones 75
Términos utilizados en streaming r Un stream es una secuencia de caracteres que fluye hacia/desde un proceso. r Un input stream se asocia a alguna fuente de entrada de datos para el procesos, por ejemplo, el teclado o un socket. r Un output stream se asocia a una fuente de salida, por ejemplo, la pantalla o un socket. Capa de Aplicaciones 76
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 in. From. User) , envía al servidor a través de un socket (stream out. To. Server) 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 in. From. Server) Proceso cliente Socket TCP del cliente Capa de Aplicaciones 77
Interacción de sockets en cliente/servidor: TCP Servidor (ejecutando en hostid) Cliente crea socket, port=x, para recibir solicitudes: welcome. Socket = Server. Socket() establece conexión TCP espera solicitudes de conexión connection. Socket = welcome. Socket. accept() envía solicitudes usando client. Socket lee solicitudes desde connection. Socket escribe las respuestas en connection. Socket cierra connection. Socket crea socket, se conecta a hostid, port=x client. Socket = Socket() cierra conexión TCP lee respuestas de client. Socket cierra client. Socket Capa de Aplicaciones 78
Ejemplo: Cliente Java (TCP) import java. io. *; import java. net. *; class TCPClient { Crea input stream asociado al teclado Crea socket para el cliente, conecta al servidor Crea output stream asociado al socket public static void main(String argv[]) throws Exception { String sentence; String modified. Sentence; Buffered. Reader in. From. User = new Buffered. Reader(new Input. Stream. Reader(System. in)); Socket client. Socket = new Socket("hostname", 6789); Data. Output. Stream out. To. Server = new Data. Output. Stream(client. Socket. get. Output. Stream()); Capa de Aplicaciones 79
Ejemplo: Cliente Java (TCP), cont. Crea input stream asociado al socket Buffered. Reader in. From. Server = new Buffered. Reader(new Input. Stream. Reader(client. Socket. get. Input. Stream())); sentence = in. From. User. read. Line(); Envía la línea al servidor out. To. Server. write. Bytes(sentence + 'n'); Lee la línea desde el servidor modified. Sentence = in. From. Server. read. Line(); System. out. println("FROM SERVER: " + modified. Sentence); client. Socket. close(); } } Capa de Aplicaciones 80
Ejemplo: Servidor Java (TCP) import java. io. *; import java. net. *; class TCPServer { 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 public static void main(String argv[]) throws Exception { String client. Sentence; String capitalized. Sentence; Server. Socket welcome. Socket = new Server. Socket(6789); while(true) { Socket connection. Socket = welcome. Socket. accept(); Buffered. Reader in. From. Client = new Buffered. Reader(new Input. Stream. Reader(connection. Socket. get. Input. Stream())); Capa de Aplicaciones 81
Ejemplo: Servidor Java (TCP), cont. Crea output stream, asociado al socket Data. Output. Stream out. To. Client = new Data. Output. Stream(connection. Socket. get. Output. Stream()); Lee la línea desde el socket client. Sentence = in. From. Client. read. Line(); capitalized. Sentence = client. Sentence. to. Upper. Case() + 'n'; Escribe la línea al socket out. To. Client. write. Bytes(capitalized. Sentence); } } } Fin del ciclo while, regresa al inicio del ciclo y espera otra conexión de cliente Capa de Aplicaciones 82
Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r 2. 2 Web y HTTP r 2. 3 FTP r 2. 4 Correo electrónico m SMTP, POP 3 e IMAP r 2. 5 DNS r 2. 6 Programación con Sockets de TCP r 2. 7 Programación con Sockets de UDP r 2. 8 Construyendo un servidor Web r 2. 9 Distribución de contenido m m m Caching de web en la red Redes de distribución de contenido Archivos compartidos P 2 P Capa de Aplicaciones 83
Programando sockets con UDP: no establece una “conexión” entre el cliente y el servidor r No hace handshaking r El emisor explícitamente asocia la dirección IP y el puerto destino a cada paquete r El servidor debe extraer la dirección IP y el puerto del emisor a partir del paquete enviado Para la aplicación… UDP transfiere de manera no confiable grupos de bytes (“datagramas”) entre el cliente y el servidor UDP: los datos transmitidos pueden ser recibidos fuera de orden o pueden ser perdidos Capa de Aplicaciones 84
Interacción de sockets en cliente/servidor: UDP Servidor (ejecutando en hostid) crea socket, port=x, para recibir solicitudes: server. Socket = Datagram. Socket() Lee la solicitud desde server. Socket Escribe la respuesta en server. Socket Especificando la dirección IP del cliente y el número de puerto Cliente crea socket, client. Socket = Datagram. Socket() Crea, asocia dirección (hostid, port=x) envía datagrama de solicitud usando client. Socket Lee la respuesta desde client. Socket cierra client. Socket Capa de Aplicaciones 85
Ejemplo: Cliente Java (UDP) Proceso cliente Input: recibe paquetes (TCP recibe “byte stream”) Output: envía paquetes (TCP envía “byte stream”) client UDP socket Capa de Aplicaciones 86
Ejemplo: Cliente Java (UDP) import java. io. *; import java. net. *; Crea input stream Crea socket para el client Traslada nombre de host a dirección IP utilizando el DNS class UDPClient { public static void main(String args[]) throws Exception { Buffered. Reader in. From. User = new Buffered. Reader(new Input. Stream. Reader(System. in)); Datagram. Socket client. Socket = new Datagram. Socket(); Inet. Address IPAddress = Inet. Address. get. By. Name("hostname"); byte[] send. Data = new byte[1024]; byte[] receive. Data = new byte[1024]; String sentence = in. From. User. read. Line(); send. Data = sentence. get. Bytes(); Capa de Aplicaciones 87
Ejemplo: Cliente Java (UDP), cont. Crea datagrama con la longitud de datosa-enviar, dirección IP, puerto Envía datagrama al servidor Datagram. Packet send. Packet = new Datagram. Packet(send. Data, send. Data. length, IPAddress, 9876); client. Socket. send(send. Packet); Datagram. Packet receive. Packet = new Datagram. Packet(receive. Data, receive. Data. length); Lee datagrama desde el servidor client. Socket. receive(receive. Packet); String modified. Sentence = new String(receive. Packet. get. Data()); System. out. println("FROM SERVER: " + modified. Sentence); client. Socket. close(); } } Capa de Aplicaciones 88
Ejemplo: Servidor Java (UDP) import java. io. *; import java. net. *; Crea socket tipo Datagrama en el puerto 9876 class UDPServer { public static void main(String args[]) throws Exception { Datagram. Socket server. Socket = new Datagram. Socket(9876); byte[] receive. Data = new byte[1024]; byte[] send. Data = new byte[1024]; while(true) { Crea espacio para recibir datagrama Recibe datagrama Datagram. Packet receive. Packet = new Datagram. Packet(receive. Data, receive. Data. length); server. Socket. receive(receive. Packet); Capa de Aplicaciones 89
Ejemplo: Servidor Java (UDP), cont String sentence = new String(receive. Packet. get. Data()); Consigue le dirección IP puerto #, del solicitante Inet. Address IPAddress = receive. Packet. get. Address(); int port = receive. Packet. get. Port(); String capitalized. Sentence = sentence. to. Upper. Case(); send. Data = capitalized. Sentence. get. Bytes(); Crea datagrama para envíar al cliente Escribe el datagrama en el socket } Datagram. Packet send. Packet = new Datagram. Packet(send. Data, send. Data. length, IPAddress, port); server. Socket. send(send. Packet); } } Fin del ciclo while, regresa al inicio y espera otro datagrama Capa de Aplicaciones 90
Construyendo un servidor Web simple r Maneja sólo una solicitud r r HTTP Acepta la solicitud Analiza el header Obtiene el archivo solicitado desde el sistema de archivos del servidor Crea el mensaje de respuesta HTTP: m r Después de construir el servidor, usted puede solicitar el archivo urilizando un browser (Internet Explorer o Netscape Navigator) r Vea el texto para más detalles Líneas de header + archivo r Envía la respuesta al cliente Capa de Aplicaciones 91
Programando sockets: referencias Tutorial para lenguaje C (audio/slides): r “Unix Network Programming” (J. Kurose), http: //manic. cs. umass. edu/~amldemo/courseware/intro. Tutoriales de Java: r “All About Sockets” (Sun tutorial), http: //www. javaworld. com/javaworld/jw-12 -1996/jw-12 sockets. html r “Socket Programming in Java: a tutorial, ” http: //www. javaworld. com/javaworld/jw-12 -1996/jw-12 sockets. html Capa de Aplicaciones 92
Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r 2. 2 Web y HTTP r 2. 3 FTP r 2. 4 Correo electrónico m SMTP, POP 3 e IMAP r 2. 5 DNS r 2. 6 Programación con Sockets de TCP r 2. 7 Programación con Sockets de UDP r 2. 8 Construyendo un servidor Web r 2. 9 Distribución de contenido m m m Caching de web en la red Redes de distribución de contenido Archivos compartidos P 2 P Capa de Aplicaciones 93
Cache en Web (servidor proxy) Meta: satisfacer las solicitudes del cliente sin involucrar el servidor origen r El usuario debe configurar el browser: Los accesos web se realizan a través del cache r El browser envía todas las solicitudes HTTP al cache m m 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 TP icit T Proxy ud HT Res it TP c i TP cliente pue T l o H Sol S ta s e HT spu TP e R TP T nse H o p tud es i r c li TP So T ta. H s e pu s Re cliente sta Servidor origen Capa de Aplicaciones 94
Más sobre Web caching r El servidor de cache actua tanto como cliente y como servidor r El servidor de cache puede hacer actualizaciones de su contenido utilizando el header HTTP If-modified-since m m 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. r Un servidor de cache típico se instala en un ISP (universidad, compañía, ISP residencial) ¿Por qué utilizar Web caching? r Reduce el tiempo de respuesta de las solicitudes del cliente. r Reduce el tráfico sobre el canal de acceso a Internet de una institución. r Internet con muchos servidores cache permite que los proveedores de contenido “pobre” entreguen contenido de manera efectiva Capa de Aplicaciones 95
Ejemplo de Caching (1) Supuestos r Tamaño promedio del objeto = 100, 000 bits r Tasa de solicitudes promediodesde el browser de la institucióna los servidores origen = 15/seg r Retardo desde el router institucional a cualquier servidor origen y de regreso al router = 2 seg Consecuencias r utilización sobre la LAN = 15% r utilización sobre el enlace de acceso = 100% r 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 Capa de Aplicaciones 96
Ejemplo de Caching (2) Posible solución r Incrementar ancho de banda del enlace de acceso, digamos a 10 Mbps Consecuencias Servidores origen Internet pública r Utilización de la LAN = 15% Enlace de acceso 10 Mbps r Utilización sobre el enlace de acceso = 15% r Retardo Total = retardo en Internet + retardo del canal de acceso + retardo en la LAN = 2 seg + milisegundos r Generalmente una actualización costosa Red institucional LAN a 10 Mbps Capa de Aplicaciones 97
Ejemplo de Caching (3) Servidores origen Instalando servidor cahe r Supongamos que la tasa de hits es. 4 r 40% de las solicitudes serán satisfechas casi inmediatamente El 60% de las solicitudes serán satisfechas desde el servidor origen La utilización del enlace de accesose reduce al 60%, lográndose retardos casi despreciables (diagmos 10 milisegundos) Retardo total = Retardo en Internet + retardo en el enlace de acceso + retardo en la LAN. 6*2 segundos +. 6*. 01 segundos + milisegundos < 1. 3 segundos Consecuencia r r r = Internet pública Enlace de acceso Red institucional 1. 5 Mbps 10 Mbps LAN Cache institucional Capa de Aplicaciones 98
Redes de distribución de contenido (CDNs) r Los proveedores de contenido Servidor origen en Norteamérica son los clientes de las CDN. Replicación de contenido r Las CDN instalan cientos de Nodo de distribución CDN servidores CDN sobre toda Internet m En los ISPs que están más cerca de los usuarios r La CDN replica el contenido de sus clientes en los servidores CDN. Cuando el Servidor CDN En Suarmérica proveedor actualiza el Servjdor CDN en Asia contenido, la CDN actualiza en Europa los servidores Capa de Aplicaciones 99
Ejemplo de CDN Solicitud HTTP para www. foo. com/sports. html Servidor origen 1 2 3 Consulta DNS para www. cdn. com Servidor DNS autoritativo Para las CDNs Solicitud HTTP para www. cdn. com/www. foo. com/sports/ruth. gif Servidor CDN cercano Servidor origen r www. foo. com r distribuye HTML r Reemplaza: http: //www. foo. com/sports. ruth. gif con http: //www. cdn. com/www. foo. com/sports/ruth. gif Compañía CDN r cdn. com r distribuye archivos gif r Utiliza su servidor DNS autoritativo para enrutar y redirigir las solicitudes Capa de Aplicaciones 100
Más sobre CDNs Solicitudes de enrutamiento r La CDN crea un mapa indicando las distancias desde los ISP “hoja” y los nodos CDN r Cuando una consulta llega al servidor DNS autoritativo: m El servidor determina el m ISP desde el cual se origina la consulta Utiliza “mapeo” para determinar el mejor servidor CDN No sólo páginas web r Audio y video “streaming stored” r Audio y video en “realtime” m Los nodos CDN construyen una overlay network sobre la capa de aplicaciones Capa de Aplicaciones 101
Compartiendo archivos P 2 P r Alicia selecciona uno de los Ejemplo r Alicia corre un cliente para una aplicación P 2 P sobre su computador r Intermitentemente se conecta a Internet; consigue una dirección IP nueva para cada conexión r Pregunta por “Hey Jude” r La aplicación muestra otros PCs que tienenuna copia de Hey Jude. PCs, Beto. r El archivo es copiado desde el PC de Beto al computador de Alicia: HTTP r Mientras Alicia descarga, otros usuarios descargan del computador de Alicia. r El PC de alicia ejecuta una plicación que es a la vez un cliente Web y uin servidor Web. Todos los equipos (peers) se comportan como servidores = ¡servicio altamente escalable! Capa de Aplicaciones 102
P 2 P: directorio centralizado Diseño original de Servidor de directorio centralizado “Napster” 1) Cuando un PC se conecta, este informa al servidor central: m m Dirección IP contenido 2) Alicia pregunta por “Hey Jude” 3) Alicia solicita el archivo desde Beto 2 Beto 1 PCs (peers) 1 3 1 1 Alicia Capa de Aplicaciones 103
P 2 P: problemas con directorio centralizado r Un solo punto de falla (fall el directorio, falla todo) r Cuello de botella para el desempeño r Problemas con derechos de autor (Copyright) la transferencia de archivos es descentralizada, pero la localización de contenido es altamente centralizada Capa de Aplicaciones 104
P 2 P: directorio descentralizado r Cada PC o es un líder de grupo a es asignado a un líder de grupo. r El líder de grupo debe mantener un seguimiento al contenido de todos “sus hijos”. r Un PC consulta a su líder de grupo; un líder de grupo puede consultar a otros líderes de grupo. Capa de Aplicaciones 105
Más sobre directorio descentralizado overlay network r Los PCs son los nodos r Hay arcos entre los PCs y sus líderes de grupo r También hay arcos entre parejas de líderes r Vecinos virtuales Nodo bootstrap r Un PC que se conecte se le asigna la tarea de ser un líder de grupo o es asignado a un líder Ventajas del enfoque r No hay servidor de directorio centralizado m m El servicio de localización se distribuye en entre los PCs Más difícil de “derribar” desventajas del enfoque r Se necesita un nodo de bootstrap r Los líderes de grupo pueden recibir sobrecarga de trabajo Capa de Aplicaciones 106
P 2 P: inundación de consultas r Gnutella r Envía la consulta a sus vecinos r No existen jerarquías r Los vecinos reenvían la consulta r Utiliza un nodo bootstrap r Si el PCs consultado tiene el para aprender sobre los otros r Mensaje de asociación ( join message) objeto, este envía el mensaje de regreso al PC que hizo la consulta join Capa de Aplicaciones 107
P 2 P: más sobre inundación de consultas Ventajas r Tienen responsabilidades similares: no hay líderes en el grupo r Altamente descentralizado r Ningún nodo mantiene información de directorio Desventajas r excesivo tráfico de consultas r query radius: may not have content when present r bootstrap node r maintenance of overlay network Capa de Aplicaciones 108
Capítulo 2: resumen Nuestro estudio de aplicaciones de red se ha terminado! r Requerimientos de r Protocolos específicos: servicio de las m HTTP aplicaciones: m FTP m confiabilidad, ancho de banda, delay r Paragdima cliente- servidor r Modelo de servicio de transporte de Internet m m Orientado a conexión, confiable: TCP No confiable, datagramas: UDP m m SMTP, POP, IMAP DNS r Programación con sockets r Distribución de contenido m m caches, CDNs P 2 P Capa de Aplicaciones 109
Capítulo 2: resumen Más importante: aprender sobre protocolos r Intercambio de mensajes solicitud/respuesta típico: m m El cliente solicita información o el servicio El servidor responde con datos, códigos de estado r Formatos de mensaje: m m Encabezados: campos que dan información sobre los datos: la información que está siendo transmitida r control vs. mensajes de r r r datos m in-band, out-band centralizado vs. descentralizado stateless vs. stateful Transferencia de mensajes confiables vs. no confiables “complejidad en el borde de la red” seguridad: autenticación Capa de Aplicaciones 110
- Intervalos automaticos o manuales en power point
- Adaptada de livro aberto
- Texto-base adaptada universidade federal de alagoas ufal
- Atividade adaptada de porcentagem
- Constancias escritas de operaciones comerciales
- éric está deprimido. cierto falso
- Aplicaciones mas usadas en argentina
- Pentoxido de diodo
- Pila redox
- Materiales compuestos aplicaciones
- Borato de galio
- Aplicaciones de la ley de ohm
- Derivadas vida cotidiana
- óxido-reducción ejemplos
- Aplicaciones de la derivada concepto
- Principio de trabajos virtuales
- Aplicaciones de la espectrometría de masas
- Resortes belleville aplicaciones
- Aplicaciones de la pnl
- Aplicaciones de la termodinámica
- Teorema de valor absoluto
- Aplicaciones tecnologicas
- Aplicaciones de transporte privado
- Aplicaciones de la elasticidad
- Aplicaciones de los materiales ferrosos
- Scaner
- Aplicaciones del cloro
- Aplicaciones de las funciones lineales
- Propiedades logaritmicas y exponenciales
- Fosfoacilglicerol
- Aplicaciones de las redes neuronales
- Uso del vanadio en la vida cotidiana
- Integrales impropias aplicaciones
- Como funciona el plano inclinado
- Materiales compuestos aplicaciones
- Aplicaciones de control del sueño para enfermos de cáncer
- El principio de arquímedes
- Competencia comunicativa y sus aplicaciones
- Integrales
- Xfinita
- Efecto fotoelectrico
- Aplicaciones del principio de pascal
- Evaporador de tubo vertical
- Aplicaciones del eter
- Que es el magnetismo
- 5 ejemplos de la raíz cuadrada en la vida cotidiana
- Lazo en grafos
- Caracteristicas
- Aplicaciones logica difusa
- Elementos del bloque d
- Ejemplos de regresión lineal simple en la vida cotidiana
- Aplicaciones de ecuaciones diferenciales de primer orden
- Sensor magnetoresistivo
- Aplicaciones del lenguaje ensamblador
- Desarrollo de aplicaciones web con asp.net
- Aplicaciones de la electrólisis
- Aplicaciones de la polarimetria
- Multivibrador monoestable aplicaciones
- Taller sobre aplicaciones en la administración
- Aplicaciones de la regresión lineal simple
- Espira
- Plano inclinado dinamica
- Aplicaciones de la energía eólica
- Capa certification exam
- Abnt referencia bibliografica
- Donde encontramos el ozono
- Capa 4
- Cisura de ronaldo
- Modelo cliente servidor
- Kentucky nursing license
- Capa tool
- Lon capa ostfalia
- Robert capa photographer biography
- Capa
- Capa 5 whys
- Lon capa ohio
- Capa neuroepitelial
- Capa pain assessment tool
- Musculos de la primera capa del pie
- Conductillos dentinarios
- Que es la estructura de la tierra
- Capa de mezcla
- Windchill 10
- Capa
- Rca and capa of medication error
- Capa osi
- Oraciones con capa de ozono
- Kentucky board of nursing
- Capa uga
- Capa transporte
- Capa monitoring
- Adventicia tejido conectivo
- Capa lean
- Capa de telecomunicaciones
- Loncapa gwu
- Cual es la capa mas gruesa de la geosfera
- Halimbawa ng duplo sa panahon ng kastila
- Las capas de la tierra
- Servicios de la capa de transporte
- The falling soldier robert capa
- Zonas de la piel delgada gruesa y sensible
- Capa de huxley
- Capa de distribucion
- Capa
- Capa asphalt
- Capa externa del trofoblasto
- Capa risk matrix
- Capa de peregrino
- Streliť capa význam
- Peter harbison capa
- Steven splevins