Capa de aplicaciones NOTA esta presentacin es adaptada

  • Slides: 110
Download presentation
Capa de aplicaciones NOTA: esta presentación es adaptada de: Computer Networking: A Top Down

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

Capa de aplicaciones Metas: r Aspectos conceptuales de la implementación de los protocolos para

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

Contenido r Principios de los protocolos de la capa de aplicaciones m m Clientes

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

Aplicaciones de red: algunos términos Proceso: instancia de un Agente de usuario: interfaces programa

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

Aplicaciones y protocolos de la capa de aplicaciones Aplicaciones: procesos distribuidos, procesos que se

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

Un protocolo de la capa de aplicaciones define… r Los tipos de mensajes intercambiados,

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

Paradigma cliente-servidor Las aplicaciones de red típicas tienen dos partes: el cliente y el

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

Los procesos se comunican a través de la red r Los procesos envían/reciben mensajes

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

Direccionamiento de procesos: r Para que un proceso reciba mensajes, este debe tener un

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

¿Qué servicios de transporte requiere una aplicación? Pérdida de datos r Algunas aplicaciones (por

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

Requerimientos de servicios de transporte de aplicaciones comunes Pérdida Aplicación de Datos Ancho de

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

Servicios de los protocolos de transporte de Internet Servicio de TCP: r Orientado a

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

Aplicaciones de Internet: aplicación, protocolos de transporte Aplicación e-mail Acceso remoto Web Transferencia de

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

Correo electrónico Cola de mensajes salientes Agente de usuario Tres componentes principales: r Agentes

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

Correo electrónico: servidores de correo Agente de usuario Servidores de correo r buzón contiene

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

Correo electrónico: SMTP [RFC 2821] r Utiliza TCP para transferir confiablemente mensajes de correo

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

Escenario: Alicia envía un mensaje a Beto 4) El lado “cliente” de SMTP envía

Escenario: Alicia envía un mensaje a Beto 4) El lado “cliente” de SMTP envía el mensaje de alicia sobre la conexión TCP 5) El servidor de correo de Beto coloca el mensaje en el buzón de Beto 6) Beto invoca su agente de usuario para leer los mensajes 1) Alicia utiliza su agente de usuario para elaborar un mensaje para beto@algunsitio. edu 2) El agente de usuario de Alicia envía el mensaje a “su servidor de correo”; el mensaje es colocado en la cola de mensajes 3) El lado “Cliente” de SMTP abre una conexión TCP con el servidor de correo de Beto 1 Agente de usuario 2 Servidor de correo 3 4 5 6 Agente de usuario Capa de Aplicaciones 17

Ejemplo de la interacción SMTP S: C: S: C: C: C: S: 220 hamburger.

Ejemplo de la interacción SMTP S: C: S: C: C: C: S: 220 hamburger. edu HELO crepes. fr 250 Hello crepes. fr, pleased to meet you MAIL FROM: <alicia@crepes. fr> 250 alicia@crepes. fr. . . Sender ok RCPT TO: <beto@hamburger. edu> 250 beto@hamburger. edu. . . Recipient ok DATA 354 Enter mail, end with ". " on a line by itself ¿Te gusta la salsa de tomate? ¿y los pepinillos? . 250 Message accepted for delivery QUIT 221 hamburger. edu closing connection Capa de Aplicaciones 18

Interacción SMTP hecha “a mano” : r telnet nombre_servidor 25 r Se observa el

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

SMTP: palabras finales r SMTP utiliza conexiones persistentes (como el HTTP persistente) r SMTP

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

Formato del mensaje de correo SMTP: protocolo para intercambio de mensajes de correo RFC

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

Formato del mensaje: extensiones para multimedia r MIME: Multimedia Internet Mail Extension, RFC 2045,

Formato del mensaje: extensiones para multimedia r MIME: Multimedia Internet Mail Extension, RFC 2045, 2056 r Líneas adicionales en el header del mensaje declaran contenido tipo MIME Versión de MIME Método utilizado para codificar datos Tipo de dato multimedia, subtipo, parámetro de declaración From: alicia@crepes. fr To: beto@hamburger. edu Subject: Imagen de un crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data Datos codificados Capa de Aplicaciones 22

