Aula04 CamadaAplicacao

Prévia do material em texto

Redes de Computadores: 
Camada de Aplicação 
Luciana Andreia Fondazzi Martimiano 
Kalinka Castelo Branco (ICMC-USP) 
Roteiro 
 Princípios dos 
protocolos da camada 
de aplicação 
 HTTP (transferência de 
objetos na Web) 
 SMTP (e-mail) 
 DHCP (distribuição de 
IPs) 
 DNS (sistema de 
domínios) 
 
 Exemplo de aplicação 
com serviço orientado à 
conexão e não 
orientado à conexão 
Algumas aplicações de rede 
 E-mail 
 Web 
 Instant messaging 
 Login remoto 
 Compartilhamento de 
arquivos P2P 
 Jogos de rede multi-
usuários 
 Vídeo-clipes 
armazenados 
 
 
 Voz sobre IP 
 Vídeo conferência em 
tempo real 
 Computação paralela 
em larga escala 
 ... 
Criando uma aplicação de rede 
Programas que 
 Executam em diferentes sistemas 
finais 
 Comunicam-se através da rede 
 p.ex., Web: servidor Web se 
comunica com o navegador 
Programas não relacionados 
ao núcleo da rede 
 Dispositivos do núcleo da rede 
não executam aplicações de 
usuários 
 Aplicações nos sistemas finais 
permite rápido desenvolvimento e 
disseminação 
aplicação 
transporte 
rede 
enlace 
física 
aplicação 
transporte 
rede 
enlace 
física 
aplicação 
transporte 
rede 
enlace 
física 
Arquiteturas das aplicações 
Cliente-servidor 
 Peer-to-peer (P2P) 
Híbrido de cliente-servidor e P2P 
Arquiteturas das aplicações 
P2P pura 
 Não há servidor sempre 
ligado 
 Sistemas finais arbitrários 
se comunicam 
diretamente 
 Pares estão conectados 
intermitentemente e 
mudam endereços IP 
 Exemplo: Torrent 
 
Cliente-Servidor 
Servidor: 
 Sempre ligado 
 Endereço IP permanente 
 Escalabilidade com server farms 
Cliente: 
 Comunica-se com o servidor 
 Pode estar conectado 
intermitentemente 
 Pode ter endereços IP dinâmicos 
 Não se comunica diretamente 
com outros clientes 
Processos em comunicação 
Processo: programa que 
executa num hospedeiro 
 processos no mesmo 
hospedeiro se comunicam 
usando comunicação 
entre processos definida 
pelo sistema operacional 
(SO) 
 processos em 
hospedeiros distintos se 
comunicam trocando 
mensagens através da 
rede 
Processo cliente: 
processo que inicia a 
comunicação 
Processo servidor: 
processo que espera 
para ser contatado 
 
 
 
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 o 
número da porta associados 
ao processo no host  
SOCKET. 
 O identificador identifica 
unicamente o processo em 
um host 
 Exemplo de números de 
portas: 
 Servidor HTTP: 80 
 Servidor de Correio: 25 
 DHCP: 67 
 DNS: 53 
Endereçando os processos: 
Sockets 
processo 
TCP com 
Buffers e 
Variáveis, ou 
UDP 
socket 
host 
processo 
TCP com 
Buffers e 
Variáveis, ou 
UDP 
socket 
host 
Internet 
controlado 
pelo SO 
 
“controlado” pelo 
desenvolvedor da 
aplicação e gerenciado 
pelo SO 
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 
interoperabilidade 
 Ex.: HTTP, SMTP, 
DHCP, FTP, DNS, ... 
 
Protocolos proprietários: 
 Ex., Windows Media 
Player 
Web e HTTP 
Primeiro algum jargão 
 Páginas Web consistem de objetos 
 Objeto pode ser um arquivo HTML, uma imagem 
JPEG, um applet Java, um arquivo de áudio,… 
 Páginas Web consistem de um arquivo HTML base 
que inclui vários objetos referenciados 
 Cada objeto é endereçável por uma URL 
 Exemplo de URL: 
 www.someschool.edu/someDept/pic.gif 
