Panoramica del bilanciamento del carico HTTP(S) esterno

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento introduce i concetti che è necessario comprendere per configurare il bilanciamento del carico HTTP(S) esterno di Google Cloud.

Il bilanciamento del carico HTTP(S) 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 bilanciamento del carico HTTP(S) esterno distribuisce il traffico HTTP e HTTPS in backend ospitati su diverse piattaforme Google Cloud (ad esempio Compute Engine, Google Kubernetes Engine, GKE), Cloud Storage e così via), nonché backend esterni collegati a Internet o tramite connettività ibrida. Per maggiori dettagli, vedi Casi d'uso.

Modalità di funzionamento

Puoi configurare il bilanciamento del carico HTTP(S) esterno nelle seguenti modalità:

  • Bilanciatore del carico HTTP(S) 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 mirroring del traffico, suddivisione del traffico basata sul peso, trasformazioni di intestazione basate su richieste/risposte e altro ancora.
  • Bilanciatore del carico HTTP(S) esterno globale (classico). Questo è il classico bilanciatore del carico HTTP(S) esterno globale nel livello Premium, ma può essere configurato a livello di regione nel livello standard. Questo bilanciatore del carico è implementato su Google Front End (GFE). I GFE sono distribuiti a livello globale e operano insieme utilizzando la rete globale e il piano di controllo di Google.
  • Bilanciatore del carico HTTP(S) a livello di area geografica. Si tratta di un bilanciatore del carico a livello di area geografica, implementato come servizio gestito nel proxy Envoy open source. Include funzionalità di gestione avanzata del traffico come mirroring del traffico, suddivisione del traffico basata sul peso, trasformazioni dell'intestazione basate su richieste/risposta e altro ancora.
Modalità bilanciatore del carico Casi d'uso consigliati Funzionalità
Bilanciatore del carico HTTP(S) esterno globale Utilizza questo bilanciatore del carico per carichi di lavoro HTTP(S) esterni con utenti o servizi di backend dislocati a livello globale in più aree geografiche.
Bilanciatore del carico HTTP(S) esterno globale (versione classica)

Questo bilanciatore del carico è globale nel livello Premium, ma può essere configurato per essere efficace a livello di regione nel livello Standard.

Nel livello di servizio di rete Premium, questo bilanciatore del carico offre il bilanciamento del carico a più aree geografiche, indirizzando il traffico al backend integro più vicino che ha capacità e termina il traffico HTTP(S) il più vicino possibile agli utenti.

Nel livello di servizio di rete standard, il bilanciamento del carico viene gestito a livello di area geografica.

  • Compatibile con GKE tramite Ingress o Gateway (completamente orchestrati).
  • Supporta Google Cloud Armor (inclusa la gestione di bot).
  • Meno funzionalità per il routing del traffico.
Consulta la pagina Funzionalità di bilanciamento del carico per l'elenco completo delle funzionalità.
Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Questo bilanciatore del carico contiene molte delle funzionalità dell'attuale bilanciatore del carico HTTP(S) esterno globale (classico), oltre alle funzionalità di gestione avanzata del traffico.

Utilizza questo bilanciatore del carico se vuoi gestire i contenuti da una sola geolocalizzazione (ad esempio per soddisfare le normative di conformità) o se vuoi il livello di servizio di rete standard.

Per l'elenco completo, consulta Funzionalità di bilanciamento del carico.

Identificare la modalità

console Cloud

  1. In Google Cloud Console, vai alla pagina Bilanciamento del carico.
    Vai a Bilanciamento del carico
  2. Nella scheda Bilanciatori del carico, vengono visualizzati il tipo, il protocollo e l'area geografica 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 bilanciamento del carico Regione Livello di rete
    Bilanciatore del carico HTTP(S) esterno globale HTTP(S) PREMIUM
    Bilanciatore del carico HTTP(S) esterno globale (versione classica) HTTP(S)(classico) STANDARD o PREMIUM
    Bilanciatore del carico HTTP(S) esterno a livello di area geografica HTTP(S) Specifica una regione STANDARD

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 riepiloga 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 HTTP(S) esterno globale Gestito all'esterno Globale PREMIUM
    Bilanciatore del carico HTTP(S) esterno globale (versione classica) ESTERNO Globale STANDARD o PREMIUM
    Bilanciatore del carico HTTP(S) esterno a livello di area geografica Gestito all'esterno Specifica una regione STANDARD

Architettura

Per un deployment del bilanciamento del carico HTTP(S) sono necessarie le seguenti risorse:

  • Solo per i bilanciatori del carico HTTP(S) esterni a livello di area geografica, 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 sul traffico. Il proxy può anche autenticare le comunicazioni utilizzando i certificati SSL.

    • Per il bilanciamento del carico HTTPS, il proxy HTTPS di destinazione utilizza i certificati SSL per dimostrare la propria identità ai client. Un proxy HTTPS di destinazione supporta fino al numero documentato dei certificati SSL.
  • Il proxy HTTP(S) utilizza una mappa URL per determinare i percorsi in base agli attributi HTTP (ad esempio percorso della richiesta, cookie o intestazioni). In base alla decisione di routing, il proxy inoltra le richieste del client a servizi o bucket di backend specifici. La mappa URL può specificare azioni aggiuntive, come l'invio di reindirizzamenti ai client.

  • Un servizio di backend distribuisce le richieste a backend integri. I bilanciatori del carico HTTP(S) esterni globali supportano anche i bucket di backend.

    • Uno o più backend devono essere connessi al servizio o al bucket di backend.
  • Un controllo di integrità monitora periodicamente l'idoneità dei tuoi backend. Ciò riduce il rischio che le richieste vengano inviate a backend che non possono gestire la richiesta.

  • Regole firewall per i backend per accettare probe di controllo di integrità. I bilanciatori del carico HTTP(S) esterni a livello di area geografica richiedono una regola firewall aggiuntiva per consentire il traffico proveniente dalla subnet solo proxy per raggiungere i backend.

Globale

Questo diagramma mostra i componenti di un deployment di un bilanciatore del carico HTTP(S) esterno globale. Questa architettura si applica sia al bilanciatore del carico HTTP(S) esterno globale con funzionalità di gestione avanzata del traffico sia al bilanciatore del carico HTTP(S) esterno globale (classico) nel livello Premium.

Componenti del bilanciatore del carico HTTP(S) esterno globale
Componenti globali del bilanciatore del carico HTTP(S)

Regionale

Questo diagramma mostra i componenti di un deployment di un bilanciatore del carico HTTP(S) esterno a livello di regione.

Componenti del bilanciatore del carico HTTP(S) esterno a livello di regione
Componenti del bilanciatore del carico HTTP(S) a livello di area geografica

Subnet solo proxy

Le subnet solo proxy sono richieste solo per i bilanciatori del carico HTTP(S) esterni a livello di regione.

