O que acontece quando você acessa um site?

A URL inicia um plano, não um único pacote

Quando você digita https://portal.example.com/trilhas?tema=redes#modulo-4, o navegador não envia essa linha inteira ao DNS nem existe um “pacote do site” que percorre sozinho a Internet. Primeiro, o cliente interpreta a URL e distribui responsabilidades.

A origem combina esquema, host e porta. Duas URLs podem apontar para caminhos diferentes da mesma origem e reutilizar estado de conexão; mudar host, porta ou esquema pode exigir novas decisões.

Esta aula reúne a trilha inteira. Os links levam às explicações canônicas de cada mecanismo; aqui o objetivo é enxergar como as peças cooperam e onde procurar quando algo diverge.

O navegador começa pelo que já possui

Antes de criar tráfego, o navegador e o sistema podem consultar estado local:

• uma resposta HTTP ainda válida no cache;
• uma conexão aberta e apropriada para a origem;
• uma resolução DNS em cache;
• políticas que exigem HTTPS;
• um Service Worker capaz de responder ou intermediar a requisição;
• configurações de proxy;
• credenciais, cookies e estado da aplicação;
• dados pré-carregados ou uma navegação já em andamento.

Se uma resposta fresca e aplicável estiver disponível, parte da jornada pode terminar localmente. Se a conexão segura ainda estiver aberta, DNS e handshakes podem não aparecer na captura daquela navegação. “Não vi uma consulta” não significa automaticamente “DNS não foi usado”; o resultado pode ter sido obtido antes.

O dispositivo também precisa estar configurado. Em uma rede comum, DHCP, Router Advertisements e outros mecanismos já forneceram endereço, prefixo, gateway e resolvedor. Se essa base falha, o navegador talvez nem alcance a etapa web.

DNS oferece candidatos, não escolhe sozinho a conexão

Para portal.example.com, o cliente pode precisar de registros A e AAAA. Um resolvedor recursivo responde do cache ou percorre delegações até a autoridade, conforme explicado em DNS e resolução de nomes.

O resultado pode conter vários endereços. Registros HTTPS/SVCB também podem anunciar endpoints e parâmetros, como protocolos de aplicação disponíveis. O DNS fornece dados; ele não garante que cada endereço esteja alcançável naquele instante.

Clientes dual stack normalmente ordenam candidatos e escalonam tentativas para evitar esperar demais por uma família quebrada. A técnica conhecida como Happy Eyeballs favorece conectividade funcional sem transformar “IPv6 primeiro” ou “IPv4 primeiro” em espera rígida. Quando uma tentativa vence, as demais podem ser canceladas.

Isso produz consequências importantes:

• o endereço usado pode variar entre acessos;
• A e AAAA podem ser consultados de forma assíncrona;
• conexão e resolução podem se sobrepor;
• o primeiro endereço da resposta não é obrigatoriamente o escolhido;
• uma CDN pode responder com destinos diferentes conforme rede, política ou localização;
• sucesso em IPv4 não prova que IPv6 esteja saudável, e vice-versa.

A ordem observada pode encurtar ou se sobrepor

Em um primeiro acesso sem cache, a jornada lógica pode incluir URL, DNS, conexão segura, pedido HTTP e recursos. Em acessos posteriores, cache e reutilização cortam etapas. Navegadores também antecipam trabalho quando possuem evidências suficientes.

Não some automaticamente “tempo de DNS + TCP + TLS + resposta” medido por ferramentas diferentes. A consulta pode começar junto com outra tarefa; QUIC integra negociação criptográfica ao transporte; uma conexão reutilizada elimina estabelecimento; a resposta pode chegar em fluxo enquanto o servidor ainda a produz.

O próximo salto precisa de uma entrega no enlace

Depois de escolher um endereço de destino, o sistema consulta sua tabela de rotas. Se o servidor não pertence ao prefixo local, o próximo salto costuma ser o gateway padrão. O host precisa então do endereço de enlace desse próximo salto.

Em Ethernet ou Wi-Fi, isso pode envolver:

• ARP para relacionar IPv4 ao endereço MAC do vizinho;
• Neighbor Discovery para localizar vizinhos IPv6;
• uma associação Wi-Fi e proteção do enlace já estabelecidas;
• um quadro destinado ao ponto de acesso ou gateway, não ao MAC do servidor remoto.

A aula Ethernet, endereços MAC, ARP e NDP explica essa fronteira. O endereço MAC é útil naquele enlace. Cada roteador remove o quadro recebido e cria outro apropriado ao próximo trecho; o MAC do notebook não atravessa a Internet como identidade ponta a ponta.

Roteadores repetem decisões locais

O pacote IP chega ao gateway, que procura o prefixo mais específico aplicável e escolhe um próximo salto. Outros roteadores repetem o processo. Eles não precisam conhecer a URL, o HTML nem a intenção do usuário.

O caminho de ida pode incluir rede de acesso, operadora, trânsito e a rede que hospeda um CDN ou servidor. O caminho de volta não precisa ser geometricamente igual. Rotas podem mudar durante conexões longas, desde que a conectividade e os estados intermediários continuem compatíveis.

No IPv4 doméstico, NAT pode trocar endereço e porta de origem e manter uma associação para o retorno. Ele não é etapa obrigatória de toda Internet e não deve ser inserido no desenho de uma conexão IPv6 apenas por hábito.

No caminho, o tamanho máximo de pacote, ICMP, filas, perda e congestionamento também influenciam a experiência. Uma página lenta não implica necessariamente servidor lento: rádio ocupado, retransmissão, RTT, congestionamento, CPU, armazenamento ou dependências podem dominar momentos diferentes.

A conexão segura pode usar TCP ou QUIC

Para HTTPS, duas famílias comuns aparecem:

HTTP/1.1 ou HTTP/2 sobre TCP e TLS

O cliente estabelece uma conexão TCP com o endpoint, geralmente usando a porta 443. O handshake TCP sincroniza estado de transporte. Em seguida, TLS negocia parâmetros criptográficos, autentica o servidor segundo o contexto e deriva chaves para proteger os dados.

Durante TLS, extensões cumprem papéis importantes:

• SNI indica o nome pretendido quando vários serviços compartilham um endpoint;
• ALPN permite selecionar um protocolo de aplicação, como http/1.1 ou h2;
• grupos e algoritmos apoiam a negociação criptográfica;
• o certificado e as provas correspondentes permitem validar a identidade apresentada.

HTTP/3 sobre QUIC

QUIC é um transporte seguro sobre UDP. Ele integra TLS 1.3 ao handshake, oferece identificadores de conexão, recuperação de perdas, controle de congestionamento e múltiplos streams. HTTP/3 mapeia a semântica HTTP nesses streams.

“Usa UDP” não significa que HTTP/3 perdeu confiabilidade. A confiabilidade relevante é fornecida pelo QUIC. Se UDP estiver bloqueado ou o endpoint HTTP/3 falhar, clientes podem tentar versões baseadas em TCP; o comportamento exato depende das alternativas conhecidas e da implementação.

TLS protege o canal, não julga o conteúdo

Na validação baseada em certificados, o cliente verifica elementos como:

• se o certificado é aplicável ao nome da origem;
• se o período de validade é compatível com o relógio;
• se a cadeia conduz a uma âncora de confiança aceita;
• se assinaturas e parâmetros atendem à política;
• se o servidor prova possuir a chave correspondente.

Depois do handshake, TLS oferece confidencialidade e integridade entre os endpoints TLS. Isso impede que um observador comum leia ou altere silenciosamente o conteúdo protegido naquele trecho.

Mas o cadeado não significa que a informação é verdadeira, ética ou livre de malware. Um site malicioso também pode obter certificado para o próprio domínio. TLS não protege um navegador comprometido, um servidor invadido nem dados depois de descriptografados nas pontas.

Proxies corporativos e CDNs podem terminar TLS quando fazem parte da arquitetura e possuem certificados e confiança apropriados. Nesse caso, podem existir conexões TLS diferentes por trecho, não um túnel criptográfico único até o processo final da aplicação.

A página Criptografia, hash e assinatura digital aprofunda os mecanismos. Aqui, guarde a separação entre autenticidade do endpoint, proteção do canal e confiabilidade do conteúdo.

HTTP expressa a intenção da requisição

Com a conexão apropriada disponível, o navegador envia uma mensagem HTTP. Conceitualmente, uma navegação pode produzir:

GET /trilhas?tema=redes HTTP/1.1
Host: portal.example.com
Accept: text/html

HTTP/2 e HTTP/3 não usam essa mesma representação textual na rede, mas preservam a semântica: método, URI de destino, campos e conteúdo. GET pede uma representação do recurso; não significa “baixar um arquivo físico com esse nome”.

Outros campos podem comunicar tipos aceitos, idiomas, codificações, condições de cache, credenciais e contexto. Cookies são campos HTTP conforme regras próprias; não são enviados ao DNS nem fazem parte do handshake TCP.

O servidor ou intermediário reconstrói o alvo, aplica roteamento, autenticação, cache e lógica. A origem pode ser atendida por:

• um cache local ou compartilhado;
• um proxy de saída;
• um CDN na borda;
• um balanceador ou reverse proxy;
• um servidor de aplicação;
• outros serviços internos invisíveis ao navegador.

“O IP do site” pode, portanto, identificar uma borda compartilhada, não a máquina que gerou o conteúdo. O protocolo HTTP aceita cadeias de intermediários, e cada conexão da cadeia pode ter características próprias.

A resposta traz status, metadados e representação

Uma resposta inclui status, campos e possivelmente conteúdo. Exemplos:

O status não conta toda a história. Um 200 pode conter uma página de erro criada pela aplicação; um 304 depende de uma representação já armazenada; um 404 prova que o servidor respondeu, não que DNS ou TCP falharam.

Campos como Content-Type orientam a interpretação. Content-Encoding pode indicar compressão. Cache-Control, ETag, Last-Modified, Vary e Age participam do cache. O corpo pode chegar em partes e ser processado antes do fim, conforme versão HTTP, intermediários e implementação.

O HTML inicia novas buscas

Receber HTML não conclui necessariamente a página. Ao analisar o documento, o navegador encontra referências a:

• folhas CSS;
• scripts;
• imagens e vídeos;
• fontes;
• módulos;
• manifests;
• frames;
• chamadas feitas posteriormente por código.

Cada referência é resolvida contra uma URL base e passa por decisões de cache, origem, prioridade e conexão. Recursos da mesma origem podem compartilhar conexão; outra origem pode exigir DNS e conexão próprios. Redirecionamentos podem mudar novamente o destino.

CSS pode participar do cálculo visual; scripts podem alterar o documento, solicitar dados ou bloquear determinadas etapas; fontes e imagens podem mudar o layout. O navegador pode descobrir recursos antecipadamente, priorizar o documento principal e executar downloads concorrentes. Não existe uma ordem universal “HTML inteiro, depois CSS inteiro, depois JavaScript inteiro, depois imagens”.

Quando dados suficientes chegam, o navegador constrói estruturas internas, calcula estilos e layout, pinta e compõe pixels. Essas atividades de CPU e GPU podem continuar depois que a rede terminou. “Carregou” depende do marco observado: primeira resposta, DOM, evento load, conteúdo visível, estabilidade ou interação.

As versões HTTP compartilham semântica

HTTP/1.1, HTTP/2 e HTTP/3 usam os mesmos conceitos de métodos, status e campos, mas organizam mensagens e conexões de formas diferentes.

No HTTP/1.1, conexões podem ser persistentes, mas uma conexão não oferece a multiplexação de streams de HTTP/2 e HTTP/3. Clientes podem usar mais de uma conexão, com custos e limites.

