Panoramica del bilanciatore del carico delle applicazioni esterno

Questo documento introduce i concetti necessari per comprendere come 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. L'Application Load Balancer esterno distribuisce il traffico HTTP e HTTPS sui backend ospitati su diverse piattaforme Google Cloud (come Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage e così via), nonché ai backend esterni connessi su internet o tramite connettività ibrida. Per maggiori dettagli, vedi Panoramica dei bilanciatori del carico delle applicazioni: 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 avanzata del traffico come il mirroring del traffico, la suddivisione del traffico basata sulla ponderazione, le trasformazioni di intestazione basate su richiesta/risposta e altro ancora.
• Bilanciatore del carico delle applicazioni classico Questo è il bilanciatore del carico delle applicazioni esterno classico, globale nel livello Premium, ma che può essere configurato per essere 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 regione implementato come servizio gestito sul proxy Envoy open source. Include funzionalità di gestione avanzata del traffico come mirroring del traffico, suddivisione del traffico basata sui pesi, trasformazioni di intestazioni basate su richiesta/risposta e altro ancora.

Modalità 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 tramite 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, ma può essere configurato in modo da essere efficace a livello di regione nel livello Standard. Nel livello di servizio di rete premium, questo bilanciatore del carico offre bilanciamento del carico multiregionale, tenta di indirizzare il traffico al backend integro più vicino con capacità e termina il traffico HTTP(S) il più vicino possibile agli utenti. Per maggiori dettagli sul processo di distribuzione delle richieste, consulta Distribuzione del traffico. Nel livello di servizio di rete standard, il bilanciamento del carico viene gestito a livello di 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 l'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à del bilanciatore del carico delle applicazioni classico esistente, oltre a funzionalità di gestione avanzata del traffico. Utilizza questo bilanciatore del carico se vuoi gestire contenuti provenienti da una sola geolocalizzazione (ad esempio per soddisfare le normative di conformità). Questo bilanciatore del carico può essere configurato al 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 una singola regione da te configurata Pubblica contenuti solo dalla regione configurata Per l'elenco completo, vedi 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 sono visualizzati il tipo, il protocollo e la regione del bilanciatore del carico. Se la regione è vuota, il bilanciatore del carico è globale. La tabella seguente riassume come identificare la modalità del bilanciatore del carico.

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

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Nell'output 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à 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 forwarding esterno specifica un indirizzo IP esterno, una porta e un proxy HTTP(S) di destinazione. I client usano 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 routing 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 certificati SSL per dimostrare la sua 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 effettuare una determinazione del routing in base agli attributi HTTP (come il percorso della richiesta, i cookie o le intestazioni). In base alla decisione di routing, il proxy inoltra le richieste dei client a servizi o bucket di backend specifici. La mappa URL può specificare ulteriori azioni, come l'invio di reindirizzamenti ai client.

• Un servizio di backend distribuisce le richieste ai backend integri. I bilanciatori del carico delle applicazioni esterni globali supportano anche i bucket di backend.

  • Uno o più backend devono essere connessi al servizio di backend o al bucket di backend.

• Un controllo di integrità monitora periodicamente l'idoneità dei backend. In questo modo ridurrai il rischio che le richieste vengano inviate a backend che non possono gestire la richiesta.

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

Globale

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

Componenti del bilanciatore del carico delle applicazioni esterno globale

Regionale

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

Componenti del bilanciatore del carico delle applicazioni esterno regionale

Subnet solo proxy

Le subnet solo proxy sono obbligatorie solo per gli Application Load Balancer 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 Application Load Balancer 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 dalla stessa subnet solo proxy. Inoltre:

• Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i tuoi backend.
• Le VM o gli endpoint di backend di tutti gli Application Load Balancer esterni regionali in una regione e la 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 e indirizzi di forwarding

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.

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 Cloud Load Balancing ne assegni uno.

Ogni regola di forwarding per un bilanciatore del carico delle applicazioni può fare riferimento a una singola porta tra 1 e 65535. Per supportare più porte, devi configurare più regole di forwarding. Puoi configurare più regole di forwarding in modo che utilizzino lo stesso indirizzo IP esterno (VIP) e facciano riferimento allo stesso proxy HTTP(S) di destinazione, purché la combinazione complessiva di indirizzo IP, porta e protocollo sia univoca per ciascuna regola di forwarding. 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, indirizzo IP e 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 il bilanciatore del carico.

Modalità bilanciatore del carico	Livello di servizio di rete	Regola di forwarding, indirizzo IP e schema di bilanciamento del carico	Routing 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 indirizzate al GFE più vicino al client 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 client su internet.
	Livello Standard	Regola di forwarding esterno a livello di regione 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 forwarding esterno a livello di regione Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL_MANAGED	Richieste indirizzate ai proxy Envoy nella stessa regione del bilanciatore del carico.

^* Non puoi utilizzare la console Google Cloud per creare un bilanciatore del carico delle applicazioni esterno regionale nel livello Premium. Inoltre, per questi bilanciatori del carico nella console Google Cloud sono disponibili solo le regioni che supportano il livello Standard. Utilizza gcloud o l'API.

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

Proxy di destinazione

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

Non fare affidamento sul proxy per preservare i nomi delle intestazioni delle richieste o delle risposte. Ad esempio, un'intestazione della risposta Server: Apache/1.0 potrebbe essere visualizzata sul client come server: Apache/1.0.

Nota: per i gruppi di endpoint di rete (NEG), le richieste del bilanciatore del carico provengono da intervalli IP diversi in base al tipo di NEG (globale o a livello di regione). Per maggiori informazioni, consulta la sezione Autenticazione delle richieste.

La tabella seguente specifica il tipo di proxy di destinazione richiesto dai bilanciatori del carico delle applicazioni esterni in ciascuna modalità.

Modalità bilanciatore del carico	Tipi di proxy di destinazione	Intestazioni aggiunte dal proxy	Intestazioni personalizzate supportate	Supporto di Cloud Trace
Bilanciatore del carico delle applicazioni esterno globale	HTTP globale, HTTPS globale	I proxy impostano le intestazioni delle richieste/risposte HTTP nel modo seguente: Via: 1.1 google (richieste e risposte) X-Forwarded-Proto: [http | https] (solo richieste) X-Forwarded-For: [<provider-value>,]<client-ip>,<load-balancer-ip> (vedi X-Forwarded-For header) (solo richieste) Anche i proxy possono impostare l'intestazione X-Cloud-Trace-Context.	Configurato nel servizio di backend o nel bucket di backend Non supportata con Cloud CDN
Bilanciatore del carico delle applicazioni classico	HTTP globale, HTTPS globale	I proxy impostano le intestazioni delle richieste/risposte HTTP nel modo seguente: Via: 1.1 google (richieste e risposte) X-Forwarded-Proto: [http | https] (solo richieste) X-Forwarded-For: [<provider-value>,]<client-ip>,<load-balancer-ip> (vedi X-Forwarded-For header) (solo richieste) Anche i proxy possono impostare l'intestazione X-Cloud-Trace-Context.	Configurato nel servizio di backend o nel bucket di backend
Bilanciatore del carico delle applicazioni esterno regionale	HTTP regionale, HTTPS a livello di regione	X-Forwarded-Proto: [http | https] (solo richieste) Via: 1.1 google (richieste e risposte) X-Forwarded-For: [<provider-value>,]<client-ip>,<load-balancer-ip> (vedi X-Forwarded-For header) (solo richieste)

