Tema2_RC1415.ppt

REDES DE COMPUTADORESAplicacin 2-*

Some material copyright 1996-2010J.F Kurose and K.W. Ross, All Rights ReservedTema 2: Nivel de Aplicacin

2.1 Principios de las aplicaciones en red2.2 DNS2.3 Web y HTTP2.4 Programacin de la interfaz de acceso al servicio de transporte fiable de Internet en JAVA:Sockets con TCP2.5 Programacin de la interfaz de acceso al servicio de transporte no fiable de Internet en JAVA: Sockets con UDP

Tema 2: Nivel de aplicacinObjetivos: Conceptos, aspectos de implementacin de protocolos de aplicacin en redmodelos de servicio del nivel de transporteparadigma cliente-servidorparadigma P2PAprender ms sobre protocolos estudiando dos protocolos de la capa de aplicacin de internetHTTPDNSProgramando aplicaciones en redsocket APIAplicacin 2-*

Algunas aplicaciones en rede-mailwebmensajera instantneaAcceso remotoComparticin de archivos P2PJuegos online multiusuarioStreaming de video (ej. YouTube)

Voz sobre IP (VoIP)VideoconferenciaComputacin en la nube (cloud) Aplicacin 2-*

Creando una aplicacin en red escribir programas queCorran en (diferentes) sistemas finalesSe comuniquen a travs de la redEj: software de un servidor web qu se comunica con el software navegador web no hay que hacer programas para el ncleo de la redLos dispositivos del ncleo no corren las aplicaciones de los usuariosAl hacerlo en los sistemas finales se acelera el tiempo de desarrollo y propagacin de la aplicacinAplicacin 2-*

Tema 2: Nivel de aplicacinAplicacin 2-*2.1 Principios de las aplicaciones en red2.2 DNS2.3 Web y HTTP2.4 Programacin de la interfaz de acceso al servicio de transporte fiable de Internet en JAVA:Sockets con TCP2.5 Programacin de la interfaz de acceso al servicio de transporte no fiable de Internet en JAVA: Sockets con UDP

Arquitectura de las aplicacionescliente-servidorpeer-to-peer (P2P)hbrido ente cliente-servidor y P2PAplicacin 2-*Direccin IP: identifica de forma nica a los equipos (sistemas finales, routers,) conectados a una red TCP/IP. La asigna el ISP de forma esttica (fija) o dinmica (variable). Ms en breveNota

Arquitectura Cliente-servidorServidor:Equipo siempre-ONDireccin IP fijaGranjas de servidores por escalabilidadClientes:Se comunican con el servidorDe manera intermitenteCon IPs dinmicas o fijasNo se comunican directamente entre ellosAplicacin 2-*

Arquitectura P2PEl servidor no est siempre-ONLos sistemas finales se comunican entre si de manera arbitrariaLos peers se comunican de manera intermintente y con direcciones IP distintas en cada ocasin

muy escalable pero difcil de gestionarAplicacin 2-*

Hbrido cliente-servidor y P2PSkypeAplicacin voz-sobre-IP arquitectura P2PServidor centralizado: encontrar direccin IP del interlocutor remotoConexin cliente-cliente: directa (sin pasar por el servidor) Mensajera instantneaLa charla entre 2 usuarios es P2PServidor centralizado: detecta presencia y localizacin de los clientesLos usuarios registran su IP con el servidor central al conectarseLos usuarios dialogan con el servidor central en busca de la IP de su contacto

Aplicacin 2-*

Cmo se implementa la capa de aplicacin?Aplicacin 2-*

InternetInterfaz UsuarioInterfaz UsuarioProtocolo aplicacinA_PDUT_SAPT_SAPNavegadores Web, p.e: Mozilla firefox, Internet Explore, Safari,

Transporte

Aplicacin

Transporte

Aplicacin

El protocolo de nivel de aplicacin define:Tipo de mensaje a intercambiar, e.g., peticin, respuesta Sintaxis del mensajeNmero de campos y delimitacin entre ellosSemntica del mensajeSignificado de los camposReglas de cmo y cundo los procesos envan y responden a los mensajesProtocolos de dominio pblico:definidos en RFCsPermiten la inter-operatibilidadEj: HTTP, SMTPProtocolos propietarios:Ej: SkypeAplicacin 2-*

Comunicacin entre procesosproceso: programa que corre en un equipo (en nuestro caso implementa un determinado protocolo de aplicacin).En un mismo equipo, 2 procesos se comunican usando comunicacin entre-procesos (la proporciona SO).Procesos en equipos diferentes se comunican intercambiando mensajes (PDU) usando los servicios de comunicacin (en general los proporciona SO)Proceso cliente: proceso que inicia la comunicacinProceso servidor: proceso que espera a ser contactado

nota: las aplicaciones P2P combinan ambos procesos, cliente y servidorAplicacin 2-*

