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

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

Prof. Marcelo Diniz Fonte:

Apresentações semelhantes


Apresentação em tema: "Prof. Marcelo Diniz Fonte:"— Transcrição da apresentação:

1 Prof. Marcelo Diniz Fonte: http://wps.aw.com/br_kurose_rede_1/
Redes de Computadores 1 Prof. Marcelo Diniz Fonte: 2b: Camada de Aplicação

2 Capítulo 2: Roteiro 2.1 Princípios de aplicações de rede
2.2 A Web e o HTTP 2.3 Transferência de arquivo: FTP 2.4 Correio Eletrônico na Internet 2.5 DNS: o serviço de diretório da Internet 2.6 Aplicações P2P 2.7 Programação de sockets com TCP 2.8 Programação de sockets com UDP 2.9 Construindo um servidor Web simples 2b: Camada de Aplicação

3 DNS: Domain Name System
Pessoas: muitos identificadores: CPF, nome, no. da Identidade hospedeiros, roteadores Internet : endereço IP (32 bit) - usado p/ endereçar datagramas “nome”, ex., jambo.ic.uff.br - usado por gente P: como mapear entre nome e endereço IP? Domain Name System: base de dados distribuída implementada na hierarquia de muitos servidores de nomes protocolo de camada de aplicação permite que hospedeiros, roteadores, servidores de nomes se comuniquem para resolver nomes (tradução endereço/nome) nota: função imprescindível da Internet implementada como protocolo de camada de aplicação complexidade na borda da rede 2b: Camada de Aplicação

4 DNS (cont.) Serviços DNS Por que não centralizar o DNS?
Tradução de nome de hospedeiro para IP Apelidos para hospedeiros (aliasing) Nomes canônicos e apelidos Apelidos para servidores de Distribuição de carga Servidores Web replicados: conjunto de endereços IP para um nome canônico Por que não centralizar o DNS? ponto único de falha volume de tráfego base de dados centralizada e distante manutenção (da BD) Não é escalável! 2b: Camada de Aplicação

5 Base de Dados Hierárquica e Distribuída
Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu yahoo.com amazon.com pbs.org Cliente quer IP para 1a aprox: Cliente consulta um servidor raiz para encontrar um servidor DNS .com Cliente consulta servidor DNS .com para obter o servidor DNS para o domínio amazon.com Cliente consulta servidor DNS do domínio amazon.com para obter endereço IP de 2b: Camada de Aplicação

6 DNS: Servidores raiz procurado por servidor local que não consegue resolver o nome servidor raiz: procura servidor oficial se mapeamento desconhecido obtém tradução devolve mapeamento ao servidor local a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) i Autonomica, Stockholm (plus 3 other locations) k RIPE London (also Amsterdam, Frankfurt) m WIDE Tokyo 13 servidores de nome raiz em todo o mundo 2b: Camada de Aplicação

7 Servidores TLD e Oficiais
Servidores Top-level domain (TLD) : servidores DNS responsáveis por domínios com, org, net, edu, etc, e todos os domínios de países como br, uk, fr, ca, jp. Network Solutions mantém servidores para domínio .com NIC.br (Registro .br) para domínio .br Servidores oficiais: servidores DNS das organizações, provendo mapeamentos oficiais entre nomes de hospedeiros e endereços IP para os servidores da organização (e.x., Web e correio). Podem ser mantidos pelas organizações ou pelo provedor de acesso 2b: Camada de Aplicação

8 Domínios Registrados por DPN (Domínio de Primeiro Nível) 28/09/09
2b: Camada de Aplicação

9 Servidor de Nomes Local
Não pertence necessariamente à hierarquia Cada ISP (ISP residencial, companhia, universidade) possui um. Também chamada do “servidor de nomes default” Quanto um hospedeiro faz uma consulta DNS, a mesma é enviada para o seu servidor DNS local Atua como um intermediário, enviando consultas para a hierarquia. 2b: Camada de Aplicação

