Visão geral do balanceamento de carga de HTTP(S) externo

Neste documento, apresentamos os conceitos que você precisa entender para configurar o balanceamento de carga HTTP(S) externo do Google Cloud.

O balanceamento de carga HTTP(S) é um balanceador de carga global da camada 7 baseado em proxy que permite executar e escalonar seus serviços em todo o mundo atrás de um único endereço IP externo. O balanceamento de carga HTTP(S) externo distribui o tráfego HTTP e HTTPS aos back-ends hospedados em várias plataformas do Google Cloud, como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage e outras, assim como back-ends externos conectados pela Internet ou por conectividade híbrida. Veja detalhes em Casos de uso.

Nesta página, você verá a arquitetura de um balanceador de carga HTTP(S) externo independente. Se você quiser expor seus aplicativos no GKE à Internet, recomendamos que use a Entrada do GKE para balanceamento de carga HTTP(S) externo integrada.

Modos de balanceadores de carga HTTP(S) externos

É possível configurar o balanceamento de carga HTTP(S) externo nos seguintes modos:

  • Balanceador de carga HTTP/S externo. Esse é o balanceador de carga HTTP(S) externo regional no nível Standard e global no nível Premium. O balanceador de carga HTTP(S) externo é implementado no Google Front Ends (GFEs). Os GFEs são distribuídos globalmente e funcionam em conjunto usando a rede global e o plano de controle do Google.
  • Balanceador de carga HTTP(S) externo regional (Visualização). Esse é um balanceador de carga regional implementado como um serviço gerenciado no proxy Envoy de código aberto (em inglês). Ele inclui recursos avançados de gerenciamento de tráfego, como espelhamento de tráfego, divisão de tráfego baseada em peso, transformações de cabeçalho com base em solicitação/resposta e muito mais.
Modo balanceador de carga Casos de uso recomendados Recursos
Balanceador de carga HTTP(S) externo

Este é o balanceador de carga HTTP(S) externo regional no nível Standard e global no nível Premium.

No nível de serviço de rede Premium, o balanceador de carga HTTP(S) externo oferece balanceamento de carga multirregional, direcionando o tráfego para o back-end íntegro mais próximo que tiver capacidade e for encerrado Tráfego HTTP(S) o mais próximo possível dos seus usuários.

No nível de serviço de rede padrão, o balanceamento de carga é processado regionalmente.

Consulte a página de Recursos de balanceamento de carga para ver a lista completa de recursos.
Balanceador de carga HTTP(S) externo regional com recurso avançado de gerenciamento de tráfego (Visualizar)

Esse balanceador de carga contém muitos dos recursos do balanceador de carga HTTP(S) externo existente, além de outros recursos avançados de gerenciamento de tráfego.

Esse é o balanceador de carga HTTP(S) externo recomendado para exibir conteúdo de apenas uma geolocalização (por exemplo, para cumprir as regulamentações de conformidade).

Use esse balanceador de carga quando apenas serviços de back-end regionais forem necessários, ou o nível de serviço de rede padrão for desejado.

Para ver a lista completa, consulte Recursos de balanceamento de carga.

Arquitetura

Os recursos a seguir são necessários para implantar um balanceador de carga HTTP(S) externo:

  • Somente para balanceadores de carga HTTP(S) regionais externos, uma sub-rede somente proxy é usada para enviar conexões do balanceador de carga para os back-ends.

  • Uma regra de encaminhamento externo especifica um endereço IP externo, uma porta e um proxy HTTP(S) de destino global. Os clientes usam o endereço IP e a porta para se conectar ao balanceador de carga.

  • Um proxy HTTP(S) de destino regional recebe uma solicitação do cliente. O proxy HTTP(S) avalia a solicitação usando o mapa de URLs para tomar decisões de roteamento de tráfego. O proxy também pode autenticar comunicações usando certificados SSL.

    • No balanceamento de carga HTTPS, o proxy HTTPS de destino usa certificados SSL para provar a identidade aos clientes. Um proxy HTTPS de destino é compatível com um número documentado de certificados SSL.
  • O proxy HTTP(S) usa um mapa de URLs para fazer a determinação do roteamento com base em atributos HTTP, como caminho de solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha solicitações de cliente para serviços ou buckets de back-end específicos. O mapa de URLs pode especificar ações adicionais, como o envio de redirecionamentos para clientes.

  • Um serviço de back-end distribui as solicitações para back-ends íntegros. O balanceador de carga HTTP(S) externo também é compatível com buckets de back-end.

    • Um ou mais back-ends precisam estar conectados ao serviço ou bucket de back-end.
  • Uma verificação de integridade monitora periodicamente a prontidão de seus back-ends. Isso reduz o risco de que solicitações sejam enviadas para back-ends que não podem atender à solicitação.

  • Regras de firewall para que os back-ends aceitem sondagens de verificação de integridade. Os balanceadores de carga HTTP(S) regionais exigem uma regra de firewall extra para permitir que o tráfego da sub-rede somente proxy atinja os back-ends.

Modo global

Este diagrama mostra os componentes de uma implantação de balanceador de carga HTTP(S) externo.

Componentes do balanceador de carga HTTP(S) externo
Componentes do balanceador de carga HTTP(S) externo

Modo regional

Este diagrama mostra os componentes de uma implantação de balanceador de carga HTTP(S) externo regional.

Componentes do balanceador de carga HTTP(S) externo regional
Componentes do balanceador de carga HTTP(S) externo regional

Sub-rede somente proxy

As sub-redes apenas de proxy são necessárias apenas para balanceadores de carga HTTP(S) externos regionais.

A sub-rede somente proxy fornece um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. É necessário criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga HTTP(S) internos. A sinalização --purpose dessa sub-rede apenas de proxy é definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga HTTP(S) externos regionais na mesma região e rede VPC compartilham um pool de proxies Envoy da mesma sub-rede somente proxy. Além disso:

  • As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
  • As VMs de back-end ou os endpoints de todos os balanceadores de carga HTTP(S) internos em uma região e uma rede VPC recebem conexões da sub-rede somente proxy.
  • O endereço IP do balanceador de carga HTTP(S) regional não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciada interna, descrita abaixo.

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 no DNS. É possível especificar o endereço IP a ser usado ou permitir que o 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.

