Como a internet funciona do DNS ao HTTP

Você digita github.com no navegador e meio segundo depois a página carrega. Parece simples. Por baixo, aconteceu uma cadeia de operações que envolve pelo menos quatro protocolos distintos, múltiplos servidores em lugares diferentes do planeta, e uma quantidade razoável de coisas que podem dar errado em qualquer etapa. Entender o que acontece nesse meio segundo não é curiosidade acadêmica — é o que diferencia debugar um timeout de procurar problema em lugar errado por uma hora.

O que é um endereço IP e por que você precisa dele

Antes de falar de DNS, é preciso entender o problema que ele resolve.

Toda máquina conectada à internet tem um endereço IP — um número que funciona como endereço postal da rede. No IPv4, esse número tem formato 203.0.113.42. No IPv6, é uma sequência mais longa como 2001:db8::1. O roteador da sua casa tem um IP. O servidor do GitHub tem um IP. Para duas máquinas se comunicarem, uma precisa saber o IP da outra.

O problema é óbvio: ninguém memoriza 140.82.112.3 para acessar o GitHub. O DNS existe para resolver esse problema.

O que é DNS e o que acontece na consulta

DNS significa Domain Name System — é o sistema que traduz nomes legíveis (github.com) para endereços IP (140.82.112.3).

Quando você digita um endereço no navegador, a primeira coisa que acontece é uma consulta DNS. O processo segue uma hierarquia:

1. Cache local. O sistema operacional verifica se já resolveu esse nome recentemente. Se sim, usa o resultado em cache e pula as etapas seguintes.

2. Resolver recursivo. Se não há cache, a consulta vai para o resolver DNS configurado na sua rede — geralmente o do seu ISP, ou um público como 8.8.8.8 (Google) ou 1.1.1.1 (Cloudflare).

3. Root nameserver. O resolver pergunta a um dos 13 conjuntos de root nameservers: "quem cuida do domínio .com?" O root server responde com o endereço dos servidores TLD.

4. TLD nameserver. O resolver pergunta ao servidor de .com: "quem cuida de github.com?" Esse servidor responde com os nameservers autoritativos do domínio.

5. Nameserver autoritativo. Finalmente, o resolver pergunta ao nameserver do próprio GitHub: "qual é o IP de github.com?" Esse servidor tem a resposta definitiva.

Todo esse processo acontece em milissegundos. O resultado é armazenado em cache por um período definido pelo TTL (Time to Live) do registro — pode ser 5 minutos ou 24 horas, dependendo de como o domínio está configurado.

Navegador
  → Cache local (sem resultado)
    → Resolver recursivo (8.8.8.8)
      → Root nameserver (. → .com)
        → TLD nameserver (.com → github.com)
          → Nameserver autoritativo (github.com → 140.82.112.3)
        ← IP retorna por toda a cadeia
  ← Navegador agora tem o IP

Vale notar: para a maioria das requisições do dia a dia, os passos 3 e 4 são pulados porque o resolver já tem em cache os nameservers dos domínios mais acessados. Na prática, muitas consultas DNS levam menos de 20ms.

TCP/IP: como os bytes chegam de um lado ao outro

Com o IP em mãos, o navegador precisa estabelecer uma conexão. É aqui que entram TCP e IP — dois protocolos que funcionam em camadas diferentes.

IP (Internet Protocol) é responsável pelo endereçamento e roteamento: pega um pacote de dados, coloca o endereço de origem e destino, e envia. IP é best-effort — ele tenta entregar, mas não garante que o pacote vai chegar, nem que vai chegar na ordem certa.

TCP (Transmission Control Protocol) resolve os problemas que o IP não resolve. TCP é orientado a conexão e garante:

• Que os pacotes chegam (e pede reenvio se não chegarem)
• Que chegam na ordem correta
• Que não há dados duplicados
• Controle de fluxo para não sobrecarregar o receptor

Antes de qualquer dado ser enviado, TCP estabelece a conexão com um handshake de três vias:

Cliente → SYN      → Servidor   ("quero conectar")
Cliente ← SYN-ACK ← Servidor   ("ok, pode conectar")
Cliente → ACK      → Servidor   ("confirmado, conexão aberta")

Só depois desse handshake o navegador começa a enviar a requisição HTTP. Isso adiciona latência — tipicamente uma ida e volta (round-trip) antes do primeiro byte de dado. Em conexões de alta latência, esse custo é perceptível.

O IP do pacote navega pela internet através de roteadores. Cada roteador olha para o endereço de destino e decide para onde encaminhar o pacote — como um sistema postal que reencaminha cartas pelo caminho mais eficiente disponível naquele momento. A rota pode mudar entre pacotes diferentes da mesma conexão.

HTTP: a linguagem que o navegador e o servidor falam

Com a conexão TCP estabelecida, o navegador faz a requisição HTTP. HTTP é um protocolo de texto — é literalmente uma mensagem de texto estruturada.

Uma requisição GET simples parece assim:

GET / HTTP/1.1
Host: github.com
Accept: text/html
User-Agent: Mozilla/5.0

O servidor recebe, processa, e responde:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 12345

<!DOCTYPE html>...

O status code na primeira linha da resposta é o que o navegador usa para decidir o que fazer. 200 significa sucesso. 301 ou 302 é redirect — o navegador faz uma nova requisição para a URL indicada no header Location. 404 significa que o recurso não existe. 500 é erro no servidor.