La subnet solo proxy fornisce un set di indirizzi IP che Google utilizza per eseguire i proxy Envoy per tuo conto. Devi creare una subnet solo proxy in ogni area geografica di una rete VPC in cui utilizzi bilanciatori del carico HTTP(S) esterni a livello di area geografica. Il flag --purpose per questa subnet solo proxy è impostato su REGIONAL_MANAGED_PROXY. Tutti i bilanciatori del carico basati su Envoy a livello di area geografica nella stessa area geografica 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 backend.
  • Le VM o gli endpoint di backend di tutti i bilanciatori del carico HTTP(S) esterni di una regione e di una rete VPC ricevono le connessioni dalla subnet solo proxy.
  • L'indirizzo IP del bilanciatore del carico HTTP(S) esterno a livello di area geografica non si trova nella subnet solo proxy. L'indirizzo IP del bilanciatore del carico è definito dalla relativa regola di forwarding gestito esterno, 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 per 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 per te.

  • La regola di forwarding per un bilanciatore del carico HTTP può fare riferimento solo alle porte TCP 80 e 8080.
  • La regola di forwarding per un bilanciatore del carico HTTPS può fare riferimento solo alla porta TCP 443.

Il tipo di regola di forwarding, l'indirizzo IP e lo schema di bilanciamento del carico utilizzati dai bilanciatori del carico HTTP(S) 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 HTTP(S) 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 HTTP(S) esterno globale (versione classica) Livello Premium

Regola di forwarding esterno globale

Indirizzo IP esterno globale

Schema di bilanciamento del carico:
EXTERNAL

Richieste indirizzate 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 HTTP(S) esterno a livello di area geografica Livello Standard

Regola di forwarding esterno a livello di regione

Indirizzo IP esterno a livello di regione

Schema di bilanciamento del carico:
EXTERNAL_MANAGED

Richieste instradate ai proxy Envoy nella stessa regione del bilanciatore del carico.

Per l'elenco completo dei protocolli supportati dalle regole di forwarding di bilanciamento del carico HTTP(S) in ogni modalità, consulta le 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 indirizzare il traffico ai backend.

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

La tabella seguente specifica il tipo di proxy di destinazione richiesto dal bilanciamento del carico HTTP(S) in ciascuna modalità.

Modalità bilanciatore del carico Tipi di proxy di destinazione Intestazioni aggiunte a proxy Intestazioni personalizzate supportate Cloud Trace supportato
Bilanciatore del carico HTTP(S) esterno globale HTTP globale,
HTTPS globale
I proxy impostano le intestazioni di richiesta/risposta HTTP come segue:
  • Via: 1.1 google (richieste e risposte)
  • X-Forwarded-Proto: [http | https] (solo richieste)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo richieste)
    Contiene i parametri per Cloud Trace.
  • X-Forwarded-For: [<provided-value>,]<client-ip>,<load-balancer-ip> (vedi X-Forwarded-For intestazioni) (solo richieste)
Configurato sul servizio di backend o nel bucket di backend

Non supportati con Cloud CDN

Bilanciatore del carico HTTP(S) esterno globale (versione classica) HTTP globale,
HTTPS globale
I proxy impostano le intestazioni di richiesta/risposta HTTP come segue:
  • Via: 1.1 google (richieste e risposte)
  • X-Forwarded-Proto: [http | https] (solo richieste)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo richieste)
    Contiene i parametri per Cloud Trace.
  • X-Forwarded-For: [<provided-value>,]<client-ip>,<load-balancer-ip> (vedi X-Forwarded-For intestazioni) (solo richieste)
Configurato sul servizio di backend o nel bucket di backend
Bilanciatore del carico HTTP(S) esterno a livello di area geografica HTTP a livello di area geografica,
HTTPS a livello di area geografica
  • X-Forwarded-Proto: [http | https] (solo richieste)
  • Via: 1.1 google (richieste e risposte)
  • X-Forwarded-For: [<provided-value>,]<client-ip>,<load-balancer-ip> (vedi X-Forwarded-For intestazioni) (solo richieste)

Intestazione host

Quando il bilanciatore del carico invia la richiesta HTTP, conserva la relativa 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 nella richiesta in entrata non è presente un'intestazione X-Forwarded-For, i due indirizzi IP corrispondono all'intero valore dell'intestazione:

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

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

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

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

  • L'indirizzo IP del Google Front End (GFE) che ha stabilito la connessione 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 a monte 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 delle richieste ai servizi di backend appropriati in base all'URL. Un servizio predefinito è definito per gestire qualsiasi richiesta che non corrisponde a una regola host o a una regola di corrispondenza del percorso specificata. In alcune situazioni, ad esempio nell'esempio di bilanciamento del carico su più aree geografiche, 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 suddividere il traffico esaminando i componenti degli URL per inviare richieste a diversi set di backend.

Le mappe URL utilizzate con bilanciatori del carico HTTP(S) esterni globali e bilanciatori del carico HTTP(S) esterni a livello di area geografica supportano diverse funzionalità avanzate di gestione del traffico come sterzo del traffico basato su intestazione, suddivisione del traffico basata sul peso e mirroring delle richieste. Per ulteriori informazioni, consulta quanto segue:

La tabella seguente specifica il tipo di mappa URL richiesta dal bilanciamento del carico HTTP(S) in ciascuna modalità.

Modalità bilanciatore del carico Tipo di mappa URL
Bilanciatore del carico HTTP(S) esterno globale Globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica) Globale (con solo un sottoinsieme delle funzionalità supportate)
Bilanciatore del carico HTTP(S) esterno a livello di area geografica Regione

Certificati SSL

TLS (Transport Layer Security) è un protocollo di crittografia utilizzato nei certificati SSL per proteggere le comunicazioni di rete.

Google Cloud utilizza i certificati SSL per fornire privacy e sicurezza da un client a un bilanciatore del carico. Se utilizzi il bilanciamento del carico basato su HTTPS, devi installare uno o più certificati SSL sul proxy HTTPS di destinazione.

La tabella seguente specifica l'ambito del certificato SSL richiesto dal bilanciamento del carico HTTP(S) in ciascuna modalità:

Modalità bilanciatore del carico Ambito del certificato SSL
Bilanciatore del carico HTTP(S) esterno globale Globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica) Globale
Bilanciatore del carico HTTP(S) esterno a livello di area geografica Regione

Per ulteriori informazioni sui certificati SSL, consulta quanto segue:

Certificate Manager

Se utilizzi il bilanciatore del carico HTTP(S) esterno globale (classico) nel livello di servizio di rete Premium, puoi utilizzare Gestione certificati per eseguire il provisioning e gestire i certificati SSL su più istanze del bilanciatore del carico HTTP(S) esterno globale (classico) su larga scala. Per ulteriori informazioni, consulta la panoramica di Certificate Manager.

Criteri SSL

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

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

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

