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

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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) externo é um balanceador de carga global da camada 7 baseado em proxy que permite executar e escalonar serviços 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.

Modos de operação

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

  • Balanceador de carga HTTP(S) externo global. Este é um balanceador de carga global que é implementado como um serviço gerenciado no Google Front Ends (GFEs). Ele usa o proxy Envoy de código aberto para oferecer suporte a 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.
  • Balanceador de carga HTTP(S) externo global (versão clássica). Este é o balanceador de carga HTTP(S) externo clássico que é global no nível Premium, mas pode ser configurado para ser regional no nível Standard. Esse balanceador de carga é 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. 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 Funções
Balanceador de carga HTTP(S) externo global Use esse balanceador de carga para cargas de trabalho HTTP(S) externas com usuários dispersos globalmente ou serviços de back-end em várias regiões.
Balanceador de carga HTTP(S) externo global (clássico)

Esse balanceador de carga é global no nível Premium, mas pode ser configurado para ser efetivamente regional no nível Standard.

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

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

  • Compatível com o GKE usando o Ingress ou gateway (totalmente orquestrado).
  • Compatível com o Google Cloud Armor (incluindo gerenciamento de bots).
  • Menos recursos de roteamento de tráfego.
Consulte a página de Recursos do balanceamento de carga para ver a lista completa de recursos.
Balanceador de carga HTTP(S) externo regional

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

Use esse balanceador de carga se quiser exibir conteúdo de apenas uma geolocalização (por exemplo, para atender às regulamentações de conformidade) ou se você quiser usar o nível de serviço de rede Standard.

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

Como identificar o modo

Console do Cloud

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.
    Acessar balanceamento de carga
  2. Na guia Balanceadores de carga, você verá o protocolo, a região e o tipo de balanceador. Se a região estiver em branco, o balanceador de carga será global. Veja na tabela a seguir como identificar o modo do balanceador de carga.
    Modo balanceador de carga Tipo de balanceamento de carga Região Nível da rede
    Balanceador de carga HTTP(S) externo global HTTP(S) PREMIUM
    Balanceador de carga HTTP(S) externo global (clássico) HTTP(S) (clássico) PADRÃO OU PREMIUM
    Balanceador de carga HTTP(S) externo regional (Prévia) HTTP(S) Especifica uma região STANDARD

gcloud

  1. Para determinar o modo de um balanceador de carga, execute o seguinte comando:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
    

    Na saída do comando, verifique o esquema de balanceamento de carga, a região e o nível da rede. Veja na tabela a seguir como identificar o modo do balanceador de carga.

    Modo balanceador de carga Esquema de balanceamento de carga Regra de encaminhamento Nível da rede
    Balanceador de carga HTTP(S) externo global EXTERNAL_MANAGED Global PREMIUM
    Balanceador de carga HTTP(S) externo global (clássico) EXTERNAL Global PADRÃO OU PREMIUM
    Balanceador de carga HTTP(S) externo regional EXTERNAL_MANAGED Especifica uma região STANDARD

Arquitetura

Os seguintes recursos são necessários para uma implantação de balanceamento de carga HTTP(S):

  • 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. Os balanceadores de carga HTTP(S) externos globais também suportam 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.

Global

Este diagrama mostra os componentes de uma implantação de balanceador de carga HTTP(S) externo global. Essa arquitetura se aplica ao balanceador de carga HTTP(S) externo global com recurso avançado de gerenciamento de tráfego e ao balanceador de carga HTTP(S) externo global (versão clássica) no nível Premium.

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

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 regionais baseados em Envoy na mesma região e rede VPC compartilham um pool de proxies do 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.

Se você já tiver criado uma sub-rede somente proxy com --purpose=INTERNAL_HTTPS_LOAD_BALANCER, é necessário migrar a finalidade da sub-rede para REGIONAL_MANAGED_PROXY antes de criar outros balanceadores de carga baseados no Envoy na mesma região da rede VPC.

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 global Nível Premium

Regra de encaminhamento externo global

Endereço IP externo global

Esquema de balanceamento de carga:
EXTERNAL_MANAGED

