O documento apresenta uma visão geral do protocolo HTTP, incluindo suas versões (HTTP/1.0 e HTTP/1.1) e como ele funciona na comunicação entre clientes e servidores web. Ele discute conceitos como conexões persistentes e não persistentes, cache, e o funcionamento de cookies na manutenção do estado da sessão. Além disso, menciona outros protocolos como FTP e SMTP, com detalhes sobre suas operações e interações.

1. © 2009 by Almir Silveira 1
1
Pilha de Protocolos TCP/IP

2. © 2009 by Almir Silveira 2
2
Protocolo HTTP
HTTP: hypertext transfer protocol
• protocolo da camada de
aplicação da Web
• modelo cliente/servidor
– cliente: browser que pede,
recebe, “visualiza” objetos
Web
– servidor: servidor Web envia
objetos em resposta a
pedidos
• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2068
PC executa
Explorer
Servidor
executando
servidor
WWW
do NCSA
Mac executa
Navigator

3. © 2009 by Almir Silveira 3
3
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
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
HTTP é “sem estado”
• servidor não mantém
informação sobre pedidos
anteriores do cliente
Nota
8 - 3

4. © 2009 by Almir Silveira 4
4
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

5. © 2009 by Almir Silveira 5
5
Exemplo de HTTP não persistente
Supomos 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.i
ndex), envia mensagem via
socket
tempo

6. © 2009 by Almir Silveira 6
6
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

7. 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:
• 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ão
TCP
RTT
solicita
arquivo
RTT
arquivo
recebido
tempo tempo
8 - 7

8. © 2009 by Almir Silveira 8
8
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 browser 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

9. © 2009 by Almir Silveira 9
9
Formato de mensagem HTTP: pedido
 Dois tipos de mensagem HTTP: pedido, resposta
 mensagem de pedido HTTP:
 ASCII (formato legível por pessoas)
GET /somedir/page.html HTTP/1.0
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(carriage return (CR), line feed(LF) adicionais)
linha do pedido
(comandos GET,
POST, HEAD)
linhas do
cabeçalho
Carriage return,
line feed
indicam fim
de mensagem
8 - 9

10. © 2009 by Almir Silveira 10
10
Mensagem de pedido HTTP: formato geral
8 - 10

11. © 2009 by Almir Silveira 13
13
Formato de mensagem HTTP: resposta
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
dados dados dados dados ...
linha de status
(protocolo,
código de status,
frase de status)
linhas de
cabeçalho
dados, p.ex.,
arquivo html
solicitado
8 - 13

12. © 2009 by Almir Silveira 14
14
códigos de status da resposta HTTP
200 OK
– sucesso, objeto pedido segue mais adiante nesta mensagem
301 Moved Permanently
– objeto pedido mudou de lugar, nova localização especificado
mais adiante nesta mensagem (Location:)
400 Bad Request
– mensagem de pedido não entendida pelo servidor
404 Not Found
– documento pedido não se encontra neste servidor
505 HTTP Version Not Supported
– versão de http do pedido não usada por este servidor
Na primeira linha da mensagem de resposta servidor->cliente. Alguns códigos típicos:

13. © 2009 by Almir Silveira 15
15
Experimente você com HTTP (do lado cliente)
1. Use cliente telnet para seu servidor WWW
favorito:
Abre conexão TCP para a porta 80
(porta padrão do servidor http) a www.ic.uff.br.
Qualquer coisa digitada é enviada para a
porta 80 do www.ic.uff.br
telnet www.ic.uff.br 80
2. Digite um pedido GET HTTP:
GET /~celio/index.html HTTP/1.0 Digitando isto (deve teclar
ENTER duas vezes), está enviando
este pedido GET mínimo (porém
completo) ao servidor http
3. Examine a mensagem de resposta enviada pelo
servidor HTTP !

14. © 2009 by Almir Silveira 16
16
Cookies: manutenção do “estado” da conexão
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:
– 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

