HTTP, TCP e DNS: antes do seu código rodar

Antes do Framework — Ep. 02

Etapa 1 da ordem: entender o que acontece antes de qualquer linha de código sua ser executada.

Você já abriu o DevTools, viu um erro net::ERR_CONNECTION_REFUSED ou um 404 Not Found e ficou olhando sem saber por onde começar?

Ou então: sua API funciona no local, mas em produção simplesmente não responde. Você trocou a URL, reiniciou o servidor, rezou. Nada.

Esses problemas têm solução. Mas só aparecem de forma óbvia quando você entende o que acontece debaixo do framework.

O que acontece quando você digita uma URL e aperta Enter

Parece mágica. Mas é uma cadeia de eventos muito bem definida.

Vamos usar https://vick1st.com como exemplo:

1. DNS: traduzindo nome para endereço

Seu computador não sabe onde fica vick1st.com. Ele pergunta para um servidor DNS: "Qual o IP desse domínio?"

O DNS responde: 76.76.21.21.

Agora seu computador sabe para onde mandar a requisição. É como ligar para uma central de informações e perguntar o endereço de uma empresa antes de ir até lá.

2. TCP: estabelecendo a conexão

Com o IP em mãos, seu computador precisa abrir uma conexão com o servidor. O TCP faz isso através do three-way handshake:

Cliente → Servidor: "Oi, posso falar?" (SYN)
Servidor → Cliente: "Pode sim, pode falar" (SYN-ACK)
Cliente → Servidor: "Certo, vou começar" (ACK)

Só depois disso a comunicação começa. Esse processo garante que os dois lados estão prontos antes de trocar dados.

3. HTTP: fazendo o pedido

Com a conexão aberta, o browser manda uma requisição HTTP:

GET / HTTP/1.1
Host: vick1st.com
Accept: text/html

O servidor processa, encontra o conteúdo e responde:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>...

Pronto. O browser renderiza o HTML e você vê a página.

HTTP na prática: os conceitos que você usa todo dia

Métodos

Cada requisição tem um método que indica a intenção:

Método	Uso
`GET`	Buscar dados
`POST`	Criar algo
`PUT` / `PATCH`	Atualizar
`DELETE`	Deletar

Quando você cria uma API REST, está definindo quais métodos aceita em cada rota.

Status codes

A resposta sempre vem com um código de status. Os mais importantes:

Código	Significado
`200`	OK: funcionou
`201`	Created: recurso criado
`400`	Bad Request: dados inválidos
`401`	Unauthorized: não autenticado
`403`	Forbidden: sem permissão
`404`	Not Found: não existe
`500`	Internal Server Error: erro no servidor

Quando sua API retorna 200 mas o frontend não funciona, o problema provavelmente está no corpo da resposta. Quando retorna 403, é autenticação ou permissão. Entender isso corta o tempo de debug pela metade.

Headers

Os headers carregam metadados da requisição e da resposta:

Content-Type: application/json
Authorization: Bearer eyJhbGci...
Cache-Control: no-cache

CORS? É um problema de header. JWT? Vai no header Authorization. Cache? Configurado via header. Grande parte dos bugs "misteriosos" de integração são problemas de header mal configurado.

TCP vs UDP: quando cada um é usado

TCP garante entrega. Se um pacote se perde, ele é reenviado. Ideal para APIs, páginas web e qualquer comunicação onde perder dados é inaceitável.

UDP não garante entrega, mas é muito mais rápido. Ideal para:

Streaming de vídeo (melhor perder um frame do que pausar)
Jogos online (latência importa mais que perfeição)
DNS (consultas rápidas e simples)

Como dev de aplicações web, você vai trabalhar com TCP quase sempre. Mas saber a diferença explica por que o Netflix não usa a mesma tecnologia que uma API de banco.

DNS na prática: o que você precisa saber

Quando você faz deploy de um sistema, é você quem configura o DNS. Alguns conceitos essenciais:

Registro A: aponta um domínio para um IP

vick1st.com → 76.76.21.21

Registro CNAME: aponta um domínio para outro domínio

www.vick1st.com → cname.vercel-dns.com

TTL (Time to Live): por quanto tempo o DNS fica em cache. Se você mudou o registro e o site ainda não atualizou, é o TTL que está segurando. Pode levar até 48h para propagar globalmente.

Exemplo prático: configurando DNS na Hostinger

Se você ainda não tem um domínio, a Hostinger é onde registro os meus. Painel simples, suporte decente e o melhor custo-benefício que encontrei. Tem 20% de desconto esperando por você no link. Para apontar seu domínio para uma plataforma como Vercel, Netlify ou qualquer servidor:

Faça login na Hostinger → Domínios → Meus domínios
Clique em Gerenciar no domínio desejado
Vá em DNS / Nameservers
Aqui você gerencia todos os registros do seu domínio

Para apontar para a Vercel, por exemplo, você adicionaria:

Tipo	Nome	Valor
`A`	`@`	`76.76.21.21`
`CNAME`	`www`	`cname.vercel-dns.com`

O @ representa o domínio raiz (seudominio.com). O www cobre www.seudominio.com.

Atenção: se já existir um registro A ou CNAME com o mesmo nome, edite o existente em vez de criar um novo. Registros duplicados causam conflito.

Cada plataforma tem seus próprios valores. Sempre consulte a documentação da plataforma onde está fazendo o deploy para pegar os IPs e CNAMEs corretos.

Por que isso importa antes do framework

Quando você aprende só o framework, você aprende a usar ferramentas que abstraem tudo isso. Funciona até o momento em que algo dá errado.

Com esse conhecimento:

Você sabe por que localhost:3000 não é acessível de outra máquina
Você entende o que é um proxy reverso e por que o Nginx existe
Você debugga erros de CORS sem copiar solução do Stack Overflow às cegas
Você configura domínios e DNS sozinho, sem depender de ninguém
Você entende o que um Load Balancer faz e quando usar

Esses não são conceitos avançados. São a base do que acontece em todo sistema web, e que a maioria dos tutoriais pula porque não é o que vende curso.

→ Próximo episódio
Você já sabe como os dados chegam até o servidor. Agora precisa saber o que acontece quando eles chegam lá — e o ambiente que recebe tudo isso é Linux. Não importa se você desenvolve no Windows ou Mac: em produção, é Linux. Sempre.
Antes do Framework — Ep. 03: Como usar Linux do zero — o guia para desenvolvedores

HTTP, TCP e DNS: o que acontece antes do seu código rodar