Modalità bilanciatore del carico Criteri SSL supportati
Bilanciatore del carico HTTP(S) esterno globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica)
Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Servizi e bucket di backend

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 Compute Engine, consulta Configurare un bilanciatore del carico HTTP(S) esterno con un backend 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 HTTP(S) esterno, consulta Configurazione di un bilanciatore del carico con bucket di backend.

La tabella seguente specifica le funzionalità di backend supportate dal bilanciamento del carico HTTP(S) in ogni 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
Gruppi di istanze NEG NEGLI NEG Internet NEG serverless NEG ibridi NEG di Private Service Connect
Bilanciatore del carico HTTP(S) esterno globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica)
quando utilizzi il livello Premium

Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Per ulteriori informazioni, consulta quanto segue:

Backend e reti VPC

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

  • Per il bilanciatore del carico HTTP(S) esterno globale e il bilanciatore del carico HTTP(S) esterno globale (classico), tutti i backend devono trovarsi nello stesso progetto, ma possono trovarsi in reti VPC diverse. Non è necessario connettere le diverse reti VPC utilizzando il peering di rete VPC perché i sistemi proxy GFE comunicano direttamente con i backend nelle rispettive reti VPC.
  • Per il bilanciatore del carico HTTP(S) esterno a livello di area geografica, tutti i backend devono trovarsi nella stessa rete VPC e nella stessa area geografica.

Protocollo ai backend

Quando configuri un servizio di backend per il bilanciatore del carico, devi impostare il protocollo utilizzato dal servizio di backend per comunicare con i backend. Puoi scegliere tra HTTP, HTTPS e HTTP/2. Il bilanciatore del carico utilizza solo il protocollo specificato. Il bilanciatore del carico non usa 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, consulta Funzionalità di bilanciamento del carico: protocolli dal bilanciatore del carico ai backend.

Supporto WebSocket

I bilanciatori del carico basati su HTTP(S) di Google Cloud supportano in modo nativo il protocollo WebSocket quando utilizzi HTTP o HTTPS come protocollo nel 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. Una richiesta HTTP(S) avvia il canale. Per informazioni dettagliate sul protocollo, consulta RFC 6455.

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

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.

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

Utilizzo di gRPC con le applicazioni Google Cloud

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

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

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

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

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

Il bilanciatore del carico potrebbe comunque negoziare HTTPS con alcuni client o accettare richieste HTTP non sicure su un bilanciatore del carico configurato per 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 in modo che proxy le richieste su HTTP/2 alle istanze di backend.

Devi abilitare TLS sui tuoi backend. Per saperne di più, consulta Crittografia dal bilanciatore del carico ai backend.

Se vuoi configurare un bilanciatore del carico HTTP(S) esterno utilizzando HTTP/2 con Ingress di Google Kubernetes Engine o gRPC e HTTP/2 con Ingress, vedi HTTP/2 per il bilanciamento del carico con Ingress.

Per informazioni sulla risoluzione dei problemi con HTTP/2, consulta Risoluzione dei problemi con HTTP/2 nei backend.

Per informazioni sulle limitazioni HTTP/2, consulta Limitazioni HTTP/2.

Controlli di integrità

Ogni servizio di backend specifica un controllo di integrità per le istanze di backend.

Per i probe del controllo di integrità, devi creare una regola firewall in entrata che consenta al traffico di raggiungere le tue istanze di backend. La regola firewall deve consentire i seguenti intervalli di origine:

  • 130.211.0.0/22
  • 35.191.0.0/16

Sebbene non sia obbligatorio, una best practice consiste nell'utilizzare un controllo di integrità il cui protocollo corrisponde al protocollo del servizio di backend. Ad esempio, un controllo di integrità HTTP/2 verifica con maggiore precisione la connettività HTTP/2 ai backend. Per l'elenco dei protocolli di controllo di integrità supportati, consulta le funzionalità di bilanciamento del carico.

La tabella seguente specifica l'ambito del controllo di integrità supportato dal bilanciamento del carico HTTP(S) in ogni modalità.

Modalità bilanciatore del carico Tipo di controllo di integrità
Bilanciatore del carico HTTP(S) esterno globale Globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica) Globale
Bilanciatore del carico HTTP(S) esterno a livello di area geografica Regione

Per ulteriori informazioni sui controlli di integrità, consulta quanto segue:

Regole del firewall

Il bilanciamento del carico HTTP(S) richiede le seguenti regole firewall:

  • Per i bilanciatori del carico HTTP(S) esterni globali, una regola di autorizzazione in entrata per consentire il traffico dai Google Front End (GFE) di raggiungere i tuoi backend.
    Per il bilanciatore del carico HTTP(S) esterno a livello di area geografica, 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 proveniente 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, consulta Intervalli IP e regole del firewall.

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 il bilanciatore del carico HTTP(S) esterno globale e il bilanciatore del carico HTTP(S) esterno globale (classico), puoi utilizzare Google Cloud Armor per ottenere questo risultato.

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

  • Consenti il traffico alla porta di destinazione per il controllo di integrità di ogni 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 in ogni gruppo di istanze. I numeri di porta possono variare a seconda dei 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 riportata di seguito riassume gli intervalli di indirizzi IP di origine richiesti per le regole firewall:

Modalità bilanciatore del carico Intervalli di origine del controllo di integrità Intervalli di origini richiesta
Bilanciatore del carico HTTP(S) esterno globale
  • 130.211.0.0/22
  • 35.191.0.0/16