15. © 2009 by Almir Silveira 17
17
Cookies: manutenção do “estado” (cont.)
cliente servidor
msg usual pedido http
resposta usual http +
Set-cookie: 1678
msg usual pedido http
cookie: 1678
resposta usual http
msg usual pedido http
cookie: 1678
resposta usual http
ação
específica
do cookie
ação
específica
do cookie
servidor
cria a ID 1678
para o usuário
arquivo de
Cookies
amazon: 1678
ebay: 8734
arquivo de
Cookies
ebay: 8734
arquivo de
Cookies
amazon: 1678
ebay: 8734
uma semana depois:

16. © 2009 by Almir Silveira 18
18
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
redirecionamento e cookies
para aprender ainda mais
• agências de propaganda
obtêm perfil a partir dos
sítios visitados
nota

17. © 2009 by Almir Silveira 19
19
Cache Web (servidor proxy)
• usuário configura browser:
acessos Web via proxy
• cliente envia todos pedidos
HTTP ao proxy
– se objeto no cache do
proxy, este o devolve
imediatamente na
resposta HTTP
– senão, solicita objeto do
servidor de origem,
depois devolve resposta
HTTP ao cliente
Meta: atender pedido do cliente sem envolver servidor de
origem
cliente
Servidor
proxy
cliente
Servidor
de origem
Servidor
de origem

18. © 2009 by Almir Silveira 20
20
Mais sobre Caches Web
• Cache atua tanto como cliente
quanto como servidor
• Tipicamente o cache é instalado
por um ISP (universidade,
empresa, ISP residencial)
Para que fazer cache Web?
• Redução do tempo de resposta
para os pedidos do cliente
• Redução do tráfego no canal de
acesso de uma instituição
• A Internet cheia de caches
permitem que provedores de
conteúdo “pobres” efetivamente
forneçam conteúdo!

19. © 2009 by Almir Silveira 21
21
Exemplo de cache (1)
Hipóteses
• Tamanho médio de um objeto = 100.000 bits
• Taxa média de solicitações dos browsers de uma
instituição para os servidores originais = 15/seg
• Atraso do roteador institucional para qualquer
servidor origem e de volta ao roteador = 2seg
Conseqüências
• Utilização da LAN = 15%
• Utilização do canal de acesso = 100%
• Atraso total = atraso da Internet + atraso de
acesso + atraso na LAN = 2 seg + minutos +
milisegundos
Servidores
de origem
Internet
pública
rede da
instituição
LAN 10 Mbps
enlace de acesso
1,5 Mbps

20. © 2009 by Almir Silveira 22
22
Exemplo de cache (2)
Solução em potencial
• Aumento da largura de banda do canal de
acesso para, por exemplo, 10 Mbps
Conseqüências
• Utilização da LAN = 15%
• Utilização do canal de acesso = 15%
• Atraso total = atraso da Internet + atraso de
acesso + atraso na LAN = 2 seg + msegs +
msegs
• Freqüentemente este é uma ampliação cara
Servidores
de origem
Internet
pública
rede da
instituição
LAN 10 Mbps
enlace de acesso
10 Mbps

21. © 2009 by Almir Silveira 23
23
Exemplo de cache (3)
Instale uma cache
• Assuma que a taxa de acerto seja de 0,4
Consequências
• 40% dos pedidos serão atendidos quase que
imediatamente
• 60% dos pedidos serão servidos pelos
servidores de origem
• Utilização do canal de acesso é reduzido para
60%, resultando em atrasos desprezíveis (ex.
10 mseg)
• Atraso total = atraso da Internet + atraso de
acesso + atraso na LAN = 0,6*2 seg +
0,6*0,01 segs + msegs < 1,3 segs
Servidores
de origem
Internet
pública
rede da
instituição
LAN 10 Mbps
enlace de acesso
1,5 Mbps
cache
institucional

22. © 2009 by Almir Silveira 24
24
GET condicional
• Meta: não enviar objeto se cliente já tem
(no cache) versão atual
• cache: especifica data da cópia no cache
no pedido http
If-modified-since: <date>
• servidor: resposta não contém objeto se
cópia no cache é atual:
HTTP/1.0 304 Not Modified
cache servidor
msg de pedido http
If-modified-since:
<date>
resposta http
HTTP/1.0
304 Not Modified
objeto
não
modificado
msg de pedido http
If-modified-since:
<date>
resposta http
HTTP/1.1 200 OK
…
<data>
objeto
modificado

