Visão geral do balanceador de carga de aplicativo externo

Neste documento, apresentamos os conceitos necessários para configurar um balanceador de carga de aplicativo externo.

O balanceador de carga de aplicativo externo é um balanceador de carga da camada 7 baseado em proxy que permite executar e escalonar serviços atrás de um único endereço IP externo. O balanceador de carga de aplicativo externo distribui o tráfego HTTP e HTTPS para back-ends hospedados em várias plataformas do Google Cloud, como o Compute Engine, o Google Kubernetes Engine (GKE), o Cloud Storage e assim por diante, bem como back-ends externos conectados pela Internet ou por conectividade híbrida. Para mais detalhes, consulte Visão geral do balanceador de carga de aplicativo: casos de uso.

Modos de operação

É possível configurar um balanceador de carga de aplicativo externo nos seguintes modos:

• Balanceador de carga de aplicativo 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 de gerenciamento de tráfego avançado, 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 de aplicativo clássico. Este é o balanceador de carga de aplicativo 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 de aplicativo externo regional. Esse é um balanceador de carga regional implementado como um serviço gerenciado no proxy Envoy de código aberto. Ele inclui recursos avançados de gerenciamento de tráfego, como espelhamento de tráfego, divisão de tráfego baseada em peso, transformações de cabeçalho com base em solicitação/resposta e muito mais.

Modo balanceador de carga	Casos de uso recomendados	Recursos
Balanceador de carga de aplicativo 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.	Compatível com o GKE usando o gateway (totalmente orquestrado) ou NEGs independentes (orquestração manual). Suporta gerenciamento de tráfego avançado Endereços IP externos Anycast globais no nível Premium Pode acessar back-ends em várias regiões Compatível com Cloud CDN. Compatível com o Google Cloud Armor
Balanceador de carga de aplicativo clássico	Esse balanceador de carga é global no nível Premium. No nível do serviço de rede Premium, esse balanceador de carga oferece balanceamento de carga entre regiões, tenta direcionar 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. Para detalhes sobre o processo de distribuição de solicitações, consulte Distribuição de tráfego. No nível de serviço de rede padrão, esse balanceador de carga pode distribuir tráfego para back-ends em apenas uma região.	Compatível com o GKE usando o Gateway (totalmente orquestrado), Entrada (totalmente orquestrada) ou NEGs independentes (orquestração manual). Compatível com o Google Cloud Armor 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 de aplicativo externo regional	Esse balanceador de carga contém muitos dos recursos do balanceador de carga clássico do aplicativo atual, além de recursos de gerenciamento de tráfego avançado. Use este balanceador de carga se quiser veicular conteúdo de apenas uma geolocalização (por exemplo, para atender a regulamentações de conformidade). Este balanceador de carga pode ser configurado no nível Premium ou Standard.	Compatível com o GKE usando NEGs independentes (orquestração manual). Compatível com recursos avançados de gerenciamento de tráfego VIPs regionais usando o nível Padrão de rede Encerra o TLS em uma única região que você configura Veicula conteúdo somente da região configurada Para ver a lista completa, consulte Recursos de balanceamento de carga.

Identificar o modo

console do Cloud

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

   Acessar o "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. A tabela a seguir resume como identificar o modo do balanceador de carga.

Modo balanceador de carga	>Tipo de balanceador de carga	Tipo de acesso	Região
Balanceador de carga de aplicativo externo global	legado	Externos
Balanceador de carga de aplicativo clássico	Aplicativo (clássico)	Externos
Balanceador de carga de aplicativo externo regional	legado	Externos	Especifica uma região

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 de aplicativo externo global	EXTERNAL_MANAGED	Global	Premium
Balanceador de carga de aplicativo clássico	EXTERNO	Global	Padrão ou Premium
Balanceador de carga de aplicativo externo regional	EXTERNAL_MANAGED	Especifica uma região	Padrão ou Premium

Importante: depois de criar um balanceador de carga, não é possível editar o modo. Em vez disso, é preciso excluir o balanceador de carga e criar um novo.

Arquitetura

Os seguintes recursos são necessários para uma implantação externa do balanceador de carga de aplicativo:

• Somente para balanceadores de carga de aplicativo externos regionais, 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. 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 determinar o 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 as solicitações de cliente para serviços ou buckets de back-end específicos. O mapa de URLs pode especificar outras ações, 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 de aplicativo externos globais também são compatíveis com buckets de back-end. Um ou mais back-ends precisam estar conectados ao serviço de back-end 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 possam atender à solicitação.

• Regras de firewall para que os back-ends aceitem sondagens de verificação de integridade. Os balanceadores de carga de aplicativo externos 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 do balanceador de carga de aplicativo externo global. Essa arquitetura se aplica ao balanceador de carga de aplicativo externo global e ao balanceador de carga de aplicativo clássico no nível Premium.

Componentes do balanceador de carga de aplicativo externo global (clique para ampliar).

Regional

Este diagrama mostra os componentes de uma implantação do balanceador de carga de aplicativo externo regional.

Componentes do balanceador de carga de aplicativo externo regional (clique para ampliar).

Sub-rede somente proxy

Sub-redes somente proxy são necessárias apenas para balanceadores de carga regionais de aplicativos externos.

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 de aplicativo externos regionais. A flag --purpose dessa sub-rede somente proxy está 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 de aplicativo 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 regional externo do aplicativo não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciado externo, descrita abaixo.

Se você já tiver criado uma sub-rede somente proxy com --purpose=INTERNAL_HTTPS_LOAD_BALANCER, será 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 de encaminhamento e endereços IP

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 um proxy de destino, mapa de URL e um ou mais serviços de back-end.

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

Especificação da porta. Cada regra de encaminhamento para um balanceador de carga de aplicativo pode referenciar uma única porta de 1 a 65535. Para permitir várias portas, configure várias regras de encaminhamento. É possível configurar várias regras de encaminhamento para usar o mesmo endereço IP externo (VIP) e ter referência ao mesmo proxy HTTP(S) de destino, desde que a combinação geral do endereço IP, da porta e do protocolo sejam exclusivos para cada regra de encaminhamento. Dessa forma, é possível usar um único balanceador de carga com um mapa de URL compartilhado como um proxy para vários aplicativos.

O tipo de regra de encaminhamento, o endereço IP e o esquema de balanceamento de carga usado por balanceadores de carga de aplicativo 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 de aplicativo 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 de aplicativo 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 de aplicativo externo regional	Nível Premium ou Standard	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL_MANAGED	As solicitações chegam ao Google Cloud no PoP mais próximo do cliente. As solicitações são encaminhadas pela backbone premium do Google Cloud até chegarem aos proxies do Envoy na mesma região que o balanceador de carga.

^* É possível anexar serviços de back-end EXTERNAL_MANAGED a regras de encaminhamento EXTERNAL. No entanto, os serviços de back-end EXTERNAL não podem ser anexados às regras de encaminhamento EXTERNAL_MANAGED. Para aproveitar os novos recursos disponíveis apenas com o balanceador de carga de aplicativo externo global, recomendamos que você migre seus recursos EXTERNAL atuais para EXTERNAL_MANAGED usando o processo de migração descrito em Migrar recursos do balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global.

Confira a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceador de carga de aplicativo em cada modo em Recursos do balanceador de carga.

Regras de encaminhamento e redes VPC

Esta seção descreve como as regras de encaminhamento usadas por balanceadores de carga de aplicativo externos são associadas às redes VPC.

Modo balanceador de carga	Associação de rede VPC
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico	Nenhuma rede VPC associada. A regra de encaminhamento sempre usa um endereço IP que está fora da rede VPC. Portanto, a regra de encaminhamento não tem uma rede VPC associada.
Balanceador de carga de aplicativo externo regional	A rede VPC da regra de encaminhamento é a rede em que a sub-rede somente proxy foi criada. Você especifica a rede ao criar a regra de encaminhamento. Dependendo se você usa um endereço IPv4 ou um intervalo de endereços IPv6, sempre há uma rede VPC explícita ou implícita associada à regra de encaminhamento. Os endereços IPv4 externos regionais sempre existem fora das redes VPC. No entanto, ao criar a regra de encaminhamento, é necessário especificar a rede VPC em que a sub-rede somente proxy foi criada. Portanto, a regra de encaminhamento tem uma associação de rede explícita. Os intervalos de endereços IPv6 externos regionais sempre existem dentro de uma rede VPC. Ao criar a regra de encaminhamento, você precisa especificar a sub-rede de onde o intervalo de endereços IP é retirado. Essa sub-rede precisa estar na mesma região e rede VPC em que uma sub-rede somente proxy foi criada. Assim, há uma associação de rede implícita.

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.

Observação: para grupos de endpoints de rede (NEGs, na sigla em inglês) da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IPs, dependendo do tipo de NEG (global ou regional) ). Para mais informações, consulte Como autenticar solicitações.

