O que é HTTP e como ele funciona?

HTTP (Hypertext Transfer Protocol) é um protocolo de aplicação que especifica o formato e as regras para troca de mensagens entre um cliente e um servidor.

Ele funciona em um modelo requisição–resposta e é a base de sites e APIs, normalmente usando TCP (HTTP/1.1 e HTTP/2) ou QUIC/UDP (HTTP/3).

HTTP

HTTP é um protocolo de transferência da camada de aplicação baseado em texto e é considerado a base para a comunicação de dados entre dispositivos em rede. Durante esse processo de requisição-resposta, o HTTP usa padrões e regras predefinidos para a troca de informações. Em geral, HTTP é o protocolo que clientes e servidores usam para se comunicar.

Além disso, para que a troca de dados ocorra, o HTTP depende de outros dois protocolos de rede: TCP (Transmission Control Protocol) e IP (Internet Protocol). A partir disso, temos o modelo TCP/IP, que faz parte do processo de comunicação entre clientes e servidores e também entre servidores e APIs Mobile/Web. HTTP é o protocolo mais usado para aplicações baseadas na web e APIs.

Observe que TCP/IP é um modelo, mas também uma pilha de protocolos na qual o HTTP se encaixa. Em relação ao modelo OSI – do qual falaremos mais adiante – TCP é a camada 4 e IP é a camada 3.

Quando usar HTTP (3–5 pontos)

• Quando você precisa expor um site (HTML, imagens, vídeos, CSS/JS) para navegadores.
• Quando você vai construir ou consumir APIs Web (REST, GraphQL, gRPC-web, etc.).
• Quando precisa de cache, proxies, CDN e observabilidade baseados em cabeçalhos e status.
• Quando quer compatibilidade universal (clientes, bibliotecas, gateways e ferramentas).
• Quando o tráfego precisa atravessar redes corporativas e Internet com alto suporte a intermediários (proxy, balanceadores, WAF).

Quando não usar HTTP (3–5 pontos)

• Quando a aplicação exige latência ultrabaixa e comunicação contínua e você não quer trabalhar sobre HTTP (ex.: protocolos customizados em UDP; embora HTTP/3 reduza latência, nem sempre resolve).
• Quando você precisa de mensageria assíncrona com filas, retenção e entrega garantida (use Kafka/RabbitMQ/SQS, etc.).
• Quando o caso é transferência de arquivos com semânticas específicas (SFTP/FTPS podem ser mais adequados em ambientes legados).
• Quando a rede exige protocolos industriais/IoT específicos (MQTT, CoAP, etc.).
• Quando você não pode operar segurança (TLS, autenticação, rate limiting): HTTP “puro” sem controles vira superfície de ataque.

Sinais de que você precisa entender (ou ajustar) HTTP (sintomas)

