View
240
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended