Gerenciamento de Conexões HTTP

Ao navegar em páginas web modernas, que frequentemente incluem diversos recursos como imagens, scripts e folhas de estilo, o navegador realiza múltiplas solicitações HTTP. O método de gerenciamento dessas conexões TCP subjacentes tem um impacto significativo no desempenho.

Conexões Persistentes e Não Persistentes

Historicamente, cada solicitação HTTP abria e fechava uma nova conexão TCP. Esse modelo, conhecido como conexão não persistente (ou "curta"), acarretava uma sobrecarga considerável devido ao handshake TCP para cada recurso. No entanto, a partir do HTTP/1.1, as conexões passaram a ser persistentes por padrão.

• Com conexões persistentes, uma única conexão TCP pode ser reutilizada para múltiplas trocas HTTP, reduzindo a latência e o consumo de recursos. Para encerrar explicitamente uma conexão persistente, o cabeçalho Connection: close é enviado.
• Em versões anteriores ao HTTP/1.1, as conexões eram não persistentes por padrão. Para solicitar uma conexão persistente, o cabeçalho Connection: Keep-Alive era utilizado.

Pipelining (Pipeline HTTP)

O pipelining permite que um cliente envie várias solicitações HTTP através de uma única conexão TCP persistente sem esperar pela resposta de cada uma. Isso pode melhorar a eficiência, especialmente em redes com alta latência, ao evitar o tempo de espera entre o envio de uma solicitação e o recebimento de sua resposta antes de enviar a próxima.

No entanto, o pipelining possui limitações. Se a primeira solicitação na fila demorar a ser processada (problema conhecido como "head-of-line blocking"), as solicitações subsequentes também serão atrasadas. Por essa razão, e com o advento do HTTP/2 e HTTP/3, que oferecem multiplexação real, o pipelining não é amplamente adotado e é até desabilitado por padrão em muitos navegadores.

Estado em HTTP: Cookies e Sessões

O protcoolo HTTP, por sua natureza, é sem estado, o que significa que o servidor não mantém informações sobre as solicitações anteriores de um cliente específico. Para construir aplicações web interativas que exigem o rastreamento de estado (como carrinhos de compras ou sessões de login), mecanismos adicionais são necessários. Os Cookies e as Sessões são as principais soluções para esse desafio.

Cookies HTTP

Cookies são pequenos blocos de dados que um servidor web envia para o navegador do usuário. O navegador os armazena e os envia de volta ao mesmo servidor em cada solicitação subsequente. Eles servem para identificar usuários, armazenar preferências e manter o estado da sessão. Embora úteis, o envio de Cookies com cada requisição pode adicionar sobrecarga, especialmente em dispositivos móveis.

Finalidades Comuns

• Gerenciamento de Sessão: Manter um usuário logado, itens de carrinho de compras, pontuações de jogos, etc.
• Personalização: Armazenar configurações do usuário, como tema ou idioma preferencial.
• Rastreamento: Analisar o comportamento do usuário e suas interações com o site.

Ciclo de Criação e Envio

Quando um servidor deseja definir um Cookie, ele inclui um cabeçalho Set-Cookie na sua resposta HTTP:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: user_session=abCdeF123; HttpOnly; SameSite=Lax
Set-Cookie: preferences=dark_mode; Expires=Wed, 21 Oct 2025 07:28:00 GMT

<!-- conteúdo da página -->

Posteriormente, em cada solicitação ao mesmo domínio, o navegador inclui os Cookies armazenados no cabeçalho Cookie:

GET /profile HTTP/1.1
Host: www.example.org
Cookie: user_session=abCdeF123; preferences=dark_mode

Tipos de Cookies

• Cookies de Sessão: São temporários e são excluídos quando o navegador é fechado.
• Cookies Persistentes: Permanecem no navegador por um período definido, especificado pelos atributos Expires (data e hora específicas) ou Max-Age (duração em segundos).

Set-Cookie: user_id=johnDoe123; Max-Age=3600;  // Válido por 1 hora

Definição de Escopo

• Domain: Controla quais domínios podem receber o Cookie. Se não especificado, assume o domínio do documento atual (excluindo subdomínios). Se definido (e.g., Domain=example.com), o Cookie será enviado para example.com e seus subdomínios (e.g., blog.example.com).
• Path: Restringe o Cookie a um caminho específico dentro do domínio. Se definido como Path=/app, o Cookie será enviado para solicitações como /app, /app/users, /app/products, mas não para /admin.

Sessões no Servidor

Em contraste com os Cookies, que armazenam dados no lado do cliente, as sessões armazenam informações de estado no lado do servidor. Isso oferece maior segurança, pois os dados sensíveis não são expostos diretamente no navegador do usuário.

Para cada nova sessão, o servidor gera um ID de Sessão único. Este ID é então enviado ao cliente (geralmente via Cookie) e usado em solicitações subsequentes para recuperar os dados da sessão correspondente armazenados no servidor. Os dados da sessão podem ser persistidos em arquivos, bancos de dados ou, para melhor desempenho, em armazenamentos em memória como Redis.

Fluxo de Autenticação com Sessões

1. O usuário envia credenciais (nome de usuário e senha) em um formulário.
2. O servidor valida as credenciais. Se forem válidas, ele cria uma nova sessão, armazena as informações do usuário (ou um subset delas) em um armazenamento de sessão (e.g., Redis) e associa-as a um ID de Sessão.
3. A resposta do servidor inclui um cabeçalho Set-Cookie contendo o ID de Sessão.
4. O navegador armazena esse Cookie. Em solicitações futuras ao mesmo servidor, o navegador envia o Cookie com o ID de Sessão.
5. O servidor recebe o ID de Sessão, o utiliza para recuperar os dados do usuário do armazenamento de sessão e processa a solicitação.

