Conceitos de balanceamento de carga HTTP(S)

Neste documento, apresentamos os conceitos de que você precisa para saber como configurar o balanceamento de carga HTTP ou HTTPS.

Princípios básicos

Um balanceador de carga HTTP(S) tem diversos componentes. O diagrama a seguir representa a arquitetura de um balanceador de carga HTTP(S) completo:

Diagrama de balanceamento de carga inter-regional com base em conteúdo (clique para ampliar)
Diagrama de balanceamento de carga inter-regional com base em conteúdo (clique para ampliar)

Nas seções a seguir, descrevemos como cada componente funciona em conjunto para criar cada tipo de balanceador de carga. Para ver uma descrição detalhada de cada componente, consulte Componentes abaixo.

Balanceamento de carga HTTP

A estrutura de um balanceador de carga HTTP completo é assim:

  1. Uma regra de encaminhamento direciona solicitações recebidas para um proxy HTTP de destino.
  2. O proxy HTTP de destino verifica cada solicitação em um mapa de URL para determinar o serviço de back-end apropriado a ela.
  3. O serviço de back-end direciona cada solicitação a um back-end apropriado com base na capacidade de exibição, zona e integridade de instância dos back-ends anexados. A integridade de cada instância de back-end é verificada por meio de uma verificação de integridade HTTP, uma verificação de integridade HTTPS ou uma verificação de integridade HTTP/2. Se o serviço de back-end estiver configurado para usar uma verificação de integridade HTTPS ou HTTP/2, a solicitação é criptografada a caminho da instância de back-end.
  4. Sessões entre o balanceador de carga e a instância podem usar o protocolo HTTP, HTTPS ou HTTP/2. Se você usar HTTPS ou HTTP/2, será necessário que cada instância tenha um certificado SSL.

Balanceamento de carga de HTTPS

Um balanceador de carga HTTPS tem a mesma estrutura básica de um balanceador de carga HTTP (descrito acima), mas difere das seguintes maneiras:

Comunicações do cliente com o balanceador de carga

  • Os clientes podem se comunicar com o balanceador de carga usando o protocolo HTTP 1.1 ou HTTP/2.
  • Quando HTTPS é usado, o padrão dos clientes modernos é HTTP/2. Isso é controlado no cliente, não no balanceador de carga HTTPS.
  • Não é possível desativar o HTTP/2 alterando a configuração do próprio balanceador de carga. No entanto, é possível configurar alguns clientes para usar HTTP 1.1 em vez de HTTP/2. Por exemplo, com curl, use o parâmetro --http1.1.
  • Os balanceadores de carga HTTPS não são compatíveis com a autenticação baseada em certificado de cliente, também conhecida como autenticação TLS mútua.

Portas abertas

Os balanceadores de carga HTTP(S) são balanceadores de carga de proxy reverso. O balanceador de carga encerra as conexões de entrada e depois abre novas conexões do balanceador de carga para os back-ends. A funcionalidade de proxy reverso é fornecida pelo Google Front Ends (GFE).

As regras de firewall que você define bloqueiam o tráfego dos GFEs para os back-ends, mas não bloqueiam o tráfego de entrada para os GFEs.

Os balanceadores de carga HTTP(S) têm diversas portas abertas para acomodar outros serviços do Google que são executados na mesma arquitetura. Se você executar uma verificação de segurança ou de porta nos endereços IP externos de um balanceador de carga HTTP(S) do GCP, terá a impressão de que há mais portas abertas.

Isso não afeta balanceadores de carga HTTP(S). As regras de encaminhamento, que são usadas na definição de um balanceador de carga HTTP(S), só podem referenciar as portas TCP 80, 8080 e 443. O tráfego que tiver uma porta de destino TCP diferente não será encaminhado ao back-end do balanceador de carga.

Componentes

Veja a seguir os componentes dos balanceadores de carga HTTP(S).

Regras e endereços de encaminhamento

As regras de encaminhamento roteiam o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga que consiste em proxy de destino, mapa de URL e um ou mais serviços de back-end.