Nota: in conformità alla specifica 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, entrambe le intestazioni delle richieste e delle risposte sono sempre convertite in lettere minuscole. Ad esempio, Host diventa host e Keep-ALIVE diventa keep-alive.

  L'unica eccezione è quando utilizzi backend NEG internet globali con HTTP/1.1. Per maggiori dettagli 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 delle richieste e delle risposte vengono convertite in lettere minuscole, tranne quando si utilizza HTTP/1.1. Con HTTP/1.1, le intestazioni hanno invece le maiuscole appropriate. La prima lettera della chiave dell'intestazione e ogni lettera che segue un trattino (-) sono in maiuscolo per preservare la compatibilità con i client HTTP/1.1. Ad esempio, user-agent viene cambiato in User-Agent e content-encoding viene cambiato 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 i cui 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 effettua 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 singola virgola all'intestazione X-Forwarded-For 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 la richiesta in entrata non contiene un'intestazione X-Forwarded-For, questi due indirizzi IP corrispondono al valore completo 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 precedenti a <client-ip>,<load-balancer-ip> in questa intestazione. Gli indirizzi IP precedenti potrebbero contenere altri caratteri, inclusi spazi.

Durante l'esecuzione di un software proxy inverso per 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 del Google Front End (GFE) connesso al backend. Questi indirizzi IP sono compresi negli intervalli 130.211.0.0/22 e 35.191.0.0/16.

• L'indirizzo IP del sistema di backend stesso.

Pertanto, un processo upstream dopo il backend del bilanciatore del carico potrebbe ricevere un'intestazione X-Forwarded-For del modulo:

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

Mappe URL

Le mappe URL definiscono i pattern corrispondenti per il routing basato su URL delle richieste ai servizi di backend appropriati. Un servizio predefinito è definito per gestire tutte le richieste che non corrispondono a una regola host specificata o a una regola di corrispondenza del percorso. In alcune situazioni, come nell'esempio di bilanciamento del carico per più regioni, potresti non definire alcuna regola per gli URL e fare affidamento solo sul servizio predefinito. Per il routing delle richieste, la mappa URL ti consente di dividere il traffico esaminando i componenti dell'URL per inviare richieste a diversi set di backend.

Le mappe URL utilizzate con i bilanciatori del carico delle applicazioni esterni globali e il bilanciatore del carico delle applicazioni esterno regionale supportano diverse funzionalità avanzate di gestione del traffico, come reindirizzamento del traffico basato su intestazioni, suddivisione del traffico basata sulla ponderazione e mirroring delle richieste. Per maggiori informazioni, consulta quanto segue:

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

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

Modalità 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 di funzionalità supportate)
Bilanciatore del carico delle applicazioni esterno regionale	A livello di regione

Certificati SSL

I bilanciatori del carico delle applicazioni esterni che utilizzano i 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 l'assegnazione di chiavi private e certificati SSL ai proxy HTTPS: i certificati SSL di Compute Engine e Gestione certificati. Per una descrizione di ciascuna configurazione, vedi Metodi di configurazione dei certificati nella panoramica dei certificati SSL.

• Google Cloud offre due tipi di certificati: autogestito e gestito 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 i metodi di configurazione e i tipi di certificati supportati. Per maggiori dettagli, consulta la sezione Certificati e bilanciatori del carico Google Cloud nella panoramica dei certificati SSL.

Mutual TLS

In genere, con la comunicazione HTTPS, l'autenticazione funziona solo in un modo: il client verifica l'identità del server. Per le applicazioni che richiedono che il bilanciatore del carico autentichi l'identità dei client che si connettono allo stesso, sia un bilanciatore del carico delle applicazioni esterno globale sia un bilanciatore del carico delle applicazioni classico supportano TLS reciproco (mTLS).

Con mTLS, il bilanciatore del carico richiede al client di inviare un certificato per l'autenticazione durante l'handshake TLS con il bilanciatore del carico. Puoi configurare un archivio di attendibilità utilizzato dal bilanciatore del carico per convalidare la catena di attendibilità del certificato del client.

Google Cloud utilizza la risorsa TrustConfig in Gestore certificati per archiviare i certificati che il server utilizza per verificare il certificato presentato dal client. Se utilizzi un bilanciatore del carico delle applicazioni classico sul livello di servizio di rete premium o un bilanciatore del carico delle applicazioni esterno globale, puoi utilizzare Gestore certificati per eseguire il provisioning e gestire i certificati SSL o TrustConfig su più istanze del bilanciatore del carico su larga scala. Per ulteriori informazioni, consulta la panoramica di Gestore certificati.

Per ulteriori informazioni su mTLS, consulta Autenticazione TLS reciproca.

Criteri SSL

I criteri SSL specificano l'insieme di funzionalità SSL utilizzate dai bilanciatori del carico di Google Cloud durante la negoziazione di 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 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 di SSL con i client. Inoltre, puoi applicare questo criterio SSL al proxy HTTPS di destinazione.

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

Modalità 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 e bucket

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. I bilanciatori del carico utilizzano le informazioni in un servizio di backend per indirizzare il traffico in entrata a uno o più backend collegati. 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.

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 Configurazione di un bilanciatore del carico con bucket di backend.

La tabella seguente specifica le funzionalità di backend supportate dai bilanciatori del carico delle applicazioni esterni in ciascuna modalità.

Modalità bilanciatore del carico	Backend supportati su un servizio di backend						Supporta bucket di backend	Supporta Google Cloud Armor	Supporta Cloud CDN^#	Supporta IAP^#	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		^*

^* Utilizza endpoint di tipo GCE_VM_IP_PORT con GKE: usa NEG autonomi a livello di zona o usa Ingress

^† Utilizza endpoint di tipo GCE_VM_IP_PORT con GKE: Usa NEG autonomi a livello di zona

^‡ Supportato solo con il controller gateway GKE

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

Per ulteriori informazioni, consulta le seguenti risorse:

• Panoramica dei servizi di backend
• Che cos'è Cloud Storage?

Backend e reti VPC

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

• Per il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico, tutte le istanze di backend dei gruppi di istanze e tutti gli endpoint dei backend del NEG devono trovarsi nello stesso progetto. Tuttavia, un backend di un gruppo di istanze o un NEG può utilizzare una rete VPC diversa in quel progetto. Non è necessario connettere le diverse reti VPC tramite peering di rete VPC, poiché i GFE comunicano direttamente con i backend nelle rispettive reti VPC.
• Per l'Application Load Balancer esterno regionale, tutti i backend devono trovarsi nella stessa rete VPC e nella stessa regione.

Protocollo ai backend

Quando configuri un servizio di backend per il bilanciatore del carico, imposti il protocollo utilizzato dal servizio di backend per comunicare con i backend. Puoi scegliere HTTP, HTTPS o HTTP/2. Il bilanciatore del carico utilizza solo il protocollo da te specificato. Il bilanciatore del carico non utilizza uno degli altri protocolli se non è in grado di negoziare una connessione al backend con il protocollo specificato.

Se usi HTTP/2, devi utilizzare TLS. HTTP/2 senza crittografia non è supportato.

Per l'elenco completo dei protocolli supportati, vedi Funzionalità di bilanciamento del carico: protocolli dal bilanciatore del carico ai backend.

Supporto di WebSocket