HTTPS e TLS: a camada de segurança

Hoje praticamente toda navegação usa HTTPS, não HTTP. A diferença é a camada TLS (Transport Layer Security) entre o TCP e o HTTP.

Antes de enviar qualquer dado, o cliente e o servidor fazem um TLS handshake:

1. O servidor apresenta seu certificado digital, que prova que ele é quem diz ser (emitido por uma CA — Certificate Authority — confiável)
2. Os dois lados negociam algoritmos criptográficos e trocam chaves
3. A partir daí, tudo é criptografado

Isso adiciona mais uma ida e volta antes do primeiro byte de dado HTTP. Conexões modernas com TLS 1.3 reduziram isso para zero RTTs adicionais em reconexões, mas o impacto ainda é relevante em conexões novas.

O cadeado no navegador confirma que o certificado é válido e que a conexão está criptografada. Não confirma que o site é confiável — só que a comunicação com ele é privada.

O que acontece depois do HTTP/1.1

HTTP/1.1 tem um problema sério: head-of-line blocking. Em cada conexão TCP, as requisições são atendidas em fila — a segunda só começa quando a primeira termina. Para carregar uma página com 50 recursos (JS, CSS, imagens), o navegador abre múltiplas conexões TCP paralelas, o que tem seus próprios custos.

HTTP/2 resolveu isso com multiplexação: múltiplas requisições e respostas fluem pela mesma conexão TCP em paralelo, como streams independentes. Um atraso em um recurso não bloqueia os outros.

HTTP/3 vai mais fundo e troca TCP por QUIC — um protocolo sobre UDP que implementa a confiabilidade do TCP sem o problema de head-of-line blocking no nível de transporte. QUIC também integra TLS 1.3, eliminando um RTT do handshake. É o protocolo que o Google e a Cloudflare já usam para a maioria do tráfego.

Onde está meu IP nessa história toda

Quando o servidor do GitHub recebe a sua requisição, ele vê o IP de saída da sua rede — não o IP do seu dispositivo. Se você está em casa, é o IP público do seu roteador, atribuído pelo ISP. Se você está atrás de um proxy corporativo, é o IP do proxy. Se está usando VPN, é o IP do exit node da VPN.

Esse IP diz ao servidor onde a conexão originou — a nível de rede, não de pessoa. Para saber o seu próprio IP público e o que ele revela (ISP, ASN, localização aproximada), uso o IP Address Info — você vê em tempo real o que qualquer servidor enxerga quando você faz uma requisição.

Perguntas frequentes

Por que o site demora a carregar mesmo com boa internet?

Alta largura de banda não resolve latência. Se o servidor está fisicamente distante, cada ida e volta na rede adiciona milissegundos — e o handshake TCP+TLS precisa de pelo menos 2 RTTs antes do primeiro byte de dado. CDNs (Content Delivery Networks) existem exatamente para colocar servidores fisicamente mais próximos dos usuários e reduzir esse custo.

O que é um IP dinâmico e por que muda?

ISPs residenciais geralmente não atribuem um IP fixo para cada cliente — eles mantêm um pool de endereços e atribuem conforme necessário. Quando o roteador reconecta, pode receber um IP diferente. IP estático (fixo) é um serviço adicional, comum em contratos corporativos.

DNS pode ser hackeado?

Sim. DNS spoofing (ou DNS cache poisoning) é um ataque onde um resolver recebe respostas falsas e começa a retornar IPs errados para domínios legítimos. Isso redireciona o usuário para um servidor malicioso sem que o nome do domínio mude. DNSSEC adiciona assinaturas criptográficas às respostas DNS para mitigar isso, mas a adoção ainda é parcial.

Por que o ping para um domínio às vezes retorna um IP diferente do que o site usa?

Muitos servidores usam balanceamento de carga — o DNS retorna IPs diferentes para requisições diferentes, distribuindo o tráfego entre múltiplos servidores. O ping resolve o DNS no momento em que é executado e usa aquele IP. Uma requisição HTTP feita um segundo depois pode ir para um servidor diferente.

Do nome ao byte: o que importa saber

A cadeia completa — DNS, IP, TCP, TLS, HTTP — foi projetada em camadas independentes. Cada camada resolve um problema específico e não precisa saber como as outras funcionam. Isso é o que permite trocar HTTP/1.1 por HTTP/3 sem mudar como o DNS funciona, ou usar IPv6 sem mudar o protocolo de aplicação.

Para debugar problemas de rede, entender onde está o gargalo é tudo. Timeout de DNS é diferente de timeout de conexão TCP, que é diferente de erro HTTP 503. Quando você sabe que o problema está na resolução DNS, não vai passar meia hora ajustando timeout de conexão. Quando você sabe que o certificado TLS expirou, não vai suspeitar do banco de dados.

A internet parece simples por fora porque cada camada faz bem o seu trabalho. Por dentro, é engenharia de décadas que ainda está evoluindo.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação de ferramenta relacionada ao tema do post.

Ferramenta relacionada

Para ver seu IP público, ISP, ASN e localização aproximada em tempo real — o mesmo dado que qualquer servidor enxerga quando você faz uma requisição — o IP Address Info mostra tudo isso no navegador, sem enviar nada para servidor externo. Útil especialmente para confirmar o que muda quando você ativa uma VPN.