Tipos MIME Content-Type: tipo/subtipo; parámetros Text r Ejemplo de subtipos: plain, html Image r

Tipos MIME Content-Type: tipo/subtipo; parámetros Text r Ejemplo de subtipos: plain, html Image r Ejemplo de subtipos : jpeg, gif Audio r Ejemplo de subtipos: basic (codificación 8 -bit mu-law), 32 kadpcm (codificación 32 kbps) Video r Ejemplo de subtipos: mpeg, quicktime Application r Datos que deben ser procesados por el cliente antes de “poderse ver” r Ejemplo de subtipos: msword, octet-stream Capa de Aplicaciones 23

Tipo Multipart From: alicia@crepes. fr To: beto@hamburger. edu Subject: Imagen de un crepe. MIME-Version:

Tipo Multipart From: alicia@crepes. fr To: beto@hamburger. edu Subject: Imagen de un crepe. MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=Start. Of. Next. Part --Start. Of. Next. Part Hola Beto, por favor encuentra la imagen de un crepe. --Start. Of. Next. Part Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --Start. Of. Next. Part ¿te gustaría tener la receta? Capa de Aplicaciones 24

Protocolos de acceso al correo SMTP Agente de usuario Servidor de correo del remitente

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

Protocolo POP 3 Fase de autorización r Comandos del cliente: user: nombre de usuario

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

POP 3 e IMAP Más sobre POP 3 r El ejemplo anterior utiliza el

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

Web y HTTP Algunos términos r Una página Web consta de objetos r Los

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

Panorámica de HTTP: protocolo de transferencia de hipertexto r Es el protocolo de la

Panorámica de HTTP: protocolo de transferencia de hipertexto r Es el protocolo de la capa de aplicación para el Web r Usa el modelo cliente/servidor m cliente: browser o navegador que solicita, recibe y muestra los objetos Web m servidor: Servidor www que envía objetos en respuesta a las solicitudes del browser r HTTP 1. 0: RFC 1945 r HTTP 1. 1: RFC 2068 Sol icit ud H PC ejecutando. Res pue sta IE Explorer TT P HT TP TP T H d u TP Servidor t i T c H li ejecutando ta So s e u El servidor Web sp e R Apache Mac ejecutando Netscape Navigator Capa de Aplicaciones 29