L'origine del traffico GFE dipende dal tipo di backend:
  • Gruppi di istanze, NEG di zona (GCE_VM_IP_PORT) e NEG di connettività ibrida (NON_GCP_PRIVATE_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16
  • SERVERLESS NEG e bucket di backend: la rete di produzione di Google gestisce il routing dei pacchetti
Bilanciatore del carico HTTP(S) esterno globale (versione classica)
  • 130.211.0.0/22
  • 35.191.0.0/16
L'origine del traffico GFE dipende dal tipo di backend:
  • Gruppi di istanze, NEG di zona (GCE_VM_IP_PORT) e 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 HTTP(S) esterno a livello di area geografica
  • 130.211.0.0/22
  • 35.191.0.0/16
La subnet solo proxy che hai configurato.

Architettura VPC condivisa

Il bilanciamento del carico HTTP(S) supporta le reti che utilizzano la rete VPC condivisa. Una rete VPC condivisa consente alle organizzazioni di connettere risorse di più progetti a una rete VPC comune così che possano comunicare tra loro in modo sicuro ed efficiente utilizzando IP interni di quella rete. Se non hai ancora dimestichezza con il VPC condiviso, leggi la documentazione di riepilogo sul VPC condiviso.

Esistono diversi modi per configurare il bilanciamento del carico HTTP(S) esterno in 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 HTTP(S) esterno globale,
Bilanciatore del carico HTTP(S) esterno globale (classico)
L'indirizzo IP esterno globale, la regola di forwarding, il proxy HTTP(S) di destinazione e la mappa URL associata devono essere definiti nello stesso progetto di servizio dei backend. Un servizio di backend globale deve essere definito nello stesso progetto di servizio dei backend (gruppi di istanze o NEG). I controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto anche nel servizio di backend.
Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Crea la rete e la subnet solo proxy richieste nel progetto host del VPC condiviso.

L'indirizzo IP esterno a livello di area geografica, 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 o NEG) nello stesso progetto di servizio dei componenti frontend.

  • Crea servizi e backend (gruppi di istanze o NEG) di backend nel numero di progetti di servizio necessario. Una singola mappa URL può fare riferimento ai servizi di backend in diversi progetti. Questo tipo di deployment è noto come riferimento multiservizio.
  • 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 anche nel servizio di backend.

Anche se puoi creare tutti i componenti e i backend di bilanciamento del carico nel progetto host del VPC condiviso, questo modello non separa le responsabilità di amministrazione di rete e di sviluppo del servizio.

Backend serverless in un ambiente VPC condiviso

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

Inoltre, per il bilanciatore del carico HTTP(S) esterno a livello di area geografica che supporta il riferimento a servizi tra progetti, il servizio di backend, il NEG serverless e il servizio Cloud Run devono essere sempre nello stesso progetto di servizio.

Riferimenti a servizi tra progetti

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

Il riferimento di servizi tra progetti consente alle organizzazioni di configurare un bilanciatore del carico centrale e indirizzare il traffico a centinaia di servizi distribuiti in più progetti diversi. Puoi gestire centralmente tutte le regole di routing del traffico e i criteri 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 eseguire il deployment dell'applicazione e ridurre i requisiti di gestibilità, costi operativi e quota.

Avendo diversi progetti per ciascuno dei tuoi team funzionali, puoi anche ottenere una separazione dei ruoli all'interno della tua organizzazione. I proprietari di 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 ed entrambi possono essere connessi utilizzando il riferimento di servizi tra progetti.

I proprietari dei servizi possono mantenere l'autonomia nell'esposizione dei loro servizi e controllare quali utenti possono accedere ai loro servizi tramite il bilanciatore del carico. Si ottiene da un ruolo IAM speciale, chiamato ruolo IAM Utente del servizio bilanciatore del carico.

Per saperne di più su come configurare un VPC condiviso per un bilanciatore del carico HTTP(S) esterno a livello di area geografica, (con e senza riferimento a servizi multiprogetto, vedi Configurare un bilanciatore del carico HTTP(S) esterno a livello di area geografica con VPC condiviso.

Il riferimento ai servizi tra progetti non è supportato per il bilanciatore del carico HTTP(S) esterno globale e il bilanciatore del carico HTTP(S) esterno globale (classico).

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

Di seguito è riportato un esempio di deployment in cui vengono creati il frontend e la mappa URL del bilanciatore del carico nel progetto di servizio A, mentre 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 richiederanno l'accesso ai servizi di backend nel progetto di servizio B. Gli amministratori del progetto di servizio B assegnano 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 mappa URL del bilanciatore del carico nel progetto del servizio
frontend e backend del bilanciatore del carico in diversi progetti di servizio

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 e i servizi di backend (e i backend) vengono creati nei progetti di servizio.

In questo caso, gli amministratori di rete o del bilanciatore del carico nel progetto host richiederanno l'accesso ai servizi di backend nel progetto di servizio. Gli amministratori dei progetti 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 e mappa URL del bilanciatore del carico nel progetto host
Carico di front-end e mappa URL del bilanciatore del carico nel progetto host

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

In questo modello, tutti i componenti e i backend del bilanciatore del carico si trovano in un progetto di servizio. Questo modello di deployment è supportato da tutti i bilanciatori del carico HTTP(S).

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

Bilanciatore del carico HTTP(S) a livello di regione sulla rete VPC condiviso
Bilanciatore del carico HTTP(S) a livello di regione sulla rete VPC condiviso

Come funzionano le connessioni nel bilanciamento del carico HTTP(S)

Connessioni del bilanciatore del carico HTTP(S) esterno globale

I bilanciatori del carico HTTP(S) esterni globali sono implementati da molti proxy chiamati Google Front End (GFE). Non esiste un unico proxy. Nel livello Premium, lo stesso indirizzo IP esterno globale è pubblicizzato da diversi punti di presenza e le richieste dei client sono indirizzate al GFE più vicino del client.

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

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.

Keepalive HTTP è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. I keepalive HTTP tentano di utilizzare in modo efficiente la stessa sessione TCP; tuttavia, non c'è garanzia. Il GFE utilizza un timeout keepalive di 600 secondi e non puoi configurarlo. Tuttavia, puoi configurare il timeout della richiesta/risposta impostando il timeout del servizio di backend. Sebbene siano strettamente correlati, un keepalive HTTP e un timeout per inattività TCP non sono la stessa cosa. Per ulteriori informazioni, consulta la pagina relativa a timeout e nuovi tentativi.

Il numero di connessioni HTTP e sessioni TCP dipende dal numero di connessioni GFE, dal numero di client che si connettono ai GFE, dal protocollo ai backend e da dove viene eseguito il deployment dei backend.

Per ulteriori informazioni, consulta la sezione relativa al funzionamento del bilanciamento del carico HTTP(S) nella guida alle soluzioni: ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale.

Connessioni del bilanciatore del carico HTTP(S) esterno a livello di regione

Il bilanciatore del carico HTTP(S) esterno a livello di area geografica è un servizio gestito implementato sul proxy Envoy. Il bilanciatore del carico HTTP(S) esterno a livello di area geografica utilizza una subnet condivisa denominata subnet solo proxy per eseguire il provisioning di un set di indirizzi IP utilizzati da Google per eseguire i proxy Envoy per tuo conto. Il flag --purpose per questa subnet solo proxy è impostato su REGIONAL_MANAGED_PROXY. Tutti i bilanciatori del carico basati su Envoy a livello di area geografica in una particolare rete e area geografica 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 area geografica del client. Il bilanciatore del carico termina le richieste dei client e 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 la connessione ai tuoi backend può essere HTTP, HTTPS o HTTP/2. Se HTTP o HTTPS, la versione HTTP è HTTP 1.1. Keepalive HTTP è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. Il proxy Envoy utilizza un timeout di keepalive di 600 secondi che non puoi configurare. Tuttavia, puoi configurare il timeout della richiesta o della risposta impostando il timeout del servizio di backend. Per ulteriori informazioni, vedi timeout e nuovi tentativi.

Comunicazioni del client con il bilanciatore del carico

  • I client possono comunicare con il bilanciatore del carico utilizzando il protocollo HTTP 1.1 o HTTP/2.
  • Quando si utilizza HTTPS, i client moderni hanno come valore predefinito HTTP/2. Questa proprietà è 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 in modo che utilizzino HTTP 1.1 anziché HTTP/2. Ad esempio, con curl, utilizza il parametro --http1.1.
  • Il bilanciamento del carico HTTP(S) supporta la risposta HTTP/1.1 100 Continue.

Per l'elenco completo dei protocolli supportati dalle regole di forwarding di bilanciamento del carico HTTP(S) in ogni modalità, consulta le funzionalità del bilanciatore del carico.

Indirizzi IP di origine per i pacchetti client

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

Per i bilanciatori del carico HTTP(S) 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 NAT o un proxy di inoltro).
    • Indirizzo IP di destinazione: l'indirizzo IP del bilanciatore del carico.
  • Connessione 2, dal bilanciatore del carico (GFE) alla VM o all'endpoint 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.

Per i bilanciatori del carico HTTP(S) esterni a livello di regione:

  • 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 NAT o 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 area geografica 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 HTTP(S) esterni globali, Google Cloud utilizza route speciali non definite nella rete VPC per i controlli di integrità. Per ulteriori informazioni, consulta Percorsi di ritorno del bilanciatore del carico.

Per i bilanciatori del carico HTTP(S) esterni a livello di area geografica, Google Cloud utilizza i proxy Envoy open source per terminare le richieste del 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 nella rete VPC facilitano la comunicazione dai proxy Envoy ai backend e dai backend ai proxy Envoy.

Porte aperte

Questa sezione si applica solo ai bilanciatori del carico HTTP(S) esterni globali che vengono implementati utilizzando i GFE.

I GFE hanno diverse porte aperte per supportare altri servizi Google eseguiti sulla stessa architettura. Per visualizzare un elenco di alcune delle porte che probabilmente saranno aperte sui GFE, consulta la sezione Regola di forwarding: specifiche delle porte. Potrebbero essere presenti altre porte aperte per altri servizi Google in esecuzione sui GFE.

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

  • Una scansione delle porte (ad esempio con nmap) in genere non richiede alcun pacchetto di risposta o un pacchetto TCP RST durante l'esecuzione del probe SYN TCP. I GFE inviano pacchetti SYN-ACK in risposta ai probe SYN solo per le porte per le quali hai configurato una regola di forwarding e sulle porte 80 e 443 se il bilanciatore del carico utilizza un indirizzo IP del livello Premium. I GFE inviano i pacchetti ai tuoi backend 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 indirizzi IP diversi del bilanciatore del carico o l'indirizzo IP del bilanciatore del carico su una porta non configurata nella regola di forwarding non comportano l'invio dei pacchetti ai backend del bilanciatore del carico. I GFE implementano funzionalità di sicurezza come Google Cloud Armor. Anche senza una configurazione di Google Cloud Armor, l'infrastruttura e i GFE di Google forniscono una difesa in profondità per gli attacchi DDoS e le inondazioni SYN.

  • I pacchetti inviati all'indirizzo IP del bilanciatore del carico potrebbero ricevere risposta da qualsiasi GFE nel parco risorse Google, tuttavia, la scansione di una combinazione di indirizzo IP e porta di destinazione del 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, la scansione dell'indirizzo IP di un bilanciatore del carico basato su GFE non esegue la scansione di tutti i GFE nel parco risorse Google.

Alla luce di ciò, ecco alcuni modi più efficaci per controllare la sicurezza delle tue istanze di backend:

  • Un revisore della sicurezza dovrebbe controllare la configurazione delle regole di forwarding per 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 a una sola porta TCP di destinazione. Per un bilanciatore del carico che utilizza la porta TCP 443, la porta UDP 443 viene utilizzata quando la connessione viene aggiornata a QUIC (HTTP/3).

  • Un revisore della sicurezza dovrebbe controllare la configurazione della regola firewall applicabile alle VM di backend. Le regole firewall che hai impostato 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 sulle regole firewall.

terminazione TLS

La tabella seguente riepiloga il modo in cui la terminazione TLS viene gestita dai bilanciatori del carico HTTP(S) esterni in ogni modalità.

Modalità bilanciatore del carico terminazione TLS
Bilanciatore del carico HTTP(S) esterno globale TLS viene terminato su un GFE, che può essere ovunque nel mondo.
Bilanciatore del carico HTTP(S) esterno globale (versione classica) TLS viene terminato su un GFE, che potrebbe essere ovunque nel mondo.
Bilanciatore del carico HTTP(S) esterno a livello di area geografica 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

Il bilanciamento del carico HTTP(S) esterno ha due tipi distinti di timeout:
  • Un timeout del servizio di backend HTTP configurabile, che rappresenta il periodo di tempo in cui il bilanciatore del carico attende che il backend restituisca una risposta HTTP completa. Il valore predefinito per il timeout del servizio di backend è 30 secondi. L'intervallo completo dei valori di timeout consentito è compreso tra 1 e 2.147.483.647 secondi.

    Ad esempio, se vuoi scaricare un file da 500 MB e il valore del timeout del servizio di backend è il valore predefinito di 30 secondi, il bilanciatore del carico prevede che il backend fornisca l'intero file da 500 MB entro 30 secondi. È possibile configurare il timeout del servizio di backend in modo che non sia abbastanza lungo da inviare la risposta HTTP completa al backend. In questa situazione, se il bilanciatore del carico ha almeno ricevuto le intestazioni delle risposte HTTP, il bilanciatore del carico restituisce le intestazioni complete della risposta e tutto il corpo della risposta che potrebbe ottenere entro il timeout del servizio di backend.

    Il timeout del servizio di backend deve essere impostato sul tempo massimo possibile dal primo byte della richiesta all'ultimo byte della risposta, per l'interazione tra il proxy (GFE o Envoy gestito) e il backend. Se utilizzi WebSocket, il timeout del servizio di backend deve essere impostato sulla durata massima di un WebSocket, inattivo o attivo.

    Ti consigliamo di aumentare il timeout in una delle seguenti circostanze:

    • Prevedi che un backend impiegherà più tempo per restituire le risposte HTTP.
    • Vedrai una risposta HTTP 408 con jsonPayload.statusDetail client_timed_out.
    • La connessione viene aggiornata a un WebSocket.

    Il timeout del servizio di backend impostato è l'obiettivo migliore. Non garantisce che le connessioni TCP sottostanti rimangano aperte per la durata del timeout in questione.

    Puoi impostare il timeout del servizio di backend sul valore che preferisci; tuttavia, impostarlo su un valore superiore a un giorno (86.400 secondi) non significa che il bilanciatore del carico manterrà una connessione TCP in esecuzione per questo periodo. Google riavvia periodicamente le attività software di GFE e Envoy per gli aggiornamenti software e la manutenzione di routine e il timeout del servizio di backend non lo sostituisce. Più lungo è il timeout del servizio di backend, più è probabile che Google interromperà una connessione TCP per manutenzione. Ti consigliamo di implementare la logica dei nuovi tentativi per ridurre l'impatto di tali eventi.

    Il timeout del servizio di backend non è un timeout HTTP idle (keepalive). È possibile che l'input e l'output (IO) dal backend siano bloccati a causa di un client lento (ad esempio, un browser con connessione lenta). Questo tempo di attesa non viene conteggiato rispetto al timeout del servizio di backend.

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

    • Google Cloud Console: modifica il campo Timeout del servizio di backend del bilanciatore del carico.
    • Google Cloud CLI: usa il comando gcloud compute backend-services update per modificare il parametro --timeout della risorsa del servizio di backend.
    • API: modifica il parametro timeoutSec per la risorsa di servizio di backend global o regional.

    Per i bilanciatori del carico HTTP(S) esterni a livello di area geografica, il parametro routeActions.timeout della mappa URL può sostituire il timeout del servizio di backend. Il timeout del servizio di backend viene utilizzato come valore predefinito per routeActions.timeout.

  • Un timeout keepalive HTTP il cui valore è fisso su 10 minuti (600 secondi). Questo valore non è configurabile modificando il servizio di backend. Devi configurare il software server web utilizzato dai backend in modo che il relativo timeout keepalive sia superiore a 600 secondi per evitare che le connessioni vengano chiuse prematuramente dal backend. Questo timeout non si applica ai WebSocket. Questa tabella illustra le modifiche necessarie per modificare i timeout keepalive per il software comune del server web:
    Software server web Parametro Impostazione predefinita Impostazione consigliata
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75 secondi; keepalive_timeout 620s;

Nuovi tentativi

Il supporto del bilanciamento del carico HTTP(S) per la logica dei nuovi tentativi dipende dalla modalità del bilanciatore del carico HTTP(S) esterno.

Modalità bilanciatore del carico Riprova la logica
Bilanciatore del carico HTTP(S) esterno globale

Configurabile tramite un criterio di nuovo tentativo nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1; il numero massimo di nuovi tentativi configurabili con il criterio di ripetizione è 25. Il timeout predefinito per ogni tentativo (perTryTimeout) è di 30 secondi con un massimo perTryTimeout configurabile di 24 ore.

Senza un criterio di ripetizione, le richieste non riuscite senza corpo HTTP (ad esempio, richieste GET) che generano HTTP 502, 503 o risposte 504 (retryConditions=["gateway-error"]) vengono tentate di nuovo. Non viene eseguito un nuovo tentativo per le richieste POST HTTP.

Le richieste testate generano solo una voce di log per la risposta finale.

Bilanciatore del carico HTTP(S) esterno globale (versione classica)

Impossibile modificare il criterio di ripetizione per i nuovi tentativi di connessione.

Non viene eseguito un nuovo tentativo per le richieste HTTP POST.

Per le richieste GET HTTP viene sempre eseguito un nuovo tentativo solo se l'80% o più dei backend è in stato integro. Se esiste una singola istanza di backend in un gruppo e la connessione a tale istanza non riesce, la percentuale di istanze di backend in stato non integro è del 100%, quindi il GFE non ritenta la richiesta.

In determinate circostanze, il bilanciatore del carico ritenta le richieste GET non riuscite, ad esempio quando il timeout del servizio di backend è esaurito. I nuovi tentativi di richiesta sono limitati a 25 tentativi. Le richieste testate generano solo una voce di log per la risposta finale. Per ulteriori informazioni, consulta Logging e monitoraggio del bilanciamento del carico HTTP(S).

Se le richieste non hanno esito positivo, il bilanciatore del carico sintetizza una risposta HTTP 502.

Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Configurabile tramite un criterio di ripetizione nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1; il numero massimo di nuovi tentativi configurabili con il criterio di nuovo tentativo è 25. Il timeout predefinito per ogni tentativo (perTryTimeout) è di 30 secondi con un massimo perTryTimeout configurabile di 24 ore.

Senza un criterio di ripetizione, le richieste non riuscite senza corpo HTTP (ad esempio, richieste GET) che generano HTTP 502, 503 o risposte 504 (retryConditions=["gateway-error"]) vengono tentate di nuovo. Non viene eseguito un nuovo tentativo per le richieste POST HTTP.

Le richieste testate 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 sia alle richieste client sia alle risposte backend di raggiungere, rispettivamente, il backend o il client per una serie di motivi. Alcuni motivi sono strettamente indicati per la conformità HTTP/1.1, mentre altri devono evitare il trasferimento di dati imprevisti da o verso i backend. Nessuno dei controlli può essere disattivato.

Il bilanciatore del carico blocca quanto segue per la conformità HTTP/1.1:

  • Non può analizzare la prima riga della richiesta.
  • Nell'intestazione manca il delimitatore :.
  • Le intestazioni o la prima riga contengono caratteri non validi.
  • La lunghezza dei contenuti non è un numero valido oppure esistono più intestazioni di lunghezza dei contenuti.
  • Ci sono più chiavi di codifica di trasferimento oppure sono presenti valori di codifica di trasferimento non riconosciuti.
  • Il corpo non è suddiviso in blocchi e non viene specificata alcuna lunghezza dei contenuti.
  • Pezzi 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.

Il bilanciatore del carico blocca la richiesta se si verifica una delle seguenti condizioni:

Il bilanciatore del carico blocca la risposta del backend se si verifica una delle seguenti condizioni:

  • La dimensione totale delle intestazioni della risposta supera il limite massimo per la dimensione massima dell'intestazione della risposta per il bilanciamento del carico HTTP(S) esterno.
  • La versione HTTP è sconosciuta.

Distribuzione del traffico

Quando aggiungi un gruppo di istanze o un NEG di backend a un servizio di backend, devi specificare una modalità di bilanciamento, che definisce un metodo per misurare il carico del backend e una capacità di destinazione. Il bilanciamento del carico HTTP(S) esterno supporta due modalità di bilanciamento:

  • RATE, per gruppi di istanze o NEG, è il numero massimo target di richieste (query) al secondo (RPS, QPS). Il valore RPS/QPS massimo target può essere superato se tutti i backend raggiungono o superano la capacità.

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

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

Bilanciatore del carico HTTP(S) esterno globale

Prima che un Google Front End (GFE) invii richieste alle istanze di backend, il GFE stima quali istanze di backend hanno la capacità di ricevere richieste. La stima della capacità viene effettuata in modo proattivo, non in corrispondenza delle richieste in arrivo. I GFE ricevono periodicamente informazioni 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 una stima del carico di query che ogni istanza può gestire. La stima cambia nel tempo man mano che cambiano l'utilizzo delle istanze e i modelli di traffico.

Entrambi i fattori (la stima della capacità e l'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 di ottimizzare la selezione delle istanze di backend per ogni richiesta.

Per il bilanciatore del carico HTTP(S) esterno globale (classico), la modalità di bilanciamento viene utilizzata per selezionare il backend (gruppo di istanze o NEG) più vantaggioso. Il traffico viene quindi distribuito in modo round robin tra istanze o endpoint all'interno del backend.

Per il bilanciatore del carico HTTP(S) esterno globale, il bilanciamento del carico è a due livelli. La modalità di bilanciamento determina la ponderazione o la frazione del traffico che deve essere inviato a ogni backend (gruppo di istanze o NEG). Il criterio di bilanciamento del carico (LocalityLbPolicy) determina quindi la distribuzione del traffico in istanze o endpoint all'interno del gruppo. Per ulteriori informazioni, consulta il criterio della località di bilanciamento del carico (documentazione dell'API del servizio di backend).

Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Per i bilanciatori del carico HTTP(S) esterni a livello di area geografica, la distribuzione del traffico si basa sulla modalità di bilanciamento del carico e sul criterio della località di bilanciamento del carico.

La modalità di bilanciamento determina la ponderazione e la frazione del traffico che deve essere inviato a ogni gruppo (gruppo di istanze o NEG). Il criterio della località di bilanciamento del carico (LocalityLbPolicy) determina il bilanciamento del carico dei backend all'interno del gruppo.

Quando un servizio di backend riceve il traffico, lo indirizza innanzitutto a un backend (gruppo di istanze o NEG) in base alla modalità di bilanciamento del backend. Dopo la selezione di un backend, il traffico viene quindi distribuito tra le istanze o gli endpoint in quel gruppo di backend in base ai criteri della località di bilanciamento del carico.

Per ulteriori informazioni, consulta quanto segue:

Come vengono distribuite le richieste

La distribuzione del traffico a livello di area geografica o globale dipende dalla modalità del bilanciatore del carico e dal livello di servizio di rete in uso.

Per il livello Premium:

  • Google pubblicizza l'indirizzo IP del tuo bilanciatore del carico da tutti i punti di presenza in tutto il mondo. Ogni indirizzo IP del bilanciatore del carico è anycast globale.
  • Se configuri un servizio di backend con backend in più regioni, i Google Front End (GFE) tentano di indirizzare le richieste ai gruppi di istanze o ai NEG di integrità nell'area geografica più vicina all'utente. I dettagli del processo sono documentati in questa pagina.

Per il livello Standard:

  • Google pubblicizza l'indirizzo IP del tuo bilanciatore del carico dai punti di presenza associati all'area geografica della regola di forwarding. Il bilanciatore del carico utilizza un indirizzo IP esterno a livello di regione.

  • Puoi configurare i backend nella stessa area geografica della regola di forwarding. Il processo qui documentato continua a essere applicato, ma il bilanciatore del carico indirizza solo le richieste a backend integri in quella regione.

Procedura di distribuzione delle richieste:

La modalità di bilanciamento e la scelta del target definiscono la completazza del backend dal punto di vista di ogni NEG di zona GCE_VM_IP_PORT, gruppo di istanze a livello di zona o zona di un gruppo di istanze a livello di regione. La distribuzione all'interno di una zona viene eseguita con hashing coerente per il bilanciatore del carico HTTP(S) esterno globale (classico) ed è configurabile tramite il criterio di località del bilanciamento del carico per il bilanciatore del carico HTTP(S) esterno globale e il bilanciatore del carico HTTP(S) esterno a livello di regione.

I bilanciatori del carico HTTP(S) esterno basato su GFE utilizzano la seguente procedura per distribuire le richieste in arrivo:

  1. L'indirizzo IP esterno della regola di forwarding è pubblicizzato dai router perimetrali ai confini della rete Google. Ogni annuncio elenca un hop successivo a un sistema di bilanciamento del carico di livello 3/4 (Maglev).
  2. I sistemi di Maglev indirizzano il traffico a un Google Front End (GFE) di primo livello. Il GFE di primo livello termina TLS se necessario, quindi instrada il traffico ai GFE di secondo livello in base a questo processo:
    1. La mappa URL seleziona un servizio di backend.
    2. Se un servizio di backend utilizza backend GCE_VM_IP_PORT di gruppo o di istanza NEG, i primi GFE di livello preferiti preferiscono i GFE di secondo livello che si trovano all'interno o vicino all'area geografica che contiene il gruppo di istanze o il NEG.
    3. Per i bucket di backend e i servizi di backend con NEG ibridi, NEG serverless e NEG Internet, i GFE di primo livello scelgono i GFE di secondo livello in un sottoinsieme di regioni in modo che il tempo di round trip tra i due GFE sia ridotto al minimo.

      La preferenza GFE al secondo livello non è una garanzia e può variare dinamicamente in base alle condizioni e alla manutenzione della rete Google.

      I GFE di secondo livello sono a conoscenza dello stato del controllo di integrità e dell'utilizzo effettivo della capacità di backend.

  3. Il GFE di secondo livello indirizza le richieste ai backend nelle zone che si trovano all'interno della regione.
  4. Per il livello Premium, a volte i GFE di secondo livello inviano richieste ai backend in zone di aree geografiche diverse. Questo comportamento è chiamato sversamento.
  5. La fuoriuscita è regolata da due principi:

    • Lo sversamento è possibile quando tutti i backend noti a un GFE di secondo livello sono al completo o non sono in stato integro.
    • Il GFE di secondo livello contiene informazioni per i backend in stato integro e disponibili nelle zone di un'area geografica diversa.

    In genere, i GFE di secondo livello sono configurati per gestire un sottoinsieme di località di backend.

    Il comportamento di overflow non esaurisce tutte le possibili zone di Google Cloud. Se devi indirizzare il traffico dai backend in una zona specifica o in un'intera area geografica, devi impostare il gestore della scalabilità della capacità su zero. La configurazione dei backend per non superare i controlli di integrità non garantisce che il GFE di secondo livello si sovrapponga a backend in zone di un'area geografica diversa.

  6. Durante la distribuzione delle richieste ai backend, i GFE operano a livello di zona.

    Con un numero ridotto di richieste al secondo, i GFE di secondo livello a volte preferiscono una zona di un'area geografica rispetto alle altre. Questa preferenza è normale e prevista. La distribuzione tra le zone nell'area geografica non diventa fino a quando il bilanciatore del carico non riceve più richieste al secondo.

Affinità sessione

Affinità sessione offre il miglior tentativo di inviare richieste da un determinato client allo stesso backend purché il backend sia integro e abbia la capacità massima, 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).

