La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Módulo 02 La Capa de Aplicaciones (Pt. 1)

Presentaciones similares


Presentación del tema: "Módulo 02 La Capa de Aplicaciones (Pt. 1)"— Transcripción de la presentación:

1 Módulo 02 La Capa de Aplicaciones (Pt. 1)

2 Copyright Copyright © 2010-2017 A. G. Stankevicius
Se asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, versión 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Una copia de esta licencia está siempre disponible en la página La versión transparente de este documento puede ser obtenida de la siguiente dirección: Redes de Computadoras - Mg. A. G. Stankevicius

3 Contenidos Servicios que requiere la capa de aplicaciones.
Protocolos de la capa de aplicaciones. HTTP. SMTP, POP e IMAP. DNS. Arquitectura de las aplicaciones p2p. Programación basada en sockets. Redes de Computadoras - Mg. A. G. Stankevicius

4 ISO/OSI - TCP/IP Usted está aquí aplicación aplicación presentación
7 aplicación aplicación 5 6 presentación 5 sesión transporte 4 4 3 red 3 2 enlace 2 1 física 1 Redes de Computadoras - Mg. A. G. Stankevicius

5 Un poco de nuestra jerga
Denominaremos proceso a un programa en ejecución en una cierta computadora. Los procesos se comunican entre sí principalmente de dos maneras: Dentro de una misma computadora usando algún mecanismo de IPC (Inter Process Communication). Entre procesos en distintas computadoras usando alguno de los protocolos de la capa de aplicaciones. Redes de Computadoras - Mg. A. G. Stankevicius

7 ¿Qué es una aplicación? Tareas a cargo del programador:
Escribir el código que correrá en la frontera de la red posiblemente en diferentes computadoras. Definir los protocolos que se usarán para comunicarse a través de la red. No necesita preocuparse por escribir código para el núcleo de la red, puede asumir que funciona de acuerdo a su especificación. Extraordinaria decisión de diseño: ¡que la complejidad radique en la frontera de la red! Redes de Computadoras - Mg. A. G. Stankevicius

8 Aplicaciones de red En la actualidad contamos con aplicaciones de red del más variado tipo: Navegador. Correo electrónico. Mensajería instantánea. Transferencia de archivos. Distribución p2p de archivos. Juegos multiusuario en línea. Desarrollo colaborativo. Redes de Computadoras - Mg. A. G. Stankevicius

9 Aplicaciones de red Continúa: Operación remota de computadoras.
Reproducción remota de contenidos multimediales. Telefonía sobre IP (VoIP). Video conferencia en tiempo real. Computación basada en la nube (cloud computing). Realidad aumentada y virtual. Redes de Computadoras - Mg. A. G. Stankevicius

10 Modelo cliente-servidor
El modelo cliente-servidor permite separar las tareas en dos grupos de procesos: Por un lado los procesos clientes, que son los encargados de iniciar los requerimientos a los servidores. Por otro lado los procesos servidores, que son los encargados de atender y responder a esos requerimientos. El servidor debe estar siempre a disposición para atender nuevos requerimientos. Redes de Computadoras - Mg. A. G. Stankevicius

11 Cliente prototípico El cliente tiene como responsabilidad gestionar la interfaz con la que el usuario final interactúa. Tiene que iniciar las solicitudes a los servidores que correspondan. Usualmente la solicitud es producto de una acción del usuario, pero también es factible que el cliente genere solicitudes de forma autónoma. Una vez obtenida la respuesta a una solicitud, debe poner a disposición del usuario la información recibida de una manera acorde. Redes de Computadoras - Mg. A. G. Stankevicius

12 Servidor prototípico El servidor tiene como responsabilidad estar en todo momento a la espera de nuevas solicitudes de servicio. El servidor suele ser un proceso que está corriendo todo el tiempo (esto es, un daemon). Al recibir cada nueva solicitud debe generar una respuesta acorde y suministrar esta respuesta al cliente correspondiente. Se suele hacer uso de la técnica de pre-forking para mejorar el desempeño. Redes de Computadoras - Mg. A. G. Stankevicius

