Depuração de Redes

Prévia do material em texto

Fundamentos e depuração de redes de
computadores
Você aprenderá a analisar e depurar protocolos de rede, como HTTP, DHCP, TCP, UDP, Telnet, FTP, SMTP,
DNS, ICMP, IP, Ethernet e ARP, utilizando softwares como Wireshark e Tcpdump, através de experimentos
práticos.
Prof.Guilherme Dutra Gonzaga Jaime
1. Itens iniciais
Propósito
O conhecimento sobre análise e depuração de protocolos de rede é crucial para profissionais de TI, pois
permite identificar e resolver problemas de comunicação em redes, garantindo a eficiência e segurança dos
sistemas. Isso é essencial para a manutenção e otimização de redes corporativas.
Objetivos
Aplicar conceitos de modelos de camadas para depurar protocolos HTTP e DHCP, juntamente com TCP
e UDP.
 
Analisar aplicações Telnet, SMTP, FTP e DNS utilizando modelos de camadas.
 
Depurar o protocolo ICMP e a aplicação traceroute com Tcpdump.
 
Aplicar a depuração do protocolo ARP para repasse de pacotes dentro e fora da rede do remetente.
Introdução
Neste conteúdo, você aprenderá a analisar protocolos de camada de aplicação, como HTTP e DHCP, através
de experimentos práticos. Para a análise de cada um desses protocolos, será usado o software Wireshark.
Com ele, capturaremos PDUs (Packet Data Units) de cada um dos protocolos de aplicação citados e
realizaremos uma depuração passo a passo do significado de cada PDU, bem como de sua relação com os
comandos dados pelos usuários/clientes. Também analisaremos protocolos de camada de transporte (TCP e
UDP) e sua relação com os protocolos de aplicação estudados (HTTP e DHCP).
 
Você aprenderá a analisar protocolos de camada de aplicação como Telnet, FTP, SMTP e DNS através de
experimentos práticos. Para a análise de cada um desses protocolos, será usado o software Wireshark. Com
ele, capturaremos PDUs (packet data units) de cada um dos protocolos de aplicação citados e realizaremos
uma depuração passo a passo do significado de cada PDU, bem como de sua relação com os comandos
dados pelos usuários/clientes.
 
Aplicaremos o conceito de modelagem em camadas de redes para estudarmos a análise e depuração de
protocolos da camada de rede, como ICMP. Estudaremos o funcionamento do encapsulamento IP. Para a
análise de cada um desses protocolos, será usado o software Tcpdump. Com ele, capturaremos PDUs (packet
data units) ICMP e realizaremos uma depuração passo a passo do significado de cada PDU, bem como de sua
relação com os comandos dados pelos usuários/clientes. Por fim, faremos um estudo de caso com o aplicativo
traceroute.
 
Aplicaremos o conceito de modelagem em camadas de redes para estudarmos a análise e depuração do
processo de repasse de pacotes da camada de rede, juntamente com os protocolos de camada de enlace
necessários para que o repasse da camada de rede funcione. Para a análise de cada um dos protocolos, será
usado o software Wireshark. Com ele, capturaremos PDUs (packet data units), IP, Ethernet e ARP (Address
Resolution Protocol), e realizaremos uma depuração passo a passo do significado de cada PDU, bem como de
sua relação com o processo de repasse de pacotes para um destino localizado na mesma rede que o
remetente e para um destino localizado em uma rede diferente da rede do remetente.
• 
• 
• 
• 
1. Estudo de protocolos das camadas de aplicação e de transporte - Parte 1
Camada de aplicação
A camada de aplicação é responsável por prover serviços que efetivamente interessam aos usuários.
Incontáveis aplicações estão disponíveis para os usuários e diversas são desenvolvidas todos os dias.
 
Antes de entrarmos nos detalhes deste conteúdo, precisamos recordar brevemente o modelo de camadas
para você relembrar que a camada de aplicação roda apenas nos sistemas finais da rede. Ela trata, portanto,
da troca de mensagens entre aplicativos que rodam nos sistemas finais, conforme mostrado no esquema
abaixo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Vamos, então, abordar quatro aplicações muito populares:
 
Web.
 
Transferência.
 
Correio.
 
Terminal remoto e a configuração de arquivos eletrōnico automática de endereços IP.
Protocolo de comunicação
• 
• 
• 
• 
Qualquer aplicação que deseja prover serviços através de uma rede de dados deve, necessariamente, definir
um conjunto de regras que irão reger a comunicação entre os aplicativos. A esse conjunto de regras damos o
nome de protocolo de comunicação.
 
Esse protocolo define não só o formato de cada tipo de mensagem a ser trocada entre os pares, mas também
que atitude cada entidade deve tomar quando ocorre um evento, como um comando do usuário ou mesmo a
chegada de uma mensagem.
 
Note que a camada de aplicação não se preocupa (e nem deve, segundo o modelo de camadas) com toda a
complexidade da rede, conforme mostrado na imagem abaixo, no exemplo para a aplicação Web.
Comentário
O objetivo primordial é que um lado (por exemplo, cliente) seja capaz de enviar comandos ao outro par
(servidor), de modo que o servidor compreenda o que o cliente deseja e possa tomar as ações
necessárias para executar a solicitação do cliente e enviar respostas com os resultados (ou mensagens
de erro). 
Você pode observar essa relação na imagem abaixo:
A complexidade da infraestrutura da rede é invisível aos olhos da camada de aplicação. Então, para cada
aplicação bem conhecida da internet, há um protocolo.
 
A tabela abaixo lista os protocolos de camada de aplicação usados para cada uma das aplicações mais
conhecidas da internet a serem abordadas neste conteúdo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Veja o que significa HTTP e RFC: 
Hyper Text Transfer Protocol (HTTP)
Protocolo padrão para navegação Web da Internet.
Request For Comments (RFC)
Documentos de domínio público que definem cada padrão/protocolo usado pela internet. Esses
documentos estão gratuitamente disponíveis na Internet.
HTTP
O HTTP — Protocolo de Transferência de Hipertexto (HyperText Transfer Protocol) —, protocolo da camada
de aplicação da Web, está no coração da Web e é definido no [RFC 1945] e no [RFC 2616]. Ele é executado
em dois aplicativos/programas: um cliente e outro servidor. Os dois, tipicamente executados em sistemas
finais diferentes, conversam entre si por meio da troca de mensagens HTTP.
É importante ressaltar que o HTTP define a estrutura dessas mensagens e o modo como o cliente e
o servidor as trocam.
Antes de explicarmos em detalhes o HTTP, devemos revisar a terminologia da Web:
 
Uma página Web (também denominada documento) é constituída de objetos.
 
Um objeto é apenas um arquivo — tal como um arquivo HTML, uma imagem JPEG, um applet Java, ou
um clipe de vídeo — que se pode acessar com um único URL ― Uniform Resource Locator (Localizador
Padrão de Recursos).
 
Um URL pode ser entendido como o endereço de um recurso disponível em uma rede. A maioria das
páginas Web é constituída de um arquivo-base HTML e diversos objetos referenciados. Por exemplo,
se uma página contiver um texto HTML e cinco imagens JPEG, ela terá seis objetos: o arquivo-base
HTML e mais as cinco imagens.
 
O arquivo-base HTML referencia os outros objetos na página com os URLs dos objetos.
 
Cada URL tem dois componentes:
 
1. O nome de hospedeiro (hostname) do servidor que abriga o objeto.
 
2. O nome do caminho do objeto.
 
Por exemplo, no URL: //info.cern.ch/hypertext/WWW/TheProject.html
info.cern.ch é o nome de hospedeiro e /hypertext/WWW/TheProject.html é o nome do caminho. 
• 
• 
• 
• 
 
Veja na imagem abaixo:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Navegadores Web (como Chrome, Firefox, Safari e Edge) executam no host do cliente. Os servidores Web, que
executam o lado servidor do HTTP, abrigam objetos Web, cada um endereçado por um URL.
 
Dados de 2014 mostram que o Apache é o servidor HTTP mais usado do mundo, seguido pelo Microsoft
Internet Information 
Apresentação de três vias
Considere, agora, o que aconteceroteador lê a coluna “Ender. de
Gateway” (C), apontada pela rota (D). No caso em questão, o valor é “No vínculo”.
Isso quer dizer que o destino se encontra na própria rede do remetente. Portanto, o pacote destinado ao IP
(10.0.2.3) pode ser encapsulado em um quadro da camada de enlace que será entregue diretamente à
interface de rede do destino.
Esse quadro terá que ter o endereço MAC da interface de rede de 10.0.2.3 preenchido no campo de cabeçalho
End. Mac Destino.
 
Qual é o endereço MAC de destino que o S.O. deve preencher no cabeçalho do quadro de camada de enlace a
ser gerado?
Agora o S.O. tem um novo problema em mãos, mas, em princípio, ele não sabe essa resposta. Então, ele usa o
protocolo ARP (Address Resolution Protocol, Protocolo de Resolução de Endereço) para enviar uma consulta
ARP a todas as interfaces da LAN perguntando qual é o endereço MAC da interface de rede que está
configurada com o endereço IP 10.0.2.3. Essa solicitação é denominada consulta ARP (ARP Request),
conforme indicado na imagem seguinte.
Nessa imagem vemos o pacote de Número 1, em destaque, capturado pelo Wireshark, mostra a consulta ARP
enviada pelo host 10.0.2.15 no exemplo em questão.
• 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Host 10.0.2.15 envia consulta ARP a todas as interfaces da LAN.
Na parte inferior da imagem, é possível depurar a consulta ARP, extraindo todas as informações necessárias
para entendermos o que se passa. 
 
Veja a seguir.
Cabeçalhos Ethernet (Camada de enlace)
O campo Type preenchido com o valor 0x806 informa ao receptor que este quadro carrega uma mensagem
do protocolo ARP. Assim, ao receber este quadro e notar que o campo Tipo está preenchido com o valor
0x806, o receptor sabe que deve entregar o conteúdo do quadro do processo ARP do receptor.
O Campo Destination está preenchido com o valor ff:ff:ff:ff:ff:ff, o que quer dizer que este quadro é destinado
a todas as interfaces de rede da LAN. Ou seja, é um quadro de difusão (broadcast).
Cabeçalhos ARP
Opcode=1: O Valor 1 no campo OPcode indica que essa é uma requisição ARP (solicitação de mapeamento IP-
>MAC).
 
Sender IP address=10.0.2.15 e Sender Mac address=08:00:27:83:5b:c1: Esses campos indicam o End. MAC e
End. IP do host solicitante.
 
Target IP Address=10.0.2.3: Esse campo indica qual é o endereço IP que a consulta ARP deseja mapear em
endereço MAC. Ou seja, deseja-se saber qual é o endereço MAC da interface de rede que está configurada
com o IP 10.0.2.3.
 
Todas as interfaces de rede da LAN ao qual o host solicitante pertence receberão e processarão essa
consulta ARP. Entretanto, somente o host configurado com o endereço IP 10.0.2.3 enviará uma resposta ARP
(ARP Reply), conforme ilustrado pelo pacote de número 2, capturado usando o software Wireshark,
apresentado em detalhes na imagem, a seguir.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Detalhes da resposta ARP enviada pelo host 10.0.2.3.
Na parte inferior da imagem, é possível depurar a resposta ARP, extraindo todas as informações necessárias
para entendermos o que se passa. 
 
Veja a seguir.
Cabeçalhos Ethernet (Camada de enlace)
O campo Type preenchido com o valor 0x806 informa ao receptor que este quadro carrega uma mensagem
do protocolo ARP. Assim, ao receber este quadro e notar que o campo Tipo está preenchido com o valor
0x806, o receptor da resposta ARP sabe que deve entregar o conteúdo do quadro do processo ARP.
O Campo Destination está preenchido com o valor 08:00:27:83:5b:c1, o que quer dizer que este quadro é
destinado especificamente à interface de rede do host que transmitiu a consulta ARP.
Cabeçalhos ARP
Opcode=2: O Valor 2 no campo OPcode indica que essa é uma resposta ARP (ARP Reply), que contém o
mapeamento IP->MAC solicitado.
 
Sender IP address=10.0.2.3 e Sender Mac address=52:54:00:12:35:03: Esses campos indicam o End. MAC e
End. IP do host que gerou essa resposta ARP. Esses são os campos que permitem ao receptor da resposta
ARP aprender qual é o endereço MAC da interface de rede configurada com o IP 10.0.2.3.
 
