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

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

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

2 Capa de aplicaciones Metas:
Aspectos conceptuales de la implementación de los protocolos para las aplicaciones de red Modelos de servicio de la capa de transporte Paradigma cliente-servidor Paradigma peer-to-peer Aprender sobre protocolos al examinar los protocolos de aplicaciones comunes de Internet SMTP / POP3 / IMAP HTTP FTP XMPP DNS LDAP Programar aplicaciones de red El API socket Capa de Aplicaciones

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

4 Aplicaciones de red: algunos términos
Proceso: instancia de un programa que se ejecuta dentro de un nodo o contexto de ejecución de un programa que está corriendo. Dentro del mismo host, dos procesos se comunican utilizando comunicación entre procesos (definido por el sistema operativo). Los procesos que se ejecutan entre diferentes nodos lo hacen mediante un protocolo de la capa de aplicación Agente de usuario: interfaces con el usuario “arriba” y la red “abajo”. Implementa la interfaz de usuario y el protocolo de la capa de aplicación Cliente Web: browser Cliente lector de correo Cliente de mensajería instantánea: IM client Cliente streaming audio/video: media player Capa de Aplicaciones

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

6 Un protocolo de la capa de aplicaciones define…
Los tipos de mensajes intercambiados, es decir los mensajes de solicitud y los de respuesta La sintáxis de los tipos de mensaje: qué campos tendrá el mensaje y cómo se delimitan los campos La semántica de los campos, es decir, el significado de la información colocada en los campos Las reglas de cuándo y cómo los procesos envían o reciben mensajes Protocolos de dominio público: Definidos en RFCs Buscan interoperabilidad ejemplos, HTTP, SMTP Protocolos proprietarios: ejemplo, KaZaA Capa de Aplicaciones

7 Paradigma cliente-servidor
Las aplicaciones de red típicas tienen dos partes: el cliente y el servidor aplicación transporte red enlace física respuesta solicitud Cliente: Inicia el contacto con el servidor (“habla primero”) Normalmente solicita servicios desde el servidor, Web: el cliente está implementado en el browser; en el lector de correo Servidor: Proporciona el servicio solicitado por el cliente ejemplo, el servidor Web envía la página web solicitada, el servidor de correo entrega el mensaje de correo Capa de Aplicaciones

8 Los procesos se comunican a través de la red
TCP con buffers, variables socket host o servidor proceso TCP con buffers, variables socket host o servidor Los procesos envían/reciben mensajes hacia/desde su socket Un socket es análogo a una puerta El proceso que envía empuja el mensaje hacia afuera El proceso que envía asume que existe una infraestructura de transporte al otro lado de la puerta que llevará el mensaje hasta el socket del proceso que lo recibirá Controlado por el desarrollador Internet controlado por OS API: (1) selección del protocolo de la capa de transporte; (2) habilidad para fijar unos pocos parámetros (se estudiará luego) Capa de Aplicaciones

9 Direccionamiento de procesos:
Para que un proceso reciba mensajes, este debe tener un identificador Cualquier nodo en Internet tiene una dirección IP única (32 bits en IPv4, 128 bits en IPv6) Pregunta: ¿es suficiente con la dirección IP para identificar los procesos? Respuesta: No. Muchos procesos pueden ejectutarse en el mismo host El identificador de un proceso en Internet incluye tanto la dirección IP como el número de puerto asociado con el proceso dentro del host. Ejemplos de números de puerto “bien conocidos”: Servidor HTTP: 80 Servidor de correo: 25 Se estudiará luego Capa de Aplicaciones

10 ¿Qué servicios de transporte requiere una aplicación?
Pérdida de datos Algunas aplicaciones (por ejemplo, audio) pueden tolerar alguna pérdida otras aplicaciones (ftp, telnet) requieren una confiabilidad del 100% al transferir datos Ancho de Banda Algunas aplicaciones (multimedia) requieren un mínimo en la cantidad de ancho de banda para ser “efectivas” otras aplicaciones (“aplicaciones elásticas”) utilizan el ancho de banda que encuentren Control preciso de tiempo Algunas aplicaciones (telefonía Internet, juegos interactivos) requieren poco retardo para que sean “efectivas” Capa de Aplicaciones

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

12 Servicios de los protocolos de transporte de Internet
Servicio de TCP: Orientado a conexión: se debe establecer una conexión entre los procesos cliente y servidor Transporte confiable entre el proceso emisor y el proceso receptor Control de flujo: el emisor no debe “saturar” al receptor Control de congestión: el emisor debe moderarse cuando la red esté “sobrecargada” No ofrece: ni control de tiempos, ni garantiza un mínimo ancho de banda Servicio de UDP: Transferencia de datos no confiable entre el proceso emisor y el receptor NO ofrece: establecimiento de conexión, confiabilidad, control de flujo, control de congestión, control de tiempo, o garantía de ancho de banda mínimo Capa de Aplicaciones

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

