Capítulo 2 Capa de aplicación -...

Redes de computadoras

Traducción y adaptación Alejandra Stolk 2018 Kurose and Ross, Computer Networking: A Top Down Approach, 6th edition, Addison-Wesley, 2012

Capítulo 2Capa de aplicación

Computer Networking: A Top Down Approach 6th edition Jim Kurose, Keith RossAddison-WesleyMarch 2012

Estas clases son de Kurose y Ross

Gracias a Kurose y Ross que pusieron este material libre

La traducción y adaptación es de Alejandra Stolk para la materia Redes de Computadoras

All material copyright 1996-2012 J.F Kurose and K.W. Ross, All Rights Reserved



Capítulo 2: la ruta

2.1 principios de aplicaciones de redes 2.2 Web y HTTP2.3 FTP 2.4 Correo electrónico

SMTP, POP3, IMAP2.5 DNS2.6 Aplicaciones de P2P 2.7 Programación para sockets con UDP y TCP


Traducción y adaptación Alejandra Stolk 2018 Kurose and Ross, Computer Networking: A Top Down Approach, 6th edition, Addison-Wesley, 2012Application Layer 2-3

Capítulo 2: la capa de aplicación

Nuestros objetivos: Conceptualmente,

aspectos de implementación de los protocolos Modelo de

transporte y servicio Paradigma cliente-

servidor Paradigma peer-to-

peer

Aprender sobre los protocolos, examinando aquellos que son populares en la capa de aplicación HTTP FTP SMTP / POP3 / IMAP DNS

Crear aplicaciones de red APIs



Algunas aplicaciones de red

Correo electrónico web Mensajería de texto Sesión remota Intercambio de archivos

P2P Juegos multi-usuario en

red Streaming de videos

(YouTube, Hulu, Netflix)

Voz sobre IP (e.g., Skype) Videoconferencias Redes sociales Búsquedas … …



Creando una app de redEscriban programas que: Puedan correr en diferentes

sistemas operativos sobre la red e.g., El servidor web se comunica

con el navegador web independientemente del navegador y del sistema operativo del servidor web

No hay necesidad de escribir programas para equipos de la columna vertebral de la red

Equipos de la columna vertebral de la red no ejecutan aplicaciones de usuario

Las aplicaciones en equipos finales permiten un rápido desarrollo, implementación y propagación

aplicacióntransporte

redenlacefísica


redenlacefísica


redenlacefísica



Arquitecturas de aplicación

Posibles estructuras de las aplicaciones sobre la red: cliente-servidor peer-to-peer (P2P)



Arquitectura cliente-servidor

servidor: Siempre en un equipo Dirección IP permanente Centros de datos para el

escalamiento

clientes: Se comunica con el servidor Puede estar conectado

intermitentemente Puede tener una dirección IP

dinámica No se comunican

directamente entre ellos

cliente/servidor



Arquitectura P2P

No siempre está en un servidor Usuarios finales se comunican

entre si arbitraria y directamente

Los paren solicitan servicios de otros pares y a su vez proveen servicios a otros pares Auto-escalammiento –

nuevos pares traen más capacidad, y a su vez más demanda al sistema

Pares están conectados intermitentemente y cambian de dirección IP constantemente Administración compleja

peer-peer



Comunicación entre procesos

proceso: programa que se ejecuta dentro del mismo equipo

Dentro del equipo, 2 procesos se comunican utilizando procesos de intercomunicación (definido por el S.O.)

Procesos en equipos diferentes se comunican utilizando mensajes

Procesos clientes: son aquellos que inician la comunicación

Procesos de servidor: son aquellos que esperan ser contactados

Aparte: las aplicaciones que usan arquitectura P2P generan procesos de cliente y servidor

clientes, servidores



Sockets Los procesos envían/reciben mensajes desde/hasta a través de

un socket Un socket es análogo a una puerta

El proceso de envío empuja el mensaje a la puerta El proceso de envío depende de la infraestructura de

transporte del otro lado de la puerta para entregar el mensaje al socket en el proceso de recepción

Internet

Controlado por el S.O.

Controlado por el desarrollador

transporte

aplicación

físico

enlace

red

proceso

transporte

aplicación

físico

enlace

red

procesosocket



Proceso de direccionamiento

Para recibir mensajes es imprescindible tener un identificador

Para ello cada equipo cuenta con un dirección IPv4 y/o un dirección IPv6 de 32 y 128 bits respectivamente

P: ¿La dirección IP del host en qué proceso se ejecuta es suficiente para identificar el proceso?