Cada regra de encaminhamento fornece um único endereço IP que pode ser usado em registros DNS do aplicativo. Não é necessário nenhum balanceamento de carga baseado em DNS. É possível especificar o endereço IP a ser usado ou permitir que o Google Cloud Load Balancing atribua um para você.

  • A regra de encaminhamento de um balanceador de carga HTTP só pode referenciar as portas TCP 80 e 8080.
  • A regra de encaminhamento de um balanceador de carga HTTPS só pode referenciar a porta TCP 443.

Proxies de destino

Os proxies de destino encerram as conexões HTTP(S) dos clientes. Uma ou mais regras de encaminhamento global direcionam o tráfego para o proxy de destino, e o proxy de destino consulta o mapa de URL para determinar como rotear tráfego para os back-ends.

Os proxies definem cabeçalhos de solicitação/resposta HTTP da seguinte maneira:

  • Via: 1.1 google (solicitações e respostas)
  • X-Forwarded-Proto: [http | https] (apenas solicitações)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (apenas solicitações) Uma lista separada por vírgulas de endereços IP anexada pelos intermediários em que a solicitação transitou. Se você estiver executando proxies dentro do GCP que anexam dados ao cabeçalho X-forwarded-For, seu software precisará considerar a existência e a quantidade desses proxies. Somente as entradas <immediate client IP> e <global forwarding rule external IP> são fornecidas pelo balanceador de carga. Todas as outras entradas na lista são passadas sem verificação. A entrada <immediate client IP> indica o cliente que se conectou diretamente ao balanceador de carga. A entrada <global forwarding rule external IP> indica o endereço IP externo da regra de encaminhamento do balanceador de carga. Se houver mais entradas do que isso, a primeira entrada da lista será o endereço do cliente original. Outras entradas antes de <immediate client IP> representam outros proxies que encaminharam a solicitação para o balanceador de carga.
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (apenas solicitações)
    Parâmetros do Stackdriver Trace.

É possível criar cabeçalhos de solicitação personalizados se os cabeçalhos padrão não atenderem às suas necessidades. Para mais informações sobre este recurso, consulte Como criar cabeçalhos de solicitação definidos pelo usuário.

Não espere que o proxy mantenha a capitalização dos nomes de cabeçalho de solicitação ou resposta. Por exemplo, um cabeçalho de resposta Server: Apache/1.0 pode aparecer no cliente como server: Apache/1.0.

Mapas de URL

Os mapas de URL definem os padrões de correspondência do roteamento de solicitações baseado em URL aos serviços de back-end apropriados. Um serviço padrão é definido para lidar com qualquer solicitação que não corresponda a uma regra de host ou regra de correspondência de caminho especificada. Em algumas situações, como o exemplo de balanceamento de carga entre regiões, é possível não definir nenhuma regra de URL e depender apenas do serviço padrão. Para roteamento de tráfego baseado em conteúdo, o mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends.

Certificados SSL

Se você estiver usando o balanceamento de carga HTTPS, será necessário instalar um ou mais certificados SSL no proxy HTTPS de destino. Até quinze (15) certificados SSL podem estar instalados. Eles são usados por proxies HTTPS de destino para autenticar comunicações entre o balanceador de carga e o cliente. Podem ser certificados SSL gerenciados pelo Google ou autogerenciados.

Para mais informações sobre como instalar certificados SSL para um balanceador de carga HTTPS, consulte Certificados SSL.

Se você estiver usando HTTPS ou HTTP/2 do balanceador de carga para os back-ends, será preciso instalar certificados SSL em cada instância de VM. Para instalar certificados SSL em uma instância de VM, use as instruções contidas na documentação do aplicativo. Esses certificados podem ser autoassinados.

Políticas de SSL

As políticas de SSL oferecem a capacidade de controlar os recursos de SSL que seu balanceador de carga HTTPS negocia com os clientes HTTPS.

Por padrão, o balanceamento de carga HTTPS usa um conjunto de recursos SSL que oferece boa segurança e ampla compatibilidade. Alguns aplicativos exigem mais controle sobre quais versões de SSL e criptografias são usadas nas próprias conexões HTTPS ou SSL. É possível definir políticas SSL que controlam os recursos de SSL que seu balanceador de carga negocia e associar uma política de SSL ao seu proxy HTTPS de destino.