Il bilanciamento del carico HTTP(S) offre i seguenti tipi di affinità sessione:

La tabella seguente riepiloga le opzioni di affinità sessione supportate per ogni modalità di bilanciamento del carico HTTP(S):

Modalità bilanciatore del carico Opzioni di affinità sessione
  Nessuna IP client Cookie generato Campo intestazione Cookie HTTP
Bilanciatore del carico HTTP(S) esterno globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica)
Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Supporto HTTP/2

Stream simultanei HTTP/2 max

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 in un bilanciatore del carico Google Cloud non ha alcun senso perché il bilanciatore del carico non avvia i flussi sul 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 le richieste al server e potrebbero verificarsi errori.

Limitazioni HTTP/2

  • HTTP/2 tra il bilanciatore del carico e l'istanza può richiedere molte più connessioni TCP all'istanza rispetto a HTTP(S). Il pool di connessioni, un'ottimizzazione che riduce il numero di queste connessioni con HTTP(S), non è attualmente disponibile con HTTP/2. Di conseguenza, potresti notare un'elevata latenza del backend 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 delle 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 per QUIC HTTP/3 e Google

HTTP/3 è un protocollo Internet di nuova generazione. Si basa su QUIC IETF, un protocollo sviluppato dal protocollo Google QUIC originale. HTTP/3 è supportato tra il bilanciatore del carico HTTP(S) esterno, Cloud CDN e client.

