Esgotamento de portas efêmeras em conexões entre servidores Ephemeral port exhaustion (TIME_WAIT)

ID da causa so-ports · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)

Abrir o card interativo, com figuras e simulações →

Quando o servidor do jogo abre e fecha conexões curtas com frequência para o BD ou outros servidores, as conexões encerradas seguram a porta por um tempo e não dá para abrir conexões novas.

Por quê Abre e fecha uma conexão nova a cada pedido → Efeito O lado que fecha primeiro segura a porta por cerca de 60 s no Linux (TIME_WAIT), e as portas disponíveis acabam → Na tela Pedidos internos falham: salvamentos falham e recursos dão erro

Sintomas: Ação perdida / rollback, Não conecta / loading infinito
Fatores: Perda de pacotes
Quem é afetado: Servidor inteiro, Só um recurso específico
Quando: Quando junta muita gente
Responsável: Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento): Reutilizar conexões (pool de conexões), não abrir e fechar uma conexão nova a cada pedido.
O que fazer (Equipe de infraestrutura): Ampliar a faixa de portas (ip_local_port_range), avaliar a reutilização de TIME_WAIT em conexões de saída (tcp_tw_reuse no Linux), monitorar o número de TIME_WAIT.
Números de referência: A faixa de portas padrão do Linux (32768–60999) tem cerca de 28 mil portas. Mais de 470 conexões novas por segundo para o mesmo endereço de destino esgotam essa faixa. O Windows tem cerca de 16 mil portas por padrão (49152–65535) e um TIME_WAIT mais longo, então esgota mais rápido.
No gráfico: Achata ao bater no limite · Sockets em TIME_WAIT, falhas de conexão interna
Onde olhar: Contar os sockets em TIME_WAIT por endereço de destino com ss -tan state time-wait e procurar falhas de connect (EADDRNOTAVAIL) no log do servidor do jogo
Confirma se: Os TIME_WAIT para o mesmo destino (BD etc.) achatam perto do tamanho da faixa de portas efêmeras (cerca de 28 mil por padrão), e o connect falha com EADDRNOTAVAIL
Descarta se: Poucos TIME_WAIT, mas só as conexões para serviços externos falham: “Limite de conexões e portas do gateway NAT na nuvem”
Como verificar: Ferramentas de infra (sem precisar do código do jogo)
Saiba mais: No Linux, os 60 s do TIME_WAIT são um valor fixo no kernel. Reduzir o tcp_fin_timeout, de nome parecido, não encurta o TIME_WAIT.

Fontes

IP Sysctl Linux kernel
ip_local_port_range com padrão 32768–60999; tcp_tw_reuse; tcp_fin_timeout é o tempo de permanência no estado FIN_WAIT_2
include/net/tcp.h (Linux v6.12) Linux kernel
TCP_TIMEWAIT_LEN(60*HZ): os cerca de 60 s do TIME_WAIT são uma constante do kernel
TCP/IP port exhaustion troubleshooting Microsoft
Portas dinâmicas do Windows com padrão 49152–65535; conexões fechadas seguram a porta em TIME_WAIT por 4 minutos por padrão
ss(8) — Linux manual page iproute2
O filtro de estado state time-wait mostra só os sockets em TIME_WAIT
connect(2) — Linux manual page Linux man-pages
EADDRNOTAVAIL: não dá para abrir a conexão porque todas as portas da faixa efêmera estão em uso

Veja também

Mesma camada: L7 SO do servidor (kernel)

Mesmo sintoma (Ação perdida / rollback) em outras camadas

Erro na sincronização do relógio L1 Processo do jogo no cliente
Limite de conexões e portas do gateway NAT na nuvem L5 Equipamentos de rede do data center
Microburst no switch L5 Equipamentos de rede do data center
Ring buffer insuficiente L6 Placa de rede do servidor
Limite de PPS da nuvem excedido L6 Placa de rede do servidor
Configuração de retransmissão do UDP confiável L8 Sockets e protocolos
Acúmulo na fila de mensagens L9 Processo do jogo no servidor
Crash do servidor L9 Processo do jogo no servidor

Ver o card interativo, com figuras e simulações