HTTP/2 multiplexa streams sobre uma conexão TCP. Isso evita que uma resposta HTTP tenha de esperar logicamente a resposta anterior, mas uma perda TCP interrompe temporariamente a entrega ordenada de bytes posteriores da conexão aos streams.

HTTP/3 usa streams QUIC. Uma perda que afeta dados de um stream não exige bloquear a entrega ordenada de outros streams por causa daquele byte ausente. Ainda existem largura de banda compartilhada, congestionamento, limites de fluxo, perdas de pacotes e dependências da página.

Uma rede pode favorecer TCP, outra pode permitir QUIC com menos custo. Reutilização, RTT, servidor, tamanho, prioridade e perdas pesam mais que o número da versão isolado.

Cache pode responder, reutilizar ou validar

Uma resposta HTTP fresca e aplicável pode ser reutilizada sem consultar a origem. Quando está stale, o cliente ou cache pode fazer uma requisição condicional:

If-None-Match: "versao-abc"

Se a representação não mudou, 304 Not Modified atualiza metadados e permite reutilizar o corpo armazenado. Se mudou, o servidor envia uma nova representação, normalmente com 200.

no-cache não significa obrigatoriamente “não armazenar”; exige validação antes de reutilizar. no-store instrui a não armazenar nos caches aos quais se aplica. Vary acrescenta campos da requisição à seleção da resposta. Cache privado do navegador e cache compartilhado têm regras e riscos diferentes.

Cache HTTP e cache DNS são independentes. Limpar um não garante apagar o outro. Um Service Worker pode acrescentar ainda outra política local. Diagnóstico precisa identificar qual camada forneceu o resultado observado.

Redirecionamento inicia uma nova decisão

Se a resposta contém Location, o navegador interpreta a nova referência e decide se deve segui-la. O novo alvo pode:

• manter a origem e trocar apenas o caminho;
• mudar http para https;
• trocar host e exigir outro DNS;
• usar outra porta;
• alterar método conforme o status e as regras aplicáveis;
• formar uma cadeia ou um loop.

DNS CNAME não é redirecionamento HTTP: ele auxilia a resolução de nome sem instruir a barra de endereço. Um 301, 302, 307 ou 308 é uma resposta HTTP recebida depois que alguma conexão já alcançou um serviço.

Tempos localizam trabalho, não culpados automáticos

Ferramentas costumam mostrar marcos como:

• fila e bloqueio antes da requisição;
• DNS;
• estabelecimento de conexão;
• TLS;
• envio da requisição;
• espera pelo primeiro byte;
• transferência;
• processamento e renderização.

Time to First Byte reúne rede, filas, intermediários e tempo para o primeiro byte da resposta; não mede apenas banco de dados ou servidor. Um TTFB curto também não garante página rápida se recursos, JavaScript ou imagens dominarem depois.

RTT alto amplia handshakes e dependências seriais. Largura de banda pesa mais em grandes transferências. Perda provoca recuperação e pode reduzir a janela de congestionamento. CPU e servidor podem dominar antes do primeiro byte. A melhoria correta depende do gargalo medido.

Diagnostique pela primeira divergência

Quando “o site não abre”, percorra a jornada com evidências:

1. confirme URL, esquema, host, porta e proxy;
2. verifique se o problema ocorre em um recurso, origem ou em toda a rede;
3. confira endereço, prefixo, gateway e resolvedor do cliente;
4. compare cache local, Service Worker e navegação privada quando aplicável;
5. observe A, AAAA, HTTPS/SVCB, RCODE, TTL e resolvedor usado;
6. identifique o endpoint realmente escolhido;
7. teste IPv4 e IPv6 separadamente sem assumir que falham juntos;
8. confirme ARP/NDP do gateway e rota de saída;
9. procure tradução e estado se houver NAT ou CGNAT;
10. observe SYN/SYN-ACK/ACK em TCP ou handshake QUIC;
11. valide certificado, nome, relógio, cadeia, SNI e ALPN;
12. examine método, alvo, status, Location e campos HTTP;
13. procure proxy, CDN, balanceador e logs correlacionados;
14. diferencie HTML principal de recurso secundário que falhou;
15. compare cache hit, validação e resposta da origem;
16. se a rede terminou, investigue parse, script, estilo, layout e aplicação.

