Computer Networking: A Top Down Approach Featuring the Internet, 4th edition. Jim Kurose, Keith RossAddison-Wesley, July 2008.

Material original de:

J.F Kurose and K.W. Ross All Rights Reserved

Arquitectura de redes

Algunas aplicaciones en red

E-mail Web Mensajería

instantánea Acceso remoto Compartición P2P Juegos multi-usuario Streaming de vídeo

Telefonía por internet

Vídeo-conferencia Computación

masivamente distribuida

Arquitecturas de las aplicaciones Cliente-servidor Peer-to-peer (P2P) Híbridas entre cliente-servidor y P2P

Arquitectura Cliente-servidorservidor:

Servidor siempre encendido IP fija Granjas para escalado

clientes: Se comunican con el

servidor Intermitentemente

conectados Pueden tener IP dinámicas No se comunican entre ellos

Arquitectuas P2P puras

Servidores no siempre encendidos

Los sistemas se comunican entre ellos arbitrariamente

Los peers (pares) pueden estar intermitentemente conectados

Los pares pueden cambiar de IP

ejemplo: Gnutella

Áltamente escalable

Difíciles de gestionar

Híbridos de cliente-servidor y P2P

Napster Trnansferencia de ficheros P2P Búsqueda centralizeda:

• Peers registran contenido en un servidor central• Peers preguntan al mismo servidor para encontrar

información

Mensajería instantánea La conversación entre dos pares es P2P La detección/localización está centralizada:

• Los usuarios registran su IP en el servidor al estar on-line• Los usuarios contactan con el servidor central para

encontrar la dirección IP de sus amigos

Comunicación de procesos

Proceso: programa ejecutando en un computador.

Dos procesos en la misma máquina se comunican mediante comunicación inter-proceso (definida por el SO).

procesos en máquinas diferentes se comunicancan intercambiando mensajes

Proceso Cliente: proceso que inicia la comunicación

Proceso Servidor: proceso que espera a ser contactado

Nota: Las aplicaciones con arquitectura P2P tienen procesos cliente y servidor

Comunicación de procesos en Internet: Sockets

Los procesos envían/ reciben mensajes a/de su socket

socket se parece a buzón El proceso que envía mete

el mensaje en el buzón El proceo emisor confía en

que la infraestrucuta de transporte dejará en el buzón de destino el mensaje enviado

proceso

TCP(buffers,

Variables)

socket

cliente oservidor

proceso

TCP (buffers,

Variables)

socket

cliente oservidor

Internet

controladopor el SO

Controlado porel programador

API: (1) elección del protocolo de transporte, (2) se fijan los parámetros

Direccionamiento Para que un proceso

pueda recibir mensajes necesita un identificador

Cada ordenador tiene una idrección IP de 32 bits

Pregunta: ¿es suficiente con la IP del ordenador donde corre para identificar al porceso?

Respuesta: No, puede haber muchos procesos ejecutando en el mismo ordenador

El identificador incluye tanto la dirección IP como el número de puerto asociado con el proceso en el ordenador.

Ejemplos de puertos: HTTP: 80 Mail: 25

Más sobre esto luego

Protocolos de las aplicaciones Tipos de mensajes

intercambiados. Ej: mensajes de petición y respuesta

Sintaxis de los tipos de mensaje: campos en cada mensaje y su tipo

Semántica de los campos: información en cada campo

Reglas sobre cuándo y cómo se procesan los envíos y las recepciones.

Protocolos públicos: Definidos en RFCs Facilitan la

interoperabilidad Ej: HTTP, SMTPProtocolos propietarios: Ej: KaZaA

Definen:

¿Qué servicio de transporte necesita?

Pérdidas Algunas aplicaciones pueden

tolerar pérdidas (ej: audio) Otras no (ej: transferencia de

ficheros, sesión remota, etc), necesitan transmisión 100% fiable

Tiempo de respuesta Algunas aplicaciones

necesitan delays bajos para ser usables. Ej: juegos on-line, telefonía sobre internet, etc.