10 Exemplo de resolução de nome pelo DNS
servidor raiz 2 Hospedeiro em cis.poly.edu quer endereço IP para gaia.cs.umass.edu consulta interativa: servidor consultado responde com o nome de um servidor de contato “Não conheço este nome, mas pergunte para esse servidor” 3 servidor TLD 4 5 servidor local dns.poly.edu 7 6 1 8 servidor oficial dns.cs.umass.edu solicitante cis.poly.edu gaia.cs.umass.edu 2b: Camada de Aplicação

11 Exemplo de resolução de nome pelo DNS
solicitante cis.poly.edu gaia.cs.umass.edu servidor DNS raiz servidor DNS local dns.poly.edu 1 2 4 5 6 servidor DNS oficial dns.cs.umass.edu 7 8 servidor TLD 3 consulta recursiva: transfere a responsabilidade de resolução do nome para o servidor de nomes contatado carga pesada? 2b: Camada de Aplicação

12 DNS: uso de cache, atualização de dados
uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cache local entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo) Servidores TLD tipicamente armazenados no cache dos servidores de nomes locais Servidores raiz acabam não sendo visitados com muita freqüência estão sendo projetados pela IETF mecanismos de atualização/notificação dos dados RFCs 2136, 3007, 4033/4/5 2b: Camada de Aplicação

13 formato RR: (nome, valor, tipo, sobrevida)
Registros DNS DNS: BD distribuído contendo registros de recursos (RR) formato RR: (nome, valor, tipo, sobrevida) Tipo=A nome é nome de hospedeiro valor é o seu endereço IP Tipo=CNAME nome é nome alternativo (alias) para algum nome “canônico” (verdadeiro) valor é o nome canônico Tipo=NS nome é domínio (p.ex. foo.com.br) valor é endereço IP de servidor oficial de nomes para este domínio Tipo=MX nome é domínio valor é nome do servidor de correio para este domínio 2b: Camada de Aplicação

14 DNS: protocolo e mensagens
protocolo DNS: mensagens de pedido e resposta, ambas com o mesmo formato de mensagem cabeçalho de msg identificação: ID de 16 bit para pedido, resposta ao pedido usa mesmo ID flags: pedido ou resposta recursão desejada recursão permitida resposta é oficial 2b: Camada de Aplicação

15 DNS: protocolo e mensagens
2b: Camada de Aplicação

16 Inserindo registros no DNS
Exemplo: acabou de criar a empresa “Network Utopia” Registra o nome netutopia.com.br em uma entidade registradora (e.x., Registro.br) Tem de prover para a registradora os nomes e endereços IP dos servidores DNS oficiais (primário e secundário) Registradora insere dois RRs no servidor TLD .br: (netutopia.com.br, dns1.netutopia.com.br, NS) (dns1.netutopia.com.br, , A) Põe no servidor oficial um registro do tipo A para e um registro do tipo MX para netutopia.com.br Como as pessoas vão obter o endereço IP do seu site? 2b: Camada de Aplicação

17 Capítulo 2: Roteiro 2.1 Princípios de aplicações de rede
2.2 A Web e o HTTP 2.3 Transferência de arquivo: FTP 2.4 Correio Eletrônico na Internet 2.5 DNS: o serviço de diretório da Internet 2.6 Aplicações P2P 2.7 Programação de sockets com TCP 2.8 Programação de sockets com UDP 2.9 Construindo um servidor Web simples 2b: Camada de Aplicação

18 Arquitetura P2P pura sem servidor sempre ligado
sistemas finais arbitrários se comunicam diretamente pares estão conectados de forma intermitente e mudam seus endereços IP Três tópicos: Distribuição de arquivos Busca de informações Estudo de caso: Skype par-par 2b: Camada de Aplicação

19 Distribuição de Arquivo: C/S x P2P
Pergunta: Quanto tempo leva para distribuir um arquivo de um servidor para N pares? us: banda de upload do servidor Servidor ui: banda de upload do par i u1 d1 u2 d2 us di: banda de download do par i Arquivo, tamanho F dN Rede (com banda abundante) uN 2b: Camada de Aplicação

