Redefinição do TCP do Load Balancer e tempo limite ocioso

Você pode usar o Standard Load Balancer para criar um comportamento de aplicativo mais previsível para seus cenários, permitindo a Redefinição de TCP no modo ocioso para uma determinada regra. O comportamento de padrão do Load Balancer é remover fluxos silenciosamente quando o tempo limite de ociosidade de um fluxo for atingido. Habilitar a redefinição de TCP faz com que o Balanceador de Carga envie redefinições de TCP bidirecionais (pacotes de redefinição de TCP) em tempo limite ocioso para informar aos pontos de extremidade do aplicativo que a conexão atingiu o tempo limite e não é mais utilizável. Pontos de extremidade podem estabelecer imediatamente uma nova conexão se necessário.

O diagrama mostra o comportamento de redefinição de TCP padrão de nós de rede.

Redefinição de TCP

Alterar esse comportamento padrão e habilitar envio de Redefinições de TCP no tempo limite de ociosidade em regras NAT de entrada, regras de balanceamento de carga e regras de saída. Quando ativado por regra, o Balanceador de Carga envia Redefinições de TCP bidirecionais (pacotes TCP RST) para os pontos de extremidade do cliente e do servidor no momento do tempo limite ocioso para todos os fluxos correspondentes.

Os pontos de extremidade que recebem pacotes TCP RST fecham o soquete correspondente imediatamente. Isso fornece uma notificação imediata para os pontos de extremidade que a liberação da conexão ocorreu e qualquer comunicação futura na mesma conexão TCP falhará. Aplicativos podem limpar conexões quando o soquete é fechado e restabelecer as conexões conforme necessário, sem esperar o tempo limite eventual da conexão TCP.

Em muitos cenários, a redefinição do TCP pode reduzir a necessidade de enviar keepalives do TCP (ou da camada de aplicativos) para atualizar o tempo limite de inatividade de um fluxo.

Escolha entre redefinição de TCP e keepalives

Use os seguintes critérios para decidir qual mecanismo seu cenário precisa:

  • Ative o reset do TCP quando quiser que os endpoints sejam notificados imediatamente de que um fluxo ocioso foi encerrado, para que as aplicações possam purgar e restabelecer conexões em vez de esperar seu próprio timeout TCP.
  • Use o TCP keepalives quando suas durações de inatividade excederem o intervalo de tempo de espera configurável, ou quando sua aplicação se comporta de forma inesperada com os resets TCP ativados. Keepalives não são recomendados para aplicações móveis, porque consomem a bateria do dispositivo mais rápido.
  • Use keepalives na camada de aplicação quando a conexão for encaminhada por um proxy em algum ponto do caminho, pois um proxy pode encerrar a conexão TCP que os keepalives da camada de transporte atualizam.

Ao examinar cuidadosamente todo o cenário de ponta a ponta, você pode determinar os benefícios de ativar as redefinições de TCP e ajustar o tempo limite de inatividade. Depois, decida se são necessários mais passos para garantir o comportamento desejado da aplicação.

Tempo limite de ociosidade de TCP configurável

O Azure Load Balancer Standard tem um intervalo de tempo limite de 4 a 100 minutos para regras do balanceador de carga e regras de NAT de entrada. As regras de saída têm uma faixa configurável de 4 a 120 minutos. O padrão é 4 minutos para todos os tipos de regras. Se um período de inatividade for maior que o valor de tempo limite, não haverá nenhuma garantia de que a sessão TCP ou HTTP seja mantida entre o cliente e o serviço de nuvem. O Azure Load Balancer Basic (desativado) tinha um intervalo de tempo limite de até 60 minutos.

Quando a conexão é fechada, seu aplicativo cliente pode receber a seguinte mensagem de erro: "A conexão subjacente foi fechada: uma conexão que deveria ser mantida ativa foi fechada pelo servidor".

Se as redefinições de TCP estiverem habilitadas e forem perdidas por qualquer motivo, ela será redefinida para quaisquer pacotes subsequentes. Se a opção de redefinição de TCP não estiver habilitada, os pacotes serão descartados silenciosamente.

Uma prática comum é usar um TCP keep alive. Essa prática mantém a conexão ativa por um período maior. Para obter mais informações, consulte estes exemplos do .NET. Com o keep alive habilitado, os pacotes são enviados durante os períodos de inatividade na conexão. Os pacotes keep-alive garantem que o valor de tempo limite de ociosidade não será atingido, e a conexão será mantida por um longo período.

O TCP keep-alive descrito nesta seção se aplica apenas a conexões de entrada. O reset TCP e o tempo limite de inatividade configurável são compatíveis separadamente em regras de saída. Para evitar a perda da conexão, configure o TCP keep-alive com um intervalo menor do que a configuração de tempo limite de ociosidade ou aumente o valor do tempo limite de ociosidade. Para dar suporte a esses cenários, está disponível o suporte a um tempo limite ocioso configurável.

O TCP keep-alive funciona para cenários em que a vida útil da bateria não é uma restrição. Não é recomendável para aplicativos móveis. Usar o TCP keep alive em um aplicativo móvel pode consumir a bateria do dispositivo mais rapidamente.

Ordem de precedência

É importante levar em conta como os valores de tempo limite ocioso definidos para diferentes IPs podem interagir.

Entrada

  • Se houver uma regra do balanceador de carga (de entrada) com um valor de tempo limite ocioso definido de forma diferente do tempo limite ocioso do IP de front-end ao qual ela faz referência, o tempo limite ocioso do IP de front-end do balanceador de carga terá precedência.
  • Se houver uma regra NAT de entrada com um valor de tempo limite ocioso definido de forma diferente do tempo limite ocioso do IP de front-end ao qual ela faz referência, o tempo limite ocioso do IP de front-end do balanceador de carga terá precedência.

Saída

  • Se houver uma regra de saída com um valor de tempo limite ocioso diferente de 4 minutos (que é o tempo limite ocioso de saída de IP bloqueado), o tempo limite ocioso da regra de saída terá precedência.
  • Como um gateway NAT sempre terá precedência sobre as regras de saída do balanceador de carga (e sobre os endereços IP públicos atribuídos diretamente às VMs), o valor de tempo limite ocioso atribuído ao gateway NAT será usado. (Na mesma linha, os tempos limite ociosos de saída de IPs bloqueados de 4 minutos de quaisquer IPs atribuídos ao NAT GW não são considerados.)

Limitações

Essas limitações se aplicam à redefinição de TCP e ao tempo limite de inatividade no Azure Load Balancer:

  • O reset do TCP só é enviado durante uma conexão TCP no estado ESTABELECIDO.
  • O timeout de inatividade não é suportado para regras de balanceamento de carga UDP.
  • O reset TCP não é permitido para regras de portas de alta disponibilidade (HA) de balanceadores de carga internos quando um dispositivo virtual de rede (NVA) está no caminho. Como solução alternativa, use uma regra de saída com reset TCP a partir do dispositivo virtual de rede.
  • O tempo limite de inatividade do TCP não é compatível com as regras de portas HA do balanceador de carga interno quando uma rota definida pelo usuário (UDR) encaminha o tráfego para o balanceador de carga interno.

Próximas etapas

  • Last updated on