• Seu site “abre”, mas alguns recursos falham (404/403 em assets, CORS, headers).
• A API está correta, mas o cliente recebe 401/403 (auth), 415 (content-type), 429 (rate limit) ou 5xx intermitente.
• Você vê lentidão sem aumento de CPU: suspeite de RTT alto, TLS handshake, head-of-line blocking, cache ineficiente.
• Caches não funcionam (sempre MISS, revalidações excessivas, conteúdo incorreto por Vary/Cache-Control).
• Tráfego anômalo ou picos de requisições geram queda (flood HTTP L7, bots, scraper

Natureza Stateless

Um fato importante sobre o protocolo HTTP é que ele é stateless – mas o que significa “stateless”? Significa que cada requisição que o cliente faz é uma transação independente, que não está relacionada a nenhuma requisição anterior, e cada uma é diferente para o servidor. Ou seja, mesmo que várias requisições sejam feitas ao mesmo tempo, uma não sabe que a outra existe, e o servidor não armazena nenhuma informação sobre o estado do cliente. Assim que uma conexão TCP é estabelecida, todas as informações trocadas são perdidas. As vantagens disso são que há uma redução no uso de memória no servidor e uma redução nos problemas resultantes de uma sessão expirada.

Também é importante mencionar que o HTTP é stateless se visto de um alto nível de abstração, mas também é baseado em TCP (não UDP), e assim é baseado em conexão e stateful de um ponto de vista de camada inferior. O que isso significa é que, por ser baseado em conexão, ele é stateful na entrega, o que garante que todos os pacotes sejam recebidos e sequenciados corretamente.

URL

Já sabemos o que é uma URL, e que é o primeiro passo no processo de troca de informações. Mas, embora faça parte do nosso cotidiano online, muitos de nós não sabemos o que sua estrutura significa. Então, vamos considerar a seguinte URL:

Em sua forma básica, podemos dividir a URL em três partes:

• O protocolo (http:// ou https://) informa ao seu navegador como se comunicar com o servidor de um website para enviar e recuperar informações. Cuando é HTTPS, significa que é um HTTP seguro que possui alguns padrões de segurança adicionais e texto criptografado.
• O domínio (blog.azion.com) - tem o subdomínio (blog.), o nome pelo qual o website é conhecido (azion) e o TLD (.com). TLD significa Top Level Domain (Domínio de Nível Superior), que é a categoria dos websites como .com (comercial), .org (organizações) e .net (redes).
• O caminho (/edge) - direciona o navegador para uma página específica no website.

História do HTTP

Vamos começar com o termo hipertexto, que foi criado por Ted Nelson em 1965 e foi definido como “escrita não sequencial”. Em outras palavras, é um tipo de texto que se ramifica, não é necessariamente linear e contém links para outros textos. Este termo, por sua vez, foi inspirado nas ideias de Vannevar Bush apresentadas anteriormente em seu artigo de 1945 As We May Think.

Mais tarde, em 1989, Tim Berners-Lee propôs o projeto WorldWideWeb e, em 1991, ele e sua equipe criaram um protocolo que permitiria a recuperação de textos de outros documentos através de links de hipertexto, que se tornaria o formato original do HTTP. Hipertextos foram os primeiros arquivos que usaram HTML (HyperText Mark-up Language), um formato textual para representar documentos em hipertexto. HTML, assim como hipertexto, é texto, mas pode servir como comandos, incluindo a chamada de outros recursos como imagens, vídeos, áudios, etc. Sua versão mais recente é o HTML5.

Como tudo no mundo da Internet, o protocolo HTTP passou por várias transformações e evoluiu muito, como pode ser visto abaixo.

• HTTP/0.9 - A primeira versão foi lançada em 1991 e era muito simples. Focava na transferência de texto e tinha apenas o método de requisição GET; não tinha cabeçalhos HTTP, status ou códigos de erro.
• HTTP/1.0 - Esta versão posterior é de 1996, e apresentou, além da transferência de texto simples, a transmissão de dados mais sofisticados, como metadados de requisição/resposta e negociação de conteúdo.
• HTTP/1.1 - Esta versão de 1999 é considerada um marco na evolução da Internet, pois eliminou vários problemas das versões anteriores e introduziu uma série de otimizações, como um mecanismo adicional de cache, transferências de codificação fragmentada, pipelining de requisições e criptografia de transferência. Embora exista uma versão mais recente, esta ainda é a versão padrão e mais usada no mundo.
• HTTP/2 - Esta versão é de 2015 e está melhor preparada para o uso massivo e generalizado da Internet atual. Embora não tenha havido mudança na semântica da versão anterior, alguns benefícios notáveis são melhor performance no transporte de informações e segurança de dados e latência significativamente menor.
• HTTP/3 - Lançado em 2019, o protocolo HTTP/3 é ainda mais rápido, confiável e seguro. Apresenta uma diferença fundamental da versão anterior: um novo protocolo de transporte, o QUIC. QUIC é baseado em UDP (User Datagram Protocol), que é mais rápido que TCP na transmissão de dados, pois não passa pelo processo de verificação de dados; isso, no entanto, o torna menos seguro. Embora não seja um transporte confiável, o QUIC adiciona uma camada extra ao UDP, trazendo recursos como retransmissão de pacotes e controle de congestionamento. Outra característica importante do HTTP/3 é que ele suporta HTML5, a versão mais moderna do HTML, que adiciona a capacidade de fazer programação nativa.

Entendendo onde o HTTP se encaixa no quebra-cabeça da comunicação

HTTP é uma pequena peça na pilha de comunicação, mas como ele se encaixa nela? Para entender melhor, vamos primeiro ter uma visão rápida do modelo OSI.

O modelo OSI (Open System Interconnection), criado pela Organização Internacional de Padronização em 1971, é um modelo de redes de computadores que serve como padrão, ou regras, para protocolos de comunicação entre diferentes sistemas em uma rede. Ou seja, é como se fosse uma linguagem universal para redes de computadores. Neste modelo, o sistema de comunicação é dividido em sete camadas abstratas, cada uma com uma funcionalidade específica.

O protocolo HTTP atua precisamente na camada 7, a camada de aplicação, onde ocorre a interação entre usuários e computadores – quando os usuários visitam um website ou verificam e-mails, por exemplo. A camada de aplicação é responsável pelos protocolos e manipulação de dados dos quais o software depende para apresentar dados significativos ao usuário. Além do HTTP, outros protocolos que operam na camada de aplicação são: HTTPS, DNS, FTP, IMAP, MIME, POP, RTP, SMTP, TELNET, TFTP e TLS.

A comunicação HTTP

Quando um cliente deseja se comunicar com um servidor, a primeira coisa que acontece, depois que o usuário digita a URL na barra de endereço do navegador ou vai para outra página, é abrir uma conexão TCP/IP, e a requisição HTTP é enviada para o servidor. Nessa requisição, há uma mensagem com uma série de dados descrevendo o que o cliente solicitou. O servidor então envia a resposta ao cliente, que também contém dados que podem ser lidos. Finalmente, o processo de requisição-resposta é finalizado. Tenha em mente que tudo isso geralmente leva microssegundos para acontecer.

No processo de comunicação que descrevemos acima, você deve ter notado que existem dois agentes essenciais: a requisição e a resposta.

Mensagens HTTP

O que é uma requisição?

A requisição é o que o cliente precisa do servidor. Nessa mensagem, há dados específicos, que descrevem o que foi solicitado. Os principais componentes de uma requisição são descritos abaixo.

1. O método - indica a ação que o cliente deseja realizar, como:
   • GET - para obter recursos ou recuperar dados do servidor; é o mais comum;
   • POST - para enviar dados ao servidor, como enviar um formulário;
   • HEAD - para resumir a linha de resposta e cabeçalhos;
   • PUT - para enviar arquivos ao servidor ou fazer uma atualização completa de um recurso;
   • PATCH - para fazer uma atualização parcial de um recurso;
   • DELETE - para excluir documentos dentro do servidor;
   • OPTIONS - para consultar quais comandos estão disponíveis para um determinado usuário; e
   • TRACE - para depurar requisições, retornando um cabeçalho de documento.

2. O caminho - o URI (Uniform Resource Identifier) do recurso a ser pesquisado.

3. A versão HTTP do protocolo.

4. Os cabeçalhos da requisição - contendo informações adicionais para servidores.

5. O corpo da requisição - opcional e necessário para alguns métodos, como POST, e contém o recurso solicitado.

O que é uma resposta?

A resposta dada pelo servidor contém as informações solicitadas pelo cliente ou informa que houve um erro em relação ao que foi solicitado. Ela contém os elementos listados abaixo.

1. O cabeçalho da resposta - contém a versão do protocolo, o código de status da requisição e o tipo de conteúdo que está incluído no corpo.
2. O código de status - indica se a requisição foi bem-sucedida ou não. A resposta é dada por códigos específicos, como:
   • 200 - a requisição foi respondida com sucesso;
   • 301 - a requisição foi movida permanentemente;
   • 401 - a requisição não foi autorizada pelo servidor;
   • 404 - a requisição não foi encontrada pelo servidor; e
   • 500 - erro interno do servidor.
3. O corpo da resposta - como na requisição, é opcional e contém dados sobre o recurso solicitado.

Outro aspecto interessante da comunicação HTTP é o uso de cache, que mantém cópias de dados que são frequentemente acessados. Basicamente, o cache acelera a busca e entrega de dados frequentemente utilizados e poupa o uso de recursos em um servidor, melhorando a performance e velocidade do processo – mas este é um tópico para outro post do blog.

A desvantagem do HTTP

Você viu que o protocolo HTTP é a base para qualquer troca de informações na Internet, mas, como tudo nesta vida, há um problema: ele não é seguro. Você sabia que é exatamente por isso que ele é alvo de ações mal intencionadas? Entre os crimes cibernéticos que podem afetar o protocolo HTTP, podemos mencionar a interceptação de dados durante a transmissão de informações e ataques DDoS na camada 7, também conhecidos como ataques de inundação HTTP, que sobrecarregam um servidor com requisições HTTP. Quando o servidor não é mais capaz de responder ao tráfego normal, as requisições de usuários legítimos sofrerão negação de serviço.

Embora todos os sites e aplicações estejam sujeitos a crimes cibernéticos, a boa notícia é que existem algumas maneiras de se proteger contra essas ameaças, como: Web Application Firewall, Proteção DDoS e Proteção de Camada de Rede.

Soluções de Segurança Avançadas

O Web Application Firewall (WAF) aprimora a segurança de aplicações web defendendo contra uma ampla gama de ameaças, desde vulnerabilidades do OWASP Top 10 até sofisticados ataques zero-day. Ele protege a camada de aplicação (camada 7), onde as aplicações interagem com serviços de rede, atuando como uma barreira protetora que aplica um conjunto de regras para filtrar e monitorar o tráfego entre a aplicação e a Internet. Em termos práticos, o WAF se concentra em proteger protocolos HTTP/S analisando requisições, detectando e bloqueando atividades maliciosas antes que possam impactar a infraestrutura—tudo sem comprometer a performance da aplicação.

A solução de Proteção DDoS oferece múltiplas camadas de defesa contra ataques DDoS, incluindo aqueles que têm como alvo a camada 7, onde o protocolo HTTP opera. Ao aproveitar uma rede globalmente distribuída junto com centros de mitigação especializados, ela fornece a inteligência e escalabilidade necessárias para neutralizar até mesmo os ataques mais complexos e de grande escala.

Para uma cobertura de segurança ainda mais ampla, a Proteção de Camada de Rede estabelece um perímetro de segurança programável no edge da rede, controlando o tráfego de entrada e saída. Esta solução permite a capacidade de bloquear ameaças, monitorar comportamentos suspeitos e impor penalidades como limitações de acesso.

Adotar essas estratégias de mitigação ajuda as empresas a permanecerem resilientes contra ameaças cibernéticas emergentes, incluindo ataques cada vez mais frequentes e de grande escala, exploração direcionada de API e metodologias de ataque em evolução.

A Importância do HTTP

HTTP é um protocolo simples, mas mais do que isso, é um recurso marcante e também acessível, já que foi projetado para ter mensagens que podem ser lidas e compreendidas por qualquer usuário. Além disso, sua natureza stateless simplifica a performance do servidor e o torna mais rápido, já que não há necessidade de armazenar ou limpar dados para as próximas requisições. Se uma transação for interrompida, nenhuma parte do sistema precisa ser responsável por limpar o estado atual do servidor. Outro aspecto fundamental é o fato de ser extensível, o que permite a inserção de novas funcionalidades e, consequentemente, o HTTP acompanha as necessidades e a evolução da Internet em sua missão de transmitir os dados que praticamente movem o mundo.

Erros comuns (e como corrigir)

1. Usar HTTP sem TLS em produção
   • Correção: adote HTTPS, HSTS e redirecionamento 301 de HTTP→HTTPS.
2. Cache-Control ausente ou contraditório
   • Correção: defina políticas claras (max-age, s-maxage, stale-while-revalidate) e valide Vary.
3. Misturar semântica de métodos (ex.: GET com efeito colateral)
   • Correção: use POST/PUT/PATCH/DELETE corretamente; mantenha GET idempotente.
4. Ignorar códigos de status e “confiar no corpo”
   • Correção: implemente tratamento por classe (2xx/3xx/4xx/5xx) e logs com status.
5. CORS configurado “no chute”
   • Correção: restrinja origens, métodos e cabeçalhos; use OPTIONS/preflight com intenção.
6. Autenticação fraca e sem rate limiting
   • Correção: OAuth/JWT bem configurados + rate limiting + detecção de bots + WAF quando necessário.

Mini FAQ

• HTTP e HTTPS são a mesma coisa?

Não. HTTPS é HTTP com criptografia e autenticação via TLS, protegendo dados em trânsito e reduzindo riscos de interceptação e manipulação.

• HTTP é TCP ou UDP?

  Depende da versão. HTTP/1.1 e HTTP/2 usam TCP. HTTP/3 usa QUIC sobre UDP, com confiabilidade implementada no QUIC.

• Por que HTTP é considerado stateless?

  Porque cada requisição é independente e deve conter o necessário para ser processada; “sessão” é construída acima do HTTP (cookies/tokens).

• **Quais status codes eu devo monitorar primeiro?

  5xx** (falha no servidor/origin),429 (limitação/abuso), 401/403 (auth), 404 (rotas/recursos), além de p95/p99 de latência.

• Como sei se meu cache está funcionando? Meça cache hit ratio, observe headers (Cache-Control, ETag, Age) e compare TTFB com e sem cache.

Glossário rápido (para leitura e implementação)

• Cliente: navegador/app que faz a requisição.
• Origin: servidor de origem que hospeda a aplicação/dados.
• Header: metadado HTTP (cache, auth, content-type).
• Status code: resultado padronizado (200, 404, 500…).
• TTL: tempo de vida no cache.
• RTT/TTFB: métricas de rede e resposta percebida.