Target IP Address=10.0.2.15: Esse campo indica o end. IP e o end. MAC do host ao qual essa resposta ARP é
destinada.
 
Ao receber essa resposta ARP, o host 10.0.2.15 realiza a leitura dos campos do quadro, conforme fizemos
acima e registra o mapeamento IP->MAC em sua tabela ARP. Observe a seguir:
 Tabela ARP em 10.0.2.15 contendo o mapeamento IPMAC informado pela
resposta ARP.
Saiba mais
O comando “arp –a” pode ser usado em qualquer host Windows para listar a tabela ARP local. Na
implementação da tabela ARP do S.O. Windows 7, 8 e 10, o tempo em que o mapeamento IPMAC fica
registrado na tabela ARP é de cerca de 15 a 45 segundos. Se um mapeamento IPMAC não for usado
por um tempo maior do que esse, então, o mapeamento é removido da tabela, e o host terá que enviar
outra consulta ARP se desejar enviar pacotes ao end. IP em questão. 
Após registrar o mapeamento IPMAC em sua tabela ARP, o host está finalmente pronto para encapsular o
pacote destinado a 10.0.2.3 em um quadro da camada de enlace destinado a 52:54:00:12:35:03, e transmitir o
quadro para a LAN, conforme ilustrado pelo pacote de número 3 capturado pelo Wireshark na imagem
seguinte.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Finalmente um pacote de dados (ping, em nosso exemplo) é enviado de 10.0.2.15
diretamente para 10.0.2.3
Note que na Figura 6 os pacotes de número 3, 5, 7 e 9 são pacotes ping enviados por 10.0.2.15 e destinados a
10.0.2.3. Esses pacotes estão encapsulados em quadros da camada de enlace destinados a
52:54:00:12:35:03.
 
Por fim, os pacotes 4, 6, 8 e 10 são pacotes ping reply enviados pelo host 10.0.2.3 e destinados ao host
10.0.2.15. Ao receber essas respostas ping, o aplicativo ping finalmente mostra o resultado de sua execução
ao usuário, conforme ilustrado a seguir.
 
Note que o comando “arp –d” foi dado antes de “ping 10.0.2.3” para que a tabela ARP do host fosse apagada.
Com isso, garantimos que o mapeamento IPMAC necessário não estaria presente na tabela ARP, e uma
consulta ARP teria que ser necessariamente gerada.
Após todo o processo que depuramos, o aplicativo ping apresenta seus resultados
ao usuário.
Depuração do protocolo ARP para repasse de pacotes -
redes distintas
O segundo objetivo deste estudo consiste em depurar a interação entre a camada de rede e a camada de
enlace, e seus respectivos protocolos em um cenário como o descrito na imagem seguinte, onde o host
10.0.2.15 deseja enviar um pacote (exemplo ping) destinado ao host 8.8.8.8, que NÃO está localizado na
mesma rede IP que o remetente.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Primeiro cenário proposto – Envio de pacote para destino na mesma rede.
Veja, a seguir, como acontece esse processo.
1. Ao gerar um pacote, a aplicação informa ao S.O. que o endereço IP destino do pacote é 8.8.8.8.
2. A camada de rede, localizada no S.O., deve olhar para a tabela de roteamento (Figura 9) para consultar se
alguma de suas rotas (linhas) gerará um match (equivalência) com o endereço de destino do pacote.
3. O S.O. do host cliente tentará encontrar um match (explicado em detalhes logo abaixo) para todas as rotas
(linhas) da tabela de roteamento. Entretanto, em nosso exemplo, a única rota que gerará um match com o
endereço IP de destino do pacote (8.8.8.8) é a rota para a rede 0.0.0.0 (D) (Figura 9).
4. A máscara (B) 0.0.0.0 para a rota (D) 0.0.0.0, também é vista como uma instrução de como realizar a
comparação entre o endereço IP de destino do pacote e o endereço de rede da rota, com o objetivo de testar
se há um match.
 
Veja, a seguir, como é feita a tentativa de obter um match.
 
1. O roteador realiza um AND Lógico bit-a-bit entre o endereço IP de destino do pacote (8.8.8.8) e a máscara
da rota que está sendo testada (0.0.0.0). 
 
Veja na imagem abaixo.Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
A rota 0.0.0.0 é uma rota muito especial, e é chamada de rota default, ou rota padrão. Essa rota é
automaticamente criada quando o administrador configura um endereço IP de default gateway (gateway
padrão) no host. Em nosso exemplo, o host do remente foi configurado com default gateway=10.0.2.2.
 
Para entender porque a rota padrão é especial, repare novamente, na Figura 9, na máscara (B) da rede
destino. A máscara possui valor 0.0.0.0.
Como todos os bits da máscara são iguais a zero, o resultado do AND Lógico bit-a-bit sempre dará 0.0.0.0
seja qual for o endereço IP de destino de um pacote. Ou seja, qualquer endereço IP destino de um pacote
SEMPRE gerará um match com a rota default.
 
A intuição é a seguinte: Se a consulta à tabela de roteamento não gerou match para nenhuma rota, dado o
end. IP de destino de um pacote, então a rota default será usada.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Tabela de Roteamento do host 10.0.2.15 - Rota Default em destaque
2. O roteador compara o resultado obtido (0.0.0.0) com o endereço de rede destino 0.0.0.0 (D) da rota que
está sendo testada na tabela de roteamento.
 
3. O roteador percebe que ambos são iguais, ou seja,
ocorreu um match. Então, o roteador lê a coluna “Ender.
de Gateway” (C), apontada pela rota (D). No caso em
questão, o valor é “10.0.2.2”.
Isso quer dizer que o destino NÃO se encontra na mesma
rede do remetente. Portanto, o pacote destinado ao IP
(8.8.8.8) deve ser encapsulado em um quadro da camada
de enlace que será entregue à interface 10.0.2.2 do
roteador.
 
Esse quadro terá que ter o endereço MAC 52:54:00:12:35:02 da interface de rede do roteador que liga a LAN
do host remetente ao restante do mundo. Podemos citar como exemplo a Internet.
Qual é o endereço MAC de destino que o S.O. deve preencher no cabeçalho do quadro de camada
de enlace a ser gerado?
Agora, o S.O. tem um novo problema em mãos, mas, em princípio, ele não sabe essa resposta. Então, ele usa o
protocolo ARP (Address Resolution Protocol, Protocolo de Resolução de Endereço) para enviar uma consulta
ARP a todas as interfaces da LAN perguntando qual é o endereço MAC da interface de rede que está
configurada com o endereço IP 10.0.2.2.
 
Essa solicitação é denominada consulta ARP (ARP Request), conforme indicado na imagem seguinte.
 
Nela, vemos o pacote de Número 1 em destaque, capturado pelo Wireshark, mostra a consulta ARP enviada
pelo host 10.0.2.15 no exemplo em questão.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Host 10.0.2.15 envia consulta ARP a todas as interfaces da LAN.
Na parte inferior da imagem, é possível depurar a consulta ARP, extraindo todas as informações necessárias
para entendermos o que se passa. Veja a seguir.
Cabeçalhos Ethernet (Camada de enlace)
O campo Type preenchido com o valor 0x806 informa ao receptor que este quadro carrega uma mensagem
do protocolo ARP. Assim, ao receber este quadro e notar que o campo Tipo está preenchido com o valor
0x806, o receptor sabe que deve entregar o conteúdo do quadro do processo ARP do receptor.
Comentário
O Campo Destination está preenchido com o valor ff:ff:ff:ff:ff:ff, o que quer dizer que este quadro é
destinado a todas as interfaces de rede da LAN. Ou seja, é um quadro de difusão (broadcast). 
Cabeçalhos ARP
Opcode=1
O Valor 1 no campo OPcode indica que essa é uma requisição ARP (solicitação de mapeamento IP-
>MAC).
Sender IP address=10.0.2.15 e Sender Mac address=08:00:27:83:5b:c1
Esses campos indicam o End. MAC e End. IP do host solicitante.
Target IP Address=10.0.2.2
Este campo indica qual é o endereço IP que a consulta ARP deseja mapear em endereço MAC. Ou
seja, deseja-se saber qual é o endereço MAC da interface de rede do roteador configurada com
endereço IP 10.0.2.2. Esse será o próximo salto (next hop) do pacote destinado a 8.8.8.8.
Todas as interfaces de rede da LAN ao qual o host solicitante pertence receberão e processarão essa
consulta ARP. Entretanto, somente o host configurado com o endereço IP 10.0.2.2 enviará uma resposta ARP
(ARP Reply), conforme ilustrado pelo pacote de número 2, capturado usando o software Wireshark,
apresentado em detalhes na imagem seguinte.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Detalhes da resposta ARP enviada pelo roteador
Na parte inferior da imagem, é possível depurar a resposta ARP, extraindo todas as informações necessárias
para entendermos o que se passa. Veja a seguir.
Cabeçalhos Ethernet (Camada de enlace)
O campo Type preenchido com o valor 0x806 informa ao receptor que esse quadro carrega uma mensagem
do protocolo ARP. Assim, ao receber esse quadro e notar que o campo Tipo está preenchido com o valor
0x806, o receptor da resposta ARP sabe que deve entregar o conteúdo do quadro do processo ARP.
Comentário
O Campo Destination está preenchido com o valor 08:00:27:83:5b:c1, o que quer dizer que esse quadro
é destinado especificamente à interface de rede do host que transmitiu a consulta ARP. 
Cabeçalhos ARP
Opcode=2: O Valor 2 no campo OPcode indica que essa é uma resposta ARP (ARP Reply), que contém o
mapeamento IP->MAC solicitado.
 
Sender IP address=10.0.2.2 e Sender Mac address=52:54:00:12:35:02: Estes campos indicam o End. MAC e
End. IP do host que gerou essa resposta ARP. Esses são os campos que permitem ao receptor da resposta
ARP aprender qual é o endereço MAC da interface de rede configurada com o IP 10.0.2.2.
 
Target IP Address=10.0.2.15: Este campo indica o end. IP e o end. MAC do host ao qual essa resposta ARP é
destinada.
Ao receber essa resposta ARP, o host 10.0.2.15 realiza a leitura dos cabeçalhos do quadro, conforme fizemos
acima, e registra o mapeamento IP->MAC em sua tabela ARP. O comando “arp –a” pode ser usado em qualquer
host Windows para listar a tabela ARP local.
Tabela ARP em 10.0.2.15 contendo o mapeamento IPMAC informado pela
resposta ARP vinda do roteador.
Após registrar o mapeamento IPMAC em sua tabela ARP, o host está finalmente pronto para encapsular o
pacote destinado a 8.8.8.8 em um quadro da camada de enlace destinado a 52:54:00:12:35:02, e transmitir o
quadro para a LAN, conforme ilustrado pelo pacote de número 3 capturado pelo Wireshark na imagem
seguinte.
Finalmente um pacote de dados (ping, em nosso exemplo) é enviado de 10.0.2.15 ao
roteador 10.0.2.2
Note que os pacotes de número 3, 5, 7 e 9 são pacotes ping enviados por 10.0.2.15 e destinados a 8.8.8.8.
Entretanto, diferentemente do cenário anterior, os pacotes estão encapsulados em quadros da camada de
enlace destinados à interface do roteador (52:54:00:12:35:02), que será responsável por repassar o pacote
adiante.
 
O pacote seguirá sendo repassado de roteador a roteador, usando um processo análogo ao que depuramos
aqui, até que eventualmente chegue ao seu destino final.
 
Por fim, os pacotes 4, 6, 8 e 10 são pacotes ping reply enviados pelo host 8.8.8.8 e destinados ao host
10.0.2.15. Ao receber essas respostas ping, o aplicativo ping finalmente mostra o resultado de sua execução
ao usuário.
Verificando o aprendizado
Questão 1
Considere a rede abaixo. Suponha que o host 10.0.2.15 deseja enviar um pacote de dados destinado ao host
10.0.2.3. Suponha que a tabela ARP do remetente esteja vazia.
 
