Capítulo 2: Camada de Aplicação

Transcrição

1 Aplicações e protocolos da camada Capítulo 2: Camada Aplicação Antônio Abelém abelem@ufpa.br Aplicação: processos distribuídos em comunicação executam em hospeiros no espaço trocam mensagens para implementar p.ex., correio, transf. arquivo, WWW Protocolos da camada apl. uma parte da fine mensagens trocadas por apls e ações tomadas usam serviços providos por protocolos camadas inferiores transporte re enlace física transporte re enlace física transporte re enlace física 2: Camada Aplicação 1 2: Camada Aplicação 2 Aplicações re: algum jargão Paradigma - (C-S) Um processo éum programa em execução num hospeiro. 2 processos no mesmo hospeiro se comunicam usando communicação entre processos finida pelo sistema operacional (SO). 2 processos em hospeiros distintos se comunicam usando um protocolo da camada. Um (UA) é uma interface entre o e a re. WWW: browser Correio: leitor/compositor mensagens streaming audio/vio: tocador mídia Apl. re típica tem duas partes: and Cliente: inicia contato com o ( fala primeiro ) tipicamente solicita serviço do para WWW, implementado no browser; para correio no leitor mensagens Servidor: provê ao o serviço requisitado transporte re enlace física pedido resposta transporte re enlace física 2: Camada Aplicação 3 p.ex., WWW envia página solicitada; correio entrega mensagens 2: Camada Aplicação 4

2 Protocolos da camada (cont). API: interface programação aplicações fine interface entre e camada transporte socket (= tomada) : API da Internet 2 processos se comunicam enviando dados para um socket ou lendo dados um socket P: como um processo po intificar o outro processo com o qual quer se comunicar? enreço IP do hospeiro do outro processo número porta - permite que o hospeiro receptor termine a qual processo ve ser entregue a mensagem voltamos mais tar a este assunto. 2: Camada Aplicação 5 De que serviço transporte uma precisa? Perda dados algumas apls (p.ex. áudio) pom tolerar algumas perdas outras (p.ex., transf. arquivos, telnet) requerem transferência 100% confiável Temporização algumas apls (p.ex., telefonia Internet, jogos interativos) requerem baixo retardo para serem viáveis Largura banda algumas apls (p.ex., multimídia) requerem quantia mínima banda para serem viáveis outras apls ( apls elásticas ) conseguem usar qq quantia banda disponível 2: Camada Aplicação 6 Requisitos do serviço transporte apls comuns Serviços providos por protocolos transporte Internet Aplicação transferência arqs correio documentos WWW áudio/vío tempo real áudio/vío gravado jogos interativos apls financeiras Perdas sem perdas sem perdas sem perdas tolerante tolerante tolerante sem perdas Banda elástica elástica elástica áudio: 5Kb-1Mb vío:10kb-5mb como anterior > alguns Kbps elástica Sensibilida temporal não não não sim, 100 s mseg sim, alguns segs sim, 100 s mseg sim e não 2: Camada Aplicação 7 serviço TCP: orientado a conexão: setup requerido entre, transporte confiável entre processos remetente e receptor controle fluxo: remetente não vai afogar receptor controle congestionamento: estrangular remetente quando a re carregada não provê: garantias temporais ou banda mínima serviço UDP: transferência dados não confiável entre processos remetente e receptor não provê: setup da conexão, confiabilida, controle fluxo, controle congestionamento, garantias temporais ou banda mínima P: Qual é o interesse em ter um UDP? 2: Camada Aplicação 8