14 Correo electrónico SMTP SMTP SMTP Tres componentes principales:
Buzón del usuario Cola de mensajes salientes Agente de usuario Tres componentes principales: Agentes de usuario Servidores de correo Protocolo simple de transferencia de correo: SMTP Agente de usuario Conocido como “lector de correo” Permite elaborar, editar y leer mensajes de correo. Ejemplos: Eudora, Outlook, elm, Netscape Messenger Recupera los mensajes colocados en el servidor servidor de correo Agente de usuario SMTP Servidor de correo Agente de usuario SMTP Servidor de correo SMTP Agente de usuario Agente de usuario Agente de usuario Capa de Aplicaciones

15 Correo electrónico: servidores de correo
Agente de usuario Servidores de correo buzón contiene los mensajes que han llegado para el usuario Cola de mensajes mensajes de correo salientes (para ser enviados) Protocolo SMTP usado entre los servidores de correo para enviar los mensajes Se comporta como cliente SMTP: cuando envia correo a otro servidor de correo Se comporta como “servidor”: cuando recibe correo de otro servidor de correo servidor de correo Agente de usuario SMTP Servidor de correo Agente de usuario SMTP Servidor de correo SMTP Agente de usuario Agente de usuario Agente de usuario Capa de Aplicaciones

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

17 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 Servidor de correo Servidor de correo 1 Agente de usuario Agente de usuario 2 3 6 4 5 Capa de Aplicaciones

18 Ejemplo de la interacción SMTP
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 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 Capa de Aplicaciones

19 Interacción SMTP hecha “a mano” :
telnet nombre_servidor 25 Se observa el código 220 como respuesta del servidor Se digitan los comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT Lo anterior le permite enviar un mensaje de correo electrónico sin utilizar el cliente de correo Capa de Aplicaciones

20 SMTP: palabras finales
SMTP utiliza conexiones persistentes (como el HTTP persistente) SMTP obliga a que el mensaje (encabezado & cuerpo) estén en ASCII de 7 bits El servidor SMTP utiliza CRLF.CRLF para “decir” donde está el final del mensaje Comparación con HTTP: HTTP: protocolo pull (halar) SMTP: protocolo push (empujar) Los dos protocolos interactuan mediante comandos/respuestas en ASCII y códigos de status HTTP: cada objeto se “encapsula” en su propio mensaje de respuesta SMTP: multiples objectos se envían en un mensaje “multiparte” Capa de Aplicaciones

21 Formato del mensaje de correo
SMTP: protocolo para intercambio de mensajes de correo RFC 822: estándar para el formato de mensajes de texto: Líneas de header, es decir, To: From: Subject: ¡Son diferentes a los comandos SMTP! Cuerpo (body) Es el “mensaje”, sólo permite caracteres ASCII header Línea en blanco body Capa de Aplicaciones

22 Formato del mensaje: extensiones para multimedia
MIME: Multimedia Internet Mail Extension, RFC 2045, 2056 Líneas adicionales en el header del mensaje declaran contenido tipo MIME 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 Versión de MIME Método utilizado para codificar datos Tipo de dato multimedia, subtipo, parámetro de declaración Datos codificados Capa de Aplicaciones

23 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 Datos que deben ser procesados por el cliente antes de “poderse ver” Ejemplo de subtipos: msword, octet-stream Capa de Aplicaciones

24 Tipo Multipart From: alicia@crepes.fr To: beto@hamburger.edu
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. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data ¿te gustaría tener la receta? Capa de Aplicaciones

25 Protocolos de acceso al correo
SMTP SMTP Protocolo de Acceso Agente de usuario Agente de usuario Servidor de correo del remitente Servidor de correo del destinatario SMTP: entrega al servidor de correo del receptor Protocolo de acceso al correo: recupera los mensajes desde el servidor POP: Post Office Protocol [RFC 1939] autorización (agente <-->servidor) y descarga los mensajes IMAP: Internet Mail Access Protocol [RFC 1730] Más características (más complejo) manipulación de los mensajes almacenados en el servidor HTTP: Hotmail , Yahoo! Mail, etc. Capa de Aplicaciones

26 Protocolo POP3 Fase de autorización C: list
S: +OK POP3 server ready C: user beto S: +OK C: pass goloso S: +OK user successfully logged on Fase de autorización Comandos del cliente: user: nombre de usuario pass: la clave Respuestas del servidor +OK -ERR Fase de transacción, cliente: list: lista los números de los mensajes retr: recupera el mensaje por el número dele: borra el mensaje quit: termina la sesión C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> C: dele 1 C: retr 2 C: dele 2 C: quit S: +OK POP3 server signing off Capa de Aplicaciones

27 POP3 e IMAP Más sobre POP3 IMAP
El ejemplo anterior utiliza el modo “descargue y borre”. Beto no puede volver a leer un mensaje si se cambia de cliente “Descargue y guarde”: copias de los mensajes en diferentes clientes POP3 no mantiene información de sesiones anteriores (stateless) IMAP Mantiene todos los mensajes en el mismo lugar: el servidor Permite al usuario que organice sus mensajes en fólderes IMAP mantiene información de estado de sesiones anteriores: Nombres de fólderes y “mapeo” entre la identificación de los mensajes y el nombre de los fólderes Capa de Aplicaciones

