Panoramica del bilanciatore del carico delle applicazioni esterno

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

Un bilanciatore del carico delle applicazioni esterno è un bilanciatore del carico di livello 7 basato su proxy che ti consente di eseguire e scalare i servizi dietro un singolo indirizzo IP esterno. Il bilanciatore del carico delle applicazioni esterno distribuisce il traffico HTTP e HTTPS ai backend ospitati su una serie di piattaformeGoogle Cloud (come Compute Engine, Google Kubernetes Engine (GKE) e Cloud Storage), nonché ai backend esterni connessi a internet o tramite connettività ibrida. Per maggiori dettagli, consulta Panoramica del bilanciatore 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 le funzionalità di gestione avanzata del traffico come il mirroring del traffico, la suddivisione del traffico in base al peso e le trasformazioni delle intestazioni basate su richieste o risposte.
• Bilanciatore del carico delle applicazioni classico. Si tratta del bilanciatore del carico delle applicazioni esterno classico che è globale nel livello Premium, ma può essere configurato in modo che sia 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 regionale implementato come servizio gestito sul proxy Envoy open source. Include funzionalità di gestione avanzata del traffico come il mirroring del traffico, la suddivisione del traffico in base al peso e le trasformazioni delle intestazioni basate su richieste o risposte.

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

Identificare la modalità

Console

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

   Vai a Bilanciamento del carico

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

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

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

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

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

Architettura

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

• Solo per i bilanciatori del carico delle applicazioni esterni regionali, viene utilizzata una subnet solo proxy per inviare 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 utilizzano l'indirizzo IP e la porta per connettersi al bilanciatore del carico.

• Un proxy HTTP(S) di destinazione riceve una richiesta dal client. Il proxy HTTP(S) valuta la richiesta utilizzando la mappa URL per prendere decisioni di 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 propria identità ai client. Un proxy HTTPS di destinazione supporta fino al numero documentato di certificati SSL.

• Il proxy HTTP(S) utilizza una mappa URL per determinare il 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 del client a servizi di backend o bucket di backend specifici. La mappa degli URL può specificare azioni aggiuntive, 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 la preparazione dei backend. In questo modo si riduce il rischio che le richieste vengano inviate a backend che non possono soddisfarle.

• Regole firewall per i backend per 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 di un bilanciatore del carico delle applicazioni esterno globale. Questa architettura si applica sia al bilanciatore del carico delle applicazioni esterno globale sia al bilanciatore del carico delle applicazioni classico nel livello Premium.

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

Regionale

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

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

Subnet solo proxy

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

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

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

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

Regole di forwarding e indirizzi IP

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

Specifica dell'indirizzo IP. Ogni regola di forwarding fornisce un singolo indirizzo IP che può essere utilizzato nei record DNS per la tua applicazione. Non è necessario il bilanciamento del carico basato sul DNS. Puoi specificare l'indirizzo IP da utilizzare o lasciare che Cloud Load Balancing ne assegni uno per te.

Specifica della porta. Ogni regola di forwarding per un bilanciatore del carico delle applicazioni può fare riferimento a una singola porta compresa tra 1 e 65535. Per supportare più porte, devi configurare più regole di forwarding. Puoi configurare più regole di forwarding per utilizzare lo stesso indirizzo IP esterno (VIP) e per fare riferimento allo stesso proxy HTTP(S) di destinazione, a condizione che la combinazione complessiva di indirizzo IP, porta e protocollo sia univoca per ogni 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à del 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	Le richieste vengono instradate al servizio 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 ^1	Richieste instradate al GFE più vicino al client su internet.
	Livello Standard	Regola di inoltro esterno regionale Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL^1	Richieste indirizzate a un GFE nella regione del bilanciatore del carico.
Bilanciatore del carico delle applicazioni esterno regionale	Livello Premium o livello Standard	Regola di inoltro esterno regionale Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL_MANAGED	Le richieste raggiungono Google Cloud il PoP più vicino al client. Le richieste vengono quindi instradate tramite il backbone premium di Google Cloudfino a raggiungere i proxy Envoy nella stessa regione del bilanciatore del carico.

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

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

Regole di forwarding e reti VPC

Questa sezione descrive in che modo le regole di forwarding utilizzate dai bilanciatori del carico delle applicazioni esterni sono associate alle reti VPC.

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

Proxy target

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 la distinzione tra maiuscole e minuscole dei nomi delle intestazioni di richieste o risposte. Ad esempio, un'intestazione di risposta Server: Apache/1.0 potrebbe essere visualizzata nel client come server: Apache/1.0.

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

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

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

Nota: in conformità con la 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 modifica altre intestazioni HTTP nei seguenti modi:

• Per il bilanciatore del carico delle applicazioni esterno globale, le intestazioni di richiesta e risposta potrebbero essere convertite in minuscolo.

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

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

• Alcune intestazioni sono state 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 uniti solo gli header i cui valori possono essere rappresentati come un 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 all'intestazione X-Forwarded-For, separati da una sola virgola, nel seguente ordine:

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

