HTTP/HTTPS: o que é, protocolos de transferência de dados e criptografia TLS

O que são HTTP e HTTPS?

HTTP (HyperText Transfer Protocol) é um protocolo de camada de aplicação do modelo OSI projetado para transferir documentos hipertexto e outros dados na World Wide Web. Desenvolvido por Tim Berners-Lee em 1989, o HTTP passou por várias versões: desde HTTP/0.9 (apenas requisições GET e respostas HTML) até os modernos HTTP/2 e HTTP/3. O protocolo opera no modelo requisição-resposta: o cliente envia uma requisição ao servidor, o servidor a processa e retorna uma resposta.

HTTPS (HTTP Secure) é uma extensão do protocolo HTTP que adiciona uma camada de criptografia através do TLS (Transport Layer Security). HTTPS não é um protocolo separado — é uma combinação de HTTP e TLS. Os dados transmitidos via HTTPS são criptografados no lado do cliente e descriptografados no servidor, tornando-os inacessíveis para interceptação e adulteração. O HTTPS também fornece autenticação do servidor através de certificados SSL/TLS, garantindo que o cliente se conecte ao servidor real e não a um atacante.

A principal diferença entre HTTP e HTTPS é a segurança. O HTTP transmite dados em texto simples: qualquer nó da rede entre o cliente e o servidor pode ler o conteúdo de uma requisição ou resposta. O HTTPS criptografa todo o conteúdo, incluindo URL, cabeçalhos e corpo da requisição, deixando visível apenas o endereço IP do servidor e a porta de conexão. Para aplicativos móveis que operam em redes Wi-Fi públicas, o HTTPS é um requisito obrigatório de segurança.

Como o HTTP funciona

HTTP é um protocolo sem estado (stateless) que opera sobre TCP/IP. O cliente estabelece uma conexão TCP com o servidor (geralmente na porta 80 para HTTP ou 443 para HTTPS), envia uma requisição HTTP, recebe uma resposta HTTP e fecha a conexão (em HTTP/1.1 a conexão pode ser reutilizada). Cada interação entre cliente e servidor consiste em uma requisição e uma resposta. A ausência de estado significa que o servidor não armazena informações sobre requisições anteriores do cliente — cada requisição é processada independentemente.

O processo de interação HTTP inclui as seguintes etapas:

• Resolução DNS — o navegador ou cliente converte o nome de domínio em um endereço IP via DNS
• Handshake TCP — uma conexão TCP é estabelecida através de um handshake de três vias (SYN, SYN-ACK, ACK)
• Handshake TLS — para HTTPS, uma conexão criptografada é adicionalmente estabelecida (troca de certificados e chaves)
• Requisição HTTP — o cliente envia o método, URL, cabeçalhos e opcionalmente o corpo da requisição
• Resposta HTTP — o servidor retorna um código de status, cabeçalhos e corpo da resposta

Uma característica importante do HTTP é a idempotência de métodos. GET, HEAD, PUT, DELETE e OPTIONS são idempotentes: executar repetidamente a mesma requisição não altera o estado do servidor após a primeira execução. POST, PATCH e CONNECT não são idempotentes — cada chamada pode criar um novo recurso ou alterar o estado. Para o desenvolvimento móvel, entender a idempotência é crítico: ao reenviar uma requisição devido a um erro de rede, o cliente deve saber se é seguro repetir a requisição.

HTTPS e criptografia TLS

HTTPS usa o protocolo criptográfico TLS (Transport Layer Security) para proteger os dados transmitidos. TLS é o sucessor do SSL (Secure Sockets Layer), que foi desenvolvido pela Netscape em 1995. As versões SSL 2.0 e 3.0 são consideradas obsoletas e inseguras; as versões modernas TLS 1.2 (lançada em 2008) e TLS 1.3 (lançada em 2018) são usadas em toda parte. O TLS 1.3, em particular, reduz o tempo de estabelecimento de conexão de 2 round-trips para 1, acelerando significativamente o carregamento em dispositivos móveis.

O processo de handshake TLS inclui as seguintes etapas:

• Client Hello — o cliente envia uma lista de versões TLS suportadas e conjuntos de cifras
• Server Hello — o servidor seleciona a versão TLS e o conjunto de cifras, envia seu certificado SSL/TLS
• Verificação do certificado — o cliente verifica o certificado do servidor através de uma cadeia de confiança até a CA raiz
• Troca de chaves — o cliente e o servidor geram uma chave secreta compartilhada (chave de sessão)
• Mudança de cifra — ambos os lados confirmam a transição para comunicação criptografada

A verificação do certificado SSL/TLS é uma etapa crítica para a segurança. O cliente verifica se o certificado: não expirou, é assinado por uma Autoridade Certificadora (CA) confiável, corresponde ao domínio na URL e não foi revogado (via CRL ou OCSP). Em aplicativos móveis, recomenda-se usar Certificate Pinning — vinculação a um certificado específico do servidor ou chave pública. Isso previne ataques MITM mesmo em caso de comprometimento de uma CA. No entanto, o pinning requer cautela: quando o certificado muda, o aplicativo deve ser atualizado antecipadamente.

Estrutura de requisição e resposta HTTP

Uma requisição HTTP consiste em três partes: linha de requisição, cabeçalhos e um corpo opcional. A linha de requisição contém o método HTTP, a URL da requisição e a versão do HTTP. Os cabeçalhos transmitem meta-informação: tipo de conteúdo, tokens de autenticação, configurações de cache. O corpo está presente apenas em métodos que transmitem dados (POST, PUT, PATCH) e está ausente em GET e DELETE.