14 Modelo híbrido En ocasiones se logra el mejor desempeño siguiendo un modelo híbrido. Por caso, las aplicaciones de telefonía VoIP: Las llamadas entre dos usuarios se realizan de manera directa entre sí (es decir, de manera p2p). Existe un servidor centralizado que registra cuáles son y dónde están los usuarios en línea en ese momento. La aplicación consulta al servidor como paso previo a iniciar una llamada con otro usuario. Redes de Computadoras - Mg. A. G. Stankevicius

16 Espacio de nombres de la red
Para que un proceso sea capaz de recibir un mensaje debe contar con un identificar unívoco a lo ancho de toda la red. En el espacio de nombres adoptado cada computadora cuenta con una dirección IP propia. ¿Será suficiente con poder identificar cada una de las computadoras de la red? Para poder distinguir a los distintos procesos dentro de una determinada computadora también se debe suministrar un número de puerto (port). Redes de Computadoras - Mg. A. G. Stankevicius

17 El rol de los protocolos
Los protocolos de la capa de aplicaciones cumplen un rol central en las aplicaciones: Su implementación constituyen una parte integral de la aplicación de red (la otra parte es la GUI). Se caracteriza definiendo los mensajes que han de ser intercambiado así como las acciones que se deben tomar al recibir dichos mensajes. La comunicación entre procesos es provista como servicio por la capa de red inmediata inferior y es implementada a través de sus protocolos. Redes de Computadoras - Mg. A. G. Stankevicius

18 Definición de un protocolo
Para definir un protocolo hace falta especificar diversos aspectos: Los tipos de mensajes a ser intercambiados. La sintaxis de estos mensajes (esto es, definir sus campos y explicitar cómo se delimitan). La semántica de la información contenida en los campos de los mensajes contemplados. La información acerca del secuenciamiento de los mensajes (esto es, cuándo y cómo deben interactuar los procesos que implementen el protocolo). Redes de Computadoras - Mg. A. G. Stankevicius

19 Definición de un protocolo
La definición formal de un protocolo puede ser de acceso público o privado. Si es de acceso público, nos aseguramos una amplia difusión y una gran compatibilidad entre las distintas implementaciones. Se suelen definir dentro de un documento técnico denominado RFC (Request For Comments). Si en cambio son privados, nos aseguramos el monopolio excluyendo a la competencia. Al menos por un tiempo (hasta la ingeniería reversa). Redes de Computadoras - Mg. A. G. Stankevicius

20 Requerimientos de transporte
Las aplicaciones tienen diversos requerimientos de transporte de datos: Algunas necesitan asegurar la integridad de los datos transferidos (web, chat, etc.). Otras son en cambio tolerantes a las pérdidas (streaming de audio, etc.). Algunas requieren baja latencia (juegos online o telefonía sobre internet), mientras que otras no se ven tan afectadas por los retardos. Algunas sólo funcionan si cuentan con un dado ancho de banda a su disposición, mientras que otras aceptan lo mucho o lo poco que se disponga. Redes de Computadoras - Mg. A. G. Stankevicius

21 Requerimientos de transporte
Redes de Computadoras - Mg. A. G. Stankevicius

22 Protocolos de transporte
La capa de transporte brinda dos servicios: TCP: Un servicio de transporte orientado a la conexión, seguro, confiable, que implementa control de flujo y gestión de congestiones, pero que no da garantías acerca del ancho de banda ni de la latencia. UDP: Un servicio de transporte no orientado a la conexión, que no asegura la integridad de los datos ni implementa control de flujo, y tampoco da garantías acerca del ancho de banda ni de la latencia. Internet es una red estilo “best effort”. No da garantías de latencia ni de ancho de banda. Redes de Computadoras - Mg. A. G. Stankevicius

23 Protocolos de transporte
Redes de Computadoras - Mg. A. G. Stankevicius

