Patrick Brandão

Introdução ao Protocolo HTTP

Saudações.

Fiz esse artigo para explicar os princípios básicos do protocolo HTTP em uma abordagem passo-a-passo dos elementos e suas implementações práticas.

1 – Sobre o Protocolo HTTP

O protocolo HTTP é simples demais.

O cliente HTTP (navegador na maioria dos casos) envia um pedido (REQUEST) em texto simples para a porta HTTP, normalmente 80/TCP, e recebe uma resposta (REPLY).

Requisições e respostas tem o mesmo formato:

  • Cabeçalho: Texto contendo na primeira linha a instrução principal seguida das demais linhas com cabeçalhos (formato “nome-cabeçalho: valor cabeçalho”). A primeira linha muda de acordo com o lado, pode conter:
    • Na requisição: O verbo HTTP (método): GET, POST, PUT, DELETE, PATH;
    • Na resposta: A versão do protocolo HTTP e o código de retorno;
  • Corpo: Conteúdo preenchido livremente pelo cliente ou pelo servidor, normalmente um texto em HTML ou JSON.

Essa explicação simples resume 99.99% do uso do protocolo HTTP, dominar isso é mais que suficiente para desenvolver e analisar sistemas que usam URLs, APIs, Webhooks e site.

1.1 – DNS

O DNS é importante para que a URL possa ser acessada por nome de domínio, como meusite.com.br em vez do IP, 45.255.128.2.

Estude o protocolo DNS para entender como ele pode impactar na abertura de sites pelo nome.

Antigamente os sites eram acessados pelo host “www” antes do nome do dominio. Hoje é recomendado que o mesmo site abra com e sem o “www”, exemplo:

  • www.meusite.com.br IN A (está no ipv4) 45.255.128.2
  • meusite.com.br IN A 45.255.128.2

Problemas de DNS são o primeiro motivo para sites não abrirem ou ficarem lentos.

Recursos especiais que podem existir no servidor DNS:

  • View e Split-Horizon: Respondem IPs diferentes baseados no IP de origem da requisição DNS;
  • Balance: Respondem IPs diferentes a cada requisição para balancear o tráfego em diferentes datacenters;

É preciso ficar atento a esses recursos pois eles podem fazer o site abrir em um provedor mas não abrir em outro.

1.2 – Sites

Ao criar sites, o cliente HTTP solicita ao servidor o caminho “/”, que por padrão retorna um conteúdo HTML contendo a “programação do site”, o que inclui:

  • URLs para baixar código javascript (.js) e estilos (.css);
  • URLs de objetos como imagens (PNG, JPEG, GIF, SVG);

Para cada URL o navegador faz novas requisições HTTP para obter o conteúdo. O site só começa a ser exibido para o usuário depois que os principais recursos são obtidos.

Por conta disso um site que inclui muitas URLs próprias e muitas URLs de outros sites e servidores podem demorar para carregar.

Essa lentidão é difícil de determinar pois requer inspecionar no menu “Network” do navegador o tempo que cada URL demorou para carregar e localizar as URLs lentas.

1.3 – APIs

As APIs são URLs que recebem comandos e retornam dados extremamente pontuais.

Normalmente o tipo de conteúdo envolvido é JSON. Sempre que uma API é acionada ela retorna o que o cliente pediu. Cada botão em um site envolve uma API no lado servidor.

1.4 – Webhooks

Chamados de webhooks as APIs que não precisam retornar, obrigatoriamente, dados para o cliente solicitante.

Exemplo didático mais exato:

  • Eu criei uma URL: https://meusite.com.br/webhook/aviso-pagamento
  • Configurei banco permite que eu cadastre uma URL de webhook sempre que um PIX ou boleto é pago;
  • Se um cliente pagar um PIX as 5:45, meu banco vai enviar um conteúdo JSON para a minha URL de webhook, só isso!
  • Minha webhook não precisa responder nada para o banco, apenas o codigo 200 (OK, recebido).

Webhooks são APIs do tipo “tome isso, só me confirme que recebeu, não me importo com o resultado”.

1.5 – HTTPs

Atualmente o uso do HTTP puro, que apenas transporta texto, não é admitido na Internet por questões de segurança e sigilo dos dados.

Antes de trocar comandos de texto, o cliente e o servidor precisam estabelecer uma conexão TLS para criar um canal criptográfico.

Cada lado, cliente e servidor, trocam o texto HTTP simples, mas pela rede o conteúdo é transportado pelo TLS com sigilo e proteção total.

1.6 – TCP e UDP

O protocolo HTTP é normalmente transportado entre os IPs do cliente e do servidor usando TCP, que exige 3way handshake (SYN, SYN/ACK, ACK) para estabelecer uma conexão.

O protocolo HTTP 1, HTTP 2 usam TCP, a criptografia é implementada pela camada TLS.

O protocolo HTTP 3 implementou o transporte por UDP, a criptografia é implementada pela camada QUIC.

1.7 – Balanceador L4 e Firewall de borda

Balanceadores de camada 4 (TCP ou UDP) são equipamentos que recebem um volume muito grande de conexões IPv4 ou IPv6 transportando TCP ou UDP e distribuem para vários servidores internos.

