Redes de Computadores · FUNDATEC · 2026 | Questão sqc-qg685516

Redes de ComputadoresProtocolo

Código: qg685516
Banca: FUNDATEC
Órgão: IFC-SC
Ano: 2026
Nível: Superior

Cargo: Professor EBTT - Computação

Uma desenvolvedora está implementando o carrinho de compras de um sistema de e-commerce. Ela percebe que, ao enviar a segunda requisição HTTP ao servidor — adicionando um segundo produto ao carrinho —, o servidor não tem como associá-la à primeira requisição do mesmo cliente: o carrinho parece estar sempre vazio a cada nova chamada. Assinale a alternativa que identifica corretamente a causa do problema e a abordagem padrão para resolvê-lo.

AO HTTP é um protocolo sem estado (stateless): cada requisição é processada de forma independente, sem memória de interações anteriores. O estado da sessão é gerenciado na camada de aplicação via cookies — o servidor emite um identificador de sessão que o cliente reenvia em cada requisição subsequente.
BConexões TCP persistentes (keep-alive) não foram habilitadas. Sem elas, o servidor encerra o contexto da sessão ao fechar o socket. Com keep-alive ativo, o protocolo de transporte mantém automaticamente o estado do carrinho entre requisições.
CFalta um módulo de rastreamento ativo no servidor: servidores HTTP associam automaticamente o estado da sessão ao IP de origem, mas apenas quando o módulo está habilitado — requisições do mesmo IP passam então a compartilhar a mesma sessão.
DO cabeçalho ‘Connection: keep-alive’ não foi incluído nas requisições. Sem ele, o servidor encerra o contexto de sessão após cada resposta e não preserva variáveis, como o conteúdo do carrinho, entre chamadas consecutivas.
EO HTTP/1.0 não suportava sessões persistentes; migrar para HTTP/1.1 e habilitar keep-alive faz o protocolo manter automaticamente o estado da aplicação entre requisições do mesmo cliente.

Revelar gabarito e comentário

GabaritoA — O HTTP é um protocolo sem estado (stateless): cada requisição é processada de forma independente, sem memória de interações anteriores. O estado da sessão é gerenciado na camada de aplicação via cookies — o servidor emite um identificador de sessão que o cliente reenvia em cada requisição subsequente.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Protocolo HTTP: natureza stateless e solução com cookies

Gabarito: letra A. O HTTP é um protocolo sem estado (stateless), ou seja, cada requisição é independente e o servidor não mantém informações sobre requisições anteriores. Para preservar o estado da sessão (como o carrinho de compras), a abordagem padrão é utilizar cookies, que permitem ao servidor enviar um identificador de sessão para o cliente, que o reencaminha nas requisições seguintes.

A questão ilustra o problema clássico de um carrinho de compras: ao adicionar um segundo produto, o servidor não reconhece a sessão anterior. Isso ocorre porque o HTTP, por definição, não mantém estado entre requisições. As demais alternativas confundem esse conceito com conexões persistentes (keep-alive), que apenas reutilizam a conexão TCP, mas não resolvem a ausência de estado na camada de aplicação.

Característica	HTTP (Protocolo)	Cookies (Solução)
Natureza	Stateless (sem estado)	Mecanismo de estado na aplicação
Comportamento	Cada requisição é independente	Identificador de sessão reenviado pelo cliente
Função no carrinho	Não associa requisições do mesmo cliente	Permite ao servidor reconhecer a sessão e manter o carrinho

HTTP: stateless

1Problema
- Cada requisição é independente
- Carrinho vazio a cada chamada
2Solução padrão
- Cookies na camada de aplicação
- Servidor emite ID de sessão
- Cliente reenvia ID nas requisições
3Confusões comuns (erradas)
- Keep-alive (TCP)
  - Reutiliza conexão, não estado
  - Não resolve o problema
- Rastreamento por IP
  - Frágil (NAT, múltiplos usuários)
  - Não é padrão HTTP

LEVEL · soulevel.com.br

Alternativa A — ✅ Correta ⟵ GABARITO

Descreve corretamente que o HTTP é stateless e que a solução é gerenciar o estado na aplicação via cookies, com o servidor emitindo um identificador de sessão reenviado pelo cliente em cada requisição. É a alternativa que expressa com precisão o problema e a solução padrão.

Alternativa B — ❌ Incorreta

Atribui o problema à falta de conexões TCP persistentes (keep-alive). O keep-alive mantém a conexão TCP aberta para evitar o custo de novos handshakes, mas não preserva o estado da aplicação. Mesmo com keep-alive, cada requisição HTTP continua sendo processada de forma independente, a menos que haja um mecanismo como cookies para carregar o identificador de sessão. A afirmação de que o keep-alive "mantém automaticamente o estado do carrinho" é falsa.

Alternativa C — ❌ Incorreta

Alega que o servidor HTTP pode associar automaticamente o estado ao IP de origem quando um módulo de rastreamento está habilitado. Embora alguns mecanismos usem IP para sessão (como balanceadores de carga), essa não é uma funcionalidade padrão do HTTP, e a associação por IP é frágil (ex.: múltiplos usuários atrás de NAT). Além disso, a descrição é imprecisa: o "módulo de rastreamento" não faz parte do protocolo HTTP padrão.

Alternativa D — ❌ Incorreta

Novamente confunde o problema com a ausência do cabeçalho Connection: keep-alive. O keep-alive não gerencia estado de sessão; apenas reutiliza a conexão TCP. A preservação de variáveis como o conteúdo do carrinho depende de técnicas como cookies, sessões no servidor ou tokens, não do cabeçalho de conexão.

Alternativa E — ❌ Incorreta

Afirma que o HTTP/1.0 não suportava sessões persistentes e que o HTTP/1.1, com keep-alive, faz o protocolo "manter automaticamente o estado da aplicação". Mais uma vez, o erro é confundir persistência de conexão (keep-alive) com estado de sessão. O HTTP/1.1 mantém a conexão aberta por padrão, mas continua sendo stateless — o estado deve ser gerenciado em nível de aplicação.

NÃO CAIA NESSA!

A banca explora a confusão entre manter a conexão TCP aberta (keep-alive, camada de transporte) e manter o estado da sessão (camada de aplicação). Muitas alternativas sugerem que ativar o keep-alive resolveria o problema, mas o carrinho vazio persiste mesmo com keep-alive, pois cada requisição é independente — o estado precisa ser explicitamente carregado via cookies, tokens ou sessões no servidor.

Gabarito: letra A.

Link permanente: /questoes/qg685516