28 Web y HTTP Algunos términos Una página Web consta de objetos
Los objetos pueden ser un archivo HTML, una imagen JPEG, un applet Java, un archivo de audio,… Una página Web consta de un archivo HTML base que incluye diversos objetos referenciados Cada objeto se direcciona con un URL Ejemplo de un URL: Nombre del host Nombre del path Capa de Aplicaciones

29 Panorámica de HTTP HTTP: protocolo de transferencia de hipertexto
Es el protocolo de la capa de aplicación para el Web Usa el modelo cliente/servidor cliente: browser o navegador que solicita, recibe y muestra los objetos Web servidor: Servidor www que envía objetos en respuesta a las solicitudes del browser HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 Solicitud HTTP PC ejecutando IE Explorer Respuesta HTTP Solicitud HTTP Servidor ejecutando El servidor Web Apache Respuesta HTTP Mac ejecutando Netscape Navigator Capa de Aplicaciones

30 Panorámica de HTTP (continuación)
Utiliza TCP: El cliente inicia la conexión TCP (crea el socket) al servidor, puerto 80 El servidor acepta la conexión TCP solicitada por cliente Los mensajes HTTP (mensajes del protocolo de la capa de aplicación) se intercambian entre el browser (cliente HTTP) y el servidor Web (servidor HTTP) Se cierra la conexión TCP HTTP es “stateless” El servidor no mantiene información sobre las solicitudes anteriores del cliente NOTA ¡Los protocolos que mantienen información de estado son complejos! La historia pasada (estado) debe guardarse Si el servidor o el cliente fallan, sus “imágenes” del estado de la sesión pueden ser inconsistentes y deben “reconciliarlas” Capa de Aplicaciones

31 Conexiones HTTP HTTP no persistente
Al menos un objeto es enviado sobre una conexión TCP. HTTP/1.0 utiliza HTTP no persistente HTTP persistente Multiples objetos pueden ser enviados sobre una misma conexión TCP entre el cliente y el servidor. HTTP/1.1, por omisión, utiliza conexiones persistentes Capa de Aplicaciones

32 HTTP No persistente (contiene texto, referencia a 10 imágenes jpeg) Supongamos que el usuario ingresa el URL 1a. El cliente HTTP inicia la conexión TCPal servidor HTTP (el proceso) en en el puerto 80 1b. El servidor HTTP en el host espera conexiones TCP en el puerto 80. Cuando “acepta” una conexión, notifica al cliente 2. El cliente HTTP envía un request message (que contiene el URL) hacia su socket de conexión TCP. El mensaje indica que el cliente desea el objeto algunaFacultad/index.html 3. El servidor HTTP recibe el mensaje de solicitud, construye un response message que contiene el objeto solicitado, y envía el mensaje hacia su socket tiempo Capa de Aplicaciones

33 HTTP No persistente (cont.)
4. El servidor HTTP cierra la conexión TCP. 5. El cliente HTTP recibe el mensaje de repuesta que contiene el archivo html, muestra el html. Al recorrer el archivo html encuentra 10 objetos jpeg referenciados tiempo 6. Los pasos 1 a 5 se repiten para cada uno de los 10 objetos jpeg Capa de Aplicaciones

34 Modelamiento del tiempo de respuesta
Definición de RRT: tiempo para enviar un pequeño paquete y que este viaje desde el cliente hasta el servidor y que regrese. Tiempo de respuesta: Un RTT para iniciar la conexión TCP Un RTT para la solicitud HTTP y para que los primeros bytes de la respuesta HTTP regresen Tiempo de transmisión del archivo total = 2RTT+tiempo de transmisión tiempo para transmitir archivo Inicia Conexión TCP RTT solicita recibido tiempo Capa de Aplicaciones

35 HTTP Persistente Aspectos de HTTP No persistente:
requiere 2 RTTs por objeto El OS debe trabajar y asignar los recursos del host para cada conexión TCP En ocasiones un browser abre conexiones TCP paralelas para traer los objetos referenciados HTTP persistente El servidor deja la conexión abierta después de enviar el mensaje de respuesta Los mensajes HTTP que siguen entre el cliente/servidor son enviados sobre la misma conexión TCP Persistencia sin pipelining: El cliente emite una nueva solictud sólo cuando la respuesta anterior ha sido recibida Se requiere un RTT para cada objeto referenciado Persistencia con pipelining: Por omisión en HTTP/1.1 El cliente envía una solicitud tan pronto como encuentra un objeto referenciado Se requiere apenas como un RTT para TODOS los objetos referenciados Capa de Aplicaciones

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

37 Mensaje de solicitud HTTP: formato general
Capa de Aplicaciones

38 Enviando datos al servidor desde un formulario HTML
Usando el método POST: Las páginas web incluyen a menudo formularios para ingresar datos Los datos ingresados en el formulario son “subidos” o enviados al servidor a través del cuerpo del mensaje (Entity Body) Usando el URL: Utiliza el método GET Los datos ingresados son enviados en el campo del URL de la línea de solicitud Capa de Aplicaciones

