1 Redes de Computadores 1 Prof. Marcelo Diniz Fonte: 2b: Camada de Aplicação.

1

Redes de Computadores 1

Prof. Marcelo DinizFonte: http://wps.aw.com/br_kurose_rede_1/

2b: Camada de Aplicação

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


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


DNS (cont.)

Serviços DNS Tradução de nome de

hospedeiro para IP Apelidos para

hospedeiros (aliasing) Nomes canônicos e

apelidos

Apelidos para servidores de e-mail

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!


Root DNS Servers

com DNS servers org DNS servers edu DNS servers

poly.eduDNS servers

umass.eduDNS servers

yahoo.comDNS servers

amazon.comDNS servers

pbs.orgDNS servers

Base de Dados Hierárquica e Distribuída

Cliente quer IP para www.amazon.com; 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 www.amazon.com


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

13 servidores de nome raiz em todo o mundo

a Verisign, Dulles, VAc Cogent, Herndon, VA (also Los Angeles)d U Maryland College Park, MDg US DoD Vienna, VAh ARL Aberdeen, MDj Verisign, ( 11 locations)

b USC-ISI Marina del Rey, CAl ICANN Los Angeles, CA

e NASA Mt View, CAf 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


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

Domínios Registrados por DPN(Domínio de Primeiro Nível)

28/09/09



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.


solicitantecis.poly.edu

gaia.cs.umass.edu

servidor raiz

servidor local dns.poly.edu

1

23

4

5

6

servidor oficialdns.cs.umass.edu

78

servidor TLD

Exemplo de resolução de nome pelo DNS 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”


consulta recursiva: transfere a

responsabilidade de resolução do nome para o servidor de nomes contatado

carga pesada?

Exemplo de resolução de nome pelo DNS

solicitantecis.poly.edu

gaia.cs.umass.edu

servidor DNS raiz

servidor DNS localdns.poly.edu

1

2

45

6

servidor DNS oficialdns.cs.umass.edu

7

8

servidor TLD

3


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 http://www.ietf.org/html.charters/dnsext-charter.html


Registros DNSDNS: BD distribuído contendo registros de recursos (RR)

Tipo=NS nome é domínio (p.ex.

foo.com.br) valor é endereço IP de

servidor oficial de nomes para este domínio

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=MX nome é domínio valor é nome do servidor

de correio para este domínio


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


DNS: protocolo e mensagens


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, 212.212.212.1, A)

Põe no servidor oficial um registro do tipo A para www.netutopia.com.br e um registro do tipo MX para netutopia.com.br

Como as pessoas vão obter o endereço IP do seu site?


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


Distribuição de Arquivo: C/S x P2PPergunta: Quanto tempo leva para distribuir

um arquivo de um servidor para N pares?

us

u2d1 d2u1

uN

dN

Servidor

Rede (combanda abundante)

Arquivo, tamanho F

us: banda de upload do servidor

ui: banda de upload do par i

di: banda de download do par i


Tempo de distribuição do arquivo: C/S

us

u2d1 d2u1

uN

dN

Servidor


F servidor envia

seqüencialmente N cópias: Tempo = NF/us

cliente i leva F/di

para o download

cresce linearmente com N(para grandes N)

= dcs = max { NF/us, F/min(di) }i

Tempo para distribuir F para N clientes usando

abordagem cliente/servidor


Tempo de distribuição do arquivo: P2P

servidor deve enviar uma cópia: F/us

cliente i leva F/di para o download

NF bits devem ser baixados (agregado)

taxa de upload mais rápida: us + ui

dP2P = max { F/us, F/min(di) , NF/(us + ui) }i

us

u2d1 d2u1

uN

dN

Servidor


F


0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Min

imu

m D

istr

ibut

ion

Tim

e P2P

Client-Server

Cliente/Servidor x P2P: exemplo

Taxa de upload do cliente= u, F/u = 1 hora, us = 10u, dmin ≥ us


Distribuição de arquivo: BitTorrent

tracker: registra pares Participantes de uma torrente

torrente: grupo de pares trocando

pedaços de um arquivo

obtém listados pares

troca depedaços

peer

Distribuição de arquivo P2P


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)

BitTorrent (2)

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

Enviando pedaços: toma lá, dá cá!

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”



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!

2: Application Layer 27

P2P: busca por informação

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.

Índice no sistema P2P: mapeia informação à localização de um par(localização = endereço IP & número de porta).


Compartilhamento de arquivos P2PExemplo 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.

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!


P2P: diretório centralizado

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

servidor de diretóriocentralizado

parceiros

Alice

Bob

1

1

1

12

3


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.


Inundação de consultas

Completamente distribuído Sem servidor central

Protocolo de domínio público

Vários clientes Gnutella implementam o protocolo

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


Inundação de consulta

Consulta

Item achado

Consulta

Consulta

Item achado

Consulta

Consulta

Item ach

ado

Transferência arq:HTTP

Mensagem de consulta enviada pelas conexões TCP existentes Pares repassem mensagem de consulta Resposta sobre item encontrado enviada pelo caminho reverso

Escalabilidade:Inundação com escopo limitado


Gnutella: junção do Par

1. Um par X se juntando deve encontrar algum outro par na rede Gnutella: usa lista de pares candidatos

2. X tenta criar conexões TCP com os pares na lista seqüencialmente até estabelecer conexão com Y

3. X envia mensagem Ping para Y; Y repassa a mensagem Ping

4. Todos os pares recebendo a mensagem Ping respondem com uma mensagem Pong

5. X recebe várias mensagens Pong. Ele pode então estabelecer conexões TCP adicionais

Saída do par: veja problema no livro texto!


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

ordinary peer

group-leader peer

neighoring re la tionshipsin overlay network


Estudo de caso P2P: Skype

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 clients (SC)

Supernode (SN)

Skype login server


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


Programação com sockets

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

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

Meta: aprender a construir aplicações cliente/servidor que se comunicam usando sockets


Programação com sockets usando TCPSocket: 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

processo

TCP combuffers,

variáveis

socket

controlado pelodesenvolvedor de

aplicação

controladopelo sistemaoperacional

estação ouservidor

processo

TCP combuffers,

variáveis

socket

controlado pelodesenvolvedor deaplicação

controladopelo sistemaoperacional

estação ouservidor

internet


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)

TCP provê transferência confiável, ordenada de bytes

(“tubo”) entre cliente e servidor

ponto de vista da aplicação

Programação com sockets usando TCP


Comunicação entre sockets


Programação com sockets usando UDPUDP: 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


Interações cliente/servidor usando o UDP

fechasocketCliente

Servidor (executa em nomeHosp)

lê resposta dosocketCliente

cria socket,socketCliente = DatagramSocket()

Cliente

cria, endereça (nomeHosp, porta=x,envia pedido em datagramausando socketCliente

cria socket,porta=x, parapedido que chega:socketServidor = DatagramSocket()

lê pedido dosocketServidor

escreve resposta ao socketServidorespecificando endereçoIP, número de porta do cliente


Exemplo: Cliente Java (UDP)

UDP


Servidor UDP


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.

1 Redes de Computadores 1 Prof. Marcelo Diniz Fonte: 2b: Camada de Aplicação.

Documents

Transcript of 1 Redes de Computadores 1 Prof. Marcelo Diniz Fonte: 2b: Camada de Aplicação.