Transcript Arquitecturas de redes - Curso: Portal de Docencia de la ETSIT

Arquitectura de redes
Material original de:
J.F Kurose and K.W. Ross
All Rights Reserved
Computer Networking:
A Top Down Approach
Featuring the Internet,
4th edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2008.
Algunas aplicaciones en red
 E-mail
 Telefonía por internet
 Web
 Vídeo-conferencia
 Mensajería
 Computación




instantánea
Acceso remoto
Compartición P2P
Juegos multi-usuario
Streaming de vídeo
masivamente
distribuida
Arquitecturas de las aplicaciones
 Cliente-servidor
 Peer-to-peer (P2P)
 Híbridas entre cliente-servidor y P2P
Arquitectura Cliente-servidor
servidor:



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 Cliente: proceso
Proceso: programa
que inicia la
ejecutando en un
comunicación
computador.
Proceso Servidor:
 Dos procesos en la misma
proceso que espera a
máquina se comunican
ser contactado
mediante comunicación
inter-proceso (definida
por el SO).
 Nota: Las aplicaciones
con arquitectura P2P
 procesos en máquinas
tienen procesos cliente
diferentes se
y servidor
comunicancan
intercambiando mensajes
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
cliente o
servidor
cliente o
servidor
proceso
Controlado por
el programador
proceso
socket
socket
TCP
(buffers,
Variables)
Internet
TCP
(buffers,
Variables)
controlado
por el SO
 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
Definen:
 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, SMTP
Protocolos propietarios:
 Ej: KaZaA
¿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 online, 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 Pérdidas
file transfer
e-mail
Web
real-time audio/vídeo
Sin
Sin
Sin
Tolerante
audio/vídeo Tolerante
Juegos interactivos Tolerante
Mensajería instantánea Sin
Ancho de Banda
Respuesta
elástico
no
elástico
no
elástico
no
audio: 5kbps-1Mbps sí, 100’s msec
vídeo:10kbps-5Mbps
idem
sí, pocos secs
Pocos kbps
sí, 100’s msec
elástico
sí 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
correo
Acceso remoto
Web
transferencia de ficheros
streaming multimedia
Telefonía sobre internet
Protocolo de nivel
de aplicación
Protocolo de nivel
de transporte
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
propietarios
(e.g. RealNetworks)
propietarios
(e.g., Dialpad)
TCP
TCP
TCP
TCP
TCP 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 (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
NOTA
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
Conexiones HTTP
HTTP no-persistente
 Se envía como mucho
un objeto en una
conexión.
 HTTP/1.0 es nopersistente
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 persistente
Supongamos que un usuario introduce:
www.unauniv.es/algundepartamento/home.html
(contiene texto y
referencias a 10
imágenes jpeg)
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
time
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
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.
time 6. Se repiten los pasos 1-5 para
cada uno de los 10 objetos
jpeg
4. El servidor HTTP cierra la
conexión TCP
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
Inicio de la
conexión TCP
RTT
petición
de fichero
Tiempo de
transmisión
del fichero
RTT
fichero
recibido
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”)
Línea de petición
(GET, POST,
HEAD)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
líneas de Connection: close
cabecera Accept-language:fr
CR / LF
Indica fin del
mensaje
(extra CR/LF)
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
Línea de estado
(código y frase
explicativa)
Líneas
cabecera
datos, ej.,
fichero
HTML pedido
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 ...
Códigos de respuesta
In first line in server->client response message.
Algunos ejemplos:
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
Prueba HTTP desde un cliente
1. Telnet a tu servidor favorito:
telnet gsyc.es 80
Abre conexión TCP con el puerto 80
(default HTTP server port) at gsyc.es.
Todo lo que escribas se envía al
puerto 80 de gsyc.es
2. Escribe una petición HTTP:
GET /~vmo/ HTTP/1.1
Host: gsyc.es
Escribe esto (pulsa ENTER dos
veces), estás enviando esta petición
simple (pero completa):
GET petición al servidor HTTP
3. ¡Mira que te envía el servidor!
Estado en el servidor: cookies
La mayoría de los servidores
usa cookies
Componentes:
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
Cookies
ebay: 8734
Cookies
amazon: 1678
ebay: 8734
petición http usual msg
servidor
respuesta usual http +
crea el ID
Set-cookie: 1678 1678 para usuario
Petición http usual msg
cookie: 1678
respuesta usual http
Unos días después:
Cookies
amazon: 1678
ebay: 8734
servidor
Petición http usual msg
cookie: 1678
respuesta usual http
acción
específica
cookie
acción
específica
cookie
Cookies (cont.)
¿Qué proporcionan?
 autorización
 Carritos de la compra
 recomendaciones
 Sesiones de usuario
(Web e-mail)
NOTA
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
Web caches (proxy server)
Objetivo: responder a peticiones sin usar el servidor
 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
servidor
original
cliente
cliente
Proxy
server
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 HTTP
If-modified-since:
<date>
 servidor: la respuesta no
contiene el objeto si no se ha
modificado:
HTTP/1.0 304 Not
Modified
servidor
cache
Msg Petición HTTP
If-modified-since:
<date>
Respuesta HTTP
objecto
no
modificado
HTTP/1.0
304 Not Modified
Msg Petición HTTP
If-modified-since:
<date>
Respuesta HTTP
HTTP/1.0 200 OK
<data>
object
modified
Correo Electrónico
cola de
mensajes salientes
agente
usuario
Tres componentes:
 Agentes de usuario
 Servidores de correo
agente
usuario
servidor
correo
 SMTP: Simple Mail Transfer
SMTP
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
SMTP
servidor
correo
agente
usuario
SMTP
agente
usuario
servidor
correo
agente
usuario
agente
usuario
Servidores de correo electrónico
agente
usuario
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
agente
usuario
servidor
correo
SMTP
servidor
correo
agente
usuario
SMTP
agente
usuario
servidor
correo
agente
usuario
agente
usuario
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”
[email protected]
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
1
AU
2
servidor
correo
3
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
servidor
correo
4
5
AU
6
Ejemplo de interacción SMTP
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
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 correo
SMTP: 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 en
blanco
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
Versión MIME
método usado
para codificar
Datos multimedia
tipo, subtipo,
Datos codificados
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
Protocolos de acceso al correo
SMTP
SMTP
AU
Servidor de correo
del emisor
protocolo
acceso
Servidor de correo
del receptor
 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
POP3
Fase de autorización
 Comandos de cliente:
user: declara usuario
 pass: password
 Respuestas del servidor
 +OK
 -ERR

Fase de transacción
Comandos de cliente:
 list: lista mensajes por
números
 retr: descarga mensaje por
número
 dele: delete
 quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK el usuario se ha autenticado
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK el servidor POP3 cierra
POP3 e IMAP
Má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