3 Apls Internet: seus protocolos e seus protocolos transporte WWW: algum jargão Aplicação correio eletrônico accesso terminal remoto WWW transferência arquivos streaming multimídia arquivo remoto telefonia Internet Protocolo da camada apl smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietário (p.ex. RealNetworks) NSF proprietário (p.ex., Vocaltec) Protocolo transporte usado TCP TCP TCP TCP TCP ou UDP TCP ou UDP tipicamente UDP Página WWW: consiste objetos enreçada por uma URL Quase todas as páginas WWW consistem : página base HTML, e vários objetos referenciados. URL tem duas partes: nome hospeiro, e nome caminho: Agent para WWW se chama browser: MS Internet Explorer Netscape Communicator Servidor para WWW se chama WWW : Apache (domínio público) MS Internet Information Server (IIS) 2: Camada Aplicação 9 2: Camada Aplicação 10 WWW: o protocolo http Mais sobre o protocolo http http: hypertext transfer protocol protocolo da camada para WWW molo / : browser que pe, recebe, visualiza objetos WWW : WWW envia objetos em resposta a pedidos http1.0: RFC 1945 http1.1: RFC 2068 PC executa Explorer Mac executa Navigator pedido http pedido http Servidor executando WWW da UFPA http: serviço transporte TCP: inicia conexão TCP (cria socket) ao, porta 80 aceita conexão TCP do mensagens http (mensagens do protocolo da camada apl) trocadas entre browser ( http) e e WWW ( http) encerra conexão TCP http é sem estado não mantém informação sobre pedidos anteriores do Nota Protocolos que mantêm estado são complexos! história pda (estado) tem que ser guardada Caso caia /, suas visões do estado pom ser inconsistentes, vem ser reconciliadas 2: Camada Aplicação 11 2: Camada Aplicação 12

4 tempo Exemplo http Supomos que digita a URL 1a. Cliente http inicia conexão TCP a http (processo) a Porta 80 é padrão para http. 2. http envia mensagem pedido http (contendo URL) através do socket da conexão TCP (contém texto, referências a 10 imagens jpeg) 1b. http no hospeiro espera por conexão TCP na porta 80. aceita conexão, avisando ao 3. http recebe mensagem pedido, formula mensagem resposta contendo objeto solicitado (algumdepartmento/inicial.inx), envia mensagem via socket 2: Camada Aplicação 13 tempo Exemplo http (cont.) 5. http recebe mensagem resposta contendo arquivo html, visualiza html. Analisando arquivo html, encontra 10 objetos jpeg referenciados 6. Passos 1 a 5 repetidos para cada um dos 10 objetos jpeg 4. http encerra conexão TCP. 2: Camada Aplicação 14 Conexões não persistente and persistente Não persistente HTTP/1.0 analisa pedido, respon, e encerra conexão TCP 2 RTTs para trazer cada objeto (RTT=round trip time) transferência cada objeto sofre partida lenta A maioria browsers 1.0 usa connexões TCP paralelas. Persistente fault for HTTP/1.1 na mesma conexão TCP: analisa pedido, respon, analisa novo pedido,.. Cliente envia pedidos para todos objetos referenciados assim que recebe o HTML base. Menos RTTs and menos partida lenta. 2: Camada Aplicação 15 formato mensagem http: pedido Dois tipos mensagem http: pedido, resposta mensagem pedido http: ASCII (formato legível por pessoas) linha do pedido (comandos GET, POST, HEAD) linhas do cabeçalho Carriage return, line feed indicate fim mensagem GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (carriage return (CR), line feed(lf) adicionais) 2: Camada Aplicação 16

5 mensagem pedido http: formato geral formato mensagem http: resposta linha status (protocolo, código status, frase status) dados, p.ex., arquivo html solicitado linhas cabeçalho HTTP/ OK Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun Content-Length: 6821 Content-Type: text/html dados dados dados dados... 2: Camada Aplicação 17 2: Camada Aplicação 18 códigos status da Na primeira linha da mensagem resposta ->. Alguns códigos típicos: 200 OK sucesso, objeto pedido segue mais adiante nesta mensagem 301 Moved Permanently objeto pedido mudou lugar, nova localização especificado mais adiante nesta mensagem (Location:) 400 Bad Request mensagem pedido não entendida pelo 404 Not Found documentopedidonãose encontraneste 505 HTTP Version Not Supported versão http do pedido não usada por este 2: Camada Aplicação 19 Interação -: GET condicional Meta: não enviar objeto se já tem (no cache) versão atual : especifica data da cópia no cache no pedido http If-modified-since: <date> : resposta não contém objeto se cópia no cache é atual: HTTP/ Not Modified msg pedido http If-modified-since: <date> HTTP/ Not Modified msg pedido http If-modified-since: <date> HTTP/ OK <data> objeto não modificado objeto modificado 2: Camada Aplicação 20