Sockets (SAP)Un proceso enva/recibe mensajes a/de su socketAnaloga con una puerta:El proceso emisor enva el mensaje a travs de la puerta de salidaEl proceso emisor confa en la infraestructura de transporte que hay detrs de la puerta, encargada de llevar el mensaje hasta la puerta del receptorInternetControlado por el SO

Controlado por el desarrolladorAPI: (1) eleccin del servicio de transporte ; (2) posibilidad de fijar parmetros (a continuacin...) Aplicacin 2-*

Cmo se identifica el socket?Para enviar una carta a un amigo es necesario saber su direccin para que llegue al buzn de su casa.Cada sistema final tiene un direccin IP nica de 32 bits.

P: es suficiente con la direccin para hacer que llegue la carta a un amigo? R: No, varias personas pueden estar viviendo en el misma casa.Varios protocolos de aplicacin pueden estar ejecutndose en un sistema final.Navegador, lector de correo, Skype,

Aplicacin 2-*A las direcciones IP se les asocia un nombre, que es el que se utiliza para identificar a los equipos.Por ejemplo, www.dte.us.es = 150.214.141.196Ms sobre nombres en el apartado siguienteNota

Cada protocolo de aplicacin se identifica por un nmero de puerto.El nmero de puerto usado para identificar al proceso cliente y servidor en general no coinciden. Ej. de nmero de puerto:Servidor HTTP: 80Servidor Email: 25Servidor DNS: 53

La ICANN (Internet Corporation for Assigned Names and Numbers), se encarga del registro de los puertos de protocolos de aplicacin pblicos.http://www.iana.org/assignments/port-numbers Existen diferentes tipos de puertos.Un socket queda identificado por:Direccin IP.Nmero de puerto.Aplicacin 2-*Cmo se identifica el socket?

Aplicacin 2-*

InternetInterfaz UsuarioInterfaz UsuarioDir IP cliente, puertoEjemploServidor web DTE150.214.141.196, 80

Transporte

Aplicacin

Transporte

Aplicacin

Localhost suele tener asociado la IP 127.0.0.1, aunque puede ser otra. Ms en el tema 4Localhost: Conectando 2 procesos del mismo sistema finalAplicacin 2-*Notalocalhost: es un nombre especial que est asociado a una direccin IP especial que sirve para identificar al propio sistema final. Permite probar aplicaciones en red en un nico sistema final sin necesidad de estar conectado a una red.En general permite comunicar procesos en un mismo sistema final usando los servicios de comunicaciones de Internet.

P: Por qu el Servicio de Comunicacin del sistema final es capaz de distinguir a cada proceso?

Qu servicios de transporte necesito?Perdida de datosAlgunas aplicaciones toleran algo de perdida (ej: audio, video)Otras requieren 100% de fiabilidad (ej: login, transferencia de archivos)TemporizacinAlgunas aplicaciones precisan de retardos cortos para ser 'efectivas' (ej: telefona por internet, juegos interactivos)Tasa de transferenciaAlgunas requieren una tasa mnima para funcionar adecuadamente (ej: multimedia)Otras, conocidas como aplicaciones elsticas, hacen uso de la tasa disponible en cada momentoSeguridadEncriptacin, integridad de los datos, Aplicacin 2-*

Requisitos de algunas aplicaciones comunesAplicacin

transferencia ficherose-mailpginas webaudio/vdeo en tiempo realaudio/vdeo archivadojuegos interactivosmensajera instantneaPrdida datos

sin prdidassin prdidassin prdidastolerante

tolerantetolerantesin prdidasTasa transferencia

elsticaelsticaelsticaaudio: 5kbps-1Mbpsvdeo:10kbps-5Mbpscomo la anteriorvarios kbpselsticaSensible temp.

nononoS, 100s ms

S, pocos segsS, 100s msS y noAplicacin 2-*

Servicios de los protocolos de InternetServicio TCP:Orientado a conexin: requiere acuerdo previo entre los procesos cliente y servidor antes de iniciar la transferenciaTransporte fiable entre procesos emisor y receptorControl de flujo: emisor no saturar al receptorControl de congestin: uso equitativo del ancho de bandaNo provee: temporizacin, garantizar un ancho de banda, seguridadServicio UDP:Transporte ligero, no orientado a conexin y no confiable entre procesos emisor y receptorNo provee: acuerdo previo entre procesos, fiabilidad, contol de flujo, control de congestin, temporizacin, ancho de banda garantizado, ni seguridad.

P: Qu utilidad tiene UDP? Aplicacin 2-*

Ejemplos: Protocolos de aplicacin y transporteAplicacin

e-mailacceso remotoweb transferencia de ficherosstreaming multimedia

telefona IP

Traduccin de nombres en direcciones IP

Protocolo del nivel de aplicacin

SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]HTTP (ej: YouTube), RTP [RFC 1889]SIP, RTP, propietario(ej: Skype)

DNS [RFC 1034]

