Version 01/03/17

Computer Networks I

application

transport

link

physical

network

Capa de Aplicación

inocente.sanchez@uclm.es

Aplicación

2

Contenidos

Paradigmas de la capa de aplicación

Web / HTTP

SMTP, POP3, IMAP (eMail)

DNS

P2P

3

Conexión lógica

La capa de aplicación proporciona servicios a los usuarios

Conexión lógica entre capas de aplicación de ambos lados

Físicamente la conexión se produce a través de la capa física

4

El protocolo de la capa de aplicación define

Tipos de mensajes intercambiados solicitud, respuesta

Sintaxis del mensaje qué campos en los

mensajes y cómo se delimitan los mismos

Semántica del mensaje Significado de la

información en los campos

Reglas sobre cuándo y cómo los procesos envían mensajes y responden a ellos

Protocolos de dominio público Definidos por RFCs

Permiten interoperatividad

Ej: HTTP, SMTP, IMAP

Protocolos propietarios Ej: whatsapp, skype

5

Paradigma Cliente-Servidor (I)

Clientes: Comunican con el servidor cuando necesitan

sus servicios Puede conectarse de forma intermitente Puede tener una dirección IP dinámica Los clientes no se comunican entre ellos

Servidor: Host siempre encendido. Continuamente

ejecutando y esperando

Dirección IP fija, puerto a la escucha

Difícilmente escalables, fácil de gestionar

6

Paradigma Cliente-Servidor (II)

7

Paradigma P2P (peer to peer)

No se necesita un servidor siempre encendido esperando

Sistemas finales cualesquiera se comunican directamente y comparten

Pueden ser clientes y servidores indistintamente, e incluso a la vez

Los peers (iguales) se conectan de forma intermitente y cambian su dirección IP

Muy escalables, pero difíciles de gestionar

8

Paradigma P2P (igual a igual)

9

Híbridos de cliente-servidor y P2P

Skype Aplicación telefónica por Internet

Buscando direcciones de extremo remoto: servidor/es centralizado/s

La conexión cliente-cliente es directa (no mediante servidor)

Mensajería instantánea El chat entre dos usuarios puede ser P2P

La detección / localización de presencia está centralizada:

El usuario registra su dirección IP con un servidor central cuando se conecta

El usuario contacta con el servidor central para encontrar la dirección IP de amigos

10

¿Qué necesita una aplicación del servicio de transporte?

Pérdida de datos Algunas aplicaciones (p.e.

audio) pueden tolerar ciertas pérdidas

Otras aplicaciones (transferencia de archivos, telnet) necesitan 100% de fiabilidad en la transferencia

Temporización Algunas aplicaciones

(telefonía por Internet, juegos interactivos) necesitan bajos retardos para que sean “efectivos”

Ancho de banda

Algunas aplicaciones (p.e. multimedia) necesitan poco ancho de banda para ser “efectivas”

Otras aplicaciones (“aplicaciones elásticas”) se adaptan a cualquier ancho de banda del que puedan disponer

11

Necesidades del servicio de transporte para aplicaciones habituales

Aplicación

Transferencia de archivos

Correo electrónico

Documentos web

Audio/video tiempo real

Almacenam. audio/video

Juegos interactivos

Mensajería instantánea

Pérdida datos

Sin pérdidas

Sin pérdidas

Sin pérdidas

Tolerante

Tolerante

Tolerante

Sin pérdidas

Ancho de banda

Elástico

Elástico

Elástico

audio: 5kbps-1Mbps

video:10kbps-5Mbps

Igual que arriba

Pocos kbps

Elástico

Sensible tiempo

no

no

no

sí, 100 ms

sí, pocos sg

sí, 100 ms

sí y no

12

Servicios de protocolos de transporte en Internet

Servicio TCP Orientado a conexión: se

necesita el establecimiento de una conexión entre los procesos cliente y servidor

Transporte fiable entre procesos emisor y receptor