20 Tempo de distribuição do arquivo: C/S
Servidor servidor envia seqüencialmente N cópias: Tempo = NF/us cliente i leva F/di para o download F u2 u1 d1 d2 us Rede (com banda abundante) dN uN = dcs = max { NF/us, F/min(di) } i Tempo para distribuir F para N clientes usando abordagem cliente/servidor cresce linearmente com N (para grandes N) 2b: Camada de Aplicação

21 Tempo de distribuição do arquivo: P2P
Servidor servidor deve enviar uma cópia: F/us cliente i leva F/di para o download NF bits devem ser baixados (agregado) F u2 u1 d1 d2 us Rede (com banda abundante) dN uN taxa de upload mais rápida: us + Sui dP2P = max { F/us, F/min(di) , NF/(us + Sui) } i 2b: Camada de Aplicação

22 Cliente/Servidor x P2P: exemplo
Taxa de upload do cliente= u, F/u = 1 hora, us = 10u, dmin ≥ us 2b: Camada de Aplicação

23 Distribuição de arquivo: BitTorrent
Distribuição de arquivo P2P tracker: registra pares Participantes de uma torrente torrente: grupo de pares trocando pedaços de um arquivo obtém lista dos pares troca de pedaços peer 2b: Camada de Aplicação

24 BitTorrent (1) arquivo dividido em pedaços de 256KB.
par que se une à torrente: não tem nenhum pedaço, mas irá acumulá-los com o tempo registra com o tracker para obter lista dos pares, conecta a um subconjunto de pares (“vizinhos”) enquanto faz o download, par carrega pedaços para outros pares Pares podem entrar e sair quando o par obtém todo o arquivo, ele pode (egoisticamente) sair ou permanecer (altruisticamente) 2b: Camada de Aplicação

25 BitTorrent (2) Enviando pedaços: toma lá, dá cá! Obtendo Pedaços
Alice envia pedaços para quatro vizinhos que estejam lhe enviando pedaços na taxa mais elevada Reavalia os 4 mais a cada 10 segs a cada 30 segs: seleciona aleatoriamente outro par, começa a enviar pedaços o par recém escolhido pode se unir aos 4 mais “optimistically unchoke” Obtendo Pedaços num determinado instante, pares distintos possuem diferentes subconjuntos dos pedaços do arquivo periodicamente, um par (Alice) pede a cada vizinho a lista de pedaços que eles possuem Alice envia pedidos para os pedaços que ainda não tem Primeiro os mais raros 2b: Camada de Aplicação

26 BitTorrent: toma lá, dá cá!
(1) Alice “optimistically unchokes” Bob (2) Alice se torna um dos quatro melhores provedores de Bob; Bob age da mesma forma (3) Bob se torna um dos quatro melhores provedores de Alice Com uma taxa de upload mais alta, pode encontrar melhores parceiros de troca e obter o arquivo mais rapidamente! 2b: Camada de Aplicação

27 P2P: busca por informação
Índice no sistema P2P: mapeia informação à localização de um par (localização = endereço IP & número de porta). Compartilhamento de arquivos (ex: e-mule) O índice registra dinamicamente as localizações dos arquivos compartilhados pelos pares Pares devem informar ao índice os conteúdos que possuem Pares buscam no índice para descobrir onde pode encontrar os arquivos. Mensagens instantâneas O índice mapeia os nomes de usuários a locais. Quando o usuário inicia uma aplicação de MI, ele deve informar ao índice qual é a sua localização atual. Pares buscam no índice o endereço IP de um contato. Faltou incluir DHT da 5th Edition. 2: Application Layer

28 Compartilhamento de arquivos P2P
Alice escolhe um dos parceiros, Bob. O arquivo é copiado do PC de Bob para o notebook de Alice: HTTP Enquanto Alice está baixando a música, outros usuários podem estar pegando arquivos do seu computador. O parceiro de Alice é tanto um cliente Web como um servidor Web temporário. Todos os parceiros são servidores = altamente escalável! Exemplo Alice executa aplicação cliente P2P no seu notebook Periodicamente ela se conecta à Internet e recebe um novo endereço IP a cada conexão Pede a música “Hey Jude” A aplicação apresenta uma lista de outros parceiros que possuem uma cópia de Hey Jude. 2b: Camada de Aplicação

