Panoramica del bilanciatore del carico delle applicazioni esterno

Questo documento illustra i concetti che devi conoscere per configurare un bilanciatore del carico delle applicazioni esterno.

Un bilanciatore del carico delle applicazioni esterno è un bilanciatore del carico di livello 7 basato su proxy che ti consente di eseguire e scalare i servizi dietro un singolo indirizzo IP esterno. Il bilanciatore del carico delle applicazioni esterno distribuisce il traffico HTTP e HTTPS ai backend ospitati su varie piattaforme Google Cloud (come Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage e così via), nonché ai backend esterni collegati tramite internet o tramite connettività ibrida. Per maggiori dettagli, consulta la Panoramica di Application Load Balancer: casi d'uso.

Modalità di funzionamento

Puoi configurare un bilanciatore del carico delle applicazioni esterno nelle seguenti modalità:

• Bilanciatore del carico delle applicazioni esterno globale. Si tratta di un bilanciatore del carico globale implementato come servizio gestito su Google Front End (GFE). Utilizza il proxy Envoy open source per supportare funzionalità di gestione del traffico avanzate come il mirroring del traffico, la suddivisione del traffico in base al peso, le trasformazioni delle intestazioni in base a richieste/risposte e altro ancora.
• Bilanciatore del carico delle applicazioni classico. Si tratta del bilanciatore del carico delle applicazioni esterno classico, che è globale nel livello Premium, ma può essere configurato come regionale nel livello Standard. Questo bilanciatore del carico è implementato su Google Front End (GFE). I GFE vengono distribuiti a livello globale e operano insieme utilizzando la rete globale e il piano di controllo di Google.
• Bilanciatore del carico delle applicazioni esterno regionale. Si tratta di un bilanciatore del carico a livello di area geografica implementato come servizio gestito sul proxy Envoy open source. Include funzionalità di gestione del traffico avanzate come il mirroring del traffico, la suddivisione del traffico in base al peso, le trasformazioni delle intestazioni in base a richieste/risposte e altro ancora.

Modalità del bilanciatore del carico	Casi d'uso consigliati	Funzionalità
Bilanciatore del carico delle applicazioni esterno globale	Utilizza questo bilanciatore del carico per i carichi di lavoro HTTP(S) esterni con utenti o servizi di backend dislocati a livello globale in più regioni.	Compatibile con GKE utilizzando Gateway (completamente orchestrato) o NEG autonomi (orchestrazione manuale) Supporta la gestione avanzata del traffico Indirizzi IP esterni anycast globali con il livello Premium Può accedere ai backend in più regioni Supporta Cloud CDN Supporta Google Cloud Armor
Bilanciatore del carico delle applicazioni classico	Questo bilanciatore del carico è globale nel livello Premium. Nel livello Premium del servizio di rete, questo bilanciatore del carico offre il bilanciamento del carico su più regioni, tenta di indirizzare il traffico al backend funzionante più vicino con sufficiente capacità e termina il traffico HTTP(S) il più vicino possibile ai tuoi utenti. Per informazioni dettagliate sulla procedura di distribuzione delle richieste, consulta Distribuzione del traffico. Nel livello di servizio di rete standard, questo bilanciatore del carico può distribuire il traffico ai backend solo in una singola regione.	Compatibile con GKE utilizzando Gateway (completamente orchestrato), Ingress (completamente orchestrato) o NEG autonomi (orchestrazione manuale) Supporta Google Cloud Armor Meno funzionalità di routing del traffico Per un elenco completo delle funzionalità, consulta la pagina Funzionalità di bilanciamento del carico.
Bilanciatore del carico delle applicazioni esterno regionale	Questo bilanciatore del carico contiene molte delle funzionalità dell'Application Load Balancer classico esistente, oltre a funzionalità di gestione avanzata del traffico. Utilizza questo bilanciatore del carico se vuoi pubblicare contenuti da una sola geolocalizzazione (ad esempio per soddisfare le normative di conformità). Questo bilanciatore del carico può essere configurato nel livello Premium o Standard.	Compatibile con GKE utilizzando NEG autonomi (orchestrazione manuale) Supporta funzionalità avanzate di gestione del traffico VIP regionali che utilizzano il livello di rete standard Termina TLS in un'unica regione configurata Pubblica i contenuti solo dalla regione configurata Per l'elenco completo, consulta le funzionalità di bilanciamento del carico.

Identifica la modalità

console Cloud

1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.

   Vai a Bilanciamento del carico

2. Nella scheda Bilanciatori del carico vengono visualizzati il tipo, il protocollo e la regione del bilanciatore del carico. Se la regione è vuota, il bilanciatore del carico è globale. La tabella riportata di seguito riassume come identificare la modalità del bilanciatore del carico.

Modalità del bilanciatore del carico	>Tipo di bilanciatore del carico	Tipo di accesso	Regione
Bilanciatore del carico delle applicazioni esterno globale	Applicazione	Esterno
Bilanciatore del carico delle applicazioni classico	Applicazione(versione classica)	Esterno
Bilanciatore del carico delle applicazioni esterno regionale	Applicazione	Esterno	Specifica una regione

gcloud

1. Per determinare la modalità di un bilanciatore del carico, esegui il seguente comando:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Nell'output del comando, controlla lo schema di bilanciamento del carico, la regione e il livello di rete. La tabella seguente riassume come identificare la modalità del bilanciatore del carico.

Modalità del bilanciatore del carico	Schema di bilanciamento del carico	Regola di forwarding	Livello di rete
Bilanciatore del carico delle applicazioni esterno globale	EXTERNAL_MANAGED	Globale	Premium
Bilanciatore del carico delle applicazioni classico	EXTERNAL	Globale	Standard o Premium
Bilanciatore del carico delle applicazioni esterno regionale	EXTERNAL_MANAGED	Specifica una regione	Standard o Premium

Importante: dopo aver creato un bilanciatore del carico, non puoi modificarne la modalità. Devi invece eliminare il bilanciatore del carico e crearne uno nuovo.

Architettura

Per il deployment di un bilanciatore del carico delle applicazioni esterno sono necessarie le seguenti risorse:

• Solo per i bilanciatori del carico delle applicazioni esterni regionali, viene utilizzata una subnet solo proxy per inviare le connessioni dal bilanciatore del carico ai backend.

• Una regola di inoltro esterno specifica un indirizzo IP, una porta e un proxy HTTP(S) di destinazione esterni. I client utilizzano l'indirizzo IP e la porta per connettersi al bilanciatore del carico.

• Un proxy HTTP(S) di destinazione riceve una richiesta dal client. Il proxy HTTP(S) valuta la richiesta utilizzando la mappa URL per prendere decisioni di instradamento del traffico. Il proxy può anche autenticare le comunicazioni utilizzando i certificati SSL.

  • Per il bilanciamento del carico HTTPS, il proxy HTTPS di destinazione utilizza i certificati SSL per dimostrare la propria identità ai client. Un proxy HTTPS di destinazione supporta fino al numero documentato di certificati SSL.

• Il proxy HTTP(S) utilizza una mappa URL per prendere una decisione di routing in base agli attributi HTTP (ad esempio il percorso della richiesta, i cookie o gli intestazioni). In base alla decisione di routing, il proxy inoltra le richieste del client a servizi o bucket di backend specifici. La mappa URL può specificare azioni aggiuntive, come l'invio di reindirizzamenti ai client.

• Un servizio di backend distribuisce le richieste ai backends in buono stato. I bilanciatori del carico delle applicazioni esterni globali supportano anche i bucket di backend. Uno o più backends devono essere collegati al servizio di backend o al bucket di backend.

• Un controllo di integrità monitora periodicamente l'idoneità dei tuoi backend. In questo modo si riduce il rischio che le richieste vengano inviate a backend che non possono gestirle.

• Regole firewall per consentire ai backend di accettare i probe del controllo di integrità. I bilanciatori del carico delle applicazioni esterni regionali richiedono un'ulteriore regola firewall per consentire al traffico dalla subnet solo proxy di raggiungere i backend.

Globale

Questo diagramma mostra i componenti di un deployment di un bilanciatore del carico delle applicazioni esterno globale. Questa architettura si applica sia al bilanciatore del carico delle applicazioni esterno globale sia al bilanciatore del carico delle applicazioni classico nel livello Premium.

Componenti del bilanciatore del carico delle applicazioni esterno globale (fai clic per ingrandire).

Regionale

Questo diagramma mostra i componenti di un deployment di un bilanciatore del carico delle applicazioni esterno regionale.

Componenti del bilanciatore del carico delle applicazioni esterno regionale (fai clic per ingrandire).

Subnet solo proxy

Le subnet solo proxy sono necessarie solo per i bilanciatori del carico delle applicazioni esterni regionali.

La subnet solo proxy fornisce un insieme di indirizzi IP che Google utilizza per eseguire proxy Envoy per tuo conto. Devi creare una subnet solo proxy in ogni regione di una rete VPC in cui utilizzi bilanciatori del carico delle applicazioni esterni regionali. Il flag --purpose per questa subnet solo proxy è impostato su REGIONAL_MANAGED_PROXY. Tutti i bilanciatori del carico basati su Envoy a livello di regione nella stessa regione e nella stessa rete VPC condividono un pool di proxy Envoy della stessa subnet solo proxy. Inoltre:

• Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i backend.
• Le VM di backend o gli endpoint di tutti i bilanciatori del carico delle applicazioni esterni regionali in una regione e nella rete VPC ricevono connessioni dalla subnet solo proxy.
• L'indirizzo IP del bilanciatore del carico delle applicazioni esterno regionale non si trova nella subnet solo proxy. L'indirizzo IP del bilanciatore del carico è definito dalla regola di forwarding gestita esterna, descritta di seguito.

Se in precedenza hai creato una subnet solo proxy con --purpose=INTERNAL_HTTPS_LOAD_BALANCER, devi eseguire la migrazione dello scopo della subnet a REGIONAL_MANAGED_PROXY prima di poter creare altri bilanciatori del carico basati su Envoy nella stessa regione della rete VPC.

Regole di forwarding e indirizzi IP

Le regole di forwarding instradano il traffico in base a indirizzo IP, porta e protocollo a una configurazione di bilanciamento del carico composta da un proxy di destinazione, una mappa URL e uno o più servizi di backend.

Specifica dell'indirizzo IP. Ogni regola di forwarding fornisce un singolo indirizzo IP che può essere utilizzato nei record DNS per la tua applicazione. Non è richiesto alcun bilanciamento del carico basato su DNS. Puoi specificare l'indirizzo IP da utilizzare o lasciare che sia Cloud Load Balancing ad assegnarne uno.

Specifica della porta. Ogni regola di forwarding per un bilanciatore del carico delle applicazioni può fare riferimento a una singola porta da 1 a 65535. Per supportare più porte, devi configurare più regole di inoltro. Puoi configurare più regole di inoltro per utilizzare lo stesso indirizzo IP esterno (VIP) e fare riferimento allo stesso proxy HTTP(S) di destinazione, purché la combinazione complessiva di indirizzo IP, porta e protocollo sia univoca per ogni regola di inoltro. In questo modo, puoi utilizzare un singolo bilanciatore del carico con una mappa URL condivisa come proxy per più applicazioni.

Il tipo di regola di forwarding, l'indirizzo IP e lo schema di bilanciamento del carico utilizzati dai bilanciatori del carico delle applicazioni esterni dipendono dalla modalità del bilanciatore del carico e dal livello di servizio di rete in cui si trova.

Modalità del bilanciatore del carico	Livello di servizio di rete	Regola di inoltro, indirizzo IP e schema di bilanciamento del carico	Instradamento da internet al frontend del bilanciatore del carico
Bilanciatore del carico delle applicazioni esterno globale	Livello Premium	Regola di forwarding esterno globale Indirizzo IP esterno globale Schema di bilanciamento del carico: EXTERNAL_MANAGED	Richieste instradate al servizio GFE più vicino al cliente su internet.
Bilanciatore del carico delle applicazioni classico	Livello Premium	Regola di forwarding esterno globale Indirizzo IP esterno globale Schema di bilanciamento del carico: EXTERNAL ^†	Richieste instradate al GFE più vicino al cliente su internet.
	Livello Standard	Regola di inoltro esterno regionale Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL^*	Richieste instradate a un GFE nella regione del bilanciatore del carico.
Bilanciatore del carico delle applicazioni esterno regionale	Livello Premium o Standard	Regola di inoltro esterno regionale Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL_MANAGED	Le richieste raggiungono Google Cloud nel PoP più vicino al client. Le richieste vengono quindi instradate tramite la backbone premium di Google Cloud fino a raggiungere i proxy Envoy nella stessa regione del bilanciatore del carico.

^* È possibile collegare servizi di backend EXTERNAL_MANAGED alle regole di forwarding EXTERNAL. Tuttavia, i servizi di backend EXTERNAL non possono essere collegati alle regole di inoltro EXTERNAL_MANAGED. Per usufruire delle nuove funzionalità disponibili solo con il bilanciatore del carico delle applicazioni esterno globale, ti consigliamo di eseguire la migrazione delle risorse EXTERNAL esistenti a EXTERNAL_MANAGED utilizzando la procedura descritta in Eseguire la migrazione delle risorse dal bilanciatore del carico delle applicazioni classico a quello esterno globale.

Per l'elenco completo dei protocolli supportati dalle regole di inoltro del bilanciatore del carico delle applicazioni esterno in ogni modalità, consulta Funzionalità del bilanciatore del carico.

Regole di inoltro e reti VPC

Questa sezione descrive come le regole di inoltro utilizzate dai bilanciatori del carico delle applicazioni esterni vengono associate alle reti VPC.