A tabela a seguir especifica o tipo de proxy de destino exigido pelos balanceadores de carga de aplicativo externos.

Modo balanceador de carga	Tipos de proxy de destino	Cabeçalhos adicionados pelo proxy	Cabeçalhos personalizados compatíveis
Balanceador de carga de aplicativo 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-Forwarded-For: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações) Os proxies também definem o cabeçalho X-Cloud-Trace-Context se ele ainda não estiver presente.	Configurado no serviço ou bucket de back-end Sem suporte ao Cloud CDN
Balanceador de carga de aplicativo 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-Forwarded-For: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações) Os proxies também definem o cabeçalho X-Cloud-Trace-Context se ele ainda não estiver presente.	Configurado no serviço ou bucket de back-end
Balanceador de carga de aplicativo 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)	Configurado no mapa de URL

Observação: de acordo com a RFC 2616, os seguintes cabeçalhos de salto a salto não são propagados pelo proxy de destino: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding e Upgrade.

Além dos cabeçalhos adicionados pelo proxy de destino, o balanceador de carga ajusta outros cabeçalhos HTTP das seguintes maneiras:

• Para o balanceador de carga de aplicativo externo global, os cabeçalhos de solicitação e de resposta podem ser convertidos em letras minúsculas.

  A única exceção é quando você usa back-ends globais de NEG da Internet com HTTP/1.1. Para detalhes sobre como os cabeçalhos HTTP/1.1 são processados com NEGs globais da Internet, consulte a Visão geral de NEGs da Internet.

• Para o balanceador de carga de aplicativo clássico, os cabeçalhos de solicitação e resposta são convertidos em letras minúsculas, exceto quando você usa HTTP/1.1. No HTTP/1.1, os cabeçalhos são inseridos corretamente. A primeira letra da chave do cabeçalho e todas as letras após um hífen (-) são exibidas em maiúsculas para preservar a compatibilidade com clientes HTTP/1.1. Por exemplo, user-agent é alterado para User-Agent e content-encoding é alterado para Content-Encoding.

• Alguns cabeçalhos são agrupados. Quando houver várias instâncias da mesma chave de cabeçalho (por exemplo, Via), o balanceador de carga combinará os valores delas em uma lista separada por vírgulas para uma chave de cabeçalho. Serão agrupados somente cabeçalhos com valores que possam ser representados como uma lista separada por vírgulas. Outros cabeçalhos, como Set-Cookie, nunca são agrupados.

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

Cuidado: o balanceador de carga não verifica endereços IP que precedem <client-ip>,<load-balancer-ip> neste cabeçalho. Os endereços IP anteriores podem conter outros caracteres, incluindo espaços.

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 do Cloud Trace

O recurso de rastreamento não é compatível com os balanceadores de carga de aplicativo. Os balanceadores de carga de aplicativo globais e clássicos adicionam o cabeçalho X-Cloud-Trace-Context se ele não estiver presente. O balanceador de carga de aplicativo externo regional não adiciona esse cabeçalho. Se o cabeçalho X-Cloud-Trace-Context já estiver presente, ele vai passar pelos balanceadores de carga sem modificações. No entanto, nenhum rastro ou intervalo é exportado pelo balanceador de carga.

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. O mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends. Um serviço padrão é definido para processar todas as solicitações que não correspondam a uma regra de host ou regra de correspondência de caminho especificada.

Em algumas situações, como o exemplo de balanceamento de carga entre regiões, é possível não definir nenhuma regra de URL e depender apenas do serviço padrão.

Os mapas de URL oferecem suporte a 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:

• Visão geral do gerenciamento de tráfego para balanceador de carga de aplicativo externo global

• Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais

A tabela a seguir especifica o tipo de mapa de URL exigido pelos balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipo de mapa de URL
Balanceador de carga de aplicativo externo global	Global
Balanceador de carga de aplicativo clássico	Global (com apenas um subconjunto de recursos compatíveis)
Balanceador de carga de aplicativo externo regional	Regional

Certificados SSL

Os balanceadores de carga de aplicativo externos que usam proxies HTTPS de destino exigem chaves privadas e certificados SSL como parte da configuração do balanceador de carga.

• O Google Cloud oferece dois métodos de configuração para atribuir chaves privadas e certificados SSL a destinos de HTTPS: certificados SSL do Compute Engine e Gerenciador de certificados. Para uma descrição de cada configuração, consulte Métodos de configuração de certificado nas informações gerais dos certificados SSL.

• O Google Cloud oferece dois tipos de certificado: autogerenciados e gerenciados pelo Google. Para conferir uma descrição de cada tipo, consulte Tipos de certificado nas informações gerais de certificados SSL.

O tipo de balanceador de carga de aplicativo externo (global, regional ou clássico) determina quais métodos de configuração e tipos de certificado são compatíveis. Para mais detalhes, consulte Certificados e balanceadores de carga do Google Cloud nas informações gerais dos certificados SSL.

Políticas de SSL

As políticas de SSL especificam o conjunto de recursos de SSL que os balanceadores de carga do Google Cloud usam ao negociar SSL com clientes.

Por padrão, o balanceamento de carga HTTPS usa um conjunto de recursos SSL que oferece boa segurança e ampla compatibilidade. Alguns aplicativos exigem mais controle sobre quais versões de SSL e criptografias são usadas nas próprias conexões HTTPS ou SSL. É possível definir uma política de SSL para especificar o conjunto de recursos de SSL que o balanceador de carga usa ao negociar SSL com clientes. Além disso, é possível aplicar essa política de SSL ao proxy HTTPS de destino.

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

Modo balanceador de carga	Políticas de SSL suportadas
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico
Balanceador de carga de aplicativo externo regional

Serviços de back-end

Um serviço de back-end fornece informações de configuração ao balanceador de carga para direcionar solicitações aos back-ends, por exemplo, grupos de instâncias do Compute Engine ou grupos de endpoints de rede (NEGs). Para mais informações sobre os serviços de back-end, consulte Visão geral dos serviços de back-end.

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 de aplicativo externo com um back-end do Compute Engine.

Escopo do serviço de back-end

A tabela a seguir indica qual recurso e escopo do serviço de back-end é usado pelos balanceadores de carga de aplicativo externos:

Modo balanceador de carga	Recurso de serviço de back-end
Balanceador de carga de aplicativo externo global	backendServices (global)
Balanceador de carga de aplicativo clássico	backendServices (global)
Balanceador de carga de aplicativo externo regional	regionBackendServices (regional)

Protocolo para os back-ends

Os serviços de back-end para balanceadores de carga de aplicativo precisam usar um dos seguintes protocolos para enviar solicitações aos back-ends:

• HTTP, que usa HTTP/1.1 e não TLS
• HTTPS, que usa HTTP/1.1 e TLS
• HTTP/2, que usa HTTP/2 e TLS. Não há suporte para HTTP/2 sem criptografia.

O balanceador de carga só usa o protocolo de serviço de back-end especificado para se comunicar com os back-ends. O balanceador de carga não recorre a um protocolo diferente se não conseguir se comunicar com os back-ends usando o protocolo de serviço de back-end especificado.

O protocolo do serviço de back-end não precisa corresponder ao protocolo usado pelos clientes para se comunicar com o balanceador de carga. Por exemplo, os clientes podem enviar solicitações para o balanceador de carga usando HTTP/2, mas o balanceador de carga pode se comunicar com back-ends usando HTTP/1.1 (HTTP ou HTTPS).

Buckets de back-end

Os buckets de back-end direcionam o tráfego recebido para os buckets do Cloud Storage. Para um exemplo de como adicionar um bucket a um balanceador de carga de aplicativo externo, consulte Como configurar um balanceador de carga com buckets de back-end. Para informações gerais sobre o Cloud Storage, consulte O que é o Cloud Storage?

Back-ends

A tabela a seguir especifica os back-ends e recursos relacionados compatíveis com balanceadores de carga de aplicativo externos em cada modo.

Modo do 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 o Cloud CDN^#	Compatível com o IAP^#	Compatível com extensões de serviço
	Grupos de instâncias^†	NEGs por zona^‡	NEGs na Internet	NEGs sem servidor	NEGs híbridos	NEGs do Private Service Connect
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico									Nível Premium
Balanceador de carga de aplicativo externo regional

^*Os back-ends em um serviço de back-end precisam ser do mesmo tipo: todos os grupos de instâncias ou todos do mesmo tipo de NEG. Uma exceção a essa regra é que os NEGs zonais e híbridos GCE_VM_IP_PORT podem ser usados no mesmo serviço de back-end para oferecer suporte a uma arquitetura híbrida.