Se la richiesta in entrata non include un'intestazione X-Forwarded-For, l'intestazione risultante è la seguente:

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

Se la richiesta in entrata include già un'intestazione X-Forwarded-For, il bilanciatore del carico aggiunge i propri valori all'intestazione esistente:

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

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

Rimuovere i valori delle intestazioni esistenti utilizzando un'intestazione della richiesta personalizzata

È possibile rimuovere i valori delle intestazioni esistenti utilizzando le intestazioni delle richieste personalizzate nel servizio di backend. L'esempio seguente utilizza il flag --custom-request-header per ricreare l'intestazione X-Forwarded-For utilizzando le variabili client_ip_address e server_ip_address. Questa configurazione sostituisce l'intestazione X-Forwarded-For in entrata solo con l'indirizzo IP del client e del bilanciatore del carico.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Nota: questo approccio ignora tutti i valori X-Forwarded-For esistenti della richiesta. Poiché Google Cloud non registra i valori delle intestazioni, questi valori non possono essere recuperati. Se devi conservare i contenuti dell'intestazione originale, puoi memorizzarli in un'intestazione personalizzata separata.

In che modo il software di reverse proxy di backend potrebbe modificare l'intestazione X-Forwarded-For

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

1. L'indirizzo IP del GFE che si è connesso al backend. Gli indirizzi IP GFE si trovano negli intervalli 130.211.0.0/22 e 35.191.0.0/16.

2. L'indirizzo IP del sistema di backend stesso.

Di conseguenza, un sistema upstream potrebbe visualizzare un'intestazione X-Forwarded-For strutturata nel seguente modo:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Supporto di Cloud Trace

Trace non è supportata con i bilanciatori del carico delle applicazioni. I bilanciatori del carico delle applicazioni globali e classici aggiungono l'intestazione X-Cloud-Trace-Context se non è presente. Il bilanciatore del carico delle applicazioni esterno regionale non aggiunge questa intestazione. Se l'intestazione X-Cloud-Trace-Context è già presente, viene passata ai bilanciatori del carico senza modifiche. Tuttavia, il bilanciamento del carico non esporta tracce o intervalli.

Mappe URL

Le mappe URL definiscono i pattern di corrispondenza per l'instradamento basato su URL delle richieste ai servizi di backend appropriati. La mappa URL ti consente di dividere il traffico esaminando i componenti dell'URL per inviare richieste a diversi set di backend. Un servizio predefinito è definito per gestire le richieste che non corrispondono a una regola host o a una regola di corrispondenza del percorso specificata.

In alcune situazioni, ad esempio nell'esempio di bilanciamento del carico multiregionale, potresti non definire regole URL e fare affidamento solo sul servizio predefinito.

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

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

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

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

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

Certificati SSL

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

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

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

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

Policy SSL

Le policy SSL specificano l'insieme di funzionalità SSL che i bilanciatori del carico utilizzano durante la negoziazione SSL con i client. Google Cloud

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

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

Modalità del bilanciatore del carico	Policy SSL supportate
Bilanciatore del carico delle applicazioni esterno globale
Bilanciatore del carico delle applicazioni classico
Bilanciatore del carico delle applicazioni esterno regionale

Servizi di backend

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

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

Ambito del servizio di backend

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

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

Protocollo per i backend

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

• HTTP, che utilizza HTTP/1.1 e nessun protocollo TLS
• HTTPS, che utilizza HTTP/1.1 e TLS
• HTTP/2, che utilizza HTTP/2 e TLS (HTTP/2 senza crittografia non è supportato).
• H2C, che utilizza HTTP/2 su TCP. TLS non è richiesto. H2C non è supportato per i bilanciatori del carico delle applicazioni classici.

Il bilanciatore del carico utilizza solo il protocollo del servizio di backend specificato per comunicare con i backend. Il bilanciatore del carico non esegue il failover a un protocollo diverso se non riesce a comunicare con i backend utilizzando il protocollo del servizio di backend specificato.

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

Bucket di backend

I backend bucket 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. Per informazioni generali su Cloud Storage, consulta Che cos'è Cloud Storage?

Backend

La tabella seguente specifica i backend e le funzionalità correlate supportati dai bilanciatori del carico delle applicazioni esterni in ogni modalità.

Modalità del bilanciatore del carico	Backend supportati su un servizio di backend^1						Supporta i bucket di backend	Supporta Cloud Armor	Supporta Cloud CDN^2	Supporta gli acquisti in-app^2	Supporta le estensioni di servizio
	Gruppi di istanze^3	Zonal NEGs^4	NEG internet	NEG serverless	NEGs ibride	NEG Private Service Connect
Bilanciatore del carico delle applicazioni esterno globale
Bilanciatore del carico delle applicazioni classico									Livello Premium
Bilanciatore del carico delle applicazioni esterno regionale

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

² IAP e Cloud CDN sono incompatibili tra loro. Non possono essere abilitati contemporaneamente sullo stesso servizio di backend.

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