39 Tipos de métodos HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT
Hace una consulta al servidor sobre las características del objeto, pero no transfiere el objeto HTTP/1.1 GET, POST, HEAD PUT Envía un archivo en el cuerpo del mensaje al path especificado en el URL DELETE Borra el archivo especificado en el URL Capa de Aplicaciones

40 Mensaje de respuesta de HTTP
Línea de estado (código de estado del Protocolo, frase de estado) 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íneas de encabezado datos, es decir, archivo HTML solicitado Capa de Aplicaciones

41 Códigos de estado de HTTP
Se usan en la primera línea del mensaje de respuesta del servidor->cliente. Ejemplos: 200 OK Solicitud exitosa, el objeto solicitado va en este mensaje 301 Moved Permanently El objeto solicitado fue movido, la nueva ubicación se especifica posteriormente en este mensaje (Location:) 400 Bad Request El mensaje de solicitud no fue entendido por el servidor 404 Not Found El documento solicitado no se encontró en este servidor 505 HTTP Version Not Supported Capa de Aplicaciones

42 Conexión HTTP (cliente) hecha “a mano”
1. Conéctese, a través de telnet al puerto 80, a su sitio Web favorito: telnet 80 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 2. Digite una solicitud de HTTP con el método GET: Al digitar esto (y oprimir <ENTER> dos veces), se enviará esta solicitud HTTP mínima (pero completa) al servidor HTTP GET /index.html HTTP/1.0 3. ¡Observe el mensaje de respuesta enviado por el servidor HTTP! Capa de Aplicaciones

43 Interacción usuario-servidor: autorización
Autorización : control de acceso al contenido del servidor Credenciales de autorización: normalmente un nombre y una clave (password) stateless: el cliente debe presentar la autorización cada vez que haga una solicitud autorización: línea del header en cada solicitud Si no tiene la línea autorización: el servidor rechaza el acceso, y envía la línea de header WWW authenticate: En respuesta cliente servidor Solicitud http usual 401: authorization req. WWW authenticate: Solicitud http usual + Autorización: <cred> Respuesta http usual Solicitud http usual + Autorización: <cred> tiempo Respuesta http usual Capa de Aplicaciones

44 Cookies: guardando el “estado”
Muchos sitios Web utilizan cookies Cuatro componentes: 1) Línea de header “cookie:” en el mensaje de respuesta HTTP 2) Línea de header “cookie:” en el mensaje de solicitud 3) El archivo de la “cookie” es almacenado en el nodo del usuario y es administrado por el browser del usuario 4) La base de datos está en el back-end del sitio Web Ejemplo: Susana siempre accede Internet desde el mismo PC Ella visita un sitio de e-commerce específico por primera vez Cuando la solicitud HTTP inicial llega al sitio, el sitio crea un identificador único y crea un registro en la base de datos backend para esa identificación Capa de Aplicaciones

45 Cookies: guardando el “estado” (cont.)
cliente servidor Solicitud http usual Respuesta http usual + Set-cookie: 1678 cookie: 1678 Respuesta http usual Acción específica para cookie Archivo Cookie ebay: 8734 El servidor crea el ID 1678 para el usuario Registro en la Base de datos backend Archivo Cookie amazon: 1678 ebay: 8734 acceso Una semana después: acceso Archivo Cookie amazon: 1678 ebay: 8734 Capa de Aplicaciones

46 Cookies (continuación)
NOTA Cookies y privacidad: Las cookies permiten a los sitios aprender muchas cosas sobre usted Usted puede suministrar su nombre y su a los sitios web Las motores de búsqueda utilizan redireccionamiento & las cookies para aprender aún más Las compañías de publicidad obtienen información a través de los sitios web Qué se puede hacer con cookies: autorización Carros de compras recomendaciones Estado de la sesión de usuario (Web ) Capa de Aplicaciones

47 GET condicional: caching del lado del cliente
servidor Meta: no enviar objetos si el cliente tiene una versión actualizada en cache cliente: El cliente especifica la fecha de la copia en cache en el mensaje de solicitud HTTP If-modified-since: <fecha> servidor: La respuesta no lleva el objeto si la copia en cache está actualizada: HTTP/ Not Modified Solicitud HTTP If-modified-since: <fecha> objeto no modificado Respuesta HTTP HTTP/1.0 304 Not Modified Solicitud HTTP If-modified-since: <fecha> objecto modificado Respuesta HTTP HTTP/ OK <datos> Capa de Aplicaciones

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

49 FTP: control separado de la conexión para datos
Cliente FTP Servidor Puerto 21, conexión TCP de control Puerto 20, conexión TCP para datos El cliente FTP contacta el servidor FTP en el puerto 21, especificamdo TCP como protocolo de transporte El cliente obtiene autorización sobre la conexión de control El cliente permite listar el directorio remoto al enviar comandos sobre la conexión de control. Cuando el servidor recibe una comando para transferir un archivo, el servidor abre una conexión TCP para datos con el cliente Después de transferir el archivo, el servidor cierra la conexión. El servidor abre una segunda conexión de datos para transferir otro archivo. Conexión de control: “out of band” El servidor FTP mantiene información “de estado”: directorio actual, la autenticación inicial, etcétera Capa de Aplicaciones

