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 de HTTP(S) externo distribui o tráfego HTTP e HTTPS para os back-ends hospedados no Compute Engine e no Google Kubernetes Engine (GKE).

O balanceamento de carga de 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. No nível Premium, os GFEs oferecem balanceamento de carga multirregional, direcionando o tráfego para o back-end íntegro mais próximo que tem capacidade e encerrando o tráfego HTTP(S) o mais próximo possível dos usuários. Com o nível Standard, o balanceamento de carga é feito regionalmente.

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.

Arquitetura

Os recursos a seguir definem um balanceador de carga HTTP(S) externo:

  • 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 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 até o 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 ou bucket de back-end distribui as solicitações para back-ends íntegros.

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

  • Um firewall para que os back-ends aceitem sondagens de verificação de integridade.

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 e o endereço IP exigidos pelos balanceadores de carga HTTP(S) externos dependem do Nível de serviço de rede do balanceador de carga.

Para a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceamento de carga HTTP(S), consulte 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.

Tipos de proxy de destino Cabeçalhos adicionados pelo proxy Cabeçalhos personalizados compatíveis Cloud Trace compatível
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)

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.

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.

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.

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

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

ao usar o nível Premium

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

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, você precisa criar uma regra de firewall que permita que o tráfego alcance suas instâncias. A regra de firewall precisa permitir os seguintes intervalos de origem:

  • 130.211.0.0/22
  • 35.191.0.0/16

Os balanceadores de carga HTTP(S) externos usam verificações de integridade globais.

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

Protocolo para os back-ends

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

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

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

Como usar o gRPC com seus aplicativos do Google Cloud

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.

Regras de firewall

As instâncias de back-end precisam permitir conexões das seguintes origens:

  • O balanceador de carga Google Front End (GFE) para todas as solicitações enviadas aos back-ends.
  • Sondagens de verificação de integridade

Para permitir esse tráfego, você precisa criar regras de firewall de entrada. As portas para essas regras de firewall precisam permitir o tráfego da seguinte maneira:

  • Para a porta de destino de cada verificação de integridade do serviço de back-end.

  • Para back-ends de grupos de instâncias: determinados 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 de NEG GCE_VM_IP_PORT: para os números de porta 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. É possível usar o Google Cloud Armor para fazer isso.

Saiba mais sobre sondagens de verificação de integridade e por que é necessário permitir tráfego deles em Intervalos de IP de sondagem e regras de firewall.

Para balanceadores de carga HTTP(S) externos, a tabela a seguir especifica os intervalos de origem de verificação de integridade e solicitação:

Intervalos de origem da verificação de integridade Intervalos de origem de solicitação do GFE
  • 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.

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:

  • 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 da nuvem privada virtual (VPC).

Caminho de retorno

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.

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

O balanceamento 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 o tráfego é direcionado 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. 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 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. Saiba mais em Tempos limite e novas tentativas.

Os sinais de atividade HTTP tentam usar de forma eficiente a mesma sessão TCP. No entanto, não há garantias. Embora esteja estreitamente relacionado, um sinal de atividade HTTP e um sinal de inatividade TCP não são a mesma coisa.

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.

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.

Para a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceamento de carga HTTP(S), consulte Recursos do balanceador de carga.

Portas abertas

Os balanceadores de carga HTTP(S) externos são balanceadores de carga de proxy reverso. O balanceador de carga encerra as conexões de entrada e depois abre novas conexões do balanceador de carga para os back-ends. Esses balanceadores de carga são implementados usando proxies do Google Front End (GFE) em todo o mundo.

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 balanceadores de carga HTTP(S) externos que usam a porta TCP 443, a porta UDP 443 é usada quando é feito o upgrade da conexão 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

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

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.

    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.

Para o tráfego WebSocket enviado pelo balanceador de carga, o tempo limite do serviço de back-end é interpretado como o tempo máximo em que uma conexão WebSocket pode permanecer aberta, esteja ela inativa ou não. Saiba mais em Configurações do serviço de back-end.

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

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;

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. Ele não repete solicitações POST com falha. As repetições são limitadas a duas tentativas. As solicitações repetidas geram apenas uma entrada de registro como resposta final.

Um GFE não realizará uma nova tentativa se mais de 80% das instâncias de back-end não estiverem íntegras. 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. Para mais informações, consulte Geração de registros e monitoramento de balanceamento de carga HTTP(S).

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.

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.

Saiba mais sobre os modos de balanceamento em Modo de balanceamento.

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

A distribuição do tráfego regional ou global depende 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 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 por zona, grupo de instâncias por zona 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.

O balanceamento de carga do Google Cloud HTTP(S) oferece três tipos de afinidade da sessão:

  • NONE. A afinidade de sessão não está definida para o balanceador de carga.
  • A afinidade de IP do cliente envia solicitações do mesmo endereço IP do cliente para o mesmo back-end.
  • A afinidade de cookie gerado define um cookie de cliente quando a primeira solicitação é realizada e depois envia solicitações com esse cookie para o mesmo back-end.

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

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.

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 8441).
  • 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