DWEB 01.3 Protocolos de Rede: TCP/IP, HTTP e HTTPS

Já entendemos que cliente e servidor conversam o tempo todo na web. Mas conversar exige um idioma comum. Se eu falo apenas português e você apenas mandarim, a conversa não acontece — por mais que estejamos no mesmo cômodo. Na rede é a mesma coisa: cliente e servidor precisam concordar com regras que definam como pedir, como responder, em que ordem, em qual formato, e o que fazer se algo der errado. Esses conjuntos de regras chamam-se protocolos. Neste tópico, vamos conhecer os três protocolos mais importantes da sua rotina como desenvolvedor front-end: TCP/IP, HTTP e HTTPS.

Por que protocolos existem?

Imagine que você liga para uma central de atendimento de uma empresa. Existe uma ordem implícita: o atendente se identifica, você se identifica, ele pergunta como pode ajudar, você responde, ele segue um roteiro para encaminhar sua demanda, e ao final a chamada é encerrada com uma despedida. Esse roteiro é um protocolo social. Sem ele, conversas profissionais não funcionariam — porque cada um faria do seu jeito.

Na internet acontece o mesmo, mas com uma diferença importante: os “atendentes” e “clientes” são máquinas, e máquinas não têm bom-senso. Elas precisam de regras explícitas, escritas e rigorosamente seguidas, ou nada funciona. Os protocolos são essas regras. Cada protocolo cuida de uma camada da comunicação: alguns cuidam do transporte físico dos dados; outros, das regras de aplicação. Vamos olhar os três protocolos que mais aparecem na sua rotina.

TCP/IP: o motor invisível da internet

TCP/IP é, na verdade, um conjunto de protocolos — uma “família”. Os dois nomes principais dão nome ao conjunto: IP (Internet Protocol) e TCP (Transmission Control Protocol). Eles atuam em camadas diferentes e se complementam.

O IP é responsável por endereçar e rotear os pacotes de dados pela rede. Todo computador conectado à internet possui um endereço IP — uma sequência numérica única que o identifica naquele momento, parecida com um número de telefone ou um CEP. O IPv4, formato mais antigo e ainda muito presente, usa quatro grupos de números (por exemplo, 192.0.2.1). O IPv6, formato mais novo e que vai gradualmente substituí-lo, usa grupos hexadecimais bem maiores (por exemplo, 2001:db8::1). A motivação para o IPv6 é simples: o IPv4 tem um limite de cerca de 4,3 bilhões de endereços, e com a explosão de dispositivos conectados, esse número se tornou pequeno.

O TCP, por sua vez, é responsável por transportar os dados com confiabilidade. Quando uma página é enviada da Inglaterra para o Brasil, ela não viaja como um único pacote gigante — viaja quebrada em centenas ou milhares de pequenos pedaços. O TCP garante que todos esses pedaços cheguem, na ordem certa, sem corrupção. Se algum pacote se perder no caminho, o TCP pede para ser reenviado. Se chegar fora de ordem, ele reorganiza. Se chegar duplicado, ele descarta. É um trabalho silencioso e impecável.

Uma analogia: imagine enviar um livro de mil páginas pelos correios. Em vez de mandar tudo em uma única caixa enorme (cara, lenta e arriscada), você manda em cem envelopes numerados de 1 a 100, cada um com dez páginas. Se algum envelope se perder, você refaz só esse. Quando todos chegam, basta ordená-los pelos números. Essa é, em essência, a engenharia do TCP.

Como desenvolvedor front-end, você raramente vai lidar diretamente com TCP/IP. Esse trabalho é feito pelo sistema operacional e pela infraestrutura de rede. Mas é importante saber que ele existe e o que faz, porque tudo o que vem depois — incluindo o HTTP e o HTTPS — roda em cima dele.

HTTP: a linguagem da web

Sobre o TCP/IP, foi construído um protocolo mais especializado, voltado especificamente para a comunicação na web: o HTTP, que significa HyperText Transfer Protocol (Protocolo de Transferência de Hipertexto). É ele que cliente (navegador) e servidor falam quando você acessa uma página.

O HTTP segue um modelo chamado requisição-resposta: o cliente faz uma requisição ao servidor, e o servidor envia uma resposta. Ponto. A cada nova ação do usuário, uma nova requisição. Esse modelo é também sem estado (em inglês, stateless): cada requisição é independente; o servidor, em princípio, não “lembra” da requisição anterior. Há mecanismos para contornar isso (cookies, sessões, tokens), mas o desenho original é deliberadamente simples — e isso ajuda a escalar a web para bilhões de usuários.

Uma requisição HTTP, em sua forma mais simples, contém:

• Um método (GET, POST, PUT, PATCH, DELETE, entre outros — assunto do Tópico 1.6).
• Um caminho dentro do servidor (parte da URL — assunto do Tópico 1.5).
• Um conjunto de cabeçalhos com metadados (idioma preferido, formato aceito, identificação do navegador, etc. — assunto do Tópico 1.7).
• Opcionalmente, um corpo com dados a enviar (em métodos como POST).

Uma resposta HTTP contém:

• Um código de status que indica se deu certo, se deu errado, ou se precisa de algo a mais (Tópico 1.7).
• Cabeçalhos com metadados sobre a resposta.
• Um corpo com o conteúdo de fato — o HTML da página, uma imagem, um arquivo JSON, etc.

