La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Capa de Aplicaciones1 Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer Networking: A Top Down Approach Featuring the Internet, 2 nd.

Presentaciones similares


Presentación del tema: "Capa de Aplicaciones1 Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer Networking: A Top Down Approach Featuring the Internet, 2 nd."— Transcripción de la presentación:

1 Capa de Aplicaciones1 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.

2 Capa de Aplicaciones2 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 cliente- servidor m Paradigma peer-to-peer r Aprender sobre protocolos al examinar los protocolos de aplicaciones comunes de Internet m SMTP / POP3 / IMAP m HTTP m FTP m XMPP m DNS m LDAP r Programar aplicaciones de red m El API socket

3 Capa de Aplicaciones3 Contenido r Principios de los protocolos de la capa de aplicaciones m Clientes y servidores m Requerimientos de las aplicaciones r Correo electrónico m SMTP, POP3 e IMAP r Web m HTTP r Transferencia de archivos m FTP r Mensajería instantánea m XMPP r Servicio de nombres de dominio m DNS r Servicio de directorio m LDAP r Programación con Sockets m TCP m UDP r Construyendo un servidor Web

4 Capa de Aplicaciones4 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. r Dentro del mismo host, dos procesos se comunican utilizando comunicación entre procesos (definido por el sistema operativo). r 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. r Implementa la interfaz de usuario y el protocolo de la capa de aplicación m Cliente Web: browser m Cliente lector de correo m Cliente de mensajería instantánea: IM client m Cliente streaming audio/video: media player

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

6 Capa de Aplicaciones6 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, KaZaA

7 Capa de Aplicaciones7 Paradigma cliente-servidor Las aplicaciones de red típicas tienen dos partes: el cliente y el servidor aplicación transporte red enlace física aplicación transporte red enlace física Cliente: 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; en el lector de correo solicitud respuesta 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

8 Capa de Aplicaciones8 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 El proceso que envía empuja el mensaje hacia afuera m 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á proceso TCP con buffers, variables socket host o servidor proceso TCP con buffers, variables socket host o servidor Internet controlado por OS Controlado por el desarrollador r API: (1) selección del protocolo de la capa de transporte; (2) habilidad para fijar unos pocos parámetros (se estudiará luego)

9 Capa de Aplicaciones9 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 IPv4, 128 bits en IPv6) 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 Servidor HTTP: 80 m Servidor de correo: 25 r Se estudiará luego

10 Capa de Aplicaciones10 ¿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

11 Capa de Aplicaciones11 Requerimientos de servicios de transporte de aplicaciones comunes Aplicación Transferencia de archivos Correo Documentos web audio/video en tiempo real audio/video almacenado Juegos interactivos Mensajería instantánea Pérdida de Datos No Tolerante No Ancho de Banda elástico audio: 5kbps-1Mbps video:10kbps-5Mbps El mismo anterior Algunos kbps elástico Sensitivo al tiempo no sí, 100s ms sí, pocos s sí, 100s ms sí y no

12 Capa de Aplicaciones12 Servicios de los protocolos de transporte de Internet Servicio de TCP: r Orientado a conexión: se debe establecer una conexión entre los procesos cliente y servidor r Transporte confiable entre el proceso emisor y el proceso receptor r Control de flujo: el emisor no debe saturar al receptor r Control de congestión: el emisor debe moderarse cuando la red esté sobrecargada r 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

13 Capa de Aplicaciones13 Aplicaciones de Internet: aplicación, protocolos de transporte Aplicación Acceso remoto Web Transferencia de archivos streaming multimedia Telefonía Internet Protocolo de la capa de aplicación SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietario (RealNetworks) proprietary (Dialpad) Protocolo de la capa de transporte TCP TCP o UDP normalmente UDP