nome do hospedeiro 
(domínio) 
nome do caminho 
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 2616 
 HTTP/2: RFC 7540 
PC executa 
Internet Explorer 
Servidor 
executando 
servidor 
WWW 
Mac executa 
Firefox 
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 são 
trocadas entre browser 
(cliente HTTP) e servidor Web 
(servidor HTTP) 
 encerra-se a conexão TCP 
HTTP é “sem estado” 
 servidor não mantém 
informação sobre 
pedidos anteriores do 
cliente 
Tipos de Conexões HTTP 
HTTP não persistente 
 No máximo um objeto é 
enviado numa conexão 
TCP 
 Cada objeto tem sua 
própria conexão TCP 
 Browser gerencia 
conexões paralelas (4 a 
8) 
 HTTP/1.0 usa modo 
não persistente 
HTTP persistente 
 Múltiplos objetos 
podem ser enviados 
sobre uma única 
conexão TCP entre 
cliente e servidor 
 HTTP/1.1 e 2 usam 
conexões persistentes 
e paralelas no seu 
modo default 
 Browser gerencia 
conexões paralelas 
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. 
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 
e referências à 10 
imagens JPEG) 
4. 
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 4 repetidos para 
cada um dos 10 objetos 
JPEG 
4. Processo servidor solicita 
encerramento da conexão 
TCP (apenas após cliente 
receber mensagem 
completa) 
tempo 
• Browser é responsável por apresentar a página ao usuário; 
• 11 conexões: cada objeto é enviado por uma conexão TCP; 
• Conexões podem ser em série ou paralelas (browser); 
HTTP persistente 
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 
 Servidor HTTP encerra 
conexão depois de um 
certo tempo de 
inatividade 
Persistente sem pipelining: 
 o cliente envia um novo 
pedido apenas quando a 
resposta anterior tiver sido 
recebida 
 cliente envia um pedido por 
vez 
Persistente com pipelining: 
 default no HTTP/1.1 e 
HTTP/2 
 o cliente envia os pedidos 
logo que encontraum objeto 
referenciado 
 cliente pode enviar vários 
pedidos em paralelo 
HTTP: 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 para um 
objeto: 
 um RTT para iniciar a 
conexão TCP 
 um RTT para o pedido 
HTTP e o retorno dos 
primeiros bytes da resposta 
HTTP 
Envio 
do objeto 
Conexão TCP 
RTT 
solicita 
objeto 
RTT 
objeto 
recebido 
tempo tempo 
HTTP: modelagem do tempo de 
resposta 
HTTP não persistente: 
 Requer 2 RTTs para cada objeto (estabelecer conexão 
e solicitar e receber o objeto) 
 SO aloca recursos (buffers, variáveis) no cliente e no 
servidor para cada conexão (TCP) 
HTTP persistente: 
 RTT para estabelecer conexão 
 Sem pipelining: um RTT para cada objeto referenciado 
 Com pipelining: pode ser necessário apenas um RTT 
para todos os objetos referenciados 
 SO aloca recursos (buffers, variáveis) no cliente e no 
servidor com vários objetos sendo transferidos 
mesma conexão (TCP) 
 
 
Mensagem HTTP 
 Dois tipos de mensagem HTTP: pedido, resposta 
 Formato padrão: HEADER + PAYLOAD 
 Mensagem de pedido HTTP 
Mensagem de pedido HTTP: Exemplo 
linha de requisição 
(comandos GET, 
POST, HEAD) 
linhas do 
cabeçalho 
Neste exemplo, 
o corpo da mensagem (payload) está vazio 
Alguns tipos de métodos 
HTTP/1.0 
 GET 
 POST 
 HEAD 
 Pede para o servidor não 
enviar o objeto requerido 
junto com a resposta 
(usado p/ debugging) 
 
HTTP/1.1 
 GET, POST, HEAD 
 PUT 
 Upload de arquivo contido 
no corpo da mensagem 
para o caminho 
especificado no campo 
URL 
 DELETE 
 Exclui arquivo especificado 