24 TCP (más) seguro Cabe destacar que ni TCP ni UDP encriptan la información transportada. Es decir, las contraseñas viajan por la red a la vista de todos los intermediarios. Recordemos que en el comienzo de internet la seguridad no era una preocupación. Sin duda, llegado el caso una aplicación podría encargarse de encriptar y de desencriptar la información antes de encauzarla a través del socket. Redes de Computadoras - Mg. A. G. Stankevicius

25 TCP (más) seguro En la actualidad, tenemos a disposición la librería SSL (Secure Socket Layer). Esta librería brinda conexiones TCP encriptadas, asegurando la integridad de los datos y también posibilita autenticar a los interlocutores. SSL perfecciona y extiende el servicio básico provisto por el protocolo TCP permitiendo que la información sensitiva viaje protegida a través del núcleo de la red. Retomaremos este aspecto crucial más adelante, en último módulo de la materia. Redes de Computadoras - Mg. A. G. Stankevicius

26 World Wide Web Desde el punto de vista de las aplicaciones, las páginas web son meras colecciones de objetos. Esos objetos pueden ser documentos HTML (Hyper-Text Markup Language), imágenes en formato JPG o PNG, etc. Cuenta con un archivo HTML base. Todos los objetos se direccionan a través de un URL (Uniform Resource Locator): protocolo computadora puerto documento Redes de Computadoras - Mg. A. G. Stankevicius

27 El protocolo HTTP El protocolo HTTP (Hyper-Text Transfer Protocol) fue concebido por el padre de la web, Sir Tim Berners-Lee. Es el protocolo de la capa de aplicaciones de la web. Existen tres versiones del protocolo: HTTP/1.0 (RFC 1945) HTTP/1.1 (RFC 2068) HTTP/2 (RFC 7540) Redes de Computadoras - Mg. A. G. Stankevicius

29 El protocolo HTTP A grandes rasgos, el protocolo HTTP se compone de las siguientes fases: El cliente abre una conexión TCP al puerto 80 del servidor mediante un socket. El servidor acepta la conexión TCP del cliente (lo cual asigna un nuevo número de puerto). Se intercambian mensajes HTTP entre el cliente y el servidor, respetando el protocolo HTTP. Al terminar, se finaliza la conexión TCP. HTTP es un protocolo sin estado. Redes de Computadoras - Mg. A. G. Stankevicius

30 Estilos de conexión HTTP no persistente:
A lo sumo un objeto es enviado a través de cada conexión TCP. Es el estilo de conexión adoptado por HTTP/1.0. HTTP persistente: Múltiples objetos pueden ser enviados por la misma conexión TCP. Es el estilo de conexión adoptado en el modo por defecto de HTTP/1.1. Redes de Computadoras - Mg. A. G. Stankevicius

31 Traza HTTP/1.0 Supongamos que el usuario ingresa la dirección en el navegador. 1. El cliente HTTP inicia una conexión TCP con el server HTTP a la espera de nuevos requerimientos en el puerto 80 de la computadora google.com. 2. El server HTTP ubicado en google.com acepta la conexión y le avisa de ésto al cliente. 3. El cliente HTTP envía un mensaje de requerimiento HTTP (el cual contiene un URL) usando el socket TCP. El mesaje indica que el cliente quiere acceder al documento index.html. 4. El server HTTP recibe el mensaje de requerimiento, arma un mensaje de respuesta conteniendo el objeto requerido y envía este mensaje usando su socket TCP. tiempo Redes de Computadoras - Mg. A. G. Stankevicius

32 Traza HTTP/1.0 Continúa: 5. El server HTTP cierra la conexión, pues el estilo adoptado es el no persistente. 6. El cliente HTTP recibe el mensaje de respuesta conteniendo el archivo HTML solicitado y lo muestra por pantalla. Al recorrer este archivo descubre tres referencias a otros objectos (por caso, archivos PNG). 7. El cliente HTTP repite los pasos para cada uno de los objetos restantes. tiempo Redes de Computadoras - Mg. A. G. Stankevicius