23. © 2009 by Almir Silveira 25
25
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ência
do arquivo FTP
servidor
Interface
do usuário
FTP
cliente
FTP
sistema de
arquivos local
sistema de
arquivos
remoto
usuário
na
estação

24. © 2009 by Almir Silveira 26
26
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 controle
TCP, porta 21
conexão de dados
TCP, porta 20

25. © 2009 by Almir Silveira 27
27
FTP: comandos, respostas
Comandos típicos:
• enviados em texto ASCII pelo
canal de controle
• USER nome
• PASS senha
• LIST devolve lista de arquivos no
diretório atual
• RETR arquivo recupera (lê)
arquivo remoto
• STOR arquivo armazena
(escreve) arquivo no hospedeiro
remoto
Códigos de retorno típicos
• código e frase de status (como para
http)
• 331 Username OK,
password required
• 125 data connection
already open; transfer
starting
• 425 Can’t open data
connection
• 452 Error writing file

26. © 2009 by Almir Silveira 28
28
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 de
mensagens
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ário
agente
de
usuário
servidor
de correio
servidor
de correio

27. © 2009 by Almir Silveira 29
29
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ário
agente
de
usuário
servidor
de correio
servidor
de correio

28. © 2009 by Almir Silveira 30
30
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

29. © 2009 by Almir Silveira 31
31
Cenário: Alice envia uma msg para Bob
1) Alice usa o UA para compor
uma mensagem “para”
bob@someschool.edu
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
user
agent
mail
server
mail
server user
agent
1
2 3 4 5
6

30. © 2009 by Almir Silveira 32
32
Interação SMTP típica
S: 220 doces.br
C: HELO consumidor.br
S: 250 Hello consumidor.br, pleased to meet you
C: MAIL FROM: <ana@consumidor.br>
S: 250 ana@consumidor.br... Sender ok
C: RCPT TO: <bernardo@doces.br>
S: 250 bernardo@doces.br ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Voce gosta de chocolate?
C: Que tal sorvete?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 doces.br closing connection
8 - 32

31. © 2009 by Almir Silveira 33
33
Experimente uma interação SMTP:
 telnet nomedoservidor 25
 veja resposta 220 do servidor
 entre comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT
estes comandos permitem que você envie correio sem usar um cliente (leitor
de correio)
8 - 33

32. © 2009 by Almir Silveira 34
34
SMTP: últimas palavras
• SMTP usa conexões persistentes
• SMTP requer que a mensagem
(cabeçalho e corpo) sejam em
ASCII de 7-bits
• servidor SMTP usa CRLF.CRLF
para reconhecer o final da
mensagem
Comparação com HTTP
• HTTP: pull (puxar)
• SMTP: 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

33. © 2009 by Almir Silveira 35
35
Formato de uma mensagem
SMTP: protocolo para trocar msgs
de correio
RFC 822: padrão para formato de
mensagem de texto:
• linhas de cabeçalho, p.ex.,
– To:
– From:
– Subject:
diferentes dos comandos de
smtp!
• corpo
– a “mensagem”, somente de
caracteres ASCII
cabeçalho
corpo
linha em
branco

34. © 2009 by Almir Silveira 36
36
Formato de uma mensagem: extensões para
multimídia
• MIME: multimedia mail extension, RFC 2045, 2056
• linhas adicionais no cabeçalho da msg declaram tipo
do conteúdo MIME
From: ana@consumidor.br
To: bernardo@doces.br
Subject: Imagem de uma bela torta
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
tipo, subtipo de
dados multimídia,
declaração parâmetros
método usado
p/ codificar dados
versão MIME
Dados codificados

35. © 2009 by Almir Silveira 37
37
Tipos MIME
Content-Type: tipo/subtipo; parâmetros
Text
• subtipos exemplos: plain,
html
• charset=“iso-8859-1”,
ascii
Image
• subtipos exemplos : jpeg,
gif
Video
• subtipos exemplos : mpeg,
quicktime
Audio
• subtipos exemplos : basic (8-
bit codificado mu-law),
32kadpcm (codificação 32
kbps)
Application
• outros dados que precisam ser
processados por um leitor para
serem “visualizados”
• subtipos exemplos : msword,
octet-stream

36. © 2009 by Almir Silveira 38
38
Tipo Multipart
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--