no campo URL 
Enviando conteúdo de formulário 
Método POST : 
 Conteúdo é enviado para 
o servidor no corpo da 
mensagem (campo 
Corpo da Entidade) 
 
Método GET: 
 Conteúdo é enviado para 
o servidor no campo URL: 
 
 
www.somesite.com/animalsearch?key=monkeys&max=10 
 
Mensagem de resposta HTTP: formato 
Mensagem de resposta HTTP: 
Exemplo 
linha de status 
linhas de cabeçalho 
Conteúdo (payload) 
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 
Exemplos de cabeçalhos HTTP 
HTTP/2 
 Baseado no protocolo SPDY/2 (do inglês 
“speedy") do Google 
Mantém a compatibilidade com HTTP 1.1: 
Métodos 
 Códigos de estado 
 URIs 
Maioria das linhas de cabeçalhos 
Mudança: como os objetos são encapsulados e 
enviados entre cliente e servidor 
Mensagem binária, ao invés de ASCII 
 Suporte à criptografia (SSL/TSL) 
HTTP/2 
Redução da latência e overhead: 
 Compressão do cabeçalho mandatória (Código de 
Huffman) 
Multiplexação (pipelining sem restrições FIFO – head-
of-line blocking); reduzindo o número de conexões 
TCP 
 Uso de streams: Fluxo de objetos bidirecional entre 
cliente e servidor 
 Priorização de solicitações (cliente pode priorizar 
frames) 
 Servidor envia objetos proativamente da página, antes 
que o cliente os solicite (caches) (Server Push) 
HTTP/2 
 Identificando a versão: 
 String “h2” identifica HTTP/2 com TLS/SSL 
 String “h2c” identifica HTTP/2 sem TLS/SSL 
 Solicitação do cliente deve conter no 
cabeçalho informação sobre versão do HTTP 
no servidor 
HTTP/2 
 Alguns tipos de mensagens (Frames): 
 HEADERS (utilizado para abrir fluxo – stream) 
 DATA (objetos associados a um fluxo) 
 SETTINGS (configurações da conexão; tamanho 
máximo da janela de fluxo ou do frame, por 
exemplo) 
Formato Padrão do Frame HTTP 
HTTP/2 
 Alguns tipos de mensagens (Frames): 
WINDOW_UPDATE (controle de fluxo) 
 PING: medir RTT do transmissor 
 PUSH_PROMISE (serviço de Server Push) 
GOAWAY: encerrar uma conexão ou sinalizar 
erros 
Formato Padrão do Frame HTTP 
HTTP/2 
Settings Frame 
HTTP/2 - Exemplos 
HTTP/2 - Exemplos 
Cookies: manutenção do 
“estado” da conexão 
Muitos dos principais sites 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 no servidor Web 
Cookies: manutenção do 
“estado” da conexão 
Cookies 
O que os cookies podem 
obter: 
 autorização automática 
 carrinhos de compra 
 sugestões 
 estado da sessão do 
usuário 
Cookies e privacidade: 
 cookies permitem que os 
sites aprendam muito sobre 
você 
 você pode fornecer nome e 
e-mail para os sites 
 mecanismos de busca usam 
redirecionamento e cookies 
para aprender ainda mais 
 agências de propaganda 
obtêm perfil a partir dos sites 
visitados 
Nota 
Cache Web (servidor proxy) 
 usuário configura browser: 
acessos Web via proxy 
 cliente envia todos pedidos 
HTTP ao proxy 
 se objeto está 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 dos 
dados 
Caches Web 
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 
 Melhora o desempenho das aplicações 
 A Internet cheia de caches permite que provedores 
de conteúdo “pobres” efetivamente forneçam 
conteúdo! 
 
 Proxy Web: atuam como cliente e servidor 
GET conditional 
 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 
SMTP: Serviço de correio 
eletrônico 
Três componentes principais: 
 agentes do usuário (Mail User 
Agent) 
 servidores de correio 
 Simple Mail Transfer Protocol: 
SMTP (RFC 5321) 
Agente do usuário 
 Redigir, editar, ler, salvar, 
retransmitir mensagens 
 Ex. Outlook Express, Pine (texto) 
SMTP: Serviço de correio 
eletrônico 
Servidores de correio 
 Caixa de correio contém 
mensagens que chegam para 
o usuário 
 Fila de mensagens com 
mensagens de correio a 
serem enviadas 
 Protocolo SMTP entre 
servidores de correio para 
enviar mensagens de e-mail 
 Provê o serviço de 
transferir as mensagens 
 cliente: servidor de envio 
de correio 
 “servidor”: servidor de 
recepção de correio 
SMTP: Serviço de correio 
eletrônico 
 Usa TCP para transferir de modo confiável a 
mensagem do cliente SMTP ao servidor SMTP, 
porta 25 (conexões seguras – portas 465 ou 587) 
 Transferência diretaentre cliente SMTP (servidor 
de envio) e servidor SMTP (servidor de recepção) 
 Três fases da transferência: 
 handshaking (saudação entre clientes e servidores 
SMTP) – endereços de e-mail do remetente e 
destinatário 
 transferência de mensagens 
 fechamento 
 
 
SMTP: Serviço de correio 
eletrônico 
 Interação comando/resposta 
 comandos: texto ASCII 
 resposta: código e frase de estado 
 Mensagens devem estar em ASCII de 7 bits 
(limitação) 
 
SMTP: Formato da mensagem de 
correio 
RFCs 822/5322/4021: padrões 
para formato de mensagem 
de texto: 
 Envelope: encapsula a 
mensagem com informações 
para envio 
 Cabeçalho da mensagem: 
 TO 
 CC (todos veem os 
destinatários) 
 BCC (destinatários são 
escondidos) 
 FROM 
 SENDER 
 RECEIVED 
 SUBJECT 
MIME: Multipurpose Internet Mail Extensions 
 Corpo: a “mensagem”, apenas em caracteres 
ASCII; 
Extensões MIME para multimídia, figuras, etc. 
(parâmetros para codificação/decodificação e 
tipo de conteúdo no cabeçalho) 
cabeçalho 
corpo 
linha 
em 
branco 
Envelope 
Cenário: Alice envia mensagem a Bob 
1) Alice usa AU para redigir e-mail 
de alice@crepes.fr para 
bob@hamburger.edu 
2) O AU de Alice envia e-mail ao 
seu servidor de correio, que é 
colocada na fila de e-mail 
3) Cliente do SMTP solicita 
conexão TCP com servidor de 
correio de Bob 
4) Cliente SMTP envia o e-mail 
de Alice pela conexão TCP (e 
solicita encerramento da 
conexão se for o caso) 
5) Servidor de correio de Bob 
coloca o e-mail na caixa de 
correio de Bob 
6) Bob chama seu agente do 
usuário para ler o e-mail 
 