Solicitações encaminhadas para o GFE mais próximo do cliente na Internet.
Balanceador de carga HTTP(S) externo global (clássico) 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 pelo balanceamento de carga HTTP(S) 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 global 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

Sem suporte ao Cloud CDN

Balanceador de carga HTTP(S) externo global (clássico) 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>

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.

Os mapas de URL usados com balanceadores de carga HTTP(S) externos globais e com balanceadores de carga HTTP(S) externos regionais suportam vários recursos avançados de gerenciamento de tráfego, como direcionamento de tráfego com base em cabeçalho, divisão de tráfego com base em peso e espelhamento de solicitações. Para ver mais informações, consulte os seguintes tópicos:

Veja na tabela a seguir o tipo de mapa de URL exigido pelo balanceamento de carga HTTP(S) em cada modo.

Modo balanceador de carga Tipo de mapa de URL
Balanceador de carga HTTP(S) externo global Global
Balanceador de carga HTTP(S) externo global (clássico) 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) em cada modo:

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

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

Gerenciador de certificados

Se você estiver usando o balanceador de carga HTTP(S) externo global (clássico) no nível de serviço de rede Premium, use o Gerenciador de certificados para provisionar e gerenciar seus certificados SSL em várias instâncias do balanceador de carga HTTP(S) externo (clássico) global em escala. Para mais informações, consulte a Visão geral do Gerenciador de certificados.

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.

A tabela a seguir especifica o suporte da política de SSL com balanceadores de carga em cada modo.

Modo balanceador de carga Políticas de SSL suportadas
Balanceador de carga HTTP(S) externo global
Balanceador de carga HTTP(S) externo global (clássico)
Balanceador de carga HTTP(S) externo regional

Bucket e serviços 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.

A tabela a seguir especifica os recursos de back-end suportados pelo balanceamento de carga HTTP(S) em cada modo.


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 NEGs do Private Service Connect
Balanceador de carga HTTP(S) externo global
Balanceador de carga HTTP(S) externo global (clássico)
ao usar o nível Premium

Balanceador de carga HTTP(S) externo regional

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

Back-ends e redes VPC

As restrições de onde os back-ends podem estar localizados dependem do tipo de balanceador de carga.

  • Para o balanceador de carga HTTP(S) externo global e o balanceador de carga HTTP(S) externo (clássico), todos os back-ends precisam estar localizados no mesmo projeto, mas podem estar localizados em redes VPC diferentes. As diferentes redes VPC não precisam ser conectadas usando o peering de rede VPC, porque os sistemas de proxy GFE se comunicam diretamente com os back-ends nas respectivas redes VPC.
  • Para o balanceador de carga HTTP(S) externo regional, todos os back-ends precisam estar localizados na mesma rede e região VPC.

Protocolo para os back-ends

Ao configurar um serviço de back-end para o balanceador de carga, 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 do gRPC:

  • Sistemas distribuídos de baixa latência e altamente escalonáveis.
  • Desenvolvimento de clientes de dispositivos móveis que se comunicam 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:

  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 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.

A tabela a seguir especifica o escopo da verificação de integridade suportada pelo balanceamento de carga HTTP(S) em cada modo.

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

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

Regras de firewall

O balanceamento de carga HTTP(S) requer as seguintes regras de firewall:

  • Para os balanceadores de carga HTTP(S) externos globais, uma regra de permissão de entrada para permitir que o tráfego dos Google Front Ends (GFEs) alcance os back-ends.
    Para o balanceador de carga HTTP(S) externo regional, uma regra de permissão de entrada para permitir que o tráfego da sub-rede somente proxy alcance seus back-ends.
  • 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 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 global e o balanceador de carga HTTP(S) externo global (clássico), é possível usar o Google Cloud Armor para alcançar isso.

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.

A tabela a seguir resume os intervalos de endereços IP de origem obrigató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 global
  • 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
  • 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 global (clássico)
  • 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.

Arquitetura da VPC compartilhada

O balanceamento de carga HTTP(S) é compatível com redes que usam VPC compartilhada. A VPC compartilhada permite que as organizações conectem recursos de vários projetos a uma rede VPC comum para que eles possam se comunicar uns com os outros com segurança e eficiência usando IPs internos dessa rede. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada.