O tipo de regra de encaminhamento, o endereço IP e o esquema de balanceamento de carga usado por balanceadores de carga HTTP(S) externos depende do modo do balanceador de carga e de qual nível de serviço de rede o balanceador está.

Modo balanceador de carga Nível de serviço de rede Regra de encaminhamento, endereço IP e esquema de balanceamento de carga Como rotear da Internet para o front-end do balanceador de carga
Balanceador de carga HTTP(S) externo Nível Premium

Regra de encaminhamento externo global

Endereço IP externo global

Esquema de balanceamento de carga:
EXTERNAL

Solicitações encaminhadas para o GFE mais próximo do cliente na Internet.
Nível Standard

Regra de encaminhamento externo regional

Endereço IP externo regional

Esquema de balanceamento de carga:
EXTERNAL

Solicitações encaminhadas para um GFE na região do balanceador de carga.
Balanceador de carga HTTP(S) externo regional Nível Standard

Regra de encaminhamento externo regional

Endereço IP externo regional

Esquema de balanceamento de carga:
EXTERNAL_MANAGED

Solicitações encaminhadas para os proxies do Envoy na mesma região que o balanceador de carga.

Veja a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceamento de carga HTTP(S) em cada modo em Recursos do balanceador de carga.

Proxies de destino

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

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.

A tabela a seguir especifica o tipo de proxy de destino exigido pelos balanceadores de carga HTTP(S) externos em cada modo.

Modo balanceador de carga Tipos de proxy de destino Cabeçalhos adicionados pelo proxy Cabeçalhos personalizados compatíveis Cloud Trace compatível
Balanceador de carga HTTP(S) externo HTTP global,
HTTPS global
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-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (somente solicitações)
    Contém parâmetros para o Cloud Trace.
  • X-Forwarded-For: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações)
Configurado no serviço ou bucket de back-end
Balanceador de carga HTTP(S) externo regional HTTP regional,
HTTPS regional
  • X-Forwarded-Proto: [http] https] (apenas solicitações)
  • Via: 1.1 google (solicitações e respostas)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações)

Cabeçalho Host

Quando o balanceador de carga faz a solicitação HTTP, o balanceador de carga preserva o cabeçalho Host da solicitação original.

Cabeçalho X-Forwarded-For

O balanceador de carga anexa dois endereços IP separados por uma única vírgula ao cabeçalho X-Forwarded-For, na seguinte ordem:

  • O endereço IP do cliente que se conecta ao balanceador de carga
  • O endereço IP da regra de encaminhamento do balanceador de carga

Se não houver nenhum cabeçalho X-Forwarded-For na solicitação recebida, esses dois endereços IP serão o valor inteiro do cabeçalho:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Se a solicitação incluir um cabeçalho X-Forwarded-For, o balanceador de carga preservará o valor fornecido antes de <client-ip>,<load-balancer-ip>:

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

Ao executar o software de proxy HTTP reverso nos back-ends do balanceador de carga, ele pode anexar um ou os dois endereços IP a seguir no final do cabeçalho X-Forwarded-For:

  • O endereço IP do Google Front End (GFE) que se conectou ao back-end. Esses endereços IP estão nos intervalos 130.211.0.0/22 e 35.191.0.0/16.

  • O endereço IP do próprio sistema de back-end.

Assim, um processo upstream após o back-end do balanceador de carga pode receber um cabeçalho X-Forwarded-For com este formato:

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

Suporte a protocolo HTTP/3 e QUIC

O HTTP/3 é um protocolo de Internet de última geração. Ele é baseado no QUIC, um protocolo desenvolvido a partir do protocolo Google QUIC (gQUIC) original. O HTTP/3 é compatível entre o balanceador de carga HTTP(S) externo, o Cloud CDN e os clientes.

Especificamente:

  • O QUIC do IETF é 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.
  • HTTP/3 é uma camada de aplicativo criada com base no QUIC do IETF e depende do QUIC para lidar com multiplexação, controle de congestionamento e novas tentativas.
  • O HTTP/3 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 HTTP/3 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.
  • As conexões HTTP/3 usam o protocolo de controle de congestionamento BBR.

Ativar o HTTP/3 no balanceador de carga HTTP(S) externo pode melhorar o tempo de carregamento da página da Web, reduzir o armazenamento em buffer de vídeo e melhorar a capacidade em conexões de maior latência.

Como configurar o HTTP/3

Ative explicitamente a compatibilidade com HTTP/3 para o balanceador de carga HTTP(S) externo definindo quicOverride como ENABLE. No futuro, o HTTP/3 será ativado por padrão para todos os clientes de balanceadores de carga HTTP(S) externos.

Clientes que não são compatíveis com HTTP/3 ou gQUIC não negociam uma conexão HTTP/3. Não é necessário desativar HTTP/3 explicitamente, a menos que tenha identificado implementações de cliente corrompidas ou mais antigas.

O balanceador de carga HTTP(S) externo fornece três modos de configuração de HTTP/3, conforme mostrado na tabela a seguir.

Valor quicOverride Comportamento
NONE

O HTTP/3 e o Google QUIC não são divulgados aos clientes.

Observação: isso pode mudar no futuro, e o HTTP/3 será anunciado aos clientes por padrão.

ENABLE

O suporte para HTTP/3 e Google QUIC é anunciado aos clientes. O HTTP/3 é anunciado com uma prioridade mais alta. Os clientes que aceitam ambos os protocolos precisam preferir o HTTP/3 ao Google QUIC.

Observação: TLS 0-RTT (também conhecido como TLS Early Data) é implicitamente compatível quando o Google QUIC é negociado pelo cliente, mas não é compatível no momento com HTTP/3. usado.