Exemplo de interação SMTP 
(comandos do protocolo) 
 S: 220 hamburger.edu 
 C: HELO crepes.fr 
 S: 250 Hello crepes.fr, pleased to meet you 
 C: MAIL FROM: <alice@crepes.fr> 
 S: 250 alice@crepes.fr... Sender ok 
 C: RCPT TO: <bob@hamburger.edu> 
 S: 250 bob@hamburger.edu ... Recipient ok 
 C: DATA 
 S: 354 Enter mail, end with "." on a line by itself 
 C: Você gosta de ketchup? 
 C: Que tal picles? 
 C: . 
 S: 250 Message accepted for delivery 
 C: QUIT 
 S: 221 hamburger.edu closing connection 
SMTP 
 SMTP usa conexões 
persistentes 
 Servidor SMTP usa 
CRLF.CRLF para 
determinar fim da 
mensagem 
Comparação com HTTP: 
 HTTP: puxa (pull protocol) 
 SMTP: empurra (push 
protocol) 
 ambos têm interação de 
comando/resposta em 
ASCII, e códigos de estado 
 HTTP: cada objeto é 
encapsulado em sua própria 
mensagem de resposta 
 SMTP: múltiplos objetos 
enviados em uma única 
mensagem 
Protocolos de acesso de correio 
 SMTP: remessa/armazenamento no servidor do emissor 
 Protocolo de acesso ao correio: recuperação do servidor receptor 
 POP3: Post Office Protocol [RFC 1939] (TCP, portas 110 ou 
995 – conexões seguras) 
• autenticação, autorização e download 
 IMAP: Internet Mail Access Protocol [RFC 1730] (TCP, portas 
143 ou 993 – conexões seguras) 
• mais recursos (mais complexo) 
• manipulação de mensagens armazenadas no servidor 
 HTTP: via browser (TCP, portas 80 ou 443 - – conexões 
seguras) 
 