Panorámica de HTTP (continuación) Utiliza TCP: r El cliente inicia la conexión TCP (crea

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

Conexiones HTTP no persistente r Al menos un objeto es enviado sobre una conexión

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

HTTP No persistente Supongamos que el usuario ingresa el URL www. algunsitio. edu/alguna. Facultad/index.

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

HTTP No persistente (cont. ) 4. El servidor HTTP cierra la 5. El cliente

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

Modelamiento del tiempo de respuesta Definición de RRT: tiempo para enviar un pequeño paquete

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

HTTP Persistente Aspectos de HTTP No persistente: r requiere 2 RTTs por objeto r

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

Mensaje de solicitud HTTP r HTTP tiene dos tipos de mensajes: request, response r

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

Mensaje de solicitud HTTP: formato general Capa de Aplicaciones 37

Mensaje de solicitud HTTP: formato general Capa de Aplicaciones 37

Enviando datos al servidor desde un formulario HTML Usando el método POST: r Las

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

Tipos de métodos HTTP/1. 0 r GET r POST r HEAD m Hace una

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

Mensaje de respuesta de HTTP Línea de estado (código de estado del Protocolo, frase

Mensaje de respuesta de HTTP Línea de estado (código de estado del Protocolo, frase de estado) Líneas de encabezado datos, es decir, archivo HTML solicitado HTTP/1. 1 200 OK Connection close Date: Thu, 06 Aug 1998 12: 00: 15 GMT Server: Apache/1. 3. 0 (Unix) Last-Modified: Mon, 22 Jun 1998 …. . . Content-Length: 6821 Content-Type: text/html datos datos. . . Capa de Aplicaciones 40

Códigos de estado de HTTP Se usan en la primera línea del mensaje de

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

Conexión HTTP (cliente) hecha “a mano” 1. Conéctese, a través de telnet al puerto

Conexión HTTP (cliente) hecha “a mano” 1. Conéctese, a través de telnet al puerto 80, a su sitio Web favorito: telnet www. arcesio. net 80 Abre una conexión TCP al puerto 80 (puerto “bien conocido” de HTTP) en www. arcesio. net. Cualquier cosa que se digite será enviada Al puerto 80 en www. arcesio. net 2. Digite una solicitud de HTTP con el método GET: GET /index. html HTTP/1. 0 Al digitar esto (y oprimir <ENTER> dos veces), se enviará esta solicitud HTTP mínima (pero completa) al servidor HTTP 3. ¡Observe el mensaje de respuesta enviado por el servidor HTTP! Capa de Aplicaciones 42

Interacción usuario-servidor: autorización Autorización : control de acceso servidor cliente al contenido del servidor

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

Cookies: guardando el “estado” Muchos sitios Web utilizan cookies Cuatro componentes: 1) Línea de

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

Cookies: guardando el “estado” (cont. ) cliente ebay: 8734 Archivo Cookie amazon: 1678 ebay:

Cookies: guardando el “estado” (cont. ) cliente ebay: 8734 Archivo Cookie amazon: 1678 ebay: 8734 Solicitud http usual Respuesta http usual + Set-cookie: 1678 Solicitud http usual cookie: 1678 Respuesta http usual El servidor crea el ID 1678 para el usuario Acción específica para cookie amazon: 1678 ebay: 8734 so acce ac ce Una semana después: Archivo Cookie Re Ba gist ba se d ro e ck e n l en da a tos d so Archivo Cookie servidor Solicitud http usual cookie: 1678 Respuesta http usual Acción específica para cookie Capa de Aplicaciones 45

Cookies (continuación) Qué se puede hacer con cookies: r autorización r Carros de compras

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

GET condicional: caching del lado del cliente r Meta: no enviar objetos si el

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

FTP: protocolo de transferencia de archivos Interface Cliente para FTP usuario Transferencia del archivo

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

FTP: control separado de la conexión para datos Puerto 21, conexión TCP de control

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

Comandos y respuestas FTP Algunos comandos: r Envíados como testo ASCII sobre el canal

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

Mensajería instantánea y XMPP r La mensajería instantánea (Instant Messaging o IM) es una

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

Mensajería instantánea y XMPP r Los clientes con interfaz gráfica despegaron a finales de

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

Mensajería instantánea r Recientemente, muchos servicios de mensajería instantánea han comenzado a ofrecer características

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

XMPP (Extensible Messaging and Presence Protocol) r XMPP es un protocolo para el intercambio

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

XMPP (Extensible Messaging and Presence Protocol) r El servidor XMPP: m Maneja las sesiones

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

XMPP (Extensible Messaging and Presence Protocol) r El gateway XMPP: m Es un servicio

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

Esquema de direccionamiento de XMPP r Por razones históricas, las dirección de una entidad

Esquema de direccionamiento de XMPP r Por razones históricas, las dirección de una entidad XMPP se llama Jabber Identifier o JID. r Un JID válido contiene un conjunto ordenado de elementos formados por un identificador de dominio, un identificador de nodo y un identificador de recurso. r JID = nodo@dominio/recurso m oscar@imserver. arcesio. net m saladechat@200. 10. 20. 30/pinocho Capa de Aplicaciones 57

DNS: Domain Name System Las personas: tienen muchos identificacdores: m Cédula, nombre, pasaporte Identificadores

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

Servidores de nombres DNS ¿Por qué no un DNS centralizado? r Un solo punto

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

DNS: Servidores raíz (root servers) r Contactado por el servidor de nombres local que

DNS: Servidores raíz (root servers) r Contactado por el servidor de nombres local que no puede resolver el nombre r Servidor de nombres raíz: m Contacta el servidor de nombres autoritativo si el mapeo de nombre no es conocido m Consigue el mapeo m Retorna el mapeo al servidor de nombres local a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA 13 servidores raíz en el mundo Capa de Aplicaciones 60

Ejemplo Simple de DNS surf. eurecom. fr desea saber la dirección IP de gaia.

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

Ejemplo de DNS Raíz DNS raíz: r Podría no conocer el servidor de nombres

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

DNS: consultas iterativas Consulta recursiva: 2 r Coloca un bloque de consultas de resolución

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

DNS: caching y actualización de registros r Cuando el DNS aprende el mapeo, el

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

Registros del DNS: registros de recursos (RR) almacenados en una base de datos distribuida

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

Protocolo DNS y mensajes DNS Protocolo DNS: mensajes de query y reply, juntos tienen

Protocolo DNS y mensajes DNS Protocolo DNS: mensajes de query y reply, juntos tienen el mismo formato de mensaje identificación flags Header del mensaje r identificación: 16 bits que identifican la consulta (query), la respuesta a la consulta utiliza el mismo identificador r flags: m Consulta o respuesta m recursión deseada m recursión disponible m La respuesta es autoritativa número de consultas número de RRs respondidos Número de RRs autoritativos Número de RRs adicionales 12 bytes Consultas (número variable de consultas) Respuestas (número variable de registros de resursos) Autoritativas (número variable de registros de recursos) Información adicional (Número variable de registros de recursos) Capa de Aplicaciones 66

Protocolo DNS y mensajes DNS Nombre, campos tipo Para una consulta RRs en respuesta

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

Servicio de directorio y LDAP r Permite consolidar los servicios existentes en un solo

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

LDAP (Lightweight Directory Access Protocol) r LDAP (Versión 3) está definido en el RFC

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

LDAP: protocolo de acceso r Hablar de los servicios de directorio hace que se

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

Modelos de LDAP r Los modelos de LDAP representan los servicios ofrecidos por un

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

Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de

Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r 2. 2 Web y HTTP r 2. 3 FTP r 2. 4 Correo electrónico m SMTP, POP 3 e IMAP r 2. 5 DNS r 2. 6 Programación con Sockets de TCP r 2. 7 Programación con Sockets de UDP r 2. 8 Construyendo un servidor Web r 2. 9 Distribución de contenido m m m Caching de web en la red Redes de distribución de contenido Archivos compartidos P 2 P Capa de Aplicaciones 72

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

Programación con sockets Meta: aprender cómo construir aplicaciones cliente/servidor que se comuniquen utilizando sockets El API Socket r Distribuido en el UNIX BSD 4. 1, 1981 r Creado explicitamente, usado y liberado por las aplicaciones r Paradigma cliente/servidor r Dos tipos de transporte a través del socket: m Datagrama, no confiable m No confiable, orientado a flujo de bytes (byte stream-oriented) socket Una interface local al host, creado por la aplicación, controlado por el OS (una “puerta”) hacia la cual los procesos de las aplicaciones pueden enviar y recibir mensajes hacia/desde otro proceso de aplicación Capa de Aplicaciones 73

Programación con sockets utilizando TCP Socket: una puerta entre el proceso de la aplicación

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

Programando sockets con TCP El cliente debe contactar al servidor: r El proceso del

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

Términos utilizados en streaming r Un stream es una secuencia de caracteres que fluye

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

Programando sockets con TCP Ejemplo de una aplicación cliente -servidor: 1) El cliente lee

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