Sabendo que o host 10.0.2.15 emitirá uma consulta ARP (ARP Request) à sua LAN, com o objetivo de realizar
um mapeamento IPMAC, marque a opção que representa o endereço IP que será consultado pela ARP
Request enviada.
A 10.0.2.2
B 10.0.2.3
C 10.0.2.15
D 10.0.2.255
E 8.8.8.8
A alternativa B está correta.
Ao enviar um pacote de dados destinado ao host 10.0.2.3, o host 10.0.2.15 precisa descobrir o endereço
MAC correspondente ao endereço IP de destino (10.0.2.3). Como a tabela ARP do remetente está vazia, ele
emitirá uma consulta ARP (ARP Request) para toda a rede local (LAN), perguntando"Quem tem o IP
10.0.2.3?". Portanto, o endereço IP que será consultado pela ARP Request enviada é 10.0.2.3, pois este é o
destino final do pacote de dados e é necessário obter seu endereço MAC para completar a comunicação na
camada de enlace da rede.
Questão 2
Considere a rede abaixo. Suponha que o host 10.0.2.15 deseja enviar um pacote de dados destinado ao host
10.0.2.3. Suponha que a tabela ARP do remetente já contenha o mapeamento IPMAC necessário.
 
Sabendo que o pacote IP será encapsulado em um quadro da camada de enlace, marque a opção que
representa o endereço MAC de destino a ser preenchido no cabeçalho Ethernet.
A 08-00-27-83-5B-C1
B 52:54:00:12:35:02
C A1-A2-BC-10-28-F4
D 52-54-00-12-35-03
E FF-FF-FF-FF-FF-FF
A alternativa D está correta.
Ao enviar um pacote de dados do host 10.0.2.15 para o host 10.0.2.3, o endereço MAC de destino no
cabeçalho Ethernet deve corresponder ao endereço MAC do host de destino. Como a tabela ARP do
remetente já contém o mapeamento IPMAC necessário, o endereço MAC correspondente ao IP 10.0.2.3 é
"52-54-00-12-35-03". Portanto, esse é o endereço MAC que será preenchido no cabeçalho Ethernet para
garantir que o pacote seja entregue corretamente ao host de destino.
5. Conclusão
Considerações finais
Neste conteúdo, exploramos a análise de protocolos de camada de aplicação, como HTTP e DHCP, utilizando
o software Wireshark. Capturamos PDUs (Packet Data Units) e realizamos uma depuração detalhada do
significado de cada PDU, bem como sua relação com os comandos dos usuários/clientes. Também abordamos
protocolos de camada de transporte (TCP e UDP) e sua interação com os protocolos de aplicação estudados.
 
Além disso, analisamos protocolos de camada de aplicação como Telnet, FTP, SMTP e DNS, novamente
utilizando o Wireshark para capturar e depurar PDUs. Através de experimentos práticos, compreendemos a
importância de cada protocolo e sua funcionalidade específica.
 
Aplicamos o conceito de modelagem em camadas de redes para estudar a análise e depuração de protocolos
da camada de rede, como ICMP, utilizando o software Tcpdump. Capturamos PDUs ICMP e realizamos uma
depuração passo a passo, culminando em um estudo de caso com o aplicativo traceroute.
 
Por fim, exploramos o processo de repasse de pacotes da camada de rede, juntamente com os protocolos de
camada de enlace necessários para que o repasse funcione. Utilizamos o Wireshark para capturar PDUs de IP,
Ethernet e ARP, e realizamos uma depuração detalhada do significado de cada PDU e sua relação com o
processo de repasse de pacotes, tanto para destinos na mesma rede quanto para destinos em redes
diferentes.
 
Este conteúdo proporcionou uma compreensão aprofundada dos protocolos de rede e suas interações,
capacitando os alunos a identificar e resolver problemas de comunicação em redes, garantindo a eficiência e
segurança dos sistemas.
Explore +
Pesquise na internet sites, vídeos e artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale
com seu professor online, utilizando os recursos disponíveis no ambiente de aprendizagem. 
 
Veja algumas sugestões de pesquisa: 
 
O protocolo Telnet.
 
Introdução a DNS & DNSSEC.
 
Tipos de mensagens ICMP.
 
Aplicativo Traceroute.
• 
• 
• 
• 
 
Tcpdump.
 
Assista ao vídeo ARP basics for the Cisco CCNA. 
 
Veja algumas sugestões de leitura: 
 
Capítulo 4 do livro Redes de Computadores e a Internet, de James F. Kurose, para saber mais detalhes
sobre o repasse de pacotes e tabelas de roteamento.
 
Capítulo 5 do livro Redes de Computadores e a Internet, de James F. Kurose, para saber mais detalhes
sobre o protocolo ARP.
Referências
KUROSE, J. e ROS, K.; Redes de Computadores e a Internet. 6. ed. Nova Jersey: Pearson, 2013.
• 
• 
• 
	Fundamentos e depuração de redes de computadores
	1. Itens iniciais
	Propósito
	Objetivos
	Introdução
	1. Estudo de protocolos das camadas de aplicação e de transporte - Parte 1
	Camada de aplicação
	Conteúdo interativo
	Protocolo de comunicação
	Comentário
	Conteúdo interativo
	Hyper Text Transfer Protocol (HTTP)
	Request For Comments (RFC)
	HTTP
	Conteúdo interativo
	Apresentação de três vias
	Conteúdo interativo
	Software Wireshark
	Comentário
	Etapa 1
	Conteúdo interativo
	Host
	Filtro
	Atenção
	Etapa 2
	Conteúdo interativo
	Conteúdo interativo
	Atenção
	Primeira coluna
	Segunda coluna (Time)
	Terceira coluna
	Quarta coluna
	Quinta coluna
	Sexta coluna (Length)
	Sétima coluna (Info)
	Objetos web solicitados pelo navegador
	Linha 5
	Linha 15
	Como ocorreu a transferência da página web do servidor até o cliente
	Conteúdo interativo
	Saiba mais
	DHCP
	Comentário
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	Recomendação
	Verificando o aprendizado
	2. Estudo de protocolos das camadas de aplicação e de transporte - Parte 2
	Telnet
	Conteúdo interativo
	Wireshark
	Um filtro de captura (host 192.168.10.25)
	Um filtro de exibição (TCP or Telnet)
	PDUs gerados pelo comando ls
	PDU 1
	PDU 2
	PDU 3
	PDU 4
	PDU 5
	PDU 6
	Correio eletrônico
	Conteúdo interativo
	Agentes de usuário (clientes de e-mail)
	Servidores de correio
	SMTP (Simple Mail Transfer Protocol)
	Conteúdo interativo
	Análise do SMTP
	PDUs capturados pelo Wireshark
	PDU 63
	PDU 64
	PDU 66
	PDU 67
	PDU 68
	PDU 69
	PDU 70
	PDU 71
	PDU 72
	PDU 74, 75, 77 e 79
	PDU 81
	PDU 82
	PDU 85
	Saiba mais
	A porta 25 do SMTP
	Comentário
	FTP
	Relação entre os comandos digitados pelo usuário e os PDUs transmitidos pela rede
	“ftp 192.168.10.25” (inicia o aplicativo FTP e solicita uma sessão FTP com o servidor 192l168.10.25)
	“Usuário (192.168.10.25 none)): joao”
	“331 Password required for ihs. Senha:”
	“cd teste”
	“ls”
	“get arquivo.txt” (o usuário solicita o download de arquivo.txt.)
	Caraterística interessante do FTP
	Conteúdo interativo
	DNS
	Análise de PDUs gerados por uma aplicação DNS
	Conteúdo interativo
	Conteúdo interativo
	Verificando o aprendizado
	3. Estudo e depuração de protocolos da camada de rede
	ICMP
	Exemplo
	Programa ping
	Programa traceroute
	Tcpdump
	Conceitos de modelos de camadas para depurar o protocolo ICMP
	Conteúdo interativo
	Cabeçalho IP
	Cabeçalho ICMP
	Cabeçalho IP
	Cabeçalho ICMP
	Atenção
	Conceitos de modelos de camadas para depurar a aplicação traceroute/tracert
	Campos de cabeçalho mais importantes para o traceroute/tracert
	Comentário
	Comentário
	Verificando o aprendizado
	4. Estudo e depuração de protocolos da camada de rede e de enlace
	Depuração do protocolo ARP para repasse de pacotes - mesma rede
	Conteúdo interativo
	Atenção
	Conteúdo interativo
	Passo 1
	Conteúdo interativo
	Passo 2
	Passo 3
	Conteúdo interativo
	Cabeçalhos Ethernet (Camada de enlace)
	Cabeçalhos ARP
	Conteúdo interativo
	Cabeçalhos Ethernet (Camada de enlace)
	Cabeçalhos ARP
	Saiba mais
	Conteúdo interativo
	Depuração do protocolo ARP para repasse de pacotes - redes distintas
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	3. O roteador percebe que ambos são iguais, ou seja, ocorreu um match. Então, o roteador lê a coluna “Ender. de Gateway” (C), apontada pela rota (D). No caso em questão, o valor é “10.0.2.2”.Isso quer dizer que o destino NÃO se encontra na mesma rede do remetente. Portanto, o pacote destinado ao IP (8.8.8.8) deve ser encapsulado em um quadro da camada de enlace que será entregue à interface 10.0.2.2 do roteador.
	Conteúdo interativo
	Cabeçalhos Ethernet (Camada de enlace)
	Comentário
	Opcode=1
	Sender IP address=10.0.2.15 e Sender Mac address=08:00:27:83:5b:c1
	Target IP Address=10.0.2.2
	Conteúdo interativo
	Cabeçalhos Ethernet (Camada de enlace)
	Comentário
	Cabeçalhos ARP
	Verificando o aprendizado
	Questão 1
	Questão 2
	5. Conclusão
	Considerações finais
	Explore +
	Referênciasquando um usuário digita um URL em seu navegador, ou clica sobre um
hiperlink. Isso faz com que o navegador acione a camada de transporte local para solicitar que o sistema
operacional inicie uma conexão TCP entre o S.O. do host do cliente e o S.O. do host servidor. O que envolve
uma troca de mensagens de controle, na camada de transporte, chamada de “apresentação de três vias”
(Three Way Handshake):
 
1. O S.O. do cliente envia um pequeno segmento TCP ao servidor solicitando estabelecimento de conexão. O
S.O. do servidor identifica a solicitação e a reconhece.
 
2. Depois responde com um pequeno segmento destinado ao S.O. do host cliente.
 
3. Por fim, envia nova confirmação ao S.O. do servidor.
 
Veja, a seguir, um exemplo de uma sessão HTTP pedindo um objeto único:
TCP
Transmission Control Protocol.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Exemplo simples de uma sessão HTTP pedindo um objeto único (ex: arquivo .html)
As duas primeiras partes da apresentação de três vias representam um RTT — Round Trip Time (Tempo de ida
e volta). Após concluí-las, o cliente envia a mensagem de requisição HTTP combinada com a terceira parte da
apresentação de três vias (o reconhecimento) por meio da conexão TCP.
 
Assim que a mensagem de requisição chega ao servidor, ela será entregue ao aplicativo servidor Web (como o
Apache), que:
 
Processará o pedido.
 
Realizará a leitura do objeto solicitado (como o arquivo .html).
 