Há muitas maneiras de configurar o balanceamento de carga HTTP(S) externo em uma rede VPC compartilhada. Independentemente do tipo de implantação, todos os componentes do balanceador de carga precisam estar na mesma organização.

Balanceador de carga Componentes de front-end Componentes de back-end
Balanceador de carga HTTP(S) externo
balanceador de carga HTTP(S) global (clássico)
O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto de serviço dos back-ends. Um serviço de back-end global precisa ser definido no mesmo projeto de serviço que os back-ends (grupos de instâncias ou NEGs). As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.
Balanceador de carga HTTP(S) externo regional

Crie a rede e a sub-rede somente proxy necessárias no projeto host da VPC compartilhada.

O endereço IP externo regional, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto. Esse projeto pode ser o projeto host ou de serviços.

Você tem estas opções:

Embora seja possível criar todos os componentes e back-ends de balanceamento de carga no projeto host da VPC compartilhada, esse modelo não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Back-ends sem servidor em um ambiente de VPC compartilhada

Para um balanceador de carga que esteja usando um back-end de NEG sem servidor, o backup do Cloud Run, Cloud Functions ou App Engine precisa estar no mesmo projeto que o NEG sem servidor.

Além disso, para o balanceador de carga HTTP(S) externo regional que aceita referência de serviço entre projetos, o serviço de back-end, o NEG sem servidor e o serviço do Cloud Run precisam estar sempre no mesmo projeto de serviço.

Referência de serviço entre projetos

Nesse modelo, o front-end e o mapa de URL do balanceador de carga estão em um projeto host ou de serviço. Os serviços e back-ends de balanceador de carga podem ser distribuídos entre projetos no ambiente de VPC compartilhada. Os serviços de back-end entre projetos podem ser referenciados em um mapa de URL. Isso é chamado de referência de serviço entre projetos.

A referência de serviços entre projetos permite que as organizações configurem um balanceador de carga central e direcionem o tráfego para centenas de serviços distribuídos em vários projetos diferentes. É possível gerenciar de maneira centralizada todas as regras e políticas de roteamento de tráfego em um mapa de URL. Também é possível associar o balanceador de carga a um único conjunto de nomes de host e certificados SSL. Portanto, é possível otimizar o número de balanceadores de carga necessários para implantar o aplicativo e reduzir os gerenciamentos, os custos operacionais e os requisitos de cota.

Com projetos diferentes para cada uma das equipes funcionais, também é possível alcançar a separação de papéis dentro da organização. Os proprietários de serviços podem se concentrar na criação de serviços em projetos de serviço, enquanto as equipes de rede podem provisionar e manter os balanceadores de carga em outro projeto e podem ser conectadas usando a referência de serviço entre projetos.

Os proprietários de serviços podem manter a autonomia sobre a exposição dos próprios serviços e controlar quais usuários podem acessá-los pelo balanceador de carga. Isso é alcançado por um papel especial do IAM, chamado papel de IAM do usuário do serviço do balanceador de carga.

Para saber como configurar a VPC compartilhada para um balanceador de carga HTTP(S) externo regional, com e sem referência de serviço entre projetos, consulte Como configurar um balanceador de carga HTTP(S) externo regional com VPC compartilhada.

A referência de serviços entre projetos não é compatível com o balanceador de carga HTTP(S) externo global e o balanceador de carga HTTP(S) externo global (clássico).

Exemplo 1 de referência de serviço entre projetos: front-end e back-end do balanceador de carga em projetos de serviço diferentes

Veja um exemplo de uma implantação em que o mapa de URL e o front-end do balanceador de carga são criados no projeto de serviço A e o mapa de URL faz referência a um serviço de back-end no projeto de serviço B.

Nesse caso, os administradores de rede ou administradores do balanceador de carga no projeto de serviço A precisarão de acesso aos serviços de back-end no projeto de serviço B. Os administradores do projeto de serviço B concedem o papel compute.loadBalancerServiceUser do IAM aos administradores do balanceador de carga no projeto de serviço A que querem referenciar o serviço de back-end no projeto de serviço B.

Front-end do balanceador de carga e mapa de URL no projeto de serviço
Front-end e balanceador de carga do balanceador de carga em projetos de serviço diferentes