HTTP 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) 
 Sucessor (ou extensão) do protocolo BOOTP (mantém 
a compatibilidade) 
 Provê parâmetros de configuração (bindings) de 
endereço para hosts (bootstrappging) 
 Endereço IP (pelo menos) 
 Endereço de DNS 
 Endereço de Máscara de Rede 
 Endereço de Gateway Padrão 
 Utiliza arquitetura cliente/servidor (DHCP client e DCHP 
server) com UDP (cliente é responsável por timeout e 
retransmissões) 
 Cliente envia mensagem para o servidor para a porta 67 
 Servidor envia mensagem para o cliente para a porta 68 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) 
Dois componentes: 
 Protocolo para entrega dos parâmetros de 
configuração de endereço 
Mecanismos para alocação dos endereços 
O IP do cliente envia pacote para o endereço 
de broadcast para a rede para conseguir um 
endereço IP 
O servidor envia o endereço de duas formas: 
 Broadcasting 
 Utilizar informações da mensagem do cliente (MAC) 
 
 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) 
 Três estratégias para alocação de 
endereços: 
 Alocação Automática: IP permanente 
 Alocação Dinâmica: IP temporário (por um 
período de tempo, por exemplo); 
 Alocação Manual: Administrador atribui o IP e o 
DHCP apenas envia o número (lista pré-definida, 
por exemplo, com base no endereço MAC) 
 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) 
Garantias: 
 Unicidade no uso de um endereço IP em um 
determinado momento (tempo) 
 As configurações de endereço dos clientes em 
casos de reboot do cliente ou do servidor DHCP 
 Permitir configuração automática para novos 
clientes 
 Permitir configuração permanente para clientes 
específicos 
 
 
 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) - Mensagem 
op: tipo da mensagem (request 
ou reply) 
htype: tipo de endereço de 
hardware (ex.: Ethernet ou WiFi) 
hlen: tamanho do endereço MAC 
hops: incrementado pelo 
servidor DHCP caso este 
repasse a requisição para outra 
máquina (iniciado em zero pelo 
cliente) 
xid: identificação da transação 
(random) para associação entre 
cliente e servidor (request e 
reply) 
secs: tempos em segundos 
desde a solicitação de endereço 
 
 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) - Mensagem 
flags: controle das requisições e 
respostas (bit mais significativo é 
setado; demais em 0) 
ciaddr: endereço IP do cliente (caso o 
cliente saiba e quer outras 
informações) 
yiaddr: “seu” endereço IP (usado pelo 
servidor) 
siaddr: endereço IP do servidor (caso 
o cliente saiba) 
giaddr: endereço IP do roteador (caso 
o cliente saiba) 
chaddr: Endereço de hardware (MAC) 
do cliente 
sname: nome do servidor (opcional) 
file: nome do arquivo de boot 
options: parâmetros opcionais 
 
 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) - Mensagem 