Enviará o arquivo HTML por meio da conexâo TCP de volta ao navegador Web do cliente. Essa
requisição/resposta HTTP consome outro RTT.
Software Wireshark
O interessante é que todo esse processo pode ser observado pelos usuários através do uso de ferramentas
de análise de redes, como, por exemplo, o software Wireshark (https://www.wireshark.org/#download).
 
O Wireshark permite que o usuário monitore todo o tráfego de PDUs que passam por todas as camadas de
seu computador (host).
• 
• 
• 
 
Vamos, então, usar o Wireshark para acompanhar a troca de mensagens, tanto na camada de aplicação
(HTTP) quanto na camada de transporte (TCP) durante a busca da página Web anteriormente usada na
explicação do protocolo HTTP, no site info.cern.ch.
Comentário
A título de curiosidade, essa foi a primeira página Web a entrar no ar desde a criação da World Wide Web
e está no ar até hoje. 
Etapa 1
Para realizar este procedimento, recomendamos que você instale o Wireshark e realize esse procedimento
conosco em seu próprio computador. Lembrando que estamos usando a versão mais atual (2.0.3) do
Wireshark (Maio de 2016).
 
Após instalar e abrir o Wireshark, você verá uma janela equivalente à imagem abaixo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Preparando o Wireshark para capturar trocas de mensagens que ocorrem durante
uma sessão Web.
Antes de iniciar a captura de PDUs, atente-se para os seguintes passos:
Host
Digitar host 188.184.67.27 no campo "...using
this filter".
Filtro
Conferir se o fundo do campo ficou verde,
indicando que o Wireshark compreendeu o filtro
digitado.
Verifique se:
 
O endereço IP usado nesse filtro (188.184.67.27) é o endereço IP do host info.cern.ch. O filtro criado
ordena ao Wireshark que apenas PDUs trocados entre o seu host e o do info.cern.ch sejam capturados.
 
Se quiser descobrir por você mesmo o endereço IP do host info.cern.ch, basta abrir um prompt de
comando do Windows e digitar: ping info.cern.ch. O endereço IP 188.184.67.27 aparecerá ao lado do
hostname info.cern.ch na primeira linha de resposta que o ping apresenta na tela.
 
O filtro que criamos serve para livrar a tela de captura da enorme quantidade de pacotes que seu host
pode estar trocando.
Atenção
Lembre-se que você tem diversos aplicativos que eventualmente se comunicam via rede, mesmo que
não dê um comando explícito. Isso ocorre, por exemplo, com atualizações de antivírus, atualizações do
Windows, aplicativos de backup de arquivos em nuvem, como o Dropbox e OneDrive etc. Uma tela de
captura mais limpa facilita em muito o estudo de uma aplicação em específico, como é nosso
caso. Através do uso do filtro será apresentado apenas o tráfego que desejamos analisar. 
Etapa 2
Para iniciar a captura, basta dar um duplo click na área marcada em azul como vimos na imagem anterior: 
Local Área Netwok (ou na linha que representa a interface de rede que seu host usa para acessar a internet).
 
A imagem abaixo ilustra o Wireshark já aguardando que sejam transferidas para que ele possa capturá-las.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
• 
• 
• 
Wireshark pronto para capturar.
Uma vez iniciada a captura, vá até o navegador e digite o URL “info.cern.ch/hypertext/WWW/TheProject.html”
da página web que deseja que o navegador transfira do servidor web para que seja apresentada pelo
navegador. 
 
A imagem abaixo mostra o navegador Google Chrome apresentando a página web em questão:
Primeira página web da Internet: //info.cern.ch/hypertext/WWW/TheProject.html
Enquanto o navegador transfere os dados do servidor, o Wireshark vai capturando os PDUs que trafegaram
entre seu host e o servidor web, e você pode observá-los aparecendo na área apropriada, conforme mostrado
na imagem abaixo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Listagem de PDUs de camada de transporte (TCP) e camada de aplicação (HTTP)
capturadas pelo Wireshark para nosso exemplo.
Atenção
Após o navegador encerrar o download e apresentação da página web, é hora de clicar no botão “stop”
para terminar a captura de PDUs. 
Na listagem de PDUs (Packet Data Unit) capturados as colunas mostram:
Primeira coluna
Enumera as linhas de 1 a 22, que representam cada PDU capturado. Ou seja, cada linha representa
uma unidade de dados capturada e, neste experimento, 22 PDUs foram capturados.
Segunda coluna (Time)
Informa o tempo em que a unidade de dados foi capturada, tomando-se como referência o momento
de captura da unidade de número 1 (tempo zero).
Terceira coluna
Informa o endereço IP do remetente da unidade de dados (Source).
Quarta coluna
Informa o endereço IP do destinatário da unidade de dados (Destination).
Quinta coluna
É muito interessante, pois informa qual é o protocolo de camada mais alta presente naquela unidade
de dados.
Em nosso experimentos, as linhas designadas como TCP são segmentos da camada de transporte e
as linhas designadas como HTTP são mensagens da camada de aplicação (Web).
Sexta coluna (Length)
Informa o comprimento (bytes) da unidade de dados.
Sétima coluna (Info)
Informa os campos mais importantes do cabeçalho de camada mais alta contida na unidade de
dados.
Quando selecionamos uma linha, o quadro inferior da janela informa quais camadas estão contidas naquela
unidade de dados. Na figura acima, selecionamos a unidade de dados de número 1 (1ª linha), designada como
segmento TCP. O quadro inferior mostra que o segmento TCP está encapsulado dentro de um datagrama/
pacote IP (camada de rede) que, por sua vez, está encapsulado dentro de um quadro (camada de enlace)
Ethernet. É possível abrir cada um desses itens para analisar os cabeçalhos de cada camada.
 
Essa funcionalidade será útil quando formos analisar as mensagens HTTP.
Objetos web solicitados pelo navegador
A tela de captura mostra que dois objetos web foram solicitados pelo navegador:
Linha 5
A linha 5 mostra a mensagem HTTP enviada ao
servidor web solicitando um arquivo HTML foco
de nosso cenário (GET /hypertext/WWW/
TheProject.html):
Linha 15
A linha 15 mostra a mensagem HTTP enviada ao
servidor web solicitando o favicon (GET /
favicon.ico).
Como ocorreu a transferência da página web do servidor até o
cliente
Agora, analisaremos os principais cabeçalhos dos segmentos TCP (camada de transporte) e mensagens HTTP
(camada de aplicação) para compreendermos em detalhes como se deu a transferência da página web do
servidor atéo cliente. Veremos que, neste experimento, o navegador abriu duas conexões TCP, conforme
mostrado na imagem a seguir.
 
Na imagem abaixo, cada seta indicativa da transmissão de um pacote/PDU está marcada com um número
correspondente ao número de sequência do pacote capturado pelo wireshark na imagem de captura de
pacotes mais acima.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe que:
 
A conexão da esquerda (porta local 64830) foi usada para transferir o objeto TheProject.html.
 
A conexão da direita (Porta Local 64831) foi usada para transferir o objeto favicon.ico.
 
A imagem resume quais números de PDUs capturados (de 1 a 22) fizeram parte da cada conexão TCP.
Saiba mais
Para conhecer a análise das informações dos cabeçalhos leia Análise cabeçalhos. 
DHCP
O DHPC (Dynamic Host Configuration Protocol) permite que um host obtenha um endereço IP de maneira
automática.
 
Um administrador de rede pode configurar o DHCP para que determinado hospedeiro receba o mesmo
endereço IP toda vez que se conectar, ou um hospedeiro pode receber um endereço IP temporário diferente
sempre que se conectar.
 
Além de receber um endereço IP temporário, o DHCP também permite que o hospedeiro descubra
informações adicionais, como:
 
A máscara de sub-rede.
• 
• 
• 
 
O endereço do primeiro roteador (default gateway).
 
Endereço de seu servidor DNS local.
Comentário
O DHCP é um protocolo interessante, pois ele fornece um serviço “de infraestrutura” (camada de rede:
atribuição de endereço IP). Porém, é executado na camada de aplicação. Isso ocorre pois o serviço de
atribuição automática de endereços IP não estava previsto no projeto da camada de rede do modelo
TCP/IP. 
A imagem a seguir ilustra um experimento que representa cenário típico de uma aplicação DHCP.
O cliente à direita acaba de dar os comandos “ipconfig/release” e “ipconfig/renew”. Com isso, o protocolo de
camada de aplicação DHCP será usado para liberar o endereço IP que estava atribuído a ele e iniciar uma
nossa sessão DHCP para solicitar um endereço IP, uma máscara de rede, o IP do default gateway e o
endereço do servidor DNS local.
 
Nesse exemplo, o servidor DHCP não está rodando no roteador (e nem na mesma rede do cliente!) para
destacar o fato de que esse serviço pode rodar em qualquer host (desde que os roteadores da instituição
permitam). Entretanto, é muito comum que o servidor DHCP rode na mesma rede e no roteador local.
O PDU destacado na parte esquerda da imagem abaixo mostra os detalhes da mensagem DHCP
release enviada ao servidor DHCP logo depois que o usuário entrou com o comando “ipconfig /
release”.
Observe a imagem:
• 
• 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe que:
 
O IP origem do pacote (192.168.10.173) é o endereço IP que estava atribuído ao host do cliente antes de
ele comandar a liberação do endereço IP.
 
A mensagem DHCP está encapsulada em um segmento UDP (User Datagram Protocol), com porta
origem igual a 68 (porta padrão para clientes DHCP) e a porta destino igual a 67 (porta padrão para
servidores DHCP).
 
A identificação da transação DHPC é 0xe2c1a4e2. Esse valor é usado para identificar unicamente uma
sessão DHCP.
 
Por fim, o campo opcional 53 está preenchido com o valor 7, que indica que essa é uma mensagem
DHCP do tipo release (liberação do endereço IP).
 
Em seguida, em nosso exemplo, o usuário entrou com o comando “ipconfig/renew”.
 
Agora, analisaremos detalhadamente a sessão DHCP criada para atribuir ao cliente:
 
Endereço IP.
 
Máscara de sub-rede.
 
Default gateway.
• 
• 
• 
• 
• 
• 
• 
• 
 
Endereço de servidor DNS local.
O primeiro passo de uma sessão DHCP é a descoberta (DHCP DISCOVER) do servidor DHCP. Como,
inicialmente, o cliente não sabe qual é o endereço IP do servidor DHCP, esse é um passo necessário.
O campo opção 53 preenchido com o valor 1 identifica que essa é uma mensagem DHCP DISCOVER.
 
Observe na imagem:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe que:
 
O endereço IP de origem do PDU é 0.0.0.0. Isso quer dizer que um host sem endereço IP atribuído está
enviando uma mensagem a todos os hosts alcançáveis, inclusive de redes vizinhas (nesse exemplo, o
roteador teve que ser configurado para encaminhar pacotes destinados a 255.255.255.255, pois, por
padrão, roteadores não encaminham pacotes IP de broadcast).
 
O ID dessa transação DHCP é 0xf342191b e o campo Client IP preenchido com 0.0.0.0 indica que o
cliente sabe que ainda não possui endereço IP.
 
Após receber a mensagem DHCP DISCOVER, o servidor DHCP envia uma mensagem DHCP OFFER
(campo opção 53 preenchido com o valor 2), informando ao cliente solicitante que ele é o servidor
DHCP.
 
Na imagem a seguir, podemos ver, no lado esquerdo, que o PDU com número de captura 271 é um DHCP
OFFER. Esse campo veio do servidor proxy (192.168.10.1) destinado a todos os hosts da rede
(255.255.255.255).
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
O campo opção 53 está preenchido com o valor 2, o que identifica essa mensagem DHCP como um DHCP
OFFER.
O ID da transação DHCP (0xf342191b) permite que o cliente solicitante identifique que essa é uma resposta
para sua solicitação.
O DHCP OFFER informa que o endereço IP do servidor DHCP é 192.168.1.32, através do campo opção 54
(preenchido com o valor 192.168.1.32). Nesse instante, o cliente sabe quem é o servidor DHCP e pode emitir
uma requisição de atribuição de endereço IP. Em seguida, o cliente transmite uma mensagem DHCP REQUEST
(campo opção 53 preenchido com o valor 3). Essa é a mensagem em que, efetivamente, o cliente solicita que
o servidor DHCP atribua a ele um endereço IP.
O ID da transação contém o mesmo valor das duas mensagens anteriores, indicando que essa é uma
mensagem da mesma sessão DHCP.
O client IP Address continua com 0.0.0.0 informando que o cliente ainda não sabe qual é o endereço IP que ele
deve usar.
Após receber o DHCP REQUEST, o servidor, finalmente, emite uma resposta DHCP ACK (campo
opção 53 preenchido com valor 5), que é a mensagem que efetivamente atribui os endereços
solicitados ao cliente.
Observe a imagem.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
O ID da transação contém o mesmo valor (0xf342191b) das duas mensagens anteriores, indicando que esta é
uma mensagem da mesma sessão DHCP.
O client IP Address está preenchido com 192.168.10.176. Esse é o endereço IP que o cliente deve usar.
O campo opção 1 informa que a máscara de sub-rede a ser usada é 255.255.255.0.
O campo opção 51 avisa que o tempo de concessão (lease time) informado foi de 4 horas.
Após esse tempo, o cliente deverá iniciar outra sessão DHCP para renovar sua concessão do end. IP ou
solicitar outro.
O campo opção 3 informa que o default gateway para esse cliente é 192.168.10.1.
Por fim, campo opção 6 informa que o servidor DNS para esse cliente é 192.168.1.32.
Após o processamento da mensagem DHCP ACK, o cliente finaliza com sucesso suas configurações
automáticas de endereçamento.
Acompanhe!
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Você notou que não houve apresentação de três vias (three-way handshake) para as duas sessões DHCP que
estudamos (release e renew)?
 
Isso ocorre pois o DHCP usa o protocolo UDP da camada de transporte, e esse é um protocolo sem conexão,
não confiável.
 
Portanto, de fato, não há estabelecimento de conexão entre os sistemas operacionais do host cliente e do
host servidor antes de ocorrer troca de dados.
 
Um host que usa UDP simplesmente monta um datagrama UDP com o conteúdo desejado e o transmite pela
rede assim que possível, sem informar previamente o destinatário de que haverá troca de dados.
Recomendação
Exercite os conhecimentos que aprendeu por meio da lista de exercícios. 
Verificandoo aprendizado
Suponha uma troca HTTP (navegação Web) entre um cliente e um servidor. Uma breve análise dos cabeçalhos
de camada rede (IP) e camada de transporte (porta) revelaram que a troca de dados pode ser identificada
pelo conjunto: 192.168.0.1,6450 -> 192.168.0.10,80.
 
Explique o significado dos valores 6450 e 80:
Chave de resposta
O valor 80 é a porta padrão para aplicativos servidores HTTP/Web, como o Apache ou o Microsoft
Information Service. Por padrão, todo servidor web deve esperar dados através da porta 80.
O valor 6450 é a porta na qual o navegador web do cliente espera receber os dados solicitados ao servidor
web. A porta do cliente segue um valor padrão, como a porta do servidor.
Ao contrário, ao iniciar um procedimento de comunicação, o navegador web solicita ao sistema operacional
um número de porta que esteja desocupado para que ele possa receber dados do servidor web.
2. Estudo de protocolos das camadas de aplicação e de transporte - Parte 2
Telnet
O Telnet é um protocolo padrão de camada de aplicação da internet. Seu objetivo é permitir que usuários
usem um terminal de linha de comando para enviar comandos a servidores remotos, conforme mostrado no
esquema a seguir.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe:
 
Os comandos são digitados no lado cliente (direita) e transmitidos ao servidor para ser executado lá
(esquerda).
 
As mensagens de retorno de comandos são enviadas de volta ao cliente e apresentadas em seu
terminal de linha de comando local (direita).
 
O Telnet se apoia em uma conexão TCP (Protocolo de Controle de Transmissão da Internet), que atua
como uma camada de transporte, para enviar dados em formato texto puro (ASCII), caractere a
caractere.
 
É importante saber:
• 
• 
• 
 
Frequentemente, o TELNET é visto como um protocolo de camada de aplicação dos bytes digitados
pelo usuário através de uma conexão TCP até o aplicativo servidor.
 
Quando o aplicativo servidor gera bytes, eles também são transferidos pela mesma conexão TCP em
que o cliente enviou dados.
 
As especificações básicas do Telnet estão disponíveis no RFC 854, enquanto as numerosas opções são
descritas nos RFC 855 a 861.
 
Aqui, usaremos o Telnet para estabelecer conexão TCP com determinados servidores (como SMTP), com o
objetivo de analisar em detalhes o funcionamento desses protocolos. Isso é possível pois os protocolos
públicos de camada de aplicação da internet geralmente trocam mensagens texto em ASCII para enviar
comandos/respostas entre o cliente e o servidor.
 
Tendo em mente que o Telnet se propõe exatamente a enviar bytes de texto ASCII entre as duas pontas
conectadas, então a aplicação do Telnet para análise mais detalhada de protocolos de aplicação se torna
natural.
RFC
Documentos de domínio público que definem cada padrão/protocolo usado pela Internet. Esses
documentos estão gratuitamente disponíveis na internet.
Wireshark
Vamos, então, primeiramente, usar o Wireshark para capturar o tráfego de uma sessão Telnet e analisarmos os
PDUs (Packet Data Units) capturados e, assim, compreendermos o funcionamento do Telnet.
 
Para esse experimento, usaremos um cenário que envolve um cliente Telnet rodando via terminal do Windows
10 (IP: 192.168.10.176) e um servidor Telnet rodando em uma workstation com o sistema operacional HP-UX
(IP: 192.168.10.25). A sessão Telnet que analisaremos é bastante simples e envolve apenas dois passos:
 
1. Conectar ao servidor Telnet digitando o comando Telnet 192.168.10.25.
 
2. Após o login, digitar um comando slimpes de listagem de arquivos: Is.
 
No Wireshark, habilitamos dois filtros:
PDUs (Packet Data Units)
Unidade de pacote de dados (unidade de dados).
• 
• 
• 
Um filtro de captura (host 192.168.10.25)
Que ordena que apenas sejam capturados
PDUs "vindo de" ou "indo para" o servidor
Telnet.
Um filtro de exibição (TCP or Telnet)
Que ordena que apenas sejam apresentados
PDUs destes 2 protocolos.
A imagem a seguir apresenta o terminal de login Telnet resultante do comando dado no passo 1, bem como o
resultado da captura dos PDUs transmitidos até o momento em que a tela de login é mostrada.
 
Os três primeiros PDUs estão relacionados ao estabelecimento de conexão TCP, na camada de transporte,
entre o host cliente e o host destino (porta Telnet: 23), através do Three-Way Handshake (apresentação de
três vias) já estudado neste disciplina.
Observe:
 
Logo, em seguida, o Telnet gera vários pacotes de dados (suprimidos aqui por questão de espaço)
relativos ao acordo de opções usadas na sessão Telnet e na transferência do texto a ser apresentado
na tela de login.
 
Após o login, iniciamos o passo 2, que consistiu em digitar o comando ls.
PDUs gerados pelo comando ls
Como mostrado na imagem abaixo, esse comando gerou seis PDUs. Vamos ver agora cada um deles.
PDU 1
O PDU de número 1, em destaque na imagem, é uma mensagem de dados trafegando no sentido cliente-
servidor. O conteúdo dessa mensagem é o primeiro caractere do comando ls, ou seja, o l. Essa mensagem
está encapsulada em um segmento UDP.
UDP
Protocolo de Datagramas do Usuário.
• 
PDU 2
O PDU de número 2, em destaque na imagem abaixo, é a mesma mensagem Telnet, com o mesmo conteúdo,
mas trafegando no sentido servidor-cliente.
 
Essa é uma característica do protocolo Telnet. Cara caractere digitado pelo usuário é transmitido em um PDU
ao servidor e, após o aplicativo Telnet servidor receber o caractere/byte, ele emite um eco com o mesmo
caractere de volta ao cliente.
Quando o usuário digita um caractere, o aplicativo Telnet o transmite ao servidor e só apresentará o
caractere digitado na tela do cliente quando o eco chegar.
Você deve se sentir seguro com o fato de que esse processo nada tem a ver com a transmissão confiável do
TCP. Ao contrário, serve apenas para que mesmo um usuário leigo perceba como está o tempo de ida e volta
entre o cliente e o servidor e, ao ver o caractere apresentado na tela, se sinta seguro com o fato de que o
caractere foi compreendido pelo processo Telnet servidor.
PDU 3
Em seguida, no PDU de número 3, destacado na imagem abaixo, observamos que o TCP (camada de
transporte) do cliente automaticamente emitiu uma confirmação ao TCP do servidor para informá-lo que o
cliente recebeu corretamente o eco.
PDU 4
O PDU de número 4, em destaque na imagem abaixo, é uma mensagem de dados trafegando no sentido
cliente-servidor.
 
O conteúdo dessa mensagem é o segundo caractere do comando ls, ou seja, o s. Essa mensagem está
encapsulada em um segmento UDP.
PDU 5
O PDU de número 5, em destaque na imagem abaixo, é uma mensagem Telnet que carrega o eco do segundo
caractere do comando ls.
PDU 6
Em seguida, no PDU de número 6, destacado na imagem abaixo, observamos que o TCP (camada de
transporte) do cliente automaticamente emitiu uma confirmação ao TCP do servidor para informá-lo que o
cliente recebeu corretamente o eco do segundo caractere transmitido.
O Telnet seguirá agindo da forma que vimos acima para cara caractere digitado pelo usuário no terminal
cliente.
 
Quando o usuário terminar de emitir comandos a serem executados pelo Telnet Servidor, ele pode entrar com
o comando exit, que fará com que TCP (camada de transporte) do lado cliente e do lado servidor finalizem a
conexão e terminem a sessão Telnet.
Correio eletrônico
A seguir, examinaremos os protocolos de camada de aplicação que estão no núcleo do correio eletrônico da
internet. Mas, antes de entrarmos nessa discussão, vamos analisar uma visão geral do sistema de correio da
internet e de seus componentes principais.
 
A imagem abaixo apresenta uma visão do sistema de correio da internet.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Veja que há três componentes principais:
Agentes de usuário (clientes de e-mail)
Permitem que usuários leiam, respondam, encaminhem, salvem e componham mensagens.
O Thunderbird, o Microsoft Outlook, o Windows Mail e o AppleMail são alguns exemplos de clientes
de e-mail.
Servidores de correio
Quando um usuário termina de compor seu e-mail, seu cliente de e-mail envia a mensagem para seu
servidor de correio usando o protocolo SMTP.
Nesse servidor, a mensagem é colocada em sua fila de mensagens de saída. Quando chegar a hora
dessa mensagem ser servida, ela será transferida para o servidor de e-mail do usuário destino
através do protocolo SMTP.
Servidores de correio formam o núcleo da infraestrutura do e-mail. Cada destinatário tem uma caixa
postal (caixa de entrada, inbox) localizada em um desses servidores.
Quando um usuário quer ler uma mensagem, seu cliente de e-mail transfere a mensagem de sua caixa
postal, localizada em seu servidor de correio.
SMTP (Simple Mail Transfer Protocol)
O esquema a seguir mostra que uma mensagem típica inicia sua jornada no agente de usuário do
remetente, vai até seu servidor de correio (via SMTP) e viaja até o servidor do destinatário (também
via SMTP), onde é depositada na caixa postal.
Quando o usuário destinatário quer acessar as mensagens de sua caixa postal, ele se conecta (via
POP3 ou IMAP) ao servidor de correio que contém sua caixa postal.
Cabe ressaltar que todos os protocolos envolvidos na comunicação SMTP usam o TCP na camada de
transporte.
 
Observe na imagem abaixo:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Análise do SMTP
Nossa análise do SMTP envolverá um cenário simples em que o usuário opera um cliente de e-mail a partir de
seu host (192.168.10.176), de onde redige um e-mail destinado ao destino@servidor.com. O endereço de
remetente do e-mail é remetente@meuservidor.com. O assunto do e-mail é AssuntoTeste.
Observe:
 
A imagem mostra a captura de PDUs logo após o usuário remetente clicar no botão “enviar” de seu
cliente de e-mail.
 
Como nosso objetivo é analisar somente o SMTP (camada de aplicação), os segmentos TCP foram
marcados com uma cor escura, para que possamos nos concentrar unicamente nas mensagens de
camada de aplicação do SMTP. Ou seja, para manter nossa discussão na camada de aplicação,
ignoraremos o three-way handshake do TCP, que precede a troca de dados SMTP, bem como qualquer
outro segmento de controle TCP.
 
• 
• 
PDUs capturados pelo Wireshark
Imediatamente após o estabelecimento da conexão TCP (portas 25 - desatualizada ou 587 – padrão atual), os
seguintes PDUs foram capturados pelo Wireshark:
PDU 63
O servidor SMTP enviou ao cliente a mensagem “220 meuservidor.com ESMTP Postfix”.
Essa é uma mensagem de boas-vindas que informa ao cliente à qual servidor ele se conectou, bem
como o protocolo de envio de e-mails que ele usa (ESMTP – SMTP Extendido) e, ainda, qual é o
software servidor de e-mail usado (Postfix).
PDU 64
O cliente envia a mensagem SMTP “EHLO 192.168.10.176”, se identificando ao servidor.
PDU 66
O servidor transmite ao cliente a mensagem SMTP “250 correio.ien.gov.br | 250 PIPELINE...”.
PDU 67
O cliente informa ao servidor que tem um e-mail a ser entregue, cujo remetente é
remetente@meuservidor.com.
PDU 68
O Servidor informa ao cliente que compreendeu a mensagem e que o cliente pode enviar o próximo
comando.
PDU 69
O cliente informa ao servidor que tem um e-mail a ser entregue a destino@servidor.com.
PDU 70
O servidor informa ao cliente que compreende e conhece o destinatário do e-mail.
PDU 71
O cliente envia a mensagem SMTP “DATA” para informar ao servidor que começará a enviar o
conteúdo do e-mail.
PDU 72
O servidor informa ao cliente que tudo bem, e que, ao final do conteúdo do e-mail, o cliente deve
enviar os “” (dois pares de caracteres Carriage Return e Line Feed) para indicar que o conteúdo do e-
mail acabou.
PDU 74, 75, 77 e 79
O cliente emite três pacotes de dados com o conteúdo do e-mail, com tamanhos de 310, 1590 e 258
Bytes, respectivamente, e segue a instrução de preencher o final do e-mail com “”, para que o
servidor identifique que o conteúdo do e-mail terminou.
PDU 81
O servidor de e-mail informa ao cliente que a mensagem foi recebida, compreendida, foi marcada com
a identificação B0C513F82 e que será colocada na fila para ser enviada ao “servidor.com” assim que
possível.
PDU 82
O cliente envia a mensagem SMTP “QUIT” para informar ao servidor que deseja terminar a sessão.
PDU 85
O servidor SMTP envia a mensagem “Bye” ao cliente informando que compreendeu o término da
sessão e que está ok para a finalização da sessão.
Saiba mais
Embora nossa análise de PDUs trocados durante uma sessão SMTP de envio de e-mail tenha parado por
aqui, tenha em mente que outra sessão similar a essa será iniciada partindo de “meuservidor.com” para
“servidor.com”. Nesse momento, a mensagem B0C513F82 será passada de um servidor para outro e
será armazenada na caixa de entrada do usuário destino. 
A porta 25 do SMTP
A porta 25 do SMTP, por ser utilizada há mais tempo, possui uma vulnerabilidade maior a ataques e
interceptação de mensagens, além de não exigir autenticação para envio das mensagens, ao contrário da 587
que oferece essa segurança a mais.
 
A medida foi tomada através do CGI, a fim de minimizar a quantidade de SPAMs que circulam por domínios
brasileiros, a partir da constatação de que, no início de 2010, o Brasil estava em segundo lugar no ranking
mundial de envio de SPAMs, devido a vulnerabilidades a malwares ou configurações feitas incorretamente.
Comentário
Segundo o Comitê Gestor da Internet, a intenção é que a porta 25 seja bloqueada, minimizando os riscos
de invasão. Por esses motivos, optou-se por adotar a porta 587, que, para retransmissão da mensagem,
utiliza autenticação do SMTP, dificultando o uso indevido de contas de e-mail ou de máquinas como
zumbis (método bastante utilizado por spammers, em que máquinas de usuários aleatórios são usadas
como emissores de SPAM, implicando na prática de Spoofing, problema comum com usuários de e-mail). 
FTP
Em uma sessão FTP típica (como mostra o esquema), o usuário, sentado à frente de um hospedeiro (o local),
quer transferir arquivos de ou para um hospedeiro remoto. Para acessar a conta remota, o usuário deve
fornecer uma identificação e uma senha. Após fornecer essas informações de autorização, pode transferir
arquivos do sistema local de arquivos para o sistema remoto e vice-versa, conforme ilustra a imagem a seguir.
A imagem abaixo ilustra a sessão FTP usada para gerar os PDUs a serem capturados pelo Wireshark que
alimentarão nossa análise desse interessante protocolo da camada de aplicação.
 
O cliente se conecta em um servidor FTP (192.168.10.15), realiza o login, entra no diretório teste, lista os
arquivos deste diretório e realiza download do arquivo “arquivo.txt”. Observe:
Relação entre os comandos digitados pelo usuário e os PDUs transmitidos
pela rede
A seguir, analisaremos a relação entre os comandos digitados pelo usuário e os PDUs desta sessão
transmitidos pela rede:
“ftp 192.168.10.25” (inicia o aplicativo FTP e solicita uma sessão FTP com o servidor 192l168.10.25)
PDU 4: Após estabelecimento da conexão TCP, o servidor envia o texto da tela de login a ser
apresentado para o cliente FTP.
PDU 6: O cliente FTP tentou ajustar o encoding de dados para o padrão UTF08.
PDU 7: O servidor FTP informou que não conhece esse encoding.
“Usuário (192.168.10.25 none)): joao”
PDU 9: O cliente envia a mensagem FTP “USER joao” informando que o usuário se identificou,
via teclado, como usuário João.
PDU 10: O servidor informa que o login deste usuário requer senha.
“331 Password required for ihs. Senha:”
PDU 12: O cliente envia a mensagem FTP “PASS minhasenha” informando que o usuário digitou
a senha “minhasenha”.
PDU 13: O servidor enviou mensagem FTP informando que o login do usuário foi efetuado com
sucesso. O cliente apresenta a respectiva mensagem na tela.
“cd teste”
PDU 15: o cliente FTP enviou a mensagem FTP “CWD teste”, o que informa ao servidor que o
usuário deseja trocar de diretório para o diretório teste.
PDU 16: O servidor envia a mensagem FTP “250CWD Sucessfull” para informar ao cliente que
a troca de diretório foi efetuada com sucesso. O cliente apresenta a mensagem “250 CWD
command successful” ao usuário.
• 
• 
• 
• 
• 
• 
• 
• 
• 
“ls”
PDU 18: O cliente envia a mensagem FTP “PORT 192,168,10,176,194,182” ao servidor para
informar que espera receber a listagem via uma nova conexão TCP no IP 192.168.10.176 (IP do
cliente) e porta (194*256 + 182 = 49846). Esse é o método padrão definido pelo FTP para que
o cliente informe ao servidor para que porta o servidor deve se conectar para enviar os dados
da listagem solicitada).
PDU 19: O servidor envia a mensagem FTP “200 PORT command successful” para informar ao
cliente que ele entendeu as instruções sobre qual porta do cliente deve ser usada para enviar
a listagem de arquivos solicitada. O cliente apresenta essa mensagem na tela.
PDU 20: Agora que o servidor entende como enviar dados ao cliente, o cliente efetivamente
envia a mensagem FTP “NLST” pedindo que o servidor lhe envie a listagem de arquivos
imediatamente.
PDU 26: O servidor informa (“150 Opening ASCII mode data connection for file list”) ao cliente
mostrando a representação de dados que será usada para transferência da listagem de
arquivos. O cliente apresenta essa mensagem ao usuário para que ele saiba como se dará a
transmissão da listagem de arquivos.
PDU 27: O servidor envia um pacote de dados FTP (ftp-data) contendo a listagem de arquivos
solicitada pelo cliente. Ao receber a mensagem, o cliente apresenta a listagem de arquivos ao
usuário. Nesse exemplo, o único arquivo presente no diretório teste é “arquivo.txt”.
PDU 31: O servidor envia a mensagem FTP “226 Transfer Complete” informando ao cliente que
terminou a transferência da listagem de arquivos com sucesso. O cliente FTP envia essa
mensagem ao usuário, juntamente com o total de bytes recebidos e a taxa de transmissão.
• 
• 
• 
• 
• 
• 
“get arquivo.txt” (o usuário solicita o download de arquivo.txt.)
PDU 35: O cliente envia a mensagem FTP “PORT 192,168,10,176, 194,183” ao servidor,
instruindo-o a estabelecer uma nova conexão TCP via porta (194*245 + 183 = 49487) que
será usada para o envio de arquivo.txt.
PDU 36: O servidor envia a mensagem FTP “200 PORT command successfull” para informar
que compreendeu a informação de porta sobre a nova conexão TCP para envio de dados. O
cliente apresenta essa mensagem ao usuário.
PDU 37: O cliente envia a mensagem FTP “RETR arquivo.txt” ao servidor para efetivamente
solicitar que o servidor transfira o arquivo em questão ao cliente.
PDU 40: O servidor informa (“150 Opening ASCII mode data connection for file list”) ao cliente
mostrando a representação de dados que será usada para transferência da listagem de
arquivos. O cliente apresenta essa mensagem ao usuário para que ele saiba como se dará a
transmissão da listagem de arquivos.
PDU 41: O servidor envia um pacote de dados FTP (ftp-data) contendo o arquivo “arquivo.txt”
pelo cliente. Ao receber a mensagem, o cliente inicia a gravação do arquivo recebido no disco
rígido local.
PDU 47: O servidor envia a mensagem FTP “226 Transfer Complete” informando ao cliente que
terminou a transferência da listagem de arquivos com sucesso. O cliente FTP envia essa
mensagem ao usuário, juntamente com o total de bytes recebidos e a taxa de transmissão.
Com relação ao CD TESTE, observe a imagem a seguir:
Caraterística interessante do FTP
A esta altura você deve ter notado que o FTP tem uma caraterística muito interessante: os comandos são
enviados por uma conexão TCP de controle e, sempre que há necessidade de troca de dados (como a
listagem ou download de arquivos), uma nova conexão TCP é aberta para transferência de dados, conforme
indicado no esquema abaixo.
• 
• 
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe:
 
