Computer Networking: A Top Down Approach Featuring the Internet, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2008. Material original de:

Presentación del tema: "Computer Networking: A Top Down Approach Featuring the Internet, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2008. Material original de:"— Transcripción de la presentación:

1 Computer Networking: A Top Down Approach Featuring the Internet, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2008. Material original de: J.F Kurose and K.W. Ross All Rights Reserved Arquitectura de redes

2 Algunas aplicaciones en red r E-mail r Web  Mensajer í a instant á nea r Acceso remoto  Compartici ó n P2P r Juegos multi-usuario  Streaming de v í deo  Telefon í a por internet  V í deo-conferencia  Computaci ó n masivamente distribuida

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

4 Arquitectura Cliente-servidor servidor: m Servidor siempre encendido m IP fija m Granjas para escalado clientes: m Se comunican con el servidor m Intermitentemente conectados  Pueden tener IP din á micas m No se comunican entre ellos

5 Arquitectuas P2P puras r Servidores no siempre encendidos r Los sistemas se comunican entre ellos arbitrariamente r Los peers (pares) pueden estar intermitentemente conectados r Los pares pueden cambiar de IP r ejemplo: Gnutella Á ltamente escalable Dif í ciles de gestionar

6 H í bridos de cliente-servidor y P2P Napster m 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

7 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 r Nota: Las aplicaciones con arquitectura P2P tienen procesos cliente y servidor

8 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 o servidor proceso TCP (buffers, Variables) socket cliente o servidor Internet controlado por el SO Controlado por el programador  API: (1) elecci ó n del protocolo de transporte, (2) se fijan los par á metros

9 Direccionamiento r Para que un proceso pueda recibir mensajes necesita un identificador  Cada ordenador tiene una idrecci ó n IP de 32 bits r Pregunta: ¿es suficiente con la IP del ordenador donde corre para identificar al porceso? r 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. r Ejemplos de puertos: m HTTP: 80 m Mail: 25  M á s sobre esto luego

10 Protocolos de las aplicaciones  Tipos de mensajes intercambiados. Ej: mensajes de petici ó n y respuesta r 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: r Definidos en RFCs r Facilitan la interoperabilidad r Ej: HTTP, SMTP Protocolos propietarios: r Ej: KaZaA Definen:

11 ¿Qu é servicio de transporte necesita? Pérdidas r Algunas aplicaciones pueden tolerar pérdidas (ej: audio) r 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.

12 Requisitos de transporte de aplicaciones Aplicación file transfer e-mail Web real-time audio/vídeo audio/vídeo Juegos interactivos Mensajería instantánea Pérdidas Sin Tolerante Sin Ancho de Banda elástico audio: 5kbps-1Mbps vídeo:10kbps-5Mbps idem Pocos kbps elástico Respuesta no sí, 100’s msec sí, pocos secs sí, 100’s msec sí y no

13 Protocolos de transporte en internet TCP:  Orientado a conexi ó n: setup required between client and server processes r Transporte fiable entre proceso emisor y receptor r 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: r 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?

14 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 SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] propietarios (e.g. RealNetworks) propietarios (e.g., Dialpad) Protocolo de nivel de transporte TCP TCP o UDP típicamente UDP

15 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 r Cada object es direccionable por una URL r URL: www.gsyc.es/images/urjc.gif Nombre host path

16 HTTP HTTP: HyperText Transfer Protocol  Protocolo de nivel de aplicaci ó n del Web r Modelo cliente/servidor m cliente: navegador que pide, recibe y muestra objetos  servidor: env í a objetos como respuesta a peticiones r HTTP 1.0: RFC 1945 r HTTP 1.1: RFC 2068 PC (Firefox) Servidor (Apache) Mac (Safari) HTTP request HTTP response

17 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”! r Hay que mantener la historia pasada (estado) r Si el servidor o el cliente se caen, sus visiones del estado pueden ser inconsistentes y deben reconciliarse NOTA

18 Conexiones HTTP HTTP no-persistente  Se env í a como mucho un objeto en una conexi ó n. r 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. r HTTP/1.1 usa conexiones persistentes por defecto

19 HTTP No persistente Supongamos 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)

20 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

21 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 ó n del fichero Inicio de la conexi ó n TCP RTT petici ó n de fichero RTT fichero recibido tiempo

22 HTTP Persistente Resumen del no-persistente: r necesita 2 RTTs por objecto  El SO tiene que reservar y liberar los recursos para cada conexi ó n TCP r 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: r client issues new request only when previous response has been received r Un RTT para cada objeto referenciado Persistent con pipelining: r 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

23 Mensaje de petici ó n en HTTP r En HTTP hay dos tipos de mensajes:  Mensaje de petici ó n HTTP: m ASCII (formato “legible”) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: 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

24 Mensaje petici ó n: formato general

25 “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

26 Tipos de m é todos HTTP/1.0 r GET r POST r HEAD  Pide al servidor que no incluya el objeto en la respuesta, s ó lo la cabecera HTTP/1.1 r GET, POST, HEAD r PUT m Sube un fichero en el cuerpo a un path especificado en el campo URL r DELETE m Borra un fichero especificado en el campo URL

27 Mensaje de respuesta 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... L í nea de estado (c ó digo y frase explicativa) L í neas cabecera datos, ej., fichero HTML pedido