DISABLE Desativa explicitamente a divulgação de HTTP/3 e do Google QUIC para clientes.

Para ativar (ou desativar) o HTTP/3 explicitamente, siga estas etapas.

Console: HTTPS

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Selecione o balanceador de carga HTTP(S) externo que você quer editar.

  3. Clique em Configuração de front-end.

  4. Selecione o endereço IP do front-end e a porta que você quer editar. Para editar configurações HTTP/3, o endereço IP e a porta precisam ser HTTPS (porta 443).

Ativar HTTP/3

  1. Selecione a lista suspensa negociação QUIC.
  2. Para ativar explicitamente o HTTP/3 para esse front-end, selecione Ativado.
  3. Se você tiver várias regras de front-end representando IPv4 e IPv6, certifique-se de ativar o HTTP/3 em cada regra.

Desativar HTTP/3

  1. Selecione a lista suspensa negociação QUIC.
  2. Para desativar explicitamente o HTTP/3 para este front-end, selecione Desativado.
  3. Se você tiver várias regras de front-end representando IPv4 e IPv6, desative o HTTP/3 para cada regra.

gcloud: HTTPS

Antes de executar este comando, é necessário criar um recurso de certificado SSL para cada certificado.

 gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
     --global \
     --quic-override=QUIC_SETTING

Substitua QUIC_SETTING por um dos seguintes:

  • NONEAutomático (padrão): permite que o Google controle quando o QUIC é negociado.

    O QUIC é desativado quando você seleciona NONEAutomático. Ao selecionar essa opção, você permite que o Google ative automaticamente as negociações do QUIC e o HTTP/3 no futuro para este balanceador de carga. No Console do Cloud, essa opção é chamada de Automático (padrão).

  • ENABLE: anuncia HTTP/3 e Google QUIC para os clientes

  • DISABLE: não anuncia HTTP/3 ou Google QUIC para clientes

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Substitua QUIC_SETTING por um dos seguintes:

  • NONEAutomático (padrão): permite que o Google controle quando o QUIC é negociado.

    O QUIC é desativado quando você seleciona NONEAutomático. Ao selecionar essa opção, você permite que o Google ative automaticamente as negociações do QUIC e o HTTP/3 no futuro para este balanceador de carga. No Console do Cloud, essa opção é chamada de Automático (padrão).

  • ENABLE: anuncia HTTP/3 e Google QUIC para os clientes

  • DISABLE: não divulga HTTP/3 ou Google QUIC para os clientes

Como o HTTP/3 é negociado

Quando o HTTP/3 está ativado, o balanceador de carga anuncia essa compatibilidade para os clientes, permitindo que clientes que aceitam HTTP/3 tentem estabelecer conexões HTTP/3 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.
  • Os clientes que aceitam HTTP/3 usam o conhecimento prévio em cache dessa compatibilidade para salvar viagens de ida e volta desnecessárias no futuro.
  • 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.

O suporte é anunciado no cabeçalho de resposta HTTP Alt-Svc. Quando o HTTP/3 é configurado como ENABLE em um recurso targetHttpsProxy do balanceador de carga HTTP(S) externo, as respostas do balanceador de carga HTTP(S) externo incluem o seguinte cabeçalho alt-svc: valor:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

Se o HTTP/3 tiver sido definido explicitamente como DISABLE, as respostas não incluirão um cabeçalho de resposta alt-svc.

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: Isso inclui o seguinte:

  • quando um cliente aceita versões do HTTP/3 que não são compatíveis com as versões do HTTP/3 compatíveis com o 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 que impediria o funcionamento do HTTP/3 (QUIC);
  • O cliente não é compatível com HTTP/3 e, portanto, não tenta negociar uma conexão HTTP/3.

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.

Antes de ativar o HTTP/3, verifique se os comportamentos descritos acima são aceitáveis para suas cargas de trabalho.

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 do 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 solicitações, o mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends.

A tabela a seguir especifica o tipo de mapa de URL exigido pelos balanceadores de carga HTTP(S) externos em cada modo.

Modo balanceador de carga Tipo de mapa de URL
Balanceador de carga HTTP(S) externo Global (com apenas um subconjunto de recursos compatíveis)
Balanceador de carga HTTP(S) externo regional Regional

Certificados SSL

O Transport Layer Security (TLS) é um protocolo de criptografia usado em certificados SSL para proteger as comunicações de rede.

O Google Cloud usa certificados SSL para fornecer privacidade e segurança de um cliente para um balanceador de carga. Se você estiver usando o balanceamento de carga baseado em HTTPS, precisará instalar um ou mais certificados SSL no proxy HTTPS de destino.

Na tabela a seguir, é especificado o escopo do certificado SSL exigido pelos balanceadores de carga HTTP(S) externos em cada modo:

Modo balanceador de carga Escopo do certificado SSL
Balanceador de carga HTTP(S) externo Global
Balanceador de carga HTTP(S) externo regional Regional

Para mais informações sobre certificados SSL, consulte:

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. Você pode 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.

Bucket e serviços de back-end

Um balanceador de carga HTTP(S) externo pode ter serviços e buckets de back-end. O balanceador de carga HTTP(S) regional não é compatível com buckets de back-end.

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. 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. Para um exemplo que mostra como configurar um balanceador de carga com um serviço de back-end e um back-end do Compute Engine, consulte Como configurar um balanceador de carga HTTP(S) externo com um back-end do Compute Engine.

Os buckets de back-end direcionam o tráfego recebido para os buckets do Cloud Storage. Veja um exemplo de como adicionar um bucket a um balanceador de carga HTTP(S) externo em Como configurar um balanceador de carga com buckets de back-end.

Se quiser configurar um balanceador de carga HTTP(S) externo usando o HTTP/2 com a Entrada do Google Kubernetes Engine ou usando o gRPC e o HTTP/2 com a Entrada, consulte HTTP/2 para balanceamento de carga com Entrada.

A tabela a seguir especifica os recursos de back-end compatíveis com o balanceamento de carga HTTP(S).


Modo balanceador de carga
Back-ends compatíveis em um serviço de back-end Compatível com intervalos de back-end Compatível com o Google Cloud Armor Compatível com Cloud CDN. Compatível com o IAP
Grupos de instâncias NEGs por zona NEGs na Internet NEGs sem servidor NEGs híbridos
Balanceador de carga HTTP(S) externo
ao usar o nível Premium

Balanceador de carga HTTP(S) externo regional

Para ver mais informações, consulte os seguintes tópicos:

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.

Para ver a lista completa de protocolos compatíveis, consulte Recursos de balanceamento de carga: protocolos do balanceador de carga para os back-ends.

Suporte a WebSocket

Os balanceadores de carga baseados em HTTP(S) do Google Cloud têm suporte nativo para o protocolo WebSocket ao usar HTTP ou HTTPS como protocolo para o back-end. O balanceador de carga não precisa de configuração para representar conexões WebSocket.

O protocolo WebSocket fornece um canal de comunicação full-duplex entre clientes e servidores. Uma solicitação HTTP(S) inicia o canal. Para informações detalhadas sobre o protocolo, consulte RFC 6455.

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

O tempo limite de uma conexão WebSocket depende do tempo limite configurável do serviço de back-end do balanceador de carga, que é 30 segundos, por padrão. Esse tempo limite se aplica a conexões WebSocket, estando em uso ou não.

A afinidade de sessão para WebSockets funciona da mesma forma que qualquer outra solicitação. Para mais informações, consulte Afinidade da sessão.

Como usar o gRPC com seus aplicativos do Google Cloud

O gRPC é uma biblioteca de código aberto para chamadas de procedimento remoto. Ele é baseado no padrão HTTP/2. Veja alguns casos de uso para o 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 seus aplicativos do Google Cloud, é necessário enviar solicitações de proxy completas pelo HTTP/2. Para fazer isso com um balanceador de carga HTTP(S) externo:

  1. Configure um balanceador de carga HTTPS.
  2. Ative o HTTP/2 como o 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) externo 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.

Ative o TLS nos back-ends. Saiba mais em Criptografia do balanceador de carga nos back-ends.

Se quiser configurar um balanceador de carga HTTP(S) externo usando o HTTP/2 com a Entrada do Google Kubernetes Engine ou usando o gRPC e o HTTP/2 com a Entrada, consulte HTTP/2 para balanceamento de carga com Entrada.

Saiba mais sobre a solução de problemas com o HTTP/2 em Como resolver problemas com o HTTP/2 para os back-ends.

Saiba mais sobre as limitações do HTTP/2 em Limitações do HTTP/2.

Verificações de integridade

Cada serviço de back-end especifica uma verificação de integridade para instâncias de back-end.

Para as sondagens de verificação de integridade, crie uma regra de permissão de entrada de firewall que permita que o tráfego alcance suas instâncias de back-end. A regra de firewall precisa permitir os seguintes intervalos de origem:

  • 130.211.0.0/22
  • 35.191.0.0/16

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. Para ver a lista de protocolos de verificação de integridade compatíveis, consulte Recursos de balanceamento de carga.

Na tabela a seguir, é especificado o escopo da verificação de integridade compatível com balanceadores de carga HTTP(S) externos em cada modo.

Modo balanceador de carga Tipo de verificação de integridade
Balanceador de carga HTTP(S) externo Global
Balanceador de carga HTTP(S) externo regional Regional

Para saber mais sobre verificações de integridade, consulte:

Regras de firewall

Um balanceador de carga HTTP(S) interno requer as seguintes regras de firewall:

  • Para o balanceador de carga HTTP(S) externo, uma regra de permissão de entrada para permitir que o tráfego dos Google Front Ends (GFEs) alcance seus back-ends.
    Para o balanceador de carga HTTP(S) externo regional, uma regra de permissão de entrada para permitir o tráfego da sub-rede somente proxy.
  • Uma regra de permissão de entrada para permitir o tráfego dos intervalos de verificação de integridade Saiba mais sobre sondagens de verificação de integridade e por que é necessário permitir tráfego delas em Intervalos de IP de sondagem e regras de firewall.

As portas dessas regras de firewall precisam ser configuradas da seguinte maneira:

  • Permite o tráfego para a porta de destino da verificação de integridade de cada serviço de back-end.

  • Para back-ends de grupos de instâncias: determine as portas a serem configuradas pelo mapeamento entre a porta nomeada do serviço de back-end e os números de porta associados a essa porta nomeada em cada grupo de instâncias. Os números podem variar entre os grupos de instâncias atribuídos ao mesmo serviço de back-end.

  • Para back-ends NEG de GCE_VM_IP_PORT: permite tráfego para os números de portas dos endpoints.

As regras de firewall são implementadas no nível da instância de VM, não nos proxies do GFE. Não é possível usar regras de firewall do Google Cloud para impedir que o tráfego chegue ao balanceador de carga. Para o balanceador de carga HTTP(S) externo, é possível usar o Google Cloud Armor para fazer isso.

Para balanceadores de carga HTTP(S) externos, a tabela a seguir resume os intervalos de endereços IP necessários para as regras de firewall:

Modo balanceador de carga Intervalos de origem da verificação de integridade Solicitar intervalos de origem
Balanceador de carga HTTP(S) externo
  • 130.211.0.0/22
  • 35.191.0.0/16
A origem do tráfego do GFE depende do tipo de back-end:
  • Grupos de instâncias, NEGs por zona (GCE_VM_IP_PORT) e NEGs de conectividade híbrida (NON_GCP_PRIVATE_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16
  • NEGs da Internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT):
    • 34.96.0.0/20
    • 34.127.192.0/18
  • SERVERLESS NEGs e buckets de back-end: a rede de produção do Google processa o roteamento de pacotes.
Balanceador de carga HTTP(S) externo regional
  • 130.211.0.0/22
  • 35.191.0.0/16
A sub-rede somente proxy que você configura.

Como as conexões funcionam no balanceamento de carga de HTTP(S)

Conexões do balanceador de carga HTTP(S) externo

O balanceador de carga HTTP(S) externo é um serviço implementado por muitos proxies chamados Google Front Ends (GFEs). Não existe apenas um proxy. No nível Premium, o mesmo endereço IP externo global é anunciado a partir de vários pontos de presença, e as solicitações do cliente são direcionadas para o GFE mais próximo do cliente.

Dependendo de onde seus clientes estão, vários GFEs podem iniciar conexões HTTP(S) com os back-ends. Os pacotes enviados de GFEs têm endereços IP de origem do mesmo intervalo usado pelas sondagens de verificação de integridade: 35.191.0.0/16 e 130.211.0.0/22.

Dependendo da configuração do serviço de back-end, o protocolo usado por cada GFE para se conectar aos back-ends pode ser HTTP, HTTPS ou HTTP/2. Para conexões HTTP ou HTTPS, a versão HTTP usada é HTTP 1.1.

O sinal de atividade HTTP está ativado por padrão, conforme a especificação HTTP 1.1. Os sinais de atividade HTTP tentam usar de forma eficiente a mesma sessão TCP. No entanto, não há garantias. O GFE usa um tempo limite de sinal de atividade de 600 segundos e não é possível configurá-lo. No entanto, é possível configurar o tempo limite da solicitação/resposta definindo o tempo limite do serviço de back-end. Embora esteja estreitamente relacionado, um sinal de atividade HTTP e um sinal de inatividade TCP não são a mesma coisa. Saiba mais em Tempos limite e novas tentativas.

Os números de conexões HTTP e sessões TCP variam de acordo com o número de GFEs conectados, o número de clientes que se conectam aos GFEs, o protocolo aos back-ends e onde os back-ends são implantados.

Saiba mais em Como funciona o balanceamento de carga HTTP(S) no guia de soluções: Otimizações de capacidade de aplicativos com balanceamento de carga global.

Conexões do balanceador de carga HTTP(S) externo regional

O balanceador de carga HTTP(S) regional é um serviço gerenciado implementado no proxy Envoy. O balanceador de carga HTTP(S) externo regional usa uma sub-rede compartilhada chamada sub-rede apenas de proxy para provisionar um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. A sinalização --purpose dessa sub-rede somente proxy está definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga HTTP(S) externos regionais em uma determinada rede e região compartilham essa sub-rede.

Os clientes usam o endereço IP e a porta do balanceador de carga para se conectar ao balanceador de carga. As solicitações do cliente são direcionadas para a sub-rede somente proxy na mesma região do cliente. O balanceador de carga encerra solicitações de clientes e depois abre novas conexões da sub-rede somente proxy para os back-ends. Portanto, os pacotes enviados do balanceador de carga têm endereços IP de origem da sub-rede somente proxy.

Dependendo da configuração do serviço de back-end, o protocolo usado por cada Envoy para se conectar aos back-ends pode ser HTTP, HTTPS ou HTTP/2. Se HTTP ou HTTPS, a versão HTTP é HTTP 1.1. O sinal de atividade HTTP está ativado por padrão, conforme a especificação HTTP 1.1. O proxy do Envoy usa um tempo limite de sinal de atividade de 600 segundos e não é possível configurá-lo. No entanto, é possível configurar o tempo limite da solicitação/resposta definindo o tempo limite do serviço de back-end. Saiba mais em Tempos limite e novas tentativas.

Comunicações do cliente com o balanceador de carga

  • Os clientes podem se comunicar com o balanceador de carga por meio do 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 no 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.
  • O balanceamento de carga HTTP(S) é compatível com a resposta HTTP/1.1 100 Continue.

Veja a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceamento de carga HTTP(S) em cada modo em Recursos do balanceador de carga.

Endereços IP de origem para pacotes de clientes

O endereço IP de origem dos pacotes, como visto pelos back-ends, não é o endereço IP externo do Google Cloud do balanceador de carga. Em outras palavras, há duas conexões TCP:

Para o balanceador de carga HTTP(S) externo:
  • Conexão 1, do cliente original para o balanceador de carga (GFE):

    • Endereço IP de origem: o cliente original (ou endereço IP externo se o cliente estiver atrás de NAT ou de um proxy de encaminhamento).
    • Endereço IP de destino: o endereço IP do seu balanceador de carga.
  • Conexão 2, do balanceador de carga (GFE) para o endpoint ou VM de back-end:

    • Endereço IP de origem: um endereço IP em um dos intervalos especificados nas regras de firewall.

    • Endereço IP de destino: o endereço IP interno da VM ou contêiner de back-end na rede VPC.

Para o balanceador de carga HTTP(S) regional regional:

  • Conexão 1, do cliente original para o balanceador de carga (sub-rede somente proxy):

    • Endereço IP de origem: o cliente original (ou endereço IP externo se o cliente estiver atrás de NAT ou de um proxy de encaminhamento).
    • Endereço IP de destino: o endereço IP do seu balanceador de carga.
  • Conexão 2, do balanceador de carga (sub-rede somente proxy) para o endpoint ou a VM de back-end:

    • Endereço IP de origem: um endereço IP na sub-rede somente proxy compartilhado entre todos os balanceadores de carga baseados em Envoy implantados na mesma região e rede como o balanceador de carga.

    • Endereço IP de destino: o endereço IP interno da VM ou contêiner de back-end na rede VPC.

Caminho de retorno

Para balanceadores de carga HTTP(S) externos, o Google Cloud usa rotas especiais não definidas em sua rede VPC para verificações de integridade. Saiba mais em Caminhos de retorno do balanceador de carga.

Para balanceadores de carga HTTP(S) externos regionais, o Google Cloud usa proxies Envoy de código aberto para encerrar solicitações de clientes ao balanceador de carga. O balanceador de carga encerra a sessão TCP e abre uma nova sessão da sub-rede somente proxy da região para o back-end. As rotas definidas na sua rede VPC facilitam a comunicação dos proxies Envoy para seus back-ends e vice-versa.

Portas abertas

Esta seção se aplica somente ao balanceador de carga HTTP(S) externo, que é implementado usando GFEs.

Os GFEs têm várias portas abertas para oferecer suporte a outros serviços do Google, executados na mesma arquitetura. Para ver uma lista de algumas das portas que provavelmente estarão abertas nos GFEs, consulte Regra de encaminhamento: especificações de porta. Pode haver outras portas abertas para outros serviços do Google em execução nos GFEs.

Executar uma verificação de porta no endereço IP de um balanceador de carga baseado no GFE não é útil do ponto de vista de auditoria pelos seguintes motivos:

  • Uma verificação de porta (por exemplo, com nmap) geralmente não espera nenhum pacote de resposta ou um pacote TCP RST ao realizar a sondagem de TCP SYN. Os GFEs enviarão pacotes SYN-ACK em resposta a sondagens SYN para várias portas se o balanceador de carga usar um endereço IP de nível Premium. No entanto, os GFEs só enviam pacotes para os back-ends em resposta aos enviados para o endereço IP do balanceador de carga e para a porta de destino configurada na regra de encaminhamento. Pacotes enviados para diferentes endereços IP do balanceador de carga ou o endereço IP do balanceador de carga em uma porta não configurada na regra de encaminhamento não resultam no envio de pacotes para os back-ends do balanceador de carga Os GFEs implementam recursos de segurança, como o Google Cloud Armor. Mesmo sem uma configuração do Google Cloud Armor, a infraestrutura do Google e os GFEs fornecem defesa detalhada para ataques DDoS e inundações SYN.

  • Os pacotes enviados para o endereço IP do balanceador de carga poderiam ser respondidos por qualquer GFE na frota do Google; No entanto, a verificação de uma combinação de endereço IP e porta de balanceador de carga interroga apenas um único GFE por conexão TCP. O endereço IP do seu balanceador de carga não é atribuído a um único dispositivo ou sistema. Portanto, a verificação do endereço IP de um balanceador de carga baseado em GFE não verifica todos os GFEs na frota do Google.

Com isso em mente, veja a seguir algumas maneiras mais eficazes de auditar a segurança das instâncias de back-end:

  • Um auditor de segurança precisa inspecionar a configuração das regras de encaminhamento para a configuração do balanceador de carga. As regras de encaminhamento definem a porta de destino para a qual o balanceador de carga aceita pacotes e os encaminha para os back-ends. Para balanceadores de carga baseados em GFE, cada regra de encaminhamento externo só pode referenciar uma única porta TCP de destino. Para um balanceador de carga HTTP(S) externo que usa a porta TCP 443, a porta UDP 443 é usada durante o upgrade da conexão para o QUIC (HTTP/3).

  • Um auditor de segurança deve inspecionar a configuração da regra de firewall aplicável às VMs de back-end. As regras de firewall que você define bloqueiam o tráfego dos GFEs para as instâncias de back-end, mas não bloqueiam o tráfego de entrada para os GFEs. Para ver as práticas recomendadas, consulte a seção de regras de firewall.

término de TLS

Veja na tabela a seguir um resumo de como a terminação TLS é processada pelos balanceadores de carga HTTP(S) externos em cada modo.

Modo balanceador de carga término de TLS
Balanceador de carga HTTP(S) externo O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo.
Balanceador de carga HTTP(S) externo regional O TLS é encerrado nos proxies do Envoy localizados em uma sub-rede apenas de proxy em uma região escolhida pelo usuário. Use esse modo de balanceador de carga se você precisar de controle geográfico sobre a região em que o TLS é encerrado.

Tempo limite e tentativas

O balanceamento de carga HTTP(S) tem dois tipos distintos de tempo limite:
  • Um tempo limite de serviço de back-end HTTP configurável, que representa o tempo que o balanceador de carga aguarda até que o back-end retorne uma resposta HTTP completa. O valor padrão do tempo limite do serviço de back-end é de 30 segundos. O intervalo completo permitido para valores de tempo limite é de 1 a 2.147.483.647 segundos.

    Para o tráfego HTTP, esse tempo limite é a duração máxima da solicitação e da resposta HTTP.

    Para o tráfego WebSocket, esse tempo limite é o tempo máximo que uma conexão WebSocket pode permanecer aberta, esteja ela inativa ou ativa.

    Considere aumentar esse tempo limite em qualquer uma destas circunstâncias:

    • Você espera que um back-end demore mais para retornar respostas HTTP.
    • Você verá uma resposta HTTP 408 com jsonPayload.statusDetail client_timed_out.
    • A conexão recebeu um upgrade para um WebSocket.

    Por exemplo, um valor de tempo limite prático para balanceadores de carga HTTP(S) externos é de 1 dia (86.400 segundos). Observe que eventos como reinicializações do GFE podem fazer com que as sessões sejam encerradas antes desse tempo limite.

    O tempo limite do serviço de back-end não é um tempo limite HTTP inativo (sinal de atividade). É possível que a entrada e saída (E/S) do back-end sejam bloqueadas devido a um cliente lento (um navegador com uma conexão ruim, por exemplo). Esse tempo de espera não é contabilizado no tempo limite do serviço de back-end.

    Para balanceadores de carga HTTP(S) externos regionais, o parâmetro routeActions.timeout do mapa de URLs pode modificar o tempo limite do serviço de back-end. O tempo limite do serviço de back-end é usado como o valor padrão para routeActions.timeout.

  • Um tempo limite de sinal de atividade HTTP, que tem o valor fixado em 10 minutos (600 segundos). Não é possível configurar esse valor modificando o 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.

    Esta tabela ilustra as mudanças necessárias para modificar os tempos limite de keepalive para o software comum do servidor da Web:

    Software 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;
A compatibilidade do balanceamento de carga HTTP(S) com lógica de repetição depende do modo do balanceador de carga HTTP(S) externo.

Modo balanceador de carga Repetir lógica
Balanceador de carga HTTP(S) externo