33 Tiempo de Respuesta ¿Podremos acotar de alguna manera el tiempo de respuesta de un servidor HTTP? Denominaremos RTT (Round-Trip Time) al tiempo que le toma a un mensaje arbitrario en ir del cliente al servidor y volver. Hace falta un RTT para establecer la conexión. Hace falta otro RTT para enviar el pedido y recibir los primeros bytes de la respuesta correspondiente. Finalmente, hace falta esperar que se termine de transferir el documento solicitado. Redes de Computadoras - Mg. A. G. Stankevicius

35 Persistente vs. no persistente
El estilo de conexión no persistente tiene ciertos inconvenientes: Requiere 2 RTT por cada objeto transferido. El sistema operativo tiene que establecer, mantener y cerrar una conexión TCP por cada objeto transferido. Los navegadores tienden a abrir múltiples conexiones TCP simultáneas para recuperar todos los objetos referenciados en el menor tiempo posible. Redes de Computadoras - Mg. A. G. Stankevicius

36 Persistente vs. no persistente
El estilo de conexión persistente parece corregir estos defectos: El servidor no cierra la conexión TCP luego de atender el requerimiento HTML. Los subsecuentes mensajes HTML se envían y reciben reutilizando la conexión TCP preexistente. ¿Cómo podemos hacer si necesitamos acceder a más de un objeto a la vez? ¿Esperamos a terminar el requerimiento anterior antes de solicitar el siguiente? Redes de Computadoras - Mg. A. G. Stankevicius

37 Persistencia con y sin pipeline
Estilo de conexión persistente sin pipeline: El cliente sólo puede reutilizar la conexión TCP preexistente cuando el último requerimiento enviado ya haya sido atendido y contestado. Un RTT para cada objeto referenciado. Estilo de conexión persistente con pipeline: El cliente reutiliza la conexión TCP en todo momento. En el mejor de los casos insume tan solo un RTT para la totalidad de los objetos. Es el estilo adoptado por HTTP/1.1. Redes de Computadoras - Mg. A. G. Stankevicius

38 HTTP/2 El estándar HTTP/2 (antes conocido como HTTP/2.0), fue sancionado recientemente por la IETF, el organismo a cargo de la aprobación de los nuevos RFCs. Se basa en un protocolo actualmente en uso por la compañía Google en su navegador Chrome al los acceder servidores propios. Este protocolo se denomina SPDY e implementa ciertas optimizaciones que hacen que las páginas webs resulten mucho más reactivas. Redes de Computadoras - Mg. A. G. Stankevicius

39 un CR/LF marca el fin del mensaje
Mensajes HTTP HTTP contempla sólo dos tipo de mensajes: Los requerimientos (HTTP request). Las respuestas (HTTP response). Los mensajes son enviados en ASCII, es decir, una codificación entendible por los humanos. tipo de requerimiento (GET, POST, HEAD) GET /index.html HTTP/1.1 Host: User-agent: Mozilla/5.0 Connection: close Accept-language: en encabezamiento un CR/LF marca el fin del mensaje Redes de Computadoras - Mg. A. G. Stankevicius

40 Mensajes de requerimiento
El formato general de los mensajes de requerimiento HTTP es el siguiente: requerimiento método URL versión CR LF nombre de campo : valor CR LF nombre de campo : valor CR LF encabezado nombre de campo : valor CR LF CR LF cuerpo cuerpo del mensaje (si corresponde) Redes de Computadoras - Mg. A. G. Stankevicius

41 Envío de información Hasta ahora los mensajes HTTP vistos sólo permiten obtener información del servidor. En este caso, el cuerpo del mensaje es nulo. Para poder enviar información ingresada por el usuario se puede usar el método POST. El cuerpo del mensaje contiene esa información. También se puede usar el método GET, pasando lo ingresado por el usuario dentro del URL. Redes de Computadoras - Mg. A. G. Stankevicius

42 Métodos disponibles HTTP/1.0:
GET, para acceder a los distintos objetos HTML. POST, para enviar datos ingresados por el usuario. HEAD, para verificar la validez de los hipervínculos. HTTP/1.1: GET, POST y HEAD, igual que antes. PUT, para publicar un archivo en una determinada ubicación dentro del servidor. DELETE, para eliminar un archivo del servidor. Redes de Computadoras - Mg. A. G. Stankevicius