Exemplo 2 de referência de serviço entre projetos: front-end do balanceador de carga no projeto host; back-ends em projetos de serviço

Nesse tipo de implantação, o front-end e o mapa de URL do balanceador de carga são criados no projeto host, e os serviços de back-end (e back-ends) são criados em projetos de serviço.

Nesse caso, os administradores de rede ou de balanceador de carga no projeto host precisarão de acesso aos serviços de back-end nos projetos de serviço. Os administradores do projeto de serviço concedem o papel compute.loadBalancerServiceUser do IAM aos administradores do balanceador de carga no projeto host A que querem referenciar o serviço de back-end no projeto de serviço.

Front-end do balanceador de carga e mapa de URL no projeto host
Front-end do balanceador de carga e mapa de URL no projeto host

Todos os componentes e back-ends do balanceador de carga em um projeto de serviço

Nesse modelo, todos os componentes e back-ends do balanceador de carga estão em um projeto de serviço. Esse modelo de implantação é compatível com todos os balanceadores de carga HTTP(S).

Os componentes e os back-ends do balanceador de carga precisam usar a mesma rede VPC.

Balanceador de carga HTTP(S) externo regional em uma rede VPC compartilhada
Balanceador de carga HTTP(S) externo regional em rede VPC compartilhada

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

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

Os balanceadores de carga HTTP(S) externos globais são implementados 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 é divulgado 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 regionais baseados no Envoy em uma rede e região específicas 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 balanceadores de carga HTTP(S) externos globais:
  • 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 balanceadores de carga HTTP(S) externos regionais:

  • 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 os balanceadores de carga HTTP(S) externos globais, o Google Cloud usa rotas especiais não definidas na 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 aos balanceadores de carga HTTP(S) externos globais que são implementados 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 vão enviar pacotes SYN-ACK em resposta a sondagens SYN somente para portas em que você configurou uma regra de encaminhamento e nas portas 80 e 443 se o balanceador de carga usar um endereço IP de nível Premium. 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 que usa a porta TCP 443, a porta UDP 443 é usada quando a conexão recebe upgrade para 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 global O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo.
Balanceador de carga HTTP(S) externo global (clássico) 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) externo 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.

    Por exemplo, se você quiser fazer o download de um arquivo de 500 MB e o valor do tempo limite do serviço de back-end for o valor padrão de 30 segundos, o balanceador de carga espera que o back-end forneça todo o arquivo de 500 MB dentro de 30 segundos. É possível configurar o tempo limite do serviço de back-end para não ser longo o suficiente para que o back-end envie a resposta HTTP completa. Nessa situação, se o balanceador de carga tiver recebido pelo menos os cabeçalhos da resposta HTTP, ele vai retornar os cabeçalhos completos e o máximo possível do corpo de resposta dentro do tempo limite do serviço de back-end.

    O tempo limite do serviço de back-end precisa ser definido como o tempo máximo possível do primeiro byte da solicitação até o último byte da resposta, para a interação entre o proxy (GFE ou Envoy gerenciado) e o back-end. Se você estiver usando WebSockets, o tempo limite do serviço de back-end deve ser definido para a duração máxima de um WebSocket, inativo ou ativo.

    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.

    O tempo limite do serviço de back-end definido é uma meta de melhor esforço. Isso não garante que as conexões TCP subjacentes permanecerão abertas durante esse tempo limite.

    È possível definir o tempo limite do serviço de back-end como qualquer valor. No entanto, defini-lo como um valor além de um dia (86.400 segundos) não significa que o balanceador de carga manterá uma conexão TCP em execução por esse tempo. O Google reinicia periodicamente as tarefas de software dos GFEs e Envoy para atualizações de software e manutenção de rotina, e o tempo limite do serviço de back-end não substitui isso. Quanto maior for o tempo limite do serviço de back-end, mais provável será que o Google encerre uma conexão TCP para a manutenção. Recomendamos que você implemente a lógica de repetição para reduzir o impacto desses eventos.

    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 configurar o tempo limite do serviço de back-end, use um dos seguintes métodos:

    • Console do Google Cloud: modifique o campo Tempo limite do serviço de back-end do balanceador de carga.
    • Google Cloud CLI: use o comando gcloud compute backend-services update para modificar o parâmetro --timeout do recurso de serviço de back-end.
    • API: modifique o parâmetro timeoutSec para o recurso de serviço de back-end global ou regional.

    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 do servidor da Web usado pelos seus back-ends para que o tempo limite de keepalive 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 sinal de atividade 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;