50 Comandos y respuestas FTP
Algunos comandos: Envíados como testo ASCII sobre el canal de control USER username PASS password LIST retorna una lista de los archivos en el directorio actual RETR filename recupera (trae) el archivo STOR filename almacena (coloca) el archivo en el host remoto Ejemplo de códigos de retorno Utiliza un código de estado y una frase (como en HTTP) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file Capa de Aplicaciones

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

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

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

54 XMPP (Extensible Messaging and Presence Protocol)
Cliente XMPP XMPP es un protocolo para el intercambio de información en tiempo real, estructurada con XML (Extensible Markup Language). Aunque XMPP provee un ambiente generalizado para el intercambio de datos XML, es utilizado en mensajería instantánea. Puerto 5222/TCP (client-to-server) Puerto 5269/TCP (server-to-server) Servidor XMPP Servidor XMPP Cliente XMPP Gateway Traduce entre XMPP y NO-XMPP Cliente XMPP Cliente NO- XMPP Servidor IM NO-XMPP Capa de Aplicaciones

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

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

57 Esquema de direccionamiento de XMPP
Por razones históricas, las dirección de una entidad XMPP se llama Jabber Identifier o JID. Un JID válido contiene un conjunto ordenado de elementos formados por un identificador de dominio, un identificador de nodo y un identificador de recurso. JID = Capa de Aplicaciones

58 DNS: Domain Name System
Las personas: tienen muchos identificacdores: Cédula, nombre, pasaporte Identificadores de host y routers de Internet: La dirección IP (32 bits) – utilizada para direccionar datagramas El “nombre”, por ejemplo, gaia.cs.umass.edu – utilizado por los humanos Pregunta: ¿quién asocia las direcciones IP y los nombres? Domain Name System: Base de datos distribuida implementada un una jerarquía de muchos servidores de nombres Protocolo de la capa de aplicación utilizado por hosts, routers, y servidores de nombres para resolver nombres (traducción entre dirección y nombre) nota: función central de Internet, implementada como un protocolo de la capa de aplicaciones Capa de Aplicaciones

59 Servidores de nombres DNS
¿Por qué no un DNS centralizado? Un solo punto de falla Alto volumen de tráfico Base de datos centralizada distante mantenimiento ¡ NO PUEDE ESCALAR ! Ningún servidor tiene todas las asociaciones nombre a IP Servidores de nombres locales: cada ISP o compañía tiene un local (default) name server Las consultas que realizan los nodos primero se hacen con el local name server Servidor de nombres autorizado: Para un host: almacena la dirección IP y el nombre de ese host Puede hacer la traducción de nombre a dirección IP para ese host Capa de Aplicaciones

60 DNS: Servidores raíz (root servers)
Contactado por el servidor de nombres local que no puede resolver el nombre Servidor de nombres raíz: Contacta el servidor de nombres autoritativo si el mapeo de nombre no es conocido Consigue el mapeo Retorna el mapeo al servidor de nombres local 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 Capa de Aplicaciones

61 Ejemplo Simple de DNS DNS raíz surf.eurecom.fr desea saber la dirección IP de gaia.cs.umass.edu 1. Contacta su servidor DNS local, dns.eurecom.fr 2. dns.eurecom.fr contacta el servidor de nombres raíz, si es necesario 3. El servidor de nombres raíz contacta el servidor de nombres autoritativo, dns.umass.edu, si es necesario 2 4 3 5 DNS local dns.eurecom.fr DNS autoritativo dns.umass.edu 1 6 Nodo que consulta surf.eurecom.fr gaia.cs.umass.edu Capa de Aplicaciones

62 Ejemplo de DNS DNS raíz:
Podría no conocer el servidor de nombres autoritativo Podría conocer el DNS intermedio: el que se contacta para encontrar el DNS autoritativo 2 6 7 3 DNS local dns.eurecom.fr DNS intermedio dns.umass.edu 4 5 1 8 DNS autoritativo dns.cs.umass.edu Nodo que consulta surf.eurecom.fr gaia.cs.umass.edu Capa de Aplicaciones

63 DNS: consultas iterativas
DNS raíz Consulta recursiva: Coloca un bloque de consultas de resolución de nombres sobre el servidor de nombres contactado ¿demasiada carga? Consulta iterada: El servidor contactado responde con el nombre del servidor que se debe contactar “Yo no conozco ese nombre, pero pregúntele a éste servidor” Consulta iterada 2 3 4 7 DNS local dns.eurecom.fr DNS intermedio dns.umass.edu 5 6 1 8 DNS autoritativo dns.cs.umass.edu Nodo que consulta surf.eurecom.fr gaia.cs.umass.edu Capa de Aplicaciones

64 DNS: caching y actualización de registros
Cuando el DNS aprende el mapeo, el hace una copia en cache Los datos colocados en el cache tienen un tiempo de vigencia, al pasar dicho tiempo los datos desaparecen El mecanismo de actualización/notificación está en diseño por la IETF RFC 2136 Capa de Aplicaciones