Controle geográfico sobre o local em que o TLS é encerrado

O balanceador de carga HTTPS encerra o TLS em locais que são distribuídos globalmente, de modo a minimizar a latência entre os clientes e o balanceador de carga. Se você precisar de controle geográfico sobre o local em que o TLS é encerrado, use o Balanceamento de carga de rede do GCP e encerre o TLS nos back-ends localizados em regiões adequadas às suas necessidades.

Serviços de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. Um balanceador de carga HTTP(S) precisa ter pelo menos um serviço de back-end, mas pode ter vários.

Os balanceadores de carga usam as informações de um serviço de back-end para direcionar o tráfego de entrada para um ou mais back-ends anexados.

Cada back-end é composto de um grupo de instâncias e metadados com mais capacidade de exibição. A capacidade de exibição do back-end pode ser baseada em CPU ou solicitações por segundo (RPS, na sigla em inglês).

O balanceamento de carga HTTP(S) é compatível com o autoescalador do Cloud Load Balancing, com que os usuários podem fazer escalonamento automático nos grupos de instâncias de um serviço de back-end. Para mais informações, consulte Como fazer o escalonamento com base na capacidade de exibição do balanceamento de carga HTTP.

Ative a diminuição da conexão em serviços de back-end para garantir interrupção mínima aos usuários quando uma instância que está veiculando tráfego é encerrada, removida manualmente ou removida por um autoescalador. Para saber mais sobre diminuição de conexão, consulte a documentação Como ativar a diminuição de conexão.

Verificações de integridade

Cada serviço de back-end também especifica qual verificação de integridade é executada em cada instância disponível. Para que as sondagens de verificação de integridade funcionem corretamente, crie uma regra de firewall que permita que o tráfego de 130.211.0.0/22 e 35.191.0.0/16 alcance suas instâncias.

Para mais informações sobre verificações de integridade, consulte Conceitos de verificação de integridade e Como criar verificações de integridade.

Protocolo para os back-ends

Ao configurar um serviço de back-end para o balanceador de carga HTTP(S) externo, você define o protocolo que o serviço de back-end usará para se comunicar com os back-ends. As opções são HTTP, HTTPS ou HTTP/2. O balanceador de carga usará apenas o protocolo que você especificar. O balanceador de carga não recorrerá a um dos outros protocolos se não conseguir negociar uma conexão com o back-end usando o protocolo especificado.

Se você usar HTTP/2, use o TLS. O HTTP/2 sem criptografia não é compatível.

Embora não seja obrigatório, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao usado pelo serviço de back-end. Por exemplo, uma verificação de integridade HTTP/2 testa com mais precisão a conectividade HTTP/2 aos back-ends.

Como usar o gRPC com seus aplicativos do Google Cloud Platform

gRPC (em inglês) é um framework de código aberto de chamadas de procedimento remoto. Ele é baseado no padrão HTTP/2. Veja alguns casos de uso do gRPC:

  • sistemas distribuídos de baixa latência e altamente escalonáveis
  • desenvolvimento de clientes de dispositivos móveis que se comuniquem com um servidor em nuvem
  • criação de novos protocolos que ofereçam precisão, eficiência e não dependam de linguagem
  • design em camadas que permita extensão, autenticação e geração de registros

Para usar o gRPC com os aplicativos do Google Cloud Platform, é preciso representar solicitações de ponta a ponta por HTTP/2. No caso de um balanceador de carga HTTP(S), faça o seguinte:

  1. Configure um balanceador de carga HTTPS.
  2. Ative o HTTP/2 como protocolo do balanceador de carga para os back-ends.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS.

O balanceador de carga ainda pode negociar HTTPS com alguns clientes ou aceitar solicitações HTTP não seguras em um balanceador de carga HTTP(S) configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end. Essas solicitações HTTP ou HTTPS são transformadas pelo balanceador de carga para representar as solicitações por HTTP/2 para as instâncias de back-end.

Se você quiser configurar um balanceador de carga HTTP(S) usando HTTP/2 com o Google Kubernetes Engine Ingress, consulte HTTP/2 para balanceamento de carga com Ingress.