^† Combinações de grupos de instâncias não gerenciadas, gerenciadas por zona e gerenciadas por região são compatíveis com o mesmo serviço de back-end. Ao usar o escalonamento automático para um grupo gerenciado de instâncias que é um back-end para dois ou mais serviços de back-end, configure a política de escalonamento automático do grupo de instâncias para usar vários indicadores.

^‡ Os NEGs zonais precisam usar endpoints GCE_VM_IP_PORT.

^# O IAP e o Cloud CDN são incompatíveis entre si. Eles não podem ser ativados no mesmo serviço de back-end.

Back-ends e redes VPC

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

Para back-ends de balanceadores de carga de aplicativo externos globais, o seguinte se aplica:

• As instâncias de back-end (para back-ends de grupos de instâncias) e os endpoints de back-end (para back-ends de NEG) podem ser localizados em qualquer rede VPC dentro da mesma organização. As diferentes redes VPC não precisam ser conectadas usando o peering de rede VPC, porque os GFEs se comunicam diretamente com back-ends nas respectivas redes VPC.

• Os buckets do Cloud Storage não estão associados a uma rede VPC. Eles podem ser localizados em qualquer projeto na mesma organização.

  Os balanceadores de carga de aplicativo externos globais também oferecem suporte a ambientes de VPC compartilhada, em que é possível compartilhar redes VPC e os recursos associados entre projetos. No entanto, para balanceadores de carga de aplicativo externos globais, não é necessário configurar a VPC compartilhada para referenciar serviços de back-end ou buckets de back-end de outros projetos na organização.

Para back-ends do balanceador de carga de aplicativo clássico, o seguinte se aplica:

• Todas as instâncias de back-end dos back-ends de grupos de instâncias e todos os endpoints de back-end dos back-ends de NEG precisam estar localizados no mesmo projeto. No entanto, um back-end de grupo de instâncias ou um NEG pode usar uma rede VPC diferente nesse projeto. As diferentes redes VPC não precisam ser conectadas usando o peering de rede VPC, porque os GFEs se comunicam diretamente com back-ends nas respectivas redes VPC.

• Os buckets do Cloud Storage não estão associados a uma rede VPC. No entanto, eles precisam estar localizados no mesmo projeto que o balanceador de carga.

Para back-ends de balanceadores de carga de aplicativo externos regionais, o seguinte se aplica:

• Para grupos de instâncias, NEGs zonais e NEGs de conectividade híbrida, todos os back-ends precisam estar localizados no mesmo projeto e região do serviço de back-end. No entanto, um balanceador de carga pode referenciar um back-end que usa outra rede VPC no mesmo projeto que o serviço de back-end. Esse recurso está em Pré-lançamento. A conectividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada usando o peering de rede VPC, túneis da Cloud VPN, anexos da VLAN do Cloud Interconnect ou um framework do Network Connectivity Center.

  Definição de rede de back-end

  • Para NEGs zonais e híbridos, especifique explicitamente a rede VPC ao criar o NEG.
  • Para grupos gerenciados de instâncias, a rede VPC é definida no modelo de instância.
  • Para grupos não gerenciados de instâncias, a rede VPC do grupo de instâncias é definida para corresponder à rede VPC da interface nic0 da primeira VM adicionada ao grupo de instâncias.

  Requisitos de rede de back-end

  A rede do seu back-end precisa atender a um dos requisitos de rede a seguir:

  • A rede VPC do back-end precisa corresponder exatamente à rede VPC da regra de encaminhamento.

  • A rede VPC do back-end precisa estar conectada à rede VPC da regra de encaminhamento usando o peering de rede VPC. É necessário configurar as trocas de rotas de sub-rede para permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias ou endpoints de back-end.

• A rede VPC do back-end e a rede VPC da regra de encaminhamento precisam ser spokes VPC no mesmo hub do Network Connectivity Center. Os filtros de importação e exportação precisam permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas por instâncias ou endpoints de back-end.

• Para os outros tipos de back-end, todos os back-ends precisam estar localizados na mesma rede e região VPC.

  Os balanceadores de carga de aplicativo externos regionais também oferecem suporte a ambientes de VPC compartilhada, em que você pode compartilhar redes VPC e os recursos associados em vários projetos. Se você quiser que o serviço de back-end e os back-ends do balanceador de carga de aplicativo externo regional estejam em um projeto diferente da regra de encaminhamento, configure o balanceador de carga em um ambiente de VPC compartilhada com referência de serviço entre projetos.

Back-ends e interfaces de rede

Se você usar back-ends de grupos de instâncias, os pacotes serão sempre entregues a nic0. Se você quiser enviar pacotes para várias placas de rede (NIC), use back-ends NEG.

Se você usar back-ends de NEG zonal, os pacotes serão enviados para qualquer interface de rede representada pelo endpoint no NEG. Os endpoints do NEG precisam estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.

Verificações de integridade

Cada serviço de back-end especifica uma verificação de integridade que monitora periodicamente a prontidão dos back-ends para receber uma conexão do balanceador de carga. Isso reduz o risco de as solicitações serem enviadas para back-ends que não possam atender à solicitação. As verificações de integridade não conferem se o aplicativo em si está funcionando.

Para as sondagens de verificação de integridade, é necessário criar uma regra de firewall de permissão de entrada que permita que as sondagens de verificação de integridade alcancem as instâncias de back-end. Normalmente, as sondagens de verificação de integridade são originadas do mecanismo centralizado de verificação de integridade do Google.

Os balanceadores de carga de aplicativo externos regionais que usam back-ends de NEG híbridos são uma exceção a essa regra, porque as verificações de integridade são originadas da sub-rede somente proxy. Para mais detalhes, consulte a Visão geral de NEGs híbridos.

Protocolo de verificação de integridade

Embora não seja obrigatório e nem sempre possível, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao protocolo do 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. Por outro lado, os balanceadores de carga de aplicativo externos regionais que usam back-ends de NEG híbridos não são compatíveis com verificações de integridade do gRPC. 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 das verificações de integridade compatíveis com balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipo de verificação de integridade
Balanceador de carga de aplicativo externo global	Global
Balanceador de carga de aplicativo clássico	Global
Balanceador de carga de aplicativo externo regional	Regional

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

• Visão geral das verificações de integridade
• Como criar verificações de integridade

Regras de firewall

O balanceador de carga requer as seguintes regras de firewall:

• Para os balanceadores de carga de aplicativo 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 de aplicativo externo regional, uma regra de permissão de entrada para permitir que o tráfego da sub-rede somente proxy alcance os 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 de aplicativo externo global e o balanceador de carga de aplicativo clássico, use o Google Cloud Armor para fazer 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 de aplicativo externo global	35.191.0.0/16 130.211.0.0/22 Para tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias e NEGs zonais (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Para tráfego IPv6 para os back-ends: 2600:2d00:1:1::/64 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 de aplicativo clássico	35.191.0.0/16 130.211.0.0/22	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias, NEGs zonais (GCE_VM_IP_PORT) e NEGs de conectividade híbrida (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 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 de aplicativo externo regional	35.191.0.0/16 130.211.0.0/22 Para tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64 Não é necessário colocar intervalos de sondagem de verificação de integridade do Google na lista de permissões para NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário usar lista de permissões dos intervalos de sondagem de verificação de integridade do Google para NEGs zonais.	A sub-rede somente proxy que você configura.

Importante: permita pacotes dos intervalos completos de verificação de integridade. Se a regra de firewall permitir pacotes de apenas um subconjunto dos intervalos, poderão ocorrer falhas na verificação de integridade porque o balanceador de carga não pode se comunicar com os back-ends. Isso gera respostas HTTP 502.

Suporte ao GKE

O GKE usa balanceadores de carga de aplicativo externos das seguintes maneiras:

• As gateways externas criadas usando o controlador de gateway do GKE podem usar qualquer modo de um balanceador de carga de aplicativo externo. Você controla o modo do balanceador de carga escolhendo uma GatewayClass. O controlador do Gateway do GKE sempre usa back-ends de NEG zonal GCE_VM_IP_PORT.

• As entradas externas criadas usando o controlador de Entrada do GKE são sempre balanceadores de carga de aplicativo clássico. O controlador de Ingress do GKE prefere usar back-ends NEG zonais GCE_VM_IP_PORT, embora os back-ends de grupo de instâncias também sejam aceitos.

• É possível usar o NEG zonal GCE_VM_IP_PORT criado e gerenciado pelos serviços do GKE como back-ends para qualquer balanceador de carga de aplicativo ou balanceador de carga de rede proxy. Para mais informações, consulte Balanceamento de carga nativo de contêiner por meio de NEGs zonais independentes.

Arquitetura da VPC compartilhada

Os balanceadores de carga de aplicativo externos são compatíveis com redes que usam a VPC compartilhada. A VPC compartilhada permite que as organizações conectem recursos de vários projetos a uma rede VPC comum para comunicarem-se umas com as outras de maneira segura e eficiente usando os endereços IP internos dessa rede. Se você ainda não conhece a VPC compartilhada, leia a Visão geral da VPC compartilhada.

Há muitas maneiras de configurar um balanceador de carga de aplicativo 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 de aplicativo externo global	Se você estiver usando uma rede VPC compartilhada para seus back-ends, crie a rede necessária no projeto host da VPC compartilhada. 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. Esse projeto pode ser o projeto host ou um projeto de serviços.	Você tem estas opções: Crie serviços de back-end, buckets de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end, buckets de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) em projetos de serviço. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos. Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. As verificações de integridade associadas aos serviços de back-end precisam ser definidas no mesmo projeto que o serviço de back-end. Os back-ends podem ser parte de uma rede VPC compartilhada do projeto host ou de uma rede VPC independente, ou seja, uma rede VPC não compartilhada no projeto de serviços.
Balanceador de carga de aplicativo 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 host ou de serviço dos back-ends.	Um serviço de back-end global precisa ser definido no mesmo projeto host ou 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 de aplicativo 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: Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end compatíveis) em quantos projetos de serviço forem necessários. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos. Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. 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.

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

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