Tipo de Mensagem Semântica 
DHCPDISCOVER Cliente envia broadcast para localizar servidores DHCP 
DHCPOFFER Servidor responde à mensagem DHCPDISCOVER com 
oferta de parâmetros de configuração de endereço 
DHCPREQUEST Cliente ou a) solicita parâmetros de um servidor e 
declina dos demais; ou b) confirma parâmetros 
previamente atribuídos após um reboot; ou c) estende 
atribuição de um endereço 
DHCPACK Servidor envia parâmetros de configuração de 
endereço, incluindo endereço IP 
DHCP: Dynamic Host Configuration 
Protocol (RFC 2131) - Mensagem 
Tipo de Mensagem Semântica 
DHCPNAK Servidor indica que o cliente não pode receber 
endereço (fora da sub-rede ou tempo expirado) 
DHCPDECLINE Cliente indica que endereço IP está em uso 
DHCPRELEASE Cliente renuncia a um endereço e cancela associação 
com o servidor 
DHCPINFORM Cliente solicita parâmetros de configuração local, pois já 
tem endereço externo 
DHCP: Dynamic 
Host Configuration 
Protocol (RFC 
2131) – Fluxo de 
Mensagens entre 
cliente e servidor 
DNS: Domain Name System 
hosts, roteadores Internet: 
 endereço IP (32 bit) - 
usado p/ endereçar 
pacotes 
 “nome”, ex., din.uem.br- 
usado por pessoas 
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 hosts, roteadores, 
servidores de nomes se 
comuniquem para resolver nomes 
(tradução endereço IP/nome) 
 função imprescindível da 
Internet 
 complexidade na borda da rede 
DNS: Domain Name System 
 Roda sobre UDP e usa 
a porta 53 
 Especificado nas RFCs 
1034 e 1035 e 
atualizado em outras 
RFCs (2136) 
 Outros serviços: 
 apelidos para hosts 
(aliasing) 
 apelido para 
servidores de emails 
 distribuição da carga 
– vários servidores 
DNS 
Servidores de nomes DNS 
 Nenhum servidor mantém todos os mapeamentos nome - 
endereço IP 
 Três classes de servidores DNS: árvore hierárquica 
 Servidores raiz (13 – A ao M; com replicações) 
 Servidores de alto nível (Top Level Domain) 
• Genéricos (gTLD): .com; .edu; .gov; .pro; . mil; . xxx 
• Países (ccTLD): .br; .uk; .jp. nl. (a partir de 2010, países 
com alfabetos não baseados no Latim foram incluídos) 
 Servidores com autoridade 
• Mantidos por empresas, universidades, órgãos públicos 
• Ex.: uem.br; uol.com.br; google.com.br 
 Servidores DNS locais (subdomínios) 
 din.uem.br 
13 Servidores raiz 
13 Servidores raiz 
FONTE: https://www.iana.org/domains/root/servers 
DNS – parte do espaço de nomes 
http://www.nic.br/atividades/gtlds.htm 
Servidores de nomes DNS 
 Algumas regras: 
 Nomes de domínios não são case sensitive 
(DIN.UEM.BR e din.uem.br são o mesmo 
domínio) 
 Nomes de domínios podem ter até 65 caracteres 
 Caminho dos nomes de domínios podem ter até 
255 caracteres 
 
Servidores de nomes DNS 
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 muito cara 
 
Não é escalável! 
Registros de Recursos 
 Tupla de cinco campos: 
 Domain_name (chave de pesquisa para atender 
consultas) 
 Time_to_Live (estabilidade do registro; importante 
para cache do DNS) 
 Class (IN, para Internet) (opcional) 
 Type 
 Value (depende do tipo (type) do registro) 
Registros de Recursos 
Alguns tipos de registros 
Registros de Recursos 
DIN - Registros de Recursos 
; din.uem.br.db 
$TTL 7200 (campos de inteiros de 32 bits) 
; Zona 
din.uem.br. IN SOA ns1.din.uem.br. root.din.uem.br. ( 
 2012031634 (serial) 
 4800 (refresh; tempo em segundos antes da zona ser 
atualizada) 
 200 (retry: tempo em segundos que deve decorrer antes de 
uma atualização) 
 90180 (expire: tempo em segundos que deve decorrer antes da 
zona ser dada como não mais existente) 
 7200 (ttl: tempo em segundos para cache antes de 
atualização) 
 ) 
 
 
 
 
 
 
 
 
 
 
 