65 Fromato RR: (name, value, type, ttl)
Registros del DNS DNS: registros de recursos (RR) almacenados en una base de datos distribuida Fromato RR: (name, value, type, ttl) Type=A name es un nombre de hosts value es una dirección IP 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 Type=NS name es un dominio (por ejmplo. sitio.com) value es una dirección IP de un DNS autoritativo para este dominio Type=MX value es el nombre de un servidor de correo asociado con name Capa de Aplicaciones

66 Protocolo DNS y mensajes DNS
Protocolo DNS: mensajes de query y reply, juntos tienen el mismo formato de mensaje Header del mensaje identificación: 16 bits que identifican la consulta (query), la respuesta a la consulta utiliza el mismo identificador flags: Consulta o respuesta recursión deseada recursión disponible La respuesta es autoritativa identificación flags número de consultas número de RRs respondidos Número de RRs autoritativos Número de RRs adicionales Consultas (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 Capa de Aplicaciones

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

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

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

70 LDAP: protocolo de acceso
Hablar de los servicios de directorio hace que se olvide que LDAP es un protocolo (algunos utilizan términos como LDAP server o árbol LDAP) LDAP ofrece un vista de datos en forma de árbol, y este es el árbol al que las personas se refieren. LDAP es un protocolo cliente/servidor definido en el RFC 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

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

72 Capítulo 2: contenido 2.1 Principios de los protocolos de la capa de aplicaciones Clientes y servidores Requerimientos de las aplicaciones 2.2 Web y HTTP 2.3 FTP 2.4 Correo electrónico SMTP, POP3 e IMAP 2.5 DNS 2.6 Programación con Sockets de TCP 2.7 Programación con Sockets de UDP 2.8 Construyendo un servidor Web 2.9 Distribución de contenido Caching de web en la red Redes de distribución de contenido Archivos compartidos P2P Capa de Aplicaciones

73 Programación con sockets
Meta: aprender cómo construir aplicaciones cliente/servidor que se comuniquen utilizando sockets El API Socket Distribuido en el UNIX BSD4.1, 1981 Creado explicitamente, usado y liberado por las aplicaciones Paradigma cliente/servidor Dos tipos de transporte a través del socket: Datagrama, no confiable No confiable, orientado a flujo de bytes (byte stream-oriented) 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 Capa de Aplicaciones

74 Programación con sockets utilizando TCP
Socket: una puerta entre el proceso de la aplicación y el protocolo de la capa de transporte (UDP o TCP) Servicio TCP: transferencia confiable de bytes desde un proceso a otro controlado por el desarrollador de la aplicación controlado por el desarrollador de la aplicación proceso TCP con buffers, variables socket proceso TCP con buffers, variables socket controlado por el sistema operativo controlado por el sistema operativo internet host o servidor host o servidor Capa de Aplicaciones

75 Programando sockets con TCP
El cliente debe contactar al servidor: El proceso del servidor debe estar corriendo desde antes El servidor debe haber creado un socket (puerta) que acepte la solicitud del cliente El cliente contacta al servidor: Creando un socket TCP local Especificando la dirección IP y el número de puerto del proceso del servidor Cuando el cliente crea el socket: el cliente TCP establece una conexión al servidor TCP Cuando es contactado por el cliente, el servidro TCP crea un nuevo socket para que el proceso servidor se comunique con el cliente Permite al servidor comunicarse con múltiples clientes Los númerso de puerto origen son utilizados para identificar los clientes (más en el cap. 3) TCP permite transferir bytes de manera confiable, en orden (“un tubo”), entre el cliente Y el servidor Para la aplicación… Capa de Aplicaciones

76 Términos utilizados en streaming
Un stream es una secuencia de caracteres que fluye hacia/desde un proceso. Un input stream se asocia a alguna fuente de entrada de datos para el procesos, por ejemplo, el teclado o un socket. Un output stream se asocia a una fuente de salida, por ejemplo, la pantalla o un socket. Capa de Aplicaciones

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

78 Interacción de sockets en cliente/servidor: TCP
Servidor (ejecutando en hostid) Cliente crea socket, port=x, para recibir solicitudes: welcomeSocket = ServerSocket() establece conexión TCP crea socket, se conecta a hostid, port=x clientSocket = Socket() espera solicitudes de conexión connectionSocket = welcomeSocket.accept() envía solicitudes usando clientSocket lee solicitudes desde connectionSocket escribe las respuestas en lee respuestas de clientSocket cierra connectionSocket cierra conexión TCP cierra clientSocket Capa de Aplicaciones

79 Ejemplo: Cliente Java (TCP)
import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Crea input stream asociado al teclado Crea socket para el cliente, conecta al servidor Crea output stream asociado al socket Capa de Aplicaciones

80 Ejemplo: Cliente Java (TCP), cont.
Crea input stream asociado al socket BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } Envía la línea al servidor Lee la línea desde el servidor Capa de Aplicaciones