Esses balanceadores são especializados em segurar grandes cargas de conexões e são a primeira barreira contra ataques de DOS e DDoS.

Implementações nesse ponto:

  • Balanceamento: Distribuição de conexões TCP de forma transparente (TPROXY ou TCP-PROXY);
  • TLS Offload: Aceleram o inicio da conexão criptográfica, mas não lidam com o conteúdo após a conexão TLS concluir;
  • Traffic-shapping: Limitam a velocidade por conexão e por IP de origem;
  • QoS e IP Quality: Limitam a velocidade baseada na reputação do IP de origem, bloqueiam se o IP possuir reputação muito ruim ou constar em blacklists;
  • GeoIP: Identificam o país e região de origem onde o IP está para tratar de maneira diferente:
    • Switch: Entregar para servidores internos diferentes que lidam com cada região;
    • Bloquear: Normalmente sites governamentais impedem IPs de outros paises;
    • Split-tunneling: Encaminha de maneira transparente a conexão para outro datacenter.

1.8 – Proxy Reverso e Túneis

Em um ambiente simples, o cliente HTTP se conecta direto no servidor HTTP com as camadas básicas (DNS, HTTPs).

No mundo moderno, há elementos que adicionam camadas entre cliente e servidor para facilitar a administração do próprio site (separar site, APIs, webhooks, web-sockets, etc).

São:

  • Proxy Reverso: É um servidor HTTPs que recebe a conexão do cliente, ele é responsável por:
    • Fazer a conexão TCP real com o cliente (#C1);
    • Gerar e localizar o certificado adequado para a criptografia da conexão via SSL ou TLS;
    • Receber a requisição do cliente;
    • Rotear a requisição do cliente internamente até o servidor HTTP interno (#C2).
  • Túnel: É uma conexão VPN entre o servidor HTTP interno e o proxy reverso. O túnel é usado quando o servidor HTTP interno não está na mesma infra (servidor, datacenter) que o proxy reverso.

Nem sempre um túnel está envolvido, mas é certeza que na maioria dos casos existe um proxy reverso entre você e a URL que está acessando.

Alguns produtos avançados juntam balanceador TCP, firewall de borda e proxy-reverso num único produto ou cluster.

1.9 – CDN

Sites pequenos acabam por hospedar todos os componentes do site, os chamados ASSETS, juntos, seja na mesma URL base ou no mesmo servidor (mesmo IP).

Quando sites crescem isso fica inviável por alguns motivos:

  • Cobrança de ingress e egress: Datacenters/nuvens de hospedagem cobram pelo tráfego de entrada (ingress), pelo tráfego de saída (egress) e por número de conexões (req/s);
  • Recursos: Armazenar os assets consomem espaço em disco (storage) e tráfego para o disco (I/O), que será cobrada;
  • Segregação: Sites grandes possuem equipes separadas para programação, engenharia, web-design, marketing, vendas, juridico, etc. A quantidade de assets pode ser enorme;

Com isso, sites bem feitos fazem a separação lógica:

  • Assets estáticos: Ficam hospedados no CDN, normalmente terceirizado;
  • APIs e Webhooks: Ficam hospedados em serviços da nuvem (AWS, Azure, etc);

Exemplo:

  • meusite.com.br: HTML principal, processado na nuvem em meu servidor principal;
  • cdn.meusite.com.br: Servidor com arquivos dos assets, entregue a empresa de CDN;

Quando quero hospedar uma imagem no meu site:

  • No servidor CDN: Vou colocar o “banner.png” e gerar uma nova versão do arquivo CSS que faz referência a ele;
  • No servidor principal: Atualizar o código para usar a nova versão do CSS, incluir URL do cdn para que o navegador obetenha o CSS pelo cdn.

Se o servidor de CDN cair seu site fica fora do ar ou carrega incompleto.
Se o servidor principal cair seu site fica totalmente fora do ar.

1.10 – KeepAlive

Uma vez que o cliente se conectou via TCP e TLS ao servidor, a requisição HTTP é enviada e a resposta entregue pelo servidor.

Nesse ponto o cliente o servidor podem encerrar completamente a sessão, o que resulta na finalização da sessão TLS e da conexão TCP.

Esse é o procedimento esperado em Webhooks (depois de postado o conteúdo pelo cliente, não há mais o que conversar).

Em sites, APIs e servidores de assets (JS, CSS, imagens) isso pode resultar num stress elevado para o servidor pois a cada URL será necessário realizar a ciranda do zero (DNS, TCP, TLS, HTTP).

Para evitar isso existem duas configurações:

  • KeepAlive TCP: Mantem a conexão TCP ativa. Para impedir a desconexão por esquecimento em NAT/CGNAT a conexão faz um “ping” dentro da conexão TCP. Normalmente requer configuração explicita nos softwares para que esse “ping” seja feito;
  • KeepAlive HTTP: O cabeçalho “KeepAlive” informa explicitamente que a conexão deve ser mantida, o que resulta na persistência da conexão TCP na camada de baixo;

.

.

“A gente não se liberta de um hábito
atirando-o pela janela: é preciso
fazê-lo descer a escada,
degrau por degrau.“
Mark Twain

Terminamos por hoje!

Patrick Brandão, patrickbrandao@gmail.com