I bilanciatori del carico basati su HTTP(S) di Google Cloud supportano integrato 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 client e server. Il canale viene avviato da una richiesta HTTP(S). Per informazioni dettagliate sul protocollo, consulta RFC 6455.

Quando il bilanciatore del carico riconosce una richiesta Upgrade di WebSocket da un client HTTP(S) seguita da una risposta Upgrade andata a buon fine dall'istanza di backend, esegue il proxy del traffico bidirezionale per la durata della connessione attuale. Se l'istanza di backend non restituisce una risposta Upgrade riuscita, il bilanciatore del carico chiude la connessione.

I timeout della connessione WebSocket dipendono dal tipo di bilanciatore del carico (globale, a livello di regione o classico). Per maggiori dettagli, consulta Timeout del servizio di backend.

L'affinità sessione per WebSocket funziona come per qualsiasi altra richiesta. Per informazioni, consulta la sezione Affinità della sessione.

Utilizzo di gRPC con le applicazioni Google Cloud

gRPC è un framework open source per le chiamate di procedure remote. Si basa sullo standard HTTP/2. I casi d'uso di gRPC includono quanto segue:

• Sistemi distribuiti a bassa latenza, altamente scalabili
• Sviluppo di client mobili che comunicano con un server cloud
• Progettare nuovi protocolli che devono essere accurati, efficienti e indipendenti dal linguaggio
• Design a più livelli per abilitare estensioni, autenticazione e logging

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

1. Configurare un bilanciatore del carico HTTPS.
2. Abilita HTTP/2 come protocollo dal bilanciatore del carico ai backend.

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

Il bilanciatore del carico può comunque negoziare HTTPS con alcuni client o accettare richieste HTTP non sicure su un bilanciatore del carico configurato per l'utilizzo di HTTP/2 tra il bilanciatore del carico e le istanze di backend. Queste richieste HTTP o HTTPS vengono trasformate dal bilanciatore del carico per eseguirne il proxy su HTTP/2 alle istanze di backend.

Devi abilitare TLS sui tuoi backend. Per ulteriori informazioni, consulta 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 la pagina Risoluzione dei problemi relativi a HTTP/2 nei backend.

Per informazioni sulle limitazioni di HTTP/2, consulta le limitazioni HTTP/2.

Controlli di integrità

Ogni servizio di backend specifica un controllo di integrità che monitora periodicamente l'idoneità dei backend a ricevere una connessione dal bilanciatore del carico. In questo modo ridurrai il rischio che le richieste vengano inviate a backend che non possono gestire la richiesta. I controlli di integrità non controllano 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 controlli di integrità provengono invece dalla subnet solo proxy. Per maggiori dettagli, consulta la panoramica dei NEG ibridi.

Protocollo di controllo di integrità

Sebbene non sia obbligatorio e non sempre possibile, è consigliabile utilizzare un controllo di integrità il cui protocollo corrisponda al protocollo del servizio di backend. Ad esempio, un controllo di integrità HTTP/2 verifica in modo più accurato la connettività HTTP/2 ai backend. Al contrario, i bilanciatori del carico delle applicazioni esterni regionali che utilizzano backend NEG ibridi, non supportano i controlli di integrità gRPC. Per l'elenco dei protocolli per il controllo di integrità supportati, vedi Funzionalità di bilanciamento del carico.

La tabella seguente specifica l'ambito dei controlli di integrità supportati da Application Load Balancer esterni in ciascuna modalità.

Modalità 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 quanto segue:

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

Regole firewall

Il bilanciatore del carico richiede le seguenti regole firewall:

• Per i bilanciatori del carico delle applicazioni esterni globali, una regola di autorizzazione in entrata per consentire al traffico dai Google Front End (GFE) di raggiungere i tuoi backend.
  Per il bilanciatore del carico delle applicazioni esterno regionale, una regola di autorizzazione in entrata per consentire al traffico dalla subnet solo proxy di raggiungere i 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 proveniente da questi probe, consulta Intervalli IP e regole firewall dei probe.

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

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

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

• Per i backend di gruppi di istanze: determina le porte da configurare mediante la mappatura tra la porta denominata del servizio di backend e i numeri di porta associati a quella porta denominata su ciascun 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à bilanciatore del carico	Intervalli di fonti dei controlli di integrità	Intervalli di origine delle richieste
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	L'origine 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	L'origine del traffico GFE dipende dal tipo di backend: Gruppi di istanze, NEG a livello di zona (GCE_VM_IP_PORT) e NEG di 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 Non è necessario aggiungere intervalli di probe per il controllo di integrità di Google a una lista consentita per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e a livello di zona in un singolo servizio di backend, devi aggiungere gli intervalli di probe del controllo di integrità di Google a una lista consentita per i NEG a livello di zona.	La subnet solo proxy che hai configurato.

Importante: assicurati di consentire i pacchetti compresi negli intervalli completi del controllo di integrità. Se la regola firewall consente i pacchetti solo da un sottoinsieme degli intervalli, potresti riscontrare errori del controllo di integrità perché il bilanciatore del carico non è in grado di comunicare con i tuoi backend. Questo causa risposte HTTP 502.

Architettura VPC condiviso

I bilanciatori del carico delle applicazioni esterni supportano le reti che utilizzano il VPC condiviso. Un 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 già familiarità con il VPC condiviso, leggi la panoramica sul 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 deployment, tutti i componenti del bilanciatore del carico devono trovarsi nella stessa organizzazione.

Bilanciatore del carico	Componenti del 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 del 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 e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nello stesso progetto di servizio dei componenti del frontend. Crea servizi 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 di servizi tra progetti ed è attualmente in anteprima. 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 host o progetto di servizio dei backend.	Un servizio di backend globale deve essere definito nello stesso host o progetto di servizio dei backend (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 richiesta e la subnet solo proxy nel progetto host del VPC condiviso. L'indirizzo IP esterno a livello di regione, 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 e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nello stesso progetto di servizio dei componenti del frontend. Crea servizi e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) in tutti i 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 di 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 del VPC condiviso, questo tipo di deployment non separa le responsabilità di amministrazione della rete e di sviluppo dei servizi.

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

Il seguente diagramma dell'architettura mostra un deployment di un VPC condiviso standard in cui tutti i componenti e i backend del bilanciatore del carico si trovano in un progetto di servizio. Questo tipo di deployment è 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 su 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 i riferimenti ai servizi tra progetti, il servizio di backend, il NEG serverless e il servizio Cloud Run devono essere sempre nello stesso progetto di servizio.

Riferimento ai servizi tra progetti

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

I riferimenti ai servizi tra progetti consentono alle organizzazioni di configurare un bilanciatore del carico centrale e di instradare il traffico a centinaia di servizi distribuiti su più progetti diversi. Puoi gestire centralmente tutte le regole e i criteri di routing del traffico in un'unica mappa URL. Puoi anche associare il bilanciatore del carico a un singolo insieme di nomi host e certificati SSL. Puoi quindi ottimizzare il numero di bilanciatori del carico necessari per il deployment dell'applicazione e ridurre la gestibilità, i costi operativi e i requisiti di quota.

Avendo diversi progetti per ogni team funzionale, puoi anche ottenere la separazione dei ruoli all'interno dell'organizzazione. I proprietari dei servizi possono concentrarsi sulla creazione di servizi nei progetti di servizio, mentre i team di rete possono eseguire il provisioning e la manutenzione dei bilanciatori del carico in un altro progetto ed entrambi possono essere connessi utilizzando il riferimento ai servizi tra progetti.

I proprietari dei servizi possono mantenere l'autonomia sull'esposizione dei loro servizi e controllare quali utenti possono accedere ai loro servizi utilizzando il bilanciatore del carico. Ciò è possibile grazie a un ruolo IAM speciale denominato ruolo Utente dei servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser).