28 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 m Documento pedido no encontrado en el servidor 505 HTTP Version Not Supported In first line in server->client response message. Algunos ejemplos:

29 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 al puerto 80 de gsyc.es telnet gsyc.es 80 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!

30 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: m 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

31 Cookies: manteniendo “estado” (cont.) cliente servidor petici ó n http usual msg respuesta 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 ó n espec í fica cookie acci ó n espec í fica cookie servidor crea el ID 1678 para usuario entrada en la base de datos acceso Acceso Cookies amazon: 1678 ebay: 8734 Cookies ebay: 8734 Cookies amazon: 1678 ebay: 8734 Unos d í as despu é s:

32 Cookies (cont.) ¿Qu é proporcionan?  autorizaci ó n r Carritos de la compra r recomendaciones r Sesiones de usuario (Web e-mail) Cookies y privacidad: r Permiten a los sitios “aprender” sobre ti r 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

33 Web caches (proxy server) r 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 m 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 Proxy server cliente HTTP request HTTP response HTTP request HTTP response servidor original servidor original

34 M á s sobre cach é s r Puede haber caches tanto en el cliente como en el servidor r Tipicamente las caches las instala el ISP (universidad, empresa, ISP residencial…) ¿Por qu é Web cache? r 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

35 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: r servidor: la respuesta no contiene el objeto si no se ha modificado: HTTP/1.0 304 Not Modified cache servidor Msg Petici ó n HTTP If-modified-since: Respuesta HTTP HTTP/1.0 304 Not Modified objecto no modificado Msg Petici ó n HTTP If-modified-since: Respuesta HTTP HTTP/1.0 200 OK object modified

36 Correo Electr ó nico Tres componentes: r Agentes de usuario r Servidores de correo r SMTP: Simple Mail Transfer Protocol Agente de Usuario r a.k.a. “lector de correo”  Creaci ó n, edici ó n y lectura de mensajes de correo r e.g., Eudora, Outlook, elm, evolution… r Los mensajes entrantes se almacenan en el servidor Buz ó n de usuario cola de mensajes salientes servidor correo servidor correo agente usuario servidor correo SMTP agente usuario agente usuario agente usuario agente usuario agente usuario

37 Servidores de correo electr ó nico Elementos: r buzones contienen mensajes entrantes para el usuario r cola de mensajes de correo salientes (pendiente de enviar) r protocolo SMTP entre los servidores de correo para enviar los mensajes de correo m “client”: servidor enviando correo m “server”: servidor recibiendo correo servidor correo servidor correo agente usuario servidor correo SMTP agente usuario agente usuario agente usuario agente usuario agente usuario

38 Correo electr ó nico: SMTP [RFC 2821] r Usa TCP para transferir de forma fiable mensajes de correo entre cliente y servidor usando el puerto 25 r Tres fases: m handshaking (saludo) m transferencia de mensajes m cierra  Interacci ó n orden/respuesta m comandos: texto ASCII  respuesta: c ó digo de estado y frase r Los mensajes deben codificarse en ASCII 7-bits

39 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 servidor correo servidor correo AU 1 2 3 4 5 6

40 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: S: 250 alice@crepes.fr... Sender ok C: RCPT TO: 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

41 Prueba de SMTP  telnet servername 25  Ver á s una respuesta: 220 del servidor r Usa los mensajes HELO, MAIL FROM, RCPT TO, DATA, QUIT Lo anterior te permite enviar un mensaje de correo sin un agente de usuario

42 SMTP: resumen r 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: r HTTP: pull r SMTP: push  Ambos usan c ó digos de estado y expliaciones ASCII que se pueden leer r HTTP: cada objeto se encapsula en su propio mensaje  SMTP: se env í an m ú ltiples objetos en un mensaje multi-parte

43 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., m To: m From: m Subject: ¡diferente de los comandos SMTP! r cuerpo  El mensaje tiene s ó lo caracteres ASCII cabecera cuerpo L í nea en blanco

44 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 multimedia tipo, subtipo, m é todo usado para codificar Versi ó n MIME Datos codificados

45 Protocolos de acceso al correo r SMTP: entrega y almacenamiento hasta el servidor destino r Protocolo de acceso: descarga desde el servidor m POP: Post Office Protocol [RFC 1939] autorizaci ó n (agente servifor) y descarga m IMAP: Internet Mail Access Protocol [RFC 1730] M á s opciones (m á s complejo) Permite manipular los mensajes almacenados en el servidor m HTTP: Hotmail, Yahoo! Mail, etc. AU Servidor de correo del emisor AU SMTP protocolo acceso Servidor de correo del receptor

46 POP3 Fase de autorizaci ó n r Comandos de cliente:  user: declara usuario  pass: password r Respuestas del servidor m +OK  -ERR Fase de transacci ó n Comandos de cliente:  list: lista mensajes por n ú meros  retr: descarga mensaje por n ú mero  dele: delete r quit C: list S: 1 498 S: 2 912 S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: 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

47 POP3 e IMAP M á s de POP3 r 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 r POP3 no mantiene estado entre sesiones IMAP r Mantiene los mensajes en un sitio: el servidor r Permite al usuario organizar mensajes en carpetas r IMAP mantiene estado entre sesiones:  Nombres de carpetas y las relaciones de los n ú meros de mensajes en cada carpeta