O servidor usa a porta 21 para receber conexões FTP e para trocar mensagens de controle, e usa a 
porta 20 para receber dados.
 
Instantes antes de iniciar um download ou listagem de arquivos, o cliente deve informar ao servidor
qual será a porta do lado do cliente usada para transferir dados.
 
Em nosso experimento, as portas escolhidas pelo cliente foram 49846, para listagem de arquivos, e 
49847, para download de arquivo.txt.
 
DNS
A última análise que realizaremos tem como alvo o protocolo de camada de aplicação DNS (Domain Name
System).
 
O objetivo do DNS é facilitar a vida dos usuários através da tradução de nomes de hosts (como o
www.google.com) em endereços IPs (por exemplo, 216.58.22.68).
 
Como os usuários leigos têm uma relação muito mais amigável com os nomes de hosts do que com os
endereços IPs, o DNS acabou se tornando importante para diversos outros protocolos de aplicação, incluindo
a web e o e-mail.
O DNS é um protocolo interessante, pois é um componente fundamental da infraestrutura da
internet, mas implementado na camada de aplicação.
Análise de PDUs gerados por uma aplicação DNS
Para a análise de PDUs gerados por uma aplicação DNS, vamos considerar o cenário simplificado onde um
usuário abre um terminal de comandos e digita o comando “ping www.estacio.br”.
 
