La Capa de Aplicaciones (Pt. 1)cs.uns.edu.ar/~ags/RC/downloads/Handouts/Módulo 02 - La Capa de... · HTTP. SMTP, POP e IMAP. DNS. ... transferencia de archivos FTP RFC 959 TCP envio

Redes de ComputadorasRedes de ComputadorasDepto. de Cs. e Ing. de la Comp.Depto. de Cs. e Ing. de la Comp.Universidad Nacional del SurUniversidad Nacional del Sur

Módulo 02Módulo 02La Capa de AplicacionesLa Capa de Aplicaciones

(Pt. 1)(Pt. 1)

Redes de Computadoras - Mg. A. G. StankeviciusRedes de Computadoras - Mg. A. G. Stankevicius 22

CopyrightCopyrightCopyright © 2010-2018 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 disponibleen la página http://www.gnu.org/copyleft/fdl.html.

La versión transparente de este documento puedeser obtenida de la siguiente dirección:

http://cs.uns.edu.ar/~ags/teaching

http://www.gnu.org/copyleft/fdl.html

http://cs.uns.edu.ar/~ags/teaching


ContenidosContenidosServicios 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.


ISO/OSI - TCP/IPISO/OSI - TCP/IP

7

6

5

4

3

2

1 físicaenlace

redtransporte

sesiónpresentación

aplicación Usted está aquí5

4

3

2

1

aplicación


Un poco de nuestra jergaUn poco de nuestra jergaDenominaremos proceso a un programaen 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.


¿¿Qué es una aplicación?Qué es una aplicación?Bajo esta perspectiva,¿en qué consisteuna aplicación de red?

Una aplicación de redes, en esencia, un conjuntode procesos distribuidosque se comunican entre sí.

La definición resultadeliberadamente universal.

Se puede aplicar a la web,al WhatsApp, etc.

aplicacióntransporte

redenlacefísica


redenlacefísica


redenlacefísica


¿¿Qué es una aplicación?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 parael núcleo de la red, puede asumir que funcionade acuerdo a su especificación.

Extraordinaria decisión de diseño: ¡que la complejidad radique en la frontera de la red!


Aplicaciones de redAplicaciones de redEn la actualidad contamos con aplicacionesde 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.


Aplicaciones de redAplicaciones de redContinú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.

…


Modelo cliente-servidorModelo cliente-servidorEl modelo cliente-servidor permite separarlas tareas en dos grupos de procesos:

Por un lado los procesos clientes, que sonlos encargados de iniciar los requerimientosa los servidores.

Por otro lado los procesos servidores, que sonlos encargados de atender y responder a esos requerimientos.

El servidor debe estar siempre a disposición para atender nuevos requerimientos.


Cliente prototípicoCliente prototípicoEl 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óndel 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 usuariola información recibida de una manera acorde.


Servidor prototípicoServidor prototípicoEl servidor tiene como responsabilidad estaren 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-forkingpara mejorar el desempeño.


Modelo par-a-par puroModelo par-a-par puroBajo el modelo par-a-par puro, los servidoresno requieren estar siempre disponibles.

Los pares se conectan entresí intermitentemente yde manera directa.

También pueden cambiarsu dirección sin previo aviso.

Resulta altamente escalable,si bien al mismo tiempo esmás complicado de gestionar.


Modelo híbridoModelo híbridoEn 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 previoa iniciar una llamada con otro usuario.


La interfaz socketsLa interfaz socketsLos procesos se comunican enviando y recibiendo información por un socket.

El socket funciona como un sistema de mensajeríaneumático, podemos mandar y recibir sin realmente saber qué pasa con los mensajes mientras están siendo transportados por los tubos de aire.

controladopor el sistema

operativo

controlado porel programador

internet

transporte

aplicación

físicaenlace

red

proceso

transporte

aplicación

físicaenlace

red

procesosockets


Espacio de nombres de la redEspacio de nombres de la redPara que un proceso sea capaz de recibirun 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 cadauna 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).


El rol de los protocolosEl rol de los protocolosLos protocolos de la capa de aplicaciones cumplen un rol central en las aplicaciones:

Su implementación constituyen una parte integralde la aplicación de red (la otra parte es la GUI).

Se caracteriza definiendo los mensajes que hande ser intercambiado así como las acciones quese deben tomar al recibir dichos mensajes.

La comunicación entre procesos es provista como servicio por la capa de red inmediata inferior yes implementada a través de sus protocolos.


Definición de un protocoloDefinición de un protocoloPara definir un protocolo hace falta especificar diversos aspectos:

Los tipos de mensajes a ser intercambiados.

La sintaxis de estos mensajes (esto es, definirsus campos y explicitar cómo se delimitan).

La semántica de la información contenidaen 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).


Definición de un protocoloDefinición de un protocoloLa definición formal de un protocolo puede ser de acceso público o privado.

Si es de acceso público, nos aseguramosuna 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 aseguramosel monopolio excluyendo a la competencia.

Al menos por un tiempo (hasta la ingeniería reversa).


Requerimientos de transporteRequerimientos de transporteLas 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 otrasno 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.


Requerimientos de transporteRequerimientos de transporte

Tipo de Aplicación

transferencia de archivos requerido elástico sienvio y recepción de email requerido elástico si

navegar la web requerido elástico siaudio/video en tiempo real no requerido no elástico no (muy exigente)

audio/video almacenado no requerido no elástico no (menos exigente)juegos en línea no requerido no elástico no (muy exigente)

mensajería instantánea requerido elástico más o menosno requerido elástico si

terminal remota segura requerido elástico si

Integridadde los datos

Anchode banda

Tolerantea retardos

consultas al servidor DNS

Tipo de Aplicación

transferencia de archivos requerido elástico sienvio y recepción de email requerido elástico si

navegar la web requerido elástico siaudio/video en tiempo real no requerido no elástico no (muy exigente)

audio/video almacenado no requerido no elástico no (menos exigente)juegos en línea no requerido no elástico no (muy exigente)

mensajería instantánea requerido elástico más o menosno requerido elástico si

terminal remota segura requerido elástico si

Integridadde los datos

Anchode banda

Tolerantea retardos



Protocolos de transporteProtocolos de transporteLa 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.


Protocolos de transporteProtocolos de transporte

Tipo de Aplicación Protocolo

transferencia de archivos FTP RFC 959 TCP

envio y recepción de emailSMTP RFC 5321 TCPPOP3 RFC 1939 TCPIMAP RFC 3501 TCP

navegar la web HTTP RFC 2616 TCPaudio/video en tiempo real Skype privado

audio/video almacenado RTMP privadojuegos en línea battle.net privado

mensajería instantánea MSN privado TCPDNS RFC 1034/5 UDP

terminal remota segura SSH RFC 4250/6 TCP

DefiniciónFormal

Protocolo deTransporte

TCP y UDPTCP (usa HTTP)

TCP y UDP


Tipo de Aplicación Protocolo

transferencia de archivos FTP RFC 959 TCP

envio y recepción de emailSMTP RFC 5321 TCPPOP3 RFC 1939 TCPIMAP RFC 3501 TCP

navegar la web HTTP RFC 2616 TCPaudio/video en tiempo real Skype privado

audio/video almacenado RTMP privadojuegos en línea battle.net privado

mensajería instantánea MSN privado TCPDNS RFC 1034/5 UDP

terminal remota segura SSH RFC 4250/6 TCP

DefiniciónFormal

Protocolo deTransporte

TCP y UDPTCP (usa HTTP)

TCP y UDP



TCP (más) seguroTCP (más) seguroCabe destacar que ni TCP ni UDP encriptanla información transportada.

Es decir, las contraseñas viajan por la red a la vistade todos los intermediarios.

Recordemos que en el comienzo de internetla 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.


TCP (más) seguroTCP (más) seguroEn 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.


World Wide WebWorld Wide WebDesde 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ágenesen formato JPEG o PNG, etc.

Cuenta con un archivo HTML base.

Todos los objetos se direccionan a travésde un URL (Uniform Resource Locator):