O diagrama de arquitetura a seguir mostra uma implantação de VPC compartilhada padrão em que todos os componentes e back-ends do balanceador de carga estão em um projeto de serviço. Todos os balanceadores de carga de aplicativo oferecem suporte a esse tipo de implantação.

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

Balanceador de carga de aplicativo externo regional em rede VPC compartilhada

Back-ends sem servidor em um ambiente de VPC compartilhada

Para um balanceador de carga que usa um back-end NEG sem servidor, o serviço de back-end do Cloud Run ou do Cloud Functions precisa estar no mesmo projeto que o NEG sem servidor.

Além disso, para o balanceador de carga de aplicativo 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

A referência de serviços entre projetos é um modelo de implantação em que o front-end e o mapa de URL do balanceador de carga estão em um projeto, e o serviço de back-end e os back-ends do balanceador de carga estão em um projeto diferente.

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ço 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. Ambos podem ser conectados por 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 função do usuário dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser).

O suporte à referência de serviço entre projetos varia de acordo com o tipo de balanceador de carga:

• Para balanceadores de carga de aplicativo externos globais, o front-end e o mapa de URL do balanceador de carga podem fazer referência a serviços de back-end ou buckets de back-end de qualquer projeto na mesma organização. Não há restrições de rede VPC. Embora seja possível usar um ambiente de VPC compartilhada para configurar uma implantação entre projetos, conforme mostrado neste exemplo, isso não é um requisito.

• Para balanceadores de carga de aplicativo externos regionais, é necessário criar o balanceador de carga em um ambiente de VPC compartilhada. O front-end e o mapa de URL do balanceador de carga precisam estar em um projeto host ou de serviço, e os serviços e back-ends de back-end do balanceador de carga podem ser distribuídos entre projetos host ou de serviço no mesmo ambiente de VPC compartilhada.

Para saber como configurar a VPC compartilhada para um balanceador de carga de aplicativo externo global, com e sem a referência de serviço entre projetos, consulte Configurar um balanceador de carga de aplicativo externo global com VPC compartilhada.

Para saber como configurar a VPC compartilhada para um balanceador de carga de aplicativo externo regional, com e sem a referência de serviço entre projetos, consulte Configurar um balanceador de carga de aplicativo externo regional com VPC compartilhada

Limitações conhecidas com referências a serviços entre projetos

• A referência de serviço entre projetos pode ser usada com grupos de instâncias, NEGs sem servidor e a maioria dos outros tipos de back-ends compatíveis. No entanto, as seguintes limitações se aplicam:

  • Com os balanceadores de carga de aplicativo globais externos, não é possível referenciar um serviço de back-end entre projetos se ele tiver back-ends NEG sem servidor com o App Engine.

  • Com balanceadores de carga de aplicativo externos regionais, não é possível referenciar um serviço de back-end entre projetos se o serviço de back-end tiver back-ends NEG da Internet regionais.
• A referência de serviço entre projetos não é compatível com o balanceador de carga de aplicativo clássico.
• O Google Cloud não diferencia recursos (por exemplo, serviços de back-end) usando o mesmo nome em vários projetos. Portanto, ao usar a referência de serviços entre projetos, recomendamos o uso de nomes exclusivos de serviço de back-end em todos os projetos da organização.

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

Confira um exemplo de implantação de VPC compartilhada em que o front-end e o mapa de URL 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 e balanceador de carga do balanceador de carga em projetos de serviço diferentes

Exemplo 2: front-end do balanceador de carga no projeto host e back-ends em projetos de serviço

Confira um exemplo de implantação de VPC compartilhada em que 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 (clique para ampliar).

Exemplo 3: front-end e back-end do balanceador de carga em projetos diferentes

Confira um exemplo de implantação em que o front-end e o mapa de URL do balanceador de carga de aplicativo externo global são criados em um projeto diferente do serviço de back-end e dos back-ends do balanceador de carga. Esse tipo de implantação não usa a VPC compartilhada e é compatível apenas com balanceadores de carga de aplicativo externos globais.

Front-end e balanceadores de carga em projetos diferentes (clique para ampliar).

Como funcionam as conexões

Conexões do balanceador de carga de aplicativo externo global

Os balanceadores de carga de aplicativo 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.

Observação: para NEGs da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IP, dependendo do tipo de NEG (global ou regional). Para mais informações, consulte Como autenticar solicitações.

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 do sinal de atividade HTTP do cliente de 610 segundos e um valor padrão do tempo limite de sinal de atividade do back-end de 600 segundos. É possível atualizar o tempo limite do sinal de atividade HTTP do cliente, mas o valor do tempo limite do sinal de atividade do back-end é fixo. É 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 tempo limite de inatividade TCP não são a mesma coisa. Saiba mais em Tempos limite e novas tentativas.

Para garantir que o tráfego tenha a carga balanceada uniformemente, o balanceador de carga pode fechar uma conexão TCP enviando um pacote FIN ACK depois de concluir uma resposta que inclui um cabeçalho Connection: close ou pode emitir um frame HTTP/2 GOAWAY depois de concluir uma resposta. Esse comportamento não interfere em solicitações ou respostas ativas.

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.

Para mais informações, consulte Como funcionam os balanceadores de carga de aplicativo externos no guia de soluções: otimizações de capacidade de aplicativos com balanceamento de carga global.

Conexões externas regionais do balanceador de carga de aplicativo

O balanceador de carga de aplicativo externo regional é um serviço gerenciado implementado no proxy Envoy. O balanceador de carga de aplicativo externo regional usa uma sub-rede compartilhada chamada sub-rede somente 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 Envoy define o tempo limite do sinal de atividade HTTP do cliente e o tempo limite do sinal de atividade do back-end como um valor padrão de 600 segundos cada. É possível atualizar o tempo limite do sinal de atividade HTTP do cliente, mas o valor do tempo limite do sinal de atividade do back-end é fixo. É 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 usando o protocolo HTTP 1.1 ou HTTP/2.
• Quando HTTPS é usado, o padrão dos clientes modernos é HTTP/2. Isso é controlado no cliente, não no balanceador de carga HTTPS.
• Não é possível desativar o HTTP/2 alterando a configuração 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.
• Os balanceadores de carga de aplicativo externos são compatíveis com a resposta HTTP/1.1 100 Continue.

Confira a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceador de carga de aplicativo 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 os balanceadores de carga de aplicativo 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.

Observação: para NEGs da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IP. Para mais informações, consulte Como autenticar solicitações.

Para os balanceadores de carga de aplicativo 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.

Caminhos de roteamento especiais

O Google Cloud usa rotas especiais não definidas na rede VPC para rotear pacotes para os seguintes tipos de tráfego:

• Para verificações de integridade, exceto as verificações de integridade distribuídas do Envoy. Para mais informações, consulte Caminhos para verificações de integridade.

• Entre os GFEs e os back-ends dos balanceadores de carga de aplicativo externos globais e clássicos. Para mais informações, consulte Caminhos entre o Google Front Ends e os back-ends.

O Google Cloud usa rotas de sub-rede para sub-redes somente proxy para rotear pacotes para os seguintes tipos de tráfego:

• Ao usar verificações de integridade distribuídas do Envoy.

Para balanceadores de carga de aplicativo 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

Os GFEs têm várias portas abertas para oferecer suporte a outros serviços do Google, executados na mesma arquitetura. Ao executar uma verificação de portas, é possível ver outras portas abertas para outros serviços do Google em execução nos GFEs.