14 Capa de Aplicaciones14 Correo electrónico Tres componentes principales: r Agentes de usuario r Servidores de correo r Protocolo simple de transferencia de correo: SMTP Agente de usuario 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 Buzón del usuario Cola de mensajes salientes Servidor de correo Agente de usuario Agente de usuario Agente de usuario Servidor de correo Agente de usuario Agente de usuario servidor de correo Agente de usuario SMTP

15 Capa de Aplicaciones15 Correo electrónico: servidores de correo Servidores de correo r buzón contiene los mensajes que han llegado para el usuario r Cola de mensajes 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 Servidor de correo Agente de usuario Agente de usuario Agente de usuario Servidor de correo Agente de usuario Agente de usuario servidor de correo Agente de usuario SMTP

16 Capa de Aplicaciones16 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

17 Capa de Aplicaciones17 Escenario: Alicia envía un mensaje a Beto 1) Alicia utiliza su agente de usuario para elaborar un mensaje para 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 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 Agente de usuario Servidor de correo Servidor de correo Agente de usuario

18 Capa de Aplicaciones18 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: S: 250 Sender ok C: RCPT TO: S: 250 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 Capa de Aplicaciones19 Interacción SMTP hecha a mano : 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

20 Capa de Aplicaciones20 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 El servidor SMTP utiliza CRLF.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

21 Capa de Aplicaciones21 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, m To: m From: m Subject: ¡Son diferentes a los comandos SMTP! r Cuerpo (body) m Es el mensaje, sólo permite caracteres ASCII header body Línea en blanco

22 Capa de Aplicaciones22 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 From: To: Subject: Imagen de un crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data Tipo de dato multimedia, subtipo, parámetro de declaración Método utilizado para codificar datos Versión de MIME Datos codificados

23 Capa de Aplicaciones23 Tipos MIME Content-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 r Datos que deben ser procesados por el cliente antes de poderse ver Ejemplo de subtipos: msword, octet-stream

24 Capa de Aplicaciones24 Tipo Multipart From: To: Subject: Imagen de un crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --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 Capa de Aplicaciones25 Protocolos de acceso al correo 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. Agente de usuario Servidor de correo del remitente Agente de usuario SMTP Protocolo de Acceso Servidor de correo del destinatario

26 Capa de Aplicaciones26 Protocolo POP3 Fase de autorización r Comandos del cliente: user: nombre de usuario pass: la clave r Respuestas del servidor m +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: t ermina la sesión C: list S: S: S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user beto S: +OK C: pass goloso S: +OK user successfully logged on

27 Capa de Aplicaciones27 POP3 e IMAP Más sobre POP3 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 POP3 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

28 Capa de Aplicaciones28 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: Nombre del host Nombre del path

29 Capa de Aplicaciones29 Panorámica de HTTP 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 PC ejecutando IE Explorer Servidor ejecutando El servidor Web Apache Mac ejecutando Netscape Navigator Solicitud HTTP Respuesta HTTP

30 Capa de Aplicaciones30 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 ¡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 NOTA

31 Capa de Aplicaciones31 Conexiones HTTP 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

32 Capa de Aplicaciones32 HTTP No persistente Supongamos que el usuario ingresa el URL 1a. El cliente HTTP inicia la conexión TCPal servidor HTTP (el proceso) en en el puerto 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 1b. El servidor HTTP en el host 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 tiempo (contiene texto, referencia a 10 imágenes jpeg)

33 Capa de Aplicaciones33 HTTP No persistente (cont.) 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 6. Los pasos 1 a 5 se repiten para cada uno de los 10 objetos jpeg 4. El servidor HTTP cierra la conexión TCP. tiempo

34 Capa de Aplicaciones34 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 = 2RTT+tiempo de transmisión tiempo para transmitir archivo Inicia Conexión TCP RTT solicita archivo RTT archivo recibido tiempo

35 Capa de Aplicaciones35 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