Novas tentativas

O suporte 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 global

Configurável usando uma política de repetição no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. O número máximo de novas tentativas que podem ser configuradas usando a política de nova tentativa é 25. O tempo limite padrão de cada tentativa (perTryTimeout) é de 30 segundos, com um perTryTimeout configurável máximo de 24 horas.

Sem uma política de novas tentativas, as solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultam em respostas HTTP 502, 503 ou 504 (retryConditions=["gateway-error"]) serão repetidas uma vez. As solicitações HTTP POST não serão repetidas.

As solicitações repetidas geram apenas uma entrada de registro como resposta final.

Balanceador de carga HTTP(S) externo global (clássico)

Não é possível alterar a política de novas tentativas de conexã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 novas tentativas de solicitação estão limitadas a 25 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. O número padrão de novas tentativas (numRetries) é 1. O número máximo de novas tentativas que podem ser configuradas usando a política de nova tentativa é 25. O tempo limite padrão de cada tentativa (perTryTimeout) é de 30 segundos, com um perTryTimeout configurável máximo de 24 horas.

Sem uma política de novas tentativas, as solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultam em respostas HTTP 502, 503 ou 504 (retryConditions=["gateway-error"]) serão repetidas uma vez. As solicitações HTTP POST não serão repetidas.

As solicitações repetidas geram apenas uma entrada de registro como resposta final.

O protocolo WebSocket é suportado pela Entrada do GKE.

Tratamento de solicitações e respostas inválidas

O balanceador de carga 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. 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.

Balanceador de carga HTTP(S) externo global

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.

Para o balanceador de carga HTTP(S) externo global (versão clássica), o modo de balanceamento é usado para selecionar o back-end mais favorável (grupo de instâncias ou NEG). O tráfego é distribuído em estilo round-robin entre instâncias ou endpoints no back-end.

Para o balanceador de carga HTTP(S) externo global, o balanceamento de carga é em dois níveis. O modo de balanceamento determina a ponderação ou fração de tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG). Em seguida, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para as instâncias ou endpoints no grupo. Para mais informações, consulte a política de localidade de balanceamento de carga (documentação da API Backend Service).

Balanceador de carga HTTP(S) externo regional

Para balanceadores de carga HTTP(S) externos regionais, a distribuição de tráfego é baseada no modo de balanceamento de carga e na política de localidade do balanceamento de carga.

O modo de balanceamento determina a ponderação e 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.

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

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:

  • 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 o balanceador de carga direciona apenas as 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 para o balanceador de carga HTTP(S) externo global (versão clássica) e é configurável usando a política de localidade de balanceamento de carga para balanceadores de carga HTTP(S) externos globais e balanceadores de carga HTTP(S) externos regionais.

Balanceadores de carga HTTP(S) externos globais baseados em GFE usam o processo a seguir para distribuir solicitações recebidas:

  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).
  2. 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.

  3. O GFE de segunda camada direciona solicitações para back-ends em zonas de sua região.
  4. 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.
  5. 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.

  6. 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) 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 suportadas por cada modo de balanceamento de carga HTTP(S):

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 global
Balanceador de carga HTTP(S) externo global (clássico)
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

  • 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 Google 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".

Compatibilidade com HTTP/3 e Google QUIC

O HTTP/3 é um protocolo de Internet de última geração. Ele é baseado no IETF QUIC, um protocolo desenvolvido a partir do protocolo Google QUIC 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.
  • O HTTP/3 é uma camada de aplicativo criada com base no IETF QUIC e depende do QUIC para lidar com a multiplexação, o controle de congestionamento, a detecção de perdas e a retransmissão.
  • 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 algoritmo de controle de congestionamento BBR.

Ativar o HTTP/3 no balanceador de carga pode melhorar os tempos de carregamento de páginas da Web, reduzir o armazenamento em buffer de vídeo e melhorar a capacidade em conexões de maior latência.