http://cs.uns.edu.ar:80/~ags/RC/index.html

computadora documentoprotocolo puerto


El protocolo HTTPEl protocolo HTTPEl protocolo HTTP (Hyper-Text Transfer Protocol) fue concebido por el padre de la web, Sir Tim Berners-Lee.

Es el protocolo de la capade aplicaciones de la web.

Existen tres versionesdel protocolo:

HTTP/1.0 (RFC 1945)

HTTP/1.1 (RFC 2068)

HTTP/2 (RFC 7540)


El protocolo HTTPEl protocolo HTTPAdopta un claro modelo cliente-servidor:

Los clientes, llamadosnavegadores, piden,reciben y muestranpor pantalla “objetos”.

Los servidores, llamadosservidores web, envíanlos “objetos” quele soliciten.

Windows 10Edge v41

GNU/LinuxApache v2.4.33

iPhone c/IOS 11.2.6Safari v11.1.1

HTTP requestHTTP response

HTTP request

HTTP response


El protocolo HTTPEl protocolo HTTPA grandes rasgos, el protocolo HTTPse compone de las siguientes fases:

El cliente abre una conexión TCP al puerto 80del 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 yel servidor, respetando el protocolo HTTP.

Al terminar, se finaliza la conexión TCP.

HTTP es un protocolo sin estado.


Estilos de conexiónEstilos de conexiónHTTP 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 modopor defecto de HTTP/1.1.


Traza HTTP/1.0Traza HTTP/1.0Supongamos que el usuario ingresa la dirección http://google.com 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.

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.

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.

tiempo

http://google.com/


Traza HTTP/1.0Traza HTTP/1.0Continúa:

6. El cliente HTTP recibe el mensaje de respuesta conteniendoel archivo HTML solicitado ylo muestra por pantalla. Al recorrer este archivo descubre tres referencias a otros objectos (por caso, archivos PNG).

5. El server HTTP cierrala conexión, pues el estiloadoptado es el no persistente.

tiempo

7. El cliente HTTP repite los pasos1.-6. para cada uno de los objetos restantes.


Tiempo de RespuestaTiempo 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 arbitrarioen 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 recibirlos primeros bytes de la respuesta correspondiente.

Finalmente, hace falta esperar que se terminede transferir el documento solicitado.


Tiempo de RespuestaTiempo de RespuestaGráficamente:

tiempo quetoma transmitirel documento

comienzo dela conexión TCP

RTTrequerimientode documento

RTT

documento recibidopor completo

Tiempo Total ≈ 2 RTT + Tiempo de TransmisiónTiempo Total ≈ 2 RTT + Tiempo de Transmisión

comienzo de la recepcióndel documento


Persistente vs. no persistentePersistente vs. no persistenteEl 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.


Persistente vs. no persistentePersistente vs. no persistenteEl 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?


Persistencia con y sin pipelinePersistencia con y sin pipelineEstilo 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.


HTTP/2HTTP/2El estándar HTTP/2 (antes conocido comoHTTP/2.0), fue sancionado recientementepor 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 acceder a los servidores propios.

Este protocolo se denomina SPDY e implementa ciertas optimizaciones que hacen que las páginas webs resulten mucho más reactivas.


Mensajes HTTPMensajes HTTPHTTP 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.

GET /index.html HTTP/1.1Host: www.google.com User-agent: Mozilla/5.0Connection: close Accept-language: en ↵

GET /index.html HTTP/1.1Host: www.google.com User-agent: Mozilla/5.0Connection: close Accept-language: en ↵

tipo de requerimiento(GET, POST, HEAD)

encabezamientoun CR/LF marca

el fin del mensaje


Mensajes de requerimientoMensajes de requerimientoEl formato general de los mensajesde requerimiento HTTP es el siguiente:

método • URL • versión CR LF

nombre de campo : valor CR LF



CR LF

cuerpo

requerimiento

encabezado

cuerpo del mensaje(si corresponde)


Envío de informaciónEnvío de informaciónHasta 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 porel 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.http://cs.uns.edu.ar/form.html?nombre=foo&apellido=bar