⁴ I NEG a livello di zona devono utilizzare endpoint GCE_VM_IP_PORT.

Backend e reti VPC

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

Per i backend del bilanciatore del carico delle applicazioni esterno globale, si applica quanto segue:

• Le istanze di backend (per i backend dei gruppi di istanze) e gli endpoint di backend (per i backend NEG) possono trovarsi in qualsiasi rete VPC all'interno della stessa organizzazione. Le diverse reti VPC non devono essere connesse tramite il peering di rete VPC perché i GFE comunicano direttamente con i backend nelle rispettive reti VPC.

• I bucket Cloud Storage non sono associati a una rete VPC. Possono trovarsi in qualsiasi progetto all'interno della stessa organizzazione.

  I bilanciatori del carico delle applicazioni esterni globali supportano anche gli ambienti VPC condiviso in cui puoi condividere le reti VPC e le relative risorse tra i progetti. Tuttavia, per i bilanciatori del carico delle applicazioni esterni globali, non è necessario configurare il VPC condiviso per poter fare riferimento a servizi di backend o bucket di backend di altri progetti della tua organizzazione.

Per i backend del bilanciatore del carico delle applicazioni classico, si applica quanto segue:

• Tutte le istanze di backend dei backend dei gruppi di istanze e tutti gli endpoint di backend dei backend NEG devono trovarsi nello stesso progetto. Tuttavia, un backend del gruppo di istanze o un NEG può utilizzare una rete VPC diversa in quel progetto. Le diverse reti VPC non devono essere connesse tramite il peering di rete VPC perché i GFE comunicano direttamente con i backend nelle rispettive reti VPC.

• I bucket Cloud Storage non sono associati a una rete VPC. Tuttavia, devono trovarsi nello stesso progetto del bilanciatore del carico.

Per i backend del bilanciatore del carico delle applicazioni esterno regionale, si applica quanto segue:

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

  Definizione della rete di backend

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

  Requisiti di rete di backend

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

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

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

• Sia la rete VPC del backend sia la rete VPC della regola di forwarding devono essere spoke VPC collegati allo stesso hub Network Connectivity Center. I filtri di importazione ed esportazione devono consentire la comunicazione tra la subnet solo proxy nella rete VPC della regola di forwarding e le subnet utilizzate dalle istanze o dagli endpoint di backend.

• Per tutti gli altri tipi di backend, tutti i backend devono trovarsi nella stessa rete VPC e nella stessa regione.

  I bilanciatori del carico delle applicazioni esterni regionali supportano anche gli ambienti VPC condiviso in cui puoi condividere le reti VPC e le risorse associate tra i progetti. Se vuoi che il servizio di backend e i backend del bilanciatore del carico delle applicazioni esterno regionale si trovino in un progetto diverso dalla regola di forwarding, devi configurare il bilanciatore del carico in un ambiente VPC condiviso con riferimento al servizio tra progetti.

Backend e interfacce di rete

Se utilizzi i backend dei gruppi di istanze, i pacchetti vengono sempre inviati a nic0. Se vuoi inviare pacchetti a interfacce non nic0 (vNIC o interfacce di rete dinamiche), utilizza i backend NEG.

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

Controlli di integrità

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

Per i probe del controllo di integrità, devi creare una regola firewall in entrata che consenta ai probe del controllo di integrità di raggiungere le istanze di backend. In genere, i probe di 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 fanno eccezione a questa regola perché i loro controlli di integrità hanno origine dalla subnet proxy-only. Per maggiori dettagli, vedi la panoramica dei NEG ibridi.

Protocollo di controllo di integrità

Sebbene non sia obbligatorio e non sempre possibile, è una best practice utilizzare un controllo di integrità il cui protocollo corrisponda al protocollo del servizio di backend. Ad esempio, un controllo di integrità HTTP/2 verifica con maggiore precisione la connettività HTTP/2 ai backend. 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 di controllo di integrità supportati, consulta Funzionalità di bilanciamento del carico.

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

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

Per saperne di più sui controlli di integrità, consulta le seguenti risorse:

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

Regole firewall

Il bilanciatore del carico richiede le seguenti regole firewall:

• Per i bilanciatori del carico delle applicazioni esterni globali, una regola di autorizzazione in entrata per consentire al traffico proveniente dai Google Front End (GFE) di raggiungere i backend. Per il bilanciatore del carico delle applicazioni esterno regionale, una regola di autorizzazione in entrata per consentire al traffico proveniente 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 saperne di più sui probe del controllo di integrità e sul motivo per cui è necessario consentire il traffico da questi probe, consulta Intervalli IP dei probe e regole firewall.

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

Le porte per queste regole firewall devono essere configurate nel seguente modo:

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

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

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

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

