Camada de Aplicação Teleprocessamento e Redes

Apresentação em tema: "Camada de Aplicação Teleprocessamento e Redes"— 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 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 Cap. 2: Camada de Aplicação

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

4 Aplicações de Rede 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 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 Cap. 2: Camada de Aplicação

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

6 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

7 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 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 Temporização algumas aplicações (e.x., telefonia Internet, jogos interativos) exigem baixos atrasos para operarem Cap. 2: Camada de Aplicação

8 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 Sensível ao Atraso não sim, 100’s msec sim, segundos sim Cap. 2: Camada de Aplicação

9 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

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

11 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 http request PC rodando Explorer http response http request Servidor rodando NCSA Web server http response Mac rodando Netscape Navigator Cap. 2: Camada de Aplicação

12 Protocolo HTTP http é “stateless” http - protocolo de transporte: TCP
o servidor não mantém informação sobre os pedidos passados pelos clientes 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 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

13 Exemplo de Operação tempo
Usuário entra com a URL: (contém referência a 10 imagens jpeg) 1a. cliente http inicia conexão TCP ao servidor http (processo) em Porta 80 é a default para o servidor http . 1b. servidor http no host esperando pela conexão TCP na porta 80. “aceita” conexão, notificando o cliente 2. cliente http client envia uma mensagem de requisição http (contendo a URL) para o socket da conexão TCP 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

14 Exemplo (cont.) tempo 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

15 Conexões persistentes e não-persistentes
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. Cap. 2: Camada de Aplicação

16 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 Accept-language:fr (extra carriage return, line feed) linhas de cabeçalho Carriage return, line feed indica fim da mensagem Cap. 2: Camada de Aplicação

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

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

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

20 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

21 HTTP Cliente: faça você mesmo!
1. Telnet para um servidor Web: telnet 80 Abre conexão TCP para a porta 80 (porta default do servidor http) em Qualquer coisa digitada é enviada para a porta 80 em 2. Digite um pedido GET http: Digitando isto (tecle carriage return duas vezes), você envia este pedido HTTP GET mínimo (mas completo) ao servidor http GET /~ross/index.html HTTP/1.0 3. Examine a mensagem de resposta enviada pelo servidor http! Cap. 2: Camada de Aplicação

22 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

23 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=“ 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=“ feliz aniversário </A> Cap. 2: Camada de Aplicação

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

25 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 msg de pedido http comum + Authorization:line tempo msg de resposta http comum Browser guarda nome e senha para evitar que sejam pedidos ao usuário a cada acesso. Cap. 2: Camada de Aplicação

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

27 Conditional GET: armazenando no cliente
servidor 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/ Not Modified http request msg If-modified-since: <date> objeto não modificado http response HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> objeto modificado http response HTTP/ OK <data> Cap. 2: Camada de Aplicação

28 ftp: o protocolo de transferência de arquivos
interface de usuário cliente transferência de arquivos FTP servidor user at host sistema de arquivos local 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

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

30 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

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

32 Correio eletrônico: servidores de correio
mail server agente usuário servidor de correio SMTP 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 Cap. 2: Camada de Aplicação

33 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

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

35 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 sem usar o agente de usuário do rementente Cap. 2: Camada de Aplicação

36 SMTP: palavras finais Comparação com http:
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 Cap. 2: Camada de Aplicação

37 Formato das Mensagens cabeçalho corpo da mensagem
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 linha em branco corpo da mensagem Cap. 2: Camada de Aplicação

38 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 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 método usado para codificar dados tipo, subtipo e declaração de parâmetro dos dados multimídia dados codificados Cap. 2: Camada de Aplicação

39 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

40 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 delimitador 1a. parte: texto 2a. parte: imagem Cap. 2: Camada de Aplicação

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

42 Protocolos de acesso ao correio
SMTP SMTP POP3 or IMAP agente usuário agente usuário servidor de correio da origem 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

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

44 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

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

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