Não é possível alterar a política de repetição.

As solicitações HTTP POST não serão repetidas.

As solicitações HTTP GET são sempre repetidas uma vez, desde que 80% ou mais dos back-ends estejam íntegros. Se houver uma única instância de back-end em um grupo e a conexão com essa instância falhar, a porcentagem de instâncias de back-end não íntegras será 100%. Por isso, o GFE não tentará repetir a solicitação.

O balanceador de carga repete solicitações GET com falha em determinadas circunstâncias, como quando o tempo limite do serviço de back-end é esgotado. As repetições são limitadas a duas tentativas. As solicitações repetidas geram apenas uma entrada de registro como resposta final. Para mais informações, consulte Geração de registros e monitoramento de balanceamento de carga HTTP(S).

Solicitações malsucedidas resultam em um balanceador de carga sintetizando uma resposta HTTP 502.

Balanceador de carga HTTP(S) externo regional

Configurável usando uma política de repetição no mapa de URL.

Sem uma política de repetição, as solicitações sem corpo HTTP (por exemplo, solicitações GET) são repetidas uma vez.

O protocolo WebSocket é compatível com a Entrada.

Tratamento de solicitações e respostas inválidas

O balanceador de carga HTTP(S) externo impede que as solicitações do cliente e as respostas do back-end cheguem ao back-end ou ao cliente, respectivamente, por diversos 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. Nenhuma das verificações pode ser desativada.

O balanceador de carga bloqueia os casos seguintes por compliance 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 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. Esse é o único caso em que alguns dados chegam ao back-end. O balanceador de carga fecha as conexões com o cliente e o back-end quando recebe um bloco não analisável.

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

  • O tamanho total dos cabeçalhos de solicitação e o URL de solicitação excedem o limite de tamanho máximo de cabeçalhos de solicitação para balanceamento de carga HTTP(S) externo.
  • O método de solicitação não permite corpo, mas a solicitação tem um.
  • A solicitação contém um cabeçalho Upgrade, mas Upgrade não é usado para permitir conexões WebSocket.
  • A versão do HTTP é desconhecida.

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

  • O tamanho total dos cabeçalhos de resposta excede o limite de tamanho máximo de cabeçalhos de resposta para balanceamento de carga HTTP(S) externo.
  • A versão do HTTP é desconhecida.

Distribuição de tráfego

Ao adicionar um grupo de instâncias de back-end ou NEG a um serviço de back-end, você especifica um modo de balanceamento, que define um método de medição da carga de back-end e uma capacidade de destino. O balanceamento de carga HTTP(S) externo é compatível com dois modos de balanceamento:

  • RATE, para grupos de instâncias ou NEGs, é o número máximo de solicitações (consultas) por segundo (RPS, QPS). O RPS/QPS máximo do destino pode ser excedido se todos os back-ends atingirem ou ultrapassarem a capacidade.

  • UTILIZATION é o uso de back-ends de VMs em um grupo de instâncias.

A distribuição do tráfego entre back-ends depende do modo do balanceador de carga HTTP(S) externo.

Distribuição de tráfego do balanceador de carga HTTP(S) externo

Antes de um Google Front End (GFE) enviar solicitações a instâncias de back-end, o GFE avalia quais delas têm capacidade para receber solicitações. Essa estimativa de capacidade é feita proativamente, e não ao mesmo tempo que as solicitações chegam. Os GFEs recebem informações periódicas sobre a capacidade disponível e distribuem as solicitações recebidas de acordo.

O significado de capacidade depende, em parte, do modo de balanceamento. Quanto ao modo RATE, é relativamente simples: um GFE determina exatamente quantas solicitações ele pode atribuir por segundo. O balanceamento de carga baseado em UTILIZATION é mais complexo: o balanceador de carga verifica o uso atual das instâncias e, em seguida, calcula uma carga de consulta que cada instância pode processar. Essa estimativa muda ao longo do tempo à medida que o uso da instância e os padrões de tráfego mudam.

Ambos os fatores (a estimativa de capacidade e a atribuição proativa) influenciam a distribuição entre as instâncias. Assim, o Cloud Load Balancing se comporta de maneira diferente de um balanceador de carga round-robin simples que distribui as solicitações exatamente meio a meio entre duas instâncias. Em vez disso, o balanceamento de carga do Google Cloud tenta otimizar a seleção de instância de back-end para cada solicitação.

Saiba mais em Distribuição de tráfego.

Distribuição de tráfego do balanceador de carga HTTP(S) externo regional

Para um balanceador de carga HTTP(S) externo regional, a distribuição de tráfego é baseada no modo de balanceamento de carga e na política de localidade de balanceamento de carga.

O modo de balanceamento determina a ponderação/fração do tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG ). A política de localidade do balanceamento de carga (LocalityLbPolicy) determina como os back-ends do grupo são balanceados por carga.

Quando um serviço de back-end recebe tráfego, ele direciona primeiro o tráfego para um back-end (grupo de instâncias ou NEG ) de acordo com o modo de balanceamento do back-end. Depois que um back-end é selecionado, o tráfego é distribuído entre as instâncias ou os endpoints do grupo, de acordo com a política de localidade do balanceamento de carga.

Veja mais informações em:

Como as solicitações são distribuídas

A distribuição regional ou global do tráfego depende do modo do balanceador de carga e do nível de serviço da rede em uso.

Para o nível Premium (aplica-se apenas ao balanceador de carga HTTP(S) externo):

  • O Google divulga o endereço IP do balanceador de carga de todos os pontos de presença em todo o mundo. Cada endereço IP do balanceador de carga é anycast global.
  • Se você configurar um serviço de back-end com back-ends em várias regiões, o Google Front Ends (GFEs) tentará direcionar solicitações para grupos de instâncias de back-end íntegros ou NEGs na região mais próxima ao usuário. Os detalhes do processo estão documentados nesta página.