La identificación incluye la dirección IP y el número de puerto asociado con el proceso en el equipo.

Ejemplos de puertos conocidos: HTTP: 80 Correo: 25

Enviando paquetes de HTTP hacia gaia.cs.umass.edu servidor: Dirección IP: 128.119.245.12 Puerto número: 80 R: no, muchos procesos

pueden ejecutarse en el mismo equipo



La capa de aplicación define: Tipo de mensajes a

intercambiar, Ejemplo: solicitud,

respuesta Sintaxis:

Qué campos en el mensaje se llenan y cómo se delinean

Semántica de los mensajes

Información relevante en los campo

Reglas para cuándo y cómo los procesos envían y reciben los mensajes

Protocolos abiertos: Definidos por RFCs Permite la

interoperabilidad– Ejemplo: HTTP, SMTP

Protocolos propietarios:– Ejemplo: Skype



Qué servicio de transporte necesita un aplicación?

Integridad de los datos Algunas aplicaciones (e.g.,

transferencia de archivos, transacciones web) requieren un transporte 100% de confianza

Otras aplicaciones (e.g., audio) pueden tolerar algo de pérdidas de paquetes

Sincronización Algunas aplicaciones (por

ejemplo, telefonía por Internet, juegos interactivos) requieren poca demora para ser "efectivas"

Rendimiento Algunas aplicaciones (e.g.,

multimedia) requieren de un mínimo de rendimiento para ser efectivas

Otras aplicaciones (“que podemos llamar elásticas”) que pueden hacer uso de cualquier ancho de banda que le den

Seguridad cifrado, integridad de los datos,

…



Requerimiento de transporte para servicios: apps comunes



Servicios de protocolos de transporte de Internet

Servicios de TCP: Transporte confiable entre el

proceso de envío y recepción Control de flujo: el emisor no

abrumará al receptor Control de congestión:

transmisor del acelerador cuando la red está sobrecargada

No proporciona: tiempo, garantía mínima de rendimiento, seguridad

Orientado a la conexión: requiere configuración entre los procesos del cliente y del servidor

Servicio de UDP: Transferencia de datos

poco confiable: entre el proceso de envío y recepción

No proporciona: confiabilidad, control de flujo, control de congestión, tiempo, garantía de rendimiento, seguridad o configuración de la conexión.

P: ¿por qué molestarse? ¿Por qué hay un UDP?



¿Porqué UDP?

El Protocolo UDP es un protocolo de la capa de transporte para uso con el protocolo IP de la capa de red.

UDP proveé un servicio de intercambio de datagramas a través de la red en modo Best-Effort

No asegura la entrega de los datagramas o paquetes. El servicio que proveé el protocolo UDP no es fiable, ya que no garantiza la entrega o

algún tipo de protección para evitar la duplicidad de los paquetes. La simplicidad de los paquetes UDP reduce la cantidad de información necesaria para

poder ser utilizarse. Una computadora puede mandar paquetes UDP sin establecer una conexión con el

dispositivo que los va a recibir. La computadora completa los campos de información en los encabezados en el paquete UDP y envía los datos junto con el encabezado a través de la capa de red mediante el protocolo IP.



Aplicaciones en Internet: aplicación, transporte y protocolos



Aseguranndo TCP

TCP y UDP No es cifrado Se envían las

contraseñas a un socket en texto claro

SSL Proporciona conexión

TCP cifrada Integridad en los datos Autenticación punto a

punto

•SSL is at app layer Las aplicaciones usan

bibliotecas SSL, que "hablan" con TCP

SSL socket API Las contraseñas de

texto sin cifrar se envían a través de un canal cifrado transversal

+ en Capítulo 7

Application Layer 2-18



Capítulo 2: la ruta

2.1 principios de aplicaciones de redes 2.2 Web y HTTP2.3 FTP 2.4 Correo electrónico

SMTP, POP3, IMAP2.5 DNS2.6 Aplicaciones de P2P 2.7 Programación para sockets con UDP y TCP



Web y HTTP

Primero, un repaso… Una página web está compuesta por objetos Un objeto puede ser un archivo HTML, una

imagen JPEG, un applet de JAVA, un archivo de audio,…

Una página web consiste en base en un archivo HTML que incluye muchos objetos referenciados

Cada objeto es referenciable por un URL, e.g.,

www.someschool.edu/someDept/pic.gif

Nombre del equipo Ruta del enlace



Una visión del HTTPHTTP: Protocolo de

Transferencia de Hipertexto