Protocolo de transporte

TCPTCPTCPTCPTCPo UDP

usualmente UDP

TCP o UDP (usual)

Aplicacin 2-*

DNS: Domain Name Systempersonas: muchos IDs:DNI, nombre, n seguridad social...equipos y routers de Internet:direcciones IP (32 bit) sirven para direccionar datagramasnombre, ej: www.google.com usado por humanosP: cmo mapeamos entre direcciones IP y nombres y viceversa?Domain Name System:Base de datos distribuida implementada con una jerarqua de servidores de nombresProtocolo de nivel de aplicacin: equipos y servidores de nombres se comunican para resolver nombres (traduccin de direcciones y de nombres)nota: caracterstica fundamental de Internet, implementada en el nivel de aplicacin!Aplicacin 2-*

DNS por qu no centralizar el servicio de DNS?nico punto de fallaVolumen de trficoDistancia a la base de datosMantenimientoen definitiva...no sera escalable!Servicio DNSTraduccin de nombre a IP (directa)Traduccin de IP a nombre (inversa)Creacin de aliasAlias de email@dominioDistribucin de cargaServidores web replicados: conjunto de Ips para un nico nombre cannicoAplicacin 2-*Usa UDPEl cliente enva mensajes al puerto 53 del servidor a travs del socket.

DNS: cach y actualizacin entradasUna vez que un servidor DNS aprende una traduccin, sta se guarda en una memoria cachLas traducciones ms habituales suelen estar en cach y no hace falta consultar a otros DNS.Las entradas de la cach caducan tras un tiempo determinado (timeout) Hay mecanismos de actualizacin y notificacin entre DNS propuestos por el IETF standardRFC 2136Aplicacin 2-*

DNS: cmo funciona? (simplificacin)Cuando una aplicacin en un sistema final consulta al servicio DNS la direccin IP asociada a un nombre de equipo, o viceversa. El servicio DNS busca en su cach de DNS para ver si tiene una entrada para la direccin IP o el nombre, segn corresponda, puede ocurrir que encuentre la entrada.En este caso le devuelve a la aplicacin la IP o el nombre. no encuentre la entrada.Enva un mensaje (DNS_PDU) de Solicitud de DNS al servidor de DNS que tenga configurado y se espera a recibir la Respuesta de DNS del servidor con la informacin solicitada que entregar a la aplicacin que solicit su servicio.En caso de que no sea posible resolver un nombre o una direccin IP avisa a la aplicacin que solicit su servicioAplicacin 2-*Un servidor de DNS al recibir una Solicitud DNS se comporta como el servicio de DNS en el sistema final, busca en su cach y consulta a otros servidores de DNS si no encuentra la informacin solicitada.Nota

DNS: Cmo funciona? Cont.Aplicacin 2-*tiempotiempoNivelAplicacinNivelAplicacinServicio TransporteNo fiableEnvo DNS_PDURecepcin DNS_PDUServicio no confirmadoEnvo DNS_PDURecepcin DNS_PDUClienteServidor

WWW (World-Wide-Web)Primero, un repasoUna pgina web contiene una serie de objetosEsos objetos pueden ser: fichero HTML, imagen JPEG, applet Java, fichero audio,Consiste en un fichero base HTML que incluye objetos referenciadosCada objeto es direccionable a travs de su URLEjemplo de URL (Uniform Resource Locator):

Aplicacin 2-*

Formato del lenguaje HTMLSirve para elaborar las pginas web, desde 1991. Se usan elementos con etiquetas entre . Cada elemento suele tener 4 campos: una etiq. inicio () y una etiq. cierre (), unos atributos (en la de inicio) y un contenido (entre ambas). define inicio documento (opcional)pginadefine inicio/fin documentocabecerael contenido de la cabecera (informacin no visible al usuario, como ttulo, estilos, metainformacin, etc)cuerpodefine el cuerpo, contiene:de a encabezadostablacrea una tabla filas/colsenlacehipervnculo: al hacer click en enlace se solicita la pgina de URL.imagen referenciada, el navegador la carga a continuacin desde URL para visualizarla.Aplicacin 2-*

Vistazo de HTTPHTTP: HyperText Transfer ProtocolProtocolo de nivel de aplicacin para la webModelo cliente/servidorcliente: navegador que pide, recibe y muestra los objetos webservidor: proceso que enva los objetos pedidos por los clientesPC corriendoIExplorerServidor corriendoservidor web ApacheLinux corriendoFirefoxPeticin HTTPPeticin HTTPRespuesta HTTPRespuesta HTTPAplicacin 2-*