Ancho de Banda Algunas aplicaciones

(ej., multimedia) requieren un mínimo de ancho de banda para ser “efectivas”

Otras aplicaciones (“elásticas”) funcionan con lo que pueden obtener.

Requisitos de transporte de aplicaciones

Aplicación

file transfere-mail

Webreal-time audio/vídeo

audio/vídeoJuegos interactivos

Mensajería instantánea

Pérdidas

Sin SinSinTolerante

ToleranteToleranteSin

Ancho de Banda

elásticoelásticoelásticoaudio: 5kbps-1Mbpsvídeo:10kbps-5Mbpsidem Pocos kbps elástico

Respuesta

nononosí, 100’s msec

sí, pocos secssí, 100’s msecsí y no

Protocolos de transporte en internet

TCP: Orientado a conexión:

setup required between client and server processes

Transporte fiable entre proceso emisor y receptor

Control de flujo: el emisor no “ahoga” al receptor

Control de congestión: detiene al emisor si hay pérdidas

No proporciona: garantías de tiempo ni de ancho de banda

UDP: Transferencia no fiable

entre procesos emisores y receptores

No proporciona: establecimiento de conexión, fiabibilida, control de flujo, contrl de congestión, garantías de tiempo ni de ancho de banda

P: ¿por qué preocuparse? ¿por qué existe UDP?

Aplicaciones en Internet: protocolos

Aplicación

correoAcceso remoto

Web transferencia de ficherosstreaming multimedia

Telefonía sobre internet

Protocolo de nivelde aplicación

SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]propietarios(e.g. RealNetworks)propietarios(e.g., Dialpad)

Protocolo de nivelde transporte

TCPTCPTCPTCPTCP o UDP

típicamente UDP

Web y HTTP

Vocabulario Página Web consiste en objetos Objectos pueden ser ficheros HTML, imágenes

JPEG, Java applet, ficheros de audio,… Una página Web está formada por un fichero

HTML que incluye objetos Cada object es direccionable por una URL URL:

www.gsyc.es/images/urjc.gif

Nombre host path

HTTP

HTTP: HyperText Transfer Protocol

Protocolo de nivel de aplicación del Web

Modelo cliente/servidor cliente: navegador

que pide, recibe y muestra objetos

servidor: envía objetos como respuesta a peticiones

HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068

PC(Firefox)

Servidor (Apache)

Mac(Safari)

HTTP request

HTTP request

HTTP response

HTTP response

HTTP (cont.)

Usa TCP: cliente abre una conexión

TCP (crea un socket) con el puerto 80 del servidor

El servidor acepta la conexión TCP del cliente

Intercambio de mensajes HTTP (protocolo del nivel de aplicación) entre el cliente y el servidor

Se cierra la conexión TCP

HTTP “sin estado” El servidor no

mantiene información sobre peticiones pasadas del cliente

Los protocolos con estado son “complicados”!

Hay que mantener la historia pasada (estado)

Si el servidor o el cliente se caen, sus visiones del estado pueden ser inconsistentes y deben reconciliarse

NOTA

Conexiones HTTP

HTTP no-persistente Se envía como

mucho un objeto en una conexión.

HTTP/1.0 es no-persistente

HTTP Persistente Se pueden enviar

múltiples objectos sobre una misma conexión TCP entre un cliente y un servidor.

HTTP/1.1 usa conexiones persistentes por defecto

HTTP No persistenteSupongamos que un usuario introduce: www.unauniv.es/algundepartamento/home.html

1a. El cliente HTTP inicializa la conexión TCP con el servidor HTTP (proceso) en www.unauniv.es en el puerto 80

2. El cliente HTTP envía un mensaje de petición (que contiene la URL) a través del socket TCP. El mensaje indica que el cliente quiere el objecto algundepartamento/home.html

1b. El servidor HTTP en www.unauniv.es que espera conexiones TCP en el puerto 80 “accepta” la conexión y se lo notifica al cliente