In particolare:

  • IETF QUIC è un protocollo del livello di trasporto che fornisce un controllo della congestione simile a TCP ed è l'equivalente della sicurezza di SSL/TLS per HTTP/2, con prestazioni migliori.
  • HTTP/3 è un livello di applicazione basato su QUIC IETF e si basa su QUIC per gestire il multiplexing, il controllo della congestione, il rilevamento della perdita e la ritrasmissione.
  • HTTP/3 consente un'avvio più rapido della connessione client, elimina il blocco front-line degli stream multiplex e supporta la migrazione della connessione quando l'indirizzo IP di un client cambia.
  • HTTP/3 influisce sulle connessioni tra i client e il bilanciatore del carico, non sulle connessioni tra il bilanciatore del carico e i relativi backend.
  • Le connessioni HTTP/3 utilizzano l'algoritmo di controllo della congestione BBR.

L'abilitazione di HTTP/3 sul bilanciatore del carico può migliorare i tempi di caricamento delle pagine web, ridurre il buffering del video e migliorare la velocità effettiva su connessioni a latenza più elevata.

La tabella seguente specifica il supporto HTTP/3 per il bilanciamento del carico HTTP(S) in ogni modalità.

Modalità bilanciatore del carico Supporto HTTP/3
Bilanciatore del carico HTTP(S) esterno globale
Bilanciatore del carico HTTP(S) esterno globale (versione classica)
Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Modalità di negoziazione di HTTP/3