36 Capa de Aplicaciones36 Mensaje de solicitud HTTP r HTTP tiene dos tipos de mensajes: request, response r Mensaje de solicitud: m ASCII (formato legible para nosotros) GET /algundir/pagina.html HTTP/1.1 Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr (carriage return, line feed adicional) Línea de solicitud (comandos GET, POST, HEAD) Líneas de encabezado Carriage return, line feed Indica el final del mensaje

37 Capa de Aplicaciones37 Mensaje de solicitud HTTP: formato general

38 Capa de Aplicaciones38 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

39 Capa de Aplicaciones39 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

40 Capa de Aplicaciones40 Mensaje de respuesta de HTTP HTTP/ OK Connection close Date: Thu, 06 Aug :00:15 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ínea de estado (código de estado del Protocolo, frase de estado) Líneas de encabezado datos, es decir, archivo HTML solicitado

41 Capa de Aplicaciones41 Códigos de estado de HTTP 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 Se usan en la primera línea del mensaje de respuesta del servidor->cliente. Ejemplos:

42 Capa de Aplicaciones42 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 Cualquier cosa que se digite será enviada Al puerto 80 en telnet Digite una solicitud de HTTP con el método GET: GET /index.html HTTP/1.0 Al digitar esto (y oprimir 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!

43 Capa de Aplicaciones43 Interacción usuario-servidor: autorización Autorización : control de acceso al contenido del servidor r Credenciales de autorización: normalmente un nombre y una clave (password) r 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 cliente servidor Solicitud http usual 401: authorization req. WWW authenticate: Solicitud http usual + Autorización: Respuesta http usualSolicitud http usual + Autorización: Respuesta http usual tiempo

44 Capa de Aplicaciones44 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 Susana siempre accede Internet desde el mismo PC m Ella visita un sitio de e- commerce específico por primera vez m 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 Capa de Aplicaciones45 Cookies: guardando el estado (cont.) cliente servidor Solicitud http usual Respuesta http usual + Set-cookie: 1678 Solicitud http usual cookie: 1678 Respuesta http usual Solicitud http usual cookie: 1678 Respuesta http usual Acción específica para cookie Acción específica para cookie El servidor crea el ID 1678 para el usuario Registro en la Base de datos backend acceso Archivo Cookie amazon: 1678 ebay: 8734 Archivo Cookie ebay: 8734 Archivo Cookie amazon: 1678 ebay: 8734 Una semana después:

46 Capa de Aplicaciones46 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 ) Cookies y privacidad: r Las cookies permiten a los sitios aprender muchas cosas sobre usted r Usted puede suministrar su nombre y su 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 NOTA

47 Capa de Aplicaciones47 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: r servidor: La respuesta no lleva el objeto si la copia en cache está actualizada: HTTP/ Not Modified cliente servidor Solicitud HTTP If-modified-since: Respuesta HTTP HTTP/ Not Modified objeto no modificado Solicitud HTTP If-modified-since: Respuesta HTTP HTTP/ OK objecto modificado

48 Capa de Aplicaciones48 FTP: protocolo de transferencia de archivos r Transfiere archivos hacia y desde el host remoto r Usa el modelo cliente/servidor m client: quien inicia la transferencia (para transferir hacia/desde el host remoto) m server: host remoto r ftp: RFC 959, RFC1123 r Servidor ftp: puertos 21 y 20 Transferencia del archivo Servidor FTP Interface para usuario FTP Cliente FTP Sistema de archivos local Sistema de archivos remoto usuario

49 Capa de Aplicaciones49 FTP: control separado de la conexión para datos r El cliente FTP contacta el servidor FTP en el puerto 21, especificamdo TCP como protocolo de transporte r El cliente obtiene autorización sobre la conexión de control r El cliente permite listar el directorio remoto al enviar comandos sobre la conexión de control. r Cuando el servidor recibe una comando para transferir un archivo, el servidor abre una conexión TCP para datos con el cliente r Después de transferir el archivo, el servidor cierra la conexión. Cliente FTP Servidor FTP Puerto 21, conexión TCP de control Puerto 20, conexión TCP para datos 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