Registros de Recursos 
 Autoridades registradoras 
 ICANN (Internet Corporation for Assigned Names 
and Numbers) 
 Brasilregistro.br 
 Atualizações dinâmicas 
 
DNS: protocolo e mensagens 
protocolo DNS: mensagens de consulta e resposta, 
ambas com o mesmo formato 
DNS: protocolo e mensagens 
Cabeçalho: 
 identificação: ID de 16 bits para pedido; resposta 
usa mesmo ID 
 flags: 
 pedido ou resposta 
 recursão desejada 
 recursão permitida 
 resposta é de um servidor de autoridade 
Uma consulta DNS 
Host cis.poly.edu quer o 
endereço IP para 
gaia.cs.umass.edu 
 
TLD – top-level domain 
(.com, .org, .edu, 
países, etc. 
DNS: consultas interativas 
a) consulta recursiva: 
 transfere a 
responsabilidade de 
resolução do nome 
para o servidor de 
nomes contatado 
b) consulta iterativa: 
 servidor consultado 
responde com o nome 
de um servidor de 
contato 
 “Não conheço este 
nome, mas pergunte 
para este servidor” 
a) 
b) 
b) 
.edu 
DNS: uso de cache, atualização de dados 
 Uma vez que um servidor qualquer aprende um 
mapeamento, ele o coloca em uma 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) 
ttl = time to live (sobrevida) 
 Mecanismos de atualização/notificação dos dados 
(IETF ) 
 RFC 2136 
 http://www.ietf.org/html.charters/dnsind-charter.html 
DNS reverso 
 A resolução reversa de DNS é o processo 
responsável por determinar um nome de 
domínio que é associado com um endereço 
IP, através do protocolo DNS 
 A resolução reversa é importante, pois 
alguns serviços de Internet checam se esta 
configuração está correta, rejeitando as 
consultas para as quais esse mapeamento 
falha 
DNS reverso 
 A base do DNS reverso consiste do 
TLD Address and Routing Parameter 
Area (arpa) 
 IPv4 utiliza o pseudo-domínio in-addr.arpa 
 IPv6 utiliza o pseudo-domínio ip6.arpa 
O processo de resolução reversa é idêntica à 
resolução direta, porém com o uso do 
registro PTR (e não CNAME/A/AAAA) 
O registro PTR, ou apontador de domínio (domain 
pointer), é o registro responsável por mapear um 
IP em um nome 
 
Cliente deve contactar servidor 
 processo servidor deve antes 
estar em execução 
 servidor deve antes ter criado 
socket (porta) que aguarda 
contato do cliente 
Cliente contacta servidor para: 
 criar socket TCP local ao 
cliente 
 especificar endereço IP, 
número de porta do processo 
servidor 
 Quando cliente cria socket: TCP do 
cliente estabelece conexão com 
TCP do servidor 
 Quando contatado pelo cliente, o 
TCP do servidor cria socket novo 
para que o processo servidor possa 
se comunicar com o cliente 
 permite que o servidor converse 
com múltiplos clientes 
TCP provê transferência 
confiável, ordenada de bytes 
(“tubo”) entre cliente e servidor 
ponto de vista da aplicação 
Programação com sockets usando 
TCP 
Programação com sockets usando 
TCP 
Programação com sockets usando 
TCP 
1. cliente lê linha da entrada 
padrão (fluxo doUsuário), 
envia para servidor via socket 
(fluxo paraServidor) 
2. servidor lê linha do socket 
3. servidor converte linha para 
letras maiúsculas, devolve 
para o cliente 
4. cliente lê linha modificada do 
socket (fluxo doServidor), 
imprime-a 
Fluxo de entrada: sequência 
de bytes recebida pelo 
processo 
Fluxo de saída: sequência de 
bytes transmitida pelo 
processo 
 
Objetivo: servidor 
converte todas as 
letras digitadas pelo 
cliente para 
maiúsculas (mostra no 
monitor) 
Programação com sockets usando 
TCP 
Exemplo: cliente Java (TCP) 
import java.io.*; 
import java.net.*; 
class ClienteTCP { 
 