Per scoprire come configurare un 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 con i riferimenti ai servizi tra progetti

• I riferimenti ai servizi tra progetti possono essere utilizzati 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 ha i seguenti backend:

    • Bucket di backend
    • NEG serverless con App Engine
    • NEG internet a livello globale
  • Con i bilanciatori del carico delle applicazioni esterni regionali, non puoi fare riferimento a un servizio di backend tra progetti se quest'ultimo dispone di backend NEG internet a livello di regione.
• I riferimenti ai servizi tra progetti non sono supportati per l'Application Load Balancer classico.
• Google Cloud non fa distinzione tra risorse (ad esempio, servizi di backend) utilizzando lo stesso nome in più progetti. Pertanto, se utilizzi i riferimenti ai servizi tra progetti, ti consigliamo di utilizzare nomi univoci per i servizio di backend nei progetti all'interno della tua organizzazione.

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

Ecco un esempio di deployment in cui la mappa di frontend e URL del bilanciatore del carico vengono create 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 gli amministratori del bilanciatore del carico nel progetto di servizio A dovranno accedere ai servizi di backend nel progetto di servizio B. Gli amministratori del progetto di servizio B concedono 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 servizio diversi

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

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

In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto host dovranno accedere ai servizi di backend nel progetto di servizio. Gli amministratori del progetto di servizio concedono 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 (GFE). Non esiste un solo proxy. Nel livello Premium, lo stesso indirizzo IP esterno globale viene pubblicizzato da vari punti di presenza e le richieste del client vengono indirizzate al GFE più vicino.

A seconda di dove si trovano i client, più GFE possono avviare connessioni HTTP(S) ai tuoi backend. I pacchetti inviati dai GFE hanno indirizzi IP di origine nello 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 dal bilanciatore del carico provengono da intervalli IP diversi a seconda del tipo di NEG (globale o a livello di regione). Per ulteriori informazioni, consulta la pagina relativa all'autenticazione delle richieste.

A seconda della configurazione del servizio di backend, il protocollo utilizzato da ogni GFE per connettersi ai 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. Le keepalive HTTP tentano di usare in modo efficiente la stessa sessione TCP, ma non c'è alcuna garanzia. GFE utilizza un timeout keepalive HTTP del client di 610 secondi e un valore di timeout keepalive del backend predefinito 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 la sezione su timeout e nuovi tentativi.

Per garantire che il traffico sia bilanciato in modo uniforme, il bilanciatore del carico può chiudere in modo pulito una connessione TCP inviando un pacchetto FIN ACK dopo aver completato una risposta che includeva un'intestazione Connection: close o potrebbe emettere un frame HTTP/2 GOAWAY dopo aver completato una risposta. Questo comportamento non interferisce con richieste o 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 ai backend e di dove viene eseguito il deployment dei backend.

Per ulteriori informazioni, consulta Funzionamento dei 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

L'Application Load Balancer esterno regionale è un servizio gestito implementato sul proxy Envoy. Il bilanciatore del carico delle applicazioni esterno regionale utilizza una subnet condivisa denominata subnet solo proxy per eseguire il provisioning di un insieme di indirizzi IP che Google utilizza per eseguire 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 quindi apre nuove connessioni dalla subnet solo proxy ai backend. Pertanto, i pacchetti inviati dal bilanciatore del carico hanno indirizzi IP di origine dalla subnet solo proxy.

A seconda della configurazione del servizio di backend, il protocollo utilizzato dai proxy Envoy per connettersi ai 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 di backend è corretto. Puoi configurare il timeout della richiesta/risposta impostando il timeout del servizio di backend. Per ulteriori informazioni, consulta Timeout e nuovi tentativi.

Comunicazioni 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 si utilizza HTTPS, i client moderni utilizzano per impostazione predefinita HTTP/2. Questa operazione viene controllata sul client, non sul bilanciatore del carico HTTPS.
• Non puoi disabilitare HTTP/2 apportando una modifica alla configurazione nel bilanciatore del carico. Tuttavia, puoi configurare alcuni client per l'utilizzo di 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 forwarding del bilanciatore del carico delle applicazioni esterno in ogni modalità, vedi 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, ci sono 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 l'indirizzo IP esterno se il client si trova dietro a NAT o a un proxy di inoltro).
  • 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 container di backend nella rete VPC.

Nota: per i NEG internet, le richieste dal bilanciatore del carico provengono da intervalli IP diversi. Per maggiori 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 l'indirizzo IP esterno se il client si trova dietro a NAT o a un proxy di inoltro).
  • 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 container di backend nella rete VPC.

Percorso di ritorno

Per i bilanciatori del carico delle applicazioni esterni globali, Google Cloud utilizza route speciali non definite nella rete VPC per i controlli di integrità. Per maggiori informazioni, consulta Percorsi di ritorno del bilanciatore del carico.

Per i bilanciatori del carico delle applicazioni esterni regionali, Google Cloud utilizza proxy Envoy open source per terminare le richieste 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 tua rete VPC facilitano la comunicazione dai proxy Envoy ai tuoi backend e dai tuoi backend ai proxy Envoy.

Porte aperte

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

Entrambi i bilanciatori del carico basati su GFE, ovvero bilanciatori del carico delle applicazioni esterni globali e bilanciatori del carico delle applicazioni classici, mostrano sempre le porte 80 e 443 come aperte (insieme a qualsiasi altra porta configurata nelle regole di forwarding del bilanciatore del carico). Tuttavia, se non hai configurato una regola di forwarding per la porta 80 o 443, le connessioni inviate a queste porte verranno rifiutate. Al contrario, i bilanciatori del carico delle applicazioni esterni regionali vengono implementati utilizzando i proxy Envoy e non mostrano porte molto aperte 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) di solito non prevede alcun pacchetto di risposta o un pacchetto RST TCP quando si esegue il probe SYN TCP. I GFE invieranno pacchetti SYN-ACK in risposta ai probe SYN solo per le porte su cui è stata configurata una regola di forwarding. I GFE inviano pacchetti ai tuoi backend solo in risposta ai pacchetti inviati all'indirizzo IP del tuo bilanciatore del carico e alla porta di destinazione configurata nella relativa regola di forwarding. I pacchetti inviati a una porta o un indirizzo IP diversi non vengono inviati ai backend.

  I GFE implementano funzionalità di sicurezza come Google Cloud Armor. Con Google Cloud Armor Standard, i GFE offrono protezione sempre attiva 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 verranno addebitati dei costi 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 ricevere risposta da qualsiasi GFE nel parco risorse di Google. Tuttavia, la scansione della combinazione di indirizzo IP e porta di destinazione di un bilanciatore del carico 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 l'analisi di tutti i GFE nel parco risorse Google.

Tenendo conto di ciò, di seguito sono riportati alcuni modi più efficaci per verificare la sicurezza delle istanze di backend:

• Un revisore di sicurezza deve controllare la configurazione delle regole di forwarding per verificare la configurazione del bilanciatore del carico. Le regole di forwarding definiscono la porta di destinazione per cui il bilanciatore del carico accetta i pacchetti e li inoltra ai backend. Per i bilanciatori del carico basati su GFE, ogni regola di forwarding esterno può fare riferimento solo a una singola 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 di sicurezza deve esaminare la configurazione della regola firewall applicabile alle VM di backend. Le regole firewall che imposti bloccano il traffico dai GFE alle VM di backend, ma non bloccano il traffico in entrata verso i GFE. Per le best practice, consulta la sezione delle regole firewall.

terminazione TLS

La tabella seguente riassume come la terminazione TLS viene gestita dai bilanciatori del carico delle applicazioni esterni in ciascuna modalità.

Modalità bilanciatore del carico	terminazione TLS
Bilanciatore del carico delle applicazioni esterno globale	Il protocollo TLS viene terminato su un GFE, che può trovarsi ovunque nel mondo.
Bilanciatore del carico delle applicazioni classico	Il protocollo TLS viene terminato su un GFE, che potrebbe trovarsi ovunque nel mondo.
Bilanciatore del carico delle applicazioni esterno regionale	Il protocollo 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 del 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:

Tipo di timeout e descrizione	Valori predefiniti	Supporta valori personalizzati
		Global	Classica	A livello di regione
Timeout del servizio di backend^1 Un timeout per richiesta e risposta. Rappresenta il tempo massimo che può trascorrere da quando il bilanciatore del carico invia il primo byte della richiesta HTTP al tuo backend a quando il backend restituisce l'ultimo byte della risposta HTTP. Se l'intera risposta HTTP non è stata restituita al bilanciatore del carico entro il timeout della richiesta o della risposta, i dati della risposta rimanenti vengono eliminati. Per i WebSocket utilizzati con i bilanciatori del carico delle applicazioni classici, la durata massima del WebSocket, indipendentemente dal fatto che sia inattivo o attivo.	Per i NEG serverless su un servizio di backend: 60 minuti Per tutti gli altri tipi di backend su un servizio di backend: 30 secondi Per i bucket di backend: 24 ore (86.400 secondi)	^2		^2
Timeout keepalive HTTP del client Il periodo di 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 può 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 backend Il periodo di tempo massimo durante il quale la connessione TCP tra il proxy del bilanciatore del carico e un backend può essere inattiva. La stessa connessione TCP può 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 (downstream) 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 gli Application Load Balancer classici: Il timeout di inattività della sessione QUIC è il minimo tra il timeout per inattività del client o il timeout per inattività di GFE (300 secondi). Il timeout di inattività di GFE è fisso su 300 secondi. Il timeout di inattività del client può essere configurato.

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

² Il supporto della configurazione non è applicabile ai WebSocket.

Timeout del servizio di backend

Il timeout del servizio di backend configurabile rappresenta il tempo massimo che il bilanciatore del carico attende prima che il backend elabori una richiesta HTTP e restituisca la risposta HTTP corrispondente. Fatta eccezione per i 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 è di 90 secondi, il bilanciatore del carico si aspetta che il backend consegni 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 almeno ricevuto intestazioni di risposta HTTP dal backend, restituisce le intestazioni della risposta complete e la maggior parte del corpo della risposta che potrebbe ricevere entro il timeout del servizio di backend.

Devi impostare il timeout del servizio di backend sul tempo massimo necessario al backend per elaborare una risposta HTTP. Dovresti 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, dovresti aumentare il timeout se vedi 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ù alti non sono opzioni di configurazione pratiche. Google Cloud non garantisce che una connessione TCP sottostante possa rimanere aperta per tutto il valore del timeout del servizio di backend. I sistemi client devono implementare la logica per i nuovi tentativi invece di affidarsi a una connessione TCP per essere aperta per lunghi periodi di tempo.

Note aggiuntive

• I timeout della connessione WebSocket dipendono dal tipo di bilanciatore del carico:

  • Per i bilanciatori del carico delle applicazioni classici, il timeout per una connessione WebSocket dipende dal timeout del servizio di backend configurabile del bilanciatore del carico, che è di 30 secondi per impostazione predefinita. Questo timeout si applica alle connessioni WebSocket indipendentemente dal fatto che siano in uso.
  • Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni esterni regionali, le connessioni WebSocket attive non seguono il timeout del servizio di backend. Le connessioni WebSocket inattive vengono chiuse dopo il timeout del servizio di backend.
  • Inoltre, le connessioni WebSocket utilizzate dai bilanciatori del carico delle applicazioni esterni globali e dagli Application Load Balancer classici vengono chiuse automaticamente dopo 24 ore. Questo limite di 24 ore non è personalizzabile e si verifica indipendentemente dal fatto che le connessioni siano in uso o dal fatto che il valore di timeout del servizio di backend sia impostato su un valore superiore a 86.400 secondi (24 ore).

• Per un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico, non sono consigliati valori di timeout del servizio di backend superiori a un giorno (86.400 secondi), in quanto Google Cloud riavvia periodicamente Google Front End per gli aggiornamenti del software e altre operazioni di manutenzione di routine. Il valore di timeout del servizio di backend non ritarda le attività di manutenzione di Google. Più a lungo è il valore di timeout del servizio di backend, più è probabile che Google termini le connessioni TCP per la manutenzione.

• Per un bilanciatore del carico delle applicazioni esterno regionale, Google Cloud riavvia o modifica periodicamente il numero di attività software Envoy di gestione. Più a lungo è il valore di timeout del servizio di backend, più è probabile che le attività Envoy riavvii o le sostituzioni terminino le connessioni TCP.

I bilanciatori del carico delle applicazioni esterni regionali supportano un parametro di mappa URL routeActions.timeout, che può sostituire il timeout del servizio di backend. Se routeActions.timeout viene omesso, viene utilizzato il valore del timeout del servizio di backend. Quando viene fornito routeActions.timeout, il timeout del servizio di backend viene ignorato e il valore di routeActions.timeout viene utilizzato come timeout della richiesta e della risposta.

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

• Console Google Cloud: modifica il campo Timeout del servizio di backend del bilanciatore del carico.
• Google Cloud CLI: 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.
• API: per un bilanciatore del carico delle applicazioni esterno regionale, modifica il parametro timeoutSec per la risorsa regionBackendServices.

Timeout keepalive HTTP del client

Il timeout keepalive HTTP del client rappresenta la quantità massima di tempo in cui una connessione TCP può rimanere inattiva tra il client (downstream) 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 a 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 compreso tra 5 e 1200 secondi.
• Per un bilanciatore del carico delle applicazioni classico, il timeout keepalive HTTP del client è fisso su 610 secondi.
• Per un bilanciatore del carico delle applicazioni esterno regionale, il timeout keepalive HTTP del client è fisso su 600 secondi.

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

• Console Google Cloud: modifica il campo Timeout keepalive HTTP della configurazione frontend del bilanciatore del carico.
• Google Cloud CLI: 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.
• API: modifica il parametro httpKeepAliveTimeoutSec per la risorsa targetHttpProxies o la targetHttpsProxies risorsa.

Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del timeout keepalive HTTP (TCP inattivo) utilizzato dai client o dai proxy downstream. Se un client downstream ha un timeout keepalive HTTP (TCP inattivo) 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 downstream, una connessione TCP stabilita può rimanere inattiva più a lungo di quanto consentito dal bilanciatore del carico. Ciò significa che il client downstream può inviare pacchetti dopo che il bilanciatore del carico ha considerato chiusa la connessione TCP. In questo caso, il bilanciatore del carico risponde con un pacchetto TCP reset (RST).