NotaVistazo de HTTP (cont.)Usa TCP:El cliente inicia una conexin TCP (crea un socket), con el puerto 80 del servidorEl servidor acepta la conexin TCP del clienteSe intercambian mensajes HTTP (de nivel de aplicacin) el navegador web (cliente) y el servidor web (servidor)Se cierra la conexin TCPHTTP es sin estadoEl servidor no guarda informacin acerca de las peticiones anteriores de los clientesLos protocolos que recuerdan el estado son complejos:El histrico de estados anteriores se debe mantenerSi el cliente o el servidor caen sus estados pueden ser inconsistentes y tienen que sincronizarseAplicacin 2-*

Tipo de conexiones HTTPHTTP no-persistenteCmo mximo se enva un objeto por cada conexin TCP.

HTTP persistenteSe pueden enviar multiples objetos por una misma conexin TCP entre cliente y servidor.

Aplicacin 2-*

HTTP No-persistenteSupongamos que un usuario introduce esta URL:1a. La aplicacin cliente HTTP solicita establecer una conexin TCP con el proceso servidor en el equipo www.dte.us.es al puerto 802. El cliente HTTP enva un mensaje de peticin (qu contiene la URL) en la conexin TCP establecida. El mensaje indica que el cliente quiere el objeto /personal/smartin/lab3/referencias.html

1b. La aplicacin servidora HTTP en el equipo www.dte.us.es, que estaba a la espera de conexiones TCP en el puerto 80, acepta esta conexin, notificndoselo al cliente.3. El servidor HTTP recibe la peticin, forma un mensaje de respuesta conteniendo el objeto solicitado y lo enva a travs de su socket.tiempo(contiene texto y referencias a 13 objetos)Aplicacin 2-*http://www.dte.us.es/personal/smartin/lab3/referencias.html1a.1b.2.3.AplicacinClienteAplicacinServidora4. El servidor HTTP solicita cierre de la conexin TCP. (Tambin lo ha podido hacer el cliente)4.5. El cliente HTTP recibe el mensaje de respuesta, conteniendo el fichero HTML, muestra el contenido y lo analiza encontrando 13 referencias a otros objetos.6. Los pasos 1-5 se repiten para cada una de los 13 objetos (4 imgenes y 9 scripts JavaScript) con URLs distintas.ServicioTransportefiable

HTTP No-persistente: Tiempo de respuestaRTT (Round-Trip Time, tiempo de ida y vuelta): el tiempo que tarda desde que se solicita un servicio al nivel de transporte hasta que este est completado o solicita envo mensaje peticin y se empieza a recibir primeros bytes respuesta.Tiempo de respuesta (TR):1 RTT, inicio conexin.1 RTT, peticin HTTP y primeros bytes de respuesta HTTP.Tiempo transmisin bytes objeto solicitado (TTO). Aplicacin 2-*Peticin Solicitud conexinRTTRTTtiempotiempoTR= 2RTT + TTO

NivelAplicacinIndicacin Solicitud conexinNivelAplicacinServicio TransportefiableRespuesta Solicitud conexinConfirmacin Solicitud conexinEnvo HTTP_PDURecepcin HTTP_PDUServicio confirmadoServicio no confirmadoEnvo HTTP_PDURecepcin HTTP_PDUTTOClienteServidor

HTTP PersistenteInconvenientes del HTTP no-persistente:Requiere 2 RTTs por objeto (ms lo que tarde en transmitirse dicho objeto).Sobrecarga SO con cada conexin TCP

HTTP persistenteEl servidor mantiene la conexin abierta tras enviar la respuestaLos siguientes mensajes HTTP entre el mismo cliente y el servidor se envan por la conexin abiertaEl cliente enva una nueva peticin cuando acaba de recibir el objeto anteriorCada objeto referenciado tarda slo 1 RTT (ms lo que tarde en transmitirse dicho objeto).Aplicacin 2-*Conexiones HTTP en paralelo:Los navegadores a menudo abren varias conexiones TCP en paralelo para obtener los objetos referenciados ms rpidamente, los cuales se piden de forma simultnea por cada conexin (sean estas persistentes o no).Nota

Mensajes HTTP (HTTP_PDU)Hay 2 tipos de mensajes:Peticin HTTP:Enviada por el clienteTransporta informacin necesaria (HTTP_PCI) para solicitar un objeto del servidor (HTTP_UD)Se compone de caracteres ASCII (texto inteligible) Respuesta HTTP:Enviada por el servidorTransporta si procede el objeto (HTTP_UD) solicitado por el cliente adems de informacin de control (HTTP_PCI)

Aplicacin 2-*

: Carriage-Return : \r: Line-Feed: \nMensaje de Peticin HTTPLnea de peticin(comandos GET, POST, HEAD)Lneas de cabecera\r y \n al principio de una lnea indican el final de las lneas de cabeceraAplicacin 2-*GET /index.html HTTP/1.1\r\nHost: www-net.cs.umass.edu \r\nUser-Agent: Firefox/3.6.10\r\nAccept: text/html,Aplicacin/xhtml+xml\r\nAccept-Language: en-us,en;q=0.5\r\nAccept-Encoding: gzip,deflate\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7\r\nKeep-Alive: 115\r\nConnection: keep-alive\r\n\r\nCarcter retorno-de-carroCarcter nueva-lneaNota