Control de flujo: el emisor no desbordará al receptor

Control de congestión: el emisor se retrae cuando la red está sobrecargada

No proporciona temporización

Servicio UDP

Transferencia de datos no fiable entre procesos emisor y receptor

No conlleva establecimiento de conexión, no es fiable, no tiene control de flujo ni control de congestión, no proporciona temporización

¿Por qué no se prescinde de UDP?

Porque consume menos recursos y para algunas aplicaciones puede ser suficiente

13

Aplicaciones Internet: protocolos de transporte y aplicación

Aplicación

Correo electrónico

Acceso terminal remoto

Web

Transferencia de ficheros

Streaming multimedia

Telefonía Internet

Protocolo capa

Aplicación

SMTP [RFC 2821]

Telnet [RFC 854]

HTTP [RFC 2616]

FTP [RFC 959]

propietaria

(p.e. RealNetworks)

propietaria

(p.e., Vonage,Dialpad)

Protocolo capa

Transporte subyacente

TCP

TCP

TCP

TCP

TCP o UDP

Típicamente UDP

14

Web y HTTP

RFC1945 (HTTP/1.0)RFC2616 (HTTP/1.1)

15

World Wide Web (literalmente: “telaraña extendida por el mundo”)

Desarrollado en el CERN (Conseil Européen pour la Recherche Nucléaire) por Tim Berners-Lee en 1989

La www es un enorme servicio distribuido cliente-servidor

Definiciones:

Páginas Web: documentos distribuidos por Internet

Sitio: locación que proporcionan páginas web

Hipermedia: objetos enlazados dentro de las páginas web (texto, audio, video, ..)

Navegador: herramienta cliente para visualizar las páginas web

16

Navegador Web

Visualiza las páginas web (cliente)

Tres componentes

Controlador (teclado, ratón)

Protocolos del cliente (acceso documento)

Intérpretes (visualización)

17

Uniform Resource Locator (URL)Localizador de Recursos Uniforme

Cada objecto en la red está identificado de forma única por un localizador (una URL)

Protocolo (método): protocolo cliente usado

Host: dirección IP o nombre de la estación de trabajo

Puerto: servicio web en el servidor (80 por defecto)

Ruta: camino hacia el objeto dentro del servidor web

http://www.someschool.edu/someDept/pic.gif

nombre del host nombre ruta

18

Documentos web (I)

Agrupados en 3 categorías

Estáticos

Documentos almacenados

en el servidor

El cliente consigue una copia

Fichero de texto ASCII (con etiquetas)

Lenguaje marcado hipertexto

Lenguajes usados:

HTML, XML, XSL, XHTML

Dinámicos

Activos

Solicitud de página web estática

19

Documentos web (II)

Documento dinámico

Creado en el servidor bajo demanda y enviado al cliente

Puede variar de solicitud a solicitud

Programas usados:

Common Gateway Interface (Interfaz de Pasarela Común) - CGI (obsoleto e ineficiente)

CGI, un documento cada petición

Solución, usar un script

Script: código fuente empotrado en el documento, ejecutado por el servidor

Preprocesador de Hipertexto (PHP)

Páginas de Servidor Java (JSP). Java

Páginas Activas de Servidor (ASP). Visual Basic

Solicitud de página web dinámica

20

Documentos web (III)

Documento activo

Programa ejecutado en el cliente

Se envía una copia del documento o un script al cliente

Programas cliente

Applets Java. Programa en Java en el servidor. Ejecutable directamente o HTML con la dirección del applet incluida como etiqueta

JavaScripts, igual que los scripts en dinámicos. Está en código fuente en lenguaje JavaScript

Solicitud de página web activa

21

Aspectos generales de HTTP

Usa TCP como protocolo de transporte:

El cliente inicia la conexión TCP al servidor, puerto 80

El servidor acepta la conexión TCP procedente del cliente