• 
• 
• 
O ping é uma aplicação que testa a conectividade entre o localhost e o host informado no comando, bem
como mede o atraso de ida e volta.
 
Esse experimento está ilustrado na parte superior da imagem abaixo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe:
 
Logo após digitar o comando e teclar , a aplicação ping precisa obter o endereço IP relativo ao
hostname www.estacio.br. Para isso, é gerada uma consulta DNS direcionada ao endereço IP do
servidor DNS local configurado no host do cliente.
 
Como mostrado no lado direito da imagem, o primeiro pacote gerado após o início do ping é o PDU de
número 1. Este segmento UDP é direcionado à porta destino 53, que é a porta padrão DNS. O endereço
IP destino do PDU é 192.168.1.32, indicando que esse é o servidor DNS configurado na máquina do
usuário.
 
A identificação de transação é 0x595f. Cada sessão DNS possui uma identificação única. Isso é
importante para quem analisa PDUs de sessões DNS, pois é através desse valor que é possível
identificar quais PDUs DNS pertencem à mesma sessão.
 
O Campo Queries do Cabeçalho DNS informa que o hostname que se deseja traduzir é www.estacio.br.
• 
• 
• 
• 
 
Ainda na imagem, vemos que o PDU de número 2 foi recebido vindo do servidor DNS local com destino
ao host do usuário. Os detalhes dessa resposta DNS estão apresentados na imagem.
 
O transaction ID é 0x595f, o mesmo valor do transaction ID da consulta DNS. Isso confirma que esta é
a resposta DNS para a consulta DNS que analisamos.
 
Como sabemos, o DHCP é capaz de, automaticamente, informar ao host do usuário qual é o endereço IP do
servidor DNS.
 
Mais abaixo, na mesma imagem, marcamos o ponto em que o endereço IP do host www.estacio.br é de fato
apresentado.
 
Dois IPs foram fornecidos: 200.123.199.32 e 200.123.199.19.
 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Observe:
 
Se você conferir na imagem, onde é apresentada a linha de comando e os retornos do comando ping,
verá que o processo ping escolheu o endereço IP 200.123.199.19 para o envio da consulta DNS.
 
Uma das razões para consulta DNS a um hostname, para devolver vários IPs, é fornecer várias opções
para que o cliente possa escolher uma delas à sua vontade. Com isso, distribui-se a carga do tráfego
até os diversos servidores disponíveis.
 
Em nosso caso, a consulta DNS revelou que há dois servidores atendendo pelo nome www.estacio.br.
• 
• 
• 
• 
• 
Verificando o aprendizado
Questão 1
Suponha que você queira usar um aplicativo que lhe permita trocar mensagens, via linha de comandos, com o
processo servidor de diversos protocolos de aplicação, como o HTTP (Protocolo padrão para navegação web
da Internet.), SMTP ou FTP.
 
