HTTP e HTTPS
O protocolo de pedido e resposta que sustenta a web e quase toda API. Entenda o que trafega em cada requisição e o que o HTTPS acrescenta.
O HTTP que você escreve no código é quase sempre o mesmo: método, caminho, cabeçalhos e corpo. As decisões ficam em volta dele. São três: qual versão do protocolo trafega, onde a criptografia termina e quem pode guardar as respostas.
Versões do protocolo: 1.1, 2 e 3
As três versões entregam a mesma semântica. Um GET /pedidos/1 significa a mesma coisa em todas. A diferença está em como os bytes são transportados, e portanto no desempenho.
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| Ano | 1997 | 2015 | 2022 |
| Formato | Texto | Binário | Binário |
| Transporte | TCP | TCP | QUIC, sobre UDP |
| Pedidos simultâneos por conexão | Um por vez | Muitos (multiplexação) | Muitos (multiplexação) |
| Compressão de cabeçalhos | Não | Sim | Sim |
| Criptografia | Opcional | Obrigatória nos navegadores | Sempre (TLS 1.3 embutido) |
| Um pacote perdido trava | Só aquela conexão | Todos os pedidos da conexão | Só o pedido afetado |
O problema que cada versão resolveu
No HTTP/1.1, uma conexão atende um pedido por vez. Enquanto a resposta não termina, o próximo espera na fila. Os navegadores contornam isso abrindo cerca de seis conexões por domínio, e a comunidade criou gambiarras como juntar todos os arquivos em um só.
O HTTP/2 passou a intercalar vários pedidos na mesma conexão. Uma página com oitenta arquivos deixa de depender de filas. Sobrou um problema na camada de baixo: o TCP entrega os bytes em ordem, então um único pacote perdido segura todos os pedidos que dividem aquela conexão até a retransmissão chegar.
O HTTP/3 trocou o TCP pelo QUIC, que trata cada pedido como um fluxo independente. A perda de um pacote atrasa só o fluxo dono dele. A conexão também abre mais rápido e sobrevive à troca de rede, como sair do Wi-Fi para o 4G.
Como escolher
| Situação | Recomendação |
|---|---|
| Site ou API pública acessada por navegador e celular | Habilite HTTP/2 e HTTP/3 na borda (CDN ou proxy). O ganho aparece em redes móveis e instáveis. |
| Chamadas entre serviços dentro do data center | HTTP/1.1 com conexões reaproveitadas resolve a maioria dos casos. HTTP/2 vale quando há muitas chamadas simultâneas ou gRPC. |
| Você usa gRPC | HTTP/2 é requisito do protocolo. |
| Rede corporativa que bloqueia UDP | O HTTP/3 não passa. Os clientes voltam sozinhos para o HTTP/2. |
Onde terminar o TLS
"Terminar o TLS" é escolher o ponto em que o tráfego é descriptografado. Dali para trás, a conversa segue em HTTP comum ou é criptografada de novo.
| Onde termina | Como funciona | Vantagens | Custos |
|---|---|---|---|
| Na borda (CDN ou balanceador gerenciado) | O provedor cuida do certificado e entrega HTTP para a sua rede | Certificado renovado sozinho, proteção contra ataques de volume, HTTP/3 pronto | O provedor enxerga o tráfego aberto; o trecho interno precisa ser confiável ou criptografado de novo |
| No proxy reverso (Nginx, Caddy, Traefik) | Um proxy seu recebe o HTTPS e repassa HTTP para a aplicação na mesma máquina ou rede | Um lugar só para certificados; a aplicação fica simples; você controla tudo | Você opera e atualiza o proxy |
| Na aplicação | O próprio processo carrega o certificado e atende HTTPS | Criptografia de ponta a ponta, sem trecho aberto | Cada serviço gerencia certificado e renovação; recarregar o certificado exige cuidado |
O arranjo mais comum é terminar no proxy reverso ou na borda. A aplicação recebe HTTP comum e descobre o endereço e o protocolo originais pelos cabeçalhos X-Forwarded-For e X-Forwarded-Proto.
Em ambientes com exigência de sigilo dentro da rede interna (dados de saúde, pagamentos, redes compartilhadas), usa-se mTLS entre os serviços: os dois lados apresentam certificado, e cada serviço sabe com quem está falando.
Cache HTTP: expiração e validação
O protocolo já traz um sistema de cache, operado pelo navegador e pelas CDNs sem nenhum código seu além dos cabeçalhos. Há dois mecanismos, e eles se combinam.
| Mecanismo | Cabeçalhos | O que acontece | Quando usar |
|---|---|---|---|
| Expiração | Cache-Control: max-age=3600 | Durante uma hora o cliente nem consulta o servidor | Arquivos que não mudam: imagens, JavaScript e CSS com hash no nome |
| Validação | ETag na resposta, If-None-Match no pedido | O cliente pergunta "mudou?" e recebe 304 sem corpo se não mudou | Dados que mudam sem aviso, em que economizar a transferência já ajuda |
| Sem cache | Cache-Control: no-store | Nada é guardado | Respostas com dados pessoais ou financeiros |
A expiração é a mais rápida porque elimina o pedido, e por isso é a mais perigosa: você não consegue avisar um navegador que guardou uma resposta por um ano. Daí a prática de colocar um hash no nome do arquivo e mudar o nome quando o conteúdo muda.
Para APIs, duas diretivas evitam os erros mais caros:
privatepermite cache só no navegador do usuário. Sem ela, uma CDN pode guardar a resposta de um usuário e entregá-la a outro.no-storeem qualquer resposta com dado sensível.
Resumo da decisão
- Versão: ligue HTTP/2 e HTTP/3 no ponto mais externo e não se preocupe com isso no código da aplicação.
- TLS: termine na borda ou no proxy reverso, e criptografe o trecho interno se a rede não for só sua.
- Cache: expiração longa para arquivos com hash no nome, validação para dados que mudam,
no-storepara dados sensíveis.
O próximo nível mostra um servidor e um cliente HTTP nas cinco linguagens, e o que cada biblioteca decide por você.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Qual versão do HTTP faz sentido no meu sistema
Preciso decidir como configurar as versões do HTTP no meu sistema e quero entender a decisão, não só receber a configuração. Comece me fazendo estas perguntas, uma de cada vez, e espere as respostas: - Quem são os clientes do sistema (navegador, aplicativo móvel, outros serviços)? - Existe CDN, balanceador ou proxy reverso na frente da aplicação? Qual? - Os serviços internos se comunicam por REST, gRPC ou outro protocolo? - Os usuários acessam por redes móveis ou instáveis? Com as respostas, explique para o meu caso: 1. Em quais trechos do caminho (cliente até a borda, borda até a aplicação, serviço a serviço) cada versão do HTTP traria ganho real, e em quais não muda nada. 2. O que é o bloqueio de cabeça de fila, por que o HTTP/2 resolveu só uma parte dele e como o HTTP/3 resolve o resto. 3. Os riscos e custos de habilitar HTTP/3 (por exemplo, redes que bloqueiam UDP) e como o cliente se comporta quando ele não está disponível. Termine com uma recomendação objetiva e a forma de medir se a mudança ajudou.
Onde terminar o TLS
Quero comparar as opções de onde terminar o TLS numa aplicação web: na borda (CDN ou balanceador gerenciado), num proxy reverso próprio (Nginx, Caddy, Traefik) ou dentro da própria aplicação. Para cada opção, explique: - Como o tráfego circula, indicando exatamente em quais trechos ele está criptografado e em quais não está. - Quem gerencia o certificado e como acontece a renovação. - Os riscos de segurança específicos daquele arranjo. - Para que tipo de sistema e de equipe ela é a melhor escolha. Depois, explique o problema de confiar nos cabeçalhos X-Forwarded-For e X-Forwarded-Proto vindos de qualquer origem, com um exemplo de ataque, e como configurar a aplicação para confiar apenas no proxy. Por fim, explique quando vale a pena adotar mTLS entre serviços internos e qual é o custo operacional disso. Pergunte qual é a minha infraestrutura atual antes de recomendar uma opção.
Estratégia de cache HTTP para a minha API
Quero definir os cabeçalhos de cache das respostas da minha aplicação e entender o efeito de cada um. Explique a diferença entre cache por expiração (Cache-Control com max-age) e cache por validação (ETag com If-None-Match), mostrando a sequência de pedidos e respostas em cada caso, inclusive o 304. Depois, peça que eu descreva de 4 a 6 tipos de resposta da minha aplicação (por exemplo: arquivos estáticos com hash no nome, lista de produtos, dados do perfil do usuário, saldo da conta). Para cada um, recomende o valor exato de Cache-Control, diga quem pode guardar a resposta (navegador, CDN, ninguém) e explique o que daria errado com uma escolha diferente. Dê atenção especial ao risco de uma CDN entregar a resposta de um usuário para outro, e explique as diretivas private, no-store, no-cache e s-maxage, deixando claro que no-cache não significa "não guardar".