43 Mensajes de respuesta Los mensajes de respuesta HTTP sólo se generan a consecuencia de una solicitud previa. código de respuesta frase de respuesta línea de estado HTTP/ OK Connection close Date: Mon, 29 Mar :00:00 GMT Server: Apache/2.2 (Unix) Last-Modified: Wed, 24 Mar 2010… Content-Length: 1221 Content-Type: text/html datos, datos y más datos… encabezamiento documento solicitado Redes de Computadoras - Mg. A. G. Stankevicius

44 Códigos de respuesta Una solicitud HTTP puede recibir cinco clases de respuestas, distinguidas por su código: 1xx, mensajes de información (si bien el pedido no fue resuelto aún, tampoco ha sido rechazado). 2xx, éxito, la solicitud fue recibida, entendida, atendida y respondida. 3xx, redirección, hace falta hacer ciertas correcciones a la solicitud original. 4xx, error insalvable por parte del cliente. 5xx, error insalvable por parte del servidor. Redes de Computadoras - Mg. A. G. Stankevicius

45 Códigos de respuesta Ejemplos en concreto de códigos de respuesta:
200 OK, requerimiento aceptado y cumplido. 301 Moved Permanently, el objeto solicitado fue movido (la nueva ubicación es informada). 400 Bad Request, el mensaje de solicitud no fue entendido por el servidor. 404 Not Found, el documento solicitado no fue encontrado. 503 Service Unavailable, el servidor está temporalmente fuera de servicio. Redes de Computadoras - Mg. A. G. Stankevicius

46 Chateando con un servidor
¿Por qué será que este protocolo es tan “conversado” por así decir? $ telnet 80 GET /index.html HTTP/1.0 Host: Otra opción es directamente capturar los mensajes intercambiados usando el Wireshark o alguna extensión a tal efecto del navegador. Redes de Computadoras - Mg. A. G. Stankevicius

47 Restricción de acceso HTTP contempla un modelo de restricción de acceso simple, si bien un tanto básico. Es posible indicar en el servidor qué partes son públicas y qué partes requieren autorización para poder ser accedidas. Las credenciales típicas de acceso son la combinación nombre de usuario y contraseña. Se trata de un modelo sin estado, es decir, el cliente tiene que suministrar el nombre y la contraseña en cada interacción. Redes de Computadoras - Mg. A. G. Stankevicius

49 Cookies Las cookies constituyen un mecanismo bastante eficaz para sobrellevar la naturaleza sin estado del protocolo HTTP. Sin saber qué pasó antes no es posible implementar carritos de compras, evitar tener que estar enviando siempre las credenciales junto a cada solicitud, etc. Las cookies son en esencia un mapeo entre claves y valores. Este mapeo se almacena localmente en una carpeta mantenida por el navegador. Redes de Computadoras - Mg. A. G. Stankevicius

50 Cookies Las páginas web de la mayoría de los principales sitios hacen uso de ellas. Por caso, google, facebook, mercadolibre, etc. La utilización de cookies involucran cuatro componentes: El campo de las cookies en las respuestas HTTP. El campo de las cookies en las solicitudes HTTP. El repositorio local de cookies. La base de datos de usuarios en el servidor web. Redes de Computadoras - Mg. A. G. Stankevicius

52 Ventajas y desventajas
Posibilita nuevos modelos de autorización. Carritos de compras y recomendaciones personalizadas. Mantener el estado de una sesión (webmail, etc.). Desventajas: Resulta extremadamente difícil evitar que los servidores sepan más de la cuenta acerca de nosotros. ¿Es realmente gratis google? ¿Y linkedin? Redes de Computadoras - Mg. A. G. Stankevicius

53 Cache local La implementación del estándar HTTP/1.1 mejoró el desempeño de los clientes y especialmente de los servidores. ¿Será posible optimizar de alguna forma el tiempo de 2 RTT + transferencia del objeto? Si bien el navegador no tiene control sobre el valor circunstancial del RTT, en ocasiones si puede evitar pagar el costo de transferencia. El cliente puede conservar una copia local, recibida anteriormente, de un dado objeto y sólo consultarle al servidor si la copia está aún vigente. Redes de Computadoras - Mg. A. G. Stankevicius