Os balanceadores de carga baseados no GFE (balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos) sempre mostram as portas 80 e 443 como abertas (com qualquer outra porta que você tenha configurado nas regras de encaminhamento do balanceador de carga). No entanto, se você não tiver configurado uma regra de encaminhamento para a porta 80 ou 443, todas as conexões enviadas para essas portas serão recusadas. Por outro lado, os balanceadores de carga de aplicativo externos regionais são implementados usando proxies Envoy e não mostram portas abertas extras durante uma verificação.

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 apenas para portas em que você configurou uma regra de encaminhamento. 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. Os pacotes enviados para um endereço IP ou uma porta diferente não são enviados para os back-ends.

  Os GFEs implementam recursos de segurança, como o Google Cloud Armor. Com o Google Cloud Armor Standard, os GFEs oferecem proteção sempre ativada contra ataques DDoS volumétricos e baseados em protocolo e inundações de SYN. Essa proteção está disponível mesmo que você não tenha configurado explicitamente o Google Cloud Armor. Você só vai receber cobranças se configurar políticas de segurança ou se inscrever no Managed Protection Plus.

• 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 definidas bloqueiam o tráfego dos GFEs para as VMs 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

A tabela a seguir resume como término de TLS é processada pelos balanceadores de carga de aplicativo externos.

Modo balanceador de carga	término de TLS
Balanceador de carga de aplicativo externo global	O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo.
Balanceador de carga de aplicativo clássico	O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo.
Balanceador de carga de aplicativo 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

Os balanceadores de carga de aplicativo externos são compatíveis com os seguintes tipos de tempo limite para tráfego HTTP/HTTPS:

Tipo e descrição de tempo limite	Valores padrão	Suporte a valores de tempo limite personalizados
		Global	Clássico	Regional
Tempo limite do serviço de back-end^1 Tempo limite de solicitação e resposta. Representa o tempo máximo permitido entre o balanceador de carga enviando o primeiro byte de uma solicitação para o back-end e o back-end retornando o último byte da resposta HTTP para o balanceador de carga. Se o back-end não retornar toda a resposta HTTP ao balanceador de carga dentro desse limite de tempo, os dados de resposta restantes serão descartados.	Para NEGs sem servidor em um serviço de back-end: 60 minutos Para todos os outros tipos de back-end em um serviço de back-end: 30 segundos Para buckets de back-end: 24 horas (86.400 segundos)
Tempo limite do sinal de atividade HTTP do cliente O tempo máximo que a conexão TCP entre um cliente e o proxy do balanceador de carga pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP. Para os balanceadores de carga de aplicativo externos globais e clássicos, o proxy do balanceador de carga é um GFE de primeira camada. Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.	Para um balanceador de carga de aplicativo externo global e um balanceador de carga de aplicativo clássico: 610 segundos Para um balanceador de carga de aplicativo externo regional: 600 segundos
Tempo limite do sinal de atividade HTTP do back-end O tempo máximo que a conexão TCP entre o proxy do balanceador de carga e um back-end pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP. Para os balanceadores de carga de aplicativo externos globais e clássicos, o proxy do balanceador de carga é um GFE de segunda camada. Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.	Para serviços de back-end: 10 minutos (600 segundos) Para buckets de back-end: 6 minutos (360 segundos)
Tempo limite de inatividade da sessão QUIC O tempo máximo que uma sessão QUIC pode ficar inativa entre o cliente (downstream) e o GFE de um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico.	Para balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos: O tempo limite de inatividade da sessão QUIC é o mínimo de um destes: tempo limite de inatividade do cliente ou tempo limite de inatividade do GFE (300 segundos). O tempo limite de inatividade do GFE é fixo em 300 segundos. O tempo limite de inatividade do cliente pode ser configurado.

¹Não configurável para back-ends de NEG sem servidor. Não é configurável para buckets de back-end.

Tempo limite do serviço de back-end

O tempo limite do serviço de back-end configurável representa o tempo máximo que o balanceador de carga aguarda até o back-end processar uma solicitação HTTP e retornar a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor padrão do tempo limite do serviço de back-end é de 30 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 de 90 segundos, o balanceador de carga aguardará o back-end enviar todo o arquivo de 500 MB em até 90 segundos. É possível configurar o tempo limite do serviço de back-end como insuficiente para que o back-end envie a resposta HTTP completa. Nessa situação, se o balanceador de carga tiver recebido do back-end pelo menos os cabeçalhos de resposta HTTP, ele 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.

Exceto para WebSockets, defina o tempo limite do serviço de back-end como o período mais longo que você espera ser necessário para o back-end processar uma resposta HTTP. Aumente o tempo limite do serviço de back-end se o software em execução no back-end precisar de mais tempo para processar uma solicitação HTTP e retornar toda a resposta. Por exemplo, aumente o tempo limite se você receber respostas HTTP 408 com jsonPayload.statusDetail client_timed_out.

O tempo limite do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. Valores maiores não são opções de configuração possíveis. O Google Cloud também não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. No caso dos balanceadores de carga de aplicativo globais e clássicos, os GFEs impõem um tempo limite máximo de serviço de back-end de 86,400 segundos (um dia). Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.

Para configurar o tempo limite do serviço de back-end, use um dos seguintes métodos:

Console

Modifique o campo Tempo limite do serviço de back-end do balanceador de carga.

gcloud

Use o comando gcloud compute backend-services update para modificar o parâmetro --timeout do recurso de serviço de back-end.

API

Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, modifique o parâmetro timeoutSec para o recurso backendServices global.

Para um balanceador de carga de aplicativo externo regional, modifique o parâmetro timeoutSec para o recurso regionBackendServices.

Os tempos limite de conexão do WebSocket nem sempre são iguais aos tempos limite do serviço de back-end. O tempo limite da conexão WebSocket depende do tipo de balanceador de carga:

Modo balanceador de carga	Valores padrão	Descrição do tempo limite para websockets
Balanceador de carga de aplicativo externo global	Tempo limite do serviço de back-end: 30 segundos	As conexões WebSocket ativas não usam o tempo limite do serviço de back-end configurado do balanceador de carga. As conexões são fechadas automaticamente após 24 horas (86.400 segundos). Esse limite de 24 horas é fixo e substitui o tempo limite do serviço de back-end se ele for maior que 24 horas. As conexões WebSocket inativas são fechadas após o tempo limite do serviço de back-end. Não recomendamos valores de tempo limite de serviço de back-end maiores que 24 horas (86.400 segundos), porque o Google Cloud reinicia periodicamente os GFEs para atualizações de software e outras manutenções de rotina. O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção. Quanto maior for o valor do tempo limite do serviço de back-end, maior será a probabilidade de o Google Cloud encerrar as conexões TCP para manutenção.
Balanceador de carga de aplicativo clássico	Tempo limite do serviço de back-end: 30 segundos	As conexões WebSocket, inativas ou ativas, são fechadas automaticamente após o tempo limite do serviço de back-end. Não recomendamos valores de tempo limite de serviço de back-end maiores que 24 horas (86.400 segundos), porque o Google Cloud reinicia periodicamente os GFEs para atualizações de software e outras manutenções de rotina. O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção. Quanto maior for o valor do tempo limite do serviço de back-end, maior será a probabilidade de o Google Cloud encerrar as conexões TCP para manutenção.
Balanceador de carga de aplicativo externo regional	Tempo limite do serviço de back-end: 30 segundos	As conexões WebSocket ativas não usam o tempo limite do serviço de back-end do balanceador de carga. As conexões WebSocket inativas são fechadas após o tempo limite do serviço de back-end. O Google Cloud reinicia ou altera periodicamente o número de tarefas de software do Envoy em exibição. Quanto maior o valor do tempo limite do serviço de back-end, maiores as chances de as tarefas do Envoy reiniciarem ou encerrarem conexões TCP.

Os balanceadores de carga de aplicativo externos regionais usam o parâmetro routeActions.timeout configurado dos mapas de URL e ignoram o tempo limite do serviço de back-end. Quando routeActions.timeout não está configurado, o valor do tempo limite do serviço de back-end é usado. Quando routeActions.timeout é fornecido, o tempo limite do serviço de back-end é ignorado, e o valor de routeActions.timeout é usado como o tempo limite de solicitação e resposta.

Tempo limite do sinal de atividade HTTP do cliente

O tempo limite do sinal de atividade HTTP do cliente representa a quantidade máxima de tempo que uma conexão TCP pode ficar ociosa entre o cliente (downstream) e um dos seguintes tipos de proxies:

• Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico: um front-end do Google de primeira camada

• Para um balanceador de carga de aplicativo externo regional: um proxy Envoy

Um tempo limite de sinal de atividade HTTP representa o tempo limite de inatividade TCP das conexões TCP subjacentes. O tempo limite do sinal de atividade HTTP do cliente não se aplica a WebSockets.