Algunas Cabeceras HTTP que puede enviar el clienteHost: hostname (nombre del servidor web)User-Agent: versin_del_navegadorAccept-xxx: lista_de_preferencias_para_xxxConnection: keep-aliveEl cliente solicita al servidor una conexin persistente al servidorKeep-Alive: nnnEl cliente solicita al servidor el tiempo mximo de nnn segundos para las conexiones persistentesAplicacin 2-*

PDUMensaje de Peticin HTTP: formato generalAplicacin 2-* lnea de peticinCuerpoPCIUD UD lneas de cabecera

Subida de parmetros (de un formulario)Una pgina web a menudo incluye un formulario con unos parmetros que se envan al servidor. Hay 2 mtodos de envo:Mtodo POST:Los parmetros se suben al servidor en el CUERPO de la peticinMtodo GET:Las entradas se pasan al servidor en la propia URL, con la lnea de peticin (separado por ? y &):

GET /buscar?monos&platanos HTTP/1.1\r\nHost: www.unbuscador.com\r\n.Aplicacin 2-*

Tipos de mtodosHTTP/1.0 (RFC-1945)GETPOSTHEADIdntico al GET, salvo que no se incluye el objeto en el cuerpo de la respuesta (slo las cabeceras correspondientes)HTTP/1.1 (RFC-2616)GET, POST, HEADPUTSube el fichero en el CUERPO de la peticin al path especificado en la URLDELETEBorra del servidor el fichero especificado en la URLAplicacin 2-*

Mensaje de Respuesta HTTPlnea de estado(protocolo,cdigo estado,frase estado)lneas de cabeceraCUERPO ej: archivo HTML pedidoAplicacin 2-*HTTP/1.1 200 OK\r\nDate: Sun, 26 Sep 2010 20:09:20 GMT\r\nServer: Apache/2.0.52 (CentOS)\r\nLast-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\nETag: "17dc6-a5c-bf716880"\r\nAccept-Ranges: bytes\r\nContent-Length: 2652\r\nKeep-Alive: timeout=10, max=100\r\nConnection: Keep-Alive\r\nContent-Type: text/html; charset=ISO-8859-1\r\n\r\ndata data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data ... UDPCI

Algunas Cabeceras HTTP que puede enviar el servidorDate: fecha (en el que se enva el mensaje)Last-Modified: fecha (en la que el objeto se modific por ltima vez)Server: versin_del_servidorContent-Type: tipo_del_objeto (HTML, imagen, ) Content-Length: tamao_del_cuerpo (en bytes) Connection: keep-aliveEl servidor confirma al cliente que esa conexin ser persistenteKeep-Alive: timeout=ttt, max=nnnEl servidor cerrar la conexin persistente tras ttt segundos de inactividad o tras nnn segundos en cualquier caso.Aplicacin 2-*

Cdigos de estado (Respuesta)200 OKPeticin exitosa, el objeto solicitado va a continuacin...301 Moved PermanentlyEl objeto se ha movido permanentemente, se especifica la ubicacin nueva (cabecera Location:)400 Bad RequestMensaje de peticin no entendido por el servidor404 Not FoundEl documento solicitado no se encuentra en el servidor505 HTTP Version Not SupportedEl cdigo de estado aparece en la primera lnea de la respuesta del servidor al cliente.Algunos cdigos habituales:Aplicacin 2-*

Prueba el HTTP t mismo1. Telnet a tu servidor Web favorito:

Abre conexin TCP al puerto 80(puerto HTTP por defecto) de www.dte.us.es

Todo lo que escribas se enva alltelnet www.dte.us.es 802. Escribe una peticin GET:

GET /docencia/ HTTP/1.1Host: www.dte.us.es

Escribe esto (con doble-enter al final) para enviar un GET request reducido a un servidor HTTP 3. Mira el mensaje de respuesta del servidor!Aplicacin 2-*(o puedes usar Wireshark!)P. Qu ocurre si envo hola?

Cookies: manteniendo el estadoMuchos servicios web usan cookies4 componentes:1) cabecera Set-cookie: en el mensaje de respuesta2) cabecera Cookie: en el mensaje de peticin3) archivo de cookies almacenado por el equipo del usuario y gestionado por el navegador4) base de datos back-end en el servidor webEjemplo de uso:Susana siempre accede a Internet desde su PCVisita una tienda online (ej: Amazon) por primera vezAl llegar las peticiones, el servidor crea: Un ID nicoUna entrada para esa ID en la base de datos back-endAplicacin 2-*

Cookies: Ejemplo de usoServidor deAMAZONAlmacn cookies...y 1 semana despusBack-endAplicacin 2-*Cliente visita AMAZON