 public static void main(String argv[]) throws Exception 
 { 
 String frase; 
 String fraseModificada; 
 
 BufferedReader doUsuario = 
 new BufferedReader(new InputStreamReader(System.in)); 
 
 Socket socketCliente = new Socket(“hostname”, 6789); 
 
 DataOutputStream paraServidor = 
 new DataOutputStream(socketCliente.getOutputStream()); 
 
 
Cria 
fluxo de entrada 
padrão 
Cria 
socket de cliente, 
conexão ao servidor 
Cria 
fluxo de saída 
ligado ao socket 
Contém classes 
para Streams IO 
Contém classes para 
suporte à rede 
Exemplo: cliente Java (TCP), cont. 
 BufferedReader doServidor = 
 new BufferedReader(new 
 InputStreamReader(socketCliente.getInputStream())); 
 
 frase = doUsuario.readLine();paraServidor.writeBytes(frase + '\n'); 
 
 fraseModificada = doServidor.readLine(); 
 
 System.out.println(”Do Servidor: " + fraseModificada); 
 
 socketCliente.close(); 
 
 } 
} 
Cria 
fluxo de entrada 
ligado ao socket 
Envia linha 
ao servidor 
Lê linha 
do servidor 
Exemplo: servidor Java (TCP) 
import java.io.*; 
import java.net.*; 
 
class servidorTCP { 
 
 public static void main(String argv[]) throws Exception 
 { 
 String fraseCliente; 
 String fraseMaiusculas; 
 
 ServerSocket socketRecepcao = new ServerSocket(6789); 
 
 while(true) { 
 
 Socket socketConexao = socketRecepcao.accept(); 
 
 BufferedReader doCliente = 
 new BufferedReader(new 
 InputStreamReader(socketConexao.getInputStream())); 
 
 
Cria socket 
para recepção 
na porta 6789 
Aguarda, no socket 
de recepção, o 
contato do cliente 
Cria fluxo de 
entrada, ligado 
ao socket 
Contém classes 
para Streams IO 
Contém classes para 
suporte à rede 
Exemplo: servidor Java (TCP), cont 
 
 
 DataOutputStream paraCliente = 
 new DataOutputStream(socketConexão.getOutputStream()); 
 
 fraseCliente= doCliente.readLine(); 
 
 fraseEmMaiusculas= fraseCliente.toUpperCase() + '\n'; 
 
 paraClient.writeBytes(fraseEmMaiusculas); 
 } 
 } 
} 
 
Lê linha 
do socket 
Cria fluxo 
de saída, ligado 
ao socket 
Escreve linha 
ao socket 
Final do laço while, 
volta ao início e aguarda 
conexão de outro cliente 
Exercícios Sugeridos e Seções para 
leitura 
 Kurose & Ross, Redes de Computadores e a 
Internet, 5ª ed., 2010. Cap. 02 
 Questões de Revisão: 1, 2, 3, 5 a 8, 10 a 19, 27 e 
28 
 Problemas: 1 a 5, 10, 11, 13 a 15, 18, 20, 21. 
 Seções: 2.1, 2.2, 2.4, 2.5, 2.7 e 2.8; parte da 
seção 4.4.2 (DHCP) 
 
Bibliografia 
 Tanenbaum & Wetherall, Redes de Computadores, 5ª 
ed., 2011. Cap. 07 
 Kurose & Ross, Redes de Computadores e a Internet, 
5ª ed., 2010. Cap. 02 
 RFC 7540 – HTTP/2: https://tools.ietf.org/html/rfc7540 
 Comer, D. E, Interligação de Redes com TCP/IP: 
princípios, protocolos e arquitetura. Ed. Campus. Vol. 
1. 2006. Cap. 22 
 http://www.pop-ba.rnp.br/Site/DNSReversoIPv6 
 http://root-servers.org/ 
 https://www.iana.org/ 
 https://www.icann.org/ 
 http://www.lacnic.net/pt/web/lacnic/inicio