Quando HTTP/3 è abilitato, il bilanciatore del carico pubblicizza questo supporto per i 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 utilizzano sempre HTTPS o HTTP/2 quando non riescono a stabilire una connessione HTTP/3.
  • I client che supportano HTTP/3 utilizzano la loro precedente conoscenza memorizzata nella cache del supporto HTTP/3 per salvare viaggi di andata e ritorno non necessari in futuro.
  • A causa di questo fallback, l'abilitazione o la disattivazione di HTTP/3 nel bilanciatore del carico non interrompe la capacità del bilanciatore del carico di connettersi ai client.

Il supporto è pubblicizzato nell'intestazione della risposta HTTP Alt-Svc. Quando HTTP/3 è configurato come ENABLE nella risorsa targetHttpsProxy di un bilanciatore del carico HTTP(S) esterno, 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,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

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

Se HTTP/3 è abilitato sul bilanciatore del carico HTTPS, in alcune circostanze il client potrebbe utilizzare HTTPS o HTTP/2 anziché negoziare HTTP/3. tra cui:

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

Quando una connessione torna a HTTPS o HTTP/2, non viene considerata come un errore del bilanciatore del carico.

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

Configura HTTP/3

Puoi abilitare esplicitamente il supporto HTTP/3 per il bilanciatore del carico impostando quicOverride su ENABLE.