Timeout keepalive HTTP di 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 (downstream) e un GFE di primo livello. I GFE di primo livello si connettono ai GFE di secondo livello, quindi i GFE di secondo livello aprono una seconda connessione TCP ai backend.

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

Le connessioni TCP secondarie del bilanciatore del carico potrebbero non essere chiuse dopo ogni richiesta; possono rimanere aperte per gestire più richieste e risposte HTTP. Il timeout keepalive HTTP di 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 è fisso su 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 nei tuoi backend. Ciò evita una race condition in cui il sistema operativo dei tuoi backend potrebbe chiudere le connessioni TCP con una reimpostazione 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 di timeout keepalive HTTP (TCP inattivo) sia superiore a 600 secondi.

Nella tabella seguente sono elencate le modifiche necessarie per modificare i valori di timeout keepalive per i software per server web più utilizzati.

Software 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 di inattività di una sessione QUIC 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 di timeout di inattività della sessione QUIC è definito come il minimo tra il timeout di inattività del client o il timeout di inattività di GFE (300 secondi). Il timeout di inattività di GFE è fisso su 300 secondi. Il timeout di inattività del client può essere configurato.

Nuovi tentativi

Il supporto della logica dei nuovi tentativi dipende dalla modalità del bilanciatore del carico delle applicazioni esterno.

Modalità bilanciatore del carico	Logica di ripetizione
Bilanciatore del carico delle applicazioni esterno globale	Configurabile mediante un criterio di ripetizione nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1. Il numero massimo di nuovi tentativi che possono essere configurati utilizzando il criterio per i nuovi tentativi è 25. Il timeout predefinito per ogni tentativo (perTryTimeout) è di 30 secondi con un valore massimo configurabile di perTryTimeout di 24 ore. Senza un criterio di ripetizione, le richieste non riuscite senza corpo HTTP (ad esempio, richieste GET) che generano risposte HTTP 502, 503 o 504 (retryConditions=["gateway-error"]) vengono tentate una volta sola. Le richieste HTTP POST non vengono tentate di nuovo. Le richieste ricalcolate generano solo una voce di log per la risposta finale.
Bilanciatore del carico delle applicazioni classico	Impossibile modificare il criterio per i nuovi tentativi di connessione. Le richieste HTTP POST non vengono tentate di nuovo. Le richieste HTTP GET vengono sempre tentate una volta sola, purché l'80% o più dei backend sia integro. Se in un gruppo è presente una singola istanza di backend e la connessione all'istanza di backend non riesce, la percentuale di istanze di backend in stato non integro è pari al 100%, pertanto il GFE non proverà di nuovo a eseguire la richiesta. Il bilanciatore del carico tenta di nuovo una richiesta GET non riuscita se la prima richiesta non ha avuto esito positivo prima di ricevere le intestazioni di risposta dall'istanza di backend. Le richieste ricalcolate generano solo una voce di log per la risposta finale. Per maggiori informazioni, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno. Se le richieste non riuscite, il bilanciatore del carico sintetizza una risposta HTTP 502.
Bilanciatore del carico delle applicazioni esterno regionale	Configurabile utilizzando un criterio Riprova nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1. Il numero massimo di nuovi tentativi che possono essere configurati utilizzando il criterio per i nuovi tentativi è 25. Il timeout predefinito per ogni tentativo (perTryTimeout) è di 30 secondi, con un valore massimo configurabile di perTryTimeout di 24 ore. Senza un criterio di ripetizione, le richieste non riuscite senza corpo HTTP (ad esempio, richieste GET) che generano risposte HTTP 502, 503 o 504 vengono ritentate una volta. Le richieste HTTP POST non vengono tentate di nuovo. Le richieste ricalcolate generano solo una voce di log per la risposta finale.

Il protocollo WebSocket è supportato con GKE Ingress.

Gestione illegale di richieste e risposte

Il bilanciatore del carico impedisce alle richieste del client e alle risposte del backend di raggiungere rispettivamente il backend o il client per diversi motivi. Alcuni motivi sono strettamente correlati alla conformità HTTP/1.1, mentre altri servono a evitare il trasferimento di dati imprevisti da o verso i backend. Nessuno dei controlli può essere disabilitato.

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

• Non può analizzare la prima riga della richiesta.
• In un'intestazione manca il delimitatore :.
• Le intestazioni o la prima riga contengono caratteri non validi.
• La lunghezza del contenuto non è un numero valido o sono presenti più intestazioni della lunghezza del contenuto.
• Sono presenti più chiavi di codifica di trasferimento oppure sono presenti valori di codifica di trasferimento non riconosciuti.
• È presente un corpo non in blocchi e nessuna lunghezza del contenuto specificata.
• I blocchi 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 blocco non analizzabile.

Gestione delle richieste

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

• La dimensione totale delle intestazioni delle richieste e dell'URL della richiesta superano il limite previsto per le dimensioni massime delle intestazioni delle richieste per 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 abilitare le connessioni WebSocket.
• La versione HTTP è sconosciuta.

Il GFE di primo livello del bilanciatore del carico rimuove le seguenti intestazioni delle richieste dalle richieste in entrata se un client le invia:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• Trailer
• TE
• Content-Length: questa intestazione viene rimossa solo quando la richiesta ha Transfer-Encoding: chunked.
• Transfer-Encoding: l'intestazione Transfer-Encoding: chunked viene aggiunta quando la richiesta HTTP OPTIONS ha un corpo e il protocollo è HTTP o HTTPS. Questo attributo è supportato solo per HTTP/1.1.

Gestione della risposta

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

• La dimensione totale delle intestazioni delle risposte supera il limite previsto per le dimensioni massime delle intestazioni delle risposte per i bilanciatori del carico delle applicazioni esterni.
• La versione HTTP è sconosciuta.

Il GFE di secondo livello del bilanciatore del carico rimuove le seguenti intestazioni di risposta dalle risposte ricevute dal backend:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• Trailer
• TE
• Content-Length: questa intestazione viene rimossa solo quando la risposta contiene Transfer-Encoding: chunked.
• Transfer-Encoding: l'intestazione Transfer-Encoding: chunked viene aggiunta quando la richiesta HTTP OPTIONS ha un corpo e il protocollo è HTTP o HTTPS. Questo attributo è supportato solo per HTTP/1.1.

Distribuzione del traffico

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

• RATE, per i gruppi di istanze o NEG, è il numero massimo di richieste (query) al secondo (RPS, QPS) target. Il valore RPS/QPS massimo target può essere superato se tutti i backend hanno raggiunto o superato la 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, GFE stima quali istanze di backend hanno la capacità di ricevere richieste. Questa stima della capacità viene effettuata proattivamente, non nello stesso momento in cui vengono in arrivo le richieste. I GFE ricevono informazioni periodiche sulla capacità disponibile e distribuiscono le richieste in entrata di conseguenza.

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 attuale delle istanze e quindi stima un carico di query che ogni istanza è in grado di gestire. La stima cambia nel tempo man mano che l'uso delle istanze e i modelli di traffico cambiano.