Cookies: discusinPosibles aplicaciones:autorizacincarritos de la comprarecomendacionesmantenimiento de sesin de usuario (ej: webmail)Aplicacin 2-*cookies y la intimidad:las cookies permiten a los sitios conocer mucho sobre tipuedes estar dando informacin personal a esas pginas: emails, nombres, etc...Nota

Servidor Proxy (Cach de la Web)El navegador se configura para usar el Proxy-Cach.Entonces se envan todas las peticiones HTTP al Proxyobjeto en la cach: se devuelve el objetosi no: cach solicita el objeto al servidor original y lo devuelve al cliente.Objetivo: satisfacer la peticin del cliente sin involucrar al servidor web originalclienteProxyserverclientePeticin HTTPPeticin HTTPservidor originalservidor originalRespuesta HTTPRespuesta HTTPAplicacin 2-*

Ms acerca del ProxyEl cach acta como cliente (del servidor original) y como servidor (del cliente)Normalmente se instalan en los ISP (universidades, compaias, ISPs residenciales)por qu es interesante?Reducir el tiempo de respuesta de la peticin del clienteReducir el trfico de enlace de datos de una institucinPermitir a proveedores pequeos entregar de forma eficiente los contenidos (algo que tambin permite P2P)Aplicacin 2-*

GET CondicionalProxy (o cach del navegador): especifica la fecha de la copia cacheada en la peticin HTTPIf-modified-since: Servidor: en la respuesta van cabeceras ya) no va ningn objeto si la copia no se ha modificado... HTTP/1.0 304 Not Modifiedb) o bien se enva el objeto si est modificado, junto con la fecha de modificacin:Last-modified:Proxy o CachServidorPeticin HTTPIf-modified-since:Si el objeto NO fue modificado despus de

Peticin HTTPIf-modified-since:Respuesta HTTPHTTP/1.0 200 OKLast-modified:

Aplicacin 2-*Que el servidor web no enve el objeto si la cach tiene una versin actualizada del mismoObjetivoSi el objeto S fue modificado despus de

Programacin de SocketsSocket APISe introdujo en BSD4.1 UNIX, 1981Los sockets se crean, usan y liberan de forma explcita por las aplicacionesParadigma cliente/servidor 2 tipos de servicios:No fiable, orientado a datagramas (UDP)Fiable, orientado a flujo de bytes (TCP)Un interfaz del equipo local, creado por una aplicacin y controlado por el SO (una puerta) por la que el proceso de aplicacin puede tanto envar/recibir mensajes a/desde otros procesos remotos (o incluso locales)Objetivo: aprender cmo se programa una aplicacin cliente/servidor que se comunique usando socketsAplicacin 2-*

Protocolo aplicacinAplicacin 2-*

InternetInterfaz UsuarioInterfaz UsuarioDir IP cliente, puertoServidorDir IP servidor, puertoCliente

Transporte

Aplicacin

Transporte

Aplicacin

Programacin de Sockets con TCPSocket: la interfaz entre el proceso y el protocolo de transporte extremo a extremo (TCP o UDP)servicio TCP: transferencia fiable de un flujo de bytes (stream) de un proceso a otroControlado por el desarrollador de la aplicacinControlado por el Sist.OperativoCliente oservidorCliente o servidorinternetAplicacin 2-*Controlado por el desarrollador de la aplicacinControlado por el Sist.Operativo

Programacin de Sockets con TCPEl cliente debe contactar con el servidorProceso servidor debe estar corriendo primeroEl servidor debe haber creado un socket (una puerta) que aceptar la solicitud de conexin de cualquier cliente.El cliente para contactarcrear un socket TCP localespecificar la IP y el n de puerto del proceso servidorAl crearse el socket en el cliente se crea una conexin TCP con el servidorCuando es contactado por un cliente, el servidor TCP crea un nuevo socket para que el proceso servidor se comunique con lPermite al servidor hablar con mltiples clientesEl n de puerto de origen se usa para distinguir a los clientes [ms en Tema 3]Punto de vista de la aplicacinTCP provee una transferencia fiable y ordenada de bytes entre un cliente y un servidorAplicacin 2-*

Interaccin cliente/servidor con TCPServidor (corriendo en hostid)ClienteAplicacin 2-*hostid = IP o nombreEnviar primitiva: Conexin.requestEsperar primitiva:Conexin .confirmEnviar primitiva: Data.requestEsperar primitiva: Conexin.indicationEnviar primitiva: Conexin.responseEsperar primitiva: Data.indication

Stream de Javastream (flujo) es una secuencia de caracteres/bytes que entran o salen a/de un procesoinput stream est conectado a una fuente de entrada de datos, como un teclado o un socketoutput stream est conectado a una fuente de salida de datos, como un monitor o un socketEj: en el cliente vamos a usar 3 streams y 1 nico socketAplicacin 2-*a la capa de transporte

