Muitas pessoas já me perguntaram sobre como funciona ou "qual é a magica?" do processo de acesso a um website, abaixo explicarei detalhadamente como seu computador faz para requisitar e receber uma pagina da Internet (através do uso de um sniffer de rede), mas antes segue um overview sobre alguns conceitos técnicos (caso queira pular os conceitos técnicos clique aqui!!!):
Endereço MAC (Media Access Control Address)-> Também conhecido como endereço físico, ele pertence a camada 2 (modelo OSI) e é composto por 6 conjuntos de 2 dígitos hexadecimais, ex: 52:54:00:12:35:02. Esse endereço é gravado na memoria ROM da interface de rede e o sistema operacional lê esse valor e o utiliza. Os primeiros 3 conjuntos identificam o fabricante e os 3 demais identificam a interface. O MAC é um endereço único, ou seja, não deveria existir dois endereços MAC iguais, mas sabemos que existem alguns casos onde o MAC é alterado, como por exemplo, num ataque do tipo MAC spoofing ou porque você simplesmente preferiu altera-lo (já peguei um caso que haviam duas interfaces do mesmo fabricante com MAC iguais e tive de alterar).
Endereço IP (Internet Protocol Address)-> Também conhecido como endereço lógico, ele está associado a camada 3 (modelo OSI) e no IPv4 é composto por 4 octetos, ou seja, tem 32bits. Em uma rede TCP/IP tem a função de identificar um ativo na rede e encaminhamento dos dados.
ARP (Address Resolution Protocol)-> Protocolo com a função de descobrir um endereço físico baseado num endereço logico, ou seja, descobrir o endereço MAC da interface de rede do IP que será destinado o pacote. Note que o nome do comando que interage com o ARP no sistema operacional é o justamente o nome do protocolo ("arp") em Windows ou unix-like.
TCP (Transmission Control Protocol)-> Protocolo pertencente a camada 4 (modelo OSI), é orientado a conexão, garante a entrega dos pacotes de forma ordenada, faz verificação de erros, etc.
UDP (User Datagram Protocol)-> Protocolo sem orientação a conexão (não usa o three-way handshake), não garante a entrega, ordem ou proteção contra duplicação, sendo responsabilidade da aplicação que usa o UDP fazer estes tratamentos. Para o leitor não achar este protocolo ruim, um bom exemplo de sua utilidade seria em uma transmissão de áudio (dados em tempo real), pois caso o pacote se perca no meio do caminho é melhor continuar reproduzindo o áudio do que tentar recuperar o pacote (por isso que geralmente bom ou ruim é relativo). E como o TCP, ele pertence a camada 4 do modelo OSI.
Three-way handshake-> O protocolo TCP usa o three-way handshake para realizar um processo de conexão entre um cliente (IP e porta de origem) e um servidor (IP e porta de destino).
DNS (Domain Name System)-> Quando o tipo do registro DNS for do tipo "A", sua função é descobrir o endereço IP a partir de um nome (ou seja, um domínio ou subdomínio, ex: www.debian.org). Sem o DNS lembrar-se dos endereços dos websites seria muito mais difícil, pois por exemplo, você precisaria digitar no navegador http://140.211.15.34 ao invés de http://www.debian.org, precisaria decorar um novo IP caso fosse alterado o IP deste website, não conseguiria utilizar o recurso de virtual hosts baseado em URLs de um servidor WEB (ex: apache) etc, ou seja, DNS facilita em muito a nossa vida.
No ambiente montado para este artigo foi utilizado wireshark para captura dos pacotes enviados/recebidos e uma maquina virtual com as seguintes informações:
IP Fixo: 10.0.2.15/24 com MAC 08:00:27:02:E9:C0
Default GW: 10.0.2.2 com MAC 52:54:00:12:35:02
DNS Server: 208.67.222.222 (OpenDNS)
Abaixo segue os pacotes enviados e recebidos pela maquina virtual (VM) quando solicitou via browser (mais conhecido como navegador) o acesso ao website www.debian.org:
 |
| Fig. 1 - Clique na imagem para maximiza-la. |
Abaixo segue descrição por pacote, baseado na Fig. 1 acima:
Pacote 1-> Como o website encontra-se hospedado na Internet é necessário que a VM envie as requisições direcionadas a Internet para seu default gateway. Como essa é a primeira vez que a VM irá se comunicar com o gateway ela enviou um pacote do tipo "ARP Request" com origem na camada 2 08:00:27:02:E9:C0 e origem na camada 3 10.0.2.15 e destino na camada 2 FF:FF:FF:FF:FF:FF (Broadcast) e destino na camada 3 10.0.2.2 (veja as 2 origens e os 2 destinos na Fig.2 abaixo), perguntando para a rede interna quem tem o endereço IP 10.0.2.2 (Default GW), ou seja, todos os ativos presentes nessa rede (10.0.2.0/24) receberam esse pacote pelo fato do mesmo ser do tipo broadcast.
 |
| Fig. 2 - Mais detalhes do pacote 1. |
Pacote 2-> Somente o ativo de rede que detem o IP 10.0.2.2 respondeu para o endereço MAC da VM (através de um "ARP Reply") qual é o endereço MAC da interface configurada com o IP 10.0.2.2. Nesse momento a VM coloca o IP e MAC do Default GW em seu cache de tabela ARP e a mesma já pode enviar as requisições de acesso para a Internet, pois já conhece o MAC do gateway. Nesse caso o pacote tem como origem na camada 2 52:54:00:12:35:02 e na camada 3 10.0.2.2 e destino na camada 2 08:00:27:02:E9:C0 e na camada 3 10.0.2.15 (veja Fig.3 abaixo), o que faz do mesmo um pacote do tipo unicast.
 |
| Fig. 3 - Mais detalhes do pacote 2. |
Pacote 3-> Como a VM não acessou esse website ainda ela não conhece o endereço IP do mesmo (ou seja, não está em seu cache DNS local), sendo assim ela envia um pacote do tipo "DNS query" para o endereço do DNS Sever 208.67.222.222 perguntando qual é o endereço IP (registro do tipo A) do website www.debian.org. Na Fig. 4 abaixo fica claro como que um pacote é encaminhado (roteado) para a Internet pelo gateway, como podemos observar, a origem na camada 2 e 3 representa a VM, e o pacote é analisado pelo Default GW porque o destino informado na camada 2 é o endereço MAC da interface de rede do Default GW e o mesmo é roteado para a Internet porque o destino na camada 3 é o IP do DNS Server da OpenDNS (esse é um dos motivos de IP ter Internet no nome e o gateway identificar que o pacote deve ser roteado e não tratado localmente, pois para ser tratado localmente o IP de destino deveria ser 10.0.2.2).
 |
| Fig. 4 - Mais detalhes do pacote 3. |
Pacote 4-> O DNS Server 208.67.222.222 responde a solicitação feita pela VM com um "DNS response" informando que os endereços IP para o nome www.debian.org são: 140.211.15.34 e 128.31.0.51 (a resposta teve 2 IPs devido a utilização de round-robin DNS para o registro www.debian.org, suas vantagens básicas seriam o balanceamento de carga e a alta disponibilidade).
Pacote 5-> A VM então envia um pacote SYN com destino ao IP 140.211.15.34 e porta 80 TCP para iniciar o three-way handshake.
Pacote 6-> O webserver em execução no IP 140.211.15.34 e porta 80 TCP responde com um SYN+ACK para continuar o processo do three-way handshake.
Pacote 7-> Completando o three-way handshake (processo de conexão) a VM envia um pacote ACK com destino ao IP 140.211.15.34 e porta 80 TCP. A partir deste momento a VM e o webserver em execução no IP 140.211.15.34 podem trocar informações.
Pacote 8-> Em seguida a VM envia um pacote contendo a solicitação (GET / HTTP/1.1) feita pelo browser para o IP 140.211.15.34 na porta 80 TCP, ou seja, finalmente faz o pedido de visualização do conteúdo do diretório raiz (informado por exemplo, pelo parâmetro DocumentRoot do webserver Apache) do website.
Pacote 9 em diante-> É apresentado no browser a pagina central (geralmente o arquivo padrão index.html, mas nesse caso foi index.en.html, pois na solicitação enviada não continha nome de arquivo, quando isso acontece o webserver mostra o conteúdo do arquivo padrão presente no diretório, informado por exemplo, pelo parâmetro DirectoryIndex do Apache) do website www.debian.org com suas respectivas informações, imagens, links para outros setores do website, etc.
Enjoy!...
Enjoy!...
NOTA: Um leitor atento provavelmente percebeu que este artigo apenas descreveu um exemplo prático do uso e da relação entre IP e MAC numa rede TCP/IP, do protocolo ARP, serviço DNS, roteamento e o three-way handshake.
Para maiores detalhes veja os links abaixo:
Loammy, muito interessante, principalmente no fato de que muitas pessoas, mesmo muitas que trabalham com tecnologia, desconhecem o fato de como essas informações chegam ao seu navegador. Com certeza, deixou bem claro.
ResponderExcluirBoa sua observação sobre a relação do que vc escreveu. Para os curiosos, também podemos procurar saber como o Gateway se encarrega de interpretar e entregar todas as solicitações a seus respectivos remetentes e destinatários, um trabalho certamente complexo.
Para usuários nem tanto técnicos, encorajo-os que assistam esse video, que mostra o trabalho do gateway e parte do que nosso amigo Loammy nos contou. https://www.youtube.com/watch?v=hcKtffA1kvY
O intuito de escrever sobre esse assunto foi tentar ajudar o pessoal dando uma "visão prática" da relação de alguns protocolos... Esse vídeo que você mencionou é bem legal mesmo... Obrigado pelas considerações!
Excluir