Entrambi i fattori (stima della capacità e assegnazione proattiva) influenzano la distribuzione tra le istanze. Pertanto, Cloud Load Balancing si comporta in modo diverso 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 tenta invece di ottimizzare la selezione delleistanza di backendd per ogni richiesta.

Per il bilanciatore del carico delle applicazioni esterno globale, il bilanciamento del carico è a due livelli. La modalità di bilanciamento determina la ponderazione o la frazione di traffico che deve essere inviata a ciascun backend (gruppo di istanze o NEG). Quindi, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo. Per ulteriori informazioni, consulta i criteri di località di 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 quindi distribuito in modalità "round robin" tra le istanze o gli endpoint all'interno del backend.

Modalità di distribuzione delle 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 perimetrali pubblicizzano l'indirizzo IP esterno della regola di forwarding ai confini della rete Google. Ogni annuncio elenca un hop successivo a un sistema di bilanciamento del carico di livello 3/4 (Maglev). I sistemi Maglev instradano 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 a livello di regione. L'uso di una regola di forwarding di livello Standard limita i backend di gruppo di istanze e NEG a livello di zona nella stessa regione della regola di forwarding del bilanciatore del carico.
2. Dal GFE di primo livello a quello di secondo livello. Il GFE di primo livello termina TLS se necessario, quindi instrada il traffico ai GFE di secondo livello in base al seguente processo:
   • I GFE di primo livello analizzano la mappa URL e selezionano un servizio o un bucket di backend.
   • Per i servizi di backend con NEG internet, i GFE del primo livello selezionano un gateway di forwarding esterno di secondo livello in co-location con il GFE del primo livello. Il gateway di forwarding invia richieste all'endpoint NEG internet. Questo conclude il processo di distribuzione delle richieste per i NEG internet.
   • Per i servizi di backend con NEG serverless, NEG Private Service Connect (PSC) e bucket di backend, i GFE di primo livello selezionano un GFE di secondo livello nella regione corrispondente alla regione del NEG o bucket. Per i bucket Cloud Storage multiregionali, i GFE di primo livello selezionano i GFE di secondo livello in una regione il più vicino possibile ai GFE del primo livello (definiti dal tempo di round trip della rete).
   • Per i servizi di backend con gruppi di istanze, NEG di zona con endpoint GCE_VM_IP_PORT e NEG ibridi, il sistema di gestione della capacità di Google informa i GFE di primo livello sulla capacità utilizzata e configurata per ciascun backend. La capacità configurata per un backend è definita dalla modalità di bilanciamento, dalla capacità target della modalità di bilanciamento e dallo scaler 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 backend, escluse le regioni con backend configurati con 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 inoltrare le richieste ad altre regioni applicabili se una regione di prima scelta è completa. Lo spillover in altre regioni è possibile quando tutti i backend nella regione di prima scelta sono al completo.
3. I GFE 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. Con questo si conclude il processo di distribuzione delle richieste per questi backend.

   • Per i servizi di backend con gruppi di istanze, NEG di zona con endpoint GCE_VM_IP_PORT e NEG ibridi, i sistemi di probe per il controllo di integrità 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 di backend o endpoint in stato integro nella propria regione, potrebbe inviare richieste a un altro GFE di secondo livello in un'altra regione applicabile con backend configurati. Lo sversamento tra i GFE di secondo livello in regioni diverse non esaurisce tutte le possibili combinazioni tra regioni. Se devi indirizzare il traffico lontano dai backend in una determinata regione, anziché configurare backend in modo che non superino i controlli di integrità, devi impostare lo scaler 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 di backend o agli endpoint nelle zone all'interno della sua regione, come discusso nel passaggio successivo.

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

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

   • SPRAY_TO_REGION: i GFE di secondo livello non preferiscono selezionare le istanze di backend o gli endpoint nella stessa zona del GFE di secondo livello. I GFE di secondo livello tentano di distribuire il traffico a tutte le istanze di backend o endpoint in tutte le zone della regione. Ciò può portare a una distribuzione più uniforme del carico, a scapito dell'aumento del traffico tra le zone.
   • WATERFALL_BY_ZONE: i GFE di secondo livello preferiscono fortemente la selezione di istanze di backend o endpoint 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 attuale hanno raggiunto le 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 questa impostazione utilizzando un criterio per la località di bilanciamento del carico (localityLbPolicy). Il criterio relativo alla località di bilanciamento del carico si applica solo ai backend all'interno della zona selezionata discusso 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 per le località di bilanciamento del carico.

La modalità di bilanciamento determina la ponderazione e la frazione di traffico che deve essere inviata a ciascun gruppo (gruppo di istanze o NEG). Il criterio per le località di bilanciamento del carico (LocalityLbPolicy) determina il modo in cui viene bilanciato il carico dei backend all'interno del gruppo.

Quando un servizio di backend riceve traffico, indirizza innanzitutto il traffico 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 in quel gruppo di backend in base al criterio della località di bilanciamento del carico.

Per ulteriori informazioni, consulta le seguenti risorse:

• Modalità di bilanciamento
• Criterio della località di bilanciamento del carico (documentazione relativa all'API del servizio di backend regionale).

Affinità sessione

L'affinità sessione consente di 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à sessione funziona al meglio se imposti la modalità di bilanciamento sulle 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à campo intestazione
• Affinità dei cookie HTTP

La tabella seguente riassume le opzioni di affinità sessione supportate dai bilanciatori del carico delle applicazioni esterni in ciascuna modalità:

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

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. Questa operazione viene controllata 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 quindi trasformate dal bilanciatore del carico per eseguirne il proxy su HTTP/2 alle istanze di backend.

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

Stream simultanei HTTP/2 massimi

L'impostazione HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descrive il numero massimo di stream accettati da un endpoint, avviati dal peer. Il valore pubblicizzato da un client HTTP/2 a un bilanciatore del carico di Google Cloud è effettivamente privo di significato perché il bilanciatore del carico non avvia flussi di dati al client.

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

Limitazioni HTTP/2

• HTTP/2 tra il bilanciatore del carico e l'istanza può richiedere un numero notevolmente maggiore di 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 al backend elevate perché le connessioni di backend vengono effettuate più spesso.
• HTTP/2 tra il bilanciatore del carico e il backend non supporta l'esecuzione del protocollo WebSocket su un singolo flusso di una connessione HTTP/2 (RFC 8441).
• HTTP/2 tra il bilanciatore del carico e il backend non supporta il push del server.
• La percentuale di errori gRPC e il volume di richieste 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 HTTP/3

HTTP/3 è un protocollo internet di nuova generazione. Si basa su IETF QUIC, un protocollo sviluppato dal protocollo originale Google QUIC. 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 nell'aprile 2023 a favore di HTTP/3 rispetto a QUIC di IETF, che è uno standard di IETF e ha prestazioni migliori di gQUIC.

In particolare:

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

HTTP/3 sul bilanciatore del carico può migliorare i tempi di caricamento delle pagine web, ridurre il rebuffering dei video e migliorare la velocità effettiva per le connessioni a latenza più elevata.

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

Modalità bilanciatore del carico	Supporto HTTP/3
Bilanciatore del carico delle applicazioni esterno globale (sempre di 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 segnala questo supporto ai client, consentendo a quelli 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 sono in grado di stabilire una connessione HTTP/3.
• I client che supportano HTTP/3 utilizzano le proprie conoscenze memorizzate nella cache del supporto HTTP/3 per risparmiare round trip non necessari in futuro.
• A causa di questo fallback, l'abilitazione o la disabilitazione di HTTP/3 nel bilanciatore del carico non interrompe la capacità del bilanciatore del carico di connettersi ai client.

L'assistenza è pubblicizzata nell'intestazione della risposta HTTP Alt-Svc. Quando HTTP/3 è abilitato, le risposte del bilanciatore del carico includono il seguente valore di 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 della risposta alt-svc.

Se HTTP/3 è abilitato sul bilanciatore del carico HTTPS, in alcuni casi il client può utilizzare HTTPS o HTTP/2 anziché negoziare HTTP/3. Sono inclusi:

• 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 ha una frequenza limitata in modo tale da impedire il funzionamento di HTTP/3.
• Il client non supporta HTTP/3, quindi non tenta di negoziare una connessione HTTP/3.

Quando una connessione utilizza HTTPS o HTTP/2, non viene considerato come un guasto del bilanciatore del carico.

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

Configura HTTP/3

Sia NONE (impostazione predefinita) sia ENABLE abilitano il supporto HTTP/3 per il bilanciatore del carico.

Quando HTTP/3 è abilitato, il bilanciatore del carico lo annuncia ai client, il che consente a quelli 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 disabilitare esplicitamente HTTP/3, a meno che tu non abbia identificato implementazioni del client non funzionanti.

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

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

Per attivare (o disattivare) HTTP/3 in modo esplicito, segui questi passaggi.

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 che vuoi modificare.
2. Fai clic su Configurazione frontend.
3. Seleziona l'indirizzo IP e la porta frontend che vuoi modificare. Per modificare una configurazione HTTP/3, il protocollo deve essere HTTPS.

Abilita HTTP/3

1. Seleziona il menu a discesa Negoziazione QUIC.
2. Per abilitare esplicitamente HTTP/3 per questo frontend, seleziona Abilitato.
3. Se disponi di più regole frontend che rappresentano IPv4 e IPv6, assicurati di abilitare HTTP/3 su ciascuna regola.

Disabilita HTTP/3

1. Seleziona il menu a discesa Negoziazione QUIC.
2. Per disabilitare esplicitamente HTTP/3 per questo frontend, seleziona Disabilitato.
3. Se disponi di più regole frontend che rappresentano IPv4 e IPv6, assicurati di disabilitare HTTP/3 per ciascuna regola.

gcloud: HTTPS

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

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

Sostituisci QUIC_SETTING con uno dei seguenti:

*   `NONE` (default): allows Google to control when HTTP/3 is
    advertised.

Quando selezioni NONE, HTTP/3 viene pubblicizzato per i client, ma Google QUIC non è pubblicizzato. Nella console Google Cloud, questa opzione è denominata Automatico (predefinito). * ENABLE: pubblicizza HTTP/3 ai clienti. * DISABLE: non annuncia HTTP/3 ai clienti.

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 uno dei seguenti:

*   `NONE` (default): Allows Google to control when HTTP/3 is
    advertised.

Al momento, quando selezioni NONE, HTTP/3 viene pubblicizzato per i clienti, ma Google QUIC non è pubblicizzato.

Nella console Google Cloud, questa opzione è denominata Automatica (predefinita). * ENABLE: annuncia HTTP/3 e Google QUIC ai client. * DISABLE: non pubblicizza HTTP/3 o Google QUIC per i clienti.

Limitazioni

• I bilanciatori del carico HTTPS non inviano un avviso di chiusura di close_notify quando terminano le connessioni SSL. Il bilanciatore del carico chiude la connessione TCP invece di eseguire un arresto SSL.
• I bilanciatori del carico HTTPS supportano solo i caratteri minuscoli nei domini in un attributo nome comune (CN) o in un attributo nome alternativo del soggetto (SAN) del certificato. I certificati con caratteri maiuscoli nei domini vengono restituiti solo se impostati come certificato principale nel proxy di destinazione.
• I bilanciatori del carico HTTPS non utilizzano l'estensione Server Name Indication (SNI) per la connessione al backend, ad eccezione dei bilanciatori del carico con backend di NEG internet. Per maggiori dettagli, consulta Crittografia dal bilanciatore del carico ai backend.
• Quando utilizzi Application Load Balancer 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 all'interno dello 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 sottostante possa rimanere aperta per tutto il valore del timeout del servizio di backend. I sistemi client devono implementare la logica dei nuovi tentativi invece di affidarsi a una connessione TCP per rimanere 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, per questi bilanciatori del carico nella console Google Cloud sono disponibili solo le regioni che supportano il livello Standard. Utilizza invece gcloud CLI o l'API. Utilizza invece gcloud CLI o l'API.
• Cloud CDN ti consente di forzare l'esclusione di un oggetto o un insieme di oggetti dalla cache richiedendo una invalidazione della cache. Quando utilizzi un bilanciatore del carico delle applicazioni esterno globale con riferimenti di servizi tra progetti VPC condiviso, per impostazione predefinita, gli amministratori dei progetti di servizio non avranno le autorizzazioni necessarie per richiedere l'annullamento della convalida della cache. Questo perché l'invalidazione della cache è configurata nel progetto frontend (ovvero il progetto che ha la regola di forwarding, il proxy di destinazione e la mappa URL del bilanciatore del carico). Di conseguenza, le invalidazioni della cache possono essere eseguite solo dalle entità con ruoli IAM per configurare le risorse relative al bilanciatore del carico nei progetti frontend (ad esempio, il ruolo Amministratore rete Compute). Gli amministratori dei servizi, che controllano il provisioning dei servizi di backend in un progetto separato, dovranno collaborare con l'amministratore del bilanciatore del carico del progetto frontend per emettere l'annullamento della convalida della cache per i servizi tra progetti.

Passaggi successivi

• Per informazioni su come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno globale, consulta Configurazione di un bilanciatore del carico delle applicazioni esterno con un backend di Compute Engine.
• Per informazioni su come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno regionale, vedi Configurazione di un bilanciatore del carico delle applicazioni esterno regionale con un backend di Compute Engine.
• Se sei un utente esistente del bilanciatore del carico delle applicazioni classico, assicurati di rivedere l'articolo Pianificare la migrazione al bilanciatore del carico delle applicazioni esterno globale 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 gli esempi di moduli Terraform per i bilanciatori del carico delle applicazioni esterni.
• Per scoprire come configurare le funzionalità avanzate di gestione del traffico disponibili con il bilanciatore del carico delle applicazioni esterno globale, consulta Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni globali.
  • Per scoprire come configurare le funzionalità avanzate di gestione del traffico disponibili con l'Application Load Balancer esterno regionale, consulta la panoramica sulla gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali.
    • Per trovare le località per i PoP di Google, consulta Sedi dei GFE.
• Per saperne di più sulla gestione della capacità, vedi Tutorial sulla gestione della capacità con bilanciamento del carico e Ottimizzazioni della capacità delle applicazioni con bilanciamento del carico globale.
  • Per scoprire di più sulla pubblicazione di siti web, consulta la sezione Pubblicazione di siti web.
• Per informazioni su come utilizzare Gestore certificati per eseguire il provisioning e gestire i certificati SSL, consulta la panoramica di Gestore certificati.
• Per inserire la logica personalizzata nel percorso dei dati di bilanciamento del carico, configura i callout di Service Extensions.