Modalità del bilanciatore del carico	Associazione della rete VPC
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico	Nessuna rete VPC associata. La regola di forwarding utilizza sempre un indirizzo IP che si trova al di fuori della rete VPC. Pertanto, la regola di forwarding non ha una rete VPC associata.
Bilanciatore del carico delle applicazioni esterno regionale	La rete VPC della regola di forwarding è la rete in cui è stata creata la subnet solo proxy. Puoi specificare la rete quando crei la regola di forwarding. A seconda che tu utilizzi un indirizzo IPv4 o un intervallo di indirizzi IPv6, alla regola di forwarding è sempre associata una rete VPC esplicita o implicita. Gli indirizzi IPv4 esterni regionali esistono sempre al di fuori delle reti VPC. Tuttavia, quando crei la regola di forwarding, devi specificare la rete VPC in cui è stata creata la subnet solo proxy. Pertanto, la regola di forwarding ha un'associazione di rete esplicita. Gli intervalli di indirizzi IPv6 esterni regionali esistono sempre all'interno di una rete VPC. Quando crei la regola di forwarding, devi specificare la subnet da cui viene preso l'intervallo di indirizzi IP. Questa subnet deve trovarsi nella stessa regione e nella stessa rete VPC in cui è stata creata una subnet solo proxy. Pertanto, esiste un'associazione di rete implicita.

Proxy di destinazione

I proxy di destinazione terminano le connessioni HTTP(S) provenienti dai client. Una o più regole di inoltro indirizzano il traffico al proxy di destinazione, che consulta la mappa URL per determinare come indirizzare il traffico ai backend.

Non fare affidamento sul proxy per mantenere la maiuscola dei nomi delle intestazioni di richiesta o risposta. Ad esempio, un'intestazione di risposta Server: Apache/1.0 potrebbe essere visualizzata nel client come server: Apache/1.0.

Nota: per i gruppi di endpoint di rete (NEG) internet, le richieste del bilanciatore del carico provengono da intervalli IP diversi a seconda del tipo di NEG (globale o regionale). Per ulteriori informazioni, consulta la sezione Autenticazione delle richieste.

La tabella seguente specifica il tipo di proxy target richiesto dagli Application Load Balancer esterni.

Modalità del bilanciatore del carico	Tipi di proxy di destinazione	Intestazioni aggiunte dal proxy	Intestazioni personalizzate supportate
Bilanciatore del carico delle applicazioni esterno globale	HTTP globale, HTTPS globale	I proxy impostano le intestazioni di richiesta/risposta HTTP come segue: Via: 1.1 google (richieste e risposte) X-Forwarded-Proto: [http | https] (solo richieste) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (vedi intestazione X-Forwarded-For) (solo richieste) I proxy impostano anche l'intestazione X-Cloud-Trace-Context se non è già presente.	Configurato sul servizio di backend o sul bucket di backend Non supportato con Cloud CDN
Bilanciatore del carico delle applicazioni classico	HTTP globale, HTTPS globale	I proxy impostano le intestazioni di richiesta/risposta HTTP come segue: Via: 1.1 google (richieste e risposte) X-Forwarded-Proto: [http | https] (solo richieste) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (vedi intestazione X-Forwarded-For) (solo richieste) I proxy impostano anche l'intestazione X-Cloud-Trace-Context se non è già presente.	Configurato sul servizio di backend o sul bucket di backend
Bilanciatore del carico delle applicazioni esterno regionale	HTTP regionale, HTTPS regionale	X-Forwarded-Proto: [http | https] (solo richieste) Via: 1.1 google (richieste e risposte) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (vedi intestazione X-Forwarded-For) (solo richieste)

Nota: in conformità con il protocollo RFC 2616, le seguenti intestazioni hop-by-hop non vengono propagate dal proxy di destinazione:Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE,Trailers, Transfer-Encoding e Upgrade.

Oltre alle intestazioni aggiunte dal proxy di destinazione, il bilanciatore del carico regola altre intestazioni HTTP nei seguenti modi:

• Per il bilanciatore del carico delle applicazioni esterno globale, sia le intestazioni di richiesta che quelle di risposta potrebbero essere convertiere in minuscole.

  L'unica eccezione è quando utilizzi backend NEG internet globali con HTTP/1.1. Per informazioni dettagliate su come le intestazioni HTTP/1.1 vengono elaborate con i NEG internet globali, consulta la panoramica dei NEG internet.

• Per il bilanciatore del carico delle applicazioni classico, le intestazioni di richiesta e risposta vengono convertite in lettere minuscole, tranne quando utilizzi HTTP/1.1. Con HTTP/1.1, invece, le intestazioni sono in maiuscolo. La prima lettera della chiave dell'intestazione e ogni lettera che segue un trattino (-) sono in maiuscolo per mantenere la compatibilità con i client HTTP/1.1. Ad esempio, user-agent viene modificato in User-Agent e content-encoding in Content-Encoding.

• Alcune intestazioni sono unite. Quando sono presenti più istanze della stessa chiave di intestazione (ad esempio Via), il bilanciatore del carico combina i relativi valori in un unico elenco separato da virgole per una singola chiave di intestazione. Vengono unite solo le intestazioni cuyos valori possono essere rappresentati come elenco separato da virgole. Altre intestazioni, come Set-Cookie, non vengono mai unite.

Intestazione host

Quando il bilanciatore del carico invia la richiesta HTTP, conserva l'intestazione Host della richiesta originale.

Intestazione X-Forwarded-For

Il bilanciatore del carico aggiunge due indirizzi IP separati da una virgola all'X-Forwarded-For intestazione nel seguente ordine:

• L'indirizzo IP del client che si connette al bilanciatore del carico
• L'indirizzo IP della regola di forwarding del bilanciatore del carico

Se non è presente un'intestazione X-Forwarded-For nella richiesta in arrivo, questi due indirizzi IP costituisce l'intero valore dell'intestazione:

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

Se la richiesta include un'intestazione X-Forwarded-For, il bilanciatore del carico conserva il valore fornito prima di <client-ip>,<load-balancer-ip>:

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

Attenzione: il bilanciatore del carico non verifica gli indirizzi IP che precedono <client-ip>,<load-balancer-ip> in questa intestazione. Gli indirizzi IP precedenti potrebbero contenere altri caratteri, inclusi gli spazi.

Quando esegui il software del proxy inverso HTTP sui backend del bilanciatore del carico, il software potrebbe aggiungere uno o entrambi i seguenti indirizzi IP alla fine dell'intestazione X-Forwarded-For:

• L'indirizzo IP dell'interfaccia Google Front End (GFE) (GFE) che si è connessa al backend. Questi indirizzi IP si trovano negli intervalli 130.211.0.0/22 e 35.191.0.0/16.

• L'indirizzo IP del sistema di backend stesso.

Di conseguenza, un processo a monte dopo il backend del bilanciatore del carico potrebbe ricevere un'intestazione X-Forwarded-For del seguente tipo:

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

Assistenza Cloud Trace

Trace non è supportata con i bilanciatori del carico delle applicazioni. I bilanciatori del carico delle applicazioni globali e classici aggiungono l'intestazione X-Cloud-Trace-Context se non è presente. Il bilanciatore del carico delle applicazioni esterno regionale non aggiunge questa intestazione. Se l'intestazione X-Cloud-Trace-Context è già presente, passa attraverso i bilanciatori del carico invariata. Tuttavia, il bilanciatore di carico non esporta tracce o span.

Mappe URL

Le mappe URL definiscono pattern di corrispondenza per l'instradamento delle richieste in base all'URL ai servizi di backend appropriati. La mappa URL consente di suddividere il traffico esaminando i componenti dell'URL per inviare richieste a diversi set di backend. Viene definito un servizio predefinito per gestire tutte le richieste che non corrispondono a una regola di corrispondenza dell'host o del percorso specificata.

In alcuni casi, ad esempio nell'esempio di bilanciamento del carico su più regioni, potresti non definire regole URL e fare affidamento solo sul servizio predefinito.

Le mappe URL supportano diverse funzionalità avanzate di gestione del traffico, come l'indirizzamento del traffico in base all'intestazione, la suddivisione del traffico in base al peso e il mirroring delle richieste. Per ulteriori informazioni, consulta le seguenti risorse:

• Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale

• Panoramica della gestione del traffico per bilanciatori del carico delle applicazioni esterni regionali

La tabella seguente specifica il tipo di mappa URL richiesto dai bilanciatori del carico delle applicazioni esterni in ogni modalità.

Modalità del bilanciatore del carico	Tipo di mappa URL
Bilanciatore del carico delle applicazioni esterno globale	Global
Bilanciatore del carico delle applicazioni classico	Globale (con solo un sottoinsieme delle funzionalità supportate)
Bilanciatore del carico delle applicazioni esterno regionale	A livello di regione

Certificati SSL

I bilanciatori del carico delle applicazioni esterni che utilizzano proxy HTTPS di destinazione richiedono chiavi private e certificati SSL come parte della configurazione del bilanciatore del carico.

• Google Cloud offre due metodi di configurazione per assegnare chiavi private e certificati SSL ai proxy HTTPS di destinazione: i certificati SSL di Compute Engine e Certificate Manager. Per una descrizione di ciascuna configurazione, consulta Metodi di configurazione dei certificati nella panoramica dei certificati SSL.

• Google Cloud offre due tipi di certificati: autogestiti e gestiti da Google. Per una descrizione di ciascun tipo, consulta Tipi di certificati nella panoramica dei certificati SSL.

Il tipo di bilanciatore del carico delle applicazioni esterno (globale, regionale o classico) determina quali metodi di configurazione e tipi di certificati sono supportati. Per maggiori dettagli, consulta Certificati e bilanciatori di carico Google Cloud nella panoramica dei certificati SSL.

Criteri SSL

I criteri SSL specificano l'insieme di funzionalità SSL utilizzate dai bilanciatori del carico Google Cloud durante la negoziazione SSL con i client.

Per impostazione predefinita, il bilanciamento del carico HTTPS utilizza un insieme di funzionalità SSL che offrono una buona sicurezza e un'ampia compatibilità. Alcune applicazioni richiedono un maggiore controllo sulle versioni e sulle crittografie SSL utilizzate per le connessioni HTTPS o SSL. Puoi definire un criterio SSL per specificare l'insieme di funzionalità SSL utilizzate dal bilanciatore del carico durante la negoziazione SSL con i client. Inoltre, puoi applicare questo criterio SSL al proxy HTTPS di destinazione.

La tabella seguente specifica il supporto dei criteri SSL per i bilanciatori del carico in ogni modalità.

Modalità del bilanciatore del carico	Criteri SSL supportati
Bilanciatore del carico delle applicazioni esterno globale
Bilanciatore del carico delle applicazioni classico
Bilanciatore del carico delle applicazioni esterno regionale

Servizi di backend

Un servizio di backend fornisce informazioni di configurazione al bilanciatore del carico in modo che possa indirizzare le richieste ai propri backend, ad esempio gruppi di istanze Compute Engine o gruppi di endpoint di rete (NEG). Per maggiori informazioni sui servizi di backend, consulta la Panoramica dei servizi di backend.

Per un esempio che mostra come configurare un bilanciatore del carico con un servizio di backend e un backend di Compute Engine, consulta Configurazione di un bilanciatore del carico delle applicazioni esterno con un backend di Compute Engine.

Ambito del servizio di backend

La tabella seguente indica la risorsa e l'ambito del servizio di backend utilizzati dai bilanciatori del carico delle applicazioni esterni:

Modalità del bilanciatore del carico	Risorsa del servizio di backend
Bilanciatore del carico delle applicazioni esterno globale	backendServices (globale)
Bilanciatore del carico delle applicazioni classico	backendServices (globale)
Bilanciatore del carico delle applicazioni esterno regionale	regionBackendServices (regionale)

Protocollo per i backend

I servizi di backend per i bilanciatori del carico delle applicazioni devono utilizzare uno dei seguenti protocolli per inviare richieste ai backend:

• HTTP, che utilizza HTTP/1.1 e non TLS
• HTTPS, che utilizza HTTP/1.1 e TLS
• HTTP/2, che utilizza HTTP/2 e TLS (HTTP/2 senza crittografia non è supportato).

Il bilanciatore del carico utilizza solo il protocollo del servizio di backend specificato per comunicare con i relativi backend. Il bilanciatore del carico non esegue il fallback a un Protocollo diverso se non è in grado di comunicare con i backend utilizzando il Protocollo del servizio di backend specificato.

Il protocollo del servizio di backend non deve corrispondere a quello utilizzato dai client per comunicare con il bilanciatore del carico. Ad esempio, i client possono inviare richieste al bilanciatore del carico utilizzando HTTP/2, ma il bilanciatore del carico può comunicare con i backend utilizzando HTTP/1.1 (HTTP o HTTPS).

Bucket di backend

I bucket di backend indirizzano il traffico in entrata ai bucket Cloud Storage. Per un esempio che mostra come aggiungere un bucket a un bilanciatore del carico delle applicazioni esterno, consulta Configurare un bilanciatore del carico con i bucket di backend. Per informazioni generali su Cloud Storage, consulta Che cos'è Cloud Storage?

Backend

La tabella seguente specifica i backend e le funzionalità correlate supportate dagli bilanciatori di carico delle applicazioni esterni in ogni modalità.

Modalità del bilanciatore del carico	Backend supportati in un servizio di backend^*						Supporta i bucket di backend	Supporta Google Cloud Armor	Supporta Cloud CDN^#	Supporta gli acquisti in-app^#	Supporta Service Extensions
	Gruppi di istanze^†	NEG a livello di zona^‡	NEG internet	NEG serverless	NEG ibridi	NEG Private Service Connect
Bilanciatore del carico delle applicazioni esterno globale
Bilanciatore del carico delle applicazioni classico									Livello Premium
Bilanciatore del carico delle applicazioni esterno regionale

^*I backend di un servizio di backend devono essere dello stesso tipo: tutti gruppi di istanze o tutti dello stesso tipo di NEG. Un'eccezione a questa regola è che sia i NEG zonaliGCE_VM_IP_PORT sia i NEG ibridi possono essere utilizzati nello stesso servizio di backend per supportare un' architettura ibrida.

^† Le combinazioni di gruppi di istanze non gestite per zona, gestite per zona e gestite a livello di regione sono supportate nello stesso servizio di backend. Quando utilizzi la scalabilità automatica per un gruppo di istanze gestite che è un backend per due o più servizi di backend, configura il criterio di scalabilità automatica del gruppo di istanze in modo che utilizzi più indicatori.

^‡ I NEG a livello di zona devono utilizzare endpoint GCE_VM_IP_PORT.

^# IAP e Cloud CDN non sono compatibili tra loro. Non possono essere attivati entrambi nello stesso servizio di backend.

Backend e reti VPC

Le limitazioni relative alla posizione dei backend dipendono dal tipo di bilanciatore del carico.

Nota: questa sezione descrive l'associazione della rete VPC per i deployment in cui il servizio di backend e i backend del bilanciatore del carico si trovano nello stesso progetto della regola di forwarding. Se vuoi anche che il servizio di backend si trovi in un progetto diverso da quello della regola di forwarding, devi configurare il bilanciatore del carico in un ambiente VPC condiviso con riferimenti ai servizi tra progetti.

Per il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico, tutte le istanze di backend dei backend dei gruppi di istanze e tutti gli endpoint di backend dei backend NEG devono trovarsi nello stesso progetto. Tuttavia, un backend del gruppo di istanze o un gruppo di esclusioni di rete può utilizzare una rete VPC diversa nel progetto. Le diverse reti VPC non devono essere connesse utilizzando il peering di rete VPC perché le istanze GFE comunicano direttamente con i backend nelle rispettive reti VPC.

Per il bilanciatore del carico delle applicazioni esterno regionale, la limitazione relativa alla posizione dei backend dipende dal tipo di backend.

• Per i gruppi di istanze, i NEG a livello di zona e i NEG connettività ibrida, tutti i backend devono trovarsi nello stesso progetto e nella stessa regione del servizio di backend. Tuttavia, un bilanciatore del carico può fare riferimento a un backend che utilizza una rete VPC diversa nello stesso progetto del servizio di backend (questa funzionalità è in anteprima). La connettività tra la rete VPC del bilanciatore del carico e la rete VPC di backend può essere configurata utilizzando il peering di rete VPC, i tunnel Cloud VPN, i collegamenti VLAN Cloud Interconnect o un framework Network Connectivity Center.

  Definizione della rete di backend

  • Per i NEG zonali e i NEG ibridi, devi specificare esplicitamente la rete VPC quando crei il NEG.
  • Per i gruppi di istanze gestite, la rete VPC è definita nel modello di istanza.
  • Per i gruppi di istanze non gestiti, la rete VPC del gruppo di istanze è impostata in modo da corrispondere alla rete VPC dell'interfaccia nic0 per la prima VM aggiunta al gruppo di istanze.

  Requisiti di rete di backend

  La rete del tuo backend deve soddisfare uno dei seguenti requisiti:

  • La rete VPC del backend deve corrispondere esattamente alla rete VPC della regola di forwarding.

  • La rete VPC del backend deve essere connessa alla rete VPC della regola di forwarding tramite il peering di rete VPC. Devi configurare gli scambi di route di subnet per consentire la comunicazione tra la subnet solo proxy nella rete VPC della regola di forwarding e le subnet utilizzate dalle istanze o dagli endpoint di backend.

  • Sia la rete VPC del backend sia la rete VPC della regola di forwarding devono essere spoke VPC sullo stesso hub Network Connectivity Center. I filtri di importazione ed esportazione devono consentire la comunicazione tra la subnet solo proxy nella rete VPC della regola di forwarding e le subnet utilizzate dagli endpoint o dalle istanze di backend.
  • Per tutti gli altri tipi di backend, tutti i backend devono trovarsi nella stessa rete e nella stessa regione VPC.

Backend e interfacce di rete

Se utilizzi backend di gruppi di istanze, i pacchetti vengono sempre inviati a nic0. Se vuoi inviare pacchetti a NIC diverse, utilizza i backend NEG.

Se utilizzi backend NEG a livello di zona, i pacchetti vengono inviati a qualsiasi interfaccia di rete rappresentata dall'endpoint nel NEG. Gli endpoint NEG devono trovarsi nella stessa rete VPC della rete VPC definita esplicitamente del NEG.

Controlli di integrità

Ogni servizio di backend specifica un controllo di integrità che monitora periodicamente la disponibilità dei backend a ricevere una connessione dal bilanciatore del carico. In questo modo si riduce il rischio che le richieste vengano inviate a backend che non possono gestirle. I controlli di integrità non verificano se l'applicazione stessa funziona.

Per i probe del controllo di integrità, devi creare una regola firewall di autorizzazione in entrata che consenta ai probe del controllo di integrità di raggiungere le istanze di backend. In genere, i probe del controllo di integrità provengono dal meccanismo di controllo di integrità centralizzato di Google.

I bilanciatori del carico delle applicazioni esterni regionali che utilizzano backend NEG ibridi sono un'eccezione a questa regola perché i relativi controlli di integrità provengono dalla subnet solo proxy. Per maggiori dettagli, consulta la panoramica dei contratti di NEG ibridi.

Protocollo di controllo di integrità

Sebbene non sia obbligatorio e non sempre possibile, è buona prassi utilizzare un controllo di integrità il cui protocollo corrisponda al protocollo del servizio di backend. Ad esempio, un controllo di integrità HTTP/2 verifica con maggiore precisione la connettività HTTP/2 ai backend. I bilanciatori del carico delle applicazioni esterni regionali che utilizzano backend NEG ibridi, invece, non supportano i controlli di integrità gRPC. Per l'elenco dei protocolli di controllo di integrità supportati, consulta Funzionalità di bilanciamento del carico.

La tabella seguente specifica l'ambito dei controlli di integrità supportati dai bilanciatori del carico delle applicazioni esterni in ogni modalità.

Modalità del bilanciatore del carico	Tipo di controllo di integrità
Bilanciatore del carico delle applicazioni esterno globale	Global
Bilanciatore del carico delle applicazioni classico	Global
Bilanciatore del carico delle applicazioni esterno regionale	A livello di regione

Per ulteriori informazioni sui controlli di integrità, consulta le seguenti risorse:

• Panoramica dei controlli di integrità
• Creazione di controlli di integrità

Regole firewall

Il bilanciatore del carico richiede le seguenti regole firewall:

• Per gli Application Load Balancer esterni globali, una regola di autorizzazione in entrata per consentire al traffico proveniente dai front-end Google (GFEs) di raggiungere i tuoi backend. Per l'Application Load Balancer esterno regionale, una regola di autorizzazione in entrata per consentire al traffico proveniente dalla subnet solo proxy di raggiungere i tuoi backend.
• Una regola di autorizzazione in entrata per consentire il traffico dagli intervalli dei probe del controllo di integrità. Per ulteriori informazioni sui probe del controllo di integrità e sul motivo per cui è necessario consentire il traffico da questi probe, consulta Intervalli IP dei probe e regole firewall.

Le regole firewall vengono implementate a livello di istanza VM, non sui proxy GFE. Non puoi utilizzare le regole del firewall di Google Cloud per impedire al traffico di raggiungere il bilanciatore del carico. Per il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico, puoi utilizzare Google Cloud Armor per farlo.

Le porte per queste regole firewall devono essere configurate come segue:

• Consenti il traffico alla porta di destinazione per il controllo di integrità di ciascun servizio di backend.

• Per i backend del gruppo di istanze: determina le porte da configurare in base al mappatura tra la porta denominata del servizio di backend e i numeri di porta associati a quella porta denominata in ogni gruppo di istanze. I numeri di porta possono variare tra i gruppi di istanze assegnati allo stesso servizio di backend.

• Per i backend NEG GCE_VM_IP_PORT: consenti il traffico ai numeri di porta degli endpoint.

La tabella seguente riassume gli intervalli di indirizzi IP di origine richiesti per le regole firewall:

Modalità del bilanciatore del carico	Intervalli di origine del controllo di integrità	Intervalli di origine della richiesta
Bilanciatore del carico delle applicazioni esterno globale	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64	La sorgente del traffico GFE dipende dal tipo di backend: Gruppi di istanze e NEG a livello di zona (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Per il traffico IPv6 verso i backend: 2600:2d00:1:1::/64 NEG di connettività ibrida (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 NEG internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG e bucket di backend: la rete di produzione di Google gestisce il routing dei pacchetti
Bilanciatore del carico delle applicazioni classico	35.191.0.0/16 130.211.0.0/22	La sorgente del traffico GFE dipende dal tipo di backend: Gruppi di istanze, NEG a livello di zona (GCE_VM_IP_PORT) e NEG connettività ibrida (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 NEG internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG e bucket di backend: la rete di produzione di Google gestisce il routing dei pacchetti.
Bilanciatore del carico delle applicazioni esterno regionale	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64 L'inserimento nella lista consentita degli intervalli di probe di controllo di integrità di Google non è obbligatorio per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e zonali in un singolo servizio di backend, devi inserire nella lista consentita gli intervalli di sonde di controllo di integrità di Google per i NEG zonali.	La subnet solo proxy configurata.

Importante: assicurati di consentire i pacchetti dagli intervalli di controllo di integrità completo. Se la regola firewall consente i pacchetti solo da un sottoinsieme di intervalli, potresti notare errori di controllo di integrità perché il bilanciatore del carico non riesce a comunicare con i tuoi backend. Ciò causa risposte HTTP 502.

Assistenza GKE

GKE utilizza i bilanciatori del carico delle applicazioni esterni nei seguenti modi:

• I gateway esterni creati utilizzando il controller GKE Gateway possono utilizzare qualsiasi modalità di un bilanciatore del carico delle applicazioni esterno. Puoi controllare la modalità del bilanciatore del carico scegliendo un valore GatewayClass. Il controller GKE Gateway utilizza sempre i backend NEG GCE_VM_IP_PORT zonali.

• Gli ingressi esterni creati utilizzando il controller Ingress GKE sono sempre bilanciatori del carico delle applicazioni classici. Il controller in entrata GKE preferisce utilizzare i backend NEG a livello di zona GCE_VM_IP_PORT, anche se sono supportati anche i backend di gruppo di istanze.

• Puoi utilizzare NEG di zona GCE_VM_IP_PORT creati e gestiti da GKE Services come backend per qualsiasi bilanciatore del carico delle applicazioni o bilanciatore del carico di rete proxy. Per ulteriori informazioni, consulta Bilanciamento del carico nativo del container tramite NEG a livello di zona standalone.

Architettura VPC condiviso

I bilanciatori del carico delle applicazioni esterni supportano le reti che utilizzano il VPC condiviso. VPC condiviso consente alle organizzazioni di connettere risorse di più progetti a una rete VPC comune in modo che possano comunicare tra loro in modo sicuro ed efficiente utilizzando indirizzi IP interni di quella rete. Se non hai ancora familiarità con il VPC condiviso, leggi la panoramica del VPC condiviso.

Esistono molti modi per configurare un bilanciatore del carico delle applicazioni esterno all'interno di una rete VPC condiviso. Indipendentemente dal tipo di implementazione, tutti i componenti del bilanciatore del carico devono trovarsi nella stessa organizzazione.

Bilanciatore del carico	Componenti frontend	Componenti di backend
Bilanciatore del carico delle applicazioni esterno globale	Se utilizzi una rete VPC condivisa per i tuoi backend, crea la rete richiesta nel progetto host VPC condiviso. L'indirizzo IP esterno globale, la regola di forwarding, il proxy HTTP(S) di destinazione e la mappa URL associata devono essere definiti nello stesso progetto. Questo progetto può essere un progetto host o un progetto di servizio.	Puoi eseguire una delle seguenti operazioni: Crea servizi di backend e backends (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nello stesso progetto di servizio dei componenti frontend. Crea servizi di backend e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nei progetti di servizio. Una singola mappa URL può fare riferimento a servizi di backend in progetti diversi. Questo tipo di deployment è noto come riferimento ai servizi tra progetti. Ogni servizio di backend deve essere definito nello stesso progetto dei backend a cui fa riferimento. Anche i controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto del servizio di backend. I backend possono far parte di una rete VPC condiviso del progetto host o di una rete VPC autonoma, ovvero una rete VPC non condivisa nel progetto di servizio.
Bilanciatore del carico delle applicazioni classico	L'indirizzo IP esterno globale, la regola di forwarding, il proxy HTTP(S) di destinazione e la mappa URL associata devono essere definiti nello stesso progetto di host o servizio dei backend.	Un servizio di backend globale deve essere definito nello stesso progetto di host o servizio dei backends (gruppi di istanze o NEG). I controlli di integrità associati ai servizi di backend devono essere definiti anche nello stesso progetto del servizio di backend.
Bilanciatore del carico delle applicazioni esterno regionale	Crea la rete e la subnet solo proxy obbligatorie nel progetto host VPC condiviso. L'indirizzo IP esterno regionale, la regola di forwarding, il proxy HTTP(S) di destinazione e la mappa URL associata devono essere definiti nello stesso progetto. Questo progetto può essere il progetto host o un progetto di servizio.	Puoi eseguire una delle seguenti operazioni: Crea servizi di backend e backends (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nello stesso progetto di servizio dei componenti frontend. Crea servizi di backend e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) in quanti progetti di servizio necessari. Una singola mappa URL può fare riferimento a servizi di backend in progetti diversi. Questo tipo di deployment è noto come riferimento ai servizi tra progetti. Ogni servizio di backend deve essere definito nello stesso progetto dei backend a cui fa riferimento. I controlli di integrità associati ai servizi di backend devono essere definiti anche nello stesso progetto del servizio di backend.

Sebbene sia possibile creare tutti i componenti e i backend di bilanciamento del carico nel progetto host VPC condiviso, questo tipo di deployment non separa le responsabilità di amministrazione della rete e di sviluppo del servizio.

Tutti i componenti e i backend del bilanciatore del carico in un progetto di servizio

Il seguente diagramma di architettura mostra un deployment standard di VPC condiviso in cui tutti i componenti e i backend del bilanciatore del carico si trovano in un progetto di servizio. Questo tipo di implementazione è supportato da tutti i bilanciatori del carico delle applicazioni.

I componenti e i backend del bilanciatore del carico devono utilizzare la stessa rete VPC.

Bilanciatore del carico delle applicazioni esterno regionale sulla VPC condiviso condivisa

Backend serverless in un ambiente VPC condiviso

Per un bilanciatore del carico che utilizza un backend NEG serverless, il servizio di backend Cloud Run o Cloud Functions deve trovarsi nello stesso progetto del NEG serverless.

Inoltre, per il bilanciatore del carico delle applicazioni esterno regionale che supporta il riferimento ai servizi tra progetti, il servizio di backend, il NEG serverless e il servizio Cloud Run devono sempre trovarsi nello stesso progetto di servizio.

Riferimenti ai servizi tra progetti

In questo modello, il frontend e la mappa di URL del bilanciatore del carico si trovano in un progetto di servizio o host. I servizi di backend e i backend del bilanciatore del carico possono essere distribuiti tra i progetti nell'ambiente VPC condiviso. È possibile fare riferimento ai servizi di backend tra progetti in una singola mappa URL. Questo è noto come riferimento ai servizi tra progetti.

Il riferimento ai servizi tra progetti consente alle organizzazioni di configurare un bilanciatore del carico centralizzato e instradare il traffico verso centinaia di servizi distribuiti su più progetti diversi. Puoi gestire centralmente tutte le regole e i criteri di routing del traffico in una mappa URL. Puoi anche associare il bilanciatore del carico a un singolo insieme di nomi host e certificati SSL. Di conseguenza, puoi ottimizzare il numero di bilanciatori del carico necessari per implementare l'applicazione e ridurre la governabilità, i costi operativi e i requisiti di quota.

Avere progetti diversi per ciascuno dei tuoi team funzionali ti consente anche di ottenere una separazione dei ruoli all'interno della tua organizzazione. I proprietari di servizi possono concentrarsi sulla creazione di servizi nei progetti di servizi, mentre i team di rete possono eseguire il provisioning e la manutenzione dei bilanciatori del carico in un altro progetto. Entrambi possono essere collegati utilizzando il riferimento ai servizi tra progetti.

I proprietari di servizi possono mantenere l'autonomia sull'esposizione dei propri servizi e controllare quali utenti possono accedere ai loro servizi utilizzando il bilanciatore del carico. Questo viene ottenuto tramite un ruolo IAM speciale chiamato ruolo Utente dei servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser).

Per scoprire come configurare VPC condiviso per un bilanciatore del carico delle applicazioni esterno regionale, con o senza riferimenti ai servizi tra progetti, consulta Configurare un bilanciatore del carico delle applicazioni esterno regionale con VPC condiviso.

Limitazioni note relative ai riferimenti ai servizi tra progetti

• Il riferimento ai servizi tra progetti può essere utilizzato con gruppi di istanze, NEG serverless e la maggior parte degli altri tipi di backend supportati. Tuttavia, si applicano le seguenti limitazioni:

  • Con i bilanciatori del carico delle applicazioni esterni globali, non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha i seguenti backend:

    • Bucket di backend
    • NEG serverless con App Engine
  • Con i bilanciatori del carico delle applicazioni esterni regionali, non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha backend NEG internet regionali.
• Il riferimento ai servizi tra progetti non è supportato per l'Application Load Balancer classico.
• Google Cloud non distingue le risorse (ad esempio i servizi di backend) che utilizzano lo stesso nome in più progetti. Pertanto, quando utilizzi il riferimento ai servizi tra progetti, ti consigliamo di utilizzare nomi di servizio di backend univoci nei progetti della tua organizzazione.

Esempio 1: frontend e backend del bilanciatore del carico in progetti di servizi diversi

Di seguito è riportato un esempio di deployment in cui la mappa URL e il frontend del bilanciatore del carico vengono creati nel progetto di servizio A e la mappa URL fa riferimento a un servizio di backend nel progetto di servizio B.

In questo caso, gli amministratori di rete o del bilanciatore del carico nel progetto di servizio A richiederanno l'accesso ai servizi di backend nel progetto di servizio B. Gli amministratori del progetto di servizio B grantano il ruolo IAM compute.loadBalancerServiceUser agli amministratori del bilanciatore del carico nel progetto di servizio A che vogliono fare riferimento al servizio di backend nel progetto di servizio B.

Frontend e backend del bilanciatore del carico in progetti di servizi diversi

Esempio 2: frontend del bilanciatore del carico nel progetto host e backend nei progetti di servizio

In questo tipo di implementazione, la mappa URL e il frontend del bilanciatore del carico vengono creati nel progetto host e i servizi di backend (e i backend) vengono creati nei progetti di servizio.

In questo caso, gli amministratori di rete o del bilanciatore del carico nel progetto host dovranno avere accesso ai servizi di backend nel progetto di servizio. Gli amministratori del progetto di servizio devono concedere il ruolo IAM compute.loadBalancerServiceUser agli amministratori del bilanciatore del carico nel progetto host A che vogliono fare riferimento al servizio di backend nel progetto di servizio.

Frontend del bilanciatore del carico e mappa URL nel progetto host

Come funzionano le connessioni

Connessioni del bilanciatore del carico delle applicazioni esterno globale

I bilanciatori del carico delle applicazioni esterni globali sono implementati da molti proxy chiamati Google Front End (GFEs). Non esiste un solo proxy. Nel livello Premium, lo stesso indirizzo IP esterno globale viene pubblicizzato da vari punti di presenza e le richieste dei client vengono indirizzate al GFE più vicino al client.

A seconda della posizione dei client, più GFE possono avviare connessioni HTTP(S) ai tuoi backend. I pacchetti inviati dai GFE hanno indirizzi IP di origine dello stesso intervallo utilizzato dai probe del controllo di integrità: 35.191.0.0/16 e 130.211.0.0/22.

Nota: per i NEG internet, le richieste del bilanciatore del carico provengono da intervalli IP diversi a seconda del tipo di NEG (globale o regionale). Per ulteriori informazioni, consulta Autenticazione delle richieste.

A seconda della configurazione del servizio di backend, il protocollo utilizzato da ogni GFE per connettersi ai tuoi backend può essere HTTP, HTTPS o HTTP/2. Per le connessioni HTTP o HTTPS, la versione HTTP utilizzata è HTTP 1.1.

Il keepalive HTTP è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. I keepalive HTTP tentano di utilizzare in modo efficiente la stessa sessione TCP, ma non c'è alcuna garanzia. La GFE utilizza un timeout keepalive HTTP del client di 610 secondi e un valore predefinito del timeout keepalive del backend di 600 secondi. Puoi aggiornare il timeout keepalive HTTP del client, ma il valore del timeout keepalive del backend è fisso. Puoi configurare il timeout della richiesta/risposta impostando il timeout del servizio di backend. Sebbene strettamente correlati, un keepalive HTTP e un timeout di inattività TCP non sono la stessa cosa. Per ulteriori informazioni, consulta Timeout e tentativi di nuovo invio.

Per garantire che il carico venga bilanciato in modo uniforme, il bilanciatore del carico potrebbe chiudere correttamente una connessione TCP inviando un pacchetto FIN ACK dopo aver completato una risposta che includeva un'intestazione Connection: close oppure potrebbe emettere un frame HTTP/2GOAWAY dopo aver completato una risposta. Questo comportamento non interferisce con le richieste o le risposte attive.

Il numero di connessioni HTTP e sessioni TCP varia a seconda del numero di GFE che si connettono, del numero di client che si connettono ai GFE, del protocollo per i backend e della posizione in cui vengono eseguiti i deployment dei backend.

Per ulteriori informazioni, consulta Come funzionano i bilanciatori del carico delle applicazioni esterni nella guida alle soluzioni: Ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale.

Connessioni del bilanciatore del carico delle applicazioni esterno regionale

Il bilanciatore del carico delle applicazioni esterno regionale è un servizio gestito implementato sul proxy Envoy. L'Application Load Balancer esterno regionale utilizza una subnet condivisa chiamata subnet solo proxy per eseguire il provisioning di un insieme di indirizzi IP utilizzati da Google per eseguire i proxy Envoy per tuo conto. Il flag --purpose per questa subnet solo proxy è impostato su REGIONAL_MANAGED_PROXY. Tutti i bilanciatori del carico basati su Envoy a livello di regione in una determinata rete e regione condividono questa subnet.

I client utilizzano l'indirizzo IP e la porta del bilanciatore del carico per connettersi al bilanciatore del carico. Le richieste del client vengono indirizzate alla subnet solo proxy nella stessa regione del client. Il bilanciatore del carico termina le richieste dei client e poi apre nuove connessioni dalla subnet solo proxy ai tuoi backend. Pertanto, i pacchetti inviati dal bilanciatore del carico hanno indirizzi IP di origine della sottorete solo proxy.

A seconda della configurazione del servizio di backend, il protocollo utilizzato dai proxy Envoy per connettersi ai tuoi backend può essere HTTP, HTTPS o HTTP/2. Se HTTP o HTTPS, la versione HTTP è HTTP 1.1. Il keepalive HTTP è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. Il proxy Envoy imposta sia il timeout keepalive HTTP del client sia il timeout keepalive del backend su un valore predefinito di 600 secondi ciascuno. Puoi aggiornare il timeout keepalive HTTP del client, ma il valore del timeout keepalive del backend è fisso. Puoi configurare il timeout della richiesta/risposta impostando il timeout del servizio di backend. Per ulteriori informazioni, consulta timeout e tentativi di nuovo invio.

Comunicazioni del client con il bilanciatore del carico

• I client possono comunicare con il bilanciatore del carico utilizzando il protocollo HTTP 1.1 o HTTP/2.
• Quando viene utilizzato HTTPS, i client moderni utilizzano per impostazione predefinita HTTP/2. Questo viene controllato sul client, non sul bilanciatore del carico HTTPS.
• Non puoi disattivare HTTP/2 apportando una modifica alla configurazione del bilanciatore del carico. Tuttavia, puoi configurare alcuni client in modo che utilizzino HTTP 1.1 anziché HTTP/2. Ad esempio, con curl, utilizza il parametro --http1.1.
• I bilanciatori del carico delle applicazioni esterni supportano la risposta HTTP/1.1 100 Continue.

Per l'elenco completo dei protocolli supportati dalle regole di inoltro del bilanciatore del carico delle applicazioni esterno in ogni modalità, consulta Funzionalità del bilanciatore del carico.

Indirizzi IP di origine per i pacchetti client

L'indirizzo IP di origine dei pacchetti, come visto dai backend, non è l'indirizzo IP esterno di Google Cloud del bilanciatore del carico. In altre parole, esistono due connessioni TCP.

Per i bilanciatori del carico delle applicazioni esterni globali:

• Connessione 1, dal client originale al bilanciatore del carico (GFE):

  • Indirizzo IP di origine: il client originale (o indirizzo IP esterno se il client si trova dietro NAT o un proxy in avanti).
  • Indirizzo IP di destinazione:l'indirizzo IP del bilanciatore del carico.

• Connessione 2, dal bilanciatore del carico (GFE) all'endpoint o alla VM di backend:

  • Indirizzo IP di origine:un indirizzo IP in uno degli intervalli specificati in Regole firewall.

  • Indirizzo IP di destinazione:l'indirizzo IP interno della VM o del contenitore di backend nella rete VPC.

Nota: per i NEG di internet, le richieste dal bilanciatore del carico provengono da diversi intervalli IP. Per ulteriori informazioni, consulta la sezione Autenticazione delle richieste.

Per i bilanciatori del carico delle applicazioni esterni regionali:

• Connessione 1, dal client originale al bilanciatore del carico (subnet solo proxy):

  • Indirizzo IP di origine: il client originale (o indirizzo IP esterno se il client si trova dietro NAT o un proxy in avanti).
  • Indirizzo IP di destinazione:l'indirizzo IP del bilanciatore del carico.

• Connessione 2, dal bilanciatore del carico (subnet solo proxy) alla VM o all'endpoint di backend:

  • Indirizzo IP di origine:un indirizzo IP nella subnet solo proxy condiviso tra tutti i bilanciatori del carico basati su Envoy di cui è stato eseguito il deployment nella stessa regione e nella stessa rete del bilanciatore del carico.

  • Indirizzo IP di destinazione:l'indirizzo IP interno della VM o del contenitore di backend nella rete VPC.

Percorsi di routing speciali

Google Cloud utilizza route speciali non definite nella rete VPC per instradare i pacchetti per i seguenti tipi di traffico:

• Per i controlli di integrità, ad eccezione dei controlli di integrità di Envoy distribuiti. Per ulteriori informazioni, consulta Percorsi per i controlli di integrità.

• Tra i GFE e i backend dei bilanciatori del carico delle applicazioni esterni globali e dei bilanciatori del carico delle applicazioni classici. Per ulteriori informazioni, consulta Percorsi tra front-end e backend di Google.

Google Cloud utilizza le route delle subnet per le subnet solo proxy per indirizzare i pacchetti per i seguenti tipi di traffico:

• Quando utilizzi i controlli di integrità di Envoy distribuiti.

Per i bilanciatori del carico delle applicazioni esterni regionali, Google Cloud utilizza i proxy Envoy open source per terminare le richieste dei client al bilanciatore del carico. Il bilanciatore del carico termina la sessione TCP e apre una nuova sessione TCP dalla subnet solo proxy della regione al tuo backend. Le route definite all'interno della rete VPC facilitano la comunicazione dai proxy Envoy ai backend e dai backend ai proxy Envoy.

Porte aperte

I GFE hanno diverse porte aperte per supportare altri servizi Google che funzionano sulla stessa architettura. Quando esegui una scansione delle porte, potresti vedere altre porte aperte per altri servizi Google in esecuzione su GFEs.

Entrambi i bilanciatori del carico basati su GFE, ovvero i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni classici, mostrano sempre le porte 80 e 443 come aperte (insieme a qualsiasi altra porta configurata nelle regole di inoltro del bilanciatore del carico). Tuttavia, se non hai configurato una regola di forwarding per la porta 80 o per la porta 443, tutte le connessioni inviate a queste porte vengono rifiutate. Al contrario, i bilanciatori del carico delle applicazioni esterni regionali vengono implementati utilizzando i proxy Envoy e non mostrano porte aperte aggiuntive durante una scansione.

Eseguire una scansione delle porte sull'indirizzo IP di un bilanciatore del carico basato su GFE non è utile dal punto di vista del controllo per i seguenti motivi:

• Una scansione delle porte (ad esempio con nmap) in genere non prevede alcun pacchetto di risposta o un pacchetto TCP RST durante l'esecuzione del probing SYN TCP. I GFE inviano pacchetti SYN-ACK in risposta a sondaggi SYN solo per le porte su cui hai configurato una regola di forwarding. I GFE inviano pacchetti ai tuoi backend solo in risposta ai pacchetti inviati all'indirizzo IP e alla porta di destinazione del bilanciatore del carico configurati nella regola di forwarding. I pacchetti inviati a un indirizzo IP o a una porta diversa non vengono inviati ai tuoi backend.

  I GFE implementano funzionalità di sicurezza come Google Cloud Armor. Con Google Cloud Armor Standard, gli GFEs offrono protezione continua dagli attacchi DDoS volumetrici e basati su protocollo e dai flood SYN. Questa protezione è disponibile anche se non hai configurato esplicitamente Google Cloud Armor. Ti verrà addebitato solo se configuri i criteri di sicurezza o se ti registri a Managed Protection Plus.

• I pacchetti inviati all'indirizzo IP del bilanciatore del carico possono essere gestiti da qualsiasi GFE nel parco di Google. Tuttavia, la scansione di un indirizzo IP del bilanciatore del carico e di una combinazione di porta di destinazione interroga solo un singolo GFE per connessione TCP. L'indirizzo IP del bilanciatore del carico non è assegnato a un singolo dispositivo o sistema. Pertanto, l'analisi dell'indirizzo IP di un bilanciatore del carico basato su GFE non esegue la scansione di tutti i GFE nel parco risorse di Google.

Tenendo presente questo, di seguito sono riportati alcuni modi più efficaci per eseguire la verifica della sicurezza delle istanze di backend:

• Un revisore della sicurezza deve ispezionare la configurazione delle regole di inoltro per la configurazione del bilanciatore del carico. Le regole di inoltro definiscono la porta di destinazione per la quale il bilanciatore del carico accetta i pacchetti e li inoltra ai backend. Per i bilanciatori del carico basati su GFE, ogni regola di inoltro esterno può fare riferimento a una sola porta TCP di destinazione. Per un bilanciatore del carico che utilizza la porta TCP 443, viene utilizzata la porta UDP 443 quando viene eseguito l'upgrade della connessione a QUIC (HTTP/3).

• Un revisore della sicurezza deve ispezionare la configurazione delle regole del firewall applicabile alle VM di backend. Le regole del firewall che imposti bloccano il traffico dalle GFE alle VM di backend, ma non bloccano il traffico in entrata verso le GFE. Per le best practice, consulta la sezione sulle regole del firewall.

terminazione TLS

La seguente tabella riassume il modo in cui la terminazione TLS viene gestita dai bilanciatori del carico delle applicazioni esterni.

Modalità del bilanciatore del carico	terminazione TLS
Bilanciatore del carico delle applicazioni esterno globale	TLS viene terminato su una GFE, che può trovarsi in qualsiasi parte del mondo.
Bilanciatore del carico delle applicazioni classico	TLS viene terminato su una GFE, che può trovarsi ovunque nel mondo.
Bilanciatore del carico delle applicazioni esterno regionale	TLS viene terminato sui proxy Envoy situati in una subnet solo proxy in una regione scelta dall'utente. Utilizza questa modalità del bilanciatore del carico se hai bisogno di un controllo geografico sulla regione in cui viene terminato TLS.

Timeout e nuovi tentativi

I bilanciatori del carico delle applicazioni esterni supportano i seguenti tipi di timeout per il traffico HTTP/HTTPS:

Tipo e descrizione del timeout	Valori predefiniti	Supporta valori di timeout personalizzati
		Globale	Classico	Regionale
Timeout del servizio di backend^1 Un timeout per le richieste e le risposte. Rappresenta il tempo massimo consentito tra l'invio da parte del bilanciatore del carico del primo byte di una richiesta al backend e il ritorno da parte del backend dell'ultimo byte della risposta HTTP al bilanciatore del carico. Se il backend non ha restituito l'intera risposta HTTP al bilanciatore del carico entro questo limite di tempo, i dati della risposta rimanenti vengono eliminati.	Per NEG serverless su un servizio di backend: 60 minuti Per tutti gli altri tipi di backend in un servizio di backend: 30 secondi Per i bucket di backend: 24 ore (86.400 secondi)
Timeout keepalive HTTP del client Il tempo massimo durante il quale la connessione TCP tra un client e il proxy del bilanciatore del carico può essere inattiva. La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP. Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni classici, il proxy del bilanciatore del carico è un GFE di primo livello. Per i bilanciatori del carico delle applicazioni esterni regionali, il proxy del bilanciatore del carico è il software Envoy.	Per un bilanciatore del carico delle applicazioni esterno globale e un bilanciatore del carico delle applicazioni classico: 610 secondi Per un bilanciatore del carico delle applicazioni esterno regionale: 600 secondi
Timeout keepalive HTTP del backend Il tempo massimo di inattività della connessione TCP tra il proxy del bilanciatore del carico e un backend. La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP. Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni classici, il proxy del bilanciatore del carico è un GFE di secondo livello. Per i bilanciatori del carico delle applicazioni esterni regionali, il proxy del bilanciatore del carico è il software Envoy.	Per i servizi di backend: 10 minuti (600 secondi) Per i bucket di backend: 6 minuti (360 secondi)
Timeout di inattività della sessione QUIC Il tempo massimo di inattività di una sessione QUIC tra il client (a valle) e il GFE di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico.	Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni classici: Il timeout di inattività della sessione QUIC è il valore minimo del timeout di inattività del client o del timeout di inattività della GFE (300 secondi). Il timeout di inattività GFE è fissato a 300 secondi. È possibile configurare il timeout per inattività del client.

¹Non configurabile per i backend NEG serverless. Non configurabile per i bucket di backend.

Timeout del servizio di backend

Il timeout del servizio di backend configurabile rappresenta il tempo massimo che il bilanciatore del carico attende che il backend elabori una richiesta HTTP e restituisca la risposta HTTP corrispondente. Ad eccezione dei NEG serverless, il valore predefinito per il timeout del servizio di backend è 30 secondi.

Ad esempio, se vuoi scaricare un file da 500 MB e il valore del timeout del servizio di backend è 90 secondi, il bilanciatore del carico si aspetta che il backend invii l'intero file da 500 MB entro 90 secondi. È possibile configurare il timeout del servizio di backend in modo che non sia sufficiente per consentire al backend di inviare la risposta HTTP completa. In questa situazione, se il bilanciatore del carico ha ricevuto almeno le intestazioni di risposta HTTP dal backend, restituisce le intestazioni di risposta complete e la maggior parte del corpo della risposta che è riuscito a ottenere entro il timeout del servizio di backend.

Devi impostare il timeout del servizio di backend sul periodo di tempo più lungo che prevedi che il backend debba impiegare per elaborare una risposta HTTP. Devi aumentare il timeout del servizio di backend se il software in esecuzione sul tuo backend ha bisogno di più tempo per elaborare una richiesta HTTP e restituire l'intera risposta. Ad esempio, devi aumentare il timeout se visualizzi risposte HTTP 408 con jsonPayload.statusDetail client_timed_out.

Il timeout del servizio di backend accetta valori compresi tra 1 e 2,147,483,647 secondi; tuttavia, i valori più elevati non sono opzioni di configurazione pratiche. Inoltre, Google Cloud non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intero valore del timeout del servizio di backend. Nel caso degli bilanciatori di carico delle applicazioni classici e globali, i GFE impongono un timeout massimo effettivo del servizio di backend di 86,400 secondi (1 giorno). I sistemi client devono implementare la logica di ripetizione anziché fare affidamento su una connessione TCP aperta per lunghi periodi di tempo.

Per configurare il timeout del servizio di backend, utilizza uno dei seguenti metodi:

Console

Modifica il campo Timeout del servizio di backend del bilanciatore del carico.

gcloud

Utilizza il comando gcloud compute backend-services update per modificare il parametro --timeout della risorsa del servizio di backend.

API

Per un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico, modifica il parametro timeoutSec per la risorsa backendServices globale.

Per un bilanciatore del carico delle applicazioni esterno regionale, modifica il parametro timeoutSec per la risorsa regionBackendServices.

I timeout delle connessioni WebSocket non corrispondono sempre ai timeout servizio di backend. I timeout di connessione Websocket dipendono dal tipo di bilanciatore del carico:

Modalità del bilanciatore del carico	Valori predefiniti	Descrizione del timeout per i websocket
Bilanciatore del carico delle applicazioni esterno globale	servizio di backend timeout: 30 seconds	Le connessioni WebSocket attive non utilizzano il timeout del servizio di backend configurato del bilanciatore del carico. Le connessioni vengono chiuse automaticamente dopo 24 ore (86.400 secondi). Questo limite di 24 ore è fisso e sostituisce il timeout del servizio di backend se è superiore a 24 ore. Le connessioni WebSocket inattive vengono chiuse dopo il timeout del servizio di backend. Non consigliamo valori di timeout del servizio di backend superiori a 24 ore (86.400 secondi) perché Google Cloud riavvia periodicamente i GFE per gli aggiornamenti software e altre operazioni di manutenzione di routine. Il valore del timeout del servizio di backend non ritarda le attività di manutenzione. Maggiore è il valore del timeout del servizio di backend, maggiore è la probabilità che Google Cloud interrompa le connessioni TCP per la manutenzione.
Bilanciatore del carico delle applicazioni classico	servizio di backend timeout: 30 seconds	Le connessioni WebSocket, inattive o attive, si chiudono automaticamente dopo il timeout del servizio di backend. Non consigliamo valori di timeout del servizio di backend superiori a 24 ore (86.400 secondi) perché Google Cloud riavvia periodicamente i GFE per gli aggiornamenti software e altre operazioni di manutenzione di routine. Il valore del timeout del servizio di backend non ritarda le attività di manutenzione. Maggiore è il valore del timeout del servizio di backend, maggiore è la probabilità che Google Cloud interrompa le connessioni TCP per la manutenzione.
Bilanciatore del carico delle applicazioni esterno regionale	servizio di backend timeout: 30 seconds	Le connessioni WebSocket attive non utilizzano il timeout del servizio di backend del bilanciatore del carico. Le connessioni WebSocket inattive vengono chiuse dopo il timeout del servizio di backend. Google Cloud riavvia o modifica periodicamente il numero di attività software di Envoy per il servizio. Maggiore è il valore del timeout del servizio di backend, più è probabile che le attività Envoy riavviino o interrompano le connessioni TCP.

I bilanciatori del carico delle applicazioni esterni regionali utilizzano il parametro routeActions.timeout configurato delle mappe URL e ignorano il timeout del servizio di backend. Quando routeActions.timeout non è configurato, viene utilizzato il valore del timeout del servizio di backend. Quando viene fornito routeActions.timeout, il timeout del servizio di backend viene ignorato e viene utilizzato il valore di routeActions.timeout come timeout per le richieste e le risposte.

Timeout keepalive HTTP del client

Il timeout keepalive HTTP del client rappresenta il tempo massimo che una connessione TCP può rimanere inattiva tra il client (a valle) e uno dei seguenti tipi di proxy:

• Per un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico: un Google Front End (GFE) di primo livello

• Per un bilanciatore del carico delle applicazioni esterno regionale: un proxy Envoy

Un timeout keepalive HTTP rappresenta il timeout di inattività TCP per le connessioni TCP sottostanti. Il timeout keepalive HTTP del client non si applica ai websocket.

• Per un bilanciatore del carico delle applicazioni esterno globale, il valore predefinito è 610 secondi. Puoi configurare il timeout keepalive HTTP del client con un valore tra 5 e 1200 secondi.
• Per un bilanciatore del carico delle applicazioni classico, il timeout keepalive HTTP del client è fissato a 610 secondi.
• Per un bilanciatore del carico delle applicazioni esterno regionale, il valore predefinito è 600 secondi. Puoi configurare il timeout keepalive HTTP del client con un valore tra 5 e 600 secondi.

Per configurare il parametro di timeout keepalive, utilizza uno dei seguenti metodi:

Console

Modifica il campo Timeout keepalive HTTP della configurazione del frontend del bilanciatore del carico.

gcloud

Utilizza il comando gcloud compute target-http-proxies update o il comando gcloud compute target-https-proxies update per modificare il parametro --http-keep-alive-timeout-sec del proxy HTTP di destinazione o della risorsa proxy HTTPS di destinazione.

Nota:

Per un bilanciatore del carico delle applicazioni esterno regionale, non puoi aggiornare direttamente il parametro di timeout keepalive di un proxy HTTP(S) target regionale. Per aggiornare il parametro di timeout keepalive di un proxy di destinazione a livello di regione, devi procedere nel seguente modo:

1. Crea un nuovo proxy di destinazione con le impostazioni di timeout previste.
2. Esegui il mirroring di tutte le altre impostazioni del proxy target attuale su quello nuovo. Per i proxy HTTPS di destinazione, è incluso il collegamento di eventuali certificati SSL o mappe dei certificati al nuovo proxy di destinazione.
3. Aggiorna le regole di inoltro in modo che rimandino al nuovo proxy di destinazione.
4. Elimina il vecchio proxy di destinazione.

API

Modifica il parametro httpKeepAliveTimeoutSec per la risorsa targetHttpProxies o la risorsa targetHttpsProxies.

Nota:

Per un bilanciatore del carico delle applicazioni esterno regionale, non puoi aggiornare direttamente il parametro di timeout keepalive di un proxy HTTP(S) target regionale. Per aggiornare il parametro di timeout keepalive di un proxy di destinazione a livello di regione, devi procedere nel seguente modo:

1. Crea un nuovo proxy di destinazione con le impostazioni di timeout previste.
2. Esegui il mirroring di tutte le altre impostazioni del proxy target attuale su quello nuovo. Per i proxy HTTPS di destinazione, è incluso il collegamento di eventuali certificati SSL o mappe dei certificati al nuovo proxy di destinazione.
3. Aggiorna le regole di inoltro in modo che rimandino al nuovo proxy di destinazione.
4. Elimina il vecchio proxy di destinazione.

Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del timeout keepalive HTTP (inattività TCP) utilizzato dai client o dai proxy a valle. Se un client a valle ha un timeout keepalive HTTP (inattività TCP) maggiore rispetto al timeout keepalive HTTP del client del bilanciatore del carico, è possibile che si verifichi una condizione di gara. Dal punto di vista di un client a valle, è consentito che una connessione TCP stabilita rimanga inattiva per più tempo di quanto consentito dal bilanciatore del carico. Ciò significa che il client downstream può inviare pacchetti dopo che il bilanciatore del carico considera chiusa la connessione TCP. In questo caso, il bilanciatore del carico risponde con un pacchetto di reset TCP (RST).

Timeout keepalive HTTP del backend

I bilanciatori del carico delle applicazioni esterni sono proxy che utilizzano almeno due connessioni TCP:

• Per un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico, esiste una prima connessione TCP tra il client (a valle) e un GFE di primo livello. I GFE di primo livello si connettono ai GFE di secondo livello, che a loro volta aprono una seconda connessione TCP ai tuoi backend.

• Per un bilanciatore del carico delle applicazioni esterno regionale, esiste una prima connessione TCP tra il client (a valle) e un proxy Envoy. Il proxy Envoy apre quindi una seconda connessione TCP ai tuoi backend.

Le connessioni TCP secondarie del bilanciatore del carico potrebbero non chiudersi dopo ogni richiesta; possono rimanere aperte per gestire più richieste e risposte HTTP. Il timeout keepalive HTTP del backend definisce il timeout di inattività TCP tra il bilanciatore del carico e i backend. Il timeout keepalive HTTP del backend non si applica ai websocket.

Il timeout keepalive del backend è fissato a 10 minuti (600 secondi) e non può essere modificato. Il timeout keepalive del backend del bilanciatore del carico deve essere inferiore al timeout keepalive utilizzato dal software in esecuzione sui backend. In questo modo si evita una race condition in cui il sistema operativo dei tuoi backend potrebbe chiudere le connessioni TCP con un reset TCP (RST). Poiché il timeout keepalive del backend per il bilanciatore del carico non è configurabile, devi configurare il software di backend in modo che il valore del timeout keepalive HTTP (inattività TCP) sia superiore a 600 secondi.

La tabella seguente elenca le modifiche necessarie per modificare i valori del timeout keepalive per il software del server web comune.

Software del server web	Parametro	Impostazione predefinita	Impostazione consigliata
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Timeout di inattività della sessione QUIC

Il timeout di inattività della sessione QUIC rappresenta il tempo massimo che una sessione QUIC può rimanere inattiva tra il client e il GFE di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico.

Il valore del timeout di inattività della sessione QUIC è definito come il valore minimo del timeout di inattività del client o del timeout di inattività GFE (300 secondi). Il timeout di inattività GFE è fissato a 300 secondi. È possibile configurare il timeout per inattività del client.

Nuovi tentativi

Il supporto della logica di ripetizione dipende dalla modalità del bilanciatore del carico delle applicazioni esterno.

Modalità del bilanciatore del carico	Logica di ripetizione
Bilanciatore del carico delle applicazioni esterno globale	Configurabile utilizzando un criterio di ripetizione nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1. Il numero massimo di tentativi che possono essere configurati utilizzando i criteri di ripetizione è 25. Il valore perTryTimeout configurabile massimo è 24 ore. Senza un criterio di ripetizione, le richieste non andate a buon fine che non hanno un corpo HTTP (ad esempio le richieste GET) che generano risposte HTTP 502, 503 o 504 (retryConditions=["gateway-error"]) vengono ripetute una volta. Le richieste HTTP POST non vengono ripetute. Le richieste di cui è stato eseguito il riavvio generano una sola voce di log per la risposta finale.
Bilanciatore del carico delle applicazioni classico	Il criterio di ripetizione non può essere modificato per le ripetizioni della connessione. Le richieste POST HTTP non vengono ripetute. Le richieste HTTP GET vengono sempre riprovate una volta, purché almeno l'80% dei backend sia integro. Se in un gruppo è presente una singola istanza di backend e la connessione a questa istanza non va a buon fine, la percentuale di istanze di backend non integre è pari al 100%, pertanto GFE non riprova a inviare la richiesta. Il bilanciatore del carico riprova una richiesta GET non riuscita se la prima richiesta non è riuscita prima di ricevere le intestazioni di risposta dall'istanza di backend. Le richieste di cui è stato eseguito il riavvio generano una sola voce di log per la risposta finale. Per ulteriori informazioni, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno. Le richieste non andate a buon fine fanno sì che il bilanciatore del carico sintetizzi una risposta HTTP 502.
Bilanciatore del carico delle applicazioni esterno regionale	Configurabile utilizzando un criterio per i tentativi ripetuti nella mappa URL. Il numero predefinito di tentativi (numRetries) è 1. Il numero massimo di tentativi che possono essere configurati utilizzando il criterio di ripetizione è 25. Il valore perTryTimeout configurabile massimo è 24 ore. Senza un criterio di ripetizione, le richieste non andate a buon fine che non hanno un corpo HTTP (ad esempio le richieste GET) che generano risposte HTTP 502, 503 o 504 vengono ripetute una volta. Le richieste POST HTTP non vengono ripetute. Le richieste di cui è stato eseguito il riavvio generano una sola voce di log per la risposta finale.

Il protocollo WebSocket è supportato con GKE Ingress.

Gestione di richieste e risposte non consentite

Il bilanciatore del carico impedisce alle richieste del client e alle risposte del backend di raggiungere rispettivamente il backend o il client per una serie di motivi. Alcuni motivi sono strettamente per la conformità a HTTP/1.1 e altri per evitare che i dati inaspettati vengano trasmessi ai o dai backend. Nessun controllo può essere disattivato.

Il bilanciatore del carico blocca le seguenti richieste per la conformità a HTTP/1.1:

• Non può analizzare la prima riga della richiesta.
• In un'intestazione manca il delimitatore due punti (:).
• Le intestazioni o la prima riga contengono caratteri non validi.
• La lunghezza dei contenuti non è un numero valido o sono presenti più intestazioni della lunghezza dei contenuti.
• Esistono più chiavi di codifica di trasferimento o valori di codifica di trasferimento non riconosciuti.
• Il corpo non è suddiviso in blocchi e non è specificata la lunghezza dei contenuti.
• I chunk del corpo non sono analizzabili. Questo è l'unico caso in cui alcuni dati raggiungono il backend. Il bilanciatore del carico chiude le connessioni al client e al backend quando riceve un chunk non analizzabile.

Gestione delle richieste

Il bilanciatore del carico blocca la richiesta se una delle seguenti condizioni è vera:

• La dimensione totale delle intestazioni della richiesta e dell'URL richiesta supera il limite per la dimensione massima dell'intestazione della richiesta per i bilanciatori del carico delle applicazioni esterni.
• Il metodo di richiesta non consente un corpo, ma la richiesta ne ha uno.
• La richiesta contiene un'intestazione Upgrade e l'intestazione Upgrade non viene utilizzata per attivare le connessioni WebSocket.
• La versione HTTP è sconosciuta.

Gestione della risposta

Il bilanciatore del carico blocca la risposta del backend se una delle seguenti condizioni è vera:

• Le dimensioni totali delle intestazioni di risposta superano il limite di dimensione massima delle intestazioni di risposta per i bilanciatori del carico delle applicazioni esterni.
• La versione HTTP è sconosciuta.

Quando gestisce sia la richiesta sia la risposta, il bilanciatore del carico potrebbe rimuovere o sovrascrivere le intestazioni hop-by-hop in HTTP/1.1 prima di inoltrarle alla destinazione prevista.

Distribuzione del traffico

Quando aggiungi un gruppo di istanza di backend o un gruppo NEG a un servizio di backend, specifichi una modalità di bilanciamento, che definisce un metodo per misurare il carico del backend e una capacità target. I bilanciatori del carico delle applicazioni esterni supportano due modalità di bilanciamento:

• RATE, ad esempio gruppi o NEG, è il numero massimo target di richieste (query) al secondo (RPS, QPS). Il valore RPS/QPS massimo target può essere superato se tutti i backend sono al limite o al di sopra della capacità.

• UTILIZATION è l'utilizzo del backend delle VM in un gruppo di istanze.

La modalità di distribuzione del traffico tra i backend dipende dalla modalità del bilanciatore del carico.

Bilanciatore del carico delle applicazioni esterno globale

Prima che un Google Front End (GFE) invii richieste alle istanze di backend, stima quali istanze di backend hanno la capacità di ricevere richieste. Questa stima della capacità viene effettuata in modo proattivo, non contemporaneamente all'arrivo delle richieste. I GFEs ricevono informazioni periodiche sulla capacità disponibile e distribuiscono di conseguenza le richieste in arrivo.

Il significato di capacità dipende in parte dalla modalità di bilanciamento. Per la modalità RATE è relativamente semplice: un GFE determina esattamente quante richieste può assegnare al secondo. Il bilanciamento del carico basato su UTILIZATION è più complesso: il bilanciatore del carico controlla l'utilizzo corrente delle istanze e poi stima un carico di query che ogni istanza può gestire. Questa stima cambia nel tempo con l'utilizzo delle istanze e la variazione dei pattern di traffico.

Entrambi i fattori, la stima della capacità e l'assegnazione proattiva, influiscono sulla distribuzione tra le istanze. Pertanto, Cloud Load Balancing si comporta diversamente da un semplice bilanciatore del carico round robin che distribuisce le richieste esattamente 50:50 tra due istanze. Il bilanciamento del carico di Google Cloud, invece, tenta di ottimizzare la selezione dell'istanza di backend per ogni richiesta.

Per il bilanciatore del carico delle applicazioni esterno globale, il bilanciamento del carico è a due livelli. La modalità di bilanciamento determina il peso o la frazione di traffico da inviare a ciascun backend (gruppo di istanze o NEG). Il criterio di bilanciamento del carico (LocalityLbPolicy) determina poi la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo. Per ulteriori informazioni, consulta i Criteri di località per il bilanciamento del carico (documentazione dell'API del servizio di backend).

Per il bilanciatore del carico delle applicazioni classico, la modalità di bilanciamento viene utilizzata per selezionare il backend più favorevole (gruppo di istanze o NEG). Il traffico viene poi distribuito in modo round robin tra le istanze o gli endpoint all'interno del backend.

Come vengono distribuite le richieste

I bilanciatori del carico delle applicazioni esterni basati su GFE utilizzano la seguente procedura per distribuire le richieste in arrivo:

1. Dal client al GFE di primo livello. I router di confine pubblicizzano l'indirizzo IP esterno della regola di forwarding ai confini della rete di Google. Ogni annuncio elenca un hop successivo a un sistema di bilanciamento del carico di livello 3/4 (Maglev). I sistemi Maglev indirizzano il traffico a un Google Front End (GFE) di primo livello.
   • Quando utilizzi il livello Premium, Google pubblicizza l'indirizzo IP del bilanciatore del carico da tutti i punti di presenza in tutto il mondo. Ogni indirizzo IP del bilanciatore del carico è anycast globale.
   • Quando utilizzi il livello standard, Google pubblicizza l'indirizzo IP del bilanciatore del carico dai punti di presenza associati alla regione della regola di forwarding. Il bilanciatore del carico utilizza un indirizzo IP esterno regionale. L'utilizzo di una regola di forwarding di livello standard ti limita ai backend NEG di gruppi di istanze e zonali nella stessa regione della regola di forwarding del bilanciatore del carico.
2. Dal GFE di primo livello al GFE di secondo livello. Il GFE di primo livello termina TLS, se necessario, e poi instrada il traffico ai GFE di secondo livello secondo la seguente procedura:
   • I GFE di primo livello analizzano la mappa URL e selezionano un servizio di backend o un bucket di backend.
   • Per i servizi di backend con NEG di internet, le GFE di primo livello selezionano un gateway di inoltro esterno di secondo livello co-allocato con la GFE di primo livello. Il gateway di inoltro invia le richieste all'endpoint NEG internet. Questo conclude la procedura di distribuzione delle richieste per i NEG internet.
   • Per i servizi di backend con NEG serverless e NEG Private Service Connect (PSC) e bucket di backend a singola regione, le GFE di primo livello selezionano una GFE di secondo livello nella regione corrispondente a quella del NEG o del bucket. Per i bucket Cloud Storage multiregione, i GFE di primo livello selezionano GFE di secondo livello nella regione del bucket o in una regione il più vicino possibile al bucket multiregione (definito dal tempo di percorrenza della rete).
   • Per i servizi di backend con gruppi di istanze, NEG a livello di zona con GCE_VM_IP_PORT endpoint e NEG ibride, il sistema di gestione della capacità di Google informa i GFE di primo livello sulla capacità utilizzata e configurata per ogni backend. La capacità configurata per un backend è definita dalla modalità di bilanciamento, dalla capacità target della modalità di bilanciamento e dal gestore della scalabilità della capacità.
     • Livello standard:i GFE di primo livello selezionano un GFE di secondo livello nella regione contenente i backend.
     • Livello Premium: i GFE di primo livello selezionano i GFE di secondo livello da un insieme di regioni applicabili. Le regioni applicabili sono tutte le regioni in cui sono stati configurati i backend, escluse quelle con backend configurati con una capacità pari a zero. I GFE di primo livello selezionano il GFE di secondo livello più vicino in una regione applicabile (definita dal tempo di round trip della rete). Se i backend sono configurati in due o più regioni, i GFE di primo livello possono ridistribuire le richieste in altre regioni applicabili se una regione di prima scelta è piena. Lo spillover in altre regioni è possibile quando tutti i backend della regione di prima scelta sono al limite della capacità.
3. I GFEs di secondo livello selezionano i backend. I GFE di secondo livello si trovano nelle zone di una regione. Per selezionare un backend, utilizza la seguente procedura:
   • Per i servizi di backend con NEG serverless, NEG Private Service Connect e bucket di backend, i GFE di secondo livello inoltrano le richieste ai sistemi di produzione di Google. Questo conclude la procedura di distribuzione delle richieste per questi backend.

   • Per i servizi di backend con gruppi di istanze, NEG zonali con endpoint GCE_VM_IP_PORT e NEG ibride, i sistemi di sonde di controllo di Google informano i GFE di secondo livello sullo stato del controllo di integrità delle istanze o degli endpoint di backend.

     Solo livello Premium: se il GFE di secondo livello non ha istanze o endpoint di backend integri nella propria regione, potrebbe inviare richieste a un altro GFE di secondo livello in una regione applicabile diversa con backend configurati. Lo spillover tra GFEs di secondo livello in regioni diverse non esaurisce tutte le possibili combinazioni da regione a regione. Se devi allontanare il traffico dai backend in una determinata regione, anziché configurare i backend in modo che non superino i controlli di integrità, devi impostare lo scalare della capacità del backend su zero in modo che il GFE di primo livello escluda la regione durante il passaggio precedente.

   Il GFE di secondo livello indirizza quindi le richieste alle istanze o agli endpoint di backend nelle zone all'interno della sua regione, come descritto nel passaggio successivo.

4. Il secondo livello GFE seleziona una zona. Per impostazione predefinita, le GFE di secondo livello utilizzano l'algoritmo WATERFALL_BY_REGION in cui ogni GFE di secondo livello preferisce selezionare istanze o endpoint di backend nella stessa zona della zona che contiene la GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo il traffico tra le zone, a bassi livelli di richieste, ogni GFE di secondo livello potrebbe inviare esclusivamente richieste ai backend nella stessa zona del GFE di secondo livello stesso.

   Solo per i bilanciatori del carico delle applicazioni esterni globali, i GFE di secondo livello possono essere configurati per utilizzare uno dei seguenti algoritmi alternativi utilizzando un serviceLbPolicy:

   • SPRAY_TO_REGION: i GFE di secondo livello non preferiscono selezionare istanze o endpoint di backend nella stessa zona del GFE di secondo livello. I GFEs di secondo livello tentano di distribuire il traffico a tutte le istanze o gli endpoint di backend in tutte le zone della regione. Ciò può portare a una distribuzione più uniforme del carico a spese di un aumento del traffico tra le zone.
   • WATERFALL_BY_ZONE: per i GFE di secondo livello è vivamente consigliato selezionare istanze o endpoint di backend nella stessa zona del GFE di secondo livello. I GFE di secondo livello indirizzano le richieste ai backend in zone diverse solo dopo che tutti i backend nella zona corrente hanno raggiunto le loro capacità configurate.
5. Il secondo livello GFE seleziona le istanze o gli endpoint all'interno della zona. Per impostazione predefinita, un GFE di secondo livello distribuisce le richieste tra i backend in modo round robin. Solo per i bilanciatori del carico delle applicazioni esterni globali, puoi modificare questo valore utilizzando un criterio di località per il bilanciamento del carico (localityLbPolicy). Il criterio di località per il bilanciamento del carico si applica solo ai backend all'interno della zona selezionata discussa nel passaggio precedente.

Bilanciatore del carico delle applicazioni esterno regionale

Per i bilanciatori del carico delle applicazioni esterni regionali, la distribuzione del traffico si basa sulla modalità di bilanciamento del carico e sul criterio di bilanciamento del carico per le località.

La modalità di bilanciamento determina il peso e la frazione di traffico da inviare a ciascun gruppo (gruppo di istanze o NEG). Il criterio di località del bilanciamento del carico (LocalityLbPolicy) determina in che modo il bilanciamento del carico viene applicato ai backend all'interno del gruppo.

Quando un servizio di backend riceve traffico, lo indirizza innanzitutto a un backend (gruppo di istanze o NEG) in base alla modalità di bilanciamento del backend. Dopo aver selezionato un backend, il traffico viene distribuito tra le istanze o gli endpoint del gruppo di backend in base al criterio di località del bilanciamento del carico.

Per ulteriori informazioni, consulta le seguenti risorse:

• Modalità di bilanciamento
• Criterio di bilanciamento del carico per le località (documentazione dell'API del servizio di backend regionale).

Affinità sessione

L'affinità sessione esegue un tentativo secondo il criterio del massimo impegno per inviare richieste da un determinato client allo stesso backend finché il backend è integro e dispone della capacità necessaria, in base alla modalità di bilanciamento configurata.

Quando utilizzi l'affinità sessione, ti consigliamo la modalità di bilanciamento RATE anziché UTILIZATION. L'affinità di sessione funziona al meglio se imposti la modalità di bilanciamento su richieste al secondo (RPS).

I bilanciatori del carico delle applicazioni esterni offrono i seguenti tipi di affinità sessione:

• NESSUNO. L'affinità sessione non è impostata per il bilanciatore del carico.
• Affinità IP client
• Affinità cookie generata
• Affinità dei campi intestazione
• Affinità dei cookie HTTP
• Affinità sessione basata su cookie stateful

Nella tabella seguente sono riepilogate le opzioni di affinità sessione supportate dai bilanciatori del carico delle applicazioni esterni:

Modalità del bilanciatore del carico	Opzioni di affinità sessione
	Nessuna	IP client	Cookie generato	Campo intestazione	Cookie HTTP	Cookie stateful
Bilanciatore del carico delle applicazioni esterno globale
Bilanciatore del carico delle applicazioni classico
Bilanciatore del carico delle applicazioni esterno regionale

Alta disponibilità e failover

L'alta disponibilità e il failover nei bilanciatori del carico delle applicazioni esterni possono essere configurati a livello di bilanciatore del carico. Questo viene gestito creando bilanciatori del carico delle applicazioni esterni regionali di backup in qualsiasi regione in cui è necessario il backup.

La tabella seguente descrive il comportamento del failover.

Modalità del bilanciatore del carico	Metodi di failover
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico	Puoi configurare una configurazione di failover attivo-passivo in cui il traffico viene eseguito in un bilanciatore del carico delle applicazioni esterno regionale di riserva. Utilizzi i controlli di integrità per rilevare le interruzioni e i criteri di routing Cloud DNS per instradare il traffico quando viene attivato il failover.
Bilanciatore del carico delle applicazioni esterno regionale	Utilizza uno dei seguenti metodi per garantire un deployment di alta disponibilità: Puoi configurare una configurazione di failover attivo-passivo in cui il traffico viene eseguito in un bilanciatore del carico delle applicazioni esterno regionale di riserva. Utilizzi i controlli di integrità per rilevare le interruzioni e un criterio di routing per il failover di Cloud DNS per instradare il traffico quando il failover viene attivato da controlli di integrità non riusciti. Per maggiori dettagli, consulta Failover per bilanciatori del carico delle applicazioni esterni. Puoi configurare una configurazione di failover attivo-attivo in cui esegui il deployment di più bilanciatori del carico delle applicazioni esterni regionali individuali nelle regioni che ritieni supportino al meglio il traffico per la tua applicazione. Utilizza un criterio di routing per la geolocalizzazione di Cloud DNS per instradare il traffico alla regione appropriata in base all'origine della richiesta del client. Puoi anche utilizzare i controlli di integrità per rilevare le interruzioni e instradare il traffico solo ai bilanciatori del carico integri. Per dettagli, consulta Elevata disponibilità per i bilanciatori del carico delle applicazioni esterni regionali.

Supporto HTTP/2

HTTP/2 è una revisione importante del protocollo HTTP/1. HTTP/2 è supportato per le connessioni tra i client e il bilanciatore del carico delle applicazioni esterno e per le connessioni tra il bilanciatore del carico e i relativi backend.

Il bilanciatore del carico negozia automaticamente HTTP/2 con i client nell'ambito dell'handshake TLS utilizzando l'estensione TLS ALPN. Anche se un bilanciatore del carico è configurato per utilizzare HTTPS, i client moderni utilizzano per impostazione predefinita HTTP/2. Questo viene controllato sul lato client, non sul bilanciatore del carico.

Se un client non supporta HTTP/2 e il bilanciatore del carico è configurato per utilizzare HTTP/2 tra il bilanciatore del carico e le istanze di backend, il bilanciatore del carico potrebbe comunque negoziare una connessione HTTPS o accettare richieste HTTP non sicure. Queste richieste HTTPS o HTTP vengono poi trasformate dal bilanciatore del carico in modo da eseguire il proxy delle richieste tramite HTTP/2 alle istanze di backend.

Per utilizzare HTTP/2, devi attivare TLS sui tuoi backend. Per ulteriori informazioni, consulta Crittografia dal bilanciatore del carico ai backend.

Flussi simultanei massimi HTTP/2

L'impostazione HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descrive il numero massimo di stream accettati da un endpoint, iniziati dal peer. Il valore pubblicizzato da un client HTTP/2 a un bilanciatore del carico Google Cloud non ha alcun significato perché il bilanciatore del carico non avvia stream per il client.

Nei casi in cui il bilanciatore del carico utilizza HTTP/2 per comunicare con un server in esecuzione su una VM, rispetta il valore SETTINGS_MAX_CONCURRENT_STREAMS pubblicizzato dal server. Se viene pubblicizzato un valore di zero, il bilanciatore del carico non può inoltrare le richieste al server e questo potrebbe causare errori.

Limitazioni di HTTP/2

• HTTP/2 tra il bilanciatore del carico e l'istanza può richiedere molto più connessioni TCP all'istanza rispetto a HTTP(S). Il pool di connessioni, un'ottimizzazione che riduce il numero di queste connessioni con HTTP(S), non è attualmente disponibile con HTTP/2. Di conseguenza, potresti notare latenze elevate del backend perché le connessioni al backend vengono effettuate più di frequente.
• HTTP/2 tra il bilanciatore del carico e il backend non supporta l'esecuzione del protocollo WebSocket su un singolo stream di una connessione HTTP/2 (RFC 8441).
• HTTP/2 tra il bilanciatore del carico e il backend non supporta il push del server.
• Il tasso di errore e il volume delle richieste gRPC non sono visibili nell'API Google Cloud o nella console Google Cloud. Se l'endpoint gRPC restituisce un errore, i log del bilanciatore del carico e i dati di monitoraggio segnalano il codice di risposta HTTP OK 200.

Supporto di HTTP/3

HTTP/3 è un protocollo internet di nuova generazione. È basato su IETF QUIC, un protocollo sviluppato dal protocollo Google QUIC originale. HTTP/3 è supportato tra il bilanciatore del carico delle applicazioni esterno, Cloud CDN e i client.

Il supporto di Google QUIC (noto anche come gQUIC) è stato rimosso ad aprile 2023 a favore di HTTP/3 su QUIC IETF, che è sia uno standard IETF sia dimostrato di avere un rendimento migliore rispetto a gQUIC.

In particolare:

• IETF QUIC è un protocollo di livello di trasporto che offre un controllo della congestione e un'affidabilità simili a TCP, utilizza TLS 1.3 per la sicurezza e offre prestazioni migliorate.
• HTTP/3 è un livello di applicazione basato su QUIC IETF e si basa su QUIC per gestire il multiplexing, il controllo della congestione, il rilevamento delle perdite e la ritrasmissione.
• HTTP/3 consente un avvio più rapido della connessione client, elimina i blocchi head-of-line nei flussi multiplex e supporta la migrazione di connessioni quando un indirizzo IP client viene modificato.
• HTTP/3 è supportato per le connessioni tra i client e il bilanciatore del carico, ma non per le connessioni tra il bilanciatore del carico e i relativi backend.
• Le connessioni HTTP/3 utilizzano l'algoritmo per il controllo della congestione BBR.

HTTP/3 sul bilanciatore del carico può migliorare i tempi di caricamento delle pagine web, ridurre il buffering dei video e migliorare il throughput su connessioni con latenza più elevata.

La tabella seguente specifica il supporto di HTTP/3 per i bilanciatori del carico delle applicazioni esterni in ogni modalità.

Modalità del bilanciatore del carico	Supporto di HTTP/3
Bilanciatore del carico delle applicazioni esterno globale (sempre livello Premium)
Bilanciatore del carico delle applicazioni classico nel livello Premium
Bilanciatore del carico delle applicazioni classico nel livello Standard
Bilanciatore del carico delle applicazioni esterno regionale (livello Premium o Standard)

Come viene negoziato HTTP/3

Quando HTTP/3 è abilitato, il bilanciatore del carico pubblicizza questo supporto ai client, consentendo ai client che supportano HTTP/3 di tentare di stabilire connessioni HTTP/3 con il bilanciatore del carico HTTPS.

• I client implementati correttamente ricorrono sempre a HTTPS o HTTP/2 quando non riescono a stabilire una connessione HTTP/3.
• I client che supportano HTTP/3 utilizzano le conoscenze a priori memorizzate nella cache dell'assistenza HTTP/3 per risparmiare viaggi di andata e ritorno non necessari in futuro.
• Grazie a questo fallback, l'attivazione o la disattivazione di HTTP/3 nel bilanciatore del carico non interrompe la capacità del bilanciatore del carico di connettersi ai client.

Il supporto è pubblicizzato nell'Alt-Svc intestazione della risposta HTTP. Quando HTTP/3 è abilitato, le risposte del bilanciatore del carico includono il seguente valore dell'intestazione alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Nota: l'intestazione Alt-Svc pubblicizza più versioni di HTTP/3 per supportare le bozze precedenti utilizzate da alcuni client, ad esempio h3-29.

Se HTTP/3 è stato impostato esplicitamente su DISABLE, le risposte non includono un'intestazione di risposta alt-svc.

Quando hai attivato HTTP/3 sul bilanciatore del carico HTTPS, in alcune circostanze il client può eseguire il fallback su HTTPS o HTTP/2 anziché negoziare HTTP/3. Di seguito sono elencati alcuni esempi:

• Quando un client supporta versioni di HTTP/3 non compatibili con le versioni HTTP/3 supportate dal bilanciatore del carico HTTPS.
• Quando il bilanciatore del carico rileva che il traffico UDP è bloccato o limitato in modo da impedire il funzionamento di HTTP/3.
• Il client non supporta affatto HTTP/3 e, di conseguenza, non tenta di negoziare una connessione HTTP/3.

Quando una connessione passa a HTTPS o HTTP/2, non lo conteggiamo come un guasto del bilanciatore del carico.

Prima di attivare HTTP/3, assicurati che i comportamenti descritti in precedenza siano accettabili per i tuoi carichi di lavoro.

Configurare HTTP/3

Sia NONE (il valore predefinito) sia ENABLE attivano il supporto HTTP/3 per il bilanciatore del carico.

Quando HTTP/3 è abilitato, il bilanciatore del carico lo pubblicizza ai client, il che consente ai client che lo supportano di negoziare una versione HTTP/3 con il bilanciatore del carico. I client che non supportano HTTP/3 non negoziano una connessione HTTP/3. Non è necessario disattivare esplicitamente HTTP/3, a meno che non siano state identificate implementazioni client non funzionanti.

I bilanciatori del carico delle applicazioni esterni offrono tre modi per configurare HTTP/3, come mostrato nella tabella seguente.

Valore quicOverride	Comportamento
NONE	Il supporto di HTTP/3 viene pubblicizzato ai client.
ENABLE	Il supporto di HTTP/3 viene pubblicizzato ai client. Nota: TLS 0-RTT (noto anche come TLS Early Data) non è ancora supportato per HTTP/3.
DISABLE	Disattiva esplicitamente la pubblicità HTTP/3 e Google QUIC per i clienti.

Per attivare (o disattivare) esplicitamente HTTP/3:

Console: HTTPS

Nota: l'impostazione della negoziazione HTTP/3 non è attualmente supportata nella pagina dei proxy di destinazione e deve essere configurata modificando la configurazione del bilanciatore del carico.

1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.

Vai a Bilanciamento del carico

1. Seleziona il bilanciatore del carico da modificare.
2. Fai clic su Configurazione frontend.
3. Seleziona l'indirizzo IP e la porta del frontend che vuoi modificare. Per modificare una configurazione HTTP/3, il protocollo deve essere HTTPS.

Attivare HTTP/3

1. Seleziona il menu Negoziazione QUIC.
2. Per attivare esplicitamente HTTP/3 per questo frontend, seleziona Attivato.
3. Se hai più regole frontend che rappresentano IPv4 e IPv6, assicurati di attivare HTTP/3 su ogni regola.

Disattivare HTTP/3

1. Seleziona il menu Negoziazione QUIC.
2. Per disattivare esplicitamente HTTP/3 per questo frontend, seleziona Disattivato.
3. Se hai più regole frontend che rappresentano IPv4 e IPv6, assicurati di disattivare HTTP/3 per ogni regola.

gcloud: HTTPS

Prima di eseguire questo comando, devi creare una risorsa del certificato SSL per ogni certificato.

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

Sostituisci QUIC_SETTING con una delle seguenti opzioni:

• NONE (valore predefinito): consente a Google di controllare quando viene pubblicizzato HTTP/3.

  Se selezioni NONE, HTTP/3 viene pubblicizzato ai clienti, ma Google QUIC no. Nella console Google Cloud, questa opzione è chiamata Automatico (predefinito).

• ENABLE: pubblicizza HTTP/3 ai client.

• DISABLE: non pubblicizza HTTP/3 ai client.

API: HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

Sostituisci QUIC_SETTING con una delle seguenti opzioni:

• NONE (valore predefinito): consente a Google di controllare quando viene pubblicizzato HTTP/3.

  Se selezioni NONE, HTTP/3 viene pubblicizzato ai clienti, ma Google QUIC no. Nella console Google Cloud, questa opzione è chiamata Automatico (predefinito).

• ENABLE: pubblicizza HTTP/3 e Google QUIC per i client.

• DISABLE: non pubblicizza HTTP/3 o Google QUIC ai client.

Supporto WebSocket

I bilanciatori del carico basati su HTTP(S) di Google Cloud supportano il protocollo WebSocket quando utilizzi HTTP o HTTPS come protocollo per il backend. Il bilanciatore del carico non richiede alcuna configurazione per il proxy delle connessioni WebSocket.

Il protocollo WebSocket fornisce un canale di comunicazione full-duplex tra i client e il bilanciatore del carico. Per maggiori informazioni, consulta la RFC 6455.

Il protocollo WebSocket funziona nel seguente modo:

1. Il bilanciatore del carico riconosce una richiesta Upgrade websocket da un client HTTP(S). La richiesta contiene le intestazioni Connection: Upgrade, Upgrade: websocket, seguite da altre intestazioni delle richieste pertinenti relative a websocket.
2. Il backend invia una risposta Upgrade websocket. L'istanza di backend invia una risposta 101 switching protocol con intestazioni Connection: Upgrade, Upgrade: websocket e altre intestazioni di risposta relative a WebSocket.
3. Il bilanciatore del carico esegue il proxy del traffico bidirezionale per la durata della connessione corrente.

Se l'istanza di backend restituisce una risposta di errore con il codice di risposta 426 o 502, il bilanciatore del carico chiude la connessione.

I timeout delle connessioni WebSocket dipendono dal tipo di bilanciatore del carico (globale, regionale o classico). Per maggiori dettagli, vedi Timeout del servizio di backend.

L'affinità sessione per i websocket funziona come per qualsiasi altra richiesta. Per ulteriori informazioni, consulta Affinità della sessione.

Supporto gRPC

gRPC è un framework open source per le chiamate di procedura remota. È basato sullo standard HTTP/2. I casi d'uso di gRPC includono:

• Sistemi distribuiti a bassa latenza e altamente scalabili
• Sviluppo di client mobile che comunicano con un server cloud
• Progettazione di nuovi protocolli che devono essere accurati, efficienti e indipendenti dal linguaggio
• Progettazione a più livelli per consentire l'estensione, l'autenticazione e la registrazione

Per utilizzare gRPC con le tue applicazioni Google Cloud, devi eseguire il proxy delle richieste end-to-end tramite HTTP/2. Per farlo:

1. Configura un bilanciatore del carico HTTPS.
2. Attiva HTTP/2 come protocollo dal bilanciatore del carico ai backend.

Il bilanciatore del carico negozia HTTP/2 con i client nell'ambito dell'handshake SSL utilizzando l'estensione TLS ALPN.

Il bilanciatore del carico potrebbe comunque negoziare HTTPS con alcuni client o accettare richieste HTTP non sicure su un bilanciatore del carico configurato per utilizzare HTTP/2 tra il bilanciatore del carico e le istanze di backend. Queste richieste HTTP o HTTPS vengono trasformate dal bilanciatore del carico per eseguire il proxy delle richieste tramite HTTP/2 alle istanze di backend.

Devi attivare TLS sui tuoi backend. Per ulteriori informazioni, vedi Crittografia dal bilanciatore del carico ai backend.

Se vuoi configurare un bilanciatore del carico delle applicazioni esterno utilizzando HTTP/2 con Google Kubernetes Engine Ingress o gRPC e HTTP/2 con Ingress, consulta HTTP/2 per il bilanciamento del carico con Ingress.

Per informazioni sulla risoluzione dei problemi relativi a HTTP/2, consulta Risoluzione dei problemi relativi a HTTP/2 per i backend.

Per informazioni sulle limitazioni di HTTP/2, vedi Limitazioni di HTTP/2.

Supporto TLS

Per impostazione predefinita, un proxy target HTTPS accetta solo TLS 1.0, 1.1, 1.2 e 1.3 quando termina le richieste SSL del client.

Quando il bilanciatore del carico utilizza HTTPS come protocollo del servizio di backend, può negoziare TLS 1.0, 1.1, 1.2 o 1.3 con il backend.

Supporto TLS reciproco

TLS reciproco, o mTLS, è un protocollo standard di settore per l'autenticazione reciproca tra un client e un server. Garantisce che sia il client sia il server si autentichino tra loro verificando che ciascuno detenga un certificato valido emesso da un'autorità di certificazione (CA) attendibile. A differenza del TLS standard, in cui viene autenticato solo il server, mTLS richiede che sia il client sia il server presentino certificati, confermando le identità di entrambe le parti prima che la comunicazione sia stabilita.

Tutti i bilanciatori del carico delle applicazioni supportano mTLS. Con mTLS, il bilanciatore del carico richiede al client di inviare un certificato per autenticarsi durante l'handshake TLS con il bilanciatore del carico. Puoi configurare un gestore dei certificati per l'autenticazione dei certificati client.

Per ulteriori informazioni su mTLS, vedi Autenticazione TLS reciproca.

Limitazioni

• I bilanciatori del carico HTTPS non inviano un close_notify avviso di chiusura quando terminano le connessioni SSL. In altre parole, il bilanciatore del carico chiude la connessione TCP instead of performing an SSL shutdown.
• I bilanciatori del carico HTTPS supportano solo caratteri minuscoli nei domini in un attributo nome comune (CN) o in un attributo nome alternativo dell'oggetto (SAN) del certificato. I certificati con caratteri maiuscoli nei domini vengono riportati solo se impostati come certificato principale nel proxy di destinazione.
• I bilanciatori del carico HTTPS non utilizzano l'estensione SNI (Server Name Indication) quando si connettono al backend, ad eccezione dei bilanciatori del carico con backend di NEG internet. Per ulteriori dettagli, vedi Crittografia dal bilanciatore del carico ai backend.

• Quando utilizzi bilanciatori del carico delle applicazioni esterni regionali con Cloud Run in un ambiente VPC condiviso, le reti VPC autonome nei progetti di servizio possono inviare traffico a qualsiasi altro servizio Cloud Run di cui è stato eseguito il deployment in qualsiasi altro progetto di servizio nello stesso ambiente VPC condiviso. Si tratta di un problema noto e questa forma di accesso verrà bloccata in futuro.

• Google Cloud non garantisce che una connessione TCP di base possa rimanere aperta per l'intero valore del timeout del servizio di backend. I sistemi client devono implementare la logica di ripetizione anziché fare affidamento su una connessione TCP aperta per lunghi periodi di tempo.

• Non puoi creare un bilanciatore del carico delle applicazioni esterno regionale nel livello Premium utilizzando la console Google Cloud. Inoltre, nella console Google Cloud sono disponibili solo le regioni che supportano il livello Standard per questi bilanciatori del carico. Utilizza invece l'interfaccia a riga di comando gcloud o l'API. Utilizza invece l'interfaccia a riga di comando gcloud o l'API.

• Cloud CDN ti consente di forzare un oggetto o un insieme di oggetti da ignorare dalla cache richiedendo un annullamento della convalida della cache. Quando utilizzi un bilanciatore del carico delle applicazioni esterno globale con riferimento ai servizi tra progetti VPC condiviso, per impostazione predefinita, gli amministratori dei progetti di servizio non avranno le autorizzazioni necessarie per richiedere l'invalidazione della cache. Questo accade perché l'invalidazione della cache è configurata nel progetto frontend (ovvero il progetto che contiene la regola di forwarding, il proxy di destinazione e la mappa URL del bilanciatore del carico). Pertanto, l'invalidazione della cache può essere emessa solo dalle entità che dispongono dei ruoli IAM per la configurazione delle risorse correlate al bilanciatore del carico nei progetti frontend (ad esempio, il ruolo Amministratore della rete Compute). Gli amministratori dei servizi, che controllano il provisioning dei servizi di backend in un progetto distinto, dovranno collaborare con l'amministratore del bilanciatore del carico del progetto frontend per emettere l'invalidazione della cache per i propri servizi tra progetti.

Passaggi successivi

• Per scoprire come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno globale, consulta Configurare un bilanciatore del carico delle applicazioni esterno con un backend Compute Engine.

• Per scoprire come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno regionale, consulta Configurare un bilanciatore del carico delle applicazioni esterno regionale con un backend Compute Engine.

• Se sei già un utente del bilanciatore del carico delle applicazioni classico, assicurati di esaminare la Panoramica della migrazione quando pianifichi un nuovo deployment con il bilanciatore del carico delle applicazioni esterno globale.

• Per scoprire come automatizzare la configurazione del bilanciatore del carico delle applicazioni esterno con Terraform, consulta Esempi di moduli Terraform per bilanciatori del carico delle applicazioni esterni.

• Per scoprire come configurare le funzionalità di gestione avanzata del traffico disponibili con l'Application Load Balancer esterno globale, consulta la Panoramica della gestione del traffico per bilanciatori del carico delle applicazioni esterni globali.

• Per scoprire come configurare le funzionalità di gestione avanzata del traffico disponibili con il bilanciatore del carico delle applicazioni esterno regionale, consulta la panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali.

• Per scoprire di più sulla pubblicazione di siti web, consulta Pubblicazione di siti web.

• Per trovare le sedi dei PoP di Google, consulta Località GFE.

• Per informazioni sulla gestione della capacità, consulta il tutorial sulla gestione della capacità con il bilanciamento del carico e le Ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale.

• Per scoprire come utilizzare Certificate Manager per eseguire il provisioning e gestire i certificati SSL, consulta la panoramica di Certificate Manager.

• Per inserire la logica personalizzata nel percorso dati del bilanciamento del carico, configura i callout o i plug-in di Service Extensions.

• Solo per gli Application Load Balancer esterni regionali, puoi provare a utilizzare Apigee Shadow API Discovery per trovare API shadow (note anche come API non documentate) nell'infrastruttura Google Cloud esistente. Assicurati di leggere le limitazioni associate prima di attivare il rilevamento delle API shadow.