Es el protocolo de cpa de aplicación para la Web

Sigue un modelo cliente/servidor cliente: navegador que

solicita, recibe, (utilizando el protocolo HTTP) y "muestra" objetos web

servidor: el servidor web envía (utilizando el protocolo HTTP) objetos en respuesta a solicitudes

Pc ejecutando Firefox

servidor ejecutando

el servicio Webcon Apache

iphone ejecutandoSafari

Solicitud HTTPRespuesta HTTP

Solicitud HTTP

Respuesta HTTP



usa TCP: El cliente inicia una

conexión TCP (creando un socket) que apunta el puerto 80 del servidor

El servidor acepta la conexión TCP del cliente

Los mensajes HTTP (a nivel de la capa de aplicación) son intercambiados a través del navegador y el servidor

La conexión TCP se cierra

HTTP es “stateless” El servidor no

mantiene información sobre solicitudes pasadas

Los protocolos que mantienen un estado son complejos!

Parte de la historia de ese estado debe mantenerse

Si el cliente/servidor se estrellan, las vistas sobre sus estados podrían ser inconsistentes, y deberán sincronizar de nuevo por dónde iban

Por un lado

Una visión del HTTP



Conexiones HTTP

HTTP sin persistencia at most one object

sent over TCP connection Luego se cierra la

conexión La descarga de

múltiples objetos requiere de múltiple conexiones

HTTP persistente Múltiples objetos

pueden ser enviados sobre una misma conexión TCP entre el cliente y el servidor



HTTP sin persistenciaSuppongamos que un usurio escribe el URL:

1a. El cliente HTTP client inicia una conexión TCP a un servidor HTTP en www.someSchool.edu en el puerto 80

2. El cliente HTTP envía una solicitud HTTP request message (que contiene el URL) en un socket TCP. El mensaje indica que el cliente quiere obtener el objeto: someDepartment/home.index

1b. El servidor HTTP en www.someSchool.edu está a la espera de conexiones TCP en el puerto 80. El servidor “acepta” la conexión y notifica al cliente

3. El servidor HTTP recibe la solicitud y forma un mensaje de respuesta response message que contiene el objeto y los envía poniéndolo en el socket

tiempo

(contiene texto, y referencias a 10

images jpeg)www.someSchool.edu/someDepartment/home.index



5. El cliente HTTP client recibe el mensaje de respuesta que contiene el archivo html file y los desplega. El pasar el html encuentra que hay referenciado 10 objetos jpeg

6. Los pasos del 1-5 de se repiten para la obtención de los 10 archivos jpeg

4. El servidor HTTP cierra la conexión TCP.

tiempo

HTTP sin persistencia



HTTP sin persistencia: tiempo de respuesta

RTT (definición): tiempo en el que un pequeño paquete viaja del cliente al servidor y vuelve

Tiempo de respuesta del HTTP: Un RTT para iniciar la conexión

TCP Un RTT para que la solicitud

HTTP y los primeros bytes respondan

Tiempo de transferencia del archivo

Tiempo de respuesta del HTTP sin persistencia= 2RTT+ tiempo de

transferencia del archivo

Tiempo de transferencia

del archivo

Se inicia la conexión TCP

RTT

Solicitud de archivo

RTT

Archivorecibido

tiempo tiempo



HTTP persistente

Aspectos del HTTP sin persistencia:

Requiere RTTs por objeto Tendrá un tiempo de

sistema operativo por cada conexión TCP

Los navegadores comúnmente abren conexiones paralelas de TCP para obtener los objetos referenciados en un archivo HTML

HTTP persistente: El servidor deja la conexión

abierta luego de que envía una respuesta

Los siguientes mensajes HTTP entre el cliente y el servidor son transmitidos en la conexión que está abierta

El cliente envía una solicitud tan pronto cómo encuentra una referencia a un objeto

Se necesita sólo un RTT para todos los objetos a los que se haga referencia



Solicitud de mensaje HTTP

Hay dos tipos de mensajes HTTP: solicitud y respuesta La solicitud de mensaje HTTP:

ASCII (formato legible para el humano)

Línea de solicitud(comandos: GET, POST, HEAD)

Líneas de cabecera

Fin de línea, siguiente líneaAl principio indican que terminó la cabecera

GET /index.html HTTP/1.1\r\nHost: www-net.cs.umass.edu\r\nUser-Agent: Firefox/3.6.10\r\nAccept: text/html,application/xhtml+xml\r\nAccept-Language: en-us,en;q=0.5\r\nAccept-Encoding: gzip,deflate\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7\r\nKeep-Alive: 115\r\nConnection: keep-alive\r\n\r\n