55 Servidor proxy Un servidor proxy (también web cache) es en esencia una generalización de la idea del cache propio del navegador a toda una red local. La idea es poder satisfacer la mayor cantidad de requerimientos directamente desde el web cache, sin tener que acceder a los servidores en internet. El navegador se configura para que envíe todos sus requerimientos al servidor proxy. Los objetos presentes en el cache del proxy son enviados al cliente directamente; los restantes tienen que ser primero recuperados de servidor en internet. Redes de Computadoras - Mg. A. G. Stankevicius

56 Servidor proxy El servidor proxy debe actuar como cliente y servidor en simultáneo. El proxy inspecciona el valor del campo If-modified-since. El server proxy debería consultar al servidor en internet, pero... ¡hacer esto no tiene sentido! La solución implementada consiste en hacer uso de heurísticas para decidir si la copia en el cache está o no actualizada sin consultar al servidor en internet. Redes de Computadoras - Mg. A. G. Stankevicius

57 Servidor proxy Implementar un servidor proxy tiene sus costos.
¿Vale la pena asignar recursos a un servidor proxy? Beneficios: Se logra reducir el tiempo de respuesta. También se reduce la ocupación del enlace a internet. La presencia de servidores proxy en la mayoría de las redes locales hace que incluso los servidores web más precarios puedan atender a un gran número de requerimientos a la vez. Redes de Computadoras - Mg. A. G. Stankevicius

62 Correo electrónico Responsabilidad del user-agent:
Usualmente se lo denomina cliente de . Compone, edita y visualiza correos. Los mensajes entrantes y salientes se almacenan en el servidor. Responsabilidad del servidor: Mantiene una casilla de correo (mailbox) independiente para cada usuario. Mantiene una cola de mensajes salientes en tránsito. Redes de Computadoras - Mg. A. G. Stankevicius

63 El protocolo SMTP Los servidores intercambian mensajes entre sí de forma directa, usando el protocolo SMTP. Se define formalmente en el RFC 2821. Usa TCP como protocolo de transporte. Adoptan una arquitectura cliente-servidor. El servidor que envía un mensaje es el cliente. El servidor que recibe el mensaje es el servidor. El servidor está a la espera de nuevas conexiones en el puerto 25. Redes de Computadoras - Mg. A. G. Stankevicius

64 El protocolo SMTP La transferencia de mensaje involucra tres etapas:
La inicialización (handshaking). La transferencia del mensaje. La finalización. Se basa en el intercambio de mensajes: Comandos, codificados en ASCII. Respuestas, compuestas de un código y de una frase. No usa ASCII extendido, usa ASCII de 7 bits. Redes de Computadoras - Mg. A. G. Stankevicius

67 Traza SMTP S: 220 springfield.com C: HELO hotmail.com
S: 250 Hello hotmail.com, pleased to meet you C: MAIL FROM: S: Sender ok C: RCPT TO: S: Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Homero, cuando me vas a devolver C: la cortadora de cesped? C: . S: 250 Message accepted for delivery C: QUIT S: 221 springfield.com closing connection Redes de Computadoras - Mg. A. G. Stankevicius