Também é possível usar gRPC e HTTP/2 com o Ingress. Para mais informações, consulte HTTP/2 para balanceamento de carga com Ingress.

Consulte Como resolver problemas com o HTTP/2 para os back-ends para saber mais sobre o assunto. Consulte Limitações do HTTP/2 para saber mais sobre elas.

Intervalos de back-end

Os intervalos de back-end direcionam o tráfego recebido para os intervalos do Google Cloud Storage. Para um exemplo de intervalo adicionado a um balanceador de carga, consulte Como adicionar intervalos do Cloud Storage aos balanceadores de carga .

Regras de firewall

É necessário criar uma regra de firewall que permita que o tráfego proveniente de 130.211.0.0/22 e 35.191.0.0/16 chegue às instâncias. Esses são os intervalos de endereços IP que o balanceador de carga usa para se conectar a instâncias de back-end. Essa regra permite tráfego do balanceador de carga e do verificador de integridade. A regra precisa permitir o tráfego na porta em que a regra de encaminhamento global foi configurada, e é necessário que seu verificador de integridade seja configurado para usar a mesma porta. Se o verificador de integridade usar uma porta diferente, será necessário criar outra regra de firewall para essa porta.

As regras de firewall bloqueiam e permitem o tráfego no nível da instância, não nos limites da rede. Elas não impedem que o tráfego chegue ao próprio balanceador de carga.

Se for necessário determinar endereços IP externos em determinado momento, use as instruções nas Perguntas frequentes do Google Compute Engine.

Caminho de retorno

O GCP usa rotas especiais não definidas em sua rede VPC para verificações de integridade. Para informações completas a respeito, consulte Caminhos de retorno do balanceador de carga.

Algoritmo de distribuição de carga

O balanceamento de carga HTTP(S) fornece dois métodos para determinar a carga da instância. Dentro do recurso do serviço de back-end, a propriedade balancingMode seleciona o modo de solicitações por segundo (RPS, na sigla em inglês) ou o modo de utilização da CPU. Ambos permitem a especificação de um valor máximo. O balanceador de carga HTTP(S) tenta garantir que a carga permaneça no limite, mas podem ocorrer bursts breves acima do limite durante eventos de failover ou pico de carga.

As solicitações de entrada são enviadas para a região mais próxima do usuário, se essa região tiver capacidade disponível. Se mais de uma zona for configurada com back-ends em uma região, o comportamento padrão do algoritmo será distribuir o tráfego entre os grupos de instâncias de cada zona de acordo com a capacidade de cada grupo. Dentro da zona, as solicitações são distribuídas de modo uniforme entre as instâncias por meio de um algoritmo round-robin. É possível modificar a distribuição round-robin configurando a afinidade da sessão. No entanto, observe que a afinidade da sessão funciona melhor se você também definir o modo de balanceamento como solicitações por segundo (RPS).

Consulte Como funciona o balanceamento de carga HTTP(S) para exemplos específicos do algoritmo de distribuição de carga.

Afinidade da sessão

A afinidade da sessão envia todas as solicitações do mesmo cliente para a mesma instância de máquina virtual, contanto que a instância permaneça íntegra e tenha capacidade.

O balanceamento de carga HTTP(S) do GCP tem dois tipos de afinidade da sessão:

Suporte ao proxy WebSocket

O balanceamento de carga HTTP(S) tem suporte nativo para o protocolo WebSocket. Os back-ends que usam WebSocket na comunicação com clientes podem usar o balanceador de carga HTTP(S) como front-end, para fins de escalonamento e disponibilidade. O balanceador de carga não precisa de outra configuração para representar conexões WebSocket.

O protocolo WebSocket, definido em RFC 6455 (em inglês), oferece um canal de comunicação full-duplex entre clientes e servidores. O canal é iniciado a partir de uma solicitação HTTP(S).

Quando o balanceamento de carga HTTP(S) reconhece uma solicitação WebSocket Upgrade de um cliente HTTP(S) e a solicitação é seguida por uma resposta bem-sucedida da instância de back-end, o balanceador de carga representa o tráfego bidirecional durante a conexão atual. Se o back-end não retornar uma resposta Upgrade bem-sucedida, o balanceador de carga fechará a conexão.

