A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M. Costa (slides baseados em [Kurose&Ross2003])

Apresentações semelhantes


Apresentação em tema: "Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M. Costa (slides baseados em [Kurose&Ross2003])"— Transcrição da apresentação:

1 Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M. Costa (slides baseados em [Kurose&Ross2003])

2 Cap. 2: Camada de Aplicação2 Parte 2: Camada de Aplicação Nossos objetivos: conceitual, aspectos de implementação de protocolos de aplicação para redes paradigma cliente- servidor 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

3 Cap. 2: Camada de Aplicação3 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., , ftp, Web 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 aplicação transporte rede enlace física

4 Cap. 2: Camada de Aplicação4 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 leitor de correio streaming áudio/vídeo: media player

5 Cap. 2: Camada de Aplicação5 Paradigma Cliente-Servidor Aplicações de rede típicas têm duas partes: cliente and servidor aplicação transporte rede enlace física aplicação transporte rede enlace física Cliente: inicia comunicação com o servidor (fala primeiro) tipicamente solicita serviços do servidor, Web: cliente implementado no browser; leitor de correio pedido resposta Servidor: fornece os serviços solicitados pelo cliente e.x., Web server envia a página Web solicitada, servidor de envia as mensagens, etc.

6 Cap. 2: Camada de Aplicação6 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.

7 Cap. 2: Camada de Aplicação7 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

8 Cap. 2: Camada de Aplicação8 Requisitos de Transporte de Aplicações Comuns Applicação transf. de arquivos documentos Web áudio/vídeo tempo real áudio/vídeo armazenado jogos interativos comércio eletrônico Perdas sem perdas tolerante sem perda Banda elástica aúdio: 5Kb-1Mb vídeo:10Kb-5Mb igual à anterior Kbps elástica Sensível ao Atraso não sim, 100s msec sim, segundos sim, 100s msec sim

9 Cap. 2: Camada de Aplicação9 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.

10 Cap. 2: Camada de Aplicação10 Aplicações e Protocolos de Transporte da Internet Aplicação acesso de terminais remotos Web transferência de arquivos streaming multimedia servidor de arquivos remoto telefonia Internet Protocolo de Aplicação 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) Protocolo de Transporte TCP TCP ou UDP tipicamente UDP

11 Cap. 2: Camada de Aplicação11 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 http request http response

12 Cap. 2: Camada de Aplicação12 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

13 Cap. 2: Camada de Aplicação13 Exemplo de Operação Usuário entra com a URL: 1a. cliente http inicia conexão TCP ao servidor http (processo) em 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 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 (contém referência a 10 imagens jpeg)

14 Cap. 2: Camada de Aplicação14 Exemplo (cont.) 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 6. Passos 1-5 são repetidos para cada um dos 10 objetos jpeg. 4. servidor http fecha conexão TCP. tempo

15 Cap. 2: Camada de Aplicação15 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 slow- start 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.

16 Cap. 2: Camada de Aplicação16 Formato das Mensagens dois tipos de mensagens HTTP: request, response mensagem de requisição http (request): ASCII (formato legível para humanos) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg Accept-language:fr (extra carriage return, line feed) linha de pedido (comandos GET, POST, HEAD ) linhas de cabeçalho Carriage return, line feed indica fim da mensagem

17 Cap. 2: Camada de Aplicação17 HTTP request: formato geral

18 Cap. 2: Camada de Aplicação18 Formatos HTTP: response HTTP/ OK Date: Thu, 06 Aug :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... linha de status (protocolo código de status frase de status) linhas de cabeçalho dados, e.x., arquivo html

19 Cap. 2: Camada de Aplicação19 HTTP response: formato geral version status phrase

20 Cap. 2: Camada de Aplicação20 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

21 Cap. 2: Camada de Aplicação21 HTTP Cliente: faça você mesmo! 1. Telnet para um servidor Web: Abre conexão TCP para a porta 80 (porta default do servidor http) em Qualquer coisa digitada é enviada para a porta 80 em telnet 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!

