Reinicialização de TCP do Balanceador de Carga e Tempo de Espera de Inatividade

Você pode usar o Balanceador de Carga Padrão para criar um comportamento de aplicativo mais previsível para seus cenários, habilitando a Redefinição de TCP em Ocioso para uma determinada regra. O comportamento padrão do Balanceador de Carga é soltar fluxos silenciosamente quando o tempo limite ocioso de um fluxo é 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) no tempo de inatividade para informar os pontos de extremidade da aplicação de que a conexão teve o tempo limite excedido e não pode mais ser usada. Os pontos de extremidade podem estabelecer imediatamente uma nova conexão, se necessário.

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

Redefinição de TCP

Você altera esse comportamento padrão e habilita o envio de redefinições de TCP no tempo limite ocioso em regras NAT de entrada, regras de balanceamento de carga e regras de saída. Quando ativado por regra, o Balanceador de Carga envia reinicializações TCP bidirecionais (pacotes TCP RST) aos pontos de extremidade do cliente e do servidor no momento do tempo de inatividade 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 a liberação de conexão do ponto de extremidade e qualquer comunicação futura na mesma conexão TCP falhará. As aplicações podem eliminar conexões quando o soquete fecha e restabelecer conexões à medida que for necessário, sem esperar que a conexão TCP atinja o tempo limite.

Para muitos cenários, uma redefinição de TCP pode reduzir a necessidade de enviar keepalives TCP (ou da camada de aplicação) para atualizar o timeout de inatividade de um fluxo.

Escolha entre a reposição da ligação TCP e as mensagens keepalive

Use os seguintes critérios para decidir que mecanismo o seu cenário necessita:

  • Ative o reset TCP quando quiser que os endpoints sejam notificados imediatamente de que um fluxo inativo terminou, para que as aplicações possam purgar e restabelecer ligações em vez de esperar pelo seu próprio timeout TCP.
  • Utilize mensagens de keepalive de TCP quando os períodos de inatividade excederem o intervalo configurável de tempo limite de inatividade, ou quando a sua aplicação se comportar de forma inesperada com as redefinições de TCP ativadas. O Keepalives não é recomendado para aplicações móveis, porque consomem a bateria do dispositivo mais rapidamente.
  • Utilize sinais de manutenção da ligação ao nível da aplicação quando a ligação passar por um proxy em algum ponto do percurso, porque um proxy pode encerrar a ligação TCP que os sinais de manutenção da ligação da camada de transporte mantêm ativa.

Ao examinar cuidadosamente todo o cenário de ponta a ponta, pode determinar os benefícios de ativar 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 inatividade TCP configurável

O Balanceador de Carga do Azure Standard tem um intervalo de timeout de 4 minutos a 100 minutos para regras de load balancer e regras NAT de entrada. As regras de saída têm um intervalo 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 do que o valor de tempo limite, não há garantia de que a sessão TCP ou HTTP seja mantida entre o cliente e seu serviço de nuvem. Balanceador de Carga do Azure Basic (retirado) tinha até 60 minutos de timeout.

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 se esperava que fosse mantida ativa foi fechada pelo servidor."

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

Uma prática comum é utilizar um mecanismo de keep-alive TCP. Essa prática mantém a conexão ativa por um período mais longo. Para obter mais informações, consulte estes exemplos do .NET. Com o keep-alive ativado, 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 ocioso não seja atingido e que a conexão seja mantida por um longo período.

O TCP keep-alive descrito nesta secção aplica-se apenas a ligações de entrada. A reposição de TCP e o tempo limite de inatividade configurável são suportados de forma independente nas regras de saída. Para evitar perder a conexão, configure o keep-alive TCP com um intervalo menor que a configuração de tempo limite ocioso ou aumente o valor de tempo limite ocioso. Para dar suporte a esses cenários, o suporte para um tempo limite ocioso configurável está disponível.

O TCP keep-alive funciona para cenários em que a duração da bateria não é uma restrição. Não é recomendado para aplicações móveis. Usar um keep-alive TCP em um aplicativo móvel pode drenar 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 potencialmente interagir.

Entrante

  • Se houver uma regra de 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 a que ele faz referência, o tempo limite de inatividade 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 de ociosidade do IP de front-end a que faz referência, o tempo limite de inatividade do IP de front-end do balanceador de carga terá precedência.

Direção exterior

  • Se houver uma regra de saída com um valor de tempo limite ocioso diferente de 4 minutos (que é o tempo limite de ocioso de saída de IP público bloqueado), o tempo limite de ociosidade 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. (Da mesma forma, os tempos limite de inatividade de 4 minutos para IPs públicos bloqueados atribuídos ao NAT GW não são considerados.)

Limitações

Estas limitações aplicam-se ao reset TCP e ao timeout de inatividade no Balanceador de Carga do Azure:

  • O reset TCP só é enviado durante uma ligação TCP no estado ESTABELECIDO.
  • O tempo limite de inatividade não é suportado nas regras de balanceamento de carga UDP.
  • A redefinição de TCP não é suportada para regras de portas de alta disponibilidade (HA) do balanceador de carga interno quando um dispositivo virtual de rede (NVA) está no caminho. Como solução alternativa, utilize uma regra de saída com redefinição de TCP no dispositivo virtual de rede.
  • O timeout de inatividade TCP não é suportado para as regras de portas HA do balanceador de carga interno quando uma rota definida pelo utilizador (UDR) encaminha o tráfego para o balanceador de carga interno.

Próximos passos

  • Last updated on