Se intercambian los mensajes HTTP entre el navegador del cliente y el servidor Web

La conexión TCP se cierra al finalizar

HTTP es lo que se conoce como “sin estado”

El servidor no mantiene información de las peticiones que el cliente ha hecho

22

Conexiones HTTP

HTTP no persistente

Se envía un único objeto en una conexión TCP

Una nueva conexión para cada objeto en la página web

HTTP/1.0 usa HTTP no persistente

HTTP persistente

Se pueden enviar varios objetos en una misma conexión TCP entre cliente y servidor

HTTP/1.1 usa conexión persistente por defecto

23

Conexión HTTP no persistente

Ejemplo: fichero de texto con un enlace a una imagen

Cada conexión conlleva 3 mensajes TCP

La solicitud se envía en el 3º handshake (apretón de manos)

Nueva conexión para cada objeto

1 para el fichero

1 para la imagen

24

El mismo ejemplo de antes con HTTP persistente:

Sólo una conexión

La solicitud de la imagen se envía por separado

Conexión HTTP persistente

25

Formato del mensaje HTTP

4 secciones

Dos tipos de mensajes HTTP: petición, respuesta

Mensaje de petición (solicitud) HTTP: ASCII (formato que puede leer una persona)

26

Mensaje de petición HTTP (I)

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu

User-agent: Mozilla/4.0

Accept-language: fr

(extra carriage return, line feed)

Protocolo (método): (GET, POST, comandos HEAD)

Retorno de carro, alimentación de línea

Indica fin del mensaje

27

Algunos (no todos) tipos de métodos en la Línea de Petición:

GET: petición de un documento a un servidor

Más usado. Cuerpo vacío

Puede aportar información usando los parámetros URL de la línea de petición

http://www.somesite.com/animalsearch?monkeys&banana

HEAD: solicita sólo información del documento, no el propio doc.

Ej: hora del último cambio

Cuerpo vacío en la respuesta

PUT: envía un documento al servidor (sólo HTTP 1.1)

Contrario de GET

POST: envía información del cliente al servidor

Envía información para añadir a la página web o para modificarla

Ej.: página web con una forma de entrada

La entrada se incorpora en el cuerpo, no como parte de la URL

Mensaje de petición HTTP (II)

28

Cabecera de Petición:

Opcional, de 0 a varias líneas

Información adicional enviada al servidor

Mensaje de petición HTTP (III)

Cabecera Descripción

User-agent Identifica al programa cliente

Accept Muestra el formato media que puede aceptar el cliente

Accept-charset Muestra el conjunto de caracteres que puede aceptar el cliente

Accept-encoding Muestra el esquema de codificación que puede aceptar el cliente

Accept-language Muestra el idioma que puede aceptar el cliente

Authorization Muestra los permisos que tiene el cliente

Host Muestra el host y el número de puerto del cliente

Date Muestra la fecha actual

Upgrade Especifica el protocolo de comunicación preferido

Cookie Devuelve la cookie al servidor

If-Modified-Since Si el fichero se modifica desde una fecha determinada

29

HTTP/1.1 200 OK

Connection: close

Date: Thu, 06 Aug 1998 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 …...

Content-Length: 6821

Content-Type: text/html

data data data data data ...

datos,

p.e. fichero HTML pedido

Mensaje de respuesta HTTP

30

Códigos de estado de respuesta HTTP

Algunos códigos de ejemplo:

200 OK

Petición con éxito, objeto solicitado después en este mensaje

301 Redireccionado permanente

Objeto solicitado quitado, nueva localización especificada después en este mensaje (Localización)

400 Petición incorrecta

Mensaje de petición no entendido por el servidor

404 No encontrado

Documento pedido no encontrado en este servidor

505 Versión de HHTP no soportada

31

Cabecera de Respuesta:

Opcional, de 0 a varias líneas

Información adicional enviada desde el servidor

Mensaje de respuesta HTTP

