2a: Camada de Aplicação 1
Capítulo 2: Camada de AplicaçãoMetas do capítulo: aspectos conceituais e
de implementação de protocolos de aplicação em redes modelos de serviço da
camada de transporte paradigma cliente
servidor paradigma peer-to-
peer
aprenda sobre protocolos através do estudo de protocolos populares da camada de aplicação
Mais metas do capítulo protocolos específicos:
HTTP FTP SMTP/ POP3/ IMAP DNS
a programação de aplicações de rede programação usando a
API de sockets
2a: Camada de Aplicação 2
Roteiro do Capítulo 2
2.1 Princípios dos protocolos da camada de aplicação clientes e servidores requisitos das
aplicações
2.2 Web e HTTP 2.3 FTP 2.4 Correio
Eletrônico SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de Sockets com TCP
2.7 Programação de Sockets com UDP
2.8 Construindo um servidor Web
2.9 Distribuição de conteúdo Cache Web na rede Redes de distribuição
de conteúdo Compartilhamento de
arquivos P2P
2a: Camada de Aplicação 3
Aplicações de rede: algum jargão
Um processo é um programa que executa num hospedeiro.
2 processos no mesmo hospedeiro se comunicam usando comunicação entre processos definida pelo sistema operacional (SO).
2 processos em hospedeiros distintos se comunicam usando um protocolo da camada de aplicação.
Um agente de usuário (UA) é uma interface entre o usuário “acima” e a rede “abaixo”. Implementa o protocolo
da camada de aplicação WWW: browser Correio:
leitor/compositor de mensagens
streaming de áudio/vídeo: tocador de mídia
2a: Camada de Aplicação 4
Aplicações e protocolos da camada de aplicação
Aplicação: processos distribuídos em comunicação p.ex., correio, Web,
compartilhamento de arquivos P2P, mensagens instantâneas
executam em hospedeiros no “espaço de usuário”
trocam mensagens para implementar a aplicação
Protocolos da camada de aplicação uma “parte” da aplicação define mensagens trocadas
por apls e ações tomadas usam serviços providos por
protocolos da camada inferior (TCP, UDP)
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
2a: Camada de Aplicação 5
Os protocolos da camada de aplicação definem Tipos de mensagens
trocadas, ex. mensagens de pedido e resposta
Sintaxe dos tipos das mensagens: campos presentes nas mensagens e como são identificados
Semântica dos campos, i.e., significado da informação nos campos
Regras para quando os processos enviam e respondem às mensagens
Protocolos de domínio público:
definidos em RFCs Permitem a
interoperação ex, HTTP e SMTPProtocolos
proprietários: Ex., KaZaA
2a: Camada de Aplicação 6
Paradigma cliente-servidor (C-S)
Apl. de rede típica tem duas partes: cliente e servidor
aplicaçãotransport
erede
enlacefísica
aplicaçãotransporte
redeenlacefísica
Cliente: inicia contato com o servidor
(“fala primeiro”) tipicamente solicita serviço do
servidor para WWW, cliente
implementado no browser; para correio no leitor de mensagens
Servidor: provê ao cliente o serviço
requisitado p.ex., servidor WWW envia
página solicitada; servidor de correio entrega mensagens
pedido
resposta
2a: Camada de Aplicação 7
Comunicação entre processos através da rede
Os processos enviam/ recebem mensagens para/ dos seus sockets
Um socket é análogo a uma porta Processo transmissor envia a
mensagem através da porta O processo transmissor
assume a existência da infra-estrutura de transporte no outro lado da porta que faz com que a mensagem chegue ao socket do processo receptor
processo
TCP combuffers,variáveis
socket
host ouservidor
processo
TCP combuffers,variáveis
socket
host ouservidor
Internet
controladopelo SO
controlado pelodesenvolvedor daaplicação
API: (1) escolha do protocolo de transporte; (2) habilidade para fixar alguns parâmetros (mais sobre isto posteriormente)
2a: Camada de Aplicação 8
Endereçando os processos: Para que um processo
receba mensagens ele deve possuir um identificador
Cada host possui um endereço IP único de 32 bits
P: o endereço IP do host no qual o processo está sendo executado é suficiente para identificar o processo?
Resposta: Não, muitos processos podem estar executando no mesmo host
O identificador inclui tanto o endereço IP quanto os números das portas associadas com o processo no host.
Exemplo de números de portas: Servidor HTTP: 80 Servidor de Correio: 25
Mais sobre isto posteriormente.
2a: Camada de Aplicação 9
De que serviço de transporte uma aplicação precisa?Perda de dados algumas apls (p.ex. áudio)
podem tolerar algumas perdas
outras (p.ex., transf. de 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 de banda algumas apls (p.ex.,
multimídia) requerem quantia mínima de banda para serem “viáveis”
outras apls (“apls elásticas”) conseguem usar qq quantia de banda disponível
2a: Camada de Aplicação 10
Requisitos do serviço de transporte de apls comuns
Aplicação
transferência de arqscorreio
documentos WWWáudio/vídeo de
tempo realáudio/vídeo gravado
jogos interativosapls financeiras
Perdas
sem perdassem perdassem perdastolerante
tolerantetolerantesem perdas
Banda
elásticaelásticaelásticaáudio: 5Kb-1Mbvídeo:10Kb-5Mbcomo anterior> alguns Kbpselástica
Sensibilidade temporal
nãonãonãosim, 100’s mseg
sim, alguns segssim, 100’s msegsim e não
2a: Camada de Aplicação 11
Serviços providos por protocolos de transporte Internet
Serviço TCP: orientado a conexão:
inicialização requerida entre cliente e servidor
transporte confiável entre processos remetente e receptor
controle de fluxo: remetente não vai “afogar” receptor
controle de congestionamento: estrangular remetente quando a rede estiver carregada
não provê: garantias temporais ou de banda mínima
Serviço UDP: transferência de dados não
confiável entre processos remetente e receptor
não provê: estabelecimento da conexão, confiabilidade, controle de fluxo, controle de congestionamento, garantias temporais ou de banda mínima
P: Qual é o interesse em ter um UDP?
2a: Camada de Aplicação 12
Apls Internet: seus protocolos e seus protocolos de transporte
Aplicação
correio eletrônicoaccesso terminal remoto
WWW transferência de arquivos
streaming multimídia
servidor de arquivo remototelefonia Internet
Protocolo da camada de apl
SMTP [RFC 2821]telnet [RFC 854]HTTP [RFC 2616]ftp [RFC 959]proprietário(p.ex. RealNetworks)NSFproprietário(p.ex., Dialpad)
Protocolo de transporte usado
TCPTCPTCPTCPTCP ou UDP
TCP ou UDPtipicamente UDP
2a: Camada de Aplicação 13
Roteiro do Capítulo 2
2.1 Princípios dos protocolos da camada de aplicação clientes e servidores requisitos das
aplicações
2.2 Web e HTTP 2.3 FTP 2.4 Correio
Eletrônico SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de Sockets com TCP
2.7 Programação de Sockets com UDP
2.8 Construindo um servidor Web
2.9 Distribuição de conteúdo Cache Web na rede Redes de distribuição
de conteúdo Compartilhamento de
arquivos P2P
2a: Camada de Aplicação 14
WWW: algum jargão
Página WWW: consiste de “objetos” endereçada por uma URL
Quase todas as páginas WWW consistem de: página base HTML, e vários objetos
referenciados.
URL tem duas partes: nome de hospedeiro, e nome de caminho:
Agente de usuário para WWW se chama de browser: MS Internet Explorer Netscape
Communicator
Servidor para WWW se chama “servidor WWW”: Apache (domínio
público) MS Internet Information
Server (IIS)www.univ.br/algum-depto/pic.gif
2a: Camada de Aplicação 15
WWW: o protocolo HTTP
HTTP: hypertext transfer protocol
protocolo da camada de aplicação para WWW
modelo cliente/servidor cliente: browser que
pede, recebe, “visualiza” objetos WWW
servidor: servidor WWW envia objetos em resposta a pedidos
http1.0: RFC 1945 http1.1: RFC 2068
PC executaExplorer
Servidor executando
servidor WWW
do NCSA
Mac executaNavigator
pedido http
pedido http
resposta http
resposta http
2a: Camada de Aplicação 16
Mais sobre o protocolo HTTP
Usa serviço de transporte TCP:
cliente inicia conexão TCP (cria socket) ao servidor, porta 80
servidor aceita conexão TCP do cliente
mensagens HTTP (mensagens do protocolo da camada de apl) trocadas entre browser (cliente HTTP) e servidor Web (servidor HTTP)
encerra conexão TCP
HTTP é “sem estado” servidor não mantém
informação sobre pedidos anteriores do cliente
Protocolos que mantêm “estado” são complexos!
história passada (estado) tem que ser guardada
Caso caia servidor/cliente, suas visões do “estado” podem ser inconsistentes, devem ser reconciliadas
Nota
2a: Camada de Aplicação 17
Conexões HTTP
HTTP não persistente No máximo um
objeto é enviado numa conexão TCP.
HTTP/1.0 usa o HTTP não persistente
HTTP persistente Múltiplos objetos
podem ser enviados sobre uma única conexão TCP entre cliente e servidor.
HTTP/1.1 usa conexões persistentes no seu modo default
2a: Camada de Aplicação 18
Exemplo de HTTP não persistenteSupomos que usuário digita a URL www.algumaUniv.br/algumDepartmento/inicial.index
1a. Cliente http inicia conexão TCP a servidor http (processo) a www.algumaUniv.br. Porta 80 é padrão para servidor http.
2. cliente http envia mensagem de pedido de http (contendo URL) através do socket da conexão TCP
1b. servidor http no hospedeiro www.algumaUniv.br espera por conexão TCP na porta 80. “aceita” conexão, avisando ao cliente
3. servidor http recebe mensagem de pedido, formula mensagem de resposta contendo objeto solicitado (algumDepartmento/inicial.index), envia mensagem via socket
tempo
(contém texto, referências a 10
imagens jpeg)
2a: Camada de Aplicação 19
Exemplo de HTTP não persistente (cont.)
5. cliente http recebe mensagem de 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. servidor http encerra conexão TCP .
tempo
2a: Camada de Aplicação 20
Modelagem do tempo de respostaDefinição de RTT (Round Trip
Time): intervalo de tempo entre a ida e a volta de um pequeno pacote entre um cliente e um servidor.
Tempo de resposta: um RTT para iniciar a
conexão TCP um RTT para o pedido HTTP
e o retorno dos primeiros bytes da resposta HTTP
tempo de transmissão do arquivo
total = 2RTT+tempo de transmissão
tempo para transmitir o arquivo
Inicia a conexãoTCP
RTT
solicitaarquivo
RTT
arquivorecebido
tempo tempo
2a: Camada de Aplicação 21
HTTP persistente
Problemas com o HTTP não persistente:
requer 2 RTTs para cada objeto
SO aloca recursos do host para cada conexão TCP
os browsers freqüentemente abrem conexões TCP paralelas para recuperar os objetos referenciados
HTTP persistente o servidor deixa a conexão
aberta após enviar a resposta mensagens HTTP seguintes
entre o mesmo cliente/servidor são enviadas nesta conexão
Persistente sem pipelining: o cliente envia um novo
pedido apenas quando a resposta anterior tiver sido recebida
um RTT para cada objeto referenciado
Persistente com pipelining: default no HTTP/1.1 o cliente envia os pedidos
logo que encontra um objeto referenciado
pode ser necessário apenas um RTT para todos os objetos referenciados
2a: Camada de Aplicação 22
mensagem de pedido HTTP: formato geral
2a: Camada de Aplicação 23
Formulários e interação bidirecional
Formulários transmitem informação do cliente ao servidor
HTTP permite enviar formulários ao servidor
Resposta enviada como página HTML dinâmica
Formulários processados usando scripts CGI (programas que executam no servidor WWW) CGI - Common Gateway
Interface scripts CGI escondem
acesso a diferentes serviços
servidor WWW atua como gateway universal
clienteWWW
servidorWWW
Sistema deinformação
GET/POST formulário
resposta:
HTML
2a: Camada de Aplicação 28
HTML (HyperText Markup Language)
HTML: uma linguagem simples para hipertexto começou como versão simples de SGML construção básica: cadeias de texto anotadas
Construtores de formato operam sobre cadeias <b> .. </b> bold (negrito) <H1 ALIGN=CENTER> ..título centrado .. </H1> <BODY bgcolor=white text=black link=red ..> ..
</BODY>
vários formatos listas de bullets, listas ordenadas, listas de definição tabelas frames
2a: Camada de Aplicação 29
Cookies: manutenção do “estado”Muitos dos principais sítios
Web usam cookiesQuatro componentes:
1) linha de cabeçalho do cookie na mensagem de resposta HTTP
2) linha de cabeçalho do cookie na mensagem de pedido HTTP
3) arquivo do cookie mantido no host do usuário e gerenciado pelo browser do usuário
4) BD de retaguarda no sítio Web
Exemplo: Suzana acessa a
Internet sempre do mesmo PC
Ela visita um sítio específico de comércio eletrônico pela primeira vez
Quando os pedidos iniciais HTTP chegam no sítio, o sítio cria uma ID única e cria uma entrada para a ID no BD de retaguarda
2a: Camada de Aplicação 30
Cookies (continuação)
O que os cookies podem obter:
autorização carrinhos de compra sugestões estado da sessão do
usuário (Webmail)
Cookies e privacidade: cookies permitem que os
sítios aprendam muito sobre você
você pode fornecer nome e e-mail para os sítios
mecanismos de busca usam redirecionamen-to e cookies para aprender ainda mais
companhias de propaganda obtêm infos a partir dos sítios
nota
2a: Camada de Aplicação 31
Roteiro do Capítulo 2
2.1 Princípios dos protocolos da camada de aplicação clientes e servidores requisitos das
aplicações
2.2 Web e HTTP 2.3 FTP 2.4 Correio
Eletrônico SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de Sockets com TCP
2.7 Programação de Sockets com UDP
2.8 Construindo um servidor Web
2.9 Distribuição de conteúdo Cache Web na rede Redes de distribuição
de conteúdo Compartilhamento de
arquivos P2P
2a: Camada de Aplicação 32
ftp: o protocolo de transferência de arquivos
transferir arquivo de/para hospedeiro remoto modelo cliente/servidor
cliente: lado que inicia transferência (pode ser de ou para o sistema remoto)
servidor: hospedeiro remoto ftp: RFC 959 servidor ftp: porta 21
transferênciado arquivo FTP
servidor
Interface do
usuário FTP
cliente FTP
sistema de arquivos local
sistema de arquivos remoto
usuário na
estação
2a: Camada de Aplicação 33
FTP: conexões separadas p/ controle, dados cliente FTP contata servidor
FTP na porta 21, especificando o TCP como protocolo de transporte
O cliente obtém autorização através da conexão de controle
O cliente consulta o diretório remoto enviando comandos através da conexão de controle
Quando o servidor recebe um comando para a transferência de um arquivo, ele abre uma conexão de dados TCP para o cliente
Após a transmissão de um arquivo o servidor fecha a conexão
O servidor abre uma segunda conexão TCP para transferir outro arquivo
Conexão de controle: “fora da faixa”
Servidor FTP mantém o “estado”: diretório atual, autenticação anterior
cliente FTP
servidor FTP
conexão de controleTCP, porta 21
conexão de dados TCP, porta 20
2a: Camada de Aplicação 35
Roteiro do Capítulo 2
2.1 Princípios dos protocolos da camada de aplicação clientes e servidores requisitos das
aplicações
2.2 Web e HTTP 2.3 FTP 2.4 Correio
Eletrônico SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de Sockets com TCP
2.7 Programação de Sockets com UDP
2.8 Construindo um servidor Web
2.9 Distribuição de conteúdo Cache Web na rede Redes de distribuição
de conteúdo Compartilhamento de
arquivos P2P
2a: Camada de Aplicação 36
Correio Eletrônico
Três grandes componentes: agentes de usuário (UA) servidores de correio simple mail transfer protocol:
smtp
Agente de Usuário a.k.a. “leitor de correio” compor, editar, ler mensagens
de correio p.ex., Eudora, Outlook, elm,
Netscape Messenger mensagens de saída e
chegando são armazenadas no servidor
caixa de correio do usuário
fila demensagens
de saída
agente de
usuário
servidor de correio
agente de
usuário
SMTP
SMTP
SMTP
agente de
usuário
agente de
usuário
agente de
usuárioagente
de usuário
servidor de correio
servidor de correio
2a: Camada de Aplicação 37
Correio Eletrônico: servidores de correio
Servidores de correio caixa de correio contém
mensagens de chegada (ainda não lidas) p/ usuário
fila de mensagens contém mensagens de saída (a serem enviadas)
protocolo SMTP entre servidores de correio para transferir mensagens de correio cliente: servidor de
correio que envia “servidor”: servidor de
correio que recebe
servidor de correio
agente de
usuário
SMTP
SMTP
SMTP
agente de
usuário
agente de
usuário
agente de
usuárioagente
de usuário
servidor de correio
servidor de correio
2a: Camada de Aplicação 38
Correio Eletrônico: SMTP [RFC 2821]
usa tcp para a transferência confiável de msgs do correio do cliente ao servidor, porta 25
transferência direta: servidor remetente ao servidor 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 de status
mensagens precisam ser em ASCII de 7-bits
2a: Camada de Aplicação 39
Cenário: Alice envia uma msg para Bob
1) Alice usa o UA para compor uma mensagem “para” [email protected]
2) O UA de Alice envia a mensagem para o seu servidor de correio; a mensagem é colocada na fila de mensagens
3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio de Bob
4) O cliente SMTP envia a mensagem de Alice através da conexão TCP
5) O servidor de correio de Bob coloca a mensagem na caixa de entrada de Bob
6) Bob chama o seu UA para ler a mensagem
useragent
mailserver
mailserver user
agent
1
2 3 4 56
2a: Camada de Aplicação 42
SMTP: últimas palavras
SMTP usa conexões persistentes
SMTP requer que a mensagem (cabeçalho e corpo) sejam em ascii de 7-bits
algumas cadeias de caracteres não são permitidas numa mensagem (p.ex., CRLF.CRLF). Logo a mensagem pode ter que ser codificada (normalmente em base-64 ou “quoted printable”)
servidor SMTP usa CRLF.CRLF para reconhecer o final da mensagem
Comparação com HTTP HTTP: pull (puxar) email: push (empurrar)
ambos têm interação comando/resposta, códigos de status em ASCII
HTTP: cada objeto é encapsulado em sua própria mensagem de resposta
SMTP: múltiplos objetos de mensagem enviados numa mensagem de múltiplas partes
2a: Camada de Aplicação 44
Protocolos de acesso ao correio
SMTP: entrega/armazenamento no servidor do receptor protocolo de accesso ao correio: recupera do servidor
POP: Post Office Protocol [RFC 1939]• autorização (agente <-->servidor) e transferência
IMAP: Internet Mail Access Protocol [RFC 1730]• mais comandos (mais complexo)• manuseio de msgs armazenadas no servidor
HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
servidor de correio do remetente
SMTP SMTP POP3 ouIMAP
servidor de correiodo receptor
agente de
usuário
agente de
usuário
2a: Camada de Aplicação 45
Protocolo POP3
fase de autorização comandos do cliente:
user: declara nome pass: senha
servidor responde +OK -ERR
fase de transação, cliente: list: lista números das
msgs retr: recupera msg por
número dele: apaga msg quit
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off
S: +OK POP3 server ready C: user ana S: +OK C: pass faminta S: +OK user successfully logged on
2a: Camada de Aplicação 46
POP3 (mais) e IMAPMais sobre o POP3 O exemplo anterior usa o
modo “download e delete”.
Bob não pode reler as mensagens se mudar de cliente
“Download-e-mantenha”: copia as mensagens em clientes diferentes
POP3 não mantém estado entre conexões
IMAP Mantém todas as
mensagens num único lugar: o servidor
Permite ao usuário organizar as mensagens em pastas
O IMAP mantém o estado do usuário entre sessões: nomes das pastas e
mapeamentos entre as IDs das mensagens e o nome da pasta
2a: Camada de Aplicação 47
Roteiro do Capítulo 2
2.1 Princípios dos protocolos da camada de aplicação clientes e servidores requisitos das
aplicações
2.2 Web e HTTP 2.3 FTP 2.4 Correio
Eletrônico SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de Sockets com TCP
2.7 Programação de Sockets com UDP
2.8 Construindo um servidor Web
2.9 Distribuição de conteúdo Cache Web na rede Redes de distribuição
de conteúdo Compartilhamento de
arquivos P2P
2a: Camada de Aplicação 48
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
2a: Camada de Aplicação 49
DNS
Roda sobre UDP e usa a porta 53
Especificado nas RFCs 1034 e 1035 e atualizado em outras RFCs.
Outros serviços: apelidos para
hospedeiros (aliasing) apelido para o
servidor de mails distribuição da carga
2a: Camada de Aplicação 50
Servidores de nomes DNS
Nenhum servidor mantém todos os mapeamento nome-para-endereço IP
servidor de nomes local: cada provedor, empresa tem
servidor de nomes local (default)
pedido DNS de hospedeiro vai primeiro ao servidor de nomes local
servidor de nomes oficial: p/ hospedeiro: guarda nome,
endereço IP dele pode realizar tradução
nome/endereço para este nome
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!
2a: Camada de Aplicação 51
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
b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA
13 servidores de nome raiz em todo o mundo
2a: Camada de Aplicação 52
Domain Name Space
...
...
F Q D N
.. (root)
com edu net org gov mil br fr us
org com ufba mil govmicrosoft
cisco
fieb
www mail
uol esaex baftp
pmswwwwww2
www
wwwsupport cisco
netacad
fieb.org.brwww + /dendezeiros/default.html
U R L
www.fieb.org.br/dendezeiros/default.html
2a: Camada de Aplicação 53
Exemplo simples do DNS
hospedeiro manga.ic.uff.br requer endereço IP de www.cs.columbia.edu
1. Contata servidor DNS local, pitomba.ic.uff.br
2. pitomba.ic.uff.br contata servidor raiz, se necessário
3. Servidor raiz contata servidor oficial cs.columbia.edu, se necessário
solicitantemanga.ic.uff.br
www.cs.columbia.edu
servidor de nomes raiz
servidor oficialcs.columbia.edu
servidor localpitomba.ic.uff.br
1
23
4
5
6
2a: Camada de Aplicação 54
Exemplo de DNS
Servidor raiz: pode não conhecer
o servidor de nomes oficial
pode conhecer servidor de nomes intermediário: a quem contatar para descobrir o servidor de nomes oficial
solicitantemanga.ic.uff.br
www.cs.columbia.edu
servidor localpitomba.ic.uff.br
1
23
4 5
6
servidor oficialcs.columbia.edu
servidor intermediáriosaell.cc.columbia.edu
7
8
servidor de nomes raiz
2a: Camada de Aplicação 56
DNS: uso de cache, atualização de dados
uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cache local futuras consultas são resolvidas usando
dados da cache entradas na cache são sujeitas a
temporização (desaparecem depois de um certo tempo)
estão sendo projetados pela IETF mecanismos de atualização/notificação dos dados RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html
2a: Camada de Aplicação 57
cisco.netacad.net ? net é com98.3.8.231
cisco.netacad.net ?
netacad.net é com197.13.0.6cisco.netacad.net ?
cisco.netacad.net é com200.2.45.189
200.2.45.189
Pesquisa DNS - exemploServidor raiz(INTERNIC)
Servidor de net98.3.8.231
Servidor do NetAcad197.13.0.6
ServidorLocal
cisco.netacad.net ?
2a: Camada de Aplicação 58
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
2a: Camada de Aplicação 59
Características Gerais O DNS é um protocolo de camada de aplicação; O DNS usa os serviços de transporte prestado pelos protocolos
TCP e UDP, acessando a well-know port 53:UDP consultas dos clientes aos servidores DNS;TCP replicação entre servidores DNS primários e secundários;
As informações DNS ficam em BDs estáticos denominados Zonas;
Uma Zona DNS contém os registros de recursos DNS:• SOA Start of Authority Indica o Server como autoridade em
host name• NS Name Server Indica outro DNS Server• A Address Mapeia o host name para o IP address• CNAME Alias Um nome alternativo para um host• PTR Pointer É o inverso do registro A• MX Mail Exchanger Indica p/ onde mandar e-mail• RP Responsible Person Mapeia o nome do responsável
pelo domínio
DNS X WINS
2a: Camada de Aplicação 62
Capítulo 2: Resumo
Requisitos do serviço de aplicação: confiabilidade, banda,
retardo paradigma cliente-
servidor modelo de serviço do
transporte orientado a conexão, confiável da Internet: TCP não confiável,
datagramas: UDP
Terminamos nosso estudo de aplicações de rede!
Protocolos específicos: HTTP FTP SMTP, POP, IMAP DNS
programação c/ sockets distribuição de
conteúdos Caches, CDNs P2P
2a: Camada de Aplicação 63
Capítulo 2: Resumo
troca típica de mensagens pedido/resposta: cliente solicita info ou
serviço servidor responde com
dados, código de status formatos de mensagens:
cabeçalhos: campos com info sobre dados (metadados)
dados: info sendo comunicada
Mais importante: aprendemos sobre protocolos
msgs de controle X dados na banda, fora da banda
centralizado X descentralizado
s/ estado X c/ estado transferência de msgs
confiável X não confiável “complexidade na borda da
rede” segurança: autenticação