6 Cache WWW (-procurador) Por quê usar cache WWW? Servidores origem Meta: atenr pedido do sem envolver origem configura browser: acessos WWW via procurador envia todos pedidos http ao procurador se objeto estiver no cache do procurador, este o volve imediatamente na senão, solicita objeto do origem, pois volve resposta http ao pedido http pedido http Servidorprocurador pedido http pedido http Servidor origem Servidor origem 2: Camada Aplicação 21 Suposição: cache está próximo do (p.ex., na mesma re) tempo resposta menor: cache mais próximo do diminui tráfego aos es distantes muitas vezes é um gargalo o enlace que liga a re da instituição ou do provedor à Internet re da instituição Internet pública enlace accesso 2 Mbps LAN 10 Mbps cache da instituição 2: Camada Aplicação 22 ftp: o protocolo transferência arquivos ftp: conexões separadas p/ controle, dados na estação Interface do FTP FTP sistema arquivos local transferência do arquivo FTP transferir arquivo /para hospeiro remoto molo / sistema arquivos remoto : lado que inicia transferência (po ser ou para o sistema remoto) : hospeiro remoto ftp: RFC 959 ftp: porta 21 2: Camada Aplicação 23 ftp contata ftp na porta 21, especificando TCP como protocolo transporte são abertas duas conexões TCP paralelas: controle: troca comandos, respostas entre,. controle fora da banda dados: dados arquivo /para ftp mantém estado : directório corrente, autenticação realizada FTP conexão controle TCP, porta 21 conexão dados TCP, porta 20 FTP 2: Camada Aplicação 24