Métodos disponiblesMétodos disponiblesHTTP/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.


Mensajes de respuestaMensajes de respuestaLos mensajes de respuesta HTTP sólo se generan a consecuencia de una solicitud previa.

HTTP/1.1 200 OK Connection closeDate: Mon, 29 Mar 2010 12:00:00 GMT Server: Apache/2.2 (Unix) Last-Modified: Wed, 24 Mar 2010…Content-Length: 1221Content-Type: text/html↵

datos, datos y más datos…

HTTP/1.1 200 OK Connection closeDate: Mon, 29 Mar 2010 12:00:00 GMT Server: Apache/2.2 (Unix) Last-Modified: Wed, 24 Mar 2010…Content-Length: 1221Content-Type: text/html↵

datos, datos y más datos…

línea de estado

encabezamiento

documento solicitado

código de respuesta frase de respuesta


Códigos de respuestaCódigos de respuestaUna solicitud HTTP puede recibir cinco clasesde respuestas, distinguidas por su código:

1xx, mensajes de información (si bien el pedidono 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.


Códigos de respuestaCódigos de respuestaEjemplos en concreto de códigos de respuesta:

200 OK, requerimiento aceptado y cumplido.

301 Moved Permanently, el objeto solicitadofue movido (la nueva ubicación es informada).

400 Bad Request, el mensaje de solicitudno fue entendido por el servidor.

404 Not Found, el documento solicitadono fue encontrado.

503 Service Unavailable, el servidor está temporalmente fuera de servicio.


Chateando con un servidorChateando con un servidor¿Por qué será que este protocolo es tan “conversado” por así decir?

$ telnet www.google.com.ar 80

…

GET /index.html HTTP/1.0

Host: www.google.com.ar

Otra opción es directamente capturar los mensajes intercambiados usando el Wiresharko alguna extensión a tal efecto del navegador.

http://www.google.com.ar/

http://www.google.com.ar/


Restricción de accesoRestricción de accesoHTTP contempla un modelo de restricciónde 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ñaen cada interacción.


Intercambio de mensajesIntercambio de mensajesSupongamos que intentamos acceder aun documento no público:

401 Author. Req.WWW Authenticate:

solicitud convencional

solicitud convencional + Authorization: <cred>

respuesta convencional

solicitud convencional + Authorization: <cred>



CookiesCookiesLas 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.


CookiesCookiesLas 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.


Esquema de interacciónEsquema de interacción

respuesta convencional + Set-Cookie: 1234

solicitud convencional

solicitud convencional + Cookie: 1234


Repositorio

ebay: 4321

Repositorio

ebay: 4321

solicitud convencional + Cookie: 1234


-una semana después-

Repositorioamazon: 1234

ebay: 4321


ebay: 4321


ebay: 4321


ebay: 4321

DBDB

el server crea un nuevonúmero de usuario

(# 1234)

respuestas específicasen función del número

de usuario suministrado


Ventajas y desventajasVentajas y desventajasVentajas:

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 quelos servidores sepan más de la cuenta acercade nosotros.

¿Es realmente gratis google? ¿Y LinkedIn o Facebook?


Cache localCache localLa 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 consultarleal servidor si la copia está aún vigente.


Interacción con el cache localInteracción con el cache local

HTTP/1.1 304 Not Modified

solicitud convencional+If-Modified-Since <fecha>

Cache local<fecha> index.html

⋮


⋮

HTTP/1.1 200 OK + index.html

solicitud convencional+If-Modified-Since <fecha>


⋮


⋮

cache localactualizado

cache localactualizado

cache localdesactualizado

cache localdesactualizado


Servidor proxyServidor proxyUn 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 cantidadde requerimientos directamente desde el web cache,sin tener que acceder a los servidores en internet.

El navegador se configura para que envíe todossus 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.


Servidor proxyServidor proxyEl servidor proxy debe actuar como cliente y servidor en simultáneo.

El proxy inspecciona el valor del campoIf-modified-since.

El server proxy debería consultar al servidoren internet, pero... ¡hacer esto no tiene sentido!

La solución implementada consiste en hacer usode heurísticas para decidir si la copia en el cache está o no actualizada sin consultar al servidor en internet.


Servidor proxyServidor proxyImplementar 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íade las redes locales hace que incluso los servidores web más precarios puedan atender a un grannúmero de requerimientos a la vez.


Métricas de desempeñoMétricas de desempeñoSupongamos que nos enfrentamos conel siguiente escenario:

Tamaño por objeto: 100 Kb

Pedidos por segundo: 150

RTT a cualquier servidor: 2 s

En este contexto:

Utilización LAN: 1.5%

Utilización enlace: 100%

Retardo: 2 s + minutos + ms

WAN LANenlace

enlace de10 Mbps

internet

red localde 1 Gbps


Métricas de desempeñoMétricas de desempeñoMejorando el enlace a 100 Mbps (a un alto costo) se observa lo siguiente:



Retardo: 2 s + ms + ms

enlace de100 Mbps

internet

red localde 1 Gbps


Un ejemplo numéricoUn ejemplo numérico

servidorproxy

Implementando en cambio un servidor proxy con un hit-rate de 40%:



Retardo: <<2 s

El 40% de los requerimientosse resuelven a 1 Gbitsde velocidad (ms).

El 60% restante insume elretardo usual (2 s + ms + ms)

enlace de10 Mbps

internet

red localde 1 Gbps


Correo electrónicoCorreo electrónicoLa infraestructura de correo electrónico convencional se compone de tres actores:

Los user-agents (esto es, el cliente).

Los servidores de correo electrónico.

El protocolo SMTP (Simple Mail Transfer Protocol).

servidorde mail

SMTP

cola decorreosenviados

casillas de correoindividuales

useragent

useragent

useragent

useragent

useragent

useragent

servidorde mail

servidorde mail


Correo electrónicoCorreo electrónicoResponsabilidad del user-agent:

Usualmente se lo denomina cliente de email.

Compone, edita y visualiza correos.

Los mensajes entrantes y salientes se almacenanen el servidor.

Responsabilidad del servidor:

Mantiene una casilla de correo (mailbox) independiente para cada usuario.

Mantiene una cola de mensajes salientes en tránsito.


El protocolo SMTPEl protocolo SMTPLos 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 conexionesen el puerto 25.


El protocolo SMTPEl protocolo SMTPLa transferencia de mensaje involucratres 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.


Esquema de interacciónEsquema de interacciónFlanders le quiere mandar un mail a Homero:

Flanders usa su user-agent para componer un nuevo mail destinado a Homero ([email protected]).

El user-agent manda el nuevo correo al servidorde mail de Flanders, donde es encolado.

El servidor de mail, actuándo como cliente SMTP,se comunica con el servidor de mail de Homero.

servidorde mail

servidorde mail

useragent

useragent

mailto:[email protected]


Esquema de interacciónEsquema de interacciónContinúa:

Se transfiere el nuevo correo electrónico entrelos servidores de mail.

El servidor de mail deposita en la casilla de correode Homero el nuevo correo que acaba de recibir.

El user-agent de Homero al verificar si llegaron nuevos mensajes finalmente recibe el correo de Flanders.

servidorde mail

servidorde mail

useragent

useragent


Traza SMTPTraza SMTP

S: 220 springfield.com C: HELO hotmail.com S: 250 Hello hotmail.com, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected] ... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... 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

S: 220 springfield.com C: HELO hotmail.com S: 250 Hello hotmail.com, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected] ... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... 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