22 Cap. 2: Camada de Aplicação22 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.. bold (negrito)..título centrado.... vários formatos listas de bullets, listas ordenadas, listas de definição tabelas frames

23 Cap. 2: Camada de Aplicação23 Encadeamento de referências Referências... a componentes do documento local clique para uma dica a documentos no servidor local voltar ao sumário a documentos em outros servidores saiba mais sobre a UFG Multimídia imagem embutida: imagem externa: imagem maior vídeo Mpeg um bom filme som feliz aniversário

24 Cap. 2: Camada de Aplicação24 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, JSP, PHP,... cliente WWW servidor WWW Sistema de informação GET/POST formulário resposta: HTML

25 Cap. 2: Camada de Aplicação25 Interação usuário-servidor: autenticação Meta da autenticação: controle de acesso aos documentos do servidor sem estado: cliente deve apresentar autorização com cada pedido autorização: tipicamente nome, senha authorization: linha de cabeçalho no pedido se não for apresentada autorização, servidor nega accesso, e coloca no cabeçalho da resposta WWW authenticate: cliente servidor msg de pedido http comum 401: authorization req. WWW authenticate: msg de pedido http comum + Authorization:line msg de resposta http comum tempo Browser guarda nome e senha para evitar que sejam pedidos ao usuário a cada acesso. msg de pedido http comum + Authorization:line msg de resposta http comum

26 Cap. 2: Camada de Aplicação26 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: cliente apresenta o cookie em pedidos posteriores cookie: cliente servidor usual http request msg usual http response + Set-cookie: uid usual http request msg cookie: uid usual http response msgusual http request msg cookie: uid usual http response msg ação específica do cookie ação específica do cookie Gera resposta + ID único (uid) p/ cookie

27 Cap. 2: Camada de Aplicação27 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: servidor: resposta não contém objeto se a cópia do cliente está atualizada: HTTP/ Not Modified cliente servidor http request msg If-modified-since: http response HTTP/ Not Modified objeto não modificado http request msg If-modified-since: http response HTTP/ OK objeto modificado

28 Cap. 2: Camada de Aplicação28 ftp: o protocolo de transferência de arquivos 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 transferência de arquivos FTP servidor FTP interface de usuário FTP cliente sistema de arquivos local sistema de arquivos remoto user at host

29 Cap. 2: Camada de Aplicação29 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 FTP cliente FTP servidor TCP conexão de controle porta 21 TCP conexão de dados porta 20

30 Cap. 2: Camada de Aplicação30 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 Cant open data connection 452 Error writing file

31 Cap. 2: Camada de Aplicação31 Correio Eletrônico Três componentes principais: agentes de usuário servidores 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 caixa postal fila de saída de mensagem mail server agente usuário agente usuário agente usuário servidor de correio agente usuário agente usuário servidor de correio agente usuário SMTP

32 Cap. 2: Camada de Aplicação32 Correio eletrônico: servidores de correio Servidores de Correio caixa postal contém mensagens que chegaram (ainda não lidas) para o usuário fila de mensagens contém as mensagens de correio a serem enviadas protocolo smtp permite aos servidores de correio trocarem mensagens entre eles cliente: servidor de correio que envia servidor: servidor de correio que recebe mail server agente usuário agente usuário agente usuário servidor de correio agente usuário agente usuário servidor de correio agente usuário SMTP

33 Cap. 2: Camada de Aplicação33 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

34 Cap. 2: Camada de Aplicação34 Exemplo de interação SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 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

35 Cap. 2: Camada de Aplicação35 Tente o SMTP você mesmo: telnet 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 sem usar o agente de usuário do rementente

36 Cap. 2: Camada de Aplicação36 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 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

37 Cap. 2: Camada de Aplicação37 Formato das Mensagens smtp: protocolo para trocar mensagens de 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 ! corpo a mensagem, ASCII somente com caracteres cabeçalho corpo da mensagem linha em branco