A tabela a seguir especifica o suporte do HTTP/3 ao balanceamento de carga HTTP(S) em cada modo.

Modo balanceador de carga Suporte a HTTP/3
Balanceador de carga HTTP(S) externo global
Balanceador de carga HTTP(S) externo global (clássico)
Balanceador de carga HTTP(S) externo regional

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 HTTP/3.
  • 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 isso, ativar ou desativar o HTTP/3 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 incluem o seguinte valor de cabeçalho alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":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 HTTP/3 está ativado no balanceador de carga HTTPS, algumas circunstâncias podem fazer com que o cliente recorra a HTTPS ou HTTP/2 em vez de negociar o HTTP/3. 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 a impedir o funcionamento do HTTP/3.
  • 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, isso não é considerado 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.

Configurar HTTP/3

Para ativar explicitamente o suporte a HTTP/3 para o balanceador de carga, defina quicOverride como ENABLE.

Quando você ativa o HTTP/3, o balanceador de carga o anuncia para os clientes, permitindo que clientes compatíveis negociem uma versão HTTP/3 com o balanceador de carga. Clientes não compatíveis com HTTP/3 não negociam uma conexão HTTP/3. Não é necessário desativar o HTTP/3 explicitamente, a menos que você tenha identificado implementações de cliente corrompidas.

O balanceamento de carga HTTP(S) oferece três maneiras de configurar o HTTP/3, conforme mostrado na tabela a seguir.

Valor quicOverride Comportamento
NONE

A compatibilidade com HTTP/3 é anunciada para os clientes.

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: 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 ao usar o HTTP/3.

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 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:

  • NONE (padrão): permite que o Google controle quando o HTTP/3 é anunciado.

    Atualmente, quando você seleciona NONE, o HTTP/3 é anunciado para os clientes, mas o Google QUIC não.

    No console do Google Cloud, essa opção é chamada de Automática (padrão).

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

  • DISABLE: não divulga HTTP/3 ou Google QUIC para os 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:

  • NONE (padrão): permite que o Google controle quando o HTTP/3 é anunciado.

    Atualmente, quando você seleciona NONE, o HTTP/3 é anunciado para os clientes, mas o Google QUIC não.

    No console do Google Cloud, essa opção é chamada de Automática (padrão).

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

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

Limitações

  • 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.
  • Os balanceadores de carga HTTPS não enviam um alerta de encerramento close_notify ao encerrar conexões SSL. Ou seja, o balanceador de carga fecha a conexão TCP em vez de executar um encerramento SSL.
  • Os balanceadores de carga HTTPS são compatíveis apenas com caracteres em minúsculas nos domínios em um atributo de nome comum (CN) ou em um atributo de nome alternativo do assunto (SAN) do certificado. Os certificados com caracteres maiúsculos em domínios são retornados somente quando definidos como o certificado principal no proxy de destino.
  • Os balanceadores de carga HTTPS não usam a extensão de indicação de nome do servidor (SNI, na sigla em inglês) ao se conectar ao back-end, exceto para balanceadores de carga com back-ends de NEG da Internet. Veja mais detalhes em Criptografia do balanceador de carga aos back-ends.
  • Quando o Google Cloud Armor é usado com o balanceador de carga HTTP(S) externo com recurso avançado de gerenciamento de tráfego, algumas interações entre as regras do Google Cloud Armor e os serviços de back-end EXTERNAL_MANAGED podem resultar em tempos limite HTTP 408, especialmente quando as solicitações incluem corpos POST.
  • Ao usar balanceadores de carga HTTP(S) externos regionais com o Cloud Run em um ambiente de VPC compartilhada, as redes VPC independentes em projetos de serviço podem enviar tráfego para qualquer outro serviço do Cloud Run implantado em qualquer outro projeto de serviço no mesmo ambiente de VPC compartilhada. Esse é um problema conhecido e essa forma de acesso será bloqueada no futuro.
  • O reCAPTCHA Enterprise para WAF com o Google Cloud Armor é compatível apenas com o balanceador de carga HTTP(S) externo global (clássico). O balanceador de carga HTTP(S) externo global com recursos avançados de gerenciamento de tráfego não é compatível.

A seguir