• Para um balanceador de carga de aplicativo externo global, o valor padrão é de 610 segundos. É possível configurar o tempo limite do sinal de atividade HTTP do cliente com um valor entre 5 e 1.200 segundos.
• Para um balanceador de carga de aplicativo clássico, o tempo limite do sinal de atividade HTTP do cliente é fixo em 610 segundos.
• Para um balanceador de carga de aplicativo externo regional, o valor padrão é de 600 segundos. É possível configurar o tempo limite do sinal de atividade HTTP do cliente com um valor entre 5 e 600 segundos.

Para configurar o parâmetro de tempo limite do sinal de atividade, use um dos seguintes métodos:

Console

Modifique o campo Tempo limite do sinal de atividade HTTP da configuração de front-end do balanceador de carga.

gcloud

Use o comando gcloud compute target-http-proxies update ou o comando gcloud compute target-https-proxies update para modificar o parâmetro --http-keep-alive-timeout-sec do proxy HTTP de destino ou do recurso de proxy HTTPS de destino.

Observação:

Para um balanceador de carga de aplicativo externo regional, não é possível atualizar o parâmetro de tempo limite de keepalive de um proxy HTTP(S) de destino regional diretamente. Para atualizar o parâmetro de tempo limite de keepalive de um proxy de destino regional, faça o seguinte:

1. Crie um novo proxy de destino com as configurações de tempo limite desejadas.
2. Espelhe todas as outras configurações do proxy de destino atual no novo. Para proxies HTTPS de destino, isso inclui vincular certificados SSL ou mapas de certificados ao novo proxy de destino.
3. Atualize as regras de encaminhamento para apontar para o novo proxy de destino.
4. Exclua o proxy de destino antigo.

API

Modifique o parâmetro httpKeepAliveTimeoutSec para o recurso targetHttpProxies ou o recurso targetHttpsProxies.

Observação:

Para um balanceador de carga de aplicativo externo regional, não é possível atualizar o parâmetro de tempo limite de keepalive de um proxy HTTP(S) de destino regional diretamente. Para atualizar o parâmetro de tempo limite de keepalive de um proxy de destino regional, faça o seguinte:

1. Crie um novo proxy de destino com as configurações de tempo limite desejadas.
2. Espelhe todas as outras configurações do proxy de destino atual no novo. Para proxies HTTPS de destino, isso inclui vincular certificados SSL ou mapas de certificados ao novo proxy de destino.
3. Atualize as regras de encaminhamento para apontar para o novo proxy de destino.
4. Exclua o proxy de destino antigo.

O tempo limite do sinal de atividade do cliente HTTP do balanceador de carga precisa ser maior que o tempo limite do sinal de atividade HTTP (TCP inativo) usado por clientes downstream ou proxies. Se um cliente downstream tiver o tempo limite do sinal de atividade HTTP (TCP inativo) maior do que o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga, ocorrerá uma possível disputa. Da perspectiva de um cliente downstream, uma conexão TCP estabelecida pode ficar inativa por mais tempo do que o balanceador de carga permite. Isso significa que o cliente downstream pode enviar pacotes depois que o balanceador de carga considerar a conexão TCP encerrada. Quando isso acontece, o balanceador de carga responde com um pacote de redefinição (RST) TCP.

Tempo limite do sinal de atividade HTTP do back-end

Os balanceadores de carga de aplicativo externos são proxies que usam pelo menos duas conexões TCP:

• Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, há uma primeira conexão TCP entre o cliente (downstream) e um GFE de primeira camada. Os GFEs de primeira camada se conectam a GFEs de segunda camada e, em seguida, os GFEs de segunda camada abrem uma segunda conexão TCP com os back-ends.

• Para um balanceador de carga de aplicativo externo regional, há uma primeira conexão TCP entre o cliente (downstream) e um proxy Envoy. Em seguida, o proxy Envoy abre uma segunda conexão TCP com os back-ends.

As conexões TCP secundárias do balanceador de carga talvez não sejam encerradas após cada solicitação. Elas podem permanecer abertas para lidar com várias solicitações e respostas HTTP. O tempo limite do sinal de atividade HTTP do back-end define o tempo limite de inatividade do TCP entre o balanceador de carga e os back-ends. O tempo limite do sinal de atividade HTTP do back-end não se aplica a WebSockets.

O tempo limite do sinal de atividade do back-end é fixado em 10 minutos (600 segundos) e não pode ser alterado. O tempo limite do sinal de atividade do back-end do balanceador de carga precisa ser menor que o tempo limite do sinal de atividade usado pelo software em execução nos back-ends. Isso evita uma disputa em que o sistema operacional dos back-ends pode encerrar conexões TCP com uma redefinição (RST) TCP. Como o tempo limite do sinal de atividade do back-end do balanceador de carga não é configurável, é necessário configurar o software do back-end para que o valor de tempo limite do sinal de atividade HTTP (TCP inativo) seja maior que 600 segundos.

A tabela a seguir lista as alterações necessárias para modificar os valores de tempo limite do sinal de atividade para software servidor da Web comum.

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;

Tempo limite de inatividade da sessão QUIC

O tempo limite de inatividade da sessão QUIC representa o tempo máximo que essa sessão pode ficar inativa entre o cliente e o GFE de um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico.

O valor do tempo limite de inatividade da sessão QUIC é definido como o mínimo de um destes: tempo limite de inatividade do cliente ou tempo limite de inatividade do cliente do GFE (300 segundos). O tempo limite de inatividade do GFE é fixo em 300 segundos. O tempo limite de inatividade do cliente pode ser configurado.

Novas tentativas

A compatibilidade com a lógica de repetição depende do modo do balanceador de carga de aplicativo externo.

Modo balanceador de carga	Repetir lógica
Balanceador de carga de aplicativo 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 pode ser configurado usando a política é 25. O perTryTimeout máximo configurável é de 24 horas. Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 (retryConditions=["gateway-error"]) serão repetidas uma vez. As solicitações HTTP POST não são repetidas. As solicitações repetidas geram apenas uma entrada de registro como resposta final.
Balanceador de carga de aplicativo clássico	Não é possível alterar a política de novas tentativas de conexão. As solicitações HTTP POST não sã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 repetirá uma solicitação GET com falha se a primeira solicitação falhar antes de receber cabeçalhos de resposta da instância de back-end. As solicitações repetidas geram apenas uma entrada de registro como resposta final. Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga de aplicativo externo. Solicitações malsucedidas resultam em um balanceador de carga sintetizando uma resposta HTTP 502.
Balanceador de carga de aplicativo externo regional	Configurável usando uma política de nova tentativa no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. O número máximo de novas tentativas que pode ser configurado usando a política é 25. O perTryTimeout máximo configurável é de 24 horas. Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 serão repetidas uma vez. As solicitações HTTP POST não sã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 as seguintes solicitações para conformidade com o HTTP/1.1:

• Não é possível analisar a primeira linha da solicitação.
• Falta o delimitador dois-pontos (:) 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á vários cabeçalhos de comprimento 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.

Processamento de solicitações

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 balanceadores de carga de aplicativo externos.
• 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 ele não é usado para permitir conexões WebSocket.Upgrade
• A versão do HTTP é desconhecida.

Processamento de respostas

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 balanceadores de carga de aplicativo externos.
• A versão do HTTP é desconhecida.

Ao processar a solicitação e a resposta, o balanceador de carga pode remover ou substituir os cabeçalhos hop-by-hop no HTTP/1.1 antes de encaminhar para o destino pretendido.

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 para medir a carga de back-end e uma capacidade de destino. Os balanceadores de carga de aplicativo externos são compatíveis 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 de aplicativo 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 de aplicativo externo global, o balanceamento de carga é de duas camadas. 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).

Para o balanceador de carga clássico do aplicativo, 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.

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

Balanceadores de carga de aplicativo externos baseados no GFE usam o seguinte processo para distribuir solicitações recebidas:

1. Do cliente para o GFE de primeira camada. Os roteadores de borda divulgam o endereço IP externo da regra de encaminhamento nas bordas da rede do Google. Cada divulgação lista um próximo salto para um sistema de balanceamento de carga de camada 3/4 (Maglev). Os sistemas Maglev encaminham o tráfego para o Google Front End (GFE) de primeira camada.
   • Ao usar o nível Premium, o Google divulga o endereço IP do seu balanceador de carga de todos os pontos de presença em todo o mundo. Cada endereço IP do balanceador de carga é anycast global.
   • Ao usar o nível Standard, o Google divulga o endereço IP do balanceador de carga de pontos de presença associados à região da regra de encaminhamento. O balanceador de carga usa um endereço IP externo regional. Ao usar uma regra de encaminhamento de nível Standard, você se limita a grupo de instâncias e back-ends de NEG zonal na mesma região da regra de encaminhamento do balanceador de carga.