50 Capa de Aplicaciones50 Comandos y respuestas FTP Algunos comandos: r 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 r Utiliza un código de estado y una frase (como en HTTP) r 331 Username OK, password required r 125 data connection already open; transfer starting r 425 Cant open data connection r 452 Error writing file

51 Capa de Aplicaciones51 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, iChat, 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).

52 Capa de Aplicaciones52 Mensajería instantánea y XMPP r 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. r Pocos años después, AOL logró dos patentes para mensajería instantánea en los EE.UU. r 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. r 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 r Los servidores de Jabber pueden actuar como gateways a otros protocolos de IM, reduciendo la necesidad de tener varios clientes. r 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 Capa de Aplicaciones53 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 (VoIP) y web conferencing. m Los servicios de Web conferencing integran video conferencia y mensajería instantánea. m 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.

54 Capa de Aplicaciones54 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 (server- to-server) Cliente XMPP Gateway Traduce entre XMPP y NO-XMPP Cliente XMPP Servidor XMPP Servidor XMPP Cliente XMPP Servidor IM NO-XMPP Cliente NO- XMPP

55 Capa de Aplicaciones55 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.

56 Capa de Aplicaciones56 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 (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, puede intercambiar mensajes, presencia y otra información con (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

57 Capa de Aplicaciones57 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 = m m

58 Capa de Aplicaciones58 DNS: Domain Name System Las personas: tienen muchos identificacdores: m Cédula, nombre, pasaporte Identificadores de host y routers de Internet: m La dirección IP (32 bits) – utilizada para direccionar datagramas m 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

59 Capa de Aplicaciones59 Servidores de nombres DNS r Ningún servidor tiene todas las asociaciones nombre a IP Servidores de nombres locales: m cada ISP o compañía tiene un local (default) name server m Las consultas que realizan los nodos primero se hacen con el local name server Servidor de nombres autorizado: m Para un host: almacena la dirección IP y el nombre de ese host m Puede hacer la traducción de nombre a dirección IP para ese host ¿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 ¡ NO PUEDE ESCALAR !

60 Capa de Aplicaciones60 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 b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo 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 13 servidores raíz en el mundo

61 Capa de Aplicaciones61 Ejemplo Simple de DNS 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 Nodo que consulta surf.eurecom.fr gaia.cs.umass.edu DNS raíz DNS autoritativo dns.umass.edu DNS local dns.eurecom.fr

62 Capa de Aplicaciones62 Ejemplo de DNS 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 Nodo que consulta surf.eurecom.fr gaia.cs.umass.edu DNS Raíz DNS local dns.eurecom.fr DNS autoritativo dns.cs.umass.edu DNS intermedio dns.umass.edu 7 8

63 Capa de Aplicaciones63 DNS: consultas iterativas Consulta recursiva: 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 Nodo que consulta surf.eurecom.fr gaia.cs.umass.edu DNS raíz DNS local dns.eurecom.fr DNS autoritativo dns.cs.umass.edu DNS intermedio dns.umass.edu 7 8 Consulta iterada

64 Capa de Aplicaciones64 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

65 Capa de Aplicaciones65 Registros del DNS DNS: registros de recursos (RR) almacenados en una base de datos distribuida r Type=NS name es un dominio (por ejmplo. sitio.com) value es una dirección IP de un DNS autoritativo para este dominio Fromato RR: (name, value, type, ttl) r Type=A name es un nombre de hosts value es una dirección IP r Type=CNAME name es un alias para algún nombre canónico (el nombre real) es realmente servereast.backup2.ibm.com value es el nombre canónico r Type=MX value es el nombre de un servidor de correo asociado con name

66 Capa de Aplicaciones66 Protocolo DNS y mensajes DNS Protocolo DNS: mensajes de query y reply, juntos tienen el mismo formato de mensaje 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 identificaciónflags número de consultasnúmero de RRs respondidos Número de RRs autoritativosNúmero de RRs adicionales 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) 12 bytes

67 Capa de Aplicaciones67 Protocolo DNS y mensajes DNS Nombre, campos tipo Para una consulta RRs en respuesta A una consulta Registros para servidores autoritativos Información adicional útil que puede usarse identificaciónflags 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 (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)

68 Capa de Aplicaciones68 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 Está optimizado para leer m Implementa un modelo distribuido para almacenar información m Puede extender el tipo de información que almacena. m Tiene capacidades de búsqueda avanzadas. m 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).