47 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 3 5 servidor de nomes autoritativo dns.umass.edu servidor de nomes local dns.eurecom.fr 1 6 computador solicitante surf.eurecom.fr gaia.cs.umass.edu Cap. 2: Camada de Aplicação

48 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 2 6 7 3 servidor de nomes intermediário dns.umass.edu servidor de nomes local dns.eurecom.fr 4 5 1 8 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: 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 5 6 1 8 servidor de nomes autoritativo dns.cs.umass.edu computador solicitante surf.eurecom.fr gaia.cs.umass.edu Cap. 2: Camada de Aplicação

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

51 formato dos RRs: (name, value, type, ttl)
registros do DNS DNS: base de dados distribuída que armazena registros de recursos (RRs) 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=NS name é um domínio (ex. foo.com) value é o endereço IP do servidor de nomes autoritativo para este domínio Type=MX value é o nome canônico do servidor de correio associado com name Cap. 2: Camada de Aplicação

52 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

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

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

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

56 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

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

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

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

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

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

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

63 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

64 Interação Cliente/servidor: UDP
(executando em hostid) Cliente cria socket, porta=x, para solicitação entrante: serverSocket = DatagramSocket() lê pedido de: serverSocket cria socket, clientSocket = DatagramSocket() Cria endereço (hostid, port=x), envia datagrama de pedido usando clientSocket fecha clientSocket lê resposta de clientSocket escreve resposta para serverSocket especificando endereço do host cliente e número da porta Cap. 2: Camada de Aplicação

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

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

67 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); 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(); } Envia datagrama para servidor Lê datagrama do servidor Cap. 2: Camada de Aplicação

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

69 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 Cria datagrama para enviar ao cliente Escreve o datagrama para dentro do socket Termina o while loop, retorna e espera por outro datagrama Cap. 2: Camada de Aplicação

70 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,” Cap. 2: Camada de Aplicação

71 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

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

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

74 WebServer.java (2) DataOutputStream outToClient =
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(); Separa os tokens da requisição Lê requisição do cliente Verifica se comando é GET Obtém o nome do arquivo Obtém o tamanho do arquivo Cap. 2: Camada de Aplicação

75 WebServer.java (3) Lê o arquivo requisitado 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”)) image/gif\r\n”); Envia a primeira linha do cabeçalho da resposta Segunda linha (content-type) depende do tipo do arquivo requisitado (jpeg ou gif) Cap. 2: Camada de Aplicação

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

77 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

78 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

79 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 Proxy server http request http response cliente http request http response cliente servidor original Cap. 2: Camada de Aplicação

80 Porque Web Caching? menor tempo de resposta
servidores originais Internet pública rede institucional 10 Mbps LAN enlace de acesso 1.5 Mbps cache 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 Cap. 2: Camada de Aplicação

81 Análise simplificada servidores originais
Internet pública 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 enlace de acesso 1.5 Mbps rede institucional 10 Mbps LAN (15 reqs/s) . (100kbits/req)/(10Mbps) = 0,15 (15 reqs/s) . (100kbits/req)/(1,5Mbps) = 1 Cap. 2: Camada de Aplicação

82 Análise: Com o Proxy servidores originais 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! Internet pública enlace de acesso 1.5 Mbps rede institucional 10 Mbps LAN 0,4*(0,01s) + 0,6*(2,01s) = 1,2s cache institucional Cap. 2: Camada de Aplicação

83 Caches Cooperativas Múltiplos níveis de caches
servidor original Req. Resp. cache nacional 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. cache do ISP Req. Resp. Req. Resp. cache institucional cliente Cap. 2: Camada de Aplicação

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

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

86 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

87 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 Norte servidor de distribuição na Am. do Sul servidor de distribuição na Europa Cap. 2: Camada de Aplicação

88 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 Distribuído pelo servidor original Distribuído pela CDN Cap. 2: Camada de Aplicação

89 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

90 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

91 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

92 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

93 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

94 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