Indica fin de línea

Siguiente línea



HTTP: mensaje de solicitud

Línea de solicitud

Líneas decabecera

Método sp sp cr lfversiónURL

cr lfvalorNombre del campo

cr lfvalorNombre del campo

~~ ~~

cr lf

Cuerpo del mensaje cuerpo~~~~



Subiendo un formulario de datos

Método POST : Las páginas web normalmente incluyen algún

formulario de solicitud de datos Los datos se suben al servidor en el cuerpo

de la entidad (formulario)

Método URL: Utiliza el comando o método GET Los datos se suben en un campo del en el

línea de solicitud:www.somesite.com/animalsearch?monkeys&banana



Tipos de método

HTTP/1.0: GET POST HEAD

Preguntan al servidor dejar un objeto solicitado en la respuesta

HTTP/1.1: GET, POST, HEAD PUT

Suben un archivo en el cuerpo del mensaje o entidad en un enlace específico en el campo del URL

DELETE Elimina el archivo

especificado en el campo del URL



HTTP: Mensaje de respuesta

Línea de estatus(código de protocolofrase de estatus)

Líneas decabecera

datos, ejemplo, HTML solicitado

HTTP/1.1 200 OK\r\nDate: Sun, 26 Sep 2010 20:09:20 GMT\r\nServer: Apache/2.0.52 (CentOS)\r\nLast-Modified: Tue, 30 Oct 2007 17:00:02

GMT\r\nETag: "17dc6-a5c-bf716880"\r\nAccept-Ranges: bytes\r\nContent-Length: 2652\r\nKeep-Alive: timeout=10, max=100\r\nConnection: Keep-Alive\r\nContent-Type: text/html; charset=ISO-8859-

1\r\n\r\ndata data data data data ...



Códigos de respuesta de estatus HTTP

200 OK request succeeded, requested object later in this msg

301 Moved Permanently requested object moved, new location specified later in this msg

(Location:)

400 Bad Request request msg not understood by server

404 Not Found requested document not found on this server

505 HTTP Version Not Supported

El estatus del código aparece en el primera línea en del mensaje de respuesta del servidor al cliente

Algunos ejemplos:



Prueba HTTP (lado cliente)

1. Haz un Telnet a tu servidor WEB favorito:

Abre una conexión TCP en el puerto 80(puerto por omisión para HTTP) en cis.poly.edu.Cualquier cosa que se escriba será enviada al puerto 80 de cis.poly.edu

telnet cis.poly.edu 80

2. Escribe una solicitud de GET HTTP:

GET /~ross/ HTTP/1.1Host: cis.poly.edu

Al escribir esto (y darle 2 veces a return), Enviarás esta pequeña (pero completa) solicitud de GET al servidor HTTP

3. Mira la respuesta que envío el servidor HTTP!

(para verlo también puedes hacer una captura de WIRESHARK)



Estados del usuario-servidor: cookies

Muchos servidores web usan cookies

4 componentes:1) línea de encabezado de

cookie del mensaje de respuesta HTTP

2) línea de encabezado de cookie en el próximo mensaje de solicitud HTTP

3) archivo de cookies guardado en el host del usuario, administrado por el navegador del usuario

4) base de datos back-end en el sitio web

Ejemplo: Susana siempre accede a

Internet desde PC Visita un sitio de comercio

electrónico específico por primera vez

Cuando las solicitudes HTTP iniciales llegan al sitio, el sitio crea: – Identificación única ID– entrada en la base de

datos backend para ID



Cookies: guardando el “estado”

cliente servidor

usual http response msg

usual http respuesta msg

Archivo cookie

Una semana después

usual http request msgcookie: 1678 acción

específicade la cookie

acceso

ebay 8734 Mensaje HTTP que siempre se usaEl servidor de Amazon

crea ID para el usuario 1678

Entrada creada

usual http response set-cookie: 1678 ebay 8734

amazon 1678

usual http request msgcookie: 1678 acción

específicade la cookie

acceso

ebay 8734amazon 1678

Base dedatos



Cookies

Para qué se pueden usar las cookies:

autorización recomendaciones para

carritos de compra estado de sesión del

usuario (correo electrónico web)

cookies y la privacidad: las cookies permiten que los

sitios aprendan mucho sobre ti usted puede proporcionar el

nombre y el correo electrónico a los sitios

Por un lado

Cómo mantener el "estado": puntos finales de protocolo: mantener el