2. Do GFE de primeira camada para o GFE de segunda camada. O GFE de primeira camada encerra o TLS, se necessário, e depois encaminha o tráfego para os GFEs de segunda camada de acordo com este processo:
   • Os GFEs de primeira camada analisam o mapa de URLs e selecionam um serviço ou bucket de back-end.
   • Para serviços de back-end com NEGs da Internet, os GFEs de primeira camada selecionam um gateway de encaminhamento externo de segunda camada que está em colocation com o GFE de primeira camada. O gateway de encaminhamento envia solicitações para o endpoint do NEG na Internet. Isso conclui o processo de distribuição de solicitações para NEGs da Internet.
   • Para serviços de back-end com NEGs sem servidor e NEGs do Private Service Connect (PSC), e buckets de back-end de região única, os GFEs de primeira camada selecionam um GFE de segunda camada na região correspondente à do NEG ou bucket. Para buckets multirregionais do Cloud Storage, os GFEs de primeira camada selecionam GFEs de segunda camada na região do bucket ou em uma região o mais próxima possível do bucket multirregional (definido pelo tempo de retorno da rede).
   • Para serviços de back-end com grupos de instâncias, NEGs zonais com endpoints GCE_VM_IP_PORT e NEGs híbridos, o sistema de gerenciamento de capacidade do Google informa aos GFEs de primeira camada a capacidade usada e configurada de cada back-end. A capacidade configurada de um back-end é definida pelo modo de balanceamento, a capacidade desejada do modo de balanceamento e o escalonador de capacidade.
     • Nível Standard: os GFEs de primeira camada selecionam um GFE de segunda camada na região que contém os back-ends.
     • Nível Premium: os GFEs de primeira camada selecionam GFEs de segunda camada de um conjunto de regiões aplicáveis. As regiões aplicáveis são todas aquelas em que os back-ends foram configurados, exceto as regiões com back-ends configurados com capacidade zero. Os GFEs de primeira camada selecionam o GFE de segunda camada mais próximo em uma região aplicável (definido pelo tempo de retorno da rede). Se os back-ends estiverem configurados em duas ou mais regiões, os GFEs de primeira camada poderão distribuir solicitações para outras regiões aplicáveis se uma região de primeira escolha estiver cheia. A distribuição para outras regiões é possível quando todos os back-ends na região de primeira escolha estão no limite da capacidade.
3. Os GFEs de segunda camada selecionam back-ends. Os GFEs de segunda camada estão localizados em zonas de uma região. Eles usam o seguinte processo para selecionar um back-end:
   • Para serviços de back-end com NEGs sem servidor, NEGs do Private Service Connect e buckets de back-end, os GFEs de segunda camada encaminham solicitações para os sistemas de produção do Google. Isso conclui o processo de distribuição de solicitações para esses back-ends.

   • Para serviços de back-end com grupos de instâncias, NEGs zonais com endpoints GCE_VM_IP_PORT e NEGs híbridos, os sistemas de sondagem de verificação de integridade do Google informam aos GFEs de segunda camada sobre o status da verificação de integridade dos endpoints ou das instâncias de back-end.

     Somente nível Premium: se o GFE de segunda camada não tiver endpoints ou instâncias de back-end íntegros na região, ele poderá enviar solicitações para outro GFE de segunda camada em uma região aplicável diferente com back-ends configurados. A distribuição entre GFEs de segunda camada em diferentes regiões não esgota todas as combinações possíveis entre regiões. Se você precisar direcionar o tráfego para longe dos back-ends em uma região específica, em vez de configurar os back-ends para que falhem nas verificações de integridade, defina o escalonador de capacidade do back-end como zero para que o GFE de primeira camada exclua a região durante a etapa anterior.

   Em seguida, o GFE de segunda camada direciona as solicitações para endpoints ou instâncias de back-end em zonas dentro da região dele, conforme discutido na próxima etapa.

4. O GFE de segunda camada seleciona uma zona. Por padrão, os GFEs de segunda camada usam o algoritmo WATERFALL_BY_REGION, em que cada GFE de segunda camada prefere selecionar endpoints ou instâncias de back-end na mesma zona que contém o GFE de segunda camada. Como WATERFALL_BY_REGION minimiza o tráfego entre zonas, com baixas taxas de solicitação, cada GFE de segunda camada pode enviar solicitações exclusivamente para back-ends na mesma zona que o próprio GFE de segunda camada.

   Somente para balanceadores de carga de aplicativo globais externos, os GFEs de segunda camada podem ser configurados para que usem um dos seguintes algoritmos alternativos com um serviceLbPolicy:

   • SPRAY_TO_REGION: os GFEs de segunda camada não preferem selecionar endpoints ou instâncias de back-end na mesma zona que o GFE de segunda camada. Os GFEs de segunda camada tentam distribuir o tráfego para todos os endpoints ou instâncias de back-end em todas as zonas da região. Isso pode levar a uma distribuição mais uniforme da carga, à custa do aumento do tráfego entre as zonas.
   • WATERFALL_BY_ZONE: os GFEs de segunda camada preferem expressamente selecionar instâncias de back-end ou endpoints na mesma zona que o GFE de segunda camada. Os GFEs de segunda camada só direcionam solicitações para back-ends em zonas diferentes depois que todos os back-ends na zona atual atingirem as capacidades configuradas.
5. O GFE de segunda camada seleciona instâncias ou endpoints dentro da zona. Por padrão, um GFE de segunda camada distribui solicitações entre back-ends de maneira round-robin. Somente para balanceadores de carga de aplicativo externos globais, é possível alterar isso usando uma política de localidade de balanceamento de carga (localityLbPolicy). Essa política se aplica apenas aos back-ends dentro da zona selecionada discutida na etapa anterior.

Balanceador de carga de aplicativo externo regional

Para balanceadores de carga de aplicativo 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:

• Modos de balanceamento
• Política de localidade do balanceamento de carga (documentação da API de serviço de back-end regional).

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 funciona melhor quando o modo de balanceamento é definido como solicitações por segundo (RPS).

Os balanceadores de carga de aplicativo externos oferecem os seguintes tipos de afinidade da sessão:

• NONE. A afinidade de sessão não está definida para o balanceador de carga.
• Afinidade de IP do cliente
• Afinidade de cookie gerado
• Afinidade do campo de cabeçalho
• Afinidade de cookie HTTP
• Afinidade da sessão com estado baseada em cookies

A tabela a seguir resume as opções de afinidade da sessão compatíveis com os balanceadores de carga de aplicativo externos:

Modo balanceador de carga	Opções de afinidade de sessão
	Nenhum	IP do cliente	Cookie gerado	Campo de cabeçalho	Cookie HTTP	Cookie com estado
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico
Balanceador de carga de aplicativo externo regional

Alta disponibilidade e failover

A alta disponibilidade e o failover em balanceadores de carga de aplicativo externos podem ser configurados no nível do balanceador de carga. Isso é feito criando balanceadores de carga de aplicativo externos regionais em qualquer região em que você precisa de backup.

A tabela a seguir descreve o comportamento de failover.

Modo balanceador de carga	Métodos de failover
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico	É possível configurar uma configuração de failover ativa-passiva em que o tráfego é transferido para um balanceador de carga de aplicativo externo regional de backup. Você usa as verificações de integridade para detectar falhas e as políticas de roteamento do Cloud DNS para rotear o tráfego quando o failover é acionado.
Balanceador de carga de aplicativo externo regional	Use um dos seguintes métodos para garantir uma implantação altamente disponível: É possível configurar uma configuração de failover ativa-passiva em que o tráfego é transferido para um balanceador de carga de aplicativo externo regional de backup. Você usa as verificações de integridade para detectar falhas e uma política de roteamento de failover do Cloud DNS para rotear o tráfego quando o failover é acionado por verificações de integridade com falha. Para mais detalhes, consulte Failover para balanceadores de carga de aplicativo externos. É possível configurar um failover ativo-ativo em que você implanta vários balanceadores de carga de aplicativo externos regionais individuais em regiões que determinam o melhor suporte ao tráfego do aplicativo. Você usa uma política de roteamento de geolocalização do Cloud DNS para encaminhar o tráfego para a região apropriada com base na origem da solicitação do cliente. Também é possível usar as verificações de integridade para detectar interrupções e rotear o tráfego apenas para os balanceadores de carga íntegros. Para detalhes, consulte Alta disponibilidade para balanceadores de carga de aplicativo externos regionais.

Suporte a HTTP/2

HTTP/2 é uma revisão importante do protocolo HTTP/1. O HTTP/2 é compatível com conexões entre clientes e o balanceador de carga de aplicativo externo e para conexões entre o balanceador de carga e os back-ends dele.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS. Mesmo que um balanceador de carga esteja configurado para usar HTTPS, os clientes modernos usam HTTP/2 como padrão. Isso é controlado no lado do cliente, não no balanceador de carga.