Modalità del bilanciatore del carico	Intervalli di origine del controllo di integrità	Intervalli di origine della richiesta
Bilanciatore del carico delle applicazioni esterno globale	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64	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 connettività ibrida (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 NEG internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG e bucket di backend: la rete di produzione di Google gestisce il routing dei pacchetti.
Bilanciatore del carico delle applicazioni esterno regionale	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64 Non è necessario consentire il traffico proveniente dagli intervalli di probe di controllo di integrità di Google per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e zonali in un unico servizio di backend, devi consentire il traffico dagli intervalli di probecontrollo di integritào dell'integrità di Google per i NEG zonali.	La subnet solo proxy che configuri.

Importante:assicurati di consentire i pacchetti provenienti dagli intervalli di controllo di integrità completi. 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 può comunicare con i backend. Ciò causa risposte con codice di stato HTTP 502.

Assistenza GKE

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

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

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

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

Architettura VPC condiviso

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

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

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

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

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

Il seguente diagramma dell'architettura mostra un deployment VPC condiviso standard in cui tutti i componenti del bilanciatore del carico e i backend 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 sulla rete VPC condiviso (fai clic per ingrandire).

Backend serverless in un ambiente VPC condiviso

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

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

Riferimento ai servizi tra progetti

Il riferimento al servizio tra progetti è un modello di deployment in cui il frontend e la mappa URL del bilanciatore del carico si trovano in un progetto, mentre il servizio di backend e i backend del bilanciatore del carico si trovano in un progetto diverso.

Il riferimento ai servizi tra progetti consente alle organizzazioni di configurare un bilanciatore del carico centrale e instradare il traffico a centinaia di servizi distribuiti su più progetti diversi. Puoi gestire centralmente tutte le regole e le policy di routing del traffico in una sola mappa URL. Puoi anche associare il bilanciatore del carico a un unico insieme di nomi host e certificati SSL. Puoi quindi ottimizzare il numero di bilanciatori del carico necessari per il deployment dell'applicazione e ridurre i requisiti di gestibilità, costi operativi e quote.

Se hai progetti diversi per ciascuno dei tuoi team funzionali, puoi anche ottenere la separazione dei ruoli all'interno della tua 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 gestire i bilanciatori del carico in un altro progetto. Entrambi possono essere collegati utilizzando i riferimenti di servizio tra progetti.

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

Il supporto del riferimento al servizio tra progetti varia in base al tipo di bilanciatore del carico:

• Per i bilanciatori del carico delle applicazioni esterni globali: il frontend e la mappa URL del bilanciatore del carico possono fare riferimento a servizi di backend o bucket di backend di qualsiasi progetto all'interno della stessa organizzazione. Non si applicano limitazioni alla rete VPC. Sebbene tu possa utilizzare un ambiente VPC condiviso per configurare un deployment tra progetti diversi, come mostrato in questo esempio, questo non è un requisito.

• Per i bilanciatori del carico delle applicazioni esterni regionali: devi creare il bilanciatore del carico in un ambiente VPC condiviso. Il frontend e la mappa URL del bilanciatore del carico devono trovarsi in un progetto host o di servizio, mentre i servizi di backend e i backend del bilanciatore del carico possono essere distribuiti tra progetti host o di servizio nello stesso ambiente VPC condiviso.

Per scoprire come configurare VPC condiviso per un bilanciatore del carico delle applicazioni esterno globale, con e senza riferimento al servizio tra progetti, consulta Configura un bilanciatore del carico delle applicazioni esterno globale con VPC condiviso.

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

Note sull'utilizzo per il riferimento ai servizi tra progetti

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

  • Con i bilanciatori del carico delle applicazioni esterni globali, non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha backend NEG serverless con App Engine.

  • Con i bilanciatori del carico delle applicazioni esterni regionali, non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha backend NEG internet regionali.
• I riferimenti ai servizi tra progetti non sono supportati per l'Application Load Balancer classico.
• Google Cloud non distingue le risorse (ad esempio, i servizi di backend) che utilizzano lo stesso nome in più progetti. Pertanto, quando utilizzi i riferimenti ai servizi tra progetti, ti consigliamo di utilizzare nomi dservizio di backendnd univoci nei progetti all'interno della tua organizzazione.
• Se viene visualizzato un errore come "I riferimenti tra progetti per questa risorsa non sono consentiti", assicurati di disporre dell'autorizzazione per utilizzare la risorsa. Un amministratore del progetto proprietario della risorsa deve concederti il ruolo Utente dei servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser). Questo ruolo può essere concesso a livello di progetto o di risorsa. Per un esempio, consulta Concedere le autorizzazioni all'amministratore del bilanciatore del carico Compute per utilizzare il servizio di backend o il bucket di backend.

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

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

In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto di servizio A richiedono l'accesso ai servizi di backend nel progetto di servizio B. Gli amministratori del progetto di servizio B concedono il ruolo Utente dei servizi bilanciatore del carico Compute (roles/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 (fai clic per ingrandire).

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

Di seguito è riportato un esempio di deployment VPC condiviso in cui il frontend e la mappa URL del bilanciatore del carico vengono creati nel progetto host e i servizi di backend (e i backend) vengono creati nei progetti di servizio.

In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto host richiedono l'accesso ai servizi di backend nel progetto di servizio. Gli amministratori del progetto di servizio concedono il ruolo Utente dei servizi bilanciatore del carico Compute (roles/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 (fai clic per ingrandire).

Esempio 3: frontend e backend del bilanciatore del carico in progetti diversi

Di seguito è riportato un esempio di deployment in cui il frontend e la mappa URL del bilanciatore del carico delle applicazioni esterno globale vengono creati in un progetto diverso dal servizio di backend e dai backend del bilanciatore del carico. Questo tipo di deployment non utilizza il VPC condiviso ed è supportato solo per i bilanciatori del carico delle applicazioni esterni globali.

Frontend e backend del bilanciatore del carico in progetti diversi (fai clic per ingrandire).

Per saperne di più su questa configurazione, consulta Configurare il riferimento al servizio tra progetti con un servizio di backend e un bucket di backend.

Alta disponibilità e failover

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

La tabella seguente descrive il comportamento di failover.

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

Supporto di HTTP/2

HTTP/2 è una revisione importante del protocollo HTTP/1. Esistono due modalità di supporto di HTTP/2:

• HTTP/2 su TLS
• Testo in chiaro HTTP/2 su TCP

HTTP/2 su TLS

HTTP/2 su TLS è 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 HTTP/2 per impostazione predefinita. Questo è controllato sul 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 protette. Queste richieste HTTPS o HTTP vengono quindi trasformate dal bilanciatore del carico per eseguire il proxy delle richieste su HTTP/2 alle istanze di backend.

Per utilizzare HTTP/2 su TLS, devi attivare TLS sui backend e impostare il protocollo del servizio di backend su HTTP2. Per ulteriori informazioni, vedi Crittografia dal bilanciatore del carico ai backend.

Numero massimo di flussi di dati in parallelo HTTP/2

L'impostazione HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descrive il numero massimo di flussi accettati da un endpoint, avviati dal peer. Il valore pubblicizzato da un client HTTP/2 a un bilanciatore del caricoGoogle Cloud è effettivamente privo di significato perché il bilanciatore del carico non avvia flussi 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 annunciato dal server. Se viene pubblicizzato un valore pari a zero, il bilanciatore del carico non può inoltrare le richieste al server e ciò potrebbe causare errori.

Limitazioni di HTTP/2

• HTTP/2 tra il bilanciatore del carico e l'istanza può richiedere molte più connessioni TCP all'istanza rispetto a HTTP o HTTPS. Il pool di connessioni, un'ottimizzazione che riduce il numero di queste connessioni con HTTP o HTTPS, non è disponibile con HTTP/2. Di conseguenza, potresti notare latenze di backend elevate perché le connessioni di backend vengono effettuate più frequentemente.
• 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.
• Il tasso di errori e il volume delle richieste gRPC non sono visibili nell'APIGoogle Cloud o nella console Google Cloud . Se l'endpoint gRPC restituisce un errore, i log del bilanciamento del carico e i dati di monitoraggio riportano il codice di stato HTTP 200 OK.

Testo non crittografato HTTP/2 su TCP (H2C)

HTTP/2 di testo non crittografato su TCP, noto anche come H2C, consente di utilizzare HTTP/2 senza TLS. H2C è supportato per entrambe le seguenti connessioni:

• Connessioni tra i client e il bilanciatore del carico. Non è richiesta alcuna configurazione speciale.

• Connessioni tra il bilanciatore del carico e i relativi backend.

  Per configurare H2C per le connessioni tra il bilanciatore del carico e i relativi backend, imposta il protocollo del servizio di backend su H2C.

Il supporto di H2C è disponibile anche per i bilanciatori del carico creati utilizzando il controller GKE Gateway e Cloud Service Mesh.

H2C non è supportato per i bilanciatori del carico delle applicazioni classici.

Supporto di HTTP/3

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

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

In particolare:

• IETF QUIC è un protocollo del livello di trasporto che fornisce controllo della congestione e affidabilità simili a TCP, utilizza TLS 1.3 per la sicurezza e offre prestazioni migliorate.
• HTTP/3 è un livello applicativo basato su IETF QUIC e si basa su QUIC per gestire il multiplexing, il controllo della congestione, il rilevamento delle perdite e la ritrasmissione.
• HTTP/3 consente un avvio più rapido della connessione client, elimina i blocchi head-of-line nei flussi multiplex e supporta la migrazione di connessioni quando un indirizzo IP client viene modificato.
• HTTP/3 è supportato per le connessioni tra i client e il bilanciatore del carico, 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 il throughput sulle connessioni con latenza più elevata.

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

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

Come viene negoziato HTTP/3

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

• I client implementati correttamente eseguono sempre il fallback a HTTPS o HTTP/2 quando non riescono a stabilire una connessione HTTP/3.
• I client che supportano HTTP/3 utilizzano le proprie conoscenze precedenti memorizzate nella cache del supporto di HTTP/3 per evitare round trip non necessari in futuro.
• A causa di questo fallback, l'attivazione o la disattivazione di HTTP/3 nel bilanciatore del carico non influisce sulla capacità del bilanciatore del carico di connettersi ai client.

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

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

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

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

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

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

Quando una connessione esegue il fallback a HTTPS o HTTP/2, non lo consideriamo un errore del bilanciatore del carico.

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

Configurare HTTP/3

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

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

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

Valore di quicOverride	Comportamento
NONE	Il supporto di HTTP/3 viene pubblicizzato ai client.
ENABLE	Il supporto di HTTP/3 viene pubblicizzato ai client.
DISABLE	Disattiva esplicitamente la pubblicità HTTP/3 e Google QUIC per i client.

Per attivare (o disattivare) esplicitamente HTTP/3, 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 da 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.

Attiva HTTP/3

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

Disattivare HTTP/3

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

gcloud: HTTPS

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

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

Sostituisci QUIC_SETTING con una delle seguenti opzioni:

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

  Quando selezioni NONE, HTTP/3 viene pubblicizzato ai client, ma Google QUIC non viene pubblicizzato. Nella console Google Cloud , questa opzione è denominata Automatico (predefinito).

• ENABLE: annuncia HTTP/3 ai client.

• DISABLE: non pubblicizza HTTP/3 ai client.

API: HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

Sostituisci QUIC_SETTING con una delle seguenti opzioni:

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

  Quando selezioni NONE, HTTP/3 viene pubblicizzato ai client, ma Google QUIC non viene pubblicizzato. Nella console Google Cloud , questa opzione è denominata Automatico (predefinito).

• ENABLE: annuncia HTTP/3 e Google QUIC ai client.

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

Supporto di WebSocket

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

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

Il protocollo WebSocket funziona nel seguente modo:

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

Se l'istanza di backend restituisce un codice di stato 426 o 502, il bilanciatore del carico chiude la connessione.

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

L'affinità sessione per i websocket funziona come per qualsiasi altra richiesta. Per saperne di più, consulta Affinità di sessione.

Supporto gRPC

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

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

Per utilizzare gRPC con le tue Google Cloud applicazioni, devi eseguire il proxy delle richieste end-to-end su HTTP/2. Per farlo, crea un bilanciatore del carico delle applicazioni con una delle seguenti configurazioni:

• Per il traffico non criptato end-to-end (senza TLS): crei un bilanciatore del carico HTTP (configurato con un proxy HTTP di destinazione). Inoltre, configura il bilanciatore del carico in modo che utilizzi HTTP/2 per le connessioni non criptate tra il bilanciatore del carico e i relativi backend impostando il protocollo del servizio di backend su H2C.

• Per il traffico criptato end-to-end (con TLS): crei un bilanciatore del carico HTTPS (configurato con un proxy HTTPS di destinazione e un certificato SSL). Il bilanciatore del carico negozia HTTP/2 con i client nell'ambito dell'handshake SSL utilizzando l'estensione TLS ALPN.

  Inoltre, devi assicurarti che i backend possano gestire il traffico TLS e configurare il bilanciatore del carico in modo che utilizzi HTTP/2 per le connessioni criptate tra il bilanciatore del carico e i relativi backend impostando il protocollo del servizio di backend su HTTP2.

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

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

Se vuoi configurare un bilanciatore del carico delle applicazioni esterno utilizzando HTTP/2 con Cloud Run, consulta Utilizzare HTTP/2 dietro un bilanciatore del carico.

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

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

Supporto TLS

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

Quando il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni esterno regionale utilizza HTTPS come protocollo del servizio di backend, può negoziare TLS 1.2 o 1.3 con il backend.

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

Supporto di mutual TLS

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

Tutti i bilanciatori del carico delle applicazioni supportano mTLS. Con mTLS, il bilanciatore del carico richiede al client di inviare un certificato per autenticarsi durante l'handshake TLS con il bilanciatore del carico. Puoi configurare un archivio attendibilità di Certificate Manager che il bilanciatore del carico utilizza per convalidare la catena di attendibilità del certificato client.

Per ulteriori informazioni su mTLS, vedi Autenticazione TLS reciproca.

Supporto di TLS 1.3 Early Data

Nota :TLS 1.3 early data o 0-RTT è supportato solo per la ripresa delle sessioni precedenti tra i client e Cloud CDN o il bilanciatore del carico. Cloud CDN o il bilanciatore del carico non possono utilizzare i dati iniziali TLS quando inoltrano le richieste ai server di origine.

TLS 1.3 Early Data è supportato sul proxy HTTPS di destinazione dei seguenti bilanciatori del carico delle applicazioni esterni sia per HTTPS su TCP (HTTP/1.1, HTTP/2) sia per HTTP/3 su QUIC:

• Bilanciatori del carico delle applicazioni esterni globali
• Bilanciatori del carico delle applicazioni classici

TLS 1.3 è stato definito nella RFC 8446 e introduce il concetto di dati iniziali, noti anche come dati tempo di round trip (0-RTT), che possono migliorare le prestazioni delle applicazioni per le connessioni riprese del 30-50%.

Con TLS 1.2, sono necessari due round trip prima che i dati possano essere trasmessi in modo sicuro. TLS 1.3 riduce questo valore a un round trip (1-RTT) per le nuove connessioni, consentendo ai client di inviare i dati dell'applicazione immediatamente dopo la prima risposta del server. Inoltre, TLS 1.3 introduce il concetto di dati iniziali per le sessioni riprese, consentendo ai client di inviare dati dell'applicazione con il ClientHello iniziale, riducendo così il tempo di round trip effettivo a zero (0-RTT). I dati iniziali di TLS 1.3 consentono al server di backend di iniziare a elaborare i dati del client prima che il processo di handshake con il client sia completato, riducendo così la latenza; tuttavia, è necessario prestare attenzione per mitigare i rischi di replay.

Poiché i dati iniziali vengono inviati prima del completamento dell'handshake, un malintenzionato può tentare di acquisire e riprodurre le richieste. Per mitigare questo problema, il server di backend deve controllare attentamente l'utilizzo dei dati iniziali, limitandone l'uso a richieste idempotenti. I metodi HTTP che dovrebbero essere idempotenti, ma che potrebbero attivare modifiche non idempotenti, ad esempio una richiesta GET che modifica un database, non devono accettare Early Data. In questi casi, il server di backend deve rifiutare le richieste con l'intestazione HTTP Early-Data: 1 restituendo un codice di stato HTTP 425 Too Early.

Le richieste con early data hanno l'intestazione HTTP Early-Data impostata sul valore 1, che indica al server di backend che la richiesta è stata trasmessa in early data TLS. Indica inoltre che il client comprende il codice di stato HTTP 425 Too Early.

Modalità TLS Early Data (0-RTT)

Puoi configurare TLS Early Data utilizzando una delle seguenti modalità sulla risorsa proxy HTTPS di destinazione del bilanciatore del carico.

• STRICT. In questo modo vengono abilitati i dati iniziali TLS 1.3 per le richieste con metodi HTTP sicuri (GET, HEAD, OPTIONS, TRACE) e le richieste HTTP che non hanno parametri di query. Le richieste che inviano dati iniziali contenenti metodi HTTP non idempotenti (come POST o PUT) o con parametri di ricerca vengono rifiutate con un codice di stato HTTP 425.

• PERMISSIVE. In questo modo vengono abilitati i dati iniziali TLS 1.3 per le richieste con metodi HTTP sicuri (GET, HEAD, OPTIONS, TRACE). Questa modalità non nega le richieste che includonoparametri di ricercay. Il proprietario dell'applicazione deve assicurarsi che i dati iniziali siano sicuri da utilizzare per ogni percorso di richiesta, in particolare per gli endpoint in cui la riproduzione delle richieste potrebbe causare effetti collaterali indesiderati, ad esempio aggiornamenti di logging o del database attivati da richieste GET.

• DISABLED. TLS 1.3 Early Data non viene pubblicato e i tentativi (non validi) di inviare Early Data vengono rifiutati. Se le tue applicazioni non sono attrezzate per gestire in sicurezza le richieste di dati anticipate, devi disattivare i dati anticipati. TLS 1.3 Early Data è disattivato per impostazione predefinita.

• UNRESTRICTED (non consigliato per la maggior parte dei workload). In questo modo vengono abilitati i dati iniziali TLS 1.3 per le richieste con qualsiasi metodo HTTP, inclusi quelli non idempotenti, come POST. In questa modalità non vengono applicate altre limitazioni. Questa modalità può essere utile per i casi d'uso gRPC. Tuttavia, non consigliamo questo metodo a meno che tu non abbia valutato la tua strategia di sicurezza e mitigato il rischio di attacchi di replay utilizzando altri meccanismi.

Configurare TLS Early Data

Per attivare o disattivare in modo esplicito TLS early data:

Console

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

   Vai a Bilanciamento del carico

2. Seleziona il bilanciatore del carico per il quale devi attivare i dati iniziali.

3. Fai clic su Modifica.

4. Fai clic su Configurazione frontend.

5. Seleziona l'indirizzo IP e la porta frontend che vuoi modificare. Per abilitare TLS Early Data, il protocollo deve essere HTTPS.

6. Nell'elenco Early Data (0-RTT), seleziona una modalità di early data TLS.

7. Fai clic su Fine.

8. Per aggiornare il bilanciatore del carico, fai clic su Aggiorna.

gcloud

1. Configura la modalità TLS Early Data sul proxy HTTPS di destinazione di un bilanciatore del carico delle applicazioni.

   gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
     --tls-early-data=TLS_EARLY_DATA_MODE
   

   Sostituisci quanto segue:

   • TARGET_HTTPS_PROXY: il proxy HTTPS di destinazione del tuo bilanciatore del carico
   • TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED o UNRESTRICTED

API

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Sostituisci quanto segue:

• TARGET_HTTPS_PROXY: il proxy HTTPS di destinazione del tuo bilanciatore del carico
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED o UNRESTRICTED
• FINGERPRINT: una stringa codificata in Base64. Per applicare una patch al proxy HTTPS di destinazione, è necessario fornire un'impronta aggiornata. In caso contrario, la richiesta non va a buon fine e viene restituito un codice di stato HTTP 412 Precondition Failed.

Dopo aver configurato TLS Early Data, puoi inviare richieste da un client HTTP che supporta TLS Early Data. Puoi osservare una latenza inferiore per le richieste riprese.

Se un client non conforme all'RFC invia una richiesta con un metodo non idempotente o conparametri di ricercay, la richiesta viene rifiutata. Nei log del bilanciatore del carico viene visualizzato un codice di stato HTTP 425 Early e la seguente risposta HTTP:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Limitazioni

• I bilanciatori del carico HTTPS non inviano un close_notify avviso di chiusura quando terminano le connessioni SSL. ovvero il bilanciatore del carico chiude la connessione TCP anziché eseguire un arresto SSL.

• I bilanciatori del carico HTTPS supportano solo 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 SNI (Server Name Indication) quando si connettono al backend, ad eccezione dei bilanciatori del carico con backend di NEG Internet. Per ulteriori informazioni, consulta la sezione Crittografia dal bilanciatore del carico ai backend.

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

• Quando crei un bilanciatore del carico delle applicazioni esterno regionale nel livello Premium utilizzando la consoleGoogle Cloud , nella console Google Cloud sono disponibili solo le regioni che supportano il livello Standard. Per accedere ad altre regioni, utilizza gcloud CLI o l'API.

• I proxy GFE utilizzati dai bilanciatori del carico delle applicazioni globali e classici non supportano le risposte anticipate 200 OK inviate prima che il payload POST della richiesta sia stato completamente sottoposto a proxy al backend. L'invio di una risposta 200 OK anticipata fa sì che GFE chiuda la connessione al backend.

  Il backend deve rispondere con 100 Continue risposte dopo aver ricevuto le intestazioni della richiesta, quindi attendere che il payload POST della richiesta sia stato completamente sottoposto a proxy prima di rispondere con il codice di risposta finale 200 OK.

• Quando utilizzi bilanciatori del carico delle applicazioni esterni regionali con Cloud Run in un ambiente VPC condiviso, le reti VPC autonome nei progetti di servizio possono inviare traffico a qualsiasi altro servizio Cloud Run di cui è stato eseguito il deployment in qualsiasi altro progetto di servizio all'interno dello stesso ambiente VPC condiviso. Questo è un problema noto.

• Cloud CDN consente di forzare l'ignoramento di un oggetto o di un insieme di oggetti da parte della cache richiedendo un'invalidazione della cache. Quando utilizzi un bilanciatore del carico delle applicazioni esterno globale con riferimento al servizio tra progetti VPC condiviso, per impostazione predefinita gli amministratori dei progetti di servizio non dispongono delle autorizzazioni necessarie per richiedere invalidazioni della cache. Questo perché l'invalidazione della cache è configurata nel progetto frontend (ovvero il progetto che contiene la regola di forwarding, il proxy di destinazione e la mappa URL del bilanciatore del carico). Pertanto, le invalidazioni della cache possono essere emesse solo dalle entità che dispongono dei ruoli IAM per la configurazione delle risorse correlate al bilanciamento 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, devono collaborare con l'amministratore del bilanciatore del carico del progetto frontend per emettere l'invalidazione della cache per i servizi tra progetti.

Passaggi successivi

• Per scoprire come i bilanciatori del carico delle applicazioni esterni gestiscono le connessioni, indirizzano il traffico e mantengono l'affinità sessione, consulta Distribuzione delle richieste per i bilanciatori del carico delle applicazioni esterni.

• Per scoprire 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 scoprire come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno regionale, consulta Configurazione di un bilanciatore del carico delle applicazioni esterno regionale con un backend Compute Engine.

• Se sei un utente esistente del bilanciatore del carico delle applicazioni classico, assicurati di consultare la panoramica della migrazione quando pianifichi un nuovo deployment con il bilanciatore del carico delle applicazioni esterno globale.

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

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

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

• Per informazioni sulla pubblicazione di siti web, consulta Pubblicazione di siti web.

• Per trovare le posizioni dei PoP di Google, vedi Località GFE.

• Per scoprire di più sulla gestione della capacità, consulta l'esercitazione sulla gestione della capacità con il bilanciamento del carico e le ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale.

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

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

• Solo per i bilanciatori del carico delle applicazioni esterni regionali, puoi provare a utilizzare Apigee Shadow API Discovery per trovare le API shadow (note anche come API non documentate) nella tua infrastrutturaGoogle Cloud esistente. Prima di attivare Rilevamento delle API Shadow, assicurati di leggere le limitazioni associate.