38 Cap. 2: Camada de Aplicação38 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 From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data tipo, subtipo e declaração de parâmetro dos dados multimídia método usado para codificar dados versão de MIME utilizada dados codificados

39 Cap. 2: Camada de Aplicação39 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 -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

40 Cap. 2: Camada de Aplicação40 Tipo Multiparte: Mensagens com múltiplos objetos de tipos diferentes From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data a. parte: texto 2a. parte: imagem delimitador

41 Cap. 2: Camada de Aplicação41 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: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data

42 Cap. 2: Camada de Aplicação42 Protocolos de acesso ao correio 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. agente usuário servidor de correio da origem agente usuário SMTP POP3 or IMAP servidor de correio do destino

43 Cap. 2: Camada de Aplicação43 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 C: list S: S: S:. C: retr 1 S: (blah blah blah... S: ) S:. C: dele 1 C: retr 2 S: (blah blah blah... S: ) S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on

44 Cap. 2: Camada de Aplicação44 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

45 Cap. 2: Camada de Aplicação45 Servidores de Nomes DNS Nenhum servidor tem todos os 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 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

46 Cap. 2: Camada de Aplicação46 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 b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo 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 existem 13 servidores de nomes raiz no mundo (2002)

47 Cap. 2: Camada de Aplicação47 DNS: exemplo simples 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 computador solicitante surf.eurecom.fr gaia.cs.umass.edu servidor de nomes raiz servidor de nomes autoritativo dns.umass.edu servidor de nomes local dns.eurecom.fr

48 Cap. 2: Camada de Aplicação48 DNS: exemplo Servidor de nomes raiz: 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 computador solicitante surf.eurecom.fr gaia.cs.umass.edu servidor de nomes raiz servidor de nomes local dns.eurecom.fr servidor de nomes autoritativo dns.cs.umass.edu servidor de nomes intermediário dns.umass.edu 7 8

49 Cap. 2: Camada de Aplicação49 DNS: consultas encadeadas 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 computador solicitante surf.eurecom.fr gaia.cs.umass.edu servidor de nomes raiz servidor de nomes local dns.eurecom.fr servidor de nomes autoritativo dns.cs.umass.edu servidor de nomes intermediário dns.umass.edu 7 8 consulta encadeada

50 Cap. 2: Camada de Aplicação50 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

51 Cap. 2: Camada de Aplicação51 registros do DNS DNS: base de dados distribuída que armazena registros de recursos (RRs) Type=NS name é um domínio (ex. foo.com) value é o endereço IP do servidor de nomes autoritativo para este domínio formato dos RRs: (name, value, type, ttl) Type=A name é o nome do computador value é o endereço IP Type=CNAME name é um apelido para algum nome canônico (o nome real) Ex.: é realmente servereast.backup2.ibm.com value é o nome canônico Type=MX value é o nome canônico do servidor de correio associado com name

52 Cap. 2: Camada de Aplicação52 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

53 Cap. 2: Camada de Aplicação53 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 DNS: protocolo e mensagens

54 Cap. 2: Camada de Aplicação54 Programação de Sockets API de Sockets 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 uma interface local, criada 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) socket Objetivo: aprender a construir aplicações cliente/servidor que se comunicam usando sockets

55 Cap. 2: Camada de Aplicação55 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 processo TCP com buffers, variáveis socket controlado pelo criador da aplicação controlado pelo sistema operacional host ou servidor processo TCP com buffers, variáveis socket host ou servidor internet controlado pelo criador da aplicação controlado pelo sistema operacional

56 Cap. 2: Camada de Aplicação56 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 TCP fornece a transferência confiável (fluxo de bytes ordenados) (pipe) entre o cliente e o servidor ponto de vista da aplicação

57 Cap. 2: Camada de Aplicação57 Exemplo de aplicação cliente- servidor: cliente lê uma linha da entrada 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 ) outToServer para rede da rede inFromServer inFromUser tecladomonitor clientSocket input stream input stream output stream TCP socket stream de entrada: seqüência de bytes para dentro do processo stream de saída: seqüência de bytes para fora do processo processo cliente TCP socket cliente Programação de Sockets com TCP