29 P2P: diretório centralizado
servidor de diretório centralizado parceiros Alice Bob 1 2 3 Projeto original do Napster 1) Quando um parceiro conecta ele informa ao servidor central o seu: endereço IP conteúdo 2) Alice consulta sobre a música “Hey Jude” 3) Alice solicita o arquivo a Bob 2b: Camada de Aplicação

30 P2P: problemas com diretório centralizado
Ponto único de falha Gargalo de desempenho Violação de Direitos Autorais a transferência de arquivo é descentralizada, mas a localização do conteúdo é altamente centralizada. 2b: Camada de Aplicação

31 Inundação de consultas
Rede sobreposta: grafo Aresta entre pares X e Y se existe uma conexão TCP Todos os pares ativos e arestas formam a rede de sobreposição Aresta não é um enlace físico Um par vai estar conectado tipicamente com < 10 vizinhos na rede de sobreposição Completamente distribuído Sem servidor central Protocolo de domínio público Vários clientes Gnutella implementam o protocolo 2b: Camada de Aplicação

32 Inundação de consulta Escalabilidade: Inundação com escopo limitado
Mensagem de consulta enviada pelas conexões TCP existentes Pares repassem mensagem de consulta Resposta sobre item encontrado enviada pelo caminho reverso Transferência arq: HTTP Consulta Item achado Consulta Consulta Item achado Consulta Item achado Escalabilidade: Inundação com escopo limitado Consulta 2b: Camada de Aplicação

33 Gnutella: junção do Par
Um par X se juntando deve encontrar algum outro par na rede Gnutella: usa lista de pares candidatos X tenta criar conexões TCP com os pares na lista seqüencialmente até estabelecer conexão com Y X envia mensagem Ping para Y; Y repassa a mensagem Ping Todos os pares recebendo a mensagem Ping respondem com uma mensagem Pong X recebe várias mensagens Pong. Ele pode então estabelecer conexões TCP adicionais Saída do par: veja problema no livro texto! 2b: Camada de Aplicação

34 Overlay Hierárquico Cada parceiro é um líder de grupo ou está alocado a um líder de grupo Conexão TCP entre cada par e o seu líder de grupo Conexões TCP entre alguns pares de líderes de grupos O líder de um grupo mantém registro sobre o conteúdo de todos os seus filhos 2b: Camada de Aplicação

35 Estudo de caso P2P: Skype
Skype clients (SC) inerentemente P2P: comunicação entre pares de usuários. protocolo proprietário da camada de aplicação (inferido através de engenharia reversa) overlay hierárquico com SNs Índice mapeia nomes dos usuários a endereços IP; distribuído através dos SNs Skype login server Supernode (SN) 2: Application Layer

36 Pares como intermediários (relays)
Problema quando tanto Alice como Bob estão atrás de “NATs”. O NAT impede que um par externo inicie uma chamada com um par interno Solução: Intermediário é escolhido, usando os SNs de Alice e de Bob. Cada par inicia sessão com o intermediário Pares podem se comunicar através de NATs através do intermediário 2: Application Layer

37 Capítulo 2: Roteiro 2.1 Princípios de aplicações de rede
2.2 A Web e o HTTP 2.3 Transferência de arquivo: FTP 2.4 Correio Eletrônico na Internet 2.5 DNS: o serviço de diretório da Internet 2.6 Aplicações P2P 2.7 Programação de sockets com TCP 2.8 Programação de sockets com UDP 2.9 Construindo um servidor Web simples 2b: Camada de Aplicação

38 Programação com sockets
Meta: aprender a construir aplicações cliente/servidor que se comunicam usando sockets uma interface (uma “porta”), local ao hospedeiro, criada por e pertencente à aplicação, e controlado pelo SO, através da qual um processo de aplicação pode tanto enviar como receber mensagens para/de outro processo de aplicação (remoto ou local) socket API Sockets apareceu no BSD4.1 UNIX em 1981 são explicitamente criados, usados e liberados por apls paradigma cliente/servidor dois tipos de serviço de transporte via API Sockets datagrama não confiável fluxo de bytes, confiável 2b: Camada de Aplicação