O tempo limite de uma conexão WebSocket depende do tempo limite de resposta configurável do balanceador de carga, que é 30 segundos, por padrão. Esse tempo limite é aplicado às conexões WebSocket, independentemente de estarem em uso ou não. Para mais informações sobre o tempo limite da resposta e como configurá-lo, consulte Tempos limite e tentativas.

Se você configurou o IP do cliente ou gerou uma afinidade da sessão por cookie para seu balanceador de carga HTTP(S), todas as conexões WebSocket de um cliente serão enviadas para a mesma instância de back-end, contanto que a instância continue a passar verificações de integridade e tenha capacidade.

O protocolo WebSocket é compatível com o Ingress.

Compatibilidade do balanceamento de carga HTTPS com o protocolo QUIC

O balanceamento de carga HTTPS é compatível com o protocolo QUIC (em inglês) nas conexões entre o balanceador de carga e os clientes. O QUIC é um protocolo de camada de transporte que oferece controle de congestionamento semelhante ao TCP e segurança equivalente a SSL/TLS para HTTP/2, com desempenho aprimorado. O QUIC permite uma inicialização mais rápida da conexão do cliente, elimina o bloqueio "head-of-line" em fluxos multiplexados e aceita a migração da conexão quando o endereço IP de um cliente é alterado.

O QUIC afeta as conexões entre os clientes e o balanceador de carga, não as conexões entre o balanceador de carga e os back-ends.

A configuração de modificação do QUIC do proxy de destino permite ativar uma das seguintes opções:

  • quando possível, negociar o QUIC para um balanceador de carga OU
  • sempre desativar o QUIC para um balanceador de carga.

Caso não especifique nenhuma modificação de QUIC, você permitirá que o Google gerencie quando o QUIC será usado. O Google não ativa o QUIC sem uma modificação especificada. Para informações sobre como ativar e desativar o suporte ao QUIC, consulte Proxies de destino. Também é possível ativar o QUIC ao criar um balanceador de carga HTTPS usando o Console do Google Cloud Platform ou desativá-lo usando o Console do Google Cloud Platform para editar a configuração do balanceador de carga.

Como o QUIC é negociado

Quando você ativa o QUIC, o balanceador de carga pode divulgar o próprio recurso QUIC para os clientes. Isso permite que os clientes que aceitam o QUIC tentem estabelecer conexões QUIC com o balanceador de carga HTTPS. Os clientes implementados corretamente sempre recorrem a HTTPS ou HTTP/2 quando não conseguem estabelecer uma conexão QUIC. Por causa disso, ativar ou desativar o QUIC no balanceador de carga não afeta a capacidade do balanceador de carga de se conectar com os clientes.

Quando o QUIC está ativado no seu balanceador de carga HTTPS, algumas circunstâncias podem fazer com que seu cliente recorra a HTTPS ou HTTP/2 em vez de negociar o QUIC. Por exemplo:

  • quando um cliente aceita versões do QUIC que não são compatíveis com as versões do QUIC aceitas pelo balanceador de carga HTTPS;
  • quando o balanceador de carga detecta que o tráfego UDP está bloqueado ou tem limitação de taxa, de modo a impedir o funcionamento do QUIC;
  • se o QUIC estiver temporariamente desativado para balanceadores de carga HTTPS em resposta a bugs, vulnerabilidades ou outras preocupações.

Quando uma conexão retorna para HTTPS ou HTTP/2 devido a essas circunstâncias, não consideramos isso uma falha do balanceador de carga.

Verifique se os comportamentos descritos acima são aceitáveis para suas cargas de trabalho antes de ativar o QUIC.

Interfaces