Marque abaixo a opção que representao melhor aplicativo para tal objetivo:
A "Thunderbird".
B Apache.
C "Microsoft Edge".
D "Chrome".
E "Telnet"
A alternativa E está correta.
Telnet é um protocolo de rede que permite a comunicação com um servidor remoto via linha de comando,
possibilitando a interação direta com diversos protocolos de aplicação, como HTTP, SMTP e FTP. Diferente
dos navegadores web e clientes de e-mail, que possuem interfaces gráficas específicas para suas funções,
o Telnet oferece uma interface de linha de comando que é ideal para testes e diagnósticos de rede,
permitindo o envio e recebimento de comandos e respostas diretamente do servidor. Portanto, para trocar
mensagens via linha de comando com servidores de diferentes protocolos, o Telnet é a melhor escolha.
3. Estudo e depuração de protocolos da camada de rede
ICMP
O ICMP (Internet Control Message Protocol – Protocolo de Mensagens de Controle da Internet), especificado
no [RFC 792], é usado por hospedeiros e roteadores para comunicar informações de camada de rede entre si.
A utilização mais comum do ICMP é para comunicação de erros.
RFC 
Request For Comments – Documentos de domínio público que definem cada padrão/protocolo usado
pela Internet. Esses documentos estão gratuitamente disponíveis na Internet. 
Por exemplo,
ao rodar uma
sessão Telnet,
FTP ou HTTP,
é possível que
você já tenha
encontrado
uma
mensagem de
erro como
“Rede de
destino
inalcançável”.
Essa
mensagem
teve sua
origem no
ICMP.
 Em algum ponto,
um roteador IP
(Protocolo de
Internet) não
conseguiu
descobrir um
caminho para o
hospedeiro
especificado em
sua aplicação
Telnet, FTP ou
HTTP. O roteador,
então, criou e
enviou uma
mensagem ICMP
do tipo 3 a seu
hospedeiro
indicando o erro.
 O ICMP é, com
frequência,
considerado parte do
IP, mas, em termos de
arquitetura, está logo
acima, pois mensagens
ICMP são carregadas
dentro de datagramas
IP (Protocolo de
Internet.). Isto é,
mensagens ICMP são
carregadas como
carga útil IP,
exatamente como
segmentos TCP ou
UDP, que também o
são.
 Por essa
razão, o
ICMP é
considerado
um protocolo
de camada
de rede, mas
que roda na
parte
superior da
camada de
rede (sobre
o IP),
conforme
mostrado na
imagem
abaixo.
Quando um hospedeiro recebe um datagrama IP com ICMP especificado como protocolo de camada superior,
ele demultiplexa o conteúdo do datagrama para ICMP, exatamente como demultiplexaria o conteúdo de um
datagrama para TCP ou UDP.
 
Mensagens ICMP têm um campo de tipo e um campo de código. Além disso, contêm o cabeçalho e os
primeiros 8 bytes do datagrama IP que causou a criação da mensagem ICMP em primeiro lugar (de modo que
o remetente pode determinar o datagrama que causou o erro). Alguns tipos de mensagens ICMP selecionadas
são mostrados na tabela abaixo.
Тіро ICMP Código Descrição
0 0 Resposta de uma solicitação eco (resposta ping)
3 0 Rede de destino inalcançável
3 1 Hospedeiro de destino inalcançável
3 2 Protocolo de destino inalcançável
3 3 Porta de destino inalcançável
3 6 Rede de destino desconhecida
3 7 Hospedeiro de destino desconhecido
4 0 Repressão da origem (controle de congestionamento)
8 0 Solicitação eco (requisição ping)
9 0 Anúncio do roteador
10 0 Descoberta do roteador
11 0 TTL (Time to Live) expirado
12 0 Cabeçalho IP inválido
Tabela: Alguns tipos de mensagens ICMP.
Guilherme Dutra Gonzaga Jaime.
Note que mensagens ICMP não são usadas somente para sinalizar condições de erro.
Exemplo
Um exemplo interessante de mensagem ICMP é a de repressão da origem. Essa mensagem é pouco
usada na prática. Sua finalidade original era realizar controle de congestionamento (permitir que um
roteador congestionado enviasse uma mensagem ICMP de repressão da origem a um hospedeiro para
obrigá-lo a reduzir sua velocidade de transmissão). O desuso desse tipo de mensagem ICMP se deu pelo
fato de que o próprio TCP, na camada de transporte, já inclui um algoritmo de controle de
congestionamento. 
Os programas mais conhecidos de uso prático do ICMP são:
Programa ping
Talvez seja o exemplo mais amplamente conhecido de uso prático do ICMP. Quando um usuário inicia
um comando ping informando o endereço IP do host destino, o processo ping do host remetente
envia uma mensagem ICMP do tipo 8 código 0 para o hospedeiro especificado.
O hospedeiro de destino, ao ver a solicitação de eco, devolve uma resposta de eco ICMP do tipo 0
código 0. A maior parte das execuções de TCP/IP suporta o servidor ping diretamente no sistema
operacional. Isto é, o servidor não é um processo. Note que o programa cliente tem de ser capaz de
instruir o sistema operacional para que ele gere uma mensagem ICMP do tipo 8 código 0.
Programa traceroute
Outro aplicativo interessante que utiliza o ICMP é o programa traceroute (Linux) ou tracert (Windows),
que nos permite acompanhar a rota de um hospedeiro a qualquer outro hospedeiro no mundo.
O interessante é que o traceroute é executado com mensagens ICMP.
Tcpdump
O Tcpdump é um dos mais difundidos softwares sniffers disponíveis para a família de sistemas operacionais
GNU/Linux. Ele é chamado via linha de comando e começa a monitorar todos os pacotes que passam pela
interface de rede selecionada.
 
Então, o Tcpdump imprime uma descrição do conteúdo dos cabeçalhos dos pacotes que atendam à
expressão boleana fornecida.
O Tcpdump imprime na tela uma linha descrevendo cada pacote. A primeira coluna contém o
timestamp (instante de captura do pacote) expresso em horas, minutos, segundos e frações de
segundos desde a meia-noite.
Na imagem, a seguir, você pode visualizar um exemplo simplificado do uso do Tcpdump.
1. Dois terminais de comando foram usados. No terminal apresentado no meio, em uma janela menor, foi dado
o comando “telnet 192.162.10.240”.
2. No terminal maior, ao fundo, o comando “tcpdump –i eth0 port 23” aguardava por pacotes gerados pelo
telnet. Após a captura do primeiro pacote, às 17h47m32s, abortamos a captura de pacotes através do
comando “ctrl+c”.
3. A opção “-i eth0” do Tcpdump informa qual é a interface em que o Tcpdump deve realizar a captura de
pacotes. No Linux “eth0”, é, em geral, o nome dado à primeira interface de rede detectada. Se o host possui
apenas uma interface de rede, muito provavelmente ela será designada pelo Linux como “eth0”.
4. A opção “port 23” ordena que o Tcpdump capture apenas pacotes vindos de ou destinados à porta 23
(porta Telnet). O Tcpdump também pode ser chamado com a opção –w, o que faz com que os pacotes
capturados sejam salvos em um arquivo para análise posterior. Quando chamado com a opção –r, o Tcpdump
lê os dados de um arquivo de captura salvo para apresentar a captura ao usuário.
5. Note que o pacote foi capturado às 17h47m32s. Conforme os dados apresentados pelo Tpcdump, é
possível observar que o pacote capturado é um pacote IP, partindo do host local (ien) na porta 38954, com
destino ao host 192.192.10.240 na porta 23 (telnet).
6. Na camada de transporte, a flag SYN (S) está habilitada. O que indica que esse pacote é um pedido de
estabelecimento de conexão TCP, com número de sequência (seq) 2985101472 e janela de congestionamento
(win) 29200.
Conceitos de modelos de camadas para depurar o
protocolo ICMP
Para analisarmos os pacotes de uma sessão ICMP, usaremos um exemplo simples considerando que o usuário
dá o comando “ping www.google.com”, conforme mostrado na parte direita da imagem abaixo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
No lado direito da figura, temos um terminal de comandos onde foi dado o comando ping. Note que
aguardávamos o envio e retorno de 6 pings, enquanto observávamos, no terminal mostrado no lado
esquerdo da figura, a captura dos pacotes relativos a cada um dos 6 pings trocados entre o host local
e www.google.com.
 
Na imagem acima, enumeramos cada um dos pings gerados (lado direito) e os relacionamos aos
pacotes capturados (lado esquerdo) pelo Tcpdump.
• 
• 
 
Note que, para cada ping enviado, dois pacotes foram capturados: echo request (solicitação eco) e
echoreply (resposta eco).
 
No lado esquerdo da imagem, na seta indicada com o número 1, vemos que a primeira solicitação eco
foi emitida às 17h19m52.911s.
 
Vamos analisar os campos dos cabeçalhos. 
 
Observe:
Cabeçalho IP
• TOS=0x0 – Tipo de serviço padrão.
• TTL=64 – Número máximo de canais de comunicação pelos quais a solicitação eco em questão
pode passar até chegar ao destino.
• ID=36598 – Identificação única de datagrama. Cada datagrama que sai do host é carimbado com
um ID único. Esse campo é importante quando há fragmentação, pois quando um host destino recebe
vários datagramas com o mesmo ID, então ele sabe que são fragmentos de um datagrama original
que foi fragmentado em algum ponto no caminho origem-destino.
• OFFset=0 – O offset é usado para remontagem do datagrama no destino, caso haja fragmentação
no caminho origem-destino. O valor de zero significa que esse seria o primeiro fragmento (quando um
datagrama não é fragmentado, como nesse caso, então o único datagrama é também o primeiro).
• Flag=DF – Quando ocorre fragmentação de datagramas, o campo flag é usado para informar ao host
destino qual é o último fragmento gerado. Dessa forma, o host destino saberá quando tiver terminado
de remontar todos os fragmentos de volta ao datagrama original. O programa ping preenche esse
campo com o valor DF, que significa que esse datagrama não deve ser fragmentado.
• Protocol=1 (ICMP) – Esse campo do cabeçalho IP é de fundamental importância, pois, ao ser
preenchido com o valor 1 (ICMP), informa ao host destino que esse pacote carrega uma mensagem
ICMP. Assim, o host destino sabe que esse não é um pacote de dados contendo e-mail, nem um
pacote relativo à navegação web, mas, sim, um pacote ICMP. Então, o sistema operacional do host
destino (camada de rede) sabe a qual processo esse pacote deve ser entregue: ao ping.
• Length=84 – O comprimento total do pacote é de 84 bytes.
• IP remetente=192.168.10.162 - Host em que o comando ping foi dado.
• IP Destino=216.58.222.100 - Host destino informado no comando ping.
Cabeçalho ICMP
• ICMP echo request (Lembre-se: tipo 8, código 0) – Solicitação eco.
• Seq=1 – Essa é a primeira solicitação eco.
Logo em seguida, no instante 17h59m53.045s, o Tcpdump acusou a captura da resposta eco.
Agora, vamos analisar em detalhes os principais campos destes pacotes:
• 
• 
Cabeçalho IP
• TOS=0x0 – Tipo de serviço padrão.
• TTL=54 – O host destino (www.google.com) emitiu uma resposta eco com TTL=64. Como o campo
TTL chegou no host remetente com TTL=54, podemos inferir que, no caminho entre o google e o host
local, o pacote passou por 10 saltos (canais de comunicação).
• OFFset=0 – O offset é usado para remontagem do datagrama no destino, caso haja fragmentação
no caminho origem-destino. O valor de zero significa que esse seria o primeiro fragmento (quando um
datagrama não é fragmentado, como nesse caso, então o único datagrama é também o primeiro).
• Flag=0 – Quando ocorre fragmentação de datagramas, o campo flag é usado para informar ao host
destino qual é o último fragmento gerado. Dessa forma, o host destino saberá quando tiver terminado
de remontar todos os fragmentos de volta ao datagrama original. A resposta ping veio com valor
vazio, indicando que, caso tenha havido fragmentação, esse seria o último fragmento (como o
offset=0 indica que esse também é o primeiro fragmento, então concluímos que não houve
fragmentação, pois o primeiro é também último, sendo, portanto, único).
• Proto=1 (ICMP) – Esse campo do cabeçalho IP é de fundamental importância, pois, ao ser
preenchido com o valor 1 (ICMP), informa ao host destino que esse pacote carrega uma mensagem
ICMP. Assim, o host destino sabe que esse não é um pacote de dados contendo e-mail, nem um
pacote relativo à navegação web, mas, sim, um pacote ICMP. Então, o sistema operacional do host
destino (camada de rede) sabe a qual processo esse pacote deve ser entregue: ao ping.
• Length=84: Comprimento total do pacote é de 84 bytes.
• IP remetente=216.58.222.100 – O campo desse pacote foi emitido pelo host www.google.com
(destino de nosso comando ping).
• IP Destino: 192.168.10.162 – O campo end. IP destino está preenchido com o endereço do host onde
o comando ping foi dado.
Analisando esses dois campos, vemos que esse é um pacote IP emitido pelo google com destino ao
host que emitiu o comando ping.
Cabeçalho ICMP
• ICMP echo request (Lembre-se: tipo 0, código 0) – Resposta eco;
• Seq=1 – Essa é uma resposta eco relativa à solicitação eco de número de sequência igual a 1, ou
seja, é a resposta do primeiro ping.
Ainda relativo ao primeiro ping, marcado com o número 1 na imagem acima, o primeiro retorno dado pelo
comando ping informa que o tempo medido (time) entre o envio da solicitação eco e o recebimento da
resposta eco foi de 134ms.
 