Chateando con un servidorChateando con un servidorUna vez más, podemos intentar chatear con un servidor, en este caso SMTP:

$ telnet 127.0.0.1 25

...esperar a recibir la respuesta 220

...y probar qué pasa al ingresar los comandosHELO, MAIL FROM, RCPT TO, DATA y QUIT,en ese orden

Resulta cómodo usar herramientas comoFakeSMTP para depurar el desarrollo de clientes (https://nilhcem.github.io/FakeSMTP)

https://nilhcem.github.io/FakeSMTP


Formato de los emailsFormato de los emails

To: <email destino>From: <email origen>Subject: <asunto>

Texto del mensaje

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 otropor una línea en blanco.

No confundir los camposTo: y From: con losdel protocolo SMTP.


Extensiones multimediaExtensiones multimediaRecordemos 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 usodel formato MIME (Multipurpose InternetMail Extension).

Definido formalmente en los RFC 2045/6.

Líneas adicionales en el encabezamiento declaranqué tipo de archivo MIME aparece en el cuerpodel mensaje.


From: [email protected] To: [email protected] Subject: Foto de la cortadora. MIME-Version: 1.0Content-Transfer-Encoding: base64Content-Type: image/jpeg

comienzo de datos en base64............................................................................................................fin de datos en base64

From: [email protected] To: [email protected] Subject: Foto de la cortadora. MIME-Version: 1.0Content-Transfer-Encoding: base64Content-Type: image/jpeg

comienzo de datos en base64............................................................................................................fin de datos en base64

Extensiones multimediaExtensiones multimedia

tipo y subtipode archivo multimedia

método empleado paracodificar el archivo

versión MIME

archivo multimediacodificado


Tipos y subtipos MIMETipos y subtipos MIMEEl tipo y subtipo de archivo MIME se indicaen 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 deun programa externo aparte del cliente de mail (application/msword).


Mensajes multiparteMensajes multiparteFrom: [email protected]: [email protected]: Yo de nuevo... MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPartHomero, no has visto mi cortadora de setos?--StartOfNextPartContent-Transfer-Encoding: base64Content-Type: image/jpegbase64 ........................................... .................. base64--StartOfNextPartTe adjunto una foto de ella para refrescar tu memoria.

From: [email protected]: [email protected]: Yo de nuevo... MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPartHomero, no has visto mi cortadora de setos?--StartOfNextPartContent-Transfer-Encoding: base64Content-Type: image/jpegbase64 ........................................... .................. base64--StartOfNextPartTe adjunto una foto de ella para refrescar tu memoria.


Protocolo de acceso al mailProtocolo de acceso al mail¿Por qué hace falta un protocolo distinto para acceder a la casilla de correo personal?

El server SMTP tiene que estar siempre disponible,la computadora del usuario puede no estarlo.

SMTP usualmente transmite un único mensaje, pero en la casilla de correo puede haber más de uno.

servidorde mail

servidorde mail

useragent

useragent

SMTP SMTP POP3


Protocolo de acceso al mailProtocolo de acceso al mailExisten 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.)