A segurança do ID de Sessão é crítica; ele deve ser imprevisível e regularmente regenerado, especialmente após eventos de autenticação ou mudança de privilégios. Para operações de alta segurança, como transações financeiras, uma reautenticação (senha, OTP) é frequentemente necessária, além da gestão de sessão.

Métodos de Implementação de Sessão

• Via Cookies: É a abordagem mais comum. O ID de Sessão (ex: JSESSIONID) é armazenado em um Cookie.
• Via Reescrever URL (URL Rewriting): Se os Cookies estiverem desabilitados no navegador, o ID de Sessão pode ser incorporado diretamente na URL de todas as requisições e links gerados pelo servidor. Exemplo: http://www.site.com/page.html?sessionId=xyz123.

Escolha entre Cookie e Sessão

• Complexidade dos Dados: Sessões podem armazenar qualquer tipo de dado complexo, enquanto Cookies são limitados a strings de texto (geralmente ASCII).
• Segurança: Dados armazenados em sessões no servidor são mais seguros, pois não são acessíveis diretamente pelo cliente. Dados em Cookies no cliente podem ser inspecionados (embora possam ser criptografados).
• Carga no Servidor: Armazenar grandes volumes de dados para muitos usuários em sessões pode aumentar significativamente a carga e o consumo de memória do servidor. Para aliviar a carga do servidor, Cookies são preferíveis para dados não sensíveis e de menor volume.

Otimização com Cache HTTP

O cache é um mecanismo fundamental para melhorar o desempenho de aplicações web, reduzindo a carga nos servidores e diminuindo o tempo de resposta para os clientes.

Vantagens do Cache

• Redução da Carga do Servidor: Diminui o número de requisições que chegam ao servidor de origem, liberando recursos.
• Melhora na Latência do Cliente: Recursos cacheados podem ser entregues mais rapidamente (geralmente da memória local do cliente ou de um servidor proxy próximo), resultando em uma experiência de usuário mais ágil.

Tipos de Implementação

• Cache do Navegador (Cliente): Armazena recursos diretamente no dispositivo do usuário.
• Cache de Proxy: Servidores intermediários que armazenam cópias de recursos acessados por múltiplos clientes.

Controle de Cache: Cabeçalho Cache-Control

O cabeçalho HTTP Cache-Control, introduzido no HTTP/1.1, oferece controle granular sobre o comportamento do cache.

Diretivas Comuns:

• no-store: Proíbe o armazenamento em cache de qualquer parte da requisição ou resposta.

Cache-Control: no-store

46. no-cache: Permite que o recurso seja armazenado em cache, mas exige que o cache o revalide com o servidor de origem antes de usá-lo para uma nova solicitação.

Cache-Control: no-cache

48. private: Indica que o recurso pode ser armazenado em cache, mas apenas por caches privados (geralmente o navegador do usuário).

Cache-Control: private

50. public: Permite que o recurso seja armazenado em cache por qualquer cache, incluindo caches proxy compartilhados.

Cache-Control: public

52. max-age=<seconds></seconds>: Especifica o tempo máximo em segundos que um recurso é considerado fresco. Após esse período, ele é considerado obsoleto e precisa ser revalidado.

Cache-Control: max-age=86400  // 24 horas

Cabeçalho Expires

O cabeçalho Expires (do HTTP/1.0) também define uma data/hora de expiração para o recurso. No entanto, Cache-Control: max-age tem precedência em HTTP/1.1 e versões posteriores.

Expires: Thu, 04 Jul 2024 10:00:00 GMT

Validação de Cache

Quando um recurso armazenado em cache se torna obsoleto (expirado ou no-cache), o cliente pode tentar revalidá-lo com o servidor de origem em vez de baixar o recurso inteiro novamente. Isso é feito usando identificadores específicos:

ETag (Entity Tag)

Um ETag é um identificador único para uma versão específica de um recurso. O servidor de origem gera um ETag e o inclui na resposta:

ETag: "v1.2-abc-def-123456"

Para revalidar, o cliente envia esse ETag no cabeçalho If-None-Match na próxima solicitação:

GET /styles.css HTTP/1.1
Host: www.example.org
If-None-Match: "v1.2-abc-def-123456"

Se o ETag enviado pelo cliente corresponder à versão atual do recurso no servidor, o servidor responde com um status 304 Not Modified, indicando que o cliente pode usar sua cópia em cache. Caso contrário, o servidor envia o novo recurso com um status 200 OK e um novo ETag.

Last-Modified

O cabeçalho Last-Modified indica a data e hora em que o recurso foi modificado pela última vez no servidor de origem. É uma forma menos precisa de validação que ETag (limitada à precisão de segundos).

Last-Modified: Fri, 20 Oct 2023 15:30:00 GMT

O cliente pode usar essa data no cabeçalho If-Modified-Since para revalidar:

GET /script.js HTTP/1.1
Host: www.example.org
If-Modified-Since: Fri, 20 Oct 2023 15:30:00 GMT

Se o recurso não foi modificado desde a data especificada, o servidor retorna 304 Not Modified. Caso contrário, envia o novo recurso (200 OK) com uma nova data Last-Modified.