Exemplo de uma requisição HTTP para uma API REST:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Ana",
    "email": "anna@example.com"
}

Uma resposta HTTP tem estrutura similar: uma linha de status com a versão HTTP e o código de status, cabeçalhos e corpo. O código de status é um número de três dígitos que determina o resultado do processamento da requisição. Os cabeçalhos de resposta incluem Content-Type, Content-Length, Cache-Control, Set-Cookie e outros. O corpo da resposta contém os dados solicitados no formato especificado em Content-Type (geralmente JSON para APIs, HTML para páginas web, imagens para conteúdo multimídia).

Os cabeçalhos desempenham um papel crítico na operação do HTTP. Content-Type e Accept controlam o formato dos dados. Authorization transmite tokens de acesso. Cache-Control gerencia o cache. Cabeçalhos CORS (Access-Control-Allow-Origin) controlam o acesso de outros domínios em navegadores. User-Agent identifica o aplicativo cliente. Para aplicativos móveis, os cabeçalhos de controle de cache são especialmente importantes — eles ajudam a reduzir a quantidade de dados transmitidos e melhoram o desempenho em sinais fracos.

Códigos de status HTTP

Os códigos de status HTTP são agrupados em cinco classes, indicadas pelo primeiro dígito: 1xx (informativo), 2xx (sucesso), 3xx (redirecionamento), 4xx (erro do cliente), 5xx (erro do servidor). Entender esses códigos é necessário para processar corretamente as respostas em um aplicativo móvel: 2xx significa sucesso e os dados podem ser exibidos, 4xx indica um problema na requisição (mostrar um erro ao usuário), 5xx indica um problema no servidor (tentar novamente mais tarde).

Para aplicativos móveis, o tratamento do código 401 Unauthorized é especialmente importante. Ao receber este código, o cliente deve tentar atualizar o token de acesso usando um Refresh Token e repetir a requisição original. Se a atualização do token também retornar 401, o usuário deve ser redirecionado para a tela de login. Esta lógica é geralmente implementada em um Interceptor (OkHttp) ou na camada de middleware do cliente de rede.

HTTP/1.1, HTTP/2 e HTTP/3

HTTP/1.1, publicado em 1999, ainda é uma versão amplamente utilizada do protocolo. Sua principal desvantagem é o head-of-line blocking: requisições ao mesmo servidor são executadas sequencialmente, cada uma espera a conclusão da anterior. Para contornar essa limitação, os navegadores abrem de 6 a 8 conexões TCP paralelas ao mesmo domínio, aumentando a carga do servidor e o consumo de memória. HTTP/1.1 também transmite cabeçalhos em texto simples e não suporta server push.

HTTP/2 (2015) resolve o problema de bloqueio através de multiplexação — múltiplos fluxos de dados são transmitidos simultaneamente por uma única conexão TCP. O servidor pode enviar recursos ao cliente antes que o cliente os solicite (server push). HTTP/2 também comprime cabeçalhos usando HPACK, reduzindo a quantidade de dados transmitidos. Para aplicativos móveis, HTTP/2 é especialmente útil: uma conexão substitui várias, reduzindo o tempo de handshake TLS e o consumo de bateria.

HTTP/3 (2022) é a versão mais recente do protocolo, que usa QUIC (Quick UDP Internet Connections) em vez de TCP. O QUIC opera sobre UDP, eliminando o problema de head-of-line blocking no nível do protocolo de transporte. HTTP/3 reduz o tempo de estabelecimento de conexão para 0 round-trips no melhor caso (em conexões repetidas) e para 1 round-trip na primeira conexão, o que é significativamente mais rápido que HTTP/2 com seus 2-3 round-trips. Para dispositivos móveis, HTTP/3 é especialmente eficaz ao alternar entre Wi-Fi e redes móveis — a conexão não é interrompida porque o QUIC usa um identificador de conexão em vez de um endereço IP.

HTTPS no desenvolvimento móvel

Usar HTTPS em aplicativos móveis não é uma recomendação, mas um requisito obrigatório. A partir do Android 9 (API 28) e iOS 9 (ATS — App Transport Security), todas as requisições de rede devem usar HTTPS por padrão. Requisições HTTP são bloqueadas pelo sistema, e permiti-las requer uma exceção explícita na configuração do aplicativo. Google Play Store e App Store rejeitam aplicativos que transmitem dados confidenciais por HTTP, incluindo senhas, tokens e dados pessoais.

A configuração de HTTPS em um aplicativo Android inclui:

<!-- AndroidManifest.xml — permissão de requisição de rede -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — configuração de HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

No iOS, a configuração similar é feita através do Info.plist com a chave NSAppTransportSecurity. Para depurar tráfego HTTPS em aplicativos móveis, ferramentas de proxy são usadas: Charles Proxy, Proxyman ou mitmproxy. Elas exigem a instalação de um certificado SSL confiável no dispositivo. Em builds de produção, as capacidades de depuração devem ser desabilitadas e o Certificate Pinning deve ser verificado como configurado corretamente. Usar OkHttp no Android com seu CertificatePinner ou TrustManager no iOS com SecTrustEvaluate são abordagens padrão para implementar pinning.

Um aspecto importante de segurança do HTTPS no desenvolvimento móvel é o SSL Pinning. Sem pinning, o aplicativo confia em qualquer certificado assinado por uma CA conhecida. Se a CA for comprometida, um atacante poderia interceptar o tráfego do aplicativo. O pinning vincula o aplicativo a um certificado específico do servidor ou chave pública. Quando o certificado do servidor muda, uma atualização do aplicativo deve ser lançada, então o pinning é planejado com margem — vinculação a um certificado CA upstream ou uso de várias chaves de backup.