Your SlideShare is downloading. ×
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Cap2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cap2

1,000

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,000
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Capítulo 2: Camada de Aplicação Aplicações e protocolos da camada de aplicação Metas do capítulo: Mais metas do capítulo Aplicação: processos distribuídos aplicação transporte Ì aspectos conceituais e de em comunicação Ì protocolos específicos: rede enlace implementação de r executem em hospedeiros física r http protocolos de aplicação no “espaço de usuário” r ftp em redes r trocam mensagens para r smtp implementar aplicação r paradigma cliente servidor r pop r p.ex., correio, transf. de r modelos de serviço r dns arquivo, WWW Ì aprenda sobre protocolos Ì a programação de Protocolos da camada de apl. aplicação através do estudo de aplicações de rede r uma “parte” da aplicação aplicação transporte transporte rede protocolos populares do r define mensagens trocadas rede enlace r programação usando sockets enlace física nível da aplicação por apls e ações tomadas física r usam serviços providos por protocolos de camadas inferiores 2: Camada de Aplicação 1 2: Camada de Aplicação 2 Aplicações de rede: algum jargão Paradigma cliente-servidor (C-S) Apl. de rede típica tem duas aplicação Ì Um processo é um Ì Um agente de usuário partes: cliente and servidor transporte rede programa que executa num (UA) é uma interface enlace hospedeiro. Cliente: física entre o usuário e a Ì inicia contato com o servidor pedido Ì 2 processos no mesmo hospedeiro se comunicam aplicação de rede. (“fala primeiro”) usando communicação entre r WWW: browser Ì tipicamente solicita serviço do processos definida pelo r Correio: servidor sistema operacional (SO). leitor/compositor de Ì para WWW, cliente resposta Ì 2 processos em mensagens implementado no browser; para aplicação hospedeiros distintos se r streaming audio/video: correio no leitor de mensagens transporte rede comunicam usando um tocador de mídia Servidor: enlace física protocolo da camada de Ì provê ao cliente o serviço apalicação. requisitado Ì p.ex., servidor WWW envia página solicitada; servidor de 2: Camada de Aplicação 2: Camada de Aplicação 3 correio entrega mensagens 4 De que serviço de transporte uma Protocolos da camada de aplicação (cont). aplicação precisa? Perda de dados Largura de banda API: interface de P: como um processo pode Ì algumas apls (p.ex. áudio) Ì algumas apls (p.ex., programação de “identificar”o outro podem tolerar algumas multimídia) requerem aplicações processo com o qual perdas quantia mínima de banda Ì define interface entre quer se comunicar? Ì outras (p.ex., transf. de para serem “viáveis” aplicação e camada de r endereço IP do arquivos, telnet) requerem Ì outras apls (“apls elásticas”) hospedeiro do outro transferência 100% conseguem usar qq quantia transporte processo confiável de banda disponível Ì socket (= tomada) : API r “número de porta” - da Internet permite que o hospedeiro Temporização r 2 processos se comunicam receptor determine a Ì algumas apls (p.ex., enviando dados para um qual processo deve ser telefonia Internet, jogos socket ou lendo dados de entregue a mensagem interativos) requerem um socket baixo retardo para serem “viáveis” … voltamos mais tarde a este assunto. 2: Camada de Aplicação 5 2: Camada de Aplicação 6
  • 2. Serviços providos por protocolos de Requisitos do serviço de transporte de apls comuns transporte Internet Sensibilidade temporal serviço TCP: serviço UDP: Aplicação Perdas Banda Ì orientado a conexão: setup Ì transferência de dados não transferência de arqs sem perdas elástica não requerido entre cliente, confiável entre processos correio sem perdas elástica não servidor remetente e receptor documentos WWW sem perdas elástica não Ì transporte confiável entre Ì não provê: setup da conexão, áudio/vídeo de tolerante áudio: 5Kb-1Mb sim, 100’s mseg processos remetente e confiabilidade, controle de tempo real vídeo:10Kb-5Mb receptor fluxo, controle de áudio/vídeo gravado tolerante como anterior sim, alguns segs Ì controle de fluxo: remetente congestionamento, garantias jogos interativos tolerante > alguns Kbps sim, 100’s mseg não vai “afogar” receptor temporais ou de banda apls financeiras sem perdas elástica sim e não mínima Ì controle de congestionamento: estrangular remetente quando P: Qual é o interesse em ter um a rede carregada UDP? Ì não provê: garantias 2: Camada de Aplicação 7 temporais ou de banda mínima 2: Camada de Aplicação 8 Apls Internet: seus protocolos e seus protocolos de transporte WWW: algum jargão Protocolo da Protocolo de Ì Agent de usuário para Ì Página WWW: Aplicação camada de apl transporte usado WWW se chama de r consiste de “objetos” browser: correio eletrônico smtp [RFC 821] TCP r endereçada por uma URL accesso terminal remoto r MS Internet Explorer Ì Quase todas as páginas telnet [RFC 854] TCP WWW http [RFC 2068] TCP r Netscape Communicator WWW consistem de: transferência de arquivos ftp [RFC 959] TCP Ì Servidor para WWW se streaming multimídia r página base HTML, e proprietário TCP ou UDP chama “servidor (p.ex. RealNetworks) r vários objetos servidor de arquivo remoto NSF TCP ou UDP referenciados. WWW”: telefonia Internet proprietário r Apache (domínio público) tipicamente UDP Ì URL tem duas partes: (p.ex., Vocaltec) r MS Internet Information nome de hospedeiro, e Server (IIS) nome de caminho: www.univ.br/algum-depto/pic.gif 2: Camada de Aplicação 9 2: Camada de Aplicação 10 WWW: o protocolo http Mais sobre o protocolo http http: hypertext transfer http: serviço de http é “sem estado” protocol ped ido transporte TCP: Ì servidor não mantém Ì protocolo da camada de PC executa htt p Ì cliente inicia conexão TCP informação sobre res aplicação para WWW Explorer pos ta (cria socket) ao servidor, pedidos anteriores do htt p porta 80 cliente Ì modelo cliente/servidor Ì servidor aceita conexão TCP Nota r cliente: browser que Protocolos que mantêm p pede, recebe, “visualiza” htt o do cliente “estado” são complexos! did Servidor pe ttp objetos WWW ah executando Ì mensagens http (mensagens Ì história passada (estado) ost sp servidor do protocolo da camada de r servidor: servidor re tem que ser guardada WWW WWW envia objetos em do NCSA apl) trocadas entre browser Ì Caso caia servidor/cliente, resposta a pedidos (cliente http) e servidore suas visões do “estado” Mac executa WWW (servidor http) Ì http1.0: RFC 1945 Navigator podem ser inconsistentes, Ì encerra conexão TCP devem ser reconciliadas Ì http1.1: RFC 2068 2: Camada de Aplicação 11 2: Camada de Aplicação 12
  • 3. Exemplo de http Exemplo de http (cont.) Supomos que usuário digita a URL (contém texto, 4. servidor http encerra conexão www.algumaUniv.br/algumDepartmento/inicial.index referências a 10 TCP . 5. cliente http recebe mensagem imagens jpeg) de resposta contendo arquivo 1a. Cliente http inicia conexão html, visualiza html. TCP a servidor http (processo) Analisando arquivo html, 1b. servidor http no hospedeiro a www.algumaUniv.br. Porta 80 encontra 10 objetos jpeg é padrão para servidor http. www.algumaUniv.br espera por conexão TCP na porta 80. referenciados “aceita” conexão, avisando ao cliente 6. Passos 1 a 5 repetidos para 2. cliente http envia mensagem cada um dos 10 objetos jpeg de pedido de http (contendo URL) através do socket da 3. servidor http recebe mensagem tempo conexão TCP de pedido, formula mensagem de resposta contendo objeto solicitado (algumDepartmento/inicial.index), envia mensagem via socket tempo 2: Camada de Aplicação 13 2: Camada de Aplicação 14 Conexões não persistente and persistente formato de mensagem http: pedido Não persistente Persistente Ì HTTP/1.0 Ì default for HTTP/1.1 Ì Dois tipos de mensagem http: pedido, resposta Ì servidor analisa Ì na mesma conexão TCP: Ì mensagem de pedido http: pedido, responde, and servidor analisa pedido, r ASCII (formato legível por pessoas) encerra conexão TCP responde, analisa novo Ì 2 RTTs para trazer pedido,.. linha do pedido cada objeto Ì Cliente envia pedidos (comandos GET, GET /somedir/page.html HTTP/1.0 (RTT=round trip time) para todos objetos POST, HEAD) User-agent: Mozilla/4.0 Ì transferência de cada referenciados assim Accept: text/html, image/gif,image/jpeg linhas do Accept-language:fr objeto sofre de que recebe o HTML cabeçalho partida lenta base . Carriage return, (carriage return (CR), line feed(LF) adicionais) A maioria de browsers 1.0 Ì Menos RTTs and menos line feed usa connexões TCP paralelas. partida lenta. indicate fim de mensagem 2: Camada de Aplicação 15 2: Camada de Aplicação 16 mensagem de pedido http: formato geral formato de mensagem http: resposta linha de status (protocolo, código de status, HTTP/1.0 200 OK frase de status) Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... linhas de Content-Length: 6821 cabeçalho Content-Type: text/html dados dados dados dados ... dados, p.ex., arquivo html solicitado 2: Camada de Aplicação 17 2: Camada de Aplicação 18
  • 4. códigos de status da resposta http Experimente você com http (do lado cliente) Na primeira linha da mensagem de resposta servidor->cliente. Alguns códigos típicos: 1. Use cliente telnet para seu servidor WWW favorito: 200 OK telnet www.ic.uff.br 80 Abre conexão TCP para a porta 80 r sucesso, objeto pedido segue mais adiante nesta mensagem (porta padrão do servidor http) a www.ic.uff.br. Qualquer coisa digitada é enviada para a 301 Moved Permanently porta 80 do www.ic.uff.br r objeto pedido mudou de lugar, nova localização especificado mais adiante nesta mensagem (Location:) 2. Digite um pedido GET http: 400 Bad Request Digitando isto (deve teclar GET /~michael/index.html HTTP/1.0 r mensagem de pedido não entendida pelo servidor ENTER duas vezes), está enviando este pedido GET mínimo (porém 404 Not Found completo) ao servidor http r documento pedido não se encontra neste servidor 505 HTTP Version Not Supported 3. Examine a mensagem de resposta enviado pelo r versão de http do pedido não usada por este servidor servidor http ! 2: Camada de Aplicação 19 2: Camada de Aplicação 20 HTML (HyperText Markup Language) Encadeamento de referências Ì HTML: uma linguagem simples para hipertexto Ì Referências <A HREF=LinkRef> ... </A> r começou como versão simples de SGML r a componentes do documento local r construção básica: cadéias de texto anotadas <A HREF=“importante”> clique para uma dica </A> r a documentos no servidor local Ì Construtores de formato operam sobre cadéias <A HREF=“../index.htm”> voltar ao sumário </A> r <b> .. </b> bold (negrito) r a documentos em outros servidores r <H1 ALIGN=CENTER> ..título centrado .. </H1> <A HREF=“http://www.uff.br”> saiba sobre a UFF </A> r <BODY bgcolor=white text=black link=red ..> .. </BODY> Ì Multimídia Ì vários formatos r imagem embutida: <IMG SRC=“eclipse”> r listas de bullets, listas ordenadas, listas de definição r imagem externa: <A HREF=“eclipse.gif”> imagem maior </A> r tabelas r vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A> r frames r som <A HREF=“http://www.sons.br/aniv.au”> feliz niver </A> 2: Camada de Aplicação 21 2: Camada de Aplicação 22 Formulários e interação bidirecional Interação usuário-servidor: autenticação Meta da autenticação: controle de Ì Formulários transmitem Ì Formulários processados usando acesso aos documentos do cliente servidor servidor informação do cliente ao scripts CGI (programas que msg de pedido http comum servidor executam no servidor WWW) Ì sem estado: cliente deve apresentar autorização com 401: authorization req. Ì HTTP permite enviar r CGI - Common Gateway WWW authenticate: cada pedido formulários ao servidor Interface Ì autorização: tipicamente nome, Ì Resposta enviada como r scripts CGI escondem senha msg de pedido http comum página HTML dinâmica acesso a diferentes serviços + Authorization:line r authorization: linha de r servidor WWW atua como cabeçalho no pedido msg de resposta http comum gateway universal r se não for apresentada autorização, servidor nega GET/POST accesso, e coloca no msg de pedido http comum formulário cabeçalho da resposta + Authorization:line cliente servidor Sistema de tempo WWW WWW informação WWW authenticate: msg de resposta http comum resposta: Browser guarda nome e senha para HTML 2: Camada de Aplicação 23 evitar que sejam pedidos ao usuário a cada acesso. 2: Camada de Aplicação 24
  • 5. Interação usuário-servidor: cookies Interação usuário-servidor: GET condicional cliente servidor cliente servidor msg de pedido http comum Ì servidor envia “cookie” ao msg de pedido http Ì Meta: não enviar objeto se cliente na msg de resposta resposta http comum+ If-modified-since: objeto cliente já tem (no cache) Set-cookie: # <date> não Set-cookie: 1678453 versão atual Ì cliente apresenta cookie resposta http modificado Ì cliente: especifica data da HTTP/1.0 nos pedidos posteriores msg de pedido http comum Ação cópia no cache no pedido 304 Not Modified cookie: # cookie: 1678453 específica http Ì servidor casa cookie- msg de resposta http comum do cookie If-modified-since: apresentado com a info <date> msg de pedido http guardada no servidor Ì servidor: resposta não If-modified-since: objeto r autenticação msg de pedido http comum contém objeto se cópia no <date> Ação modificado cookie: # cache é atual: resposta http r lembrando preferências específica HTTP/1.1 200 OK do usuário, opções msg de resposta http comum do cookie HTTP/1.0 304 Not … anteriores Modified <data> 2: Camada de Aplicação 25 2: Camada de Aplicação 26 Cache WWW (servidor-procurador) Por quê usar cache WWW? Servidores de origem Meta: atender pedido do cliente sem envolver servidor de origem Suposição: cache está Ì usuário configura Servidor “próximo” do cliente Internet pública browser: acessos WWW de origem (p.ex., na mesma rede) cliente via procurador Servidor- ped Ì tempo de resposta Ì cliente envia todos ido procurador ttp pedidos http ao res htt p oh did ttp menor: cache “mais enlace de accesso pos pe ah procurador ta htt sp ost próximo” do cliente 2 Mbps p re r se objeto no cache do ttp ped Ì diminui tráfego aos rede da procurador, este o oh tp ido instituição did ht htt servidores distantes LAN 10 Mbps pe res devolve imediatamente o sta pos p sp ta h na resposta http re ttp r muitas vezes é um r senão, solicita objeto do gargalo o enlace que liga cliente a rede da instituição ou cache da servidor de origem, Servidor depois devolve resposta de origem do provedor à Internet instituição http ao cliente 2: Camada de Aplicação 27 2: Camada de Aplicação 28 ftp: o protocolo de transferência ftp: conexões separadas p/ controle, dados de arquivos transferência Ì cliente ftp contata servidor Interface cliente do arquivo ftp na porta 21, FTP do usuário FTP FTP servidor especificando TCP como conexão de controle usuário protocolo de transporte TCP, porta 21 sistema de sistema de na Ì são abertas duas conexões estação arquivos arquivos local remoto TCP paralelas: conexão de dados r controle: troca comandos, cliente TCP, porta 20 servidor Ì transferir arquivo de/para hospedeiro remoto respostas entre cliente, FTP FTP Ì modelo cliente/servidor servidor. rcliente: lado que inicia transferência (pode ser de ou “controle fora da banda” para o sistema remoto) r dados: dados de arquivo r servidor: hospedeiro remoto de/para servidor Ì ftp: RFC 959 Ì servidor ftp mantém Ì servidor ftp: porta 21 “estado”: directório corrente, autenticação realizada 2: Camada de Aplicação 29 2: Camada de Aplicação 30
  • 6. fila de Ftp: comandos, respostas Correio Eletrônico mensagens de saída caixa de agente correio do usuário Comandos típicos: Códigos de retorno típicos Três grandes componentes: de usuário Ì enviados em texto ASCII pelo Ì código e frase de status (como Ì agentes de usuário (UA) servidor agente de canal de controle para http) Ì servidores de correio de correio usuário Ì USER nome Ì 331 Username OK, password Ì simple mail transfer protocol: SMTP servidor Ì PASS senha required smtp de correio agente Ì LIST devolve lista de arquivos Ì 125 data connection SMTP de already open; transfer Agente de Usuário usuário no directório corrente Ì RETR arquivo recupera (lê) starting Ì a.k.a. “leitor de correio” SMTP agente arquivo remoto Ì 425 Can’t open data Ì compor, editar, ler mensagens servidor de connection de correio de correio usuário Ì STOR arquivo armazena (escreve) arquivo no hospedeiro Ì 452 Error writing file Ì p.ex., Eudora, Outlook, elm, agente remoto Netscape Messenger de Ì mensagens de saída e chegando agente usuário são armazenadas no servidor de usuário 2: Camada de Aplicação 31 2: Camada de Aplicação 32 Correio Eletrônico: servidores de correio Correio Eletrônico: smtp [RFC 821] agente Servidores de correio de usuário Ì usa tcp para a transferência confiável de msgs do correio Ì caixa de correio contém agente do cliente ao servidor, porta 25 servidor mensagens de chegada de correio de Ì transferência direta: servidor remetente ao servidor usuário (ainda não lidas) p/ usuário receptor SMTP Ì fila de mensagens contém servidor Ì três fases da transferência de correio mensagens de saída (a serem r handshaking (cumprimento) enviadas) SMTP r transferência das mensagens Ì protocolo smtp entre SMTP r encerramento servidores de correio para agente servidor de Ì interação comando/resposta transferir mensagens de de correio usuário r comandos: texto ASCII correio r resposta: código e frase de status r cliente: servidor de agente correio que envia de usuário Ì mensagens precisam ser em ASCII de 7-bits agente r “servidor”: servidor de de correio que recebe usuário 2: Camada de Aplicação 33 2: Camada de Aplicação 34 Interaction smtp típica Experimente você uma interação smtp : S: 220 doces.br C: HELO consumidor.br Ì telnet nomedoservidor 25 S: 250 Hello consumidor.br, pleased to meet you C: MAIL FROM: <ana@consumidor.br> Ì veja resposta 220 do servidor S: 250 ana@consumidor.br... Sender ok Ì entre comandos HELO, MAIL FROM, RCPT TO, C: RCPT TO: <bernardo@doces.br> DATA, QUIT S: 250 bernardo@doces.br ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself estes comandos permite que você envie correio sem C: Voce gosta de chocolate? usar um cliente (leitor de correio) C: Que tal sorvete? C: . S: 250 Message accepted for delivery C: QUIT S: 221 doces.br closing connection 2: Camada de Aplicação 35 2: Camada de Aplicação 36
  • 7. smtp: últimas palavras Formato de uma mensagem Ì smtp usa conexões Comparação com http smtp: protocolo para trocar persistentes msgs de correio cabeçalho Ì http: pull (puxar) linha em Ì smtp requerque a mensagem RFC 822: padrão para formato Ì email: push (empurrar) branco (cabeçalho e corpo) sejam em de mensagem de texto: ascii de 7-bits Ì ambos tem interação Ì linhas de cabeçalho, p.ex., Ì algumas cadeias de caracteres comando/resposta, códigos To: r corpo não são permitidas numa de status em ASCII r From: mensagem (p.ex., CRLF.CRLF). r Subject: Logo a mensagem pode ter que Ì http: cada object é diferentes dos comandos de ser codificada (normalmente encapsulado em sua própria smtp! em base-64 ou “quoted mensagem de resposta Ì corpo printable”) Ì smtp: múltiplos objetos de r a “mensagem”, somente de Ì servidor smtp usa CRLF.CRLF mensagem enviados numa caracteres ASCII para reconhecer o final da mensagem de múltiplas mensagem partes 2: Camada de Aplicação 37 2: Camada de Aplicação 38 Formato de uma mensagem: extensões para Tipos MIME multimídia Content-Type: tipo/subtipo; parâmetros Ì MIME: multimedia mail extension, RFC 2045, 2056 Ì linhas adicionais no cabeçalho da msg declaram tipo do Text Audio conteúdo MIME Ì subtipos exemplos: plain, Ì subtipos exemplos : basic html (8-bit codificado mu-law), Ì charset=“iso-8859-1”, 32kadpcm (codificação 32 From: ana@consumidor.br versão MIME ascii kbps) To: bernardo@doces.br Subject: Imagem de uma bela torta Application método usado p/ codificar dados MIME-Version: 1.0 Image Ì outros dados que precisam Content-Transfer-Encoding: base64 Ì subtipos exemplos : jpeg, ser processados por um Content-Type: image/jpeg tipo, subtipo de gif leitor para serem dados multimídia, base64 encoded data ..... “visualizados” declaração parâmetros Ì subtipos exemplos : ......................... ......base64 encoded data Video msword, octet-stream Dados codificados Ì subtipos exemplos : mpeg, quicktime 2: Camada de Aplicação 39 2: Camada de Aplicação 40 Tipo Multipart From: ana@consumidor.br To: bernardo@doces.br Protocolos de accesso ao correio Subject: Imagem de uma bela torta MIME-Version: 1.0 agente SMTP SMTP POP3 ou agente Content-Type: multipart/mixed; boundary=98766789 de de usuário IMAP usuário --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain servidor de correio servidor de correio do remetente do receptor caro Bernardo, Ì SMTP: entrega/armazenamento no servidor do receptor Anexa a imagem de uma torta deliciosa. --98766789 Ì protocolo de accesso ao correio: recupera do servidor Content-Transfer-Encoding: base64 r POP: Post Office Protocol [RFC 1939] Content-Type: image/jpeg • autorização (agente <-->servidor) e transferência base64 encoded data ..... r IMAP: Internet Mail Access Protocol [RFC 1730] ......................... ......base64 encoded data • mais comandos (mais complexo) --98766789-- • manuseio de msgs armazenadas no servidor r HTTP: Hotmail , Yahoo! Mail, Webmail, etc. 2: Camada de Aplicação 41 2: Camada de Aplicação 42
  • 8. Protocolo POP3 S: +OK POP3 server ready DNS: Domain Name System C: user ana fase de autorização S: +OK C: pass faminta Pessoas: muitos Domain Name System: Ì comandos do cliente: S: +OK user successfully logged on identificadores: Ì base de dados distribuída r user: declara nome implementada na hierarquia de C: list r CPF, nome, no. de r pass: senha muitos servidores de nomes S: 1 498 Passaporte Ì servidor responde S: 2 912 Ì protocolo de camada de aplicação hospedeiros, roteadores r +OK S: . permite hospedeiros, roteadores, C: retr 1 Internet : servidores de nomes r -ERR S: <message 1 contents> r endereço IP (32 bit) - communicarem para resolver fase de transação, cliente: S: . usado p/ endereçar nomes (tradução endereço/nome) C: dele 1 Ì list: lista números das C: retr 2 datagramas r note: função imprescindível da msgs S: <message 1 contents> r “nome”, e.g., Internet implementada como Ì retr: recupera msg por S: . jambo.ic.uff.br - usado protocolo de camada de número C: dele 2 por gente aplicação C: quit Ì dele: apaga msg S: +OK POP3 server signing off P: como mapear entre r complexidade na borda da rede Ì quit 2: Camada de Aplicação 43 nome e endereço IP? 2: Camada de Aplicação 44 Servidores de nomes DNS DNS: Servidores raíz Por quê não centralizar o Ì Nenhum servidor mantém Ì procurado por servidor DNS? todos os mapeamento nome- local que não consegue Ì ponto único de falha para-endereço IP resolver o nome servidor de nomes local: Ì servidor raíz: Ì volume de tráfego r procura servidor r cada provedor, empresa tem Ì base de dados autoritativo se servidor de nomes local (default) centralizada e distante r pedido DNS de hospedeiro vai mapeamento desconhecido Ì manutenção (da BD) primeiro ao servidor de nomes r obtém tradução local r devolve servidor de nomes autoritativo: Não é escalável! mapeamento ao r p/ hospedeiro: guarda nome, servidor local endereço IP dele Ì ~ uma dúzia de r pode realizar tradução servidores raíz no nome/endereço para este nome mundo 2: Camada de Aplicação 45 2: Camada de Aplicação 46 Exemplo simples do DNS Exemplo de DNS servidor de servidor de nomes raíz nomes raíz hospedeiro Servidor raíz: 2 6 manga.ic.uff.br requer 2 4 Ì pode não conhecer o 7 3 3 endereço IP de 5 servidor de nomes www.cs.columbia.edu autoritativo 1. Contata servidor DNS local, Ì pode conhecer pitomba.ic.uff.br servidor de nomes servidor local servidor intermediário servidor local servidor autoritativo intermediário: a quem pitomba.ic.uff.br saell.cc.columbia.edu 2. pitomba.ic.uff.br pitomba.ic.uff.br cs.columbia.edu contata servidor raíz, se contactar para 4 5 1 8 necessário 1 6 descobrir o servidor de nomes autoritativo 3. Servidor raíz contata servidor autoritativo servidor autoritativo cs.columbia.edu cs.columbia.edu, se solicitante solicitante www.cs.columbia.edu manga.ic.uff.br necessário manga.ic.uff.br www.cs.columbia.edu 2: Camada de Aplicação 47 2: Camada de Aplicação 48
  • 9. DNS: consultas iteratadas servidor de DNS: uso de cache, atualização de dados nomes raíz consulta recursiva: 2 consulta Ì uma vez um servidor qualquer aprende um Ì transfere a 3 iterrada mapeamento, ele o coloca numa cache local responsabilidade de 4 r futuras consultas são resolvidas usando dados reolução do nome para o servidor de nomes 7 da cache cntatado servidor intermediário r entradas no cache são sujeitas a temporização servidor local Ì carga pesada? pitomba.ic.uff.br saell.cc.columbia.edu (desaparecem depois de certo tempo) 5 6 ttl = time to live (sobrevida) consulta iterada: 1 8 Ì servidor consultado Ì estão sendo projetados pela IETF mecanismos responde com o nome servidor autoritativo de atualização/notificação dos dados cs.columbia.edu de um servidor de solicitante r RFC 2136 contato manga.ic.uff.br r http://www.ietf.org/html.charters/dnsind-charter.html Ì “Não conheço este www.cs.columbia.edu nome, mas pergunte para esse servidor” 2: Camada de Aplicação 49 2: Camada de Aplicação 50 Registros DNS DNS: protocolo, mensagens DNS: BD distribuída contendo resource records (RR) protocolo DNS: mensagens pedido e resposta, ambas com o mesmo formato de mensagem formato RR: (nome, valor, tipo, sobrevida) cabeçalho de msg Ì Tipo=A Ì Tipo=CNAME Ì identification: ID de 16 bit r nome é nome de hospedeiro r nome é nome alternativo para pedido, resposta ao r valor é endereço IP (alias) para algum nome pedido usa mesmo ID “canônico” (verdadeiro) Ì flags: Ì Tipo=NS r valor é o nome r pedido ou resposta r nome é domínio (p.ex. canônico r recursão desejada foo.com.br) Ì Tipo=MX r recursão permitida r valor é endereço IP de servidor de nomes r nome é domínio r resposta é autoritativa autoritativo para este r valor é nome do servidor de domínio correio para este domínio 2: Camada de Aplicação 51 2: Camada de Aplicação 52 DNS: protocolo, mensagens Programação com sockets Meta: aprender construir aplicação cliente/servidor que campos nome, tipo comunica usando sockets num pedido socket API Sockets uma interface (uma RRs em resposta Ì apareceu em BSD4.1 UNIX, “porta”), local ao ao pedido 1981 hospedeiro, criada por e Ì explicitamente criados, pertencente à aplicação, e registros para usados e liberados por apls controlado pelo SO, servidores autoritativos Ì paradigma cliente/servidor através da qual um processo de aplicação info adicional Ì dois tipos de serviço de pode tanto enviar como “relevante” que transporte via API Sockets receber mensagens pode ser usada r datagrama não confiável para/de outro processo r fluxo de bytes, confiável de aplicação (remoto ou local) 2: Camada de Aplicação 53 2: Camada de Aplicação 54
  • 10. Programação com sockets usando TCP Programação com sockets usando TCP Socket: uma porta entre o processo de aplicação e um Cliente deve contactar servidor Ì Quando cliente cria socket: TCP Ì processo servidor deve antes do cliente estabelece conexão protocolo de transporte fim-a-fim (UDP ou TCP) estar em execução ao servidor TCP Serviço TCP: transferência confiável de bytes de um Ì servidor deve antes ter Ì Quando contactado pelo cliente, processo para outro criado socket (porta) que servidor TCP cria socket novo aguarda contato do cliente processo servidor poder se comunicar com o cliente controlado pelo Cliente contacta servidor por: controlado pelo processo programador de r permite que o servidor programador de processo Ì criar socket TCP local ao aplicação converse com múltiplos aplicação socket socket cliente clientes TCP com TCP com controlado Ì especificar endereço IP, controlado buffers, pelo sistema ponto de vista da aplicação pelo sistema buffers, internet operacional número de porta do processo operacional variáveis variáveis TCP provê transferência servidor confiável, ordenada de bytes estação ou estação ou (“tubo”) entre cliente e servidor servidor servidor 2: Camada de Aplicação 55 2: Camada de Aplicação 56 Programação com sockets usando TCP Interações cliente/servidor com socket: TCP Servidor (executa em idHosp) Cliente Exemplo de apl cliente-servidor: Input stream: sequence of Ì cliente lê linha da entrada bytes into process cria socket, porta=x, para padrão (fluxo doUsuário), Output stream: sequence of receber pedido: socketRecepção = envia para servidor via socket bytes out of process ServerSocket () (fluxo paraServidor) TCP cria socket, Ì servidor lê linha do socket aguarda chegada de setup da conexão abre conexão a idHosp, porta=x pedido de conexão socketCliente = Ì servidor converte linha para socketConexão = Socket() socketRecepção.accept() letra maiúscula, devolcve para o cliente Envia pedido usando lê pedido de socketCliente Ì cliente lê linha modificado do doUsuário socketConexão d socket (fluxo doServidor), p escreve resposta imprime-a para socketConexão lê resposta de socket do cliente fecha socketCliente socketConexão fecha socketCliente o p 2: Camada de Aplicação 57 2: Camada de Aplicação 58 a S r e Exemplo: cliente Java (TCP) Exemplo: cliente Java (TCP), cont. a r import java.io.*; import java.net.*; Cria BufferedReader doServidor = class ClienteTCP { fluxo de entrada new BufferedReader(new ligado ao socket InputStreamReader(socketCliente.getInputStream())); S public static void main(String argv[]) throws Exception { v frase = doUsuario.readLine(); String frase; Envia linha String fraseModificada; paraServidor.writeBytes(frase + 'n'); ao servidor Cria e fluxo de entrada BufferedReader doUsuario = Lê linha fraseModificada = doServidor.readLine(); new BufferedReader(new InputStreamReader(System.in)); do servidor Cria i System.out.println(”Do Servidor: " + fraseModificada); socket de cliente, Socket socketCliente = new Socket(”idHosp", 6789); conexão ao servidor socketCliente.close(); r Create DataOutputStream paraServidor = output stream new DataOutputStream(socketCliente.getOutputStream()); } attached to socket d } 2: Camada de Aplicação 59 2: Camada de Aplicação 60 v o i r d
  • 11. Exemplo: servidor Java (TCP) Exemplo: servidor Java (TCP), cont import java.io.*; import java.net.*; Cria fluxo class servidorTCP { de saída, ligado DataOutputStream paraCliente = ao socket new DataOutputStream(socketConexão.getOutputStream()); public static void main(String argv[]) throws Exception { Lê linha String fraseCliente; do socket fraseCliente= doCliente.readLine(); Cria socket StringfFraseMaiusculas; para recepção fraseEmMaiusculas= fraseCliente.toUpperCase() + 'n'; ServerSocket socketRecepcao = new ServerSocket(6789); na porta 6789 Escreve linha paraClient.writeBytes(fraseEmMaiusculas); Aguarda, no socket while(true) { ao socket } para recepção, o Socket socketConexao = socketRecepcao.accept(); } contato do cliente } Final do elo while, BufferedReader doCliente = volta ao início e aguarda Cria fluxo de new BufferedReader(new conexão de outro cliente entrada, ligado InputStreamReader(socketConexao.getInputStream())); ao socket 2: Camada de Aplicação 61 2: Camada de Aplicação 62 Programação com sockets usando UDP Interações cliente/servidor com socket: UDP Servidor (executa em idHosp) Cliente UDP: não tem “conexão” entre cliente e servidor cria socket, cria socket, Ì não tem “handshaking” porta=x, para socketCliente = pedido que chega: DatagramSocket() Ì remetente coloca ponto de vista da aplicação socketServidor = explicitamente endereço IP UDP provê transferência DatagramSocket() e porta do destino cria, endereça (idHosp, porta=x, não confiável de grupos envia pedido em datagrama Ì servidor deve extrair de bytes (“datagramas”) lê pedido do usando socketCliente endereço IP, porta do entre cliente e servidor socketServidor remetente do datagrama escreve resposa recebido ao socketServidor lê resposa do especificando endereço UDP: dados transmitidos IP, número de porta socketCliente podem ser recebidos fora do cliente fecha de ordem, ou perdidos socketCliente 2: Camada de Aplicação 63 2: Camada de Aplicação 64 Exemplo: cliente Java (UDP) Exemplo: cliente Java (UDP) cont. Cria datagrama com import java.io.*; dados para enviar, DatagramPacket pacoteEnviado = import java.net.*; comprimento, new DatagramPacket(dadosEnvio, dadosEnvio.length, endereço IP, porta IPAddress, 9876); class clienteUDP { public static void main(String args[]) throws Exception Envia datagrama socketCliente.send(pacoteEnviado); Cria { ao servidor DatagramPacket pacoteRecebido = fluxo de enrada BufferedReader do Usuario= new DatagramPacket(dadosRecebidos, dadosRecebidos.length); Cria new BufferedReader(new InputStreamReader(System.in)); Lê datagrama socket de cliente do servidor socketCliente.receive(pacoteRecebido); DatagramSocket socketCliente = new DatagramSocket(); Traduz nome de String fraseModificada = InetAddress IPAddress = InetAddress.getByName(”idHosp"); hospedeiro ao new String(pacoteRecebido.getData()); endereço IP byte[] dadosEnvio = new byte[1024]; System.out.println(”Do Servidor:" + fraseModificada); usando DNS byte[] dadosRecebidos = new byte[1024]; socketCliente.close(); } String frase = doUsuario.readLine(); } dadosEnvio = frase.getBytes(); 2: Camada de Aplicação 65 2: Camada de Aplicação 66
  • 12. Exemplo: servidor Java (UDP) Exemplo: servidor Java (UDP), cont String frase = new String(pacoteRecebido.getData()); import java.io.*; import java.net.*; Obtém endereço InetAddress IPAddress = pacoteRecebido.getAddress(); IP, no. de porta class servidorUDP { do remetente int port = pacoteRecebido.getPort(); public static void main(String args[]) throws Exception Cria socket { String fraseEmMaiusculas = frase.toUpperCase(); para datagramas DatagramSocket socketServidor = new DatagramSocket(9876); na porta 9876 dadosEnviados = fraseEmMaiusculas.getBytes(); byte[] dadosRecebidos = new byte[1024]; Cria datagrama p/ DatagramPacket pacoteEnviado = byte[] dadosEnviados = new byte[1024]; enviar ao cliente new DatagramPacket(dadosEnviados, dadosEnviados.length, IPAddress, porta); while(true) Escreve { datagrama socketServidor.send(pacoteEnviado); Aloca memória para DatagramPacket pacoteRecebido = ao socket } new DatagramPacket(dadosRecebidos, receber datagrama } dadosRecebidos.length); } Fim do elo while, Recebe socketServidor.receive(pacoteRecebido); volta ao início e aguarda datagrama chegar outro datagrama 2: Camada de Aplicação 67 2: Camada de Aplicação 68 Capítulo 2: Sumário Capítulo 2: Sumário Terminamos nosso estudo de aplicações de rede! Mais importante: aprendemos de protocolos Ì Requisitos do servi;co Ì Protocolos específicos: Ì troca típica de de aplicação: r http mensagens Ì msgs de controle X dados confiabilidade, banda, r na banda, fora da banda r r ftp pedido/resposta: retardo Ì centralizado X descentralizado r smtp, pop3 r cliente solicita info ou Ì paradigma cliente- r dns serviço Ì s/ estado X c/ estado servidor servidor responde com Ì transferência de msgs Ì programação c/ sockets r confiável X não confiável Ì modelo de serviço do dados, código de status r implementação Ì “complexidade na borda da transporte orientado a cliente/servidor Ì formatos de mensagens: rede” conexão, confiável da r usando sockets tcp, udp r cabeçalhos: campos com Ì segurança: autenticação Internet: TCP info sobre dados r não confiável, (metadados) datagramas: UDP r dados: info sendo 2: Camada de Aplicação 69 comunicada 2: Camada de Aplicação 70

×