58 Cap. 2: Camada de Aplicação58 Interação Cliente/servidor: TCP espera por pedido de conexão entrante connectionSocket = welcomeSocket.accept() cria socket, porta= x, para solicitação entrante: welcomeSocket = ServerSocket() cria socket, conecta com hostid, porta= x: clientSocket = Socket() fecha connectionSocket lê resposta de clientSocket fecha clientSocket Servidor (executando em hostid ) Cliente envia pedido usando clientSocket lê pedido de connectionSocket escreve resposta para connectionSocket TCP estab. de conexão

59 Cap. 2: Camada de Aplicação59 Exemplo: 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()); Cria stream de entrada Cria socket cliente, conecta ao servidor Cria stream de saída ligada ao socket

60 Cap. 2: Camada de Aplicação60 Exemplo: 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(); } Cria stream de entrada ligada ao socket Envia linha para o servidor Lê linha do servidor

61 Cap. 2: Camada de Aplicação61 Exemplo: 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())); 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

62 Cap. 2: Camada de Aplicação62 Exemplo: servidor Java (cont) DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Lê linha do socket Cria stream de saída, ligado ao socket Escreve linha para o socket Fim do while loop, retorne e espere por outra conexão do cliente

63 Cap. 2: Camada de Aplicação63 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

64 Cap. 2: Camada de Aplicação64 Interação Cliente/servidor: UDP fecha clientSocket Servidor (executando em hostid ) lê resposta de clientSocket cria socket, clientSocket = DatagramSocket() Cliente Cria endereço ( hostid, port=x), envia datagrama de pedido usando clientSocket 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

65 Cap. 2: Camada de Aplicação65 Exemplo: cliente Java (UDP) sendPacket para rededa rede receivePacket inFromUser tecladomonitor Process clientSocket pacote UDP stream de entrada pacote UDP socket Saída: envia pacote (TCP enviaria byte stream) Entrada: recebe pacote (TCP receberia byte stream) processo cliente socket UDP cliente

66 Cap. 2: Camada de Aplicação66 Exemplo: 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(); Cria stream de entrada Cria socket cliente Traduz nome do host para endereço IP usando DNS

67 Cap. 2: Camada de Aplicação67 Exemplo: 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()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Cria datagrama com dados a enviar, tamanho, endereço IP e porta Envia datagrama para servidor Lê datagrama do servidor

68 Cap. 2: Camada de Aplicação68 Exemplo: 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); Cria socket datagrama na porta 9876 Cria espaço para datagramas recebidos Recebe datagrama

69 Cap. 2: Camada de Aplicação69 Exemplo: servidor Java, (cont.) String sentence = new String(receivePacket.getData()); 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); } Obtém endereço IP e número da porta do transmissor Escreve o datagrama para dentro do socket Termina o while loop, retorna e espera por outro datagrama Cria datagrama para enviar ao cliente

70 Cap. 2: Camada de Aplicação70 Programação de Sockets: referências tutorial sobre sockets em linguagem C (audio/slides): Unix Network Programming (J. Kurose), Tutoriais sobre sockets em Java: Socket Programming in Java: a tutorial, sockets.html

71 Cap. 2: Camada de Aplicação71 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

72 Cap. 2: Camada de Aplicação72 Construção de um Servidor Web Simplificado Cliente: Navegador Web padrão Netscape, IE, Konqueror, etc. Exemplo de requisição: URL: host e porta: usados p/ estab. conexão com servidor Requisição: GET /somefile.html HTTP/1.0

73 Cap. 2: Camada de Aplicação73 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( connectionSocket.getInputStream())); Socket para espera de conexões Socket de conexão c/ cliente Stream para receber dados via socket

74 Cap. 2: Camada de Aplicação74 WebServer.java (2) 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(); Stream para enviar dados através do socket Lê requisição do cliente Separa os tokens da requisição Verifica se comando é GET Obtém o nome do arquivo Obtém o tamanho do arquivo