Interacción de sockets en cliente/servidor: TCP Servidor (ejecutando en hostid) Cliente crea socket, port=x,

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

Ejemplo: Cliente Java (TCP) import java. io. *; import java. net. *; class TCPClient

Ejemplo: Cliente Java (TCP) import java. io. *; import java. net. *; class TCPClient { Crea input stream asociado al teclado Crea socket para el cliente, conecta al servidor Crea output stream asociado al socket public static void main(String argv[]) throws Exception { String sentence; String modified. Sentence; Buffered. Reader in. From. User = new Buffered. Reader(new Input. Stream. Reader(System. in)); Socket client. Socket = new Socket("hostname", 6789); Data. Output. Stream out. To. Server = new Data. Output. Stream(client. Socket. get. Output. Stream()); Capa de Aplicaciones 79

Ejemplo: Cliente Java (TCP), cont. Crea input stream asociado al socket Buffered. Reader in.

Ejemplo: Cliente Java (TCP), cont. Crea input stream asociado al socket Buffered. Reader in. From. Server = new Buffered. Reader(new Input. Stream. Reader(client. Socket. get. Input. Stream())); sentence = in. From. User. read. Line(); Envía la línea al servidor out. To. Server. write. Bytes(sentence + 'n'); Lee la línea desde el servidor modified. Sentence = in. From. Server. read. Line(); System. out. println("FROM SERVER: " + modified. Sentence); client. Socket. close(); } } Capa de Aplicaciones 80