69 Capa de Aplicaciones69 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.

70 Capa de Aplicaciones70 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 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 Capa de Aplicaciones71 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 Modelo de información: estructuras y tipos de datos necesarios para construir un árbol de directorio LDAP m Modelo de nombres: define como las entradas y y los datos son refernciados de manera única en el DIT (Directory Information Tree) m Modelo funcional: Es el protocolo LDAP m 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 Capa de Aplicaciones72 Capítulo 2: contenido r 2.1 Principios de los protocolos de la capa de aplicaciones m Clientes y servidores m Requerimientos de las aplicaciones r 2.2 Web y HTTP r 2.3 FTP r 2.4 Correo electrónico m SMTP, POP3 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 Caching de web en la red m Redes de distribución de contenido m Archivos compartidos P2P

73 Capa de Aplicaciones73 Programación con sockets El API Socket r Distribuido en el UNIX BSD4.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) 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 socket Meta: aprender cómo construir aplicaciones cliente/servidor que se comuniquen utilizando sockets

74 Capa de Aplicaciones74 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 proceso TCP con buffers, variables socket controlado por el desarrollador de la aplicación controlado por el sistema operativo host o servidor proceso TCP con buffers, variables socket controlado por el desarrollador de la aplicación controlado por el sistema operativo host o servidor internet

75 Capa de Aplicaciones75 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) TCP permite transferir bytes de manera confiable, en orden (un tubo), entre el cliente Y el servidor Para la aplicación…

76 Capa de Aplicaciones76 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.

77 Capa de Aplicaciones77 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 Capa de Aplicaciones78 Interacción de sockets en cliente/servidor: TCP espera solicitudes de conexión connectionSocket = welcomeSocket.accept() crea socket, port= x, para recibir solicitudes: welcomeSocket = ServerSocket() crea socket, se conecta a hostid, port= x clientSocket = Socket() cierra connectionSocket lee respuestas de clientSocket cierra clientSocket Servidor (ejecutando en hostid ) Cliente envía solicitudes usando clientSocket lee solicitudes desde connectionSocket escribe las respuestas en connectionSocket establece conexión TCP cierra conexión TCP

79 Capa de Aplicaciones79 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 Capa de Aplicaciones80 Ejemplo: Cliente Java (TCP), cont. 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(); } Crea input stream asociado al socket Envía la línea al servidor Lee la línea desde el servidor

81 Capa de Aplicaciones81 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 Capa de Aplicaciones82 Ejemplo: Servidor Java (TCP), cont. DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Lee la línea desde el socket Crea output stream, asociado al socket Escribe la línea al socket Fin del ciclo while, regresa al inicio del ciclo y espera otra conexión de cliente

83 Capa de Aplicaciones83 Capítulo 2: contenido r 2.1 Principios de los protocolos de la capa de aplicaciones m Clientes y servidores m Requerimientos de las aplicaciones r 2.2 Web y HTTP r 2.3 FTP r 2.4 Correo electrónico m SMTP, POP3 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 Caching de web en la red m Redes de distribución de contenido m Archivos compartidos P2P

84 Capa de Aplicaciones84 Programando sockets con UDP 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 UDP: los datos transmitidos pueden ser recibidos fuera de orden o pueden ser perdidos Para la aplicación… UDP transfiere de manera no confiable grupos de bytes (datagramas) entre el cliente y el servidor