7 Ftp: comandos, respostas Comandos típicos: enviados em texto ASCII pelo canal controle USER nome PASS senha LIST volve lista arquivos no directório corrente RETR arquivo recupera (lê) arquivo remoto STOR arquivo armazena (escreve) arquivo no hospeiro remoto Códigos retorno típicos código e frase status (como para http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can t open data connection 452 Error writing file 2: Camada Aplicação 25 Correio Eletrônico Três grans componentes: s (UA) es correio simple mail transfer protocol: smtp Agente Usuário a.k.a. leitor correio compor, editar, ler mensagens correio p.ex., Eudora, Outlook, elm, Netscape Messenger mensagens saída e chegando são armazenadas no correio SMTP correio SMTP SMTP fila mensagens saída caixa correio do correio 2: Camada Aplicação 26 Correio Eletrônico: es correio Correio Eletrônico: smtp [RFC 821] Servidores correio caixa correio contém mensagens chegada (ainda não lidas) p/ fila mensagens contém mensagens saída (a serem enviadas) protocolo smtp entre es correio para transferir mensagens correio : correio que envia : correio que recebe correio SMTP correio SMTP SMTP correio 2: Camada Aplicação 27 usa tcp para a transferência confiável msgs do correio do ao, porta 25 transferência direta: remetente ao receptor três fases da transferência handshaking (cumprimento) transferência das mensagens encerramento interação comando/resposta comandos: texto ASCII resposta: código e frase status mensagens precisam ser em ASCII 7-bits 2: Camada Aplicação 28

8 Interação smtp típica smtp: últimas palavras S: 220 doces.br C: HELO consumidor.br S: 250 Hello consumidor.br, pleased to meet you C: MAIL FROM: S: 250 Senr ok C: RCPT TO: S: 250 Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Voce gosta chocolate? C: Que tal sorvete? C:. S: 250 Message accepted for livery C: QUIT S: 221 doces.br closing connection smtp usa conexões persistentes smtp requerque a mensagem (cabeçalho e corpo) sejam em ascii 7-bits algumas caias caracteres não são permitidas numa mensagem (p.ex., CRLF.CRLF). Logo a mensagem po ter que ser codificada (normalmente em base-64 ou quoted printable ) smtp usa CRLF.CRLF para reconhecer o final da mensagem Comparação com http http: pull (puxar) push (empurrar) ambos tem interação comando/resposta, códigos status em ASCII http: cada object é encapsulado em sua própria mensagem resposta smtp: múltiplos objetos mensagem enviados numa mensagem múltiplas partes 2: Camada Aplicação 29 2: Camada Aplicação 30 Formato uma mensagem: extensões para multimídia Protocolos accesso ao correio MIME: multimedia mail extension, RFC 2045, 2056 linhas adicionais no cabeçalho da msg claram tipo do conteúdo MIME SMTP SMTP POP3 ou IMAP versão MIME método usado p/ codificar dados tipo, subtipo dados multimídia, claração parâmetros Dados codificados From: ana@consumidor.br To: bernardo@doces.br Subject: Imagem uma bela torta MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encod data base64 encod data correio do remetente correio do receptor SMTP: entrega/armazenamento no do receptor protocolo accesso ao correio: recupera do POP: Post Office Protocol [RFC 1939] autorização ( <-->) e transferência IMAP: Internet Mail Access Protocol [RFC 1730] mais comandos (mais complexo) manuseio msgs armazenadas no HTTP: Hotmail, Yahoo! Mail, Webmail, etc. 2: Camada Aplicação 31 2: Camada Aplicação 32

9 DNS: Domain Name System Nomes DNS Pessoas: muitos intificadores: CPF, nome, no. Pporte hospeiros, roteadores Internet : enreço IP (32 bit) - usado p/ enreçar datagramas. nome, e.g., marajo.ufpa.br - usado por gente. P: como mapear entre nome e enreço IP? Domain Name System: base dados distribuída implementada através uma hierarquia es nomes. protocolo camada permite que hospeiros, roteadores e es nomes se comuniquem para resolver nomes (tradução enreço/nome) note: função imprescindível da Internet implementada como protocolo camada complexida na borda da re 2: Camada Aplicação 33 Um nome domínio é uma concatenação nomes: nome-n.....nome-2.nome-1 Conceitualmente, o nível mais alto (nome-1) permite duas formas diferentes nomeação: Organizacional com, edu, gov, int, mil, net e org Geográfica Código dos países: xx (código ISO 2 letras - exceto uk ) Exemplos: inf.puc-rio.br jb.com.br microsoft.com purdue.edu 2: Camada Aplicação 34 DNS - Estrutura Hierárquica com... nasa gov edu... ucla... censud petrobras.... com rdc Raiz br puc-rio inf ufrj triton... tijuca bach tpd ecp amazonas us nilo 2: Camada Aplicação 35 Organização distribuída da base dados Delegação responsabilidas Não é apenas uma única entida que gerencia todos os rótulos na árvore hierárquica O inter-nic gerencia o topo da árvore e lega responsabilidas para as sub-árvores restantes (nominadas zonas) O espaço nomes particionado em zonas zonas facilitam organização ferada e hierárquica autoridas gerenciamento do espaço nomes zonas legadas a organizações autorizadas (p.ex: br puc-rio inf ) 2: Camada Aplicação 36

10 Zona x Domínio Servidores nomes DNS Zona puc-rio.br Máquina responsável vel: vialáctea.rdc.puc ctea.rdc.puc-rio.brrio.br ele civ rdc triton Domínio puc-rio.br br Zona inf.puc-rio.br puc-rio Máquina responsável vel: exu.inf.puc-rio.br inf bach odudua tpd ecp jatoba nilo 2: Camada Aplicação 37 Por quê não centralizar o DNS? ponto único falha volume tráfego base dados centralizada e distante manutenção (da BD) Não é escalável! Nenhum mantém todos os mapeamento nomepara-enreço IP nomes local: cada provedor, empresa tem nomes local (fault) pedido DNS hospeiro vai primeiro ao nomes local nomes autoritativo: p/ hospeiro: guarda nome, enreço IP le po realizar tradução nome/enreço para este nome 2: Camada Aplicação 38 DNS: Servidores raíz Implementação do DNS procurado por local que não consegue resolver o nome raíz: procura autoritativo se mapeamento sconhecido obtém tradução volve mapeamento ao local ~ uma dúzia es raíz no mundo 2: Camada Aplicação 39 A estrutura hierárquica é global e distribuída entre es nomes resolução nomes uma pesquisa distribuída Tipo da pesquisa: recursiva: fornece resultado iterativa: fornece uma dica Uso cache guardar respostas localmente dados marcados com TTL (Time To Live) 2: Camada Aplicação 40

11 nome lógico Módulo Resolução Nomes Estação Origem Resolução Nomes Enreço IP nome lógico FTP TCP IP Estabelece conexão com enreço IP envia datagrama IP p/ end. IP Inter-Re FTP TCP IP Estação Destino Módulo Resolução Nomes: consulta arquivos locais Exemplo simples do DNS hospeiro tucuxi.ufpa.br requer enreço IP 1. Contata DNS local, marajo.ufpa.br 2. marajo.ufpa.br contata raíz, se necessário 3. Servidor raíz contata autoritativo cs.columbia.edu, se necessário local marajo.ufpa.br solicitante tucuxi.ufpa.br nomes raíz autoritativo cs.columbia.edu ou um serviço resolução nomes 2: Camada Aplicação 41 2: Camada Aplicação DNS: consultas iterativas consulta recursiva: transfere a responsabilida reolução do nome para o nomes contatado carga pesada? consulta interativa: consultado respon com o nome um contato Não conheço este nome, mas pergunte para esse 1 2 local marajo.ufpa.br 8 solicitante tucuxi.ufpa.br nomes raíz consulta interativa intermediário saell.cc.columbia.edu 5 6 autoritativo cs.columbia.edu 2: Camada Aplicação 43 Elementos do DNS Molo Cliente-Servidor Parte do Resolvedor ( Resolver ) Parte do Servidor nomes 2: Camada Aplicação 44

12 Resolvedor ( Resolver ) Cliente que acessa o Servidor Nomes Funções já contidas nas bibliotecas do sistema Informações (queries) pom ser solicitadas forma recursiva ou iterativa Exemplos: UNIX: arquivo /etc/resolv.conf nameserver nameserver domain inf.puc-rio.br Configuração Win 2000: Start -> Settings -> Control Panel -> Network -> Protocols -> (Selecionar TCP/IP Protocol) -> Properties -> DNS 2: Camada Aplicação 45 Servidor Nomes Programas es que fornecem mapeamento nome enreço tb. mantêm informação sobre recursos do domínio Servidores nomes mantêm BDs zonas Servidores replicam BDs para facilitar acesso primário mantém BD autoritativa da zona secundários carregam suas BDs a partir do primário (transferência zona) 2: Camada Aplicação 46 Tipos Servidores Primário: mantem as tabelas configuração DNS localmente Secundário (slave): recebe atualização do primário com informação sobre a zona Redundância no DNS Servidor Primário + Servidor(es) Secundário(s) inf.puc-rio.br puc-rio.br Caching-only: Somente realiza cache dos domínios consultados, sem nenhuma informação local Zona puc-rio.br (original) Zona inf.puc-rio.br (cópia) Zona inf.puc-rio.br (original) Zona puc-rio.br (cópia) 2: Camada Aplicação 47 2: Camada Aplicação 48

13 Servidor Nomes Servidor Nomes (Name Server) Unix Bind - um dos mais populares Processo: in.named Arquivos: named.conf (named.boot), root.servers, arquivos com informações referentes a zona responsabilida do Win 2000 Microsoft DNS Server (Start -> Programs -> Administrative Tools -> DNS Manager) Base dados local armazenada em arquivos contidos no diretório \Winnt\system32\Dns Respostas fornecidas pom ser autoritativas ou não-autoritativas DNS: uso cache, atualização dados uma vez um qualquer apren um mapeamento, ele o coloca numa cache local futuras consultas são resolvidas usando dados da cache entradas no cache são sujeitas a temporização (saparecem pois certo tempo) ttl = time to live (sobrevida) estão sendo projetados pela IETF mecanismos atualização/notificação dos dados RFC : Camada Aplicação 49 2: Camada Aplicação 50 DNS - Registros mais importantes Start of Authority (SOA):tem domínio, primário, configuração Name Server (NS): indica os es para este domínio inf.puc-rio.br IN NS exu.inf.puc-rio.br Address (A): mapeamento nome enreço exu.inf.puc-rio.br IN A Canonical Name (CNAME): especificar apelido IN CNAME exu.inf.puc-rio.br DNS - Registros mais importantes Pointer (PTR): mapeamento reverso (end nome) in-addr.arpa IN PTR exu.inf.puc-rio.br Host Information (HINFO): talhes da estação Mail exchanger (MX): apelidos para os es inf.puc-rio.br IN MX 0 exu.inf.puc-rio.br inf.puc-rio.br IN MX 10 omega.lncc.br Servidores pom pesquisar registros MX em orm priorida 2: Camada Aplicação 51 2: Camada Aplicação 52

14 Observações Relevantes sobre DNS Dualida sobre o protocolo transporte consultas normalmente usam UDP (porta 53) sincronização BDs usa TCP (porta 53) Desempenho acesso lento ao DNS po atrasar toda comunicação erros em BDs do DNS pom causar falhas coms. acesso ao DNS po se tornar um gargalo exemplo: DNS atrás um roteador congestionado 2: Camada Aplicação 53 Programação com sockets Meta: aprenr a construir / que se comunica usando sockets API Sockets apareceu em BSD4.1 UNIX, 1981 explicitamente criados, usados e liberados por apls paradigma / doistipos serviço transporte via API Sockets datagrama não confiável fluxo bytes, confiável socket uma interface (uma porta ), local ao hospeiro, criada por e pertencente à, e controlado pelo SO, através da qual um processo po tanto enviar como receber mensagens para/ outro processo (remoto ou local) 2: Camada Aplicação 54 Programação com sockets usando TCP Programação com sockets usando TCP Socket: uma porta entre o processo e um protocolo transporte fim-a-fim (UDP ou TCP) Serviço TCP: transferência confiável bytes um processo para outro controlado pelo programador controlado pelo sistema operacional processo socket TCP com buffers, variáveis estação ou internet processo socket TCP com buffers, variáveis estação ou controlado pelo programador controlado pelo sistema operacional 2: Camada Aplicação 55 Cliente ve contactar processo ve antes estar em execução ve antes ter criado socket (porta) que aguarda contato do Clientecontactapor: criar socket TCP local ao especificar enreço IP, número porta do processo Quando cria socket: TCP do estabelece conexão ao TCP Quando contactado pelo, TCP cria socket novo processo por se comunicar com o permite que o converse com múltiplos s ponto vista da TCP provê transferência confiável, ornada bytes ( tubo ) entre e 2: Camada Aplicação 56

15 Programação com sockets usando TCP Interações / com socket: TCP Exemplo apl -: lêlinhadaentrada padrão (fluxo dousuário), enviaparavia socket (fluxo paraservidor) lê linha do socket converte linha para letra maiúscula, volve para o lê linha modificada do socket (fluxo doservidor), imprime-a Input stream: sequence of bytes into process Output stream: sequence of bytes out of process dousuário paraservidor doservidor socket do 2: Camada Aplicação 57 Servidor (executa em idhosp) cria socket, porta=x, para receber pedido: socketrecepção = ServerSocket () TCP aguarda chegada pedido conexão setup da conexão socketconexão = socketrecepção.accept() lê pedido socketconexão escreve resposta para socketconexão fecha socketconexão Cliente cria socket, abre conexão a idhosp, porta=x socketcliente = Socket() Envia pedido usando socketcliente lê resposta socketcliente fecha socketcliente 2: Camada Aplicação 58 Programação com sockets usando UDP Interações / com socket: UDP UDP: não tem conexão entre e não tem handshaking remetente coloca explicitamente enreço IP e porta do stino ve extrair enreço IP, porta do remetente do datagrama recebido UDP: dados transmitidos pom ser recebidos fora orm, ou perdidos ponto vista da UDP provê transferência não confiável grupos bytes ( datagramas ) entre e Servidor (executa em idhosp) cria socket, porta=x, para pedido que chega: socketservidor = DatagramSocket() lê pedido do socketservidor escreve resposa ao socketservidor especificando enreço IP, número porta do Cliente cria socket, socketcliente = DatagramSocket() cria, enreça (idhosp, porta=x, envia pedido em datagrama usando socketcliente lê resposa do socketcliente fecha socketcliente 2: Camada Aplicação 59 2: Camada Aplicação 60