39 Programação com sockets usando TCP
Socket: uma porta entre o processo de aplicação e um 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 desenvolvedor de aplicação controlado pelo desenvolvedor de aplicação processo TCP com buffers, variáveis socket processo TCP com buffers, variáveis socket controlado pelo sistema operacional controlado pelo sistema operacional internet estação ou servidor estação ou servidor 2b: Camada de Aplicação

40 Programação com sockets usando TCP
Cliente deve contactar servidor processo servidor deve antes estar em execução servidor deve antes ter criado socket (porta) que aguarda contato do cliente Cliente contacta servidor para: criar socket TCP local ao cliente especificar endereço IP, número de porta do processo servidor Quando cliente cria socket: TCP cliente cria conexão com TCP do servidor Quando contatado pelo cliente, o TCP do servidor cria socket novo para que o processo servidor possa se comunicar com o cliente permite que o servidor converse com múltiplos clientes Endereço IP e porta origem são usados para distinguir os clientes (mais no cap. 3) ponto de vista da aplicação TCP provê transferência confiável, ordenada de bytes (“tubo”) entre cliente e servidor 2b: Camada de Aplicação

41 Comunicação entre sockets
2b: Camada de Aplicação

42 Capítulo 2: Roteiro 2.1 Princípios de aplicações de rede
2.2 A Web e o HTTP 2.3 Transferência de arquivo: FTP 2.4 Correio Eletrônico na Internet 2.5 DNS: o serviço de diretório da Internet 2.6 Aplicações P2P 2.7 Programação de sockets com TCP 2.8 Programação de sockets com UDP 2.9 Construindo um servidor Web simples 2b: Camada de Aplicação

43 Programação com sockets usando UDP
UDP: não tem “conexão” entre cliente e servidor não tem “handshaking” remetente coloca explicitamente endereço IP e porta do destino servidor deve extrair endereço IP, porta do remetente do datagrama recebido UDP: dados transmitidos podem ser recebidos fora de ordem, ou perdidos UDP provê transferência não confiável de grupos de bytes (“datagramas”) entre cliente e servidor ponto de vista da aplicação 2b: Camada de Aplicação

44 Interações cliente/servidor usando o UDP
Servidor (executa em nomeHosp) cria socket, socketCliente = DatagramSocket() Cliente cria, endereça (nomeHosp, porta=x, envia pedido em datagrama usando socketCliente cria socket, porta=x, para pedido que chega: socketServidor = DatagramSocket() lê pedido do socketServidor fecha socketCliente lê resposta do socketCliente escreve resposta ao socketServidor especificando endereço IP, número de porta do cliente 2b: Camada de Aplicação

45 Exemplo: Cliente Java (UDP)
2b: Camada de Aplicação

46 Servidor UDP 2b: Camada de Aplicação

47 Capítulo 2: Roteiro 2.1 Princípios de aplicações de rede
2.2 A Web e o HTTP 2.3 Transferência de arquivo: FTP 2.4 Correio Eletrônico na Internet 2.5 DNS: o serviço de diretório da Internet 2.6 Aplicações P2P 2.7 Programação de sockets com TCP 2.8 Programação de sockets com UDP 2.9 Construindo um servidor Web simples 2b: Camada de Aplicação

48 Servidor Web Simples Funções do servidor Web:
Trata apenas um pedido HTTP por vez Aceita e examina o pedido HTTP Recupera o arquivo pedido do sistema de arquivos do servidor Cria uma mensagem de resposta HTTP consistindo do arquivo solicitado precedido por linhas de cabeçalho Envia a resposta diretamente ao cliente. 2b: Camada de Aplicação


Carregar ppt "Prof. Marcelo Diniz Fonte:"

Apresentações semelhantes


Anúncios Google