81 Ejemplo: Servidor Java (TCP)
import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); Crea socket de bienvenida en el puerto 6789 Espera, crea un socket para ser contactado por el cliente Crea un input stream, asociado al socket Capa de Aplicaciones

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

83 Capítulo 2: contenido 2.1 Principios de los protocolos de la capa de aplicaciones Clientes y servidores Requerimientos de las aplicaciones 2.2 Web y HTTP 2.3 FTP 2.4 Correo electrónico SMTP, POP3 e IMAP 2.5 DNS 2.6 Programación con Sockets de TCP 2.7 Programación con Sockets de UDP 2.8 Construyendo un servidor Web 2.9 Distribución de contenido Caching de web en la red Redes de distribución de contenido Archivos compartidos P2P Capa de Aplicaciones

84 Programando sockets con UDP
UDP: no establece una “conexión” entre el cliente y el servidor No hace handshaking El emisor explícitamente asocia la dirección IP y el puerto destino a cada paquete El servidor debe extraer la dirección IP y el puerto del emisor a partir del paquete enviado UDP: los datos transmitidos pueden ser recibidos fuera de orden o pueden ser perdidos Para la aplicación… UDP transfiere de manera no confiable grupos de bytes (“datagramas”) entre el cliente y el servidor Capa de Aplicaciones

85 Interacción de sockets en cliente/servidor: UDP
Servidor (ejecutando en hostid) 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 cierra clientSocket Lee la respuesta desde clientSocket Escribe la respuesta en serverSocket Especificando la dirección IP del cliente y el número de puerto Capa de Aplicaciones

86 Ejemplo: Cliente Java (UDP)
Procesocliente Input: recibe paquetes (TCP recibe “byte stream”) Output: envía paquetes (TCP envía “byte stream”) client UDP socket Capa de Aplicaciones

87 Ejemplo: Cliente Java (UDP)
import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new 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 Capa de Aplicaciones

88 Ejemplo: Cliente Java (UDP), cont.
Crea datagrama con la longitud de datos-a-enviar, dirección IP, puerto DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(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(); } Envía datagrama al servidor Lee datagrama desde el servidor Capa de Aplicaciones

89 Ejemplo: Servidor Java (UDP)
import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new 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 Capa de Aplicaciones

90 Ejemplo: Servidor Java (UDP), cont
String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Consigue le dirección IP puerto #, del solicitante Crea datagrama para envíar al cliente Escribe el datagrama en el socket Fin del ciclo while, regresa al inicio y espera otro datagrama Capa de Aplicaciones

91 Construyendo un servidor Web simple
Maneja sólo una solicitud HTTP Acepta la solicitud Analiza el header Obtiene el archivo solicitado desde el sistema de archivos del servidor Crea el mensaje de respuesta HTTP: Líneas de header + archivo Envía la respuesta al cliente Después de construir el servidor, usted puede solicitar el archivo urilizando un browser (Internet Explorer o Netscape Navigator) Vea el texto para más detalles Capa de Aplicaciones

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

93 Capítulo 2: contenido 2.1 Principios de los protocolos de la capa de aplicaciones Clientes y servidores Requerimientos de las aplicaciones 2.2 Web y HTTP 2.3 FTP 2.4 Correo electrónico SMTP, POP3 e IMAP 2.5 DNS 2.6 Programación con Sockets de TCP 2.7 Programación con Sockets de UDP 2.8 Construyendo un servidor Web 2.9 Distribución de contenido Caching de web en la red Redes de distribución de contenido Archivos compartidos P2P Capa de Aplicaciones

94 Cache en Web (servidor proxy)
Meta: satisfacer las solicitudes del cliente sin involucrar el servidor origen El usuario debe configurar el browser: Los accesos web se realizan a través del cache El browser envía todas las solicitudes HTTP al cache Si el objeto está en el cache: el cache retorna el objeto Si el objeto no está en el cache, el servidor de cache lo solicita desde el servidor origen y entonces envía el objeto al cliente Servidor origen Servidor Proxy Solicitud HTTP Solicitud HTTP cliente Respuesta HTTP Respuesta HTTP Solicitud HTTP RespuestaHTTP response cliente Servidor origen Capa de Aplicaciones

95 Más sobre Web caching ¿Por qué utilizar Web caching?
El servidor de cache actua tanto como cliente y como servidor El servidor de cache puede hacer actualizaciones de su contenido utilizando el header HTTP If-modified-since Probelma: ¿el servidor de cache debería tomar el riesgo y entregar el objeto copiado en su disco sin hacer ninguna revisión? Se utilizan métodos heurísticos. Un servidor de cache típico se instala en un ISP (universidad, compañía, ISP residencial) ¿Por qué utilizar Web caching? Reduce el tiempo de respuesta de las solicitudes del cliente. Reduce el tráfico sobre el canal de acceso a Internet de una institución. Internet con muchos servidores cache permite que los proveedores de contenido “pobre” entreguen contenido de manera efectiva Capa de Aplicaciones