75 Cap. 2: Camada de Aplicação75 WebServer.java (3) FileInputStream inFile = new FileInputStream(fileName); byte [] fileInBytes = new byte[numOfBytes]; inFile.read(fileInBytes); outToClient.writeBytes( HTTP/ 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); 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)

76 Cap. 2: Camada de Aplicação76 WebServer.java (4) 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 a 3a. linha do cabeçalho Linha em branco para separar o cabeçalho do corpo da msg Envia o arquivo requisitado Fecha a conexão com o cliente

77 Cap. 2: Camada de Aplicação77 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?

78 Cap. 2: Camada de Aplicação78 Distribuição de Conteúdo Web Caches (ou Web Proxies) Redes de Distribuição de Conteúdo (CDNs) Redes Peer-to-Peer

79 Cap. 2: Camada de Aplicação79 Web Caches (proxy server) 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 Objetivo: atender o cliente sem envolver o servidor Web originador da informação cliente Proxy server cliente http request http response http request http response servidor original servidor original

80 Cap. 2: Camada de Aplicação80 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 rede institucional 10 Mbps LAN enlace de acesso 1.5 Mbps cache institucional

81 Cap. 2: Camada de Aplicação81 Análise simplificada Tamanho médio dos objetos requisitados: bits 15 requisições / segundo Atraso da Internet: 2s Atraso total: LAN + acesso + Internet Intensidade de tráfego na LAN: Intens. de tráf. no acesso: Congestionamento no enlace de acesso: atraso crescente servidores originais Internet pública rede institucional 10 Mbps LAN enlace de acesso 1.5 Mbps (15 reqs/s). (100kbits/req)/(10Mbps) = 0,15 (15 reqs/s). (100kbits/req)/(1,5Mbps) = 1

82 Cap. 2: Camada de Aplicação82 Análise: Com o Proxy Taxa de acerto: 0,4 40% dos acessos: via proxy Atraso da LAN (0,01s) 60% dos acessos: servidor original Intes. tráf. no acesso: 0,6 Atraso: 2,01s Atraso médio: Na média, melhor do que um simples upgrade da largura de banda do enlace de acesso (e.g., para 10Mbps) Verificar! servidores originais Internet pública rede institucional 10 Mbps LAN enlace de acesso 1.5 Mbps cache institucional 0,4*(0,01s) + 0,6*(2,01s) = 1,2s

83 Cap. 2: Camada de Aplicação83 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 cliente cache institucional cache do ISP cache nacional Req. Resp. Req. Resp. Req. Resp. servidor original Req. Resp.

84 Cap. 2: Camada de Aplicação84 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 cliente hash(URL) cluster de caches

85 Cap. 2: Camada de Aplicação85 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 Peer- to-Peer Seção 2.9.3, K&R 2nd Edition (em Inglês)

86 Cap. 2: Camada de Aplicação86 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

87 Cap. 2: Camada de Aplicação87 Redes de Distribuição de Conteúdo 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 servidor original nodo de distribuição servidor de distribuição na Am. do Sul servidor de distribuição na Europa servidor de distribuição na Am. do Norte

88 Cap. 2: Camada de Aplicação88 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 w.foo.com/filme.mpeg Distribuído pelo servidor original Distribuído pela CDN

89 Cap. 2: Camada de Aplicação89 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

90 Cap. 2: Camada de Aplicação90 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

91 Cap. 2: Camada de Aplicação91 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

92 Cap. 2: Camada de Aplicação92 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)

93 Cap. 2: Camada de Aplicação93 Parte 2: Sumário 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 Nosso estudo das aplicações está agora completo! protocolos especificos: http ftp smtp, pop3 dns programação de sockets implementação cliente/servidor usando sockets tcp, udp

94 Cap. 2: Camada de Aplicação94 Parte 2: Sumário 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 Mais importante: características dos protocolos 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


Carregar ppt "Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M. Costa (slides baseados em [Kurose&Ross2003])"

Apresentações semelhantes


Anúncios Google