estado en el emisor / receptor en múltiples transacciones

cookies: los mensajes http llevan estado



Web caches (servidor proxy)

El usuario configura el navegador: accesos web a través del caché

El navegador envía todas las solicitudes HTTP a la memoria caché

Objeto en la memoria caché: la memoria caché devuelve el objeto

• El caché solicita un objeto del servidor de origen, luego devuelve el objeto al cliente

objetivo: satisfacer la solicitud del cliente sin involucrar el servidor de origen

client

Servidorproxy

client

HTTP request

HTTP response

HTTP request HTTP request

origin server

origin server

HTTP response HTTP response



Más sobre Web caché

El caché actúa como cliente y servidor servidor para el cliente

solicitante original cliente a servidor de origen

Normalmente se instalan en los ISP institucionales (universidades, empresas, etc.)

Por qué hacer Web Caché? reducir el tiempo de

respuesta para la solicitud del cliente

reducir el tráfico en el enlace de acceso de una institución

Internet denso con cachés: permite que los proveedores de contenido "pobres" entreguen contenido de forma efectiva (también lo hace el intercambio de archivos P2P)



Ejemplos de Caches:

originservers

public Internet

institutionalnetwork

1 Gbps LAN

1.54 Mbps access link

suposiciones: Tamaño promedio de paquetes: 100K

bits tasa de solicitud promedio de

navegadores a servidores de origen:15/sec

tasa promedio de datos para los navegadores: 1.50 Mbps

RTT del enrutador institucional a cualquier servidor de origen: 2 seg

velocidad de enlace de acceso: 1.54 Mbps

consecuencias: Uso de la LAN: 15% Uso del enlace de acceso = 99%Retardo total = retardo de Internet + retardo de

acceso + retardo de la LAN

problemas!



suposiciones: Tamaño promedio de paquetes:

100K bits tasa de solicitud promedio de




Velocidad del enlace: 1.54 Mbps

consecuencias: Uso de la LAN: 15% Uso del enlace de acceso = 99%Retardo total = retardo de Internet + retardo de acceso + retardo de la LAN = 2 sec + minutos + usecs

Ejemplos de Caches: un enlace más ancho

originservers

1.54 Mbps enlace de acceso154 Mbps

154 Mbps

Costos: aumentar el ancho de banda no es barato

9.9%

Internet

Redinstitucional

1 Gbps LAN




1 Gbps LAN

originservers


local web cache

How to compute link utilization, delay?

Costo: web caché (barato!)

public Internet

Ejemplos de Caches: un servidor caché local

?

suposiciones: Tamaño promedio de paquetes:

100K bits tasa de solicitud promedio de




Velocidad del enlace: 1.54 Mbps

consecuencias: Uso de la LAN: 15% Uso del enlace de acceso = 100%Retardo total = retardo de Internet + retardo de

acceso + retardo de la LAN = 2 seg + minutos + usecs



Cálculo de la utilización del enlace de acceso, demora con caché:

supongamos que la tasa de aciertos de caché es 0.4 40% solicitudes se satisfacen por el caché, 60% solicitudes se satisfacen en servidor

origen

originservers


Utilización del enlace de acceso: 60% de las solicitudes usan el enlace

velocidad de datos a los navegadores a través del enlace de acceso = 0.6*1.50 Mbps = .9 Mbps utilización = 0.9/1.54 = .58

Retardo total = 0.6 * (velocidad de datos a los

navegadores a través del enlace de acceso) +0.4 * (demora cuando está satisfecho en la memoria caché)

= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs Menos tiempo que con el enlace de 154

Mbps (y más barato!)

public Internet


1 Gbps LAN

local web cache

Ejemplos de Caches: un servidor caché local



GET condicional

objetivo: no enviar objeto si el caché tiene una versión actualizada en caché sin demora en la

transmisión de objetos menor utilización del

enlace cache: especificar la fecha de

copia en caché en la solicitud HTTPIf-modified-since: <date>

servidor: la respuesta no contiene ningún objeto si la copia en caché está actualizada:HTTP/1.0 304 Not Modified

HTTP request msgIf-modified-since: <date>

HTTP responseHTTP/1.0

304 Not Modified

objeto no

modificadoantes

<date>

HTTP request msgIf-modified-since: <date>

HTTP responseHTTP/1.0 200 OK

<data>

objeto modificadodespués <date>

cliente servidor

Capítulo 2 Capa de aplicación -...

Documents

Transcript of Capítulo 2 Capa de aplicación -...