O código de erro do navegador é pista, não veredito. ERR_NAME_NOT_RESOLVED, timeout de conexão, alerta de certificado e HTTP 503 pertencem a etapas diferentes. Começar pela primeira divergência reduz mudanças aleatórias.

Erros comuns sobre o acesso a sites

• “o navegador manda a URL ao DNS”: DNS recebe nomes e tipos de registro, não caminho, query ou fragmento;
• “sempre consulta raiz, TLD e autoridade”: cache pode responder em vários níveis;
• “o primeiro IP retornado é usado”: o cliente seleciona e pode escalonar tentativas;
• “MAC do notebook chega ao servidor”: quadros são reconstruídos em cada enlace;
• “todo acesso usa NAT”: depende da arquitetura e da família de endereços;
• “roteadores leem a página”: encaminhamento IP não exige interpretar HTML;
• “HTTPS significa TCP”: HTTP/3 usa QUIC sobre UDP;
• “UDP torna HTTP/3 não confiável”: QUIC implementa entrega confiável por stream;
• “cadeado prova que o site é honesto”: TLS protege o canal e autentica dentro de um modelo de confiança;
• “um domínio corresponde a um servidor”: CDNs, proxies e balanceadores distribuem funções;
• “200 significa que tudo funcionou”: recursos secundários e aplicação ainda podem falhar;
• “HTML é a página inteira”: ele normalmente referencia outros recursos;
• “HTTP/3 é sempre mais rápido”: rede, reutilização, RTT, perda e implementação decidem;
• “no-cache proíbe armazenamento”: normalmente exige validação antes de reutilizar;
• “TTFB é tempo do backend”: inclui caminho, filas e intermediários;
• “evento load significa experiência concluída”: diferentes marcos respondem a perguntas diferentes.

O que você deve guardar

O navegador interpreta a URL, consulta estado local e encontra candidatos de endpoint por DNS. O sistema escolhe rota e próximo salto; quadros entregam pacotes em cada enlace, roteadores conduzem o IP e NAT pode traduzir IPv4 em determinadas fronteiras.

O acesso HTTPS estabelece proteção usando TCP + TLS ou QUIC com TLS integrado. ALPN relaciona a conexão a uma versão HTTP. O cliente envia uma requisição; caches, CDNs, proxies e servidores podem participar antes que uma resposta volte.

O HTML recebido normalmente descobre outros recursos. Cache, conexões reutilizadas e tarefas concorrentes tornam a jornada uma árvore parcialmente sobreposta, não uma fila fixa. Para diagnosticar, identifique a primeira etapa que produz resultado diferente do esperado.

Referências

• IETF — RFC 3986: Uniform Resource Identifier. Acesso em 29 ago. 2026.
• IETF — RFC 8305: Happy Eyeballs Version 2. Acesso em 29 ago. 2026.
• IETF — RFC 8446: TLS 1.3. Acesso em 29 ago. 2026.
• IETF — RFC 9000: QUIC. Acesso em 29 ago. 2026.
• IETF — RFC 9110: HTTP Semantics. Acesso em 29 ago. 2026.
• IETF — RFC 9111: HTTP Caching. Acesso em 29 ago. 2026.
• IETF — RFC 9112: HTTP/1.1. Acesso em 29 ago. 2026.
• IETF — RFC 9113: HTTP/2. Acesso em 29 ago. 2026.
• IETF — RFC 9114: HTTP/3. Acesso em 29 ago. 2026.
• IETF — RFC 9460: SVCB and HTTPS Resource Records. Acesso em 29 ago. 2026.