Capítulo 2: Camada de Aplicação
Metas do capítulo:
r
Mais metas do capítulo
aspectos conceituais e de
r protocolos específicos:
implementação de
protocolos de aplicação
em redes
m modelos de serviço da
camada de transporte
m paradigma cliente
r
servidor
m paradigma peer-to-
peer
r
aprenda sobre protocolos
através do estudo de
protocolos populares da
camada de aplicação
m
m
m
m
HTTP
FTP
SMTP/ POP3/ IMAP
DNS
a programação de
aplicações de rede
m
programação usando a API
de sockets
2a: Camada de Aplicação
1
Roteiro do Capítulo 2
r
2.1 Princípios dos
protocolos da camada
de aplicação
m
m
clientes e servidores
requisitos das
aplicações
2.2 Web e HTTP
r 2.3 FTP
r 2.4 Correio Eletrônico
r
m
r
SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de
Sockets com TCP
r 2.7 Programação de
Sockets com UDP
r 2.8 Construindo um
servidor Web
r 2.9 Distribuição de
conteúdo
r
m
m
m
Cache Web na rede
Redes de distribuição de
conteúdo
Compartilhamento de
arquivos P2P
2a: Camada de Aplicação
2
Aplicações de rede: algum jargão
r
r
r
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.
r
Um agente de usuário
(UA) é uma interface
entre o usuário “acima”
e a rede “abaixo”.
m
m
m
m
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
3
Aplicações e protocolos da camada de aplicação
Aplicação: processos distribuídos em
comunicação
m p.ex., correio, Web,
compartilhamento de arquivos
P2P, mensagens instantâneas
m executam em hospedeiros no
“espaço de usuário”
m trocam mensagens para
implementar a aplicação
Protocolos da camada de aplicação
m uma “parte” da aplicação
m define mensagens trocadas por
apls e ações tomadas
m usam serviços providos por
protocolos da camada inferior
(TCP, UDP)
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
2a: Camada de Aplicação
4
Os protocolos da camada de
aplicação definem
Tipos de mensagens
trocadas, ex. mensagens
de pedido e resposta
r Sintaxe dos tipos das
mensagens: campos
presentes nas mensagens
e como são identificados
r Semântica dos campos,
i.e., significado da
informação nos campos
r Regras para quando os
processos enviam e
respondem às mensagens
r
Protocolos de domínio
público:
r definidos em RFCs
r Permitem a
interoperação
r ex, HTTP e SMTP
Protocolos proprietários:
r Ex., KaZaA
2a: Camada de Aplicação
5
Paradigma cliente-servidor (C-S)
Apl. de rede típica tem duas
partes: cliente e servidor
Cliente:
r inicia contato com o servidor
(“fala primeiro”)
r tipicamente solicita serviço do
servidor
r para WWW, cliente
implementado no browser; para
correio no leitor de mensagens
Servidor:
r provê ao cliente o serviço
requisitado
r p.ex., servidor WWW envia
página solicitada; servidor de
correio entrega mensagens
aplicação
transporte
rede
enlace
física
pedido
resposta
aplicação
transporte
rede
enlace
física
2a: Camada de Aplicação
6
Comunicação entre processos através da
rede
r
r
Os processos enviam/ recebem
mensagens para/ dos seus
sockets
Um socket é análogo a uma
porta
m
m
r
host ou
servidor
host ou
servidor
Processo transmissor envia a
mensagem através da porta
O processo transmissor
assume a existência da infraestrutura de transporte no
outro lado da porta que faz
com que a mensagem chegue
ao socket do processo
receptor
processo
controlado pelo
desenvolvedor da
aplicação
processo
socket
socket
TCP com
buffers,
variáveis
Internet
TCP com
buffers,
variáveis
controlado
pelo SO
API: (1) escolha do protocolo de transporte; (2)
habilidade para fixar alguns parâmetros (mais sobre
isto posteriormente)
2a: Camada de Aplicação
7
Endereçando os processos:
r
r
r
r
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.
r Exemplo de números
de portas:
r
m
m
r
Servidor HTTP: 80
Servidor de Correio: 25
Mais sobre isto
posteriormente.
2a: Camada de Aplicação
8
De que serviço de transporte uma
aplicação precisa?
Perda de dados
r
r
algumas apls (p.ex. áudio)
podem tolerar algumas
perdas
outras (p.ex., transf. de
arquivos, telnet) requerem
transferência 100%
confiável
Largura de banda
r
r
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
Temporização
r
algumas apls (p.ex.,
telefonia Internet, jogos
interativos) requerem
baixo retardo para serem
“viáveis”
2a: Camada de Aplicação
9
Requisitos do serviço de transporte de apls comuns
Aplicação
transferência de arqs
correio
documentos WWW
áudio/vídeo de
tempo real
áudio/vídeo gravado
jogos interativos
apls financeiras
Sensibilidade
temporal
Perdas
Banda
sem perdas
sem perdas
sem perdas
tolerante
elástica
elástica
elástica
áudio: 5Kb-1Mb
vídeo:10Kb-5Mb
como anterior
> alguns Kbps
elástica
tolerante
tolerante
sem perdas
não
não
não
sim, 100’s mseg
sim, alguns segs
sim, 100’s mseg
sim e não
2a: Camada de Aplicação
10
Serviços providos por protocolos de
transporte Internet
Serviço TCP:
Serviço UDP:
r
r
r
r
r
r
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
r
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
11
Apls Internet: seus protocolos e seus
protocolos de transporte
Aplicação
correio eletrônico
accesso terminal remoto
WWW
transferência de arquivos
streaming multimídia
servidor de arquivo remoto
telefonia Internet
Protocolo da
camada de apl
Protocolo de
transporte usado
SMTP [RFC 2821]
telnet [RFC 854]
HTTP [RFC 2616]
ftp [RFC 959]
proprietário
(p.ex. RealNetworks)
NSF
proprietário
(p.ex., Dialpad)
TCP
TCP
TCP
TCP
TCP ou UDP
TCP ou UDP
tipicamente UDP
2a: Camada de Aplicação
12
Roteiro do Capítulo 2
r
2.1 Princípios dos
protocolos da camada
de aplicação
m
m
clientes e servidores
requisitos das
aplicações
2.2 Web e HTTP
r 2.3 FTP
r 2.4 Correio Eletrônico
r
m
r
SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de
Sockets com TCP
r 2.7 Programação de
Sockets com UDP
r 2.8 Construindo um
servidor Web
r 2.9 Distribuição de
conteúdo
r
m
m
m
Cache Web na rede
Redes de distribuição de
conteúdo
Compartilhamento de
arquivos P2P
2a: Camada de Aplicação
13
WWW: algum jargão
r
Página WWW:
m
m
r
m
r
consiste de “objetos”
endereçada por uma URL
Quase todas as páginas
WWW consistem de:
m
r
página base HTML, e
vários objetos
referenciados.
Agente de usuário para
WWW se chama de
browser:
m
m
r
URL tem duas partes:
nome de hospedeiro, e
nome de caminho:
MS Internet Explorer
Netscape Communicator
Servidor para WWW se
chama “servidor
WWW”:
m
m
Apache (domínio público)
MS Internet Information
Server (IIS)
www.univ.br/algum-depto/pic.gif
2a: Camada de Aplicação
14
WWW: o protocolo HTTP
HTTP: hypertext
transfer protocol
r
r
r
r
protocolo da camada de
aplicação para WWW
modelo cliente/servidor
m cliente: browser que
pede, recebe, “visualiza”
objetos WWW
m servidor: servidor
WWW envia objetos em
resposta a pedidos
http1.0: RFC 1945
http1.1: RFC 2068
PC executa
Explorer
Servidor
executando
servidor
WWW
do NCSA
Mac executa
Navigator
2a: Camada de Aplicação
15
Mais sobre o protocolo HTTP
Usa serviço de transporte
TCP:
r
r
r
r
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”
r
servidor não mantém
informação sobre
pedidos anteriores do
cliente
Nota
Protocolos que mantêm
“estado” são complexos!
r história passada (estado)
tem que ser guardada
r Caso caia servidor/cliente,
suas visões do “estado”
podem ser inconsistentes,
devem ser reconciliadas
2a: Camada de Aplicação
16
Conexões HTTP
HTTP não persistente
r No máximo um objeto
é enviado numa
conexão TCP.
r HTTP/1.0 usa o HTTP
não persistente
HTTP persistente
r Múltiplos objetos
podem ser enviados
sobre uma única
conexão TCP entre
cliente e servidor.
r HTTP/1.1 usa conexões
persistentes no seu
modo default
2a: Camada de Aplicação
17
Exemplo de HTTP não persistente
Supomos que usuário digita a URL
www.algumaUniv.br/algumDepartmento/inicial.index
(contém texto,
referências a 10
imagens jpeg)
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
tempo
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
2a: Camada de Aplicação
18
Exemplo de HTTP não persistente
(cont.)
4. servidor http encerra conexão
5. cliente http recebe mensagem
TCP .
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
tempo
2a: Camada de Aplicação
19
Modelagem do tempo de
resposta
Definiçã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:
r um RTT para iniciar a conexão
TCP
r um RTT para o pedido HTTP e
o retorno dos primeiros bytes
da resposta HTTP
r tempo de transmissão do
arquivo
total = 2RTT+tempo de
transmissão
Inicia a conexão
TCP
RTT
solicita
arquivo
tempo para
transmitir
o arquivo
RTT
arquivo
recebido
tempo
tempo
2a: Camada de Aplicação
20
HTTP persistente
Problemas com o HTTP não
persistente:
r requer 2 RTTs para cada
objeto
r SO aloca recursos do host para
cada conexão TCP
r os browsers freqüentemente
abrem conexões TCP paralelas
para recuperar os objetos
referenciados
HTTP persistente
r o servidor deixa a conexão
aberta após enviar a resposta
r mensagens HTTP seguintes
entre o mesmo cliente/servidor
são enviadas nesta conexão
Persistente sem pipelining:
r o cliente envia um novo
pedido apenas quando a
resposta anterior tiver sido
recebida
r um RTT para cada objeto
referenciado
Persistente com pipelining:
r default no HTTP/1.1
r o cliente envia os pedidos
logo que encontra um
objeto referenciado
r pode ser necessário apenas
um RTT para todos os
objetos referenciados
2a: Camada de Aplicação
21
mensagem de pedido HTTP: formato geral
2a: Camada de Aplicação
22
Formulários e interação bidirecional
r
r
r
Formulários transmitem
informação do cliente ao
servidor
HTTP permite enviar
formulários ao servidor
Resposta enviada como
página HTML dinâmica
cliente
WWW
GET/POST
formulário
resposta:
HTML
r
Formulários processados usando
scripts CGI (programas que
executam no servidor WWW)
m CGI - Common Gateway
Interface
m scripts CGI escondem
acesso a diferentes serviços
m servidor WWW atua como
gateway universal
servidor
WWW
Sistema de
informação
2a: Camada de Aplicação
23
HTML (HyperText Markup Language)
r
HTML: uma linguagem simples para hipertexto
m
m
r
Construtores de formato operam sobre cadeias
m
m
m
r
começou como versão simples de SGML
construção básica: cadeias de texto anotadas
<b> .. </b>
bold (negrito)
<H1 ALIGN=CENTER> ..título centrado .. </H1>
<BODY bgcolor=white text=black link=red ..> .. </BODY>
vários formatos
m
m
m
listas de bullets, listas ordenadas, listas de definição
tabelas
frames
2a: Camada de Aplicação
28
Cookies: manutenção do
“estado”
Muitos dos principais sítios
Web usam cookies
Quatro 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:
m
m
m
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
29
Cookies (continuação)
O que os cookies podem
obter:
r autorização
r carrinhos de compra
r sugestões
r estado da sessão do
usuário (Webmail)
nota
Cookies e privacidade:
r
r
r
r
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
2a: Camada de Aplicação
30
Roteiro do Capítulo 2
r
2.1 Princípios dos
protocolos da camada
de aplicação
m
m
clientes e servidores
requisitos das
aplicações
2.2 Web e HTTP
r 2.3 FTP
r 2.4 Correio Eletrônico
r
m
r
SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de
Sockets com TCP
r 2.7 Programação de
Sockets com UDP
r 2.8 Construindo um
servidor Web
r 2.9 Distribuição de
conteúdo
r
m
m
m
Cache Web na rede
Redes de distribuição de
conteúdo
Compartilhamento de
arquivos P2P
2a: Camada de Aplicação
31
ftp: o protocolo de transferência
de arquivos
usuário
na
estação
r
r
r
r
Interface cliente
do usuário FTP
FTP
transferência
do arquivo
sistema de
arquivos
local
FTP
servidor
sistema de
arquivos
remoto
transferir arquivo de/para hospedeiro remoto
modelo cliente/servidor
m cliente: lado que inicia transferência (pode ser de ou
para o sistema remoto)
m servidor: hospedeiro remoto
ftp: RFC 959
servidor ftp: porta 21
2a: Camada de Aplicação
32
FTP: conexões separadas p/ controle, dados
r
r
r
r
r
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
conexão de controle
TCP, porta 21
cliente
FTP
r
r
r
conexão de dados
TCP, porta 20
servidor
FTP
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
2a: Camada de Aplicação
33
Roteiro do Capítulo 2
r
2.1 Princípios dos
protocolos da camada
de aplicação
m
m
clientes e servidores
requisitos das
aplicações
2.2 Web e HTTP
r 2.3 FTP
r 2.4 Correio Eletrônico
r
m
r
SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de
Sockets com TCP
r 2.7 Programação de
Sockets com UDP
r 2.8 Construindo um
servidor Web
r 2.9 Distribuição de
conteúdo
r
m
m
m
Cache Web na rede
Redes de distribuição de
conteúdo
Compartilhamento de
arquivos P2P
2a: Camada de Aplicação
35
Correio Eletrônico
Três grandes componentes:
r
r
r
agentes de usuário (UA)
servidores de correio
simple mail transfer protocol:
smtp
servidor
de correio
agente
de
usuário
SMTP
Agente de Usuário
SMTP
r a.k.a. “leitor de correio”
r compor, editar, ler mensagens
de correio
servidor
de correio
r p.ex., Eudora, Outlook, elm,
Netscape Messenger
r mensagens de saída e chegando
são armazenadas no servidor
agente
de
usuário
SMTP
fila de
mensagens
de saída
caixa de
correio do usuário
agente
de
usuário
servidor
de correio
agente
de
usuário
agente
de
usuário
agente
de
usuário
2a: Camada de Aplicação
36
Correio Eletrônico: servidores de correio
agente
de
usuário
Servidores de correio
r
r
r
caixa de correio contém
servidor
mensagens de chegada
de correio
(ainda não lidas) p/ usuário
SMTP
fila de mensagens contém
mensagens de saída (a serem
enviadas)
SMTP
protocolo SMTP entre
servidores de correio para
SMTP
transferir mensagens de
servidor
correio
de correio
m cliente: servidor de
correio que envia
agente
de
m “servidor”: servidor de
usuário
correio que recebe
agente
de
usuário
agente
de
usuário
servidor
de correio
agente
de
usuário
2a: Camada de Aplicação
37
Correio Eletrônico:
SMTP [RFC 2821]
r
r
r
r
r
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
m handshaking (cumprimento)
m transferência das mensagens
m encerramento
interação comando/resposta
m comandos: texto ASCII
m resposta: código e frase de status
mensagens precisam ser em ASCII de 7-bits
2a: Camada de Aplicação
38
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
1
user
agent
2
mail
server
3
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
mail
server
4
5
6
user
agent
2a: Camada de Aplicação
39
SMTP: últimas palavras
r
r
r
r
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
r
r
r
r
r
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
42
Protocolos de acesso ao correio
agente
de
usuário
SMTP
SMTP
servidor de correio
do remetente
r
r
POP3 ou
IMAP
agente
de
usuário
servidor de correio
do receptor
SMTP: entrega/armazenamento no servidor do receptor
protocolo de accesso ao correio: recupera do servidor
m POP: Post Office Protocol [RFC 1939]
• autorização (agente <-->servidor) e transferência
m IMAP: Internet Mail Access Protocol [RFC 1730]
• mais comandos (mais complexo)
• manuseio de msgs armazenadas no servidor
m HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
2a: Camada de Aplicação
44
Protocolo POP3
fase de autorização
r
r
comandos do cliente:
m user: declara nome
m pass: senha
servidor responde
m +OK
m -ERR
fase de transação, cliente:
r
r
r
r
list: lista números das
msgs
retr: recupera msg por
número
dele: apaga msg
quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user ana
+OK
pass faminta
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
2a: Camada de Aplicação
on
45
POP3 (mais) e IMAP
Mais sobre o POP3
r O exemplo anterior usa o
modo “download e delete”.
r Bob não pode reler as
mensagens se mudar de
cliente
r “Download-e-mantenha”:
copia as mensagens em
clientes diferentes
r POP3 não mantém estado
entre conexões
IMAP
r Mantém todas as
mensagens num único lugar:
o servidor
r Permite ao usuário
organizar as mensagens em
pastas
r O IMAP mantém o estado
do usuário entre sessões:
m
nomes das pastas e
mapeamentos entre as IDs
das mensagens e o nome da
pasta
2a: Camada de Aplicação
46
Roteiro do Capítulo 2
r
2.1 Princípios dos
protocolos da camada
de aplicação
m
m
clientes e servidores
requisitos das
aplicações
2.2 Web e HTTP
r 2.3 FTP
r 2.4 Correio Eletrônico
r
m
r
SMTP, POP3, IMAP
2.5 DNS
2.6 Programação de
Sockets com TCP
r 2.7 Programação de
Sockets com UDP
r 2.8 Construindo um
servidor Web
r 2.9 Distribuição de
conteúdo
r
m
m
m
Cache Web na rede
Redes de distribuição de
conteúdo
Compartilhamento de
arquivos P2P
2a: Camada de Aplicação
47
DNS: Domain Name System
Pessoas: muitos
identificadores:
m
CPF, nome, no. da
Identidade
hospedeiros, roteadores
Internet :
m
m
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:
r
base de dados distribuída
r
protocolo de camada de
aplicação permite que
implementada na hierarquia de
muitos servidores de nomes
hospedeiros, roteadores,
servidores de nomes se
comuniquem para resolver nomes
(tradução endereço/nome)
m nota: função imprescindível
da Internet implementada
como protocolo de camada de
aplicação
m complexidade na borda da
rede
2a: Camada de Aplicação
48
DNS
Roda sobre UDP e usa
a porta 53
r Especificado nas RFCs
1034 e 1035 e
atualizado em outras
RFCs.
r
r
Outros serviços:
m
m
m
apelidos para
hospedeiros (aliasing)
apelido para o servidor
de mails
distribuição da carga
2a: Camada de Aplicação
49
Servidores de nomes DNS
Por que não centralizar o r Nenhum servidor mantém
todos os mapeamento nomeDNS?
para-endereço IP
r ponto único de falha
servidor de nomes local:
r volume de tráfego
m cada provedor, empresa tem
servidor de nomes local (default)
r base de dados
m pedido DNS de hospedeiro vai
centralizada e distante
primeiro ao servidor de nomes
r manutenção (da BD)
local
servidor de nomes oficial:
Não é escalável!
m
m
p/ hospedeiro: guarda nome,
endereço IP dele
pode realizar tradução
nome/endereço para este nome
2a: Camada de Aplicação
50
DNS: Servidores raiz
r
r
procurado por servidor local que não consegue resolver o
nome
servidor raiz:
m procura servidor oficial se mapeamento desconhecido
m obtém tradução
m devolve mapeamento ao servidor local
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
13 servidores de
nome raiz em
todo o mundo
2a: Camada de Aplicação
51
Domain Name Space
. (root)
com
edu
net
org
micro
cisco netacad
soft
support www cisco
gov
mil
br
fr
org
com
ufba
mil
gov
esaex
ba
fieb
uol
ftp
www mail www2
www
URL
us
...
...
pms
FQDN
www
+ fieb.org.br
/dendezeiros/default.html
www.fieb.org.br/dendezeiros/default.html
www
2a: Camada de Aplicação
52
Exemplo simples do DNS
hospedeiro
manga.ic.uff.br requer
endereço IP de
www.cs.columbia.edu
servidor de
nomes raiz
2
4
5
3
1. Contata servidor DNS local,
pitomba.ic.uff.br
servidor local
servidor oficial
2. pitomba.ic.uff.br
pitomba.ic.uff.br
cs.columbia.edu
contata servidor raiz, se
1
6
necessário
3. Servidor raiz contata
servidor oficial
cs.columbia.edu, se
solicitante
www.cs.columbia.edu
necessário
manga.ic.uff.br
2a: Camada de Aplicação
53
Exemplo de DNS
Servidor raiz:
r
r
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
servidor de
nomes raiz
6
2
7
3
servidor intermediário
pitomba.ic.uff.br saell.cc.columbia.edu
5
4
1
8
servidor local
solicitante
servidor oficial
cs.columbia.edu
manga.ic.uff.br
www.cs.columbia.edu
2a: Camada de Aplicação
54
DNS: uso de cache, atualização de dados
uma vez que um servidor qualquer aprende um
mapeamento, ele o coloca numa cache local
m futuras consultas são resolvidas usando dados
da cache
m entradas na cache são sujeitas a temporização
(desaparecem depois de um certo tempo)
r estão sendo projetados pela IETF mecanismos
de atualização/notificação dos dados
r
m
RFC 2136
m
http://www.ietf.org/html.charters/dnsind-charter.html
2a: Camada de Aplicação
56
Pesquisa DNS - exemplo
cisco.netacad.net ?
Servidor
Local
200.2.45.189
net é com
98.3.8.231
cisco.netacad.net ?
cisco.netacad.net ?
Servidor raiz
(INTERNIC)
Servidor de net
98.3.8.231
netacad.net é com
197.13.0.6
Servidor do NetAcad
197.13.0.6
cisco.netacad.net ?
cisco.netacad.net é com
2a: Camada de Aplicação
200.2.45.189
57
Registros DNS
DNS: BD distribuído contendo registros de recursos (RR)
formato RR: (nome,
r
Tipo=A
m
m
r
valor, tipo, sobrevida)
r
nome é nome de hospedeiro
valor é o seu endereço IP
m
Tipo=NS
m
m
nome é domínio (p.ex.
foo.com.br)
valor é endereço IP de
servidor oficial de nomes
para este domínio
Tipo=CNAME
m
r
nome é nome alternativo
(alias) para algum nome
“canônico” (verdadeiro)
valor é o nome
canônico
Tipo=MX
m
m
nome é domínio
valor é nome do servidor de
correio para este domínio
2a: Camada de Aplicação
58
Características Gerais
O DNS é um protocolo de camada de aplicação;
r O DNS usa os serviços de transporte prestado pelos protocolos TCP e
UDP, acessando a well-know port 53:
r
m
m
r
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;
m
Uma Zona DNS contém os registros de recursos DNS:
•
•
•
•
•
•
•
r
SOA
NS
A
CNAME
PTR
MX
RP
Start of AuthorityIndica o Server como autoridade em host name
Name Server
Indica outro DNS Server
Address
Mapeia o host name para o IP address
Alias
Um nome alternativo para um host
Pointer
É o inverso do registro A
Mail Exchanger
Indica p/ onde mandar e-mail
Responsible Person Mapeia o nome do responsável pelo domínio
DNS X WINS
2a: Camada de Aplicação
59
Capítulo 2: Resumo
Terminamos nosso estudo de aplicações de rede!
r
Requisitos do serviço de
aplicação:
m
r
r
confiabilidade, banda,
retardo
paradigma cliente-servidor
modelo de serviço do
transporte orientado a
conexão, confiável da
Internet: TCP
m
r
não confiável, datagramas:
UDP
Protocolos específicos:
m
m
m
m
HTTP
FTP
SMTP, POP, IMAP
DNS
programação c/ sockets
r distribuição de
conteúdos
r
m
m
Caches, CDNs
P2P
2a: Camada de Aplicação
62
Capítulo 2: Resumo
Mais importante: aprendemos sobre protocolos
r
troca típica de mensagens
pedido/resposta:
m
m
r
cliente solicita info ou serviço
servidor responde com dados,
código de status
formatos de mensagens:
m
m
cabeçalhos: campos com info
sobre dados (metadados)
dados: info sendo comunicada
r
r
r
r
r
r
msgs de controle X dados
m 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
2a: Camada de Aplicação
63