No ecossistema de desenvolvimento web, o protocolo HTTP é a espinha dorsal da comunicação entre clientes e servidores. Muitos desenvolvedores o utilizam diariamente, mas podem ter dúvidas sobre seu funcionamento interno. Este artigo explora os fundamentos do HTTP, desde sua natureza até mecanismos como cookies e sessões, fornecendo uma base sólida para o estudo de containers web como Tomcat e Jetty.

Compreendendo a Diferença entre HTTP e HTML

Uma confusão comum é misturar HTTP com HTML. Enquanto HTML é uma linguagem de marcação para estruturar conteúdo web, HTTP é um protocolo de aplicação que define como os dados são solicitados e transmitidos entre um navegador e um servidor. Containers web como Tomcat atuam como servidores HTTP que processam essas requisições e integram com o conteúdo, seja ele HTML, JSON ou outros formatos.

A Natureza do HTTP: Formato de Comunicação Padronizado

O HTTP funciona como um "idioma" comum para troca de dados. Ele se baseia em TCP/IP para transporte, mas foca na estrutura das mensagens. Por exemplo, ao acessar um site, o navegador precisa indicar detalhes como o método de requisição (GET, POST, etc.), o recurso desejado e os formatos aceitos. Sem essa padronização, os servidores não conseguiriam interpretar as demandas dos clientes.

O Fluxo Completo de uma Requisição HTTP

Do clique no link à exibição da página, múltiplas etapas ocorrem:

1. O navegador inicia uma conexão TCP com o servidor após resolver o nome de domínio.
2. Um handshake TCP é realizado para estabelecer uma comunicação confiável.
3. O navegador empacota a requisição em um formato HTTP estruturado.
4. O servidor (por exemplo, um container web) recebe, analisa e processa a requisição.
5. Uma resposta HTTP é enviada de volta, contendo dados como status, cabeçalhos e corpo.
6. O navegador interpreta a resposta e renderiza o conteúdo.

Containers web usam técnicas como multithreading para gerenciar milhares de requisições simultaneamente, otimizando a performance.

Estrutura das Mensagens HTTP

Exemplo de Requisição HTTP

Considere uma requisição para autenticação de API:

POST /api/v2/users/authenticate HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Length: 65

{"email": "usuario@exemplo.com", "senha": "minhaS3nhaF0rte!"}

Ela se divide em:

• Linha de requisição: Método (POST), caminho (/api/v2/users/authenticate) e versão HTTP.
• Cabeçalhos: Chaves-valor com metadados, como tipo de conteúdo e agente do usuário.
• Corpo: Dados enviados, neste caso em formato JSON.

Exemplo de Resposta HTTP

Uma resposta correspondente:

HTTP/1.1 201 Created
Date: Mon, 15 Jul 2024 10:00:00 GMT
Content-Type: application/json; charset=utf-8
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

{"status": "success", "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

Ela inclui linha de status (versão, código, descrição), cabeçalhos e corpo.

Gerenciando Estado com Cookies e Sessões

O HTTP é sem estado, o que significa que cada requisição é independente. Para manter contextos como logins, mecanismos adicionais são usados:

Cookies

São pequenos dados armazenados no cliente. O servidor envia um cookie via cabeçalho Set-Cookie, e o navegador o inclui em requisições subsequentes. Isso permite identificação, mas dados sensíveis não devem ser armazenados diretamente por segurança.

Sessões

No servidor, uma sessão é criada para armazenar informações do usuário, como estado de autenticação. Um ID de sessão é gerado e enviado ao cliente como cookie. Em implementações Java, containers como Tomcat gerenciam sessões, podendo persisti-las em sistemas como Redis para escalabilidade e confiabilidade. Sessões têm tempo de expiração para liberar recursos.

Conexões Persistentes e o Estado do HTTP

Uma dúvida comum: se o HTTP é sem estado, como as conexões persistentes (keep-alive) se encaixam? Elas operam em níveis diferentes:

• Conexão persistente (TCP): Reutiliza uma conexão TCP para múltiplas requisições, reduzindo a sobrecarga de handshakes. Isso é configurado via cabeçalho Connection: keep-alive.
• Sem estado (HTTP): Cada requisição ainda contém todas as informações necessárias; o servidor não depende de histórico.

Assim, a eficiência da camada de transporte não contradiz a sem-estado da aplicação. Versões mais recentes como HTTP/2 melhoram isso com multiplexação.