Ejemplo: Servidor Java (TCP) import java. io. *; import java. net. *; class TCPServer

Ejemplo: Servidor Java (TCP) import java. io. *; import java. net. *; class TCPServer { Crea socket de bienvenida en el puerto 6789 Espera, crea un socket para ser contactado por el cliente Crea un input stream, asociado al socket public static void main(String argv[]) throws Exception { String client. Sentence; String capitalized. Sentence; Server. Socket welcome. Socket = new Server. Socket(6789); while(true) { Socket connection. Socket = welcome. Socket. accept(); Buffered. Reader in. From. Client = new Buffered. Reader(new Input. Stream. Reader(connection. Socket. get. Input. Stream())); Capa de Aplicaciones 81

Ejemplo: Servidor Java (TCP), cont. Crea output stream, asociado al socket Data. Output. Stream

Ejemplo: Servidor Java (TCP), cont. Crea output stream, asociado al socket Data. Output. Stream out. To. Client = new Data. Output. Stream(connection. Socket. get. Output. Stream()); Lee la línea desde el socket client. Sentence = in. From. Client. read. Line(); capitalized. Sentence = client. Sentence. to. Upper. Case() + 'n'; Escribe la línea al socket out. To. Client. write. Bytes(capitalized. Sentence); } } } Fin del ciclo while, regresa al inicio del ciclo y espera otra conexión de cliente Capa de Aplicaciones 82

Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de

Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r 2. 2 Web y HTTP r 2. 3 FTP r 2. 4 Correo electrónico m SMTP, POP 3 e IMAP r 2. 5 DNS r 2. 6 Programación con Sockets de TCP r 2. 7 Programación con Sockets de UDP r 2. 8 Construyendo un servidor Web r 2. 9 Distribución de contenido m m m Caching de web en la red Redes de distribución de contenido Archivos compartidos P 2 P Capa de Aplicaciones 83

Programando sockets con UDP: no establece una “conexión” entre el cliente y el servidor

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

Interacción de sockets en cliente/servidor: UDP Servidor (ejecutando en hostid) crea socket, port=x, para

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

Ejemplo: Cliente Java (UDP) Proceso cliente Input: recibe paquetes (TCP recibe “byte stream”) Output:

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

Ejemplo: Cliente Java (UDP) import java. io. *; import java. net. *; Crea input

Ejemplo: Cliente Java (UDP) import java. io. *; import java. net. *; Crea input stream Crea socket para el client Traslada nombre de host a dirección IP utilizando el DNS class UDPClient { public static void main(String args[]) throws Exception { Buffered. Reader in. From. User = new Buffered. Reader(new Input. Stream. Reader(System. in)); Datagram. Socket client. Socket = new Datagram. Socket(); Inet. Address IPAddress = Inet. Address. get. By. Name("hostname"); byte[] send. Data = new byte[1024]; byte[] receive. Data = new byte[1024]; String sentence = in. From. User. read. Line(); send. Data = sentence. get. Bytes(); Capa de Aplicaciones 87

Ejemplo: Cliente Java (UDP), cont. Crea datagrama con la longitud de datosa-enviar, dirección IP,

Ejemplo: Cliente Java (UDP), cont. Crea datagrama con la longitud de datosa-enviar, dirección IP, puerto Envía datagrama al servidor Datagram. Packet send. Packet = new Datagram. Packet(send. Data, send. Data. length, IPAddress, 9876); client. Socket. send(send. Packet); Datagram. Packet receive. Packet = new Datagram. Packet(receive. Data, receive. Data. length); Lee datagrama desde el servidor client. Socket. receive(receive. Packet); String modified. Sentence = new String(receive. Packet. get. Data()); System. out. println("FROM SERVER: " + modified. Sentence); client. Socket. close(); } } Capa de Aplicaciones 88

