slides Powerpoint - INF
Propaganda
Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M. Costa (slides baseados em [Kurose&Ross2003]) Parte 2: Camada de Aplicação Nossos objetivos: conceitual, aspectos de implementação de protocolos de aplicação para redes paradigma clienteservidor modelos de serviço aprenda sobre protocolos examinando algumas aplicações populares Outros objetivos do capítulo protocolos específicos: http ftp smtp pop dns programação de aplicações de rede socket API Cap. 2: Camada de Aplicação 2 Aplicações e Protocolo de Aplicação Aplicação: processos distribuídos que comunicam entre si rodam nos computadores (hosts) da rede como programas de usuário trocam mensagens entre si para realização da aplicação e.x., email, ftp, Web aplicação transporte rede enlace física Protocolos de aplicação fazem parte das aplicações definem mensagens trocadas e as ações tomadas usam serviços de comunicação das camadas inferiores aplicação transporte rede enlace física aplicação transporte rede enlace física Cap. 2: Camada de Aplicação 3 Aplicações de Rede Processo: programa executando num host. dentro do mesmo host: interprocess communication (definido pelo SO). processos executando em diferentes hosts se comunicam com um protocolo da camada de aplicação agente usuário: software que interfaceia com o usuário de um lado e com a rede de outro. implementa protocolo da camada de aplicação Web: browser E-mail: leitor de correio streaming áudio/vídeo: media player Cap. 2: Camada de Aplicação 4 Paradigma Cliente-Servidor Aplicações de rede típicas têm duas partes: cliente and servidor Cliente: aplicação transporte rede enlace física inicia comunicação com o servidor (“fala primeiro”) tipicamente solicita serviços do servidor, Web: cliente implementado no browser; e-mail: leitor de correio Servidor: fornece os serviços solicitados pelo cliente pedido resposta aplicação transporte rede enlace física e.x., Web server envia a página Web solicitada, servidor de e-mail envia as mensagens, etc. Cap. 2: Camada de Aplicação 5 Interfaces de Programação API: application programming interface define a interface entre a camada de aplicação e de transporte socket: Internet API dois processos se comunicam enviando dados para o socket e lendo dados de dentro do socket Q: Como um processo “identifica” o outro processo com o qual ele quer se comunicar? IP address do computador no qual o processo remoto executa “port number” - permite ao computador receptor determinar o processo local para o qual a mensagem deve ser entregue. Cap. 2: Camada de Aplicação 6 Serviços de Transporte Perda de dados algumas aplicações (e.x., aúdio) podem tolerar alguma perda outras aplicações (e.x., transferência de arquivos, telnet) exigem transferência de dados 100% confiável Temporização algumas aplicações (e.x., telefonia Internet, jogos interativos) exigem baixos atrasos para operarem Banda Passante algumas aplicações (e.x., multimedia) exigem uma banda mínima para serem utilizáveis outras aplicações (“aplicações elásticas”) melhoram quando a banda disponível aumenta Cap. 2: Camada de Aplicação 7 Requisitos de Transporte de Aplicações Comuns Applicação transf. de arquivos e-mail documentos Web áudio/vídeo tempo real áudio/vídeo armazenado jogos interativos comércio eletrônico Perdas Banda Sensível ao Atraso sem perdas sem perdas tolerante tolerante elástica elástica elástica aúdio: 5Kb-1Mb vídeo:10Kb-5Mb igual à anterior Kbps elástica não não não sim, 100’s msec tolerante tolerante sem perda sim, segundos sim, 100’s msec sim Cap. 2: Camada de Aplicação 8 Serviços de Transporte da Internet serviço TCP: orientado á conexão: conexão requerida entre cliente e servidor transporte confiável dados perdidos na transmissão são recuperados controle de fluxo: compatibilização de velocidade entre o transmissor e o receptor controle de congestionamento : protege a rede do excesso de tráfego não oferece: garantias de temporização e de banda mínima serviço UDP: transferência de dados não confiável entre os processos transmissor e receptor não oferece: estabelecimento de conexão, confiabilidade, controle de fluxo e de congestionamento, garantia de temporização e de banda mínima. Cap. 2: Camada de Aplicação 9 Aplicações e Protocolos de Transporte da Internet Aplicação e-mail acesso de terminais remotos Web transferência de arquivos streaming multimedia servidor de arquivos remoto telefonia Internet Protocolo de Aplicação Protocolo de Transporte smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] RTP ou proprietario (e.g. RealNetworks) NFS RTP ou proprietary (e.g., Vocaltec) TCP TCP TCP TCP TCP ou UDP TCP ou UDP tipicamente UDP Cap. 2: Camada de Aplicação 10 Protocolo HTTP HTTP: HyperText Transfer Protocol protocolo da camada de aplicação da Web modelo cliente/servidor cliente: browser que solicita, recebe e apresenta objetos da Web server: envia objetos em resposta a pedidos http1.0: RFC 1945 http1.1: RFC 2068 PC rodando Explorer Servidor rodando NCSA Web server Mac rodando Netscape Navigator Cap. 2: Camada de Aplicação 11 Protocolo HTTP http - protocolo de transporte: TCP cliente inicia conexão TCP (cria socket) para o servidor na porta 80 servidor aceita uma conexão TCP do cliente mensagens http (mensagens do protocolo de camada de aplicação) são trocadas entre o browser (cliente http) e o servidor Web (servidor http) A conexão TCP é fechada http é “stateless” o servidor não mantém informação sobre os pedidos passados pelos clientes Protocolos que mantém informações de estado são complexos! necessidade de organizar informações passadas se ocorrer um queda do sistema, as informações podem ser perdidas ou gerar inconsistências entre o cliente e o servidor Cap. 2: Camada de Aplicação 12 Exemplo de Operação Usuário entra com a URL: www.someSchool.edu/someDepartment/home.index (contém referência a 10 imagens jpeg) 1a. cliente http inicia conexão TCP ao servidor http (processo) em www.someSchool.edu. Porta 80 é a default para o servidor http . 2. cliente http client envia uma mensagem de requisição http (contendo a URL) para o socket da conexão TCP 1b. servidor http no host www.someSchool.edu esperando pela conexão TCP na porta 80. “aceita” conexão, notificando o cliente 3. servidor http recebe mensagem de pedido, constrói a mensagem de resposta contendo o objeto solicitado (someDepartment/home.index), envia mensagem para o socket tempo Cap. 2: Camada de Aplicação 13 Exemplo (cont.) 4. servidor http fecha conexão TCP. 5. cliente http recebe mensagem de resposta contendo o arquivo html, apresenta o conteúdo html. Analisando o arquivo html encontra 10 objetos jpeg referenciados tempo 6. Passos 1-5 são repetidos para cada um dos 10 objetos jpeg. Cap. 2: Camada de Aplicação 14 Conexões persistentes e não-persistentes Não-persistente http/1.0: servidor analisa pedido, envia resposta e fecha a conexão TCP 2 RTTs para obter um objeto Conexão TCP solicitação e transferência do objeto cada transferência sofre por causa do mecanismo de slowstart do TCP muitos browsers abrem várias conexões paralelas Persistente modo default para htp/1.1 na mesma conexão TCP são trazidos vários objetos o cliente envia pedido para todos os objetos referenciados tão logo ele recebe a página HTML básica. poucos RTTs, menos slow start. Cap. 2: Camada de Aplicação 15 Formato das Mensagens dois tipos de mensagens HTTP: request, response mensagem de requisição http (request): ASCII (formato legível para humanos) linha de pedido (comandos GET, POST, HEAD ) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg linhas de Accept-language:fr cabeçalho (extra carriage return, line feed) Carriage return, line feed indica fim da mensagem Cap. 2: Camada de Aplicação 16 HTTP request: formato geral Cap. 2: Camada de Aplicação 17 Formatos HTTP: response linha de status (protocolo código de status frase de status) linhas de cabeçalho dados, e.x., arquivo html HTTP/1.0 200 OK 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 ... Cap. 2: Camada de Aplicação 18 HTTP response: formato geral version status phrase Cap. 2: Camada de Aplicação 19 Códigos de status das respostas 200 OK requisição bem sucedida, objeto solicitado vem em seguida 301 Moved Permanently objeto requisitado foi movido; a nova localização é especificada a seguir na mensagem 400 Bad Request mensagem de requisição não entendida pelo servidor 404 Not Found documento requisitado não encontrado neste servidor 505 HTTP Version Not Supported Cap. 2: Camada de Aplicação 20 HTTP Cliente: faça você mesmo! 1. Telnet para um servidor Web: telnet www.eurecom.fr 80 Abre conexão TCP para a porta 80 (porta default do servidor http) em www.eurecom.fr. Qualquer coisa digitada é enviada para a porta 80 em www.eurecom.fr 2. Digite um pedido GET http: GET /~ross/index.html HTTP/1.0 Digitando isto (tecle carriage return duas vezes), você envia este pedido HTTP GET mínimo (mas completo) ao servidor http 3. Examine a mensagem de resposta enviada pelo servidor http! Cap. 2: Camada de Aplicação 21 HTML (HyperText Markup Language) HTML: uma linguagem simples para hipertexto começou como versão simples de SGML construção básica: cadeias (strings) de texto anotadas Construtores de formato operam sobre cadeias <b> .. </b> bold (negrito) <H1 ALIGN=CENTER> ..título centrado .. </H1> <BODY bgcolor=white text=black link=red ..> .. </BODY> vários formatos listas de bullets, listas ordenadas, listas de definição tabelas frames Cap. 2: Camada de Aplicação 22 Encadeamento de referências Referências <A HREF=LinkRef> ... </A> a componentes do documento local <A HREF=“importante”> clique para uma dica </A> a documentos no servidor local <A HREF=“../index.htm”> voltar ao sumário </A> a documentos em outros servidores <A HREF=“http://www.ufg.br”> saiba mais sobre a UFG </A> Multimídia imagem embutida: <IMG SRC=“eclipse”> imagem externa: <A HREF=“eclipse.gif”> imagem maior </A> vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A> som <A HREF=“http://www.sons.br/aniv.au”> feliz aniversário </A> Cap. 2: Camada de Aplicação 23 Formulários e interação bidirecional Formulários transmitem informação do cliente ao servidor HTTP permite enviar formulários ao servidor Resposta enviada como página HTML dinâmica Formulários processados usando scripts CGI (programas que executam no servidor WWW) CGI - Common Gateway Interface scripts CGI escondem acesso a diferentes serviços servidor WWW atua como gateway universal Outras tecnologias: ASP, cliente WWW GET/POST formulário resposta: HTML JSP, PHP, ... servidor WWW Sistema de informação Cap. 2: Camada de Aplicação 24 Interação usuário-servidor: autenticação Meta da autenticação: controle de acesso aos documentos do servidorcliente servidor sem estado: cliente deve msg de pedido http comum apresentar autorização com cada pedido 401: authorization req. WWW authenticate: autorização: tipicamente nome, senha authorization: linha de msg de pedido http comum cabeçalho no pedido + Authorization:line se não for apresentada msg de resposta http comum autorização, servidor nega accesso, e coloca no cabeçalho da resposta WWW authenticate: msg de pedido http comum + Authorization:line msg de resposta http comum Browser guarda nome e senha para evitar que sejam pedidos ao usuário a cada acesso. tempo Cap. 2: Camada de Aplicação 25 Cookies gerados e lembrados pelo servidor, usados mais tarde para: autenticação lembrar preferencias dos usuários ou prévias escolhas servidor envia “cookie” ao cliente na resposta HTTP Set-cookie: 1678453 cliente apresenta o cookie em pedidos posteriores cookie: 1678453 cliente servidor usual http request msg usual http response + Set-cookie: uid usual http request msg cookie: uid usual http response msg usual http request msg cookie: uid usual http response msg Gera resposta + ID único (uid) p/ cookie ação específica do cookie ação específica do cookie Cap. 2: Camada de Aplicação 26 Conditional GET: armazenando no cliente Razão: não enviar objeto se a versão que o cliente já possui está atualizada. cliente: especifica data da versão armazenada no pedido HTTP If-modified-since: <date> servidor: resposta não contém objeto se a cópia do cliente está atualizada: HTTP/1.0 304 Not Modified servidor cliente http request msg If-modified-since: <date> http response objeto não modificado HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> http response objeto modificado HTTP/1.1 200 OK <data> Cap. 2: Camada de Aplicação 27 ftp: o protocolo de transferência de arquivos user at host FTP FTP interface cliente de usuário transferência de arquivos sistema de arquivos local FTP servidor sistema de arquivos remoto transferência de arquivos de e para o computador remoto modelo cliente servidor cliente: lado que inicia a transferência (seja de ou para o lado remoto) servidor: host remoto ftp: RFC 959 ftp servidor: porta 21 Cap. 2: Camada de Aplicação 28 ftp: controle separado, conexões de dados cliente ftp contata o servidor ftp na porta 21, especificando TCP como protocolo de transporte duas conexões TCP paralelas são abertas: controle: troca de comandos e respostas entre cliente e servidor. “controle out of band” dados: dados do arquivo trocados com o servidor servidor ftp mantém o “estado”: diretório corrente, autenticação anterior TCP conexão de controle porta 21 FTP cliente TCP conexão de dados porta 20 FTP servidor Cap. 2: Camada de Aplicação 29 ftp comandos, respostas Exemplos de comandos: Enviados em texto ASCII através do canal de controle USER username PASS password LIST retorna listagem dos arquivos no diretório atual RETR filename recupera (obtém) o arquivo (GET) STOR filename armazena o arquivo no host remoto (PUT) Exemplos de códigos de retorno código de status e frase (como no http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file Cap. 2: Camada de Aplicação 30 Correio Eletrônico fila de saída de mensagem caixa postal Três componentes principais: agentes de usuário servidores de correio servidor de correio simple mail transfer protocol: smtp Agente de usuário “leitor de correio” composição, edição, leitura de mensagens de correio ex., Eudora, Outlook, elm, Netscape Messenger mensagens que chegam e saem são armazenadas em filas no servidor agente usuário SMTP agente usuário mail server agente usuário SMTP SMTP servidor de correio agente usuário agente usuário agente usuário Cap. 2: Camada de Aplicação 31 Correio eletrônico: servidores de correio agente usuário Servidores de Correio caixa postal contém mensagens servidor de correio que chegaram (ainda não lidas) para o usuário fila de mensagens contém as mensagens de correio a serem SMTP enviadas protocolo smtp permite aos servidores de correio trocarem servidor mensagens entre eles de correio “cliente”: servidor de correio que envia “servidor”: servidor de correio que recebe SMTP agente usuário mail server agente usuário SMTP agente usuário agente usuário agente usuário Cap. 2: Camada de Aplicação 32 Correio Eletrônico: smtp [RFC 821] usa TCP para transferência confiável de mensagens de correio do cliente para o servidor, através da porta 25 transferência direta: do servidor que envia para o servidor que recebe três fases de trasnferência handshaking (apresentação) transferência de mensagens fechamento interação comando/resposta comandos: texto ASCII resposta: código de status e frase mensagens devem ser formatadas em código ASCII de 7 bits Cap. 2: Camada de Aplicação 33 Exemplo de interação 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 Cap. 2: Camada de Aplicação 34 Tente o SMTP você mesmo: telnet <nome do servidor> 25 veja resposta 220 do servidor envie comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT como no exemplo anterior a seqüência acima permite enviar um e-mail sem usar o agente de usuário do rementente Cap. 2: Camada de Aplicação 35 SMTP: palavras finais SMTP usas conexões persistentes SMTP exige que as mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits algumas seqüências de caracteres não são permitidas no corpo das mensagens (ex., CRLF.CRLF). Assim mensagens genéricas têm que ser codificadas (usualmente em “base-64” ou “quoted printable”) Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem Comparação com http: http: modelo pull email: modelo push ambos usam comandos e respostas em ASCII, interação comando / resposta e códigos de status http: cada objeto encapsulado na sua própria mensagem de resposta smtp: múltiplos objetos são enviados numa mensagem multiparte Cap. 2: Camada de Aplicação 36 Formato das Mensagens smtp: protocolo para trocar mensagens de e-mail RFC 822: padrão para mensagens do tipo texto: linhas de cabeçalho, e.g., To: From: Subject: não confudir com os comandos SMTP ! cabeçalho linha em branco corpo da mensagem corpo a “mensagem”, ASCII somente com caracteres Cap. 2: Camada de Aplicação 37 Formato das Mensagens: extensões multimedia MIME: multimedia mail extension: RFC 2045, 2056 linhas adicionais no cabeçalho declaram o tipo de conteúdo MIME versão de MIME utilizada método usado para codificar dados tipo, subtipo e declaração de parâmetro dos dados multimídia dados 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 Cap. 2: Camada de Aplicação 38 Tipos MIME Content-Type: type/subtype; parâmetros Text exemplo de subtipos: plain, html Image exemplo de subtipos: jpeg, gif Audio exemplo de subtipos: basic (codificado 8-bit m-law ), 32kadpcm (codificação 32 kbps) Video exemplo de subtipos: mpeg, quicktime Application outros dados que devem ser processados pelo leitor antes de serem apresentados “visualmente” exemplo de subtipos: msword, octet-stream Cap. 2: Camada de Aplicação 39 Tipo Multiparte: Mensagens com múltiplos objetos de tipos diferentes From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789-- delimitador 1a. parte: texto 2a. parte: imagem Cap. 2: Camada de Aplicação 40 Formato das mensagens recebidas Servidor de correio do destino (que recebe a mensagem) adiciona a linha de cabeçalho Received: Received: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39 GMT 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 Cap. 2: Camada de Aplicação 41 Protocolos de acesso ao correio agente usuário SMTP SMTP servidor de correio da origem POP3 or IMAP agente usuário servidor de correio do destino SMTP: entrega e armazena as mensagens no servidor do destino Protocolo de acesso: recupera mensagens do servidor POP: Post Office Protocol [RFC 1939] • autorização (agente <-->servidor) e download IMAP: Internet Mail Access Protocol [RFC 1730] • mais recursos (mais complexo) • permite a manipulação de mensagens armazenadas no servidor (ex.: organizá-las em diretórios) HTTP: Hotmail , Yahoo! Mail, etc. Cap. 2: Camada de Aplicação 42 protocolo POP3 fase de autorização comandos do cliente: user: declara nome do usuário pass: password respostas do servidor +OK -ERR fase de transação list: lista mensagens e tamanhos retr: recupera mensagem pelo número dele: apaga quit S: C: S: C: S: +OK POP3 server ready user alice +OK pass hungry +OK user successfully logged C: S: S: S: C: S: S: S: C: C: S: S: S: C: C: S: list 1 498 2 912 . retr 1 (blah blah blah ... .....................) . dele 1 retr 2 (blah blah blah ... .....................) . dele 2 quit +OK POP3 server signing off Cap. 2: Camada de Aplicação on 43 DNS: Domain Name System Pessoas: muitos identificadores: RG, nome, passaporte Hosts e roteadores na Internet: endereços IP (32 bit) usados para endereçar datagramas “nome”, ex., gaia.cs.umass.edu - usados por humanos Q: Como relacionar nomes com endereços IP? Domain Name System: base de dados distribuída implementada numa hierarquia de muitos servidores de nomes protocolo de camada de aplicação host, roteadores se comunicam com servidores de nomes para resolver nomes (tradução nome/endereço) nota: função interna da Internet, implementada como um protocolo da camada de aplicação complexidade na “borda” da rede Cap. 2: Camada de Aplicação 44 Servidores de Nomes DNS Nenhum servidor tem todos os Porque não centralizar o DNS? ponto único de falha volume de tráfego base de dados distante manutenção Não cresce junto com a rede! isto é: não seria escalável mapeamentos de nomes para endereços IP servidores de nomes locais: cada ISP ou empresa tem um servidor de nomes local (default) Consultas dos computadores locais ao DNS vão primeiro para o servidor de nomes local servidor de nomes autoritativo: para um computador: armazena o nome e o endereço IP daquele computador pode realizar mapeamentos de nomes para endereços para aquele nome de computador Cap. 2: Camada de Aplicação 45 DNS: Servidores de Nomes Raiz são contactados pelos servidores de nomes locais que não podem resolver um nome servidor de nomes raiz:: busca servidores de nomes autoritativos se o mapeamento do nome não for conhecido obtém o mapeamento retorna o mapeamento para o servidor de nomes local a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA existem 13 servidores de nomes raiz no mundo (2002) Cap. 2: Camada de Aplicação 46 DNS: exemplo simples servidor de nomes raiz host surf.eurecom.fr quer o endereço IP de gaia.cs.umass.edu 1. contacta seu servidor DNS local, dns.eurecom.fr 2. dns.eurecom.fr contata o servidor de nomes raiz, se necessário 3. o servidor de nomes raiz contata o servidor de nomes autoritativo, dns.umass.edu, se necessário 2 4 5 servidor de nomes local dns.eurecom.fr 1 3 servidor de nomes autoritativo dns.umass.edu 6 computador solicitante gaia.cs.umass.edu surf.eurecom.fr Cap. 2: Camada de Aplicação 47 DNS: exemplo servidor de nomes raiz Servidor de nomes raiz: 6 2 7 3 pode não conhecer o servidor de nomes autoritativo para um certo nome pode conhecer: servidor de nomes intermediário: aquele que deve ser contactado para encontrar o servidor de nomes autoritativo servidor de nomes intermediário dns.umass.edu servidor de nomes local dns.eurecom.fr 1 8 4 5 servidor de nomes autoritativo dns.cs.umass.edu computador solicitante surf.eurecom.fr gaia.cs.umass.edu Cap. 2: Camada de Aplicação 48 DNS: consultas encadeadas servidor de nomes raiz consulta recursiva: transfere a tarefa de resolução do nome para o servidor de nomes consultado carga pesada? consulta encadeada: servidor contactado responde com o nome de outro servidor de nomes para contato “Eu não sei isto ,mas pergunte a este servidor” consulta encadeada 2 3 4 servidor de nomes intermediário dns.umass.edu 7 servidor de nomes local dns.eurecom.fr 1 8 5 6 servidor de nomes autoritativo dns.cs.umass.edu computador solicitante surf.eurecom.fr gaia.cs.umass.edu Cap. 2: Camada de Aplicação 49 DNS: armazenando e atualizando registros Uma vez que um servidor de nomes apreende um mapeamento, ele armazena o mapeamento num registro do tipo cache registro da cache tornam-se obsoletos (desapareçem) depois de um certo tempo Tradicionalmente: registros são armazenados estaticamente ex.: a partir de um arquivo de configuração RFC 2136: mecanismos de atualização dinâmica estão sendo projetados pelo IETF Dynamic DNS updates: adicionar ou remover registros dinamicamente http://www.ietf.org/html.charters/dnsind-charter.html Cap. 2: Camada de Aplicação 50 registros do DNS DNS: base de dados distribuída que armazena registros de recursos (RRs) formato dos RRs: (name, Type=A name é o nome do computador value é o endereço IP Type=CNAME Type=NS name é um domínio (ex. foo.com) value é o endereço IP do servidor de nomes autoritativo para este domínio value, type, ttl) name é um “apelido” para algum nome “canônico” (o nome real) Ex.: www.ibm.com é realmente servereast.backup2.ibm.com value é o nome canônico Type=MX value é o nome canônico do servidor de correio associado com name Cap. 2: Camada de Aplicação 51 DNS: protocolo e mensagens protocolo DNS: mensagen de consulta e resposta , ambas com o mesmo formato de mensagem cabeçalho da mensagem identificação: número de 16 bit para a consulta, resposta usa o mesmo número flags: consulta ou resposta recursão desejada recursão disponível resposta é autoritativa Cap. 2: Camada de Aplicação 52 DNS: protocolo e mensagens Campos de nome e tipo para uma consulta RRs de resposta a uma consulta registros para servidores autoritativos informação adicional que pode ser útil Ex.: se answer é do tipo “MX”, additional info poderá conter um RR do tipo “A” com o endereço IP do servidor de e-mail Cap. 2: Camada de Aplicação 53 Programação de Sockets Objetivo: aprender a construir aplicações cliente/servidor que se comunicam usando sockets socket API de Sockets uma interface local, criada introduzida no BSD4.1 UNIX, 1981 sockets são explicitamente criados, usados e liberados pelas aplicações paradigma cliente/servidor dois tipos de serviço de transporte via socket API: datagrama não confiável confiável, orientado a fluxo de bytes e possuída pelas aplicações controlada pelo OS uma “porta” através qual os processos de aplicação podem tanto enviar quanto receber mensagens de e para outro processo de aplicação (local ou remoto) Cap. 2: Camada de Aplicação 54 Programação de Sockets com TCP Socket: uma porta entre o processo de aplicação e o protocolo de transporte fim-a-fim (UDP ou TCP) serviço TCP: transferência confiável de bytes de um processo para outro controlado pelo criador da aplicação controlado pelo sistema operacional processo processo socket TCP com buffers, variáveis host ou servidor internet socket TCP com buffers, variáveis controlado pelo criador da aplicação controlado pelo sistema operacional host ou servidor Cap. 2: Camada de Aplicação 55 Programação de Sockets com TCP Cliente deve contactar o servidor processo servidor já deve estar executando antes de ser contactado servidor deve ter criado um socket (porta) que aceita o contato do cliente Como o cliente contacta o servidor: criando um socket TCP local especificando endereço IP e número da porta do processo servidor Quando o cliente cria o socket: cliente TCP estabelece conexão com o TCP do servidor Quando contactado pelo cliente, o TCP do servidor cria um novo socket para o processo servidor comunicar-se com o cliente permite ao servidor conversar com múltiplos clientes ponto de vista da aplicação TCP fornece a transferência confiável (fluxo de bytes ordenados) (“pipe”) entre o cliente e o servidor Cap. 2: Camada de Aplicação 56 Programação de Sockets com TCP padrão do sistema (stream inFromUser) , envia para o servidor via socket (stream outToServer) servidor lê a linha do socket servidor converte linha para letras maiúsculas e envia de volta ao cliente cliente lê a linha modificada através do sockete (stream inFromServer) input stream processo cliente stream de saída: seqüência de bytes para fora do processo output stream monitor stream de entrada: seqüência de bytes para dentro do processo inFromServer cliente lê uma linha da entrada outToServer Exemplo de aplicação clienteservidor: inFromUser teclado input stream TCP socket clientSocket cliente para rede TCP socket da rede Cap. 2: Camada de Aplicação 57 Interação Cliente/servidor: TCP Servidor (executando em hostid) cria socket, porta=x, para solicitação entrante: welcomeSocket = ServerSocket() Cliente TCP espera por pedido estab. de conexão de conexão entrante connectionSocket = welcomeSocket.accept() lê pedido de connectionSocket escreve resposta para connectionSocket fecha connectionSocket cria socket, conecta com hostid, porta=x: clientSocket = Socket() envia pedido usando clientSocket lê resposta de clientSocket fecha clientSocket Cap. 2: Camada de Aplicação 58 Exemplo: cliente Java (TCP) import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; Cria stream de entrada Cria socket cliente, conecta ao servidor Cria stream de saída ligada ao socket BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Cap. 2: Camada de Aplicação 59 Exemplo: cliente Java (TCP), cont. BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); Cria stream de entrada ligada ao socket sentence = inFromUser.readLine(); Envia linha para o servidor outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); Lê linha do servidor System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } } Cap. 2: Camada de Aplicação 60 Exemplo: servidor Java (TCP) import java.io.*; import java.net.*; class TCPServer { Cria socket de aceitação na porta 6789 Espera, no socket de aceitação por contato do cliente Cria stream de entrada, ligado ao socket 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())); Cap. 2: Camada de Aplicação 61 Exemplo: servidor Java (cont) Cria stream de saída, ligado ao socket DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); Lê linha do socket clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; Escreve linha para o socket outToClient.writeBytes(capitalizedSentence); } } } Fim do while loop, retorne e espere por outra conexão do cliente Cap. 2: Camada de Aplicação 62 Programaçaõ de Sockets com UDP UDP: não há conexão entre o cliente e o servidor não existe apresentação (handshaking) transmissor envia explicitamente endereço IP e porta de destino em cada mensagem servidor deve extrair o endereço IP e porta do transmissor de cada datagrama recebido UDP: dados transmitidos podem ser recebidos foram de ordem ou perdidos ponto de vista da aplicação UDP fornece a transferência não confiável de grupos de bytes (“datagramas”) entre o cliente e o servidor Cap. 2: Camada de Aplicação 63 Interação Cliente/servidor: UDP Servidor (executando em hostid) cria socket, porta=x, para solicitação entrante: serverSocket = DatagramSocket() lê pedido de: serverSocket escreve resposta para serverSocket especificando endereço do host cliente e número da porta Cliente cria socket, clientSocket = DatagramSocket() Cria endereço (hostid, port=x), envia datagrama de pedido usando clientSocket lê resposta de clientSocket fecha clientSocket Cap. 2: Camada de Aplicação 64 Exemplo: cliente Java (UDP) stream de entrada processo cliente monitor inFromUser teclado Process (TCP enviaria “byte stream”) pacote UDP receivePacket Saída: envia pacote sendPacket Entrada: recebe socket UDP clientSocket cliente para rede pacote (TCP receberia “byte stream”) pacote UDP UDP socket da rede Cap. 2: Camada de Aplicação 65 Exemplo: cliente Java (UDP) import java.io.*; import java.net.*; Cria stream de entrada Cria socket cliente Traduz nome do host para endereço IP usando DNS 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(); Cap. 2: Camada de Aplicação 66 Exemplo: cliente Java (UDP), cont. Cria datagrama com dados a enviar, tamanho, endereço IP e porta DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); Envia datagrama para servidor clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); Lê datagrama do servidor clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } } Cap. 2: Camada de Aplicação 67 Exemplo: servidor Java (UDP) import java.io.*; import java.net.*; Cria socket datagrama na porta 9876 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) { Cria espaço para datagramas recebidos Recebe datagrama DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Cap. 2: Camada de Aplicação 68 Exemplo: servidor Java, (cont.) String sentence = new String(receivePacket.getData()); Obtém endereço IP e número da porta do transmissor InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); Cria datagrama para enviar ao cliente DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); Escreve o datagrama para dentro do socket serverSocket.send(sendPacket); } } } Termina o while loop, retorna e espera por outro datagrama Cap. 2: Camada de Aplicação 69 Programação de Sockets: referências tutorial sobre sockets em linguagem C (audio/slides): “Unix Network Programming” (J. Kurose), http://manic.cs.umass.edu Tutoriais sobre sockets em Java: “Socket Programming in Java: a tutorial,” http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html Cap. 2: Camada de Aplicação 70 Construção de um Servidor Web Simplificado Ingredientes: Protocolo HTTP + Sockets Funcionalidade: Trata apenas uma requisição HTTP Aceita e interpreta a requisição Obtém o arquivo requisitado a partir do sistema de arquivos local (do servidor Web) Cria uma mensagem de resposta HTTP: Linhas de cabeçalho + arquivo requisitado Envia a resposta diretamente para o cliente Fecha conexão e termina Cap. 2: Camada de Aplicação 71 Construção de um Servidor Web Simplificado Cliente: Navegador Web padrão Netscape, IE, Konqueror, etc. Exemplo de requisição: URL: http://somehost.somewhere.br:6789/somefile.html host e porta: usados p/ estab. conexão com servidor Requisição: GET /somefile.html HTTP/1.0 Cap. 2: Camada de Aplicação 72 WebServer.java (1) import java.io.*; import java.net.*; import java.util.*; class WebServer { public static void main (String argv[]) throws Exception { String requestMessageLine; ServerSocket listenSocket = new ServerSocket(6789); Socket connectionSocket = listenSocket.accept(); BufferedReader inFromClient = new BufferedReader (new InputStreamReader( Stream para connectionSocket.getInputStream())); receber dados via socket Socket para espera de conexões Socket de conexão c/ cliente Cap. 2: Camada de Aplicação 73 WebServer.java (2) Separa os tokens da requisição Verifica se comando é GET Obtém o tamanho do arquivo Stream para enviar dados através do socket DataOutputStream outToClient = new DataOutputStream( connectionSocket.getOutputStream()); requestMessageLine = inFromClient.readLine(); StringTokenizer tokenizedLine = new StringTokenizer( requestMessageLine); if (tokenizedLine.nextToken().equals(“GET”)){ fileName = tokenizedLine.nextToken(); if (fileName.startsWith(“/”) == true) fileName = fileName.substring(1); File file = new File(fileName); int numOfBytes = (int) file.length(); Lê requisição do cliente Obtém o nome do arquivo Cap. 2: Camada de Aplicação 74 WebServer.java (3) Lê o arquivo requisitado Envia a primeira linha do cabeçalho da resposta Segunda linha (content-type) depende do tipo do arquivo requisitado (jpeg ou gif) FileInputStream inFile = new FileInputStream(fileName); byte [] fileInBytes = new byte[numOfBytes]; inFile.read(fileInBytes); outToClient.writeBytes( “HTTP/1.0 200 Document Follows\r\n”); if (fileName.endsWith(“.jpg”)) outToClient.writeBytes(“Content-Type: image/jpeg\r\n”); if (fileName.endsWith(“.gif”)) outToClient.writeBytes(“Content-Type: image/gif\r\n”); Cap. 2: Camada de Aplicação 75 WebServer.java (4) Envia a 3a. linha do cabeçalho Linha em branco para separar o cabeçalho do corpo da msg outToClient.writeBytes(“Content-Length: “ + numOfBytes + “\r\n”); outToClient.writeBytes(“\r\n”); outToClient.write(fileInBytes, 0, numOfBytes); connectionSocket.close(); } else System.out.println(“Bad Request Message”); Envia o arquivo requisitado Fecha a conexão com o cliente } } Cap. 2: Camada de Aplicação 76 WebServer.java: O que Falta? Aceitar múltiplas requisições Cada requisição processada por uma thread diferente Tratar outros tipos de conteúdo (linha de cabeçalho Content-type:) Suporte para demais comandos (POST, HEAD) Suporte para demais tipos de mensagem de resposta (Bad request, Not found, etc.) O que mais? Cap. 2: Camada de Aplicação 77 Distribuição de Conteúdo Web Caches (ou Web Proxies) Redes de Distribuição de Conteúdo (CDNs) Redes “Peer-to-Peer” Cap. 2: Camada de Aplicação 78 Web Caches (proxy server) Objetivo: atender o cliente sem envolver o servidor Web originador da informação servidor original usuário configura o browser: acesso à Web é feito através de um proxy cliente envia todos os pedidos http para o proxy se o objeto existe no proxy (web cache): proxy retorna o objeto caso contrário, o proxy solicita o objeto ao servidor original e então envia o objeto ao cliente. proxy guarda o objeto em sua cache cliente Proxy server cliente servidor original Cap. 2: Camada de Aplicação 79 Porque Web Caching? armazenamento está “perto” do cliente (ex., na mesma rede) menor tempo de resposta reduz o tráfego para servidores distantes links externos podem ser caros e facilmente congestionáveis servidores originais Internet pública enlace de acesso 1.5 Mbps rede institucional 10 Mbps LAN cache institucional Cap. 2: Camada de Aplicação 80 Análise simplificada Tamanho médio dos objetos requisitados: 100.000 bits 15 requisições / segundo “Atraso da Internet”: 2s Atraso total: LAN + acesso + Internet Intensidade de tráfego na LAN: (15 reqs/s) . (100kbits/req)/(10Mbps) = 0,15 servidores originais Internet pública enlace de acesso 1.5 Mbps rede institucional 10 Mbps LAN Intens. de tráf. no acesso: (15 reqs/s) . (100kbits/req)/(1,5Mbps) = 1 Congestionamento no enlace de acesso: atraso crescente Cap. 2: Camada de Aplicação 81 Análise: Com o Proxy Taxa de acerto: 0,4 40% dos acessos: via proxy servidores originais Internet pública • Atraso da LAN (0,01s) 60% dos acessos: servidor original • Intes. tráf. no acesso: 0,6 • Atraso: 2,01s Atraso médio: enlace de acesso 1.5 Mbps rede institucional 10 Mbps LAN 0,4*(0,01s) + 0,6*(2,01s) = 1,2s Na média, melhor do que um simples upgrade da “largura de banda” do enlace de acesso (e.g., para 10Mbps) Verificar! cache institucional Cap. 2: Camada de Aplicação 82 Caches Cooperativas Múltiplos níveis de caches institucional, ISP, nacional Caches de mais alto nível população de usuários maior maior taxa de acerto ICP: Internet Caching Protocol uma forma eficiente para uma cache consultar outra se esta possui o objeto Req. Resp. servidor original cache nacional Resp. Req. cache do ISP Req. Resp. Req. cache institucional Resp. cliente Cap. 2: Camada de Aplicação 83 Caches Cooperativas Outra técnica: Cluster de caches cada cache: um sub-conjunto dos objetos cliente (navegador) mapeia a URL sobre uma tabela de espalhamento (hash), que determina qual das caches deve ser consultada CARP: Cache Array Routing Protocol hash(URL) cliente cluster de caches Cap. 2: Camada de Aplicação 84 Outros Meios de Distribuição de Conteúdo Redes de Distribuição de Conteúdo Seção 2.9.2, K&R 2nd Edition (em Inglês) Compartilhamento de arquivos em redes de sobreposição (overlay networks) do tipo Peerto-Peer Seção 2.9.3, K&R 2nd Edition (em Inglês) Cap. 2: Camada de Aplicação 85 Redes de Distribuição de Conteúdo Contrastando as Abordagens: Web Caches: o provedor de acesso (ISP) arca com os custos de uma maior eficiência de acesso à Web para seus clientes CDNs - Um modelo diferente: Provedor de conteúdo contrata uma empresa de distribuição de conteúdo, a qual mantém a rede de distribuíção Custo fica sob a responsabilidade do provedor de conteúdo Cap. 2: Camada de Aplicação 86 Redes de Distribuição de Conteúdo servidor original Provedor envia conteúdo para o nodo de distribuição da CDN CDN replica o conteúdo nos seus diversos servidores de distribuição Requisições de usuários são servidas pelo servidor com o melhor tempo de resposta mais próximo do usuário nodo de distribuição servidor de distribuição na Am. do Sul servidor de distribuição na Am. do Norte servidor de distribuição na Europa Cap. 2: Camada de Aplicação 87 Redes de Distribuição de Conteúdo Como o navegador sabe qual o servidor de distribuição com o melhor tempo de resposta? Provedor original do conteúdo serve a página principal do site Demais páginas são marcadas com o nome de domínio da CDN • serão servidas pela CDN Requisições do cliente são redirecionadas pelo DNS Página principal (index.html) Objeto referenciado Objeto referenciado http://www.cdn.com/ www.foo.com/img.gif http://www.cdn.com/ww w.foo.com/filme.mpeg Distribuído pelo servidor original Distribuído pela CDN Cap. 2: Camada de Aplicação 88 Redes de Distribuição de Conteúdo Redirecionamento via DNS CDN configura o servidor de DNS autoritativo para responder de acordo com o IP do cliente Tomando como base: tabelas de roteamento da Internet estatísticas de desempenho da rede Cap. 2: Camada de Aplicação 89 Redes “Peer-to-Peer” Idéia geral Não há um servidor (ou servidores) de conteúdo centralizado Alto nível de escalabilidade Cada computador ligado à rede é capaz de prover e requisitar conteúdo Exemplo: Compartilhamento de arquivos MP3 em redes como Napster, Kazaa, Gnutella Cap. 2: Camada de Aplicação 90 Redes de Sobreposição (Overlay) Uma rede lógica construída sobre a Internet Conecta os vários computadores em uma rede peer-to-peer Estrutura altamente dinâmica: nodos podem ser inseridos ou removidos a todo tempo Cap. 2: Camada de Aplicação 91 Redes Peer-to-Peer Problema básico: Descobrir quais peers contêm o conteúdo desejado Diretório Centralizado (ex.: Napster) Diretório Distribuído (ex.: KaZaA) Inundação de consultas (query flooding) Cap. 2: Camada de Aplicação 92 Parte 2: Sumário Nosso estudo das aplicações está agora completo! exigências dos serviços de aplicação: confiabilidade, banda passante, atraso paradigma cliente-servidor modelo do serviço de transporte da Internet l orientado à conexão, confiável: TCP não confiável, datagramas: UDP protocolos especificos: http ftp smtp, pop3 dns programação de sockets implementação cliente/servidor usando sockets tcp, udp Cap. 2: Camada de Aplicação 93 Parte 2: Sumário Mais importante: características dos protocolos tipica troca de mensagens comando/resposta: cliente solicita informação ou serviço servidor responde com dados e código de status formatos das mensagens: cabeçalhos: campos que dão informações sobre os dados dados: informação sendo comunicada controle vs. dados in-band, out-of-band centralizado vs. descentralizado stateless vs. stateful transferência de mensagens confiável vs. não confiável “complexidade na borda da rede” segurança: autenticação Cap. 2: Camada de Aplicação 94