Veja, abaixo, um exemplo simplificado de como seria uma requisição HTTP em texto cru, do tipo que viaja pela rede (você verá esse formato com frequência em ferramentas de inspeção):

GET /produtos/123 HTTP/1.1
Host: lojaexemplo.com.br
Accept: text/html
User-Agent: Mozilla/5.0

E uma resposta possível:

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

<!DOCTYPE html>
<html>
<head><title>Produto 123</title></head>
<body><h1>Caneca artesanal</h1>...</body>
</html>

Não é preciso decorar nada agora. O importante é perceber: o HTTP é, literalmente, texto trocado entre cliente e servidor, com uma estrutura definida. Sempre que você ouvir alguém falar em “fazer uma requisição”, “endpoint”, “API”, “método HTTP” ou “status 404”, é desse mundo que se está falando.

HTTPS: o HTTP, mas seguro

O HTTP, em sua forma original, transmite tudo em texto puro. Isso significa que qualquer pessoa com acesso à rede pelo caminho — em um Wi-Fi público, por exemplo — poderia, em tese, ler os pacotes e ver exatamente o que está sendo enviado e recebido: senhas, dados pessoais, mensagens. Isso, evidentemente, é um problema enorme. Foi para resolvê-lo que surgiu o HTTPS, que significa HyperText Transfer Protocol Secure — HTTP, mas seguro.

O HTTPS não é um protocolo totalmente diferente do HTTP. Ele é, na prática, o mesmo HTTP, mas embrulhado em uma camada de criptografia chamada TLS (Transport Layer Security), antiga SSL (Secure Sockets Layer). Antes de qualquer requisição HTTP ser enviada, cliente e servidor fazem um pequeno ritual chamado handshake TLS: trocam informações sobre como vão criptografar a conversa, validam a identidade do servidor por meio de um certificado digital, e combinam uma chave secreta que só os dois conhecem. A partir desse momento, tudo o que viaja entre eles é embaralhado, ilegível para quem estiver no meio do caminho.

O HTTPS oferece três garantias importantes:

1. Confidencialidade: ninguém no caminho consegue ler o conteúdo.
2. Integridade: ninguém consegue alterar o conteúdo sem que cliente ou servidor percebam.
3. Autenticidade: o cliente tem certeza de que está falando com o servidor verdadeiro, e não com um impostor.

Hoje, o HTTPS é o padrão da web. Navegadores modernos sinalizam como inseguros os sites que ainda usam HTTP cru, e mecanismos de busca privilegiam sites HTTPS nos resultados. Por isso, todo site profissional precisa estar em HTTPS. Voltaremos a esse tema em detalhes no Tópico 1.10, ao falar sobre segurança, SSL/TLS e certificados.

Diferenças práticas que você precisa enxergar

A tabela abaixo resume o que cada um faz e onde ele aparece no seu dia a dia:

Protocolo	Camada / função	Onde você o “vê”	Cuidado pelo desenvolvedor front-end
IP	Endereçamento e roteamento dos pacotes	Endereço IP do servidor de destino	Raramente
TCP	Transporte confiável dos pacotes	Garante a entrega “limpa”	Praticamente nunca
HTTP	Comunicação entre cliente e servidor da web	URLs, métodos, status, cabeçalhos	Diariamente
HTTPS	HTTP + criptografia (TLS)	O cadeado na barra do navegador	Sempre que falar em segurança e confiança

Como desenvolvedor front-end, o HTTP e o HTTPS serão seus parceiros constantes. Você vai pensar em método, caminho, cabeçalho e código de status quase todos os dias. O TCP/IP, por baixo, vai fazer seu trabalho silencioso, como o sistema rodoviário que carrega as cargas sem que você precise pensar nele.

Momento de aplicação prática

Faça este pequeno experimento (não exige instalar nada além de um navegador comum):

1. Abra um navegador e acesse um site qualquer — pode ser um portal de notícias.
2. Observe a barra de endereço. Aparece um cadeado fechado? Aparece https:// à esquerda do nome do site? Se sim, esse site está usando HTTPS.
3. Agora clique no cadeado. O navegador vai mostrar informações sobre o certificado e a conexão. Procure por menções a “TLS”, “criptografia” ou “certificado”. Você acabou de ver, na prática, o resultado do handshake TLS que estudamos.

Isso é exatamente o tipo de inspeção que um desenvolvedor faz diariamente — e que estudaremos com mais detalhe no Tópico 1.8.

Armadilha comum

Iniciantes às vezes acham que “instalar HTTPS” é apenas uma questão de marcar uma caixinha. Não é. HTTPS exige um certificado digital válido, emitido por uma autoridade certificadora reconhecida. Sem isso, o navegador vai exibir um aviso amedrontador para o usuário e a maior parte das pessoas vai fechar a página. Hoje, felizmente, existem serviços que emitem certificados gratuitos (como o Let’s Encrypt) e a maioria dos serviços de hospedagem oferece a configuração de HTTPS sem custo — mas é um passo que não pode ser pulado em um projeto profissional.

O que vem a seguir

Já vimos os protocolos que transportam os dados. Mas ainda há uma peça invisível no quebra-cabeça: como o seu navegador descobre onde está o servidor de um site quando você digita um nome como leaoeducacao.com.br? Afinal, o IP que o TCP/IP usa é um número, e você nunca digita um número — você digita um nome. A ponte entre o nome e o número é feita pelo DNS, e é exatamente isso que vamos estudar no próximo tópico.