Ejemplo: Servidor Java (UDP) import java. io. *; import java. net. *; Crea socket

Ejemplo: Servidor Java (UDP) import java. io. *; import java. net. *; Crea socket tipo Datagrama en el puerto 9876 class UDPServer { public static void main(String args[]) throws Exception { Datagram. Socket server. Socket = new Datagram. Socket(9876); byte[] receive. Data = new byte[1024]; byte[] send. Data = new byte[1024]; while(true) { Crea espacio para recibir datagrama Recibe datagrama Datagram. Packet receive. Packet = new Datagram. Packet(receive. Data, receive. Data. length); server. Socket. receive(receive. Packet); Capa de Aplicaciones 89

Ejemplo: Servidor Java (UDP), cont String sentence = new String(receive. Packet. get. Data()); Consigue

Ejemplo: Servidor Java (UDP), cont String sentence = new String(receive. Packet. get. Data()); Consigue le dirección IP puerto #, del solicitante Inet. Address IPAddress = receive. Packet. get. Address(); int port = receive. Packet. get. Port(); String capitalized. Sentence = sentence. to. Upper. Case(); send. Data = capitalized. Sentence. get. Bytes(); Crea datagrama para envíar al cliente Escribe el datagrama en el socket } Datagram. Packet send. Packet = new Datagram. Packet(send. Data, send. Data. length, IPAddress, port); server. Socket. send(send. Packet); } } Fin del ciclo while, regresa al inicio y espera otro datagrama Capa de Aplicaciones 90

Construyendo un servidor Web simple r Maneja sólo una solicitud r r HTTP Acepta

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

Programando sockets: referencias Tutorial para lenguaje C (audio/slides): r “Unix Network Programming” (J. Kurose),

Programando sockets: referencias Tutorial para lenguaje C (audio/slides): r “Unix Network Programming” (J. Kurose), http: //manic. cs. umass. edu/~amldemo/courseware/intro. Tutoriales de Java: r “All About Sockets” (Sun tutorial), http: //www. javaworld. com/javaworld/jw-12 -1996/jw-12 sockets. html r “Socket Programming in Java: a tutorial, ” http: //www. javaworld. com/javaworld/jw-12 -1996/jw-12 sockets. html Capa de Aplicaciones 92

Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de

Capítulo 2: contenido r 2. 1 Principios de los protocolos de la capa de aplicaciones m m Clientes y servidores Requerimientos de las aplicaciones r 2. 2 Web y HTTP r 2. 3 FTP r 2. 4 Correo electrónico m SMTP, POP 3 e IMAP r 2. 5 DNS r 2. 6 Programación con Sockets de TCP r 2. 7 Programación con Sockets de UDP r 2. 8 Construyendo un servidor Web r 2. 9 Distribución de contenido m m m Caching de web en la red Redes de distribución de contenido Archivos compartidos P 2 P Capa de Aplicaciones 93

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

Cache en Web (servidor proxy) Meta: satisfacer las solicitudes del cliente sin involucrar el servidor origen r El usuario debe configurar el browser: Los accesos web se realizan a través del cache r El browser envía todas las solicitudes HTTP al cache m m Si el objeto está en el cache: el cache retorna el objeto Si el objeto no está en el cache, el servidor de cache lo solicita desde el servidor origen y entonces envía el objeto al cliente Servidor origen Servidor TP icit T Proxy ud HT Res it TP c i TP cliente pue T l o H Sol S ta s e HT spu TP e R TP T nse H o p tud es i r c li TP So T ta. H s e pu s Re cliente sta Servidor origen Capa de Aplicaciones 94

Más sobre Web caching r El servidor de cache actua tanto como cliente y

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

Ejemplo de Caching (1) Supuestos r Tamaño promedio del objeto = 100, 000 bits

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

Ejemplo de Caching (2) Posible solución r Incrementar ancho de banda del enlace de

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

Ejemplo de Caching (3) Servidores origen Instalando servidor cahe r Supongamos que la tasa

Ejemplo de Caching (3) Servidores origen Instalando servidor cahe r Supongamos que la tasa de hits es. 4 r 40% de las solicitudes serán satisfechas casi inmediatamente El 60% de las solicitudes serán satisfechas desde el servidor origen La utilización del enlace de accesose reduce al 60%, lográndose retardos casi despreciables (diagmos 10 milisegundos) Retardo total = Retardo en Internet + retardo en el enlace de acceso + retardo en la LAN. 6*2 segundos +. 6*. 01 segundos + milisegundos < 1. 3 segundos Consecuencia r r r = Internet pública Enlace de acceso Red institucional 1. 5 Mbps 10 Mbps LAN Cache institucional Capa de Aplicaciones 98

Redes de distribución de contenido (CDNs) r Los proveedores de contenido Servidor origen en

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

Ejemplo de CDN Solicitud HTTP para www. foo. com/sports. html Servidor origen 1 2

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

Más sobre CDNs Solicitudes de enrutamiento r La CDN crea un mapa indicando las

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

Compartiendo archivos P 2 P r Alicia selecciona uno de los Ejemplo r Alicia

Compartiendo archivos P 2 P r Alicia selecciona uno de los Ejemplo r Alicia corre un cliente para una aplicación P 2 P sobre su computador r Intermitentemente se conecta a Internet; consigue una dirección IP nueva para cada conexión r Pregunta por “Hey Jude” r La aplicación muestra otros PCs que tienenuna copia de Hey Jude. PCs, Beto. r El archivo es copiado desde el PC de Beto al computador de Alicia: HTTP r Mientras Alicia descarga, otros usuarios descargan del computador de Alicia. r El PC de alicia ejecuta una plicación que es a la vez un cliente Web y uin servidor Web. Todos los equipos (peers) se comportan como servidores = ¡servicio altamente escalable! Capa de Aplicaciones 102

P 2 P: directorio centralizado Diseño original de Servidor de directorio centralizado “Napster” 1)

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

P 2 P: problemas con directorio centralizado r Un solo punto de falla (fall

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

P 2 P: directorio descentralizado r Cada PC o es un líder de grupo

P 2 P: directorio descentralizado r Cada PC o es un líder de grupo a es asignado a un líder de grupo. r El líder de grupo debe mantener un seguimiento al contenido de todos “sus hijos”. r Un PC consulta a su líder de grupo; un líder de grupo puede consultar a otros líderes de grupo. Capa de Aplicaciones 105

Más sobre directorio descentralizado overlay network r Los PCs son los nodos r Hay

Más sobre directorio descentralizado overlay network r Los PCs son los nodos r Hay arcos entre los PCs y sus líderes de grupo r También hay arcos entre parejas de líderes r Vecinos virtuales Nodo bootstrap r Un PC que se conecte se le asigna la tarea de ser un líder de grupo o es asignado a un líder Ventajas del enfoque r No hay servidor de directorio centralizado m m El servicio de localización se distribuye en entre los PCs Más difícil de “derribar” desventajas del enfoque r Se necesita un nodo de bootstrap r Los líderes de grupo pueden recibir sobrecarga de trabajo Capa de Aplicaciones 106

P 2 P: inundación de consultas r Gnutella r Envía la consulta a sus

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

P 2 P: más sobre inundación de consultas Ventajas r Tienen responsabilidades similares: no

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

Capítulo 2: resumen Nuestro estudio de aplicaciones de red se ha terminado! r Requerimientos

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

Capítulo 2: resumen Más importante: aprender sobre protocolos r Intercambio de mensajes solicitud/respuesta típico:

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