Header Description

Date Muestra la fecha actual

Upgrade Especifica el protocolo de comunicación preferido

Server Proporciona información del servidor

Set-Cookie El servidor pide al cliente que guarde una cookie

Content-Encoding Especifica el esquema de codificación

Content-Language Especifica el idioma

Content-Length Muestra la longitud del documento

Content-Type Especifica el tipo de media

Location Pide al cliente que envíe la respuesta a otro sitio

Accept-Ranges El servidor aceptará los rangos pedidos de bytes

Last-modified Proporciona fecha y hora del último cambio

32

Ejemplo de petición HTTP GET

El cliente obtiene una imagen

Puede aceptar formatos gif y jpeg

El servidor proporciona la imagen codificada

33

Ejemplo de petición HTTP PUT

El cliente envía una página para colocar en el servidor

El cuerpo contiene la página

El servidor devuelve el resultado de la ejecución del script CGI en el cuerpo

34

Peticiones condicionales HTTP

El cliente puede incluir una condición en su petición

El servidor envía una respuesta si se cumple la condición o informa de lo contrario

Principalmente usado para modificaciones de fecha y hora

GET http://www.MyServer.com/info/file1 HTTP/1.1 Línea de petición

If-Modified-Since: Wed, Jan 06 00:00:00 GMT Cabecera

Línea en blanco

HTTP/1.1 304 Not Modified Línea de estado

Date: Thu, Jan 07 01:20:48 GMT Cabecera

Server: MyServer.com

Línea en blanco

(Empty Body) Cuerpo vacío

Petición si cambia

después del 6 de

enero a las 0 horas

No

modificado,

por tanto no

envía la

página

35

Cookies (I)

La web se diseñó como una entidad “sin estado” El servidor no mantiene información de las peticiones pasadas del cliente.

Pero hoy en día se dan situaciones tales como: Una tienda electrónica puede usar una cookie para sus clientes. Cuando un cliente selecciona un artículo y

lo inserta en el carrito de la compra, el servidor envía al navegador del cliente una cookie que contiene la

información sobre el artículo como el precio unitario, por ejemplo. Si el cliente selecciona un segundo

artículo, la cookie se actualiza con la nueva información, y así sucesivamente. Cuando el cliente termina

de hacer la compra y quiere pagar, se recupera la última cookie y se calcula el precio total.

El sitio que restringe el acceso a clientes registrados sólo envía una cookie al cliente cuando éste se

registra por primera vez. En sucesivos accesos, sólo se aceptan a aquellos clientes que envían la cookie

apropiada.

Un portal web usa la cookie de un modo similar. Cuando un usuario selecciona sus páginas favoritas, se

elabora y envía una cookie. Si se accede de nuevo al sitio, se envía la cookie al servidor para mostrar lo

que el cliente busca.

Una cookie también se usa por agencias publicitarias. Una agencia de publicidad puede colocar banners

añadidos en algún sitio web principal que a menudo visitan los usuarios. La agencia de publicidad

suministra sólo una URL que da la dirección de la agencia de publicidad en vez del propio banner. Cuando

un usuario visita el sitio web principal y pulsa el icono de la corporación, se envía una petición a la agencia

de publicidad. La agencia de publicidad envía el banner solicitado, pero también incluye una cookie con el

ID del usuario. Cualquier futuro empleo de los banners añade a la base de datos qué perfiles de

comportamiento tiene el usuario. La agencia de publicidad ha averiguado los intereses del usuario y puede

vender este información a terceros. El empleo de las cookies ha generado muchas polémicas. Se espera

que se encuentren nuevas normas regulatorias para preservar la privacidad de los usuarios.

36

Cookies (II)

Proceso de creación de Cookies El servidor recibe una petición desde el cliente y almacena

cierta información (cookie) en una base de datos

Nombre de dominio, nombre de usuario, marca de tiempo,

etc

