Como a web funciona, do clique à página

1. As partes de uma URL

Uma URL é o endereço completo de algo na web. Veja cada parte desta:

https://loja.exemplo.com.br:443/produtos/camisa?cor=azul#avaliacoes

2. O caminho completo, em seis passos

1. DNS: o navegador descobre o IP do domínio. A lição Redes na prática mostra como.
2. Conexão: o navegador abre uma conexão com o servidor naquele IP, na porta 443.
3. TLS: navegador e servidor combinam uma criptografia, e o servidor prova quem é com um certificado digital.
4. Pedido: o navegador manda um pedido HTTP, por exemplo "me dê /produtos/camisa".
5. Resposta: o servidor devolve um código de status, cabeçalhos e o conteúdo, normalmente HTML.
6. Montagem: o navegador lê o HTML, descobre que precisa de CSS, JavaScript, imagens e fontes, e faz um novo pedido para cada um. Só então a página aparece completa.

Uma página comum dispara dezenas de pedidos. Em sites grandes, passa de uma centena.

3. Pedido e resposta HTTP

HTTP é a língua que navegador e servidor falam. Por baixo, um pedido é um texto organizado assim:

GET /produtos/camisa?cor=azul HTTP/1.1
Host: loja.exemplo.com.br
User-Agent: Mozilla/5.0 ...
Accept: text/html
Accept-Language: pt-BR

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=300

<!doctype html>
<html> ... a página ... </html>

A primeira linha do pedido tem o método e o caminho. As linhas seguintes são cabeçalhos (headers), informações extras em pares nome: valor. Na resposta, depois dos cabeçalhos vem uma linha em branco e o corpo, que é o conteúdo.

Os métodos mais usados

O HTTP não guarda memória entre um pedido e outro: cada pedido chega ao servidor como se fosse o primeiro. É por isso que existem os cookies, que você vê na parte 8.

Hoje, a maioria dos sites usa HTTP/2 ou HTTP/3, que mandam várias coisas ao mesmo tempo pela mesma conexão e em formato binário, mais rápido. A ideia de pedido, cabeçalhos, status e corpo continua a mesma.

4. Códigos de status

Toda resposta traz um número de três dígitos. O primeiro dígito já diz muito:

Saber a faixa já direciona a investigação: com 4xx, confira o que foi pedido; com 5xx, olhe os logs do servidor.

5. Ver tudo nas ferramentas do navegador

Todo navegador moderno tem ferramentas de desenvolvedor (DevTools). Abra com F12 ou Ctrl+Shift+I no Windows e no Linux, ou Cmd+Option+I no Mac. No Safari, ative antes as ferramentas para desenvolvedores nos ajustes avançados do navegador.

1. Abra um site qualquer e as ferramentas de desenvolvedor.
2. Vá na aba Network (Rede).
3. Recarregue a página com F5. Cada linha que aparece é um pedido.
4. Clique no primeiro pedido, o do HTML. Em Headers, veja o método, o status e os cabeçalhos do pedido e da resposta. Em Response ou Preview, veja o conteúdo.

Repare também nas colunas Status, Type (tipo do arquivo), Size e Time. A barra de baixo mostra quantos pedidos a página fez e quanto tempo levou.

6. HTTP pelo terminal com curl

O curl faz pedidos HTTP pelo terminal. Ele já vem instalado no Linux, no Mac e no Windows 10 e 11. No PowerShell, digite curl.exe em vez de curl, porque curl sozinho chama outro comando.

curl -I https://www.wikipedia.org

O -I pede só o status e os cabeçalhos, sem o corpo. Para ver a conversa inteira, inclusive a conexão e o certificado:

curl -v https://www.wikipedia.org -o /dev/null

As linhas que começam com > são o que o curl mandou. As que começam com < são o que o servidor respondeu. O -o /dev/null descarta o corpo para não encher a tela (no Windows, use -o NUL).

Para ver um redirecionamento:

curl -I http://wikipedia.org

HTTP/1.1 301 Moved Permanently
location: https://wikipedia.org/

O servidor respondeu 301 e mandou ir para a versão com HTTPS. O navegador segue o redirecionamento sozinho; o curl só segue com a opção -L.

7. HTTPS: o cadeado

HTTPS é o HTTP dentro de uma conexão criptografada com TLS. Ele garante três coisas:

• Sigilo: quem está no meio do caminho, como alguém no mesmo Wi-Fi público, não consegue ler o que trafega.
• Integridade: ninguém consegue alterar os dados no caminho sem ser percebido.
• Identidade: o certificado prova que o servidor é mesmo dono daquele domínio. Ele é emitido por uma autoridade certificadora em que o navegador confia. O Let's Encrypt emite certificados de graça, e muitos serviços de hospedagem já configuram o HTTPS sozinhos.

8. Cookies e sessões

Como o HTTP não guarda memória, o servidor precisa de um jeito de reconhecer você de um pedido para o outro. Depois do login, ele responde com um cabeçalho Set-Cookie, e o navegador passa a mandar esse cookie em todo pedido seguinte para aquele site:

Set-Cookie: sessao=a8f3k2...; Secure; HttpOnly; SameSite=Lax

• Secure: só vai por HTTPS.
• HttpOnly: o JavaScript da página não consegue ler, o que dificulta o roubo do cookie.
• SameSite: limita o envio do cookie quando o pedido vem de outro site.

Quem tem o cookie de sessão age como você naquele site. Por isso, nunca compartilhe cookies nem prints que mostrem cabeçalhos de pedidos logados. Nas ferramentas de desenvolvedor, os cookies ficam na aba Application (Chrome e Edge) ou Storage (Firefox).

9. Cache e CDN: por que alguns sites são tão rápidos

Cache é guardar uma cópia para não buscar de novo. O servidor diz, no cabeçalho Cache-Control, por quanto tempo a cópia vale. Logos, fontes e arquivos CSS costumam ficar em cache por dias.

Uma CDN (rede de entrega de conteúdo), como Cloudflare, Fastly ou Google Cloud CDN, tem servidores espalhados pelo mundo que guardam cópias dos arquivos do site. Quem acessa de São Paulo recebe a cópia de um servidor próximo, sem precisar ir até o servidor original. Além de acelerar, a CDN aguenta picos de acesso e filtra ataques.

Ao rodar curl -I num site atrás de uma CDN, você costuma ver cabeçalhos extras, como cf-cache-status na Cloudflare ou age, que diz há quantos segundos a cópia está em cache.

10. APIs: quando a resposta não é uma página

Muitas vezes, o que volta do servidor não é HTML, e sim dados, quase sempre em JSON. É assim que aplicativos de celular e sites modernos conversam com o backend (a parte do sistema que roda no servidor): por uma API, um conjunto de endereços que recebem e devolvem dados.

curl https://api.github.com/users/octocat

{
  "login": "octocat",
  "name": "The Octocat",
  ...
}

JSON organiza os dados em pares "nome": valor entre chaves. A mesma lógica de métodos, status e cabeçalhos vale aqui: um GET busca dados, um POST cria, e o código de status diz se deu certo.

11. Missão final

curl -sI https://www.cloudflare.com | grep -i -E "server|cache"

curl -sIL http://github.com | grep -i -E "^HTTP|^location"