Mas como isso é calculado?
 
Felizmente, a captura de pacotes nos permite analisar como essa medição de tempo é feita.
 
Assim, o aplicativo ping registra o momento em que a solicitação ping é enviada (Treq) e o momento em que a
resposta ping chega (Treply). 
 
Para os outros 5 pings gerados em nosso exemplo, note que a resposta ping sempre informa o número
sequência de qual solicitação ping está sendo respondida. 
Atenção
Essa informação é importante, pois o comando ping permite (no Linux, como root) que o tempo entre
solicitações eco seja informado. 
Por exemplo, um usuário pode enviar 1000 pings por segundo.
 
Como sabemos que o roteamento na Internet ocorre de maneira independente para cada pacote, pode
ocorrer troca de ordem entre os pacotes transmitidos. Com isso, por exemplo, a primeira resposta eco
recebida pode não ser relativa à primeira solicitação eco enviada, pois a resposta eco seq=1 pode ter dado o
azar de tomar um caminho menos eficiente.
 
Então, ao receber uma primeira resposta eco marcada com seq=2, o programa ping sabe que é uma resposta
para a segunda solicitação ping enviada e não para a primeira. Dessa maneira, o tempo de ida e volta pode ser
corretamente calculado.
Conceitos de modelos de camadas para depurar a
aplicação traceroute/tracert
O traceroute (Linux) ou tracert (Windows) é um aplicativo muito útil para administradores de redes de
computadores, pois permite realizar uma listagem dos roteadores (interface de rede por qual o pacote chega)
pelos quais o pacote passa até chegar a um dado destino.
 
A ideia sob a qual essa aplicação se apoia é muito simples:
 
Quando o usuário especifica um nome de hospedeiro de destino, o programa no hospedeiro de origem
envia vários pacotes especiais em direçāo àquele destino.
 
Ao seguir seu caminho até o destino, esses pacotes passam por uma série de roteadores. Um deles
recebe um desses pacotes especiais e envia à origem uma curta mensagem, contendo o nome e o
endereço do roteador.
 
A maneira como o traceroute alcança esse objetivo é muito interessante para quem estuda redes de
computadores. Para entender como o traceroute funciona, primeiramente precisamos recordar como funciona
o campo TTL do cabeçalho IP.
O tempo TTL é decrementado sempre que o pacote passa por um roteador. Caso um roteador decremente o
campo TTL de um pacote que está sendo processado e notar que o novo valor é igual a zero, então o pacote
expirou. Isso quer dizer que o roteador não pode seguir encaminhando o pacote. Ao contrário, ele deve emitir
uma mensagem ICMP TTL Exceeded (Time To Live Exceeded – Tempo de Vida Excedido) ao host remetente.
• 
• 
No exemplo da imagem acima, usamos o terminal da direita para dar o comando “traceroute –icmp
192.168.1.34” com o objetivo de descobrir quais são os roteadores entre o host em que o comando foi
dado e o destino 192.168.1.34.
 
Ainda na janela da direita, o primeiro resultado apresentado na tela (A) informa que a primeira interface
de roteador a receber o pacote em questão foi 192.168.10.1. Também é fornecido três estimativas de
tempo de ida e volta entre o host remetente e esse roteador (2.602ms, 2.576ms e 2.578ms).
 
Na parte superioresquerda da figura, vemos quais foram os pacotes emitidos pelo programa
traceroute para mostrar o resultado (A) ao usuário.
Campos de cabeçalho mais importantes para o traceroute/
tracert
Vamos deixar o detalhamento do significado de cada campo do cabeçalho IP e ICMP (já os estudamos no
exemplo anterior sobre o ICMP) e nos concentrar apenas nos campos de cabeçalho mais importantes para o
entendimento de como funciona o traceroute/tracert. Esses campos estão destacados em amarelo no canto
superior esquerdo da imagem.
Note que o host remetente emitiu um pacote ICMP echo request destinado a 192.168.1.34. Ou seja,
um ping está sendo enviado ao host informado no comando traceroute.
Esse echo request teve o campo TTL cuidadosamente preenchido com 1.
 
Por quê?
 
Simples! Quando o pacote chegar ao primeiro roteador no caminho até o destino 192. 168. 1. 34, o TTL será
decrementado de 1 para 0, conforme ordena o protocolo IP da camada de rede.
 
• 
• 
• 
O primeiro roteador no caminho até o destino (192.168.10.1), entāo, notará que o pacote expirou e emitirá um
pacote ICMP ao remetente informando ICMP time exceeded para avisar ao remetente que o pacote expirou.
Comentário
Nesse momento, o remetente sabe que o primeiro roteador no caminho até 192.168.1.34 é o de endereço
IP 192.168.10.1. 
Ainda na parte superior esquerda da figura, notamos que o host remetente, na verdade, enviou três ICMP
echo request destinados a 192.168.1.34 com TTL=1.
 
Isso é feito para que sejam recebidas três respostas ICMP time exceeded de modo que o programa traceroute
possa realizar as três medições de tempo de ida e volta até o primeiro roteador e apresentar os resultados ao
usuário.
 
Após ter descoberto o IP do primeiro roteador no caminho até o destino e apresentado três medições de
tempo de ida e volta a esse roteador, o programa traceroute prossegue com a tentativa de descobrir o
endereço IP do segundo roteador no caminho origem-destino.
Para isso, serão enviados outros três ICMP echo requests destinados ao host informado no comando
(192.168.1.34) com o campo TTL cuidadosamente preenchido com o valor 2.
 
Veja, a seguir, como acontece esse processo:
 
1. Esses pacotes terão seu TTL decrementado para 1 no primeiro roteador no caminho até o destino e, em
seguida, decrementados para zero pelo segundo roteador no caminho origem-destino.
 
2. O segundo roteador, então, enviará mensagens ICMP time exceeded ao host remetente informando que os
pacotes expiraram, e o programa traceroute será capaz de descobrir que é o segundo roteador no caminho
origem-destino, bem como medir e apresentar ao usuário três estimativas de tempo de ida e volta entre o host
remetente e o segundo roteador no caminho.
 
3. Esse processo seguirá com o traceroute emitindo três ICMP echo request com o TTL cuidadosamente
preenchido com 3, para descobrir o terceiro roteador, e assim por diante.
 
No momento em que o programa traceroute notar que, ao invés de receber mensagens ICMP time exceeded,
recebeu mensagens ICMP echo reply, então o destino desejado já foi alcançado, e todos os roteadores no
caminho origem-destino já foram descobertos.
Comentário
A parte inferior esquerda da imagem mostra que os três ICMP echo request com TTL=2 enviados pelo
host remetente com destino a 192.168.1.34 geraram respostas destinadas a 192.168.10.162 contendo
mensagens ICMP echo reply. 
Nesse momento, em nosso exemplo, o comando traceroute sabia que o destino já havia sido alcançado e que
apenas o roteador 192.168.10.1 está no caminho entre a origem e o destino.
Verificando o aprendizado
Questão 1
Suponha que você está rodando o comando traceroute, que gerou pacotes ICMP echo request até o destino
8.8.8.8. Ao tentar descobrir o terceiro roteador no caminho origem-destino, qual é o valor que irá preenchido
no campo TTL dos pacotes ICMP echo request destinados a 8.8.8.8?
A 0
B 1
C 2
D 3
E 4
A alternativa D está correta.
Isso se justifica porque o comando traceroute utiliza o campo TTL (Time to Live) dos pacotes ICMP echo
request para descobrir cada roteador no caminho até o destino. O valor do TTL é incrementado a cada
salto, começando em 1 para o primeiro roteador, 2 para o segundo, e assim por diante. Portanto, para
descobrir o terceiro roteador no caminho, o valor do TTL deve ser 3, permitindo que o pacote alcance o
terceiro roteador antes de ser descartado e gerar uma resposta ICMP Time Exceeded, que é então usada
pelo traceroute para identificar o roteador.
4. Estudo e depuração de protocolos da camada de rede e de enlace
Depuração do protocolo ARP para repasse de pacotes -
mesma rede
Nosso primeiro objetivo aqui consiste em depurar a interação entre a camada de rede e a camada de enlace, e
seus respectivos protocolos em um cenário, como o descrito na imagem abaixo; onde o host 10.0.2.15 deseja
enviar um pacote destinado ao host 10.0.2.10, localizado na mesma rede IP que o remetente.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Primeiro cenário proposto – Envio de pacote para destino na mesma rede
Atenção
Antes de continuarmos, é importante que você se acostume com a ideia de que sempre que um pacote
vai ser transmitido, a tabela de roteamento local é necessariamente consultada. Portanto, seu laptop
possui uma tabela de roteamento e seu desktop também. Até mesmo seu smartphone possui uma tabela
roteamento. Na verdade, todo equipamento conectado à Internet necessariamente possui uma tabela de
roteamento, já que ela tem que ser consultada sempre que um pacote precisar ser transmitido. 
Abaixo listamos um exemplo de uma tabela de roteamento em um Desktop Windows 10. O comando route
print imprime a tabela de roteamento. Como a imagem seguinte, onde cada linha da tabela de roteamento
representa uma rota.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Tabela de Roteamento do host 10.0.2.15
Podemos observar no exemplo anterior que:
 
A coluna “Endereço de Rede” indica qual é a rede destino (A) para a qual a rota em questão aponta.
 
A coluna “Máscara” indica qual é a máscara de rede da rede destino (B) indicada na coluna “Endereço
de Rede”.
 
Por fim, a coluna “Ender. Gateway” indica qual é o endereço IP do próximo salto (C) para o qual o
pacote deve ser repassado para que chegue até o destino apontado por “Endereço de Rede”.
 
Recorde que, no cenário apresentado, estamos supondo que o host 10.0.2.15 deseja enviar um pacote de
dados destinado ao host 10.0.2.3 (ambos estão na mesma rede/LAN).
 
Além disso:
 
Ao gerar um pacote, a aplicação informa ao S.O. que o endereço IP destino do pacote é 10.0.2.3.
 
A camada de rede, localizada no S.O., deve olhar para a tabela de roteamento (imagem anterior) para
consultar se alguma de suas rotas (linhas) gerará um match (equivalência) com o endereço de destino
do pacote.
 
O S.O. do host cliente tentará encontrar um match (explicado em detalhes logo abaixo) para todas as
rotas (linhas) da tabela de roteamento. Entretanto, em nosso exemplo, a única rota que gerará um
match com o endereço IP de destino do pacote (10.0.2.3) é a rota para a rede 10.0.2.0 (D) (imagem
anterior).
• 
• 
• 
• 
• 
• 
 
A máscara de uma rota (255.255.255.0 para a rota 10.0.2.0) pode ser vista como uma instrução de
como realizar a comparação entre o endereço IP de destino do pacote e o endereço de rede da rota,
com o objetivo de testar se há um match.
 
Veja, a seguir, como é feita a tentativa de obter um match.
Passo 1
O roteador realiza um AND Lógico bit-a-bit entre o endereço IP de destino do pacote (10.0.2.3) e a máscara da
rota que está sendo testada (255.255.255.0):
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Passo 2
O roteador compara o resultado obtido (10.0.2.0) com o endereço de rede destino (D) da rota que está sendo
testada na tabela de roteamento (10.0.2.0).
Passo 3
O roteador percebe que ambos são iguais, ou seja, ocorreu um match. Então, o