El servidor incluye la cookie en la respuesta que envía al cliente

En la línea de cabecera

El cliente almacena la cookie localmente por nombre de dominio

del servidor

Sistemas de ficheros locales y asociados al perfil del usuario

Uso de la cookie En la petición el navegador busca una cookie almacenada

localmente

Si existe, se envía al servidor que “reconocerá” al usuario

En la línea de cabecera

37

Ejemplo de cookie (I)

Juguetería on line

1) Petición

2) Carta vacía con código 12343 + página con juguetes

3) El cliente pide un juguete

4) El servidor actualiza el carrito y envía una página con el precio total

5) El cliente envía datos de pago

6) El servidor le confirma la compra

Mientras la cookie no se borre, el servidor la recuerda

38

Ejemplo de cookie (II)

La figura muestra un caso en el cual una tienda electrónica puede beneficiarse delempleo de las cookies. Supongamos que un comprador quiere comprar un juguete deuna tienda electrónica llamada BestToys. El navegador del comprador (el cliente) envíauna petición al servidor BestToys. El servidor crea un carro vacío que hace compras(una lista) para el cliente y asigna un ID al mismo (por ejemplo, 12343). El servidorentonces envía un mensaje de respuesta, que contiene las imágenes de todos losjuguetes disponibles, con un enlace bajo cada juguete que selecciona el juguete si sepulsa. Este mensaje de respuesta también incluye la cookie en la cabecera cuyo valores 12343. El cliente ve las imágenes y almacena el valor de la cookie en un archivollamado BestToys. La cookie no se revela al comprador. Ahora el comprador seleccionauno de los juguetes y hace clic en él. El cliente envía una petición, pero incluye el ID12343 en la cabecera de la cookie. Aunque el servidor pueda haber estado ocupado yolvidado a este comprador, cuando recibe la petición y comprueba la cabecera,encuentra el valor 12343 como cookie. El servidor sabe que el cliente no es nuevo;busca el carro de la compra con ID 12343. La lista del carro de la compra está abierta yel juguete seleccionado se añade a la lista. El servidor envía otra respuesta alcomprador para decirle el precio total y pedirle que realice el pago. El compradorproporciona la información sobre su tarjeta de crédito y envía una nueva petición con elID 12343 como cookie. Cuando la petición llega al servidor, ve otra vez el ID 12343,

acepta la orden y el pago, y responde con una confirmación.

39

Cachés web (servidor proxy)

El usuario envía una petición al servidor proxy

El servidor proxy mira su caché

Si la respuesta no está almacenada en la caché, el proxy envía la petición al servidor que corresponda

Las respuestas entrantes se envían y almacenan en el proxy

El servidor proxy reduce la carga del servidor original y mejora su latencia

Servidor proxy: computador que guarda copia de las respuestas de peticiones

recientes

Objetivo: satisfacer la petición del cliente sin involucrar al servidor original

cliente

Servidor

proxy

cliente

Servidor

original

Servidor

original

40

Más sobre la caché web

Doble papel del servidor proxy

El servidor proxy actúa tanto comocliente como servidor

Cuando recibe la petición de uncliente del cual tiene la respuesta,actúa como SERVIDOR y le envía larespuesta al cliente

Cuando recibe la petición de uncliente del cual NO tiene larespuesta, actúa como CLIENTE yle envía la petición al servidororiginal

Cuando recibe la respuesta delservidor original, la almacena yactúa otra vez como SERVIDORenviando la respuesta al cliente

Típicamente la caché la instala el ISP (universidad, empresa, ISP residencial, ...)

¿Por qué la caché web?

Reduce el tiempo de respuesta para la petición del cliente

Reduce el tráfico

¿Cuánto tiempo almacenar la caché?

Mientras la información tenga vigencia. Por ejemplo, un día en agencias de noticias

Ir añadiendo nuevas informaciones sin quitar la existente manteniendo la información el tiempo que se considere oportuno