La Capa de Aplicaciones (Pt. 1)ags/RC/downloads/Handouts/Módulo 02 - La C… · Redes de...

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-2020 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

…

Ah, me olvidaba: educación a distancia!!!


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

Hay muchas maneras de optimizar este aspecto, es acá donde vale la pena focalizar nuestro esfuerzo


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 provistacomo servicio por la capa 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 7540 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 7540 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 v81

GNU/LinuxApache v2.4.43

iPhone c/iOS 13.4.1Safari v13

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 navegador1. 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 URLhttp://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/


¿¿Preguntas?Preguntas?

La Capa de Aplicaciones (Pt. 1)ags/RC/downloads/Handouts/Módulo 02 - La C… · Redes de...

Documents

Transcript of La Capa de Aplicaciones (Pt. 1)ags/RC/downloads/Handouts/Módulo 02 - La C… · Redes de...