96 Ejemplo de Caching (1) Supuestos
Tamaño promedio del objeto = 100,000 bits Tasa de solicitudes promediodesde el browser de la institucióna los servidores origen = 15/seg Retardo desde el router institucional a cualquier servidor origen y de regreso al router = 2 seg Consecuencias utilización sobre la LAN = 15% utilización sobre el enlace de acceso = 100% Retardo total = retardo en Internet + retardo del canal de acceso + retardo en la LAN = 2 seg + minutos + milisegundos Servidores origen Internet pública Enlace de acceso 1.5 Mbps Red institucional LAN a 10 Mbps Capa de Aplicaciones

97 Ejemplo de Caching (2) Posible solución
Servidores origen Posible solución Incrementar ancho de banda del enlace de acceso, digamos a 10 Mbps Consecuencias Utilización de la LAN = 15% Utilización sobre el enlace de acceso = 15% Retardo Total = retardo en Internet + retardo del canal de acceso + retardo en la LAN = 2 seg + milisegundos + milisegundos Generalmente una actualización costosa Internet pública Enlace de acceso 10 Mbps Red institucional LAN a 10 Mbps Capa de Aplicaciones

98 Ejemplo de Caching (3) Instalando servidor cahe Consecuencia Cache
Servidores origen Instalando servidor cahe Supongamos que la tasa de hits es .4 Consecuencia 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 Internet pública Enlace de acceso 1.5 Mbps Red institucional 10 Mbps LAN Cache institucional Capa de Aplicaciones

99 Redes de distribución de contenido (CDNs)
Servidor origen en Norteamérica Los proveedores de contenido son los clientes de las CDN. Replicación de contenido Las CDN instalan cientos de servidores CDN sobre toda Internet En los ISPs que están más cerca de los usuarios La CDN replica el contenido de sus clientes en los servidores CDN. Cuando el proveedor actualiza el contenido, la CDN actualiza los servidores Nodo de distribución CDN Servidor CDN En Suarmérica Servidor CDN en Asia Servjdor CDN en Europa Capa de Aplicaciones

100 Ejemplo de CDN Servidor origen Compañía CDN www.foo.com cdn.com
Solicitud HTTP para Consulta DNS para 1 2 3 Servidor origen Servidor DNS autoritativo Para las CDNs Servidor CDN cercano Servidor origen distribuye HTML Reemplaza: con Compañía CDN cdn.com distribuye archivos gif Utiliza su servidor DNS autoritativo para enrutar y redirigir las solicitudes Capa de Aplicaciones

101 Más sobre CDNs No sólo páginas web Audio y video “streaming stored”
Solicitudes de enrutamiento La CDN crea un mapa indicando las distancias desde los ISP “hoja” y los nodos CDN Cuando una consulta llega al servidor DNS autoritativo: El servidor determina el ISP desde el cual se origina la consulta Utiliza “mapeo” para determinar el mejor servidor CDN No sólo páginas web Audio y video “streaming stored” Audio y video en “real-time” Los nodos CDN construyen una overlay network sobre la capa de aplicaciones Capa de Aplicaciones

102 Compartiendo archivos P2P
Alicia selecciona uno de los PCs, Beto. El archivo es copiado desde el PC de Beto al computador de Alicia: HTTP Mientras Alicia descarga, otros usuarios descargan del computador de Alicia. 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! Ejemplo Alicia corre un cliente para una aplicación P2P sobre su computador Intermitentemente se conecta a Internet; consigue una dirección IP nueva para cada conexión Pregunta por “Hey Jude” La aplicación muestra otros PCs que tienenuna copia de Hey Jude. Capa de Aplicaciones

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

104 P2P: problemas con directorio centralizado
Un solo punto de falla (fall el directorio, falla todo) Cuello de botella para el desempeño Problemas con derechos de autor (Copyright) la transferencia de archivos es descentralizada, pero la localización de contenido es altamente centralizada Capa de Aplicaciones

105 P2P: directorio descentralizado
Cada PC o es un líder de grupo a es asignado a un líder de grupo. El líder de grupo debe mantener un seguimiento al contenido de todos “sus hijos”. 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

106 Más sobre directorio descentralizado
overlay network Los PCs son los nodos Hay arcos entre los PCs y sus líderes de grupo También hay arcos entre parejas de líderes Vecinos virtuales Nodo bootstrap 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 No hay servidor de directorio centralizado El servicio de localización se distribuye en entre los PCs Más difícil de “derribar” desventajas del enfoque Se necesita un nodo de bootstrap Los líderes de grupo pueden recibir sobrecarga de trabajo Capa de Aplicaciones

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

108 P2P: más sobre inundación de consultas
Ventajas Tienen responsabilidades similares: no hay líderes en el grupo Altamente descentralizado Ningún nodo mantiene información de directorio Desventajas excesivo tráfico de consultas query radius: may not have content when present bootstrap node maintenance of overlay network Capa de Aplicaciones

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

110 Capítulo 2: resumen Más importante: aprender sobre protocolos
Intercambio de mensajes solicitud/respuesta típico: El cliente solicita información o el servicio El servidor responde con datos, códigos de estado Formatos de mensaje: Encabezados: campos que dan información sobre los datos datos: la información que está siendo transmitida control vs. mensajes de datos 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