Se um cliente não oferecer suporte a HTTP/2 e o balanceador de carga estiver configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end, o balanceador de carga ainda poderá negociar uma conexão HTTPS ou aceitar solicitações HTTP não seguras , Essas solicitações HTTPS ou HTTP são transformadas pelo balanceador de carga para fazer proxy das solicitações por HTTP/2 para as instâncias de back-end.

Para usar HTTP/2, ative o TLS nos seus back-ends. Saiba mais em Criptografia do balanceador de carga nos back-ends.

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 divulgado 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. Como resultado, talvez você veja altas latências de back-end porque as conexões de back-end são feitas com mais frequência.
• 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 Google Cloud. Se o endpoint do gRPC retornar um erro, os registros do balanceador de carga e os dados de monitoramento vão informar o código de resposta HTTP OK 200.

Suporte a HTTP/3

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 de aplicativo externo, o Cloud CDN e os clientes.

A compatibilidade com o Google QUIC (também conhecido como gQUIC) foi removido em abril de 2023 e foi substituído pelo HTTP/3 em vez do IETF QUIC, que é um padrão IETF e tem desempenho melhor que o gQUIC.

Especificamente:

• O IETF QUIC é um protocolo de camada de transporte que oferece controle de congestionamento e confiabilidade semelhantes ao TCP, usa TLS 1.3 para segurança e melhora o desempenho.
• 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 é compatível com conexões entre clientes e o balanceador de carga, e não com conexões entre o balanceador de carga e os back-ends dele.
• As conexões HTTP/3 usam o algoritmo de controle de congestionamento BBR.

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 para balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Suporte a HTTP/3
Balanceador de carga de aplicativo externo global (sempre nível Premium)
Balanceador de carga de aplicativo clássico no nível Premium
Balanceador de carga de aplicativo clássico no nível Standard
Balanceador de carga de aplicativo externo regional (nível Premium ou Standard)

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 está ativado, 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"

Observação: o cabeçalho Alt-Svc anuncia várias versões do HTTP/3 para oferecer suporte a rascunhos anteriores usados por alguns clientes, por exemplo, h3-29.

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

Tanto NONE (o padrão) quanto ENABLE ativam suporte a HTTP/3 para o balanceador de carga.

Quando o HTTP/3 está ativado, o balanceador de carga o anuncia para os clientes, o que permite que os clientes compatíveis com ele 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.

Os balanceadores de carga de aplicativo externos oferecem 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	A compatibilidade com HTTP/3 é anunciada para os clientes. Observação: o TLS 0-RTT (também conhecido como dados antecipados do TLS) ainda não é compatível com 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

Observação: no momento, a configuração da negociação HTTP/3 não é compatível com a página de proxies de destino e precisa ser definida editando a configuração do balanceador de carga.

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

Acessar o "Balanceamento de carga"

1. Selecione o balanceador de carga que você quer editar.
2. Clique em Configuração de front-end.
3. Selecione o endereço IP do front-end e a porta que você quer editar. Para editar uma configuração HTTP/3, o protocolo precisa ser HTTPS.

Ativar HTTP/3

1. Selecione o menu 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, ative o HTTP/3 em cada regra.

Desativar HTTP/3

1. Selecione o menu 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.

  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ático (padrão).

• ENABLE: divulga o HTTP/3 para os clientes.

• DISABLE: não anuncia HTTP/3 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.

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

Suporte a WebSocket

Os balanceadores de carga baseados em HTTP(S) do Google Cloud oferecem suporte ao protocolo WebSocket quando você usa 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 o balanceador de carga. Para mais informações, consulte a RFC 6455.

O protocolo WebSocket funciona da seguinte maneira:

1. O balanceador de carga reconhece uma solicitação Upgrade do WebSocket de um cliente HTTP(S). A solicitação contém os cabeçalhos Connection: Upgrade e Upgrade: websocket, seguidos por outros cabeçalhos de solicitação relevantes relacionados ao WebSocket.
2. O back-end envia uma resposta Upgrade do WebSocket. A instância de back-end envia uma resposta 101 switching protocol com cabeçalhos Connection: Upgrade, Upgrade: websocket e outros cabeçalhos de resposta relacionados ao WebSocket.
3. O balanceador de carga encaminha o tráfego bidirecional durante a duração da conexão atual.

Se a instância de back-end retornar uma resposta de erro com o código de resposta 426 ou 502, o balanceador de carga fechará a conexão.

O tempo limite da conexão Websocket depende do tipo de balanceador de carga (global, regional ou clássico). Para mais detalhes, consulte Tempo limite do serviço de back-end.

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

Suporte ao gRPC

O gRPC é um framework 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 você quiser configurar um balanceador de carga de aplicativo 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 a 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.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 e 1.3 ao encerrar solicitações SSL do cliente.

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

Suporte a TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo padrão do setor para autenticação mútua entre um cliente e um servidor. Ele garante que o cliente e o servidor se autenticam verificando se cada um deles tem um certificado válido emitido por uma autoridade certificadora (AC) confiável. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS exige que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes que a comunicação seja estabelecida.

Todos os balanceadores de carga de aplicativo oferecem suporte a mTLS. Com o mTLS, o balanceador de carga solicita que o cliente envie um certificado para se autenticar durante o handshake de TLS com o balanceador de carga. É possível configurar um repositório de confiança do Gerenciador de certificados que o balanceador de carga usa para validar a cadeia de confiança do certificado do cliente.

Para mais informações sobre mTLS, consulte Autenticação TLS mútua.

Limitações

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

• Ao usar balanceadores de carga de aplicativo 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 Google Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.

• Não é possível criar um balanceador de carga de aplicativo externo regional no nível Premium usando o console do Google Cloud. Além disso, apenas regiões que aceitam o nível Standard estão disponíveis para esses balanceadores de carga no console do Google Cloud. Use a CLI gcloud ou a API. Use a CLI gcloud ou a API.

• O Cloud CDN permite forçar um objeto ou conjunto de objetos a ser ignorado pelo cache solicitando uma invalidação de cache. Por padrão, quando você usa um balanceador de carga de aplicativo externo global com a referência de serviço entre projetos da VPC compartilhada, os administradores do projeto de serviço não têm as permissões necessárias para solicitar invalidações de cache. Isso ocorre porque a invalidação de cache é configurada no projeto de front-end, ou seja, no projeto que tem a regra de encaminhamento, o proxy de destino e o mapa de URL do balanceador de carga. Assim, as invalidações de cache só podem ser emitidas por principais que têm os papéis do IAM para configurar recursos relacionados ao balanceador de carga nos projetos de front-end (por exemplo, o papel de administrador de rede do Compute). Os administradores de serviços, que controlam o provisionamento dos serviços de back-end em um projeto separado, precisarão trabalhar com o administrador do balanceador de carga do projeto de front-end para emitir a invalidação de cache para os serviços entre projetos.

A seguir

• Para saber como implantar um balanceador de carga de aplicativo externo global, consulte Como configurar um balanceador de carga de aplicativo externo com um back-end do Compute Engine.

• Para saber como implantar um balanceador de carga de aplicativo externo regional, consulte Como configurar um balanceador de carga de aplicativo externo regional com um back-end do Compute Engine.

• Se você já é usuário do balanceador de carga de aplicativo clássico, consulte a Visão geral da migração ao planejar uma nova implantação com o balanceador de carga de aplicativo externo global.

• Para saber como automatizar a configuração do balanceador de carga de aplicativo externo com o Terraform, consulte Exemplos de módulo do Terraform para balanceadores de carga de aplicativo externos.

• Para saber como configurar recursos avançados de gerenciamento de tráfego disponíveis com o balanceador de carga externo de aplicativos global, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais.

• Para saber como configurar recursos avançados de gerenciamento de tráfego disponíveis com o balanceador de carga de aplicativo externo regional, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais.

• Saiba mais sobre como exibir sites em Como exibir sites.

• Para encontrar os locais dos PoPs do Google, consulte locais do GFE.

• Saiba mais sobre o gerenciamento de capacidade em Tutorial sobre gerenciamento de capacidade com balanceamento de carga e Otimizações de capacidade de aplicativo com balanceamento de carga global.

• Para saber como usar o Gerenciador de certificados para provisionar e gerenciar certificados SSL, consulte a Visão geral do Gerenciador de certificados.

• Para inserir lógica personalizada no caminho de dados de balanceamento de carga, configure plug-ins ou chamadas de extensões de serviço.

• Para balanceadores de carga de aplicativo externos regionais, tente usar a descoberta de APIs Shadow da Apigee para encontrar APIs Shadow (também conhecidas como APIs não documentadas) na sua infraestrutura do Google Cloud. Leia as limitações associadas antes de ativar a descoberta da API Shadow.