Questão de Redes de Computadores — Geral — INSTITUTO AOCP 2026
Redes de Computadores›Geral
Código
qa430608
Banca
INSTITUTO AOCP
Órgão
IF CE
Ano
2026
Cargo
Ana ( )
O IFCE possui um sistema de gestão acadêmica que apresenta degradação de desempenho durante períodos de alta demanda, como dias de matrícula on-line e lançamento de notas. A infraestrutura atual conta com um único servidor de aplicação. O analista de TI propôs uma arquitetura com múltiplas instâncias do servidor de aplicação, utilizando o NGINX como proxy reverso com balanceamento de carga. Após a implantação com três instâncias, usuários relataram perda de sessão ao serem redirecionados para instâncias diferentes: o usuário realizava login no sistema, mas, ao navegar entre módulos, era redirecionado a outra instância sem o estado de sessão, exigindo nova autenticação. Qual recurso de configuração do NGINX resolve esse problema de persistência de sessão sem exigir modificações no código da aplicação?
AConfigurar o parâmetro proxy_cache no bloco upstream do NGINX para armazenar em disco as respostas HTTP de cada instância de backend, eliminando a necessidade de o cliente manter estado de sessão.
BAumentar os valores de worker_processes e worker_connections no arquivo nginx.conf para que o NGINX mantenha conexões persistentes com as instâncias de backend, preservando automaticamente o estado de sessão de cada usuário.
CHabilitar a diretiva ip_hash no bloco upstream do NGINX, garantindo que todas as requisições provenientes de um mesmo endereço IP de cliente sejam encaminhadas consistentemente para a mesma instância do servidor de aplicação, mantendo a afinidade de sessão por endereço IP.
DConfigurar o parâmetro proxy_read_timeout com um valor elevado no NGINX, evitando que conexões de longa duração sejam encerradas prematuramente durante períodos de alta carga no sistema.
EInstalar um módulo externo de gerenciamento de sessão distribuída no NGINX para sincronizar automaticamente os estados de sessão entre as três instâncias de backend sem alterações na aplicação.
Revelar gabarito e comentário▾
GabaritoC — Habilitar a diretiva ip_hash no bloco upstream do NGINX, garantindo que todas as requisições provenientes de um mesmo endereço IP de cliente sejam encaminhadas consistentemente para a mesma instância do servidor de aplicação, mantendo a afinidade de sessão por endereço IP.
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”.
Persistência de sessão no NGINX: afinidade por IP com ip_hash
Gabarito: letra C. O problema descrito é a perda de sessão quando o balanceador distribui requisições do mesmo usuário entre instâncias diferentes. A diretiva ip_hash do NGINX resolve isso ao garantir que todas as requisições de um mesmo endereço IP de cliente sejam encaminhadas consistentemente para a mesma instância de backend, mantendo a afinidade de sessão sem exigir alterações na aplicação. Essa é a solução clássica de sticky session por IP, nativa do NGINX.
O cenário é típico de aplicações web com estado de sessão armazenado localmente em cada servidor. Quando o balanceador distribui as requisições de forma round-robin (ou outro algoritmo sem afinidade), o usuário pode ser redirecionado para uma instância que não possui o seu estado de sessão, forçando nova autenticação. A solução mais simples e imediata, sem tocar no código da aplicação, é fazer o balanceador "prender" cada cliente a uma instância específica. O NGINX oferece a diretiva ip_hash no bloco upstream para exatamente isso: ela calcula um hash do endereço IP de origem do cliente e usa esse valor para selecionar consistentemente o mesmo servidor backend para todas as requisições daquele IP.
É importante entender que ip_hash não é a única forma de persistência de sessão — existem também cookies de afinidade (como sticky com cookie) e sessões distribuídas (como Redis). Mas a questão pede explicitamente um recurso de configuração do NGINX que resolva o problema sem exigir modificações no código da aplicação. O ip_hash atende perfeitamente: é uma diretiva nativa, configurada apenas no nginx.conf, e não requer nenhuma mudança na aplicação. As demais alternativas ou não resolvem o problema ou exigem alterações externas.
A pegadinha da banca está em confundir o leitor com soluções plausíveis, mas que não atacam a causa raiz: o problema não é cache, nem conexões persistentes, nem timeout, nem sincronização distribuída — é a afinidade de sessão. O candidato que conhece o conceito de sticky session identifica rapidamente a alternativa correta.
NÃO CAIA NESSA!
A banca explora a confusão entre balanceamento de carga e persistência de sessão. O balanceamento distribui requisições para otimizar recursos; a persistência de sessão garante que um mesmo usuário sempre caia na mesma instância. Alternativas como proxy_cache (A) e worker_processes (B) parecem melhorar o desempenho, mas não resolvem a perda de sessão. Lembre-se: ip_hash é a solução nativa do NGINX para afinidade por IP.
Persistência de sessão no NGINX: Problema (Balanceador distribui requisições, Usuário cai em instância sem sessão, Exige nova autenticação); Solução: ip_hash (Hash do IP de origem, Mesmo cliente → mesma instância, Sem alterar código da aplicação); Outras técnicas (Cookie sticky, Sessão distribuída (Redis))
Alternativa A — ❌ Incorreta
O proxy_cache armazena respostas HTTP em disco para acelerar o atendimento de requisições repetidas, mas não tem relação com o estado de sessão. Ele não impede que o usuário seja redirecionado para outra instância sem o seu estado. Além disso, cachear respostas de uma aplicação dinâmica pode até causar problemas de consistência. A alternativa confunde cache de conteúdo com persistência de sessão.
Alternativa B — ❌ Incorreta
Aumentar worker_processes e worker_connections melhora a capacidade do NGINX de lidar com mais conexões simultâneas, mas não cria afinidade de sessão. Essas diretivas controlam o número de processos e conexões, não a distribuição das requisições. O problema de sessão persiste, pois o balanceador continuará distribuindo requisições de um mesmo usuário entre instâncias diferentes.
Alternativa C — ✅ Correta ⟵ GABARITO
A diretiva ip_hash no bloco upstream faz com que o NGINX calcule um hash do endereço IP de origem do cliente e use esse valor para selecionar o servidor backend. Assim, todas as requisições de um mesmo IP são encaminhadas para a mesma instância, mantendo a sessão do usuário. É uma solução nativa, configurada apenas no nginx.conf, sem necessidade de alterar o código da aplicação. Exemplo de configuração:
upstream backend {
ip_hash;
server 10.0.0.1;
server 10.0.0.2;
server 10.0.0.3;
}
Alternativa D — ❌ Incorreta
O proxy_read_timeout define o tempo máximo de espera por uma resposta do backend. Aumentá-lo evita que conexões lentas sejam encerradas prematuramente, mas não resolve a perda de sessão. O problema ocorre porque o usuário é redirecionado para outra instância, não porque a conexão é encerrada por timeout. A alternativa confunde timeout de conexão com afinidade de sessão.
Alternativa E — ❌ Incorreta
Instalar um módulo externo de gerenciamento de sessão distribuída (como Redis) exigiria modificações na aplicação para armazenar e recuperar a sessão de um repositório central. A questão pede explicitamente uma solução sem exigir modificações no código da aplicação. O ip_hash resolve o problema apenas com configuração, sem tocar no código.
Gabarito: letra C — a diretiva ip_hash garante a persistência de sessão por afinidade de IP, sem alterações na aplicação.