Traza POP3Traza POP3S: +OK POP3 server readyC: USER homeroS: +OKC: PASS hamburguesaS: +OK user successfully logged onC: LISTS: 1 498S: 2 912S: .C: RETR 1S: <contenido del mensaje 1>S: .C: DELE 1C: RETR 2S: <contenido del mensaje 2>S: .C: DELE 2C: QUITS: +OK POP3 server signing off

S: +OK POP3 server readyC: USER homeroS: +OKC: PASS hamburguesaS: +OK user successfully logged onC: LISTS: 1 498S: 2 912S: .C: RETR 1S: <contenido del mensaje 1>S: .C: DELE 1C: RETR 2S: <contenido del mensaje 2>S: .C: DELE 2C: QUITS: +OK POP3 server signing off

Fase de autorización:

El cliente presenta suscredenciales.

El server contesta+OK o bien -ERR.

Fase de transacción:

El cliente accede a losmensajes almacenados.


POP3 vs. IMAPPOP3 vs. IMAPLa 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 enuna 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.


POP3 vs. IMAPPOP3 vs. IMAPIMAP, 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 entrelas distintas sesiones del usuario.


¿¿Preguntas?Preguntas?

Documents

La Capa de Aplicaciones (Pt. 1)cs.uns.edu.ar/~ags/RC/downloads/Handouts/Módulo 02 - La Capa de... · HTTP. SMTP, POP e IMAP. DNS. ... transferencia de archivos FTP RFC 959 TCP envio