37. © 2009 by Almir Silveira 39
39
Protocolos de acesso ao correio
• SMTP: entrega/armazenamento no servidor do receptor
• protocolo de acesso 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 ou
IMAP
servidor de correio
do receptor
agente
de
usuário
agente
de
usuário

38. © 2009 by Almir Silveira 40
40
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

39. © 2009 by Almir Silveira 41
41
POP3 (mais) e IMAP
Mais 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

40. © 2009 by Almir Silveira 42
42
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

41. © 2009 by Almir Silveira 43
43
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
Serviços DNS
• Roda sobre UDP e usa a porta 53
– RFCs 1034, 1035
– Atualizado em outras RFCs
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!

42. Root DNS Servers
com DNS servers org DNS servers edu DNS servers
poly.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS 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
8 - 44

43. © 2009 by Almir Silveira 45
45
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, 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
8 - 45

44. © 2009 by Almir Silveira 46
46
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
 FAPESP (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
8 - 46

45. © 2009 by Almir Silveira 47
47
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”
 Quando 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.
8 - 47

46. © 2009 by Almir Silveira 48
48
solicitante
cis.poly.edu
gaia.cs.umass.edu
servidor raiz
servidor local
dns.poly.edu
1
2
3
4
5
6
servidor oficial
dns.cs.umass.edu
7
8
servidor TLD
Exemplo de DNS
• Hospedeiro em
cis.poly.edu quer
endereço IP para
gaia.cs.umass.edu

47. © 2009 by Almir Silveira 49
49
DNS: tipos de consultas
consulta recursiva:
• transfere a
responsabilidade de
resolução do nome para
o servidor de nomes
contatado
• carga pesada?
consulta interativa:
• servidor consultado
responde com o nome de
um servidor de contato
• “Não conheço este
nome, mas pergunte para
esse servidor”
1
2 3
6
8 7
9
10
consulta
interativa
servidor de nomes
raiz
servidor local
pitomba.ic.uff.br
servidor
intermediário
servidor oficial
cs.columbia.edu
solicitante
manga.ic.uff.br
www.cs.columbia.edu
consulta
recursiva
4
5
servidor TLD
saell.cc.columbia.edu

48. © 2009 by Almir Silveira 50
50
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
– RFC 2136
– http://www.ietf.org/html.charters/dnsind-charter.html

49. © 2009 by Almir Silveira 51
51
Registros DNS
DNS: 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

50. © 2009 by Almir Silveira 52
52
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

51. © 2009 by Almir Silveira 53
53
DNS: protocolo e mensagens
campos de nome, e
de tipo num pedido
RRs em resposta
ao pedido
registros para outros
servidores oficiais
info adicional
“relevante” que
pode ser usada

52. © 2009 by Almir Silveira 54
54
Inserindo registros no DNS
 Exemplo: acabou de cria 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?
8 - 54

53. © 2009 by Almir Silveira 55
55
 Breve revisão:
 Quando a Internet iniciou, era conhecida por ARPANET e consistia de
apenas alguns hosts com endereços IPs conhecidos;
 Utilizava-se um arquivo de configuração para realizar o mapeamento
entre endereços IP e os nomes descritivos.
 Aquela época, se alguém quisesse se conectar ao IP 15.5.5.5, bastava
digitar wiley
Revisão DNS

54. © 2009 by Almir Silveira 56
56
Revisão DNS
 Breve revisão:
 Para se conectar via telnet, bastava digitar telnet 15.5.5.5 ou telnet wiley
 O arquivo de configuração era mantido em um servidor centralizado do NIC
– Network Information Center
 As conseqüências da manutenção de um arquivo centralizado eram:
• Restrição na seleção de nomes, falta de eficiência na administração da rede. Àquela
época, problemas de segurança ainda não preocupavam tanto administradores

55. © 2009 by Almir Silveira 57
57
Revisão DNS
 Breve revisão:
 Até que em 1984, Paul Mockapetris da Universidade da Califórnia
propôs um sistema mais eficiente para associação de nomes a endereços
– esse sistema é a base do mecanismo de DNS como conhecemos hoje;

56. © 2009 by Almir Silveira 58
58
Revisão DNS
 Propósito do DNS:
 Um sistema DNS é composto por servidores de nomes, resolvedores e
seus protocolos de comunicação;
 Sem o mecanismo de DNS, você teria que digitar http://201.45.141.89
ao invés de www.info.ffm.com.br; ou mandar um email para
rodrigo.almeida@216.239.39.99 ao invés de rodrigo.almeida@gmail.com

57. © 2009 by Almir Silveira 59
59
Revisão DNS
 Propósito do DNS:
 A principal motivação para o uso desse mecanismo é que endereços
numéricos são mais difíceis de lembrar que endereços em forma de
nome:
• Deve-se à nossa incapacidade em lidar com muitas informações numéricas
 O mecanismo criado para tratar de aspectos do DNS foi criado um
mecanismo hierárquico para tratar dos nomes

58. © 2009 by Almir Silveira 60
60
Revisão DNS
 Propósito do DNS:
 Uma hierarquia de nomes é necessária para atribuir endereços a
computadores

59. © 2009 by Almir Silveira 61
61
Revisão DNS
 Forward Lookup
 A resolução do tipo nome para endereço IP é comum para muitos
aplicativos. O aplicativo envia uma requisição de nome para descobrir
qual o endereço IP correspondente ao domínio.
 A vantagem dessa abordagem é a implementação de balanceamento de
carga em domínios com muitos acessos:
• www.yahoo.com  corresponde a um cluster de máquinas que respondem a
requisições a esses endereços.

60. © 2009 by Almir Silveira 62
62
Revisão DNS
 Forward Lookup
 Dependendo da carga que o domínio está sujeito, DNS pode responder
com diferentes IPs para para a mesma requisição:
• ping www.yahoo.com respondendo com os endereços 216.109.118.70 e
216.109.117.204

61. © 2009 by Almir Silveira 63
63
Revisão DNS
 Reverse Lookup
 A resolução do tipo endereço para nome é o oposto do forward lookup.
Não é processo comum para seres humanos, sendo utilizados por alguns
tipos de aplicativos relacionados à rede de computadores;
• Exemplos de aplicativos: Sniffers ou Programas de login em servidores

62. © 2009 by Almir Silveira 64
64
Revisão DNS
 Reverse Lookup
 Como exemplo, a saída de um aplicativo conhecido como tcpdump
(sniffer):

63. © 2009 by Almir Silveira 65
65
Revisão DNS
 Reverse Lookup
 Pode ser usado para determinar o domínio ao qual determinado usuário
está operando; - pode ser útil para métodos de autorização
 Como exemplo uma companhia quer que somente Hosts que tenham
origem em companhia.com tenham acesso pontos internos do site.
Utilizando o mecanismo de reverse lookup permite que um filtro (tipo
proxy) verifique a origem da requisição e barre qualquer acesso externo

64. © 2009 by Almir Silveira 66
66
Revisão DNS
 Reverse Lookup
 Armazenamento de nomes em servidores de nomes são implementados
de forma a otimizar consultas de endereços;
 Muitos intervalos de endereços IPs podem ser associados com um único
domínio (como no caso do Yahoo), e cada domínio deve ser varrido antes
do IP requisitado ser identificado
 Para otimizar essa busca, é comum o uso de servidores de
armazenamento em ordem inversa

65. © 2009 by Almir Silveira 67
67
Abordagens alternativas para DNS
 Resolução de nomes também pode ser implementado usando o
arquivo /etc/hosts em sistemas operacionais UNIX
Endereço IP Endereço de Nome Apelido
127.0.0.1 Localhost.localdomain localhost
201.45.141.189 www.info.ffm.com.br Info

66. © 2009 by Almir Silveira 68
68
Segurança em DNS
 Frequentemente servidores de DNS são instalados em
computadores que não tem capacidade de CPU suficiente ou não
conseguem lidar com alta carga;
 O acesso não autorizado a servidores de DNS pode provocar
consequências negativas
 Um ataque acontecido ao servidor de DNS do yahoo em 1998
redirecionou milhares de emails

67. © 2009 by Almir Silveira 69
69
Protegendo a Infra-estrutura do DNS
 Está sujeita aos seguintes ataques:
 Footprinting: O processo de montar um diagrama ou uma base de uma
infra-estrutura de DNS, capturando dados da zona DNS, tais como
nomes de domínio, nomes de computador endereços IP dos recursos
sigilosos da rede. Os nomes de domínio e de computador DNS muitas
vezes indicam a função ou a localização de domínios e computadores.

68. © 2009 by Almir Silveira 70
70
Protegendo a Infraestrutura do DNS
 Está sujeita aos seguintes ataques:
 Ataque de negação de serviço: O atacante tenta negar a disponibilidade
dos serviços da rede; Quando um servidor DNS está saturado de
consultas a utilização de CPU dele eventualmente atinge o máximo e o
serviços torna-se indisponível. Sem um servidor DNS operacional, os
serviços dele disponíveis ficam fora.

69. © 2009 by Almir Silveira 71
71
Protegendo a Infra-estrutura do DNS
 Está sujeita aos seguintes ataques:
 Modificação de Dados: o uso de endereços IP válidos nos pacotes IP que
um invasor criou para destruir dados ou conduzir outros ataques.
Geralmente a modificação de dados é realizada em infra-estruturas que
já passaram pelo ataque de footprinting. Se o ataque for bem sucedido
os pacotes aparentarão estar vindo de um endereço IP válido de rede.

70. © 2009 by Almir Silveira 72
72
Protegendo a Infraestrutura do DNS
 Está sujeita aos seguintes ataques:
 Redirecionamento: Um ataque o qual o atacante pode redirecionar
consultas de nomes DNS para servidores controlados por ele. Um
método de redirecionamento envolve corromper o cache DNS de um
servidor DNS com dados DNS errôneos

71. © 2009 by Almir Silveira 73
73
Servidor DHCP
 Numa rede de Arquitetura TCP/IP, todo computador tem que
possuir um endereço IP distinto.
 O DHCP - Dynamic Host Configuration Protocol - é o protocolo
que provê um meio para alocar estes endereços dinamicamente
 O DHCP ("Dynamic Host Configuration Protocol" ) permite
que todos os micros da rede recebam suas configurações de
rede automaticamente a partir de um servidor central, sem
que se precise configurar os endereços manualmente em cada
ponto.

72. © 2009 by Almir Silveira 74
74
Servidor DHCP
O DHCP pode atribuir endereço para um equipamento
de rede de três formas:
Configuração manual;
Configuração automática;
Configuração dinâmica.

73. © 2009 by Almir Silveira 75
75
Servidor DHCP
Configuração Manual - Neste caso, é possível atrelar um endereço IP a uma determinada
máquina na rede. Para isso, é necessária a associação de um endereço existente no banco do
servidor DHCP ao endereço MAC do adaptador de rede da máquina. Esse endereço
"amarrado“ ao equipamento não poderá ser utilizado por outro.
Configuração Automática - Nesta forma, o servidor DHCP é configurado para atribuir um
endereço IP a um equipamento por tempo indeterminado. Quando este conecta-se pela primeira
vez na rede, lhe é atribuído um endereço permanente. A diferença existente entre esta e a
primeira configuração é que nesta não é necessária uma especificação do equipamento que
utilizará determinado endereço. Ele é atribuído de forma automática

74. © 2009 by Almir Silveira 76
76
O Problema de Bootstrapping
 O Host ainda não tem endereço IP
 Como enviar pacotes se não pode indicar o endereço
origem?
 O host não sabe a quem pedir um endereço IP nem
que outros endereços “andam por aí”
 Solução: descobrir um servidor que possa dar uma
ajuda
 Broadcast a server-discovery message
 Server sends a reply offering an address
host host host
...
DHCP server

75. © 2009 by Almir Silveira 77
77
Motivação para o DHCP
 Parâmetros de configuração para os Hosts
 Endereço IP
 Gateway
 Mascara de Rede
 Outros…
 Antes do DHCP
 Atribuição Manual
 RARP
 BOOTP

76. © 2009 by Almir Silveira 78
78
Características do DHCP
 Protocolo para prover parâmetros de configuração para hosts
através da rede
 Alocação dinâminca de Endereçamento IP
 Minima Intervenção humana

77. © 2009 by Almir Silveira 79
79
Rede Simples
Roteador
Internet
Servidor DHCP
UDP Port 68 UDP Port 68 UDP Port 68 UDP Port 67
Clientes DHCP

78. © 2009 by Almir Silveira 80
80
Informações Preliminares
 (DHCP) Message = DHCP-PDU (A-PDU)
 Client = DHCP Client
 Server = DHCP Server
 Portas Conhecidas
 DHCP Server: UDP port 67
 DHCP Client: UDP port 68
 No ephemeral ports
 Broadcast e unicast usedos para PDUs em ambas direções
 “Broadcast”: link and IP addresses are broadcast
 “Unicast”: link and IP addresses are unicast

79. © 2009 by Almir Silveira 81
81
Fluxo Inicial de Mensagens
Server A Client Server B
Cliente tenta descobrir
DHCP servers na rede
DHCPDISCOVER DHCPDISCOVER
Servers respondem com
ofertas
DHCPOFFER DHCPOFFER
Cliente coleta as ofertas e
decide qual aceitar
Cliente responde o pedido a
um dos servidores
DHCPREQUEST DHCPREQUEST
Server autoriza o uso do
endereço IP
DHCPACK
Configuração completa
Cliente explicitamente
libera o uso do endereço
IP
DHCPRELEASE
Shutdown Elegante

80. © 2009 by Almir Silveira 82
82
DHCP - Dynamic Host Configuration Protocol
arriving
client
DHCP server
233.1.2.5

81. © 2009 by Almir Silveira 83
83
DHCP Message Use
DHCPDISCOVER Broadcast do cliente para localizar servidores ativos
DHCPOFFER Server responde ao cliente que está ativo e disponível
DHCPREQUEST Cliente aceita a oferta do servidor
DHCPDECLINE Cliente informa o servidor qual ip está utilizando
DHCPACK Servidor confirma a utilização do IP para o cliente
DHCPNAK Servidor rejeita a utilização do IP para o cliente
DHCPRELEASE Cliente solicita ao servidor para abandonar o endereço IP
DHCPINFORM Cliente solicita ao servidor parâmetros de configuração
Tipos de Mensagem DHCP

82. © 2009 by Almir Silveira 84
84
Alocação de Tempos de Renovação(Client)
 T1 < T2 < Lease time
 T1 default value = 1/2 of lease time
 T2 default value = 7/8 of lease time
 Communicated via DHCPOFFER, DHCPACK
 Client actions when times elapse
 T1: cliente deve renovar o IP com o DHCP server
 T2: cliente deve renovar o ip com qualquer DHCP
server
 Lease time: cliente vai parar de usar o endereço IP

83. © 2009 by Almir Silveira 85
85
Fluxo de Mensagens de Renovação
Server A Client Server B
Cliente pede para continuar
usando o IP
DHCPREQUEST
Servidor Confirma o pedido
e as alocações atualizadas
DHCPACK
Cliente pede para continuar
usando o IP
DHCPREQUEST DHCPREQUEST
Servidor Confirma o pedido e
as alocações atualizadas
DHCPACK
Configuração completa
T1 transcorre
T1 transcorre
Cliente pede para continuar
usando o IP
DHCPREQUEST
T2 transcorre
Configuração completa

84. © 2009 by Almir Silveira 86
86
Retransmissões
Cliente é responsável por todas as retransmissões
Estratégia de Retransmissão
Exponencial backoff
Randomizado
Recomendações
Atraso Base é duplicado para cada retransmissão
Numero Randomico entre [-1,+1]
Atraso Base Máximo: 64 seconds

85. © 2009 by Almir Silveira 87
87
Servidor de Armazenamento
 Armazenamento Permanente
 Pool de endereços IP disponíveis
 Parâmetros locais de configuração
 Mapeamento entre clientes e alocações
 Flexibilidade sobre atualização de armazenamento
 Quando DHCPOFFER envia
 Quando DHCPACK envia

86. © 2009 by Almir Silveira 88
88
Server Logic (Simplificado)
Event Action Taken
DHCPDISCOVER If current lease for client exists, send DHCPOFFER
Else, if IP address available, send DHCPOFFER
Else, do nothing
DHCPREQUEST If IP address available, send DHCPACK
Else, send DHCPNAK
DHCPDECLINE Mark IP address unavailable, notify network administrator
DHCPRELEASE Mark IP address available, delete lease
DHCPINFORM Send DHCPACK with configuration parameters
Lease expiration Mark IP address available, delete lease

87. © 2009 by Almir Silveira 89
89
FORMATO DO DHCP PDU
Operation Code Hardware Type Hardware Length Hop Count
Transaction ID
Seconds Elapsed B Must Be Zero (MBZ)
Client IP address
Your IP address
Server IP address
Relay agent IP address
Client hardware address
(16 bytes)
Server host name
(64 bytes)
Boot file name
(128 bytes)
Options
(up to 312 bytes)
Magic Cookie

88. © 2009 by Almir Silveira 90
90
Opções do DHCP
255 End of options
Code Length Data
1 byte 1 byte Length bytes
0 Padding
1 4 255 255 255 0
Subnet Mask:
99 130 83 99
Magic Cookie:
Option format:
One-byte options:
4 bytes

89. © 2009 by Almir Silveira 91
91
Outra Rede Simples
Internet
Servidor DHCP
Clientes DHCP
Agente de
Retransmissão dentro
do roteador

90. © 2009 by Almir Silveira 92
92
Agentes de Retransmissão
 Remover a restrição de ter servidor DHCP em cada rede
 Escutar mensagens DHCP e transmiti-las para a máquina apropriada
 Retransmissão de Cliente para Servidor
 Broadcast do cliente Unicast para server(s)
 Retransmissão do Servidor para o cliente
 Broadcast do server  Broadcast para cliente
 Unicast do server  Unicast para client

91. © 2009 by Almir Silveira 93
93
DNS dinâmico
 Se o endereço IP muda devido ao DHCP, entrada DNS fica errada
 Clientes ou servidores podem atualizar o DNS
 Opção 81: Client FQDN
81 Length Flags rcode1 rcode2 Name…
1 byte 1 byte “Length” bytes

92. © 2009 by Almir Silveira 94
94
Reliabilitação
 Dois servidores DHCP sincronizados na mesma rede: Primario, Secundario
 Armazenamento constant
 Falhas: Servidor secundário assume
Server
secundário
Clientes DHCP
Server
Primario

93. © 2009 by Almir Silveira 95
95
Configurando DHCP
ddns-update-style interim;
ignore client-updates;
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.254;
option subnet-mask 255.255.255.0;
option domain-name "intranet2.com.br";
option domain-name-servers 192.168.0.254, 10.10.10.10;
range 192.168.0.60 192.168.0.100;
default-lease-time 21600;
max-lease-time 43200;
}