85 Capa de Aplicaciones85 Interacción de sockets en cliente/servidor: UDP cierra clientSocket Servidor (ejecutando en hostid ) Lee la respuesta desde clientSocket crea socket, clientSocket = DatagramSocket() Cliente Crea, asocia dirección ( hostid, port=x) envía datagrama de solicitud usando clientSocket crea socket, port= x, para recibir solicitudes: serverSocket = DatagramSocket() Lee la solicitud desde serverSocket Escribe la respuesta en serverSocket Especificando la dirección IP del cliente y el número de puerto

86 Capa de Aplicaciones86 Ejemplo: Cliente Java (UDP) Output: envía paquetes (TCP envía byte stream) Input: recibe paquetes (TCP recibe byte stream) Proceso cliente client UDP socket

87 Capa de Aplicaciones87 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 byte[1024]; byte[] receiveData = new byte[1024]; 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 Capa de Aplicaciones88 Ejemplo: Cliente Java (UDP), cont. DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Crea datagrama con la longitud de datos- a-enviar, dirección IP, puerto Envía datagrama al servidor Lee datagrama desde el servidor

89 Capa de Aplicaciones89 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 byte[1024]; byte[] sendData = new byte[1024]; 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 Capa de Aplicaciones90 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(sendPacket); } Consigue le dirección IP puerto #, del solicitante Escribe el datagrama en el socket Fin del ciclo while, regresa al inicio y espera otro datagrama Crea datagrama para envíar al cliente

91 Capa de Aplicaciones91 Construyendo un servidor Web simple r Maneja sólo una solicitud HTTP r Acepta la solicitud r Analiza el header r Obtiene el archivo solicitado desde el sistema de archivos del servidor r Crea el mensaje de respuesta HTTP: m Líneas de header + archivo r Envía la respuesta al cliente 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

92 Capa de Aplicaciones92 Programando sockets: referencias Tutorial para lenguaje C (audio/slides): r Unix Network Programming (J. Kurose), Tutoriales de Java: r All About Sockets (Sun tutorial), sockets.html r Socket Programming in Java: a tutorial, sockets.html

93 Capa de Aplicaciones93 Capítulo 2: contenido r 2.1 Principios de los protocolos de la capa de aplicaciones m Clientes y servidores m Requerimientos de las aplicaciones r 2.2 Web y HTTP r 2.3 FTP r 2.4 Correo electrónico m SMTP, POP3 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 Caching de web en la red m Redes de distribución de contenido m Archivos compartidos P2P

94 Capa de Aplicaciones94 Cache en Web (servidor proxy) 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 Si el objeto está en el cache: el cache retorna el objeto m 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 Meta: satisfacer las solicitudes del cliente sin involucrar el servidor origen cliente Servidor Proxy cliente Solicitud HTTP Respuesta HTTP RespuestaHTTP response Solicitud HTTP Respuesta HTTP Servidor origen Servidor origen

95 Capa de Aplicaciones95 Más sobre Web caching r 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 m Probelma: ¿el servidor de cache debería tomar el riesgo y entregar el objeto copiado en su disco sin hacer ninguna revisión? m 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

96 Capa de Aplicaciones96 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 Red institucional LAN a 10 Mbps Enlace de acceso 1.5 Mbps

97 Capa de Aplicaciones97 Ejemplo de Caching (2) Posible solución r Incrementar ancho de banda del enlace de acceso, digamos a 10 Mbps Consecuencias r Utilización de la LAN = 15% 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 + milisegundos r Generalmente una actualización costosa Servidores origen Internet pública Red institucional LAN a 10 Mbps Enlace de acceso 10 Mbps