Ejemplo: aplicacin con sockets TCPAplicacin de ejemplo cliente/servidor TCP:1) el cliente lee una lnea de entrada standard (inFromUser stream) , y la enva al servidor por un socket (outToServer stream)2) el servidor lee la lnea de un socket3) el servidor convierte la lnea a maysculas y la enva de vuelta al cliente por el socket4) el cliente la lee del socket (inFromServer stream) y la muestra en el monitor Aplicacin 2-*

Ejemplo: cliente Java (TCP)import java.io.*; import java.net.*; class TCPClient {

public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence;

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());

Aplicacin 2-*

Ejemplo: cliente Java (TCP) (cont) BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close(); } } Creainput streamconectado al socketEnvia lnea al servidorLee lnea del servidorAplicacin 2-*Cierra socket(cierra la puerta al salir!)Enviar primitiva: Data.requestEsperar primitiva: Data.indication

Ejemplo: servidor Java (TCP)import java.io.*; import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));

Aplicacin 2-*

Ejemplo: servidor Java (TCP) (cont)

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence); connectionSocket.close(); } } } Lee lnea del socketCrea output stream conectado al socketEscribe lneaal socketFin del bucle while,vuelve y espera la conexin de otro clienteAplicacin 2-*Esperar primitiva: Data.indicationEnviar primitiva: Data.request

Programacin de Sockets con UDPUDP: no hay conexin entre cliente y servidorSin negociacinEl cliente explcitamente adjunta la direccin IP y puerto de destino de cada mensaje (PDU) que quiera enviar.El servicio de transporte debe pasar al servidor la direccin IP y el puerto del mensaje recibido.UDP: los datos transmitidos pueden ser recibidos de forma desordenada, o algunos pueden perderseUDP proporciona una transferencia no fiable de datagramas (grupos de bytes) entre el cliente y el servidor

Aplicacin 2-*

Interaccin cliente/servidor con UDPcrea socket-datagrama,puerto= x, para solicitudes entrantesserverSocket = DatagramSocket()Aplicacin 2-*Enviar primitiva: Data.requestEsperar primitiva: Data.indicationhostid = IP o nombreServidor (corriendo en hostid)

Ejemplo: cliente (con datagramas UDP)Aplicacin 2-*

Ejemplo: cliente Java (UDP)import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Creainput streamCrea socket UDP en puerto libre Traduce nombre del servidor a direccin IPusando DNSAplicacin 2-*

Ejemplo: cliente Java (UDP) (cont) DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData(),0, String(receivePacket.getLength()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } } Crea T_IDU con A_PDU a enviar,longitud, direccin IP y n de puertoEnva T_IDURecibimosT_IDUAplicacin 2-*Enviar primitiva: Data.requestEsperar primitiva: Data.indicationCreamos T_IDUen blanco

Ejemplo: servidor Java (UDP)import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Crea socket UDP en puerto 9876 conocido por clienteCreamos T_IDUen blancoRecibimosT_IDUAplicacin 2-*Esperar primitiva: Data.indication

Ejemplo: servidor Java (UDP) (cont)

String sentence = new String(receivePacket.getData(),0,receivePacket.getLength()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } } } Obtiene de la T_ICI la direccin IP y n de puerto del emisorEnvaT_IDUFin del bucle while,vuelve y espera la llegadade otro datagramaCrea T_IDU con A_PDU a enviar, longitud, direccin IP y n de puertoAplicacin 2-*

EJERCICIOSRedes de Computadores Tema 2: Nivel de AplicacinAplicacin 2-*

Pr1: Verdadero o Falso?Aplicacin 2-*a) Un usuario solicita una pgina web que consta de texto y 3 referencias a imgenes. Para obtener esa pgina, el cliente enva un mensaje de solicitud y recibe cuatro mensajes de respuesta.b) Dos pginas web diferentes (www.mit.edu/research.html y www.mit.edu/students.html ) se pueden enviar a travs de la misma conexin persistente.c) Con las conexiones no persistentes entre un navegador y un servidor de origen, un nico segmento TCP puede transportar dos mensajes de solicitud HTTP distintos.d) La lnea de cabecera Date: del mensaje de respuesta HTTP indica cundo el objeto fue modificado por ltima vez.e) Los mensajes de respuesta HTTP nunca incluyen un cuerpo de mensaje vaco.

Pr2: Aplicacin-TransporteAplicacin 2-*Un cliente HTTP desea recuperar un documento web que se encuentra en una URL dada. Inicialmente, la direccin IP del servidor HTTP es desconocida.Qu protocolos de la capa de aplicacin y de la capa de transporte, adems de HTTP, son necesarios en este escenario?

Pr3: Cabeceras Cliente HTTPAplicacin 2-*La siguiente cadena ASCII ha sido capturada cuando el navegador enviaba un mensaje GET HTTP.

