Timeout de inatividade do load balancer Load balancer idle timeout
ID da causa dc-lb-idle · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O load balancer apaga conexões ociosas depois de um tempo definido. O jogo continua tratando a conexão como ativa e, de repente, vem a desconexão.
Por quê O jogador fica um tempo sem enviar nenhum pacote (janela de chat aberta, AFK) → Efeito O load balancer remove a conexão ociosa (padrões comuns de 60–350 segundos) → Na tela Desconexão no instante em que o jogador volta a se mexer
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade (atrás de um ALB de 60 segundos, no máximo 30 segundos), reconectar automaticamente se cair. Servidor: responder aos heartbeats e encerrar a conexão por conta própria se não receber nenhum por um certo tempo, retomar a sessão com um token de sessão.
O que fazer (Equipe de infraestrutura)
Verificar o timeout de inatividade dos load balancers no caminho, compartilhar os valores com a equipe de desenvolvimento e aumentá-los se necessário.
Números de referência
Os padrões são 60 segundos no AWS ALB, 350 segundos para TCP e 120 segundos para UDP no NLB, e 4 minutos para TCP no Azure Load Balancer. Os valores de TCP do ALB e do NLB podem ser alterados, mas os 120 segundos de UDP do NLB não. Quando o tempo acaba, o ALB também fecha a conexão do lado do servidor, enquanto o NLB apaga em silêncio, e o servidor muitas vezes nem fica sabendo.
No gráfico
Queda de conexões em massa · Desconexões, tempo ocioso antes da queda
Onde olhar
Verificar a configuração de timeout de inatividade dos load balancers no caminho e juntar, para cada conexão que caiu, o tempo entre o último pacote e a queda. No AWS NLB, ver também o TCP_ELB_Reset_Count no CloudWatch (número de RSTs enviados pelo load balancer)
Confirma se
O tempo ocioso das conexões que caíram se concentra logo acima do valor configurado (ALB 60 s, NLB TCP 350 s etc.), e o problema se repete ao ficar parado por mais tempo que isso e depois se mexer. No NLB, o TCP_ELB_Reset_Count sobe nesses horários
Descarta se
Cai independentemente do tempo ocioso: não é esta causa. Concentrado perto de 350 segundos em servidor acessado direto, sem load balancer: “Expiração do rastreamento de conexões no grupo de segurança da nuvem”. No roteador da casa do jogador: “Expiração do mapeamento NAT”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
Edit attributes for your Application Load BalancerAWS Timeout de inatividade do ALB com padrão de 60 segundos (1–4.000 segundos); se a conexão do cliente ou do destino ficar em silêncio por esse tempo, o load balancer fecha a conexão
Network Load BalancersAWS Timeout de inatividade de TCP do NLB com padrão de 350 segundos (60–6.000 segundos); depois disso ele só para de rastrear e responde com RST se chegarem dados; fluxos UDP fixos em 120 segundos, sem possibilidade de alteração
Configure load balancer TCP reset and idle timeoutMicrosoft Azure Timeout de inatividade do Azure Load Balancer com padrão de 4 minutos (4–100 minutos); depois disso não há garantia de manter a sessão; o reset de TCP é uma configuração opcional