98 Capa de Aplicaciones98 Ejemplo de Caching (3) Instalando servidor cahe r Supongamos que la tasa de hits es.4 Consecuencia r 40% de las solicitudes serán satisfechas casi inmediatamente r El 60% de las solicitudes serán satisfechas desde el servidor origen r La utilización del enlace de accesose reduce al 60%, lográndose retardos casi despreciables (diagmos 10 milisegundos) r 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 Servidores origen Internet pública Red institucional 10 Mbps LAN Enlace de acceso 1.5 Mbps Cache institucional

99 Capa de Aplicaciones99 Redes de distribución de contenido (CDNs) r Los proveedores de contenido son los clientes de las CDN. Replicación de contenido r Las CDN instalan cientos de 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 proveedor actualiza el contenido, la CDN actualiza los servidores Servidor origen en Norteamérica Nodo de distribución CDN Servidor CDN En Suarmérica Servjdor CDN en Europa Servidor CDN en Asia

100 Capa de Aplicaciones100 Ejemplo de CDN Servidor origen r r distribuye HTML r Reemplaza: con h ttp://www.cdn.com/www.foo.com/sports/ruth.gif Solicitud HTTP para Consulta DNS para Solicitud HTTP para Servidor origen Servidor DNS autoritativo Para las CDNs Servidor CDN cercano Compañía CDN r cdn.com r distribuye archivos gif r Utiliza su servidor DNS autoritativo para enrutar y redirigir las solicitudes

101 Capa de Aplicaciones101 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 ISP desde el cual se origina la consulta m 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 real- time m Los nodos CDN construyen una overlay network sobre la capa de aplicaciones

102 Capa de Aplicaciones102 Compartiendo archivos P2P Ejemplo r Alicia corre un cliente para una aplicación P2P 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. r Alicia selecciona uno de los 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!

103 Capa de Aplicaciones103 P2P: directorio centralizado Diseño original de Napster 1) Cuando un PC se conecta, este informa al servidor central: m Dirección IP m contenido 2) Alicia pregunta por Hey Jude 3) Alicia solicita el archivo desde Beto Servidor de directorio centralizado PCs (peers) Alicia Beto

104 Capa de Aplicaciones104 P2P: 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

105 Capa de Aplicaciones105 P2P: 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.

106 Capa de Aplicaciones106 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 El servicio de localización se distribuye en entre los PCs m 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

107 Capa de Aplicaciones107 P2P: inundación de consultas r Gnutella r No existen jerarquías r Utiliza un nodo bootstrap para aprender sobre los otros r Mensaje de asociación ( join message) r Envía la consulta a sus vecinos r Los vecinos reenvían la consulta r Si el PCs consultado tiene el objeto, este envía el mensaje de regreso al PC que hizo la consulta join

108 Capa de Aplicaciones108 P2P: 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

109 Capa de Aplicaciones109 Capítulo 2: resumen r Requerimientos de servicio de las aplicaciones: m confiabilidad, ancho de banda, delay r Paragdima cliente- servidor r Modelo de servicio de transporte de Internet m Orientado a conexión, confiable: TCP m No confiable, datagramas: UDP Nuestro estudio de aplicaciones de red se ha terminado! r Protocolos específicos: m HTTP m FTP m SMTP, POP, IMAP m DNS r Programación con sockets r Distribución de contenido m caches, CDNs m P2P

110 Capa de Aplicaciones110 Capítulo 2: resumen r Intercambio de mensajes solicitud/respuesta típico: m El cliente solicita información o el servicio m El servidor responde con datos, códigos de estado r Formatos de mensaje: m Encabezados: campos que dan información sobre los datos m datos: la información que está siendo transmitida Más importante: aprender sobre protocolos r control vs. mensajes de datos m in-band, out-band r centralizado vs. descentralizado r stateless vs. stateful r Transferencia de mensajes confiables vs. no confiables r complejidad en el borde de la red r seguridad: autenticación


Descargar ppt "Capa de Aplicaciones1 Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer Networking: A Top Down Approach Featuring the Internet, 2 nd."

Presentaciones similares


Anuncios Google