94. © 2009 by Almir Silveira 96
96
Exclude HOST
#------NOTEBOOK DIRETOR-----------
host diretor {
hardware ethernet 68:A3:C4:56:92:52;
fixed-address 192.168.1.244;
}
} # fechamento do DHCP

95. © 2009 by Almir Silveira 97
97
Resposta de um servidor DHCP
 DHCP “offer message”
 Parâmetros de configuração (proposed IP address, mask, gateway router,
DNS server, ...)
 Lease time (o tempo durante o qual esta informação é válida)
 A resposta pode vir de mais de que um servidor
 Protege contra um crash de um servidor único
 Os vários servidores respondem com uma oferta
 O cliente decide qual deve aceitar
 Aceitação de uma das ofertas
 O cliente envia uma mensagem DHCP com os parâmetros aceites
 O servidor confirma com um ACK
 … e os outros servidores verificam que não foram escolhidos

96. © 2009 by Almir Silveira 98
98
Soft State: Refresh or Forget
 Porque é necessário o “lease time”?
 O cliente pode libertar o endereço (DHCP RELEASE)
• Por exemplo “ipconfig /release” no DOS SHELL prompt
• Trata-se um shutdown ordeiro do computador
 Mas nem sempre isso acontece
• O host tem um crash
• ou o software do cliente tem bugs
 E o endereço ficaria afetado para sempre
 Performance trade-offs
 Pequeno “lease time”: os endereços inativos são rapidamente
devolvidos
 Longo “lease time”: evita frequentes renovações

97. © 2009 by Almir Silveira 99
99
F I M
OBRIGADO PELA PACIÊNCIA