Para o nível Standard:

  • O Google divulga o endereço IP do balanceador de carga a partir dos pontos de presença associados à região da regra de encaminhamento. O balanceador de carga usa um endereço IP externo regional.

  • É possível configurar back-ends na mesma região que a regra de encaminhamento. O processo documentado aqui ainda se aplica, mas os GFEs só direcionam solicitações para back-ends íntegros nessa região.

Processo de distribuição de solicitações:

O modo de balanceamento e a escolha de destino definem a integridade do back-end na perspectiva de cada NEG GCE_VM_IP_PORT zonal, grupo de instâncias zonal ou zona de um grupo de instâncias regional. A distribuição dentro de uma zona é feita com hash consistente.

O balanceador de carga usa o seguinte processo:

  1. O endereço IP externo da regra de encaminhamento é divulgado pelos roteadores de borda nas bordas da rede do Google. Cada anúncio lista um próximo salto para um sistema de balanceamento de carga de camada 3/4 (Maglev) o mais próximo possível do usuário.
  2. Os sistemas Maglev inspecionam o endereço IP de origem do pacote de entrada. Eles direcionam a solicitação recebida para os sistemas Maglev que os sistemas de IP de localização geográfica do Google determinam como o mais próximo possível do usuário.
  3. Os sistemas Maglev encaminham o tráfego para o Google Front End (GFE) de primeira camada. O GFE de primeira camada encerra o TLS, se necessário, e depois direciona o tráfego para os GFEs de segunda camada de acordo com este processo:
    1. O mapa de URL seleciona um serviço de back-end.
    2. Se um serviço de back-end usar grupos de instâncias ou back-ends de NEG GCE_VM_IP_PORT, os primeiros GFEs de camada preferem os GFEs de segunda camada localizados ou próximos à região que contém o grupo de instâncias ou o NEG.
    3. Para buckets de back-end e serviços de back-end com NEGs híbridos, NEGs sem servidor e NEGs da Internet, os GFEs de primeira camada escolhem GFEs da segunda camada em um subconjunto de regiões, de modo que o tempo de retorno entre os dois GFEs seja minimizado.

      A preferência de GFE de segunda camada não é uma garantia e pode mudar dinamicamente com base nas condições de rede e na manutenção do Google.

      Os GFEs de segunda camada estão cientes do status da verificação de integridade e do uso real da capacidade do back-end.

  4. O GFE de segunda camada direciona solicitações para back-ends em zonas de sua região.
  5. Para o nível Premium, às vezes os GFEs de segunda camada enviam solicitações para back-ends em zonas de diferentes regiões. Esse comportamento é chamado de spillover.
  6. O spillover é regido por dois princípios:

    • O spillover é possível quando todos os back-ends conhecidos de um GFE de segunda camada estiverem no limite da capacidade ou não estiverem íntegros.
    • O GFE em segunda camada tem informações para back-ends íntegros e disponíveis em zonas de uma região diferente.

    Os GFEs de segunda camada normalmente são configurados para exibir um subconjunto de locais de back-end.

    O comportamento de spillover não esgota todas as zonas possíveis do Google Cloud. Se você precisar direcionar o tráfego para longe de back-ends em uma zona específica ou em uma região inteira, defina o escalonador de capacidade como zero. Configurar back-ends para que eles falhem nas verificações de integridade não garante que o GFE de segunda camada se estenda para back-ends em zonas de uma região diferente.

  7. Ao distribuir solicitações para back-ends, os GFEs operam em um nível zonal.

    Com um baixo número de solicitações por segundo, os GFEs de segunda camada às vezes preferem uma zona em uma região em vez das outras zonas. Essa preferência é normal e esperada. A distribuição entre zonas na região não se torna uniforme até que o balanceador de carga receba mais solicitações por segundo.

Afinidade da sessão

A afinidade de sessão oferece uma tentativa de melhor esforço de enviar solicitações de um determinado cliente para o mesmo back-end enquanto ele está íntegro e com capacidade, de acordo com o modo de balanceamento configurado.

Ao usar a afinidade de sessão, recomendamos o modo de balanceamento RATE, e não UTILIZATION. A afinidade de sessão tem um melhor desempenho quando o modo de balanceamento é configurado como solicitações por segundo (RPS).

O balanceamento de carga HTTP(S) do Google Cloud oferece os tipos de afinidade de sessão a seguir:

Veja na tabela a seguir um resumo das opções de afinidade de sessão compatíveis com cada modo de balanceadores de carga HTTP(S) externos:

Modo balanceador de carga Opções de afinidade de sessão
  Nenhum IP do cliente Cookie gerado Campo de cabeçalho Cookie HTTP
Balanceador de carga HTTP(S) externo
Balanceador de carga HTTP(S) externo regional

Suporte a HTTP/2

Máximo de streams simultâneos HTTP/2

A configuração HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descreve o número máximo de streams aceitos por um endpoint, iniciado pelo par. O valor anunciado por um cliente HTTP/2 para um balanceador de carga do Google Cloud é efetivamente insignificante, porque o balanceador de carga não inicia streams para o cliente.

Nos casos em que o balanceador de carga usa HTTP/2 para se comunicar com um servidor em execução em uma VM, o balanceador de carga respeita o valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado pelo servidor. Se um valor igual a zero for anunciado, o balanceador de carga não poderá encaminhar solicitações para o servidor. Isso poderá gerar erros.

Limitações do HTTP/2

  • Para balanceadores de carga HTTP(S) externos, o HTTP/2 entre o balanceador de carga e a instância pode exigir muito mais conexões TCP com a instância do que o HTTP(S). O pool de conexões, uma otimização que reduz o número dessas conexões com HTTP(S), não está disponível atualmente com o HTTP/2.
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com a execução do protocolo WebSocket em um único stream de uma conexão HTTP/2 (RFC 8461).
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com push do servidor.
  • A taxa de erros do gRPC e o volume da solicitação não são visíveis na API do Google Cloud ou no Console do Cloud. Se o endpoint do gRPC retornar um erro, os registros do balanceador de carga e os dados de monitoramento reportarão o código de resposta HTTP "OK 200".

A seguir