Responda a las siguientes cuestiones, indicando en que parte del mensaje GET HTTP se encuentra la respuesta a la cuestin:a) Cul es la URL del documento solicitado?b) Qu versin de HTTP se est ejecutando en el navegador?c) Solicita el navegador una conexin persistente o no?d) Cul es la direccin IP del host que corre el navegador?e) Qu tipo de navegador enva el mensaje? Por qu es necesario indicar el tipo de navegador en el mensaje?f) Cuntos bytes ocupa la HTTP_PDU enviada por el cliente?g) Cuntos bytes de HTTP_UD transporta?

NOTA: La anchura de las lneas del recuadro es 60 caracteresGET /cs453/index.html HTTP/1.1Host: gaia.cs.umass.eduUser-Agent: Mozilla/5.0 (Windows;U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)Accept: ext/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, image/png, */*;q=0.5Accept-Language: en-us,en;q=0.5Accept-Encoding: zip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-aliveNOTA: es un retorno de carro y es un fin de lnea.

Pr4: Cabeceras Servidor HTTPAplicacin 2-*La siguiente cadena muestra la respuesta devuelta por el servidor web al mensaje del problema anterior.

Responda a las siguientes cuestiones, indicando en que parte del mensaje respuesta HTTP se encuentra la respuesta a la cuestin:a) Ha encontrado el servidor el documento? En qu momento se suministra la respuesta con el doc.?b) Cundo fue modificado por ltima vez el documento?c) Cuntos bytes contiene el documento devuelto?d) Cules son los primeros 5 bytes del documento devuelto?e) Ha acordado el servidor emplear una conexin persistente? (si es que s diga el tiempo mximo de inactividad que se permite)f) Cuntos bytes de HTTP_UD transporta?g) Cuntos bytes ocupa la HTTP_PDU enviada por el servidor?

NOTA: La anchura de las lneas del recuadro es 60 caracteresHTTP/1.1 200 OKDate: Tue, 07 Mar 2008 12:39:45 GMTServer: Apache/2.0.52 (Fedora)Last-modified: Sat, 10 Dec 2005 18:27:46 GMTETag: 526c3-f22-a88a4c80Accept-Ranges: bytesContent-Length: 3874Keep-Alive: timeout=max=100Connection: keep-aliveContent-Type: text/html; charset=ISO-8859-1...Aqu seguira el resto del documento HTML...NOTA: es un retorno de carro y es un fin de lnea.

Pr5: Tiempo de transferencia (I)Aplicacin 2-*Suponga que en su navegador hace clic en un vnculo a una pgina web. La direccin IP correspondiente al URL asociado no est almacenada en la cach de su host local, por lo que es necesario realizar una bsqueda DNS. Suponga que el tiempo de ida y vuelta (RTT) de la consulta al servidor DNS es RTTDNSSuponga tambin que la pgina web asociada con el vnculo es un pequeo fichero HTML (lo que supone un tiempo de transmisin despreciable) y que no contiene referencias a otros objetos.Sea RTT0 el tiempo RTT entre el host local y el servidor web.Cunto tiempo transcurre desde que el cliente hace clic en el vnculo hasta que recibe el objeto?

Pr6: Tiempo de transferencia (II)Aplicacin 2-*Continuando con el Problema 5, suponga que el archivo base HTML hace referencia a 8 objetos muy pequeos que se encuentran en el mismo servidor.Despreciando los tiempos de transmisin, para cargar la pgina web completa, cunto tiempo transcurre si se utilizaa) HTTP no persistente sin conexiones TCP en paralelo?b) HTTP no persistente con 5 conexiones en paralelo?c) 1 nica conexin HTTP persistente?

Pr7: Proxy (I)Supongamos una universidadTamao objetos web = 100 KbitsTasa de peticiones media de los navegadores a los servidores web originales = 15 peticiones/segRetardo Internet del router superior a cualquier servidor original = 2 segLas peticiones web son pequeas y no generan retardo.En consecuencia tenemos:Uso de la LAN = 15%Uso del enlace = 100%Al tener un uso del enlace del 100% (La/R ~ 1) las colas pueden crecen indefinidamente (y con ellas el retardo de cola).

Aplicacin 2-*

Pr7: Proxy (II)Propuesta de solucin:Aumentar ancho de banda del enlace a 10 Mbps

Uso de la LAN ?Uso del enlace?Retardo total medio?Comentarios?

Aplicacin 2-*

Pr7: Proxy (III)Otra posible solucin:Instalar proxy-cachSupongamos tasa xito 0.4:40% peticiones satisfechas inmediatamente60% peticiones satisfechas por el servidor original

Uso de la LAN ?Uso del enlace?Retardo total medio?Comentarios?

ServidoresoriginalesInternetRedinstitutional10 Mbps LANEnlace de acceso1,5 MbpsProxyinstitucionalAplicacin 2-*

************************

**************Nota SMG 2012: Lo de si y no de la mensajera instantnea******************************************************************************************************************************

Documents

Tema2_RC1415.ppt