68 Chateando con un servidor
Una vez más, podemos intentar chatear con un servidor, en este caso SMTP: $ telnet ...esperar a recibir la respuesta 220 ...y probar qué pasa al ingresar los comandos HELO, MAIL FROM, RCPT TO, DATA y QUIT, en ese orden Resulta cómodo usar herramientas como FakeSMTP para depurar el desarrollo de clientes ( Redes de Computadoras - Mg. A. G. Stankevicius

69 Formato de los s El formato del correo electrónico está especificado formalmente en el RFC 822. Se compone de dos partes: Un encabezado. El cuerpo del mensaje. Se separan uno del otro por una línea en blanco. No confundir los campos To: y From: con los del protocolo SMTP. El formato del correo electrónico está especificado formalmente en el RFC 822. Se compone de dos partes: Un encabezado. El cuerpo del mensaje. To: < destino> From: < origen> Subject: <asunto> Texto del mensaje Redes de Computadoras - Mg. A. G. Stankevicius

70 Extensiones multimedia
Recordemos que el cuerpo de un correo sólo puede contener caracteres ASCII de 7 bits. Para poder enviar y recibir documentos de otros tipos (por caso, audio y video) se hace uso del formato MIME (Multipurpose Internet Mail Extension). Definido formalmente en los RFC 2045/6. Líneas adicionales en el encabezamiento declaran qué tipo de archivo MIME aparece en el cuerpo del mensaje. Redes de Computadoras - Mg. A. G. Stankevicius

71 Extensiones multimedia
From: To: Subject: Foto de la cortadora. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg comienzo de datos en base64 fin de datos en base64 versión MIME método empleado para codificar el archivo tipo y subtipo de archivo multimedia archivo multimedia codificado Redes de Computadoras - Mg. A. G. Stankevicius

72 Tipos y subtipos MIME El tipo y subtipo de archivo MIME se indica en la línea Content-Type: del encabezado. text para texto común (text/plain, text/html). image para imágenes (image/jpeg, image/png). audio para sonido (audio/basic, audio/mid). video para video (video/mpeg). application para formatos que requieran de un programa externo aparte del cliente de mail (application/msword). Redes de Computadoras - Mg. A. G. Stankevicius

73 Mensajes multiparte From: flanders@hotmail.com
To: Subject: Yo de nuevo... MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Homero, no has visto mi cortadora de setos? Content-Transfer-Encoding: base64 Content-Type: image/jpeg base base64 Te adjunto una foto de ella para refrescar tu memoria. Redes de Computadoras - Mg. A. G. Stankevicius

75 Protocolo de acceso al mail
Existen varias alternativas a la hora de acceder a los mails almacenados en la casilla de correo. POP (Post-Office Protocol): Definido en el RFC 1939 (versión 3). Maneja las credenciales y la descarga de mails. IMAP (Internet Mail Access Protocol): Definido en el RFC 3501 (versión 4, revisión 1). Más complejo, pero con más variedad de funciones. HTTP (hotmail, gmail, etc.) Redes de Computadoras - Mg. A. G. Stankevicius

76 Traza POP3 Fase de autorización: El cliente presenta sus credenciales.
El server contesta +OK o bien -ERR. Fase de transacción: El cliente accede a los mensajes almacenados. S: +OK POP3 server ready C: USER homero S: +OK C: PASS hamburguesa S: +OK user successfully logged on C: LIST S: 1 498 S: 2 912 S: . C: RETR 1 S: <contenido del mensaje 1> C: DELE 1 C: RETR 2 S: <contenido del mensaje 2> C: DELE 2 C: QUIT S: +OK POP3 server signing off Redes de Computadoras - Mg. A. G. Stankevicius

77 POP3 vs. IMAP La traza anterior de POP3 adopta una modalidad “descargo y borro”. Si cambio de user-agent, en el nuevo pierdo acceso a los mensajes descargados con el user-agent anterior. También se puede hacer uso de POP3 en una modalidad “descargo y guardo”. De esta forma, múltiples user-agents pueden tener acceso a la totalidad de los correos. POP3 no preserva el estado entre sesiones. Redes de Computadoras - Mg. A. G. Stankevicius

78 POP3 vs. IMAP IMAP, en contraste, mantiene todos los correos en un único lugar: el servidor. Permite que los usuarios organicen sus mensajes en distintas carpetas. IMAP preserva el estado entre sesiones. Los nombres de las carpetas así como la distribución de mensajes en carpetas se conserva entre las distintas sesiones del usuario. Redes de Computadoras - Mg. A. G. Stankevicius

79 ¿Preguntas? Redes de Computadoras - Mg. A. G. Stankevicius


Descargar ppt "Módulo 02 La Capa de Aplicaciones (Pt. 1)"

Presentaciones similares


Anuncios Google