Seu serviço de balanceamento de carga HTTP(S) pode ser configurado e atualizado por meio das seguintes interfaces:

  • Ferramenta de linha de comando gcloud: incluída no SDK do Cloud. Na documentação do balanceamento de carga HTTP(S), essa ferramenta é frequentemente usada para a realização de tarefas. Para uma visão geral completa da ferramenta, consulte o Guia da ferramenta gcloud. Encontre comandos relacionados ao balanceamento de carga no grupo de comandos gcloud compute.

    Também é possível acessar a ajuda detalhada de qualquer comando gcloud usando a sinalização --help:

    gcloud compute http-health-checks create --help
    
  • Console do Google Cloud Platform: as tarefas de balanceamento de carga podem ser realizadas por meio do Console do Google Cloud Platform.

  • API REST: todas as tarefas de balanceamento de carga podem ser realizadas com a API Google Cloud Load Balancing. Os documentos de referência da API descrevem os recursos e métodos disponíveis para você.

Suporte a TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 ao encerrar solicitações SSL do cliente. É possível usar políticas de SSL para alterar esse comportamento padrão e controlar como o balanceador de carga negocia SSL com os clientes.

Quando o balanceador de carga usa HTTPS como um protocolo de serviço de back-end, ele pode negociar TLS 1.0, 1.1 ou 1.2 para o back-end.

Tempos limite e tentativas

O balanceamento de carga HTTP(S) tem dois tipos distintos de tempo limite:

  • Um tempo limite de resposta HTTP configurável, que representa o tempo que o balanceador de carga aguarda até que o back-end retorne uma resposta HTTP completa. Não é um tempo limite HTTP ocioso (sinal de atividade). O valor padrão é 30 segundos. Pense na possibilidade de aumentar esse tempo limite se:

    • você espera que um back-end demore mais para retornar respostas HTTP ou
    • ocorrer upgrade da conexão para um WebSocket.

    Para o tráfego WebSocket enviado por um balanceador de carga HTTP(S) do GCP, o tempo limite do serviço de back-end é interpretado como o tempo máximo em que uma conexão WebSocket pode permanecer aberta, seja ele ocioso ou não. Para mais informações, consulte Configurações do serviço de back-end.

  • O tempo limite de uma sessão TCP, que tem o valor fixado em 10 minutos (600 segundos). Esse período de sessão às vezes é chamado de tempo limite do sinal de atividade ou ocioso e o valor dele não é configurável pela modificação do serviço de back-end. É necessário configurar o software servidor da Web usado pelos seus back-ends para que o tempo limite do sinal de atividade seja maior que 600 segundos para impedir que as conexões sejam fechadas prematuramente pelo back-end. Esse tempo limite não se aplica a WebSockets.

Nesta tabela, veja as alterações necessárias para modificar os tempos limite de sinal de atividade para o software servidor da Web comum:

Software de servidor da Web Parâmetro Configuração padrão Configuração recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

O balanceamento de carga HTTP(S) repete solicitações GET com falha em determinadas circunstâncias, como quando o tempo limite de resposta está esgotado. Ele não repete solicitações POST com falha. As repetições são limitadas a duas tentativas. As solicitações repetidas geram apenas uma entrada de registro como resposta final. Consulte Como gerar registros para mais informações.

Tratamento de solicitações e respostas inválidas

O balanceador de carga HTTP(S) bloqueia a chegada de solicitações de cliente e respostas de back-end no back-end ou no cliente, respectivamente, por alguns motivos. Alguns deles referem-se estritamente à conformidade com HTTP/1.1 e outros servem para evitar a passagem de dados inesperados para ou de back-ends.

O balanceador de carga bloqueia os casos seguintes por questão de conformidade com HTTP/1.1:

  • Não é possível analisar a primeira linha da solicitação.
  • Falta o delimitador : em um cabeçalho.
  • Cabeçalhos ou a primeira linha contêm caracteres inválidos.
  • O comprimento do conteúdo não é um número válido ou há cabeçalhos com vários comprimentos de conteúdo.
  • Há várias chaves de codificação de transferência ou há valores de codificação de transferência não reconhecidos.
  • Há um corpo não fragmentado e sem comprimento de conteúdo especificado.
  • Não é possível analisar os fragmentos do corpo. Este é o único caso em que alguns dados chegarão ao back-end. O balanceador de carga fechará as conexões com o cliente e o back-end quando receber um fragmento não analisável.

O balanceador de carga bloqueará a solicitação se alguma das seguintes condições for verdadeira:

O balanceador de carga bloqueará a resposta do back-end se alguma das seguintes condições for verdadeira:

A seguir