3. El sevidor HTTP recibe el mensaje de petición, genera un mensaje de respuesta que contiene el objeto pedido y enviía el mensaje a su socket

time

(contiene texto y referencias a 10 imágenes jpeg)

HTTP no-persistente (cont.)

5. El cliente HTTP recibe el mensaje de respuesta, lo muestra y lo analiza (“parsea”). Al analizarlo encuentra 10 objetos jpeg referenciados.

6. Se repiten los pasos 1-5 para cada uno de los 10 objetos jpeg

4. El servidor HTTP cierra la conexión TCP

time

Tiempo de Respuesta

Definición de RRT: tiempo que tarda un paquete desde el cliente al servidor y vuelta.

Tiempo de respuesta: Un RTT para inicial la

conexión TCP Un RTT para la petición

HTTP y los primeros bytes de respuesta devueltos

Tiempo de transmisión total = 2RTT+transmisión

Tiempo de transmisióndel fichero

Inicio de laconexión TCP

RTT

peticiónde fichero

RTT

ficherorecibido

tiempo tiempo

HTTP Persistente

Resumen del no-persistente: necesita 2 RTTs por objecto El SO tiene que reservar y

liberar los recursos para cada conexión TCP

Los navegadores suelen abrir conexiones TCP en paralelo para conseguir los objetos

Persistente El servidor deja la conexión

abierta tras enviar la respuesta

Los mensajes HTTP siguientes del cliente y el servidor emisor se envían sobre la conexión

Persistente sin pipelining: client issues new request

only when previous response has been received

Un RTT para cada objeto referenciado

Persistent con pipelining: Por defecto en HTTP/1.1 El cliente envía la petición

tan pronto como encuentra el objeto

Como mínimo un RTT para todos los objetos referenciados

Mensaje de petición en HTTP

En HTTP hay dos tipos de mensajes: Mensaje de petición HTTP:

ASCII (formato “legible”)

GET /somedir/page.html HTTP/1.1Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr

(extra CR/LF)

Línea de petición(GET, POST,

HEAD)

líneas de cabecera

CR / LF Indica fin del

mensaje

Mensaje petición: formato general

“Subir” información

Método Post: Página Web incluye

frecuentemente un formulario

Los datos se suben en el cuerpo (body) de la petición

Método URL: Usa método GET Los datos se suben en el

campo URL de la línea de petición:

www.unsitio.com/animalsearch?mono&perro

Tipos de métodos

HTTP/1.0 GET POST HEAD

Pide al servidor que no incluya el objeto en la respuesta, sólo la cabecera

HTTP/1.1 GET, POST, HEAD PUT

Sube un fichero en el cuerpo a un path especificado en el campo URL

DELETE Borra un fichero

especificado en el campo URL

Mensaje de respuesta

HTTP/1.1 200 OK Connection closeDate: 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 ...

Línea de estado(código y frase

explicativa)

Líneas cabecera

datos, ej., fichero

HTML pedido

Códigos de respuesta

200 OK Petición exitosa, el objeto pedido va más adelante

301 Moved Permanently Objeto solicitado trasladado, se indica la nueva

localización más adelante en el mensaje (Location:)

400 Bad Request Mensaje de petición no entendido por el servidor

404 Not Found Documento pedido no encontrado en el servidor

505 HTTP Version Not Supported

In first line in server->client response message.Algunos ejemplos:

Prueba HTTP desde un cliente

1. Telnet a tu servidor favorito:

Abre conexión TCP con el puerto 80(default HTTP server port) at gsyc.es.Todo lo que escribas se envía alpuerto 80 de gsyc.es

telnet gsyc.es 80

2. Escribe una petición HTTP:

GET /~vmo/ HTTP/1.1Host: gsyc.es

Escribe esto (pulsa ENTER dosveces), estás enviando esta peticiónsimple (pero completa): GET petición al servidor HTTP

3. ¡Mira que te envía el servidor!

Estado en el servidor: cookiesLa mayoría de los

