Expiração do rastreamento de conexões no grupo de segurança da nuvem Cloud security group connection tracking timeout
ID da causa dc-cloud-conntrack · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O firewall acoplado ao servidor na nuvem (grupo de segurança) também rastreia conexões, e as entradas de rastreamento de conexões ociosas expiram depois de um tempo definido. Mesmo em servidores acessados direto, sem load balancer, o jogador que ficou parado pode sofrer desconexão.
Por quê Configuração em que o grupo de segurança rastreia as conexões do jogo (só alguns endereços permitidos, regras de saída restritas, passagem por NLB etc.) → Efeito A entrada de rastreamento de uma conexão que ficou ociosa por um tempo expira, e o grupo de segurança descarta em silêncio os pacotes que chegam depois → Na tela Depois de ficar ausente, o jogador volta a se mexer, não tem resposta e sofre desconexão. O programa do servidor demora muito para perceber
Responsável principal Infraestrutura de servidores (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 (no máximo 175 segundos para 350 segundos em TCP, no máximo 90 segundos para 180 segundos em streams UDP), 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 tempo de rastreamento de conexões da instância (TcpEstablishedTimeout) e aumentá-lo se necessário (no UDP não dá, porque 180 segundos já é o máximo), avaliar uma configuração de grupo de segurança que não gere rastreamento (portas do jogo abertas para todos os endereços, todas as saídas permitidas; conexões que passam por NLB continuam sendo rastreadas), fazer testes de inatividade ao migrar para uma nova geração de instâncias.
Números de referência
Na AWS, tipos de instância Nitro v6 apagam por padrão a entrada de rastreamento de conexões TCP ociosas depois de 350 segundos (5 dias nos outros tipos). No UDP, o padrão é de 180 segundos para fluxos com várias trocas de requisição e resposta (streams) e de 30 segundos para fluxos em um só sentido ou com uma única requisição e resposta.
No gráfico
Queda de conexões em massa · Desconexões, tempo ocioso antes da queda
Onde olhar
Verificar a configuração do tempo de rastreamento de conexões da instância e as regras do grupo de segurança (se a configuração gera rastreamento) e juntar o tempo ocioso das conexões que caíram. Logo depois da queda, ver no servidor com ss -tnoi se a conexão continua ESTABLISHED, com o timer de retransmissão (timer:(on,…)) rodando e o backoff crescendo
Confirma se
O tempo ocioso das conexões que caíram se concentra logo acima de 350 s no TCP, 180 s em streams UDP ou 30 s em UDP de um só sentido, e o socket do lado do servidor continua ESTABLISHED sem perceber a queda (se o servidor tem dados a enviar, só repete as retransmissões)
Descarta se
Configuração em que o grupo de segurança não rastreia (portas do jogo abertas para todos os endereços, todas as saídas permitidas, sem NLB no caminho): não é esta causa. Com NLB no caminho: comparar os valores com “Timeout de inatividade do load balancer”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
Amazon EC2 security group connection trackingAWS Rastreamento de TCP ocioso com padrão de 350 segundos (Nitro v6; 432.000 segundos = 5 dias nos demais), UDP em um só sentido 30 segundos e stream 180 segundos (máximo 180); regras que permitem todos os endereços não são rastreadas; conexões via NLB são sempre rastreadas