Quando attivi HTTP/3, il bilanciatore del carico lo pubblicizza ai client, in modo che possano supportare la negoziazione di una versione HTTP/3 con il bilanciatore del carico. I client che non supportano HTTP/3 non negoziano una connessione HTTP/3. Non è necessario disattivare esplicitamente HTTP/3, a meno che non siano state identificate implementazioni client non funzionanti.

Il bilanciamento del carico HTTP(S) offre tre modi per configurare HTTP/3, come mostrato nella tabella seguente.

Valore quicOverride Comportamento
NONE

Il supporto per HTTP/3 viene pubblicizzato sui client.

ENABLE

Il supporto di HTTP/3 e QUIC di Google viene pubblicizzato per i client. HTTP/3 è pubblicizzato con una priorità più elevata. I client che supportano entrambi i protocolli dovrebbero preferire HTTP/3 rispetto a QUIC Google.

Nota: TLS 0-RTT (noto anche come dati iniziali TLS) è implicitamente supportato quando il QUIC Google negozia il client, ma non è supportato quando viene utilizzato HTTP/3.

DISABLE Disabilita esplicitamente la pubblicità HTTP/3 e QUIC di Google ai client.

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

Console: HTTPS

  1. In Google Cloud Console, vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Seleziona il bilanciatore del carico che vuoi modificare.

  3. Fai clic su Configurazione frontend.

  4. Seleziona l'indirizzo IP e la porta del frontend che vuoi modificare. Per modificare le configurazioni HTTP/3, l'indirizzo IP e la porta devono essere HTTPS (porta 443).

Abilita HTTP/3

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

Disattiva HTTP/3

  1. Seleziona il menu a discesa Negoziazione QUIC.
  2. Per disattivare esplicitamente HTTP/3 per questo frontend, seleziona Disabilitato.
  3. Se hai più regole di 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 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 elementi:

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

    Attualmente, quando selezioni NONE, HTTP/3 viene pubblicizzato per i client, ma il QUIC Google non viene pubblicizzato.

    In Google Cloud Console, questa opzione è denominata Automatica (impostazione predefinita).

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

  • DISABLE: non vengono pubblicizzati HTTP/3 o QUIC di Google 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 uno dei seguenti elementi:

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

    Attualmente, quando selezioni NONE, HTTP/3 viene pubblicizzato per i client, ma il QUIC Google non viene pubblicizzato.

    In Google Cloud Console, questa opzione è denominata Automatica (impostazione predefinita).

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

  • DISABLE: non vengono pubblicizzati HTTP/3 o QUIC di Google ai client.

Limitazioni

  • I bilanciatori del carico HTTPS non supportano l'autenticazione basata su certificati client, nota anche come autenticazione TLS reciproca.
  • I bilanciatori del carico HTTPS non inviano un avviso di chiusura close_notify quando terminano le connessioni SSL. In altre parole, il bilanciatore del carico chiude la connessione TCP invece di eseguire un arresto SSL.
  • I bilanciatori del carico HTTPS supportano solo caratteri minuscoli nei domini in un attributo nome comune (CN) o in un 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 Internet NEG. Per maggiori dettagli, consulta Crittografia dal bilanciatore del carico ai backend.
  • Quando utilizzi bilanciatori del carico HTTP(S) esterni a livello di area geografica 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.
  • reCAPTCHA Enterprise per WAF con Google Cloud Armor è supportato solo con il bilanciatore del carico HTTP(S) esterno globale (classico). Non è supportato con il bilanciatore del carico HTTP(S) esterno globale con funzionalità di gestione avanzata del traffico.

Passaggi successivi