servidores usa cookiesComponentes:

1) Línea de cabecera cookie en el mensaje de respuesta HTTP

2) Línea de cabecera cookie en el mensaje de petición HTTP

3) Se mantiene un fichero con las cookies en el cliente (manejado por el cliente)

4) Base de datos en el servidor

Ejemplo: Vicente accede a

Internet siempre desde el mismo PC

Visita un sitio de comercio electrónico por primera vez

Cuando la petición inicial llega al servidor, crea un ID y una entrada en la base de datos para ese ID

Cookies: manteniendo “estado” (cont.)

cliente servidor

petición http usual msgrespuesta usual http

+Set-cookie: 1678

Petición http usual msg cookie: 1678

respuesta usual http

Petición http usual msg cookie: 1678

respuesta usual http

acciónespecífica

cookie

acciónespecífica

cookie

servidorcrea el ID

1678 para usuario

entrada en la base

de datos

acceso

Acces

o

Cookies

amazon: 1678ebay: 8734

Cookies

ebay: 8734

Cookies

amazon: 1678ebay: 8734

Unos días después:

Cookies (cont.)

¿Qué proporcionan? autorización Carritos de la

compra recomendaciones Sesiones de usuario

(Web e-mail)

Cookies y privacidad: Permiten a los sitios

“aprender” sobre ti Puedes proporcionar

correo y nombre Los buscadores usan

las cookies y la redirección para aprender todavía más

Sitios de publicidad consiguen información de varios sitios

NOTA

Web caches (proxy server)

El usuario configura el servidor para usar un proxy

El navegador envía todas las peticiones al proxy Si el el objeto está en

la cache: se devuelve En otro caso, se pide al

servidor original y se entrega al cliente almacenando copia en la cache

Objetivo: responder a peticiones sin usar el servidor

cliente

Proxyserver

cliente

HTTP request

HTTP request

HTTP response

HTTP response

HTTP request

HTTP response

servidor original

servidor original

Más sobre cachés

Puede haber caches tanto en el cliente como en el servidor

Tipicamente las caches las instala el ISP (universidad, empresa, ISP residencial…)

¿Por qué Web cache? Reducir el tiempo de

respuesta del servicio. Reducir el tráfico en el

acceso a internet de la institución (empresas, universidades…).

Permite a los generadores de contenidos “pobres” distribuir contenido a gran escala (si la red de caches es grande). También lo permiten las redes P2P

GET condicional

Objetivo: no me envíes el objeto si el que tengo es la última versión (dice la cache)

cache: especifica la fecha del objeto almacenado en la petición HTTPIf-modified-since: <date>

servidor: la respuesta no contiene el objeto si no se ha modificado: HTTP/1.0 304 Not Modified

cache servidor

Msg Petición HTTPIf-modified-since:

<date>

Respuesta HTTPHTTP/1.0

304 Not Modified

objecto no

modificado

Msg Petición HTTPIf-modified-since:

<date>

Respuesta HTTPHTTP/1.0 200 OK

<data>

object modified

Correo Electrónico

Tres componentes: Agentes de usuario Servidores de correo SMTP: Simple Mail

Transfer Protocol

Agente de Usuario a.k.a. “lector de correo” Creación, edición y lectura

de mensajes de correo e.g., Eudora, Outlook, elm,

evolution… Los mensajes entrantes se

almacenan en el servidor

Buzón de usuario

cola de mensajes salientes

servidorcorreo

servidorcorreo

agenteusuario

servidorcorreo

SMTP

SMTP

SMTPagenteusuario

agenteusuario

agenteusuario

agenteusuario

agenteusuario

Servidores de correo electrónico

Elementos: buzones contienen

mensajes entrantes para el usuario

cola de mensajes de correo salientes (pendiente de enviar)

protocolo SMTP entre los servidores de correo para enviar los mensajes de correo “client”: servidor

enviando correo “server”: servidor

recibiendo correo

servidorcorreo

servidorcorreo

agenteusuario

servidorcorreo

SMTP

SMTPagenteusuario

agenteusuario

agenteusuario

agenteusuario

agenteusuario

Correo electrónico: SMTP [RFC 2821]

Usa TCP para transferir de forma fiable mensajes de correo entre cliente y servidor usando el puerto 25

Tres fases: handshaking (saludo) transferencia de mensajes cierra

Interacción orden/respuesta comandos: texto ASCII respuesta: código de estado y frase

Los mensajes deben codificarse en ASCII 7-bits

Escenario: Envío de mensaje

1) Alicia usa su AU para componer un mensaje “to” bob@someschool.edu

2) El AU envía el mensaje a su servidor de correo; que se coloca en la cola de mensajes

3) El lado “cliente” del servidor abre una conexión TCP con el servidor de bot

4) El cliente eSMTP client envía el mensaje de Alicia sobre la conexión TCP

5) El servidor de correo de Bob coloca el mensaje de Alicia en el buzón de Bob

6) Bob arranca su agente de correo y lee el mensaje

AU

servidorcorreo

servidorcorreo AU

1

2 3 4 56

Ejemplo de interacción SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection

Prueba de SMTP

telnet servername 25 Verás una respuesta: 220 del servidor Usa los mensajes HELO, MAIL FROM, RCPT TO,

DATA, QUIT

Lo anterior te permite enviar un mensaje de correo sin un agente de usuario

SMTP: resumen

SMTP utilia conexiones TCP persistentes

SMTP exige que el mensaje (cabecera y cuerpo) estén en ASCII 7-bits

El servidor SMTP usa CRLF.CRLF para econtrar el final de mensaje

Comparación con HTTP: HTTP: pull SMTP: push

Ambos usan códigos de estado y expliaciones ASCII que se pueden leer

HTTP: cada objeto se encapsula en su propio mensaje

SMTP: se envían múltiples objetos en un mensaje multi-parte

Formato de los mensajes de correoSMTP: protocolo para

intercambiar msgs de correo

RFC 822: formato estándar para mensajes de texto:

Líneas de cabecera, e.g., To: From: Subject:¡diferente de los comandos

SMTP! cuerpo

El mensaje tiene sólo caracteres ASCII

cabecera

cuerpo

Línea enblanco

MIME: Extensiones multimedia

MIME: extensión multimedia al correo, RFC 2045, 2056

Líneas adicionales en la cabecera del msg para declarar el contenido multimedia

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data

Datos multimediatipo, subtipo,

método usadopara codificar

Versión MIME

Datos codificados

Protocolos de acceso al correo

SMTP: entrega y almacenamiento hasta el servidor destino Protocolo de acceso: descarga desde el servidor

POP: Post Office Protocol [RFC 1939]• autorización (agente <-->servifor) y descarga

IMAP: Internet Mail Access Protocol [RFC 1730]• Más opciones (más complejo)• Permite manipular los mensajes almacenados en el servidor

HTTP: Hotmail , Yahoo! Mail, etc.

AU

Servidor de correodel emisor

AU

SMTP SMTP protocoloacceso

Servidor de correodel receptor

POP3

Fase de autorización Comandos de cliente:

user: declara usuario pass: password

Respuestas del servidor +OK -ERR

Fase de transacciónComandos de cliente: list: lista mensajes por

números retr: descarga mensaje por

número dele: delete quit

C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK el servidor POP3 cierra

S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK el usuario se ha autenticado

POP3 e IMAPMás de POP3 Los ejemplos han

usado el modo “descarga y borra”.

Bob no podrá re-leer el mensaje si cambia de cliente

“Descarga y mantén”: copias de los mensajes en diferentes clientes

POP3 no mantiene estado entre sesiones

IMAP Mantiene los mensajes

en un sitio: el servidor Permite al usuario

organizar mensajes en carpetas

IMAP mantiene estado entre sesiones: Nombres de carpetas y

las relaciones de los números de mensajes en cada carpeta