Panoramica del bilanciatore del carico delle applicazioni esterno

Questo documento introduce i concetti di base per 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 consente di eseguire e scalare i servizi dietro un unico indirizzo IP esterno. Il bilanciatore del carico delle applicazioni esterno distribuisce il traffico HTTP e HTTPS ai backend ospitati su diverse tramite le piattaforme Google Cloud (come Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage e così via), nonché le risorse esterne di backend connessi tramite internet o tramite connettività ibrida. Per maggiori dettagli, vedi Panoramica del bilanciatore del carico delle applicazioni: utilizzo di assistenza.

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 sui Google Front End (GFE). it utilizza il proxy Envoy open source per supportare il traffico avanzato come mirroring del traffico, suddivisione del traffico in base al peso trasformazioni di intestazione basate su richiesta/risposta e altro ancora.
• Bilanciatore del carico delle applicazioni classico Questo è il classico bilanciatore del carico delle applicazioni esterno globale nel livello Premium, ma può essere configurato per essere regionale nella versione Standard livello. Questo bilanciatore del carico è implementato su Google Front End (GFE). GFE sono distribuiti a livello globale e operano insieme utilizzando la rete globale di Google e piano di controllo.
• Bilanciatore del carico delle applicazioni esterno regionale. Si tratta di un bilanciatore del carico a livello di regione, implementato come servizio gestito sull'open source di Envoy proxy. Comprende traffico avanzato gestione dei dispositivi come mirroring del traffico, suddivisione del traffico in base al peso trasformazioni di intestazione basate su richiesta/risposta e altro ancora.

Modalità bilanciatore del carico	Casi d'uso consigliati	Funzionalità
Bilanciatore del carico delle applicazioni esterno globale	Utilizza questo bilanciatore del carico per i carichi di lavoro HTTP(S) esterni con di utenti o servizi di backend dislocati a livello globale in più regioni.	Compatibile con GKE utilizzando Gateway (completamente orchestrato) o Autonomi NEG (orchestrazione manuale) Supporta avanzata gestione del traffico Anycast globale indirizzi IP esterni al livello Premium Può accedere ai backend in più regioni Supporta Cloud CDN Supporta Google Cloud Armor
Bilanciatore del carico delle applicazioni classico	Questo bilanciatore del carico è globale nel livello Premium, ma può essere configurato per una regione efficace nel livello Standard. Nel servizio di rete Premium Tier, questo bilanciatore del carico offre bilanciamento del carico multiregionale, tenta di indirizzare il traffico al backend integro più vicino con capacità e termina il traffico HTTP(S) il più vicino possibili per i tuoi utenti. Per informazioni dettagliate sulla distribuzione delle richieste consulta la sezione Informazioni sul traffico la distribuzione dei contenuti. Nell'interfaccia Standard Network Livello di servizio, il bilanciamento del carico viene gestito a livello di regione.	Compatibile con GKE utilizzando Gateway (completamente orchestrato), In entrata (completamente orchestrato) o Autonomi NEG (orchestrazione manuale) Supporta Google Cloud Armor Meno funzionalità di routing del traffico Consulta la sezione Bilanciamento del carico funzionalità per l'elenco completo delle funzionalità.
Bilanciatore del carico delle applicazioni esterno regionale	Questo bilanciatore del carico contiene molte delle funzionalità un bilanciatore del carico delle applicazioni classico esistente, insieme a avanzata funzionalità di gestione del traffico. Utilizza questo bilanciatore del carico se vuoi pubblicare contenuti da una sola geolocalizzazione (ad esempio per rispettare le normative di conformità). Questo bilanciatore del carico può essere configurato in Premium o Standard livello.	Compatibile con GKE utilizzando Autonomi NEG (orchestrazione manuale) Supporta funzionalità avanzate di gestione del traffico VIP regionali che utilizzano la rete standard Livello Termina TLS in una singola regione da te configurata Pubblica contenuti solo dalla regione configurata Per l'elenco completo, consulta la sezione Caricamento di bilanciamento del carico.

Identifica la modalità

console Cloud

1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
   Vai a Bilanciamento del carico
2. Nella scheda Bilanciatori del carico, vengono indicati il tipo di bilanciatore del carico, il protocollo regione. Se la regione è vuota, il bilanciatore del carico è globale. La tabella seguente riassume come identificare la modalità di con il bilanciatore del carico di rete passthrough esterno regionale.

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

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

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

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

Architettura

Le risorse seguenti sono necessarie per un bilanciatore del carico delle applicazioni esterno deployment:

• Solo per i bilanciatori del carico delle applicazioni esterni regionali, un server solo proxy subnet viene utilizzata per inviare connessioni dal carico tramite il bilanciatore del carico e il bilanciatore del carico ai backend.

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

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

  • Per il bilanciamento del carico HTTPS, il proxy HTTPS di destinazione utilizza il protocollo SSL per dimostrare la sua identità ai clienti. R il proxy HTTPS di destinazione supporta fino allo numero di Certificati SSL.

• Il proxy HTTP(S) utilizza una mappa URL per creare un routing di determinazione in base ad attributi HTTP (come il percorso della richiesta, i cookie, o intestazioni). In base alla decisione di routing, il proxy inoltra il client a servizi di backend 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 agli utenti in stato integro backend. La 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 oppure di backend.

• Un controllo di integrità monitora periodicamente il recupero delle dai tuoi backend. In questo modo si riduce il rischio che le richieste vengano inviate ai backend che non è in grado di gestire la richiesta.

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

Globale

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

Componenti del bilanciatore del carico delle applicazioni esterno globale

Regionale

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

Componenti del bilanciatore del carico delle applicazioni esterno regionale

Subnet solo proxy

Le subnet solo proxy sono obbligatorie solo per gli Application Load Balancer esterni regionali.

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

• Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i tuoi backend.
• VM o endpoint di backend di tutti gli Application Load Balancer esterni regionali in una regione e La rete VPC riceve connessioni dalla subnet solo proxy.
• L'indirizzo IP del bilanciatore del carico delle applicazioni esterno regionale non si trova nella una subnet solo proxy. L'indirizzo IP del bilanciatore del carico viene definito dal suo esterno una regola di forwarding gestito, descritta di seguito.

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

Regole di forwarding e indirizzi IP

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

Specifica degli indirizzi IP. Ogni regola di forwarding fornisce un singolo indirizzo IP che possono essere utilizzate nei record DNS per la tua applicazione. Nessun carico basato su DNS e il bilanciamento del carico è obbligatorio. Puoi specificare l'indirizzo IP da utilizzare oppure lasciare Cloud Load Balancing ne assegna uno automaticamente.

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

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

Modalità bilanciatore del carico	Livello di servizio di rete	Regola di forwarding, indirizzo IP e bilanciamento del carico schema	Routing da internet al frontend del bilanciatore del carico
Bilanciatore del carico delle applicazioni esterno globale	Livello Premium	Regola di forwarding esterno globale Indirizzo IP esterno globale Schema di bilanciamento del carico: EXTERNAL_MANAGED	Richieste indirizzate al GFE più vicino al client su 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	Le richieste indirizzate al GFE più vicino al client sulla internet.
	Livello Standard	Regola di forwarding esterno a livello di regione Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL	Richieste instradate a un GFE nella regione del bilanciatore del carico.
Bilanciatore del carico delle applicazioni esterno regionale	Livello Premium o Standard^*	Regola di forwarding esterno a livello di regione Indirizzo IP esterno a livello di regione Schema di bilanciamento del carico: EXTERNAL_MANAGED	Richieste indirizzate ai proxy Envoy nella stessa regione del carico con il bilanciatore del carico di rete passthrough esterno regionale.

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

Per l'elenco completo dei protocolli supportati dal bilanciatore del carico delle applicazioni esterno per le regole di forwarding in ciascuna modalità, consulta Bilanciatore del carico funzionalità.

Regole di forwarding e reti VPC

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

Modalità 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 indirizzo IP, ovvero all'esterno della rete VPC. Pertanto, alla regola di forwarding non è associata una rete VPC.
Bilanciatore del carico delle applicazioni esterno regionale	La rete VPC della regola di forwarding è in cui è stata creata la subnet solo proxy. Tu specificare la rete quando crei la regola di forwarding.

Proxy di destinazione

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

Non fare affidamento sul proxy per preservare il caso dell'intestazione della richiesta o della risposta names. Ad esempio, potrebbe essere visualizzata un'intestazione di risposta Server: Apache/1.0 cliente come server: Apache/1.0.

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

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

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

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

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

• Per il bilanciatore del carico delle applicazioni esterno globale,le intestazioni della richiesta e della risposta sono vengono sempre convertiti in minuscolo. Ad esempio, Host diventa host, e Keep-ALIVE diventa keep-alive.

  L'unica eccezione è quando utilizzi backend NEG internet globali con HTTP/1.1. Per dettagli su come le intestazioni HTTP/1.1 vengono elaborate con NEG internet, consulta NEG internet Panoramica.

• Per il bilanciatore del carico delle applicazioni classico,le intestazioni delle richieste e delle risposte sono convertito in minuscolo, tranne quando si utilizza HTTP/1.1. Con HTTP/1.1, le intestazioni hanno le maiuscole corrette. La prima lettera della chiave dell'intestazione e ogni la lettera che segue un trattino (-) è in maiuscolo per preservare la compatibilità con client HTTP/1.1. Ad esempio, user-agent viene modificato in User-Agent, e content-encoding è stato modificato in Content-Encoding.

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

Intestazione host

Quando il bilanciatore del carico effettua la richiesta HTTP, conserva Intestazione host della richiesta originale.

Intestazione X-Forwarded-For

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

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

Se la richiesta in entrata non contiene un'intestazione X-Forwarded-For, questi due indirizzi IP indirizzi 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 di <client-ip>,<load-balancer-ip>:

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

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

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

• L'indirizzo IP del Google Front End (GFE) connesso al backend. Questi indirizzi IP sono compresi negli intervalli 130.211.0.0/22 e 35.191.0.0/16.

• L'indirizzo IP del sistema di backend stesso.

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

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

Mappe URL

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

Mappe URL utilizzate con i bilanciatori del carico delle applicazioni esterni globali e il bilanciatore del carico delle applicazioni esterno regionale Supportano diverse funzionalità avanzate per la gestione del traffico, come reindirizzamento del traffico, suddivisione del traffico basata sui pesi e mirroring delle richieste. Per per ulteriori informazioni, consulta le seguenti risorse:

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

La tabella seguente specifica il tipo di mappa URL richiesta dagli Application Load Balancer esterni in ciascuna modalità.

Modalità bilanciatore del carico	Tipo di mappa URL
Bilanciatore del carico delle applicazioni esterno globale	Global
Bilanciatore del carico delle applicazioni classico	Globale (solo con 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 i proxy HTTPS di destinazione richiedono chiavi private e Certificati SSL che fanno parte della configurazione del bilanciatore del carico:

• Google Cloud fornisce due metodi di configurazione per l'assegnazione chiavi e certificati SSL per scegliere come target i proxy HTTPS: SSL di Compute Engine certificati e Gestore certificati. Per una descrizione di ogni vedi Configurazione dei certificati del linguaggio naturale panoramica dei certificati.

• Google Cloud offre due tipi di certificati: autogestito e Gestita da Google. Per una descrizione di ogni tipo, vedi Certificato standard nel protocollo panoramica dei certificati.

• Il tipo di bilanciatore del carico delle applicazioni esterno (globale, regionale o classico) determina quale di configurazione e tipi di certificati sono supportati. Per maggiori dettagli, vedi Certificati e Carico Google Cloud bilanciatori del carico Panoramica dei certificati SSL.

Mutual TLS

Generalmente, con la comunicazione HTTPS, l'autenticazione funziona solo in un modo: verifica l'identità del server. Per le applicazioni che richiedono bilanciatore del carico per autenticare l'identità dei client che si connettono, sia Il bilanciatore del carico delle applicazioni esterno globale e un bilanciatore del carico delle applicazioni classico supportano TLS (mTLS reciproco).

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

Google Cloud utilizza la risorsa TrustConfig in Gestore certificati per archiviare i certificati che il server utilizza per e verificare il certificato presentato dal client. Se utilizzi un Bilanciatore del carico delle applicazioni classico su Premium Network Service da un livello o da un bilanciatore del carico delle applicazioni esterno globale, puoi utilizzare Gestore certificati per il provisioning e la gestione dei certificati SSL o TrustConfig in più istanze del bilanciatore del carico in su larga scala. Per ulteriori informazioni, vedi Gestore certificati Panoramica.

Per ulteriori informazioni su mTLS, consulta TLS reciproco autenticazione.

Criteri SSL

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

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

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

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

Servizi e bucket di backend

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. Carica usano le informazioni contenute in un servizio di backend per indirizzare il traffico in entrata uno o più backend collegati. Ad esempio, in cui viene mostrato come impostare un carico con un servizio di backend e un backend di Compute Engine, consulta Configurazione un bilanciatore del carico delle applicazioni esterno con Compute Engine di backend.

I bucket di backend indirizzano il traffico in entrata a Cloud Storage bucket. Per un esempio che mostra come aggiungere di un bucket a un bilanciatore del carico delle applicazioni esterno, consulta Configurazione di un bilanciatore del carico con bucket di backend.

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

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

^* Utilizza endpoint di tipo GCE_VM_IP_PORT con GKE: Usa NEG autonomi a livello di zona oppure utilizza Ingress

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

^‡ Solo supportati con il controller gateway GKE

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

Per ulteriori informazioni, consulta le seguenti risorse:

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

Backend e reti VPC

Le restrizioni sulla posizione dei backend dipendono dal tipo con il bilanciatore del carico di rete passthrough esterno regionale.

Nota: questa sezione descrive l'associazione di rete VPC per in cui il servizio di backend e i backend del bilanciatore del carico si trovano lo stesso progetto della regola di forwarding. Se vuoi che il servizio di backend sia in un progetto diverso dalla regola di forwarding, devi configurare bilanciatore del carico in un ambiente VPC condiviso con servizio tra progetti come riferimento.

Le restrizioni sulla posizione dei backend dipendono dal tipo con il bilanciatore del carico di rete passthrough esterno regionale.

Per il bilanciatore del carico delle applicazioni esterno globale e per il bilanciatore del carico delle applicazioni classico, tutti i backend istanze da backend di gruppi di istanze e tutti gli endpoint di backend dal NEG devono trovarsi nello stesso progetto. Tuttavia, un gruppo di istanze un backend o un NEG può utilizzare una rete VPC diversa progetto. Non è necessario che le diverse reti VPC connesse tramite peering di rete VPC perché i GFE comunicano direttamente con backend nelle rispettive reti VPC.

Per il bilanciatore del carico delle applicazioni esterno regionale, questo dipende dal tipo di backend.

• Ad esempio gruppi di istanze, NEG a livello di zona e NEG di connettività ibrida, tutti i backend deve 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 un'interfaccia rete VPC nello stesso progetto del servizio di backend. Connettività tra i bilanciatori del carico rete VPC e rete VPC di backend può essere configurato utilizzando il peering di rete VPC, tunnel, collegamenti VLAN di Cloud Interconnect o un Network Connectivity Center il modello di machine learning.

  Definizione della rete di backend

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

  Requisiti di rete di backend

  La rete del backend deve soddisfare una delle seguenti reti requisiti:

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

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

  • Sia la rete VPC del backend che la rete VPC della regola di forwarding, La rete VPC deve essere VPC spoke sullo stesso Network Connectivity Center . I filtri di importazione ed esportazione devono consentire la comunicazione solo tra proxy nella rete VPC della regola di forwarding e nelle subnet utilizzate dalle istanze di backend o dagli endpoint.

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

Backend e interfacce di rete

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

Se utilizzi backend NEG a livello di zona, i pacchetti vengono inviati a qualsiasi interfaccia di rete rappresentato dall'endpoint nel NEG. Gli endpoint NEG devono essere nello stesso rete VPC come VPC definito esplicitamente dal NEG in ogni rete.

Protocollo ai backend

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

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

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

Supporto di WebSocket

I bilanciatori del carico Google Cloud 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 di WebSocket e altre connessioni.

Il protocollo websocket fornisce un canale di comunicazione full-duplex tra e il bilanciatore del carico. Per Per ulteriori informazioni, consulta RFC 6455.

Il protocollo WebSocket funziona nel seguente modo:

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

Se l'istanza di backend restituisce una risposta di errore con codice di risposta 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 Servizio di backend timeout.

L'affinità sessione per WebSocket funziona come per qualsiasi altra richiesta. Per ulteriori informazioni, consulta la sezione Sessione di affinità.

Utilizzo di gRPC con le applicazioni Google Cloud

gRPC è un framework open source per le chiamate di procedura remota. Si basa sullo standard HTTP/2. Casi d'uso di gRPC include quanto segue:

• Sistemi distribuiti a bassa latenza, a elevata scalabilità
• Sviluppo di client mobili che comunicano con un server cloud
• Progettare nuovi protocolli che devono essere accurati, efficienti e indipendente dalla lingua
• Design a più livelli per abilitare estensioni, autenticazione e logging

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

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

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

Il bilanciatore del carico potrebbe comunque negoziare HTTPS con alcuni client o accettare contenuti non sicuri Richieste HTTP su un bilanciatore del carico configurato per utilizzare HTTP/2 tra il bilanciatore del carico e le istanze di backend. Gli indirizzi HTTP o HTTPS vengono trasformate dal bilanciatore del carico per eseguirne il proxy su HTTP/2 alle istanze di backend.

Devi abilitare TLS sui tuoi backend. Per ulteriori informazioni, consulta l'articolo Crittografia da dal bilanciatore del carico ai backend.

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

Per informazioni sulla risoluzione dei problemi con HTTP/2, consulta la sezione Risoluzione dei problemi. problemi con HTTP/2 ai backend.

Per informazioni sulle limitazioni del protocollo HTTP/2, consulta l'articolo su HTTP/2 limitazioni.

Controlli di integrità

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

Per i probe del controllo di integrità, devi creare un firewall di autorizzazione in entrata che consente ai probe del controllo di integrità di raggiungere il tuo backend di Compute Engine. In genere, i probe del controllo di integrità provengono dal sistema meccanismo di controllo di integrità.

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

Protocollo di controllo di integrità

Sebbene non sia obbligatorio e non sempre possibile, è buona norma utilizza un controllo di integrità il cui protocollo corrisponde a quello del protocollo del backend Google Cloud. Ad esempio, un controllo di integrità HTTP/2 verifica in modo più accurato la connettività HTTP/2 per di backend. Al contrario, i bilanciatori del carico delle applicazioni esterni regionali che utilizzano backend NEG ibridi non supporta i controlli di integrità gRPC. Per l'elenco dei controllo di integrità supportati protocolli, consulta Bilanciamento del carico funzionalità.

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

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

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

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

Regole firewall

Il bilanciatore del carico richiede le seguenti regole firewall:

• Per i bilanciatori del carico delle applicazioni esterni globali, un bilanciatore del carico in entrata regola per consentire il traffico proveniente da Google Front End (GFE) per raggiungere i tuoi backend.
  Per il bilanciatore del carico delle applicazioni esterno regionale, una regola di autorizzazione in entrata per consentire il traffico dalla subnet solo proxy per 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 di controllo di integrità e sul motivo per cui è necessario per consentire il traffico proveniente da questi domini. Consulta l'articolo Esaminare gli intervalli IP e il firewall .

Le regole firewall vengono implementate a livello di istanza VM, non su Proxy GFE. Non puoi utilizzare le regole firewall di Google Cloud per impedire per impedire che il traffico raggiunga il bilanciatore del carico. Per il bilanciatore del carico delle applicazioni esterno globale e la versione classica del bilanciatore del carico delle applicazioni, puoi utilizzare Google Cloud Armor per raggiungere questo obiettivo.

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

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

• Per i backend di gruppi di istanze: determina le porte che devono essere configurate mappatura tra il servizio di backend denominato Port e i numeri di porta associati a quella porta denominata su ciascun gruppo di istanze. La i numeri di porta possono variare tra i gruppi di istanze assegnati allo stesso backend completamente gestito di Google Cloud.

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

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

Modalità bilanciatore del carico	Intervalli di fonti dei controlli di integrità	Intervalli di origine delle richieste
Bilanciatore del carico delle applicazioni esterno globale	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64	L'origine del traffico GFE dipende dal tipo di backend: Gruppi di istanze e NEG a livello di zona (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Per il traffico IPv6 verso i backend: 2600:2d00:1:1::/64 NEG di connettività ibrida (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 NEG internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): . 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG e bucket di backend: di Google la rete di produzione gestisce il routing dei pacchetti
Bilanciatore del carico delle applicazioni classico	35.191.0.0/16 130.211.0.0/22	L'origine del traffico GFE dipende dal tipo di backend: gruppi di istanze, NEG a livello di zona (GCE_VM_IP_PORT) e NEG di connettività ibrida (NON_GCP_PRIVATE_IP_PORT): . 35.191.0.0/16 130.211.0.0/22 NEG internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): . 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEG e bucket di backend: di Google e la rete di produzione gestisce il routing dei pacchetti.
Bilanciatore del carico delle applicazioni esterno regionale	35.191.0.0/16 130.211.0.0/22 Non è necessario aggiungere gli intervalli di probe del controllo di integrità di Google a una lista consentita per gli ambienti ibridi NEG. Tuttavia, se utilizzi una combinazione di NEG ibridi e a livello di zona un unico servizio di backend, devi aggiungere la classe Google intervalli di probe del controllo di integrità a una lista consentita per i NEG a livello di zona.	Lo una subnet solo proxy configurata da te.

Importante: assicurati di consentire i pacchetti del controllo di integrità completo intervalli di tempo. 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 per comunicare con i tuoi backend. Questo causa risposte HTTP 502.

Architettura VPC condiviso

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

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

Bilanciatore del carico	Componenti del frontend	Componenti di backend
Bilanciatore del carico delle applicazioni esterno globale	Se utilizzi un VPC condiviso condivisa per i tuoi backend, crea la rete richiesta nel Progetto host VPC condiviso. l'indirizzo IP esterno globale, la regola di forwarding, la destinazione HTTP(S) e la mappa URL associata devono essere definiti nello stesso progetto. Questo progetto può essere un progetto host o un progetto di servizio.	Puoi procedere in uno dei seguenti modi: Creare servizi e backend di backend (istanza gruppi, NEG serverless o qualsiasi altro tipo di backend supportato) nel stesso progetto di servizio come componenti frontend. Crea i servizi e i backend (istanza gruppi, NEG serverless o qualsiasi altro tipo di backend supportato) in dei progetti di servizio. Una singola mappa URL può fare riferimento a servizi di backend tra progetti diversi. Questo tipo di è noto come servizio tra progetti riferimento ed è attualmente in Anteprima. Ogni servizio di backend deve essere definito nello stesso progetto come backend a cui fa riferimento. Salute anche i controlli associati ai servizi di backend devono essere definiti progetto come servizio di backend. I backend possono essere parte di un Rete VPC condiviso dal progetto host o da una rete rete VPC, ovvero una rete VPC non condivisa progetto di servizio.
Bilanciatore del carico delle applicazioni classico	L'indirizzo IP esterno globale, la regola di forwarding, l'HTTP(S) di destinazione proxy e la mappa URL associata deve essere definita nel lo stesso host o lo stesso progetto di servizio dei backend.	Un servizio di backend globale deve essere definito nello stesso host o nello stesso servizio progetto come backend (gruppi di istanze o NEG). Controlli di integrità associati ai servizi di backend deve essere definito anche nello stesso progetto del servizio di backend.
Bilanciatore del carico delle applicazioni esterno regionale	Crea la rete e solo proxy richiesti nel progetto host del VPC condiviso. La regione indirizzo IP esterno, la regola di forwarding, il proxy HTTP(S) di destinazione la mappa URL associata deve essere definita nello stesso progetto. Questo progetto può essere il progetto host o un progetto di servizio.	Puoi procedere in uno dei seguenti modi: Creare servizi e backend di backend (istanza gruppi, NEG serverless o qualsiasi altro tipo di backend supportato) nel stesso progetto di servizio come componenti frontend. Crea i servizi e i backend (istanza gruppi, NEG serverless o qualsiasi altro tipo di backend supportato) nel maggior numero possibile a progetti di servizio come richiesto. Una singola mappa URL può fare riferimento a servizi di backend tra progetti diversi. Questo tipo di è noto come servizio tra progetti fare riferimento. Ogni servizio di backend deve essere definito nello stesso progetto come backend a cui fa riferimento. Salute i controlli associati ai servizi di backend devono essere definiti nello stesso anche come servizio di backend.

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

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

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

I componenti e i backend del bilanciatore del carico devono utilizzare lo stesso VPC in ogni rete.

Bilanciatore del carico delle applicazioni esterno regionale sulla VPC condiviso condivisa

Backend serverless in un ambiente VPC condiviso

Per un bilanciatore del carico che utilizza un backend NEG serverless, il backend Il servizio Cloud Run o Cloud Functions deve essere nel lo stesso progetto del NEG serverless.

Inoltre, per il bilanciatore del carico delle applicazioni esterno regionale che supporta applicazioni riferimento al servizio, il servizio di backend, il NEG serverless Il servizio Cloud Run deve essere sempre nello stesso progetto di servizio.

Riferimento ai servizi tra progetti

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

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

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

I proprietari dei servizi possono mantenere l'autonomia sull'esposizione dei loro servizi e controlla quali utenti possono accedere ai servizi usando il bilanciatore del carico. Questo è da un ruolo IAM speciale chiamato Ruolo Utente servizi bilanciatore del carico Compute (roles/compute.loadBalancerServiceUser).

Per scoprire come configurare un VPC condiviso Bilanciatore del carico delle applicazioni esterno regionale, con o senza servizio tra progetti fare riferimento a Configurare un bilanciatore del carico delle applicazioni esterno regionale VPC condiviso.

Limitazioni note con i riferimenti ai servizi tra progetti

• I riferimenti ai servizi tra progetti possono essere utilizzati con gruppi di istanze, NEG serverless e la maggior parte degli altri tipi di backend supportati. Tuttavia, si applicano le seguenti limitazioni:

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

    • Bucket di backend
    • NEG serverless con App Engine
  • Con i bilanciatori del carico delle applicazioni esterni regionali, non puoi fare riferimento a un servizio di backend se il servizio di backend dispone di un NEG internet a livello di regione di backend.
• I riferimenti ai servizi tra progetti non sono supportati per il il bilanciatore del carico delle applicazioni classico.
• Google Cloud non fa distinzione tra le risorse (ad esempio, di backend) utilizzando lo stesso nome in più progetti. Pertanto, quando utilizzi i riferimenti ai servizi multiprogetto, ti consigliamo utilizza nomi univoci per servizio di backend nei vari progetti dell'organizzazione.

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

Ecco un esempio di deployment in cui frontend e URL del bilanciatore del carico vengono create nel progetto di servizio A e la mappa degli URL fa riferimento a un 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. Progetto di servizio B gli amministratori concedono il ruolo IAM compute.loadBalancerServiceUser agli amministratori del bilanciatore del carico nel progetto di servizio A che vogliono fare riferimento al backend nel progetto di servizio B.

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

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

In questo tipo di deployment, il frontend e la mappa URL del bilanciatore del carico vengono creati nel progetto host e i servizi di backend (e i backend) vengono create 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. Progetto di servizio concedono il ruolo IAM compute.loadBalancerServiceUser a agli amministratori del bilanciatore del carico nel progetto host A che vogliono fare riferimento al backend nel progetto di servizio.

Frontend del bilanciatore del carico e mappa URL nel progetto host

Come funzionano le connessioni

Connessioni del bilanciatore del carico delle applicazioni esterno globale

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

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

Nota: per i NEG internet, le richieste dal bilanciatore del carico provengono da indirizzi IP diversi in base al tipo di NEG (globale o regionale). Per ulteriori informazioni, consulta Autenticazione richieste.

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

Il keepalive HTTP è abilitato per impostazione predefinita, come specificato in HTTP 1.1 la specifica del container. Le keepalive HTTP tentano di utilizzare in modo efficiente la stessa sessione TCP. ma non ne viene fornita nessuna garanzia. Il GFE utilizza un timeout keepalive HTTP del client 610 secondi e un valore di timeout keepalive del backend predefinito di 600 secondi. Tu può aggiornare il timeout keepalive HTTP del client ma il timeout keepalive del backend è fisso. Puoi configurare il timeout della richiesta/risposta impostando il parametro dal timeout del servizio di backend. Sebbene strettamente correlato, un keepalive HTTP e un TCP il timeout per inattività non sono la stessa cosa. Per ulteriori informazioni, vedi timeout e nuovi.

Per garantire che il bilanciamento del carico sia uniforme, il bilanciatore del carico potrebbe chiudi una connessione TCP inviando un pacchetto FIN ACK dopo aver completato un risposta che includeva un'intestazione Connection: close o potrebbe generare un errore HTTP/2 GOAWAY frame dopo aver completato una risposta. Questo comportamento non interferisce con richieste o risposte attive.

Il numero di connessioni HTTP e sessioni TCP varia in base al numero di connessioni HTTP e sessioni TCP. i GFE che si connettono, il numero di client che si connettono ai GFE, il protocollo i backend e dove viene eseguito il deployment.

Per saperne di più, consulta Come i bilanciatori del carico delle applicazioni esterni lavoro Nella guida alle soluzioni: ottimizzazioni della capacità delle applicazioni con il carico globale Bilanciamento.

Connessioni del bilanciatore del carico delle applicazioni esterno regionale

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

I client utilizzano l'indirizzo IP e la porta del bilanciatore del carico per connettersi al carico con il bilanciatore del carico di rete passthrough esterno regionale. Le richieste del client vengono indirizzate alla subnet solo proxy nello stesso regione come client. Il bilanciatore del carico termina le richieste dei client apre nuove connessioni dalla subnet solo proxy ai tuoi backend. Pertanto, e pacchetti inviati dal bilanciatore del carico hanno indirizzi IP di origine una subnet.

A seconda della configurazione del servizio di backend, il protocollo utilizzato da Envoy i proxy per la connessione ai backend possono essere HTTP, HTTPS o HTTP/2. Se HTTP o HTTPS, la versione HTTP è HTTP 1.1. Il keepalive HTTP è abilitato per impostazione predefinita, specificato nella specifica HTTP 1.1. Il proxy Envoy imposta il client Timeout keepalive HTTP e timeout keepalive del backend su un valore predefinito 600 secondi ciascuna. Puoi aggiornare il timeout keepalive HTTP del client, ma il valore di timeout keepalive del backend è fisso. Puoi configurare la richiesta/risposta il timeout impostando il timeout del servizio di backend. Per ulteriori informazioni, vedi timeout e nuovi tentativi.

Comunicazioni client con il bilanciatore del carico

• I client possono comunicare con il bilanciatore del carico utilizzando HTTP 1.1 HTTP/2.
• Quando si utilizza HTTPS, i client moderni utilizzano per impostazione predefinita HTTP/2. L'attivazione è controllata su sul client, non sul bilanciatore del carico HTTPS.
• Non puoi disattivare HTTP/2 apportando una modifica alla configurazione al caricamento con il bilanciatore del carico di rete passthrough esterno regionale. Tuttavia, è possibile configurare alcuni client in modo che utilizzino HTTP 1.1 anziché HTTP/2. Ad esempio, con curl, utilizza il parametro --http1.1.
• I bilanciatori del carico delle applicazioni esterni supportano la risposta HTTP/1.1 100 Continue.

Per l'elenco completo dei protocolli supportati dal bilanciatore del carico delle applicazioni esterno per le regole di forwarding in ciascuna modalità, consulta Bilanciatore del carico funzionalità.

Indirizzi IP di origine per i pacchetti client

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

Per i bilanciatori del carico delle applicazioni esterni globali:

.

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

  • Indirizzo IP di origine: il client originale (o l'indirizzo IP esterno se è protetto da NAT o un proxy di inoltro).
  • Indirizzo IP di destinazione: l'indirizzo IP del bilanciatore del carico.

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

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

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

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

Per i bilanciatori del carico delle applicazioni esterni regionali:

.

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

  • Indirizzo IP di origine: il client originale (o l'indirizzo IP esterno se è protetto da 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 backend oppure endpoint:

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

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

Percorsi di routing speciali

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

• Per i controlli di integrità, tranne integrità di Envoy distribuita controlli. Per maggiori informazioni, vedi Percorsi per l'integrità controlli.

• Tra GFE e backend di bilanciatori del carico delle applicazioni esterni globali e Application Load Balancer classici. Per ulteriori informazioni, vedi Percorsi tra Google Front Termina e di backend.

Google Cloud utilizza route di subnet per solo proxy subnet di routing dei pacchetti per i seguenti tipi di traffico:

• Quando utilizzi controlli di integrità di Envoy distribuiti.

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

Porte aperte

I GFE hanno diverse porte aperte per supportare altri servizi Google in esecuzione la stessa architettura. Quando esegui una scansione delle porte, potresti vedere altre porte aperte per ad altri servizi Google in esecuzione sui GFE.

Entrambi i bilanciatori del carico basati su GFE: bilanciatori del carico delle applicazioni esterni globali Application Load Balancer classici: mostra sempre le porte 80 e 443 come aperte (insieme qualsiasi altra porta configurata nelle regole di forwarding del bilanciatore del carico). Tuttavia, se non hai configurato una regola di forwarding per la porta 80 o per la porta 443, le connessioni inviate a quelle porte vengono rifiutate. Al contrario, I bilanciatori del carico delle applicazioni esterni regionali vengono implementati utilizzando proxy Envoy e non vengono visualizzati porte extra aperte durante una scansione.

Non è utile eseguire una scansione delle porte sull'indirizzo IP di un bilanciatore del carico basato su GFE dal punto di vista della revisione per i seguenti motivi:

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

  I GFE implementano funzionalità di sicurezza come Google Cloud Armor. Con Standard Google Cloud Armor, GFE forniscono protezione sempre attiva dagli attacchi DDoS volumetrici e basati su protocollo e inondazioni SYN. Questa protezione è disponibile anche se non hai esplicitamente configurato con Google Cloud Armor. Ti verranno addebitati dei costi solo se configuri criteri di sicurezza o se ti registri a Managed Protection Plus.

• I pacchetti inviati all'indirizzo IP del bilanciatore del carico possono ricevere risposta da qualsiasi GFE nel parco risorse Google ma l'analisi dell'indirizzo IP di un bilanciatore del carico combinazione di porte di destinazione interroga solo un singolo GFE connessione TCP. L'indirizzo IP del bilanciatore del carico non è assegnato a un un singolo dispositivo o sistema. Analizzando quindi l'indirizzo IP di un carico basato su GFE non esegue la scansione di tutti i GFE nel parco risorse Google.

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

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

terminazione TLS

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

Modalità bilanciatore del carico	terminazione TLS
Bilanciatore del carico delle applicazioni esterno globale	Il protocollo TLS viene terminato su un GFE, che può trovarsi ovunque nel mondo.
Bilanciatore del carico delle applicazioni classico	Il protocollo TLS viene terminato su un GFE, che potrebbe trovarsi ovunque nel mondo.
Bilanciatore del carico delle applicazioni esterno regionale	Il protocollo TLS viene interrotto sui proxy Envoy che si trovano in una rete una subnet in una regione scelta dall'utente. Utilizza questa modalità del bilanciatore del carico se hai bisogno di controllo geografico sulle in cui viene terminato il TLS.

Timeout e nuovi tentativi

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

Tipo di timeout e descrizione	Valori predefiniti	Supporta valori personalizzati
		Global	Classica	A livello di regione
Timeout del servizio di backend^1 Un timeout per richiesta e risposta. Rappresenta la quantità di tempo massima che possono trascorrere da quando il bilanciatore del carico invia il primo byte Richiesta HTTP al tuo backend per indicare il momento in cui quest'ultimo restituisce l'ultimo byte. della risposta HTTP. Se l'intera risposta HTTP non è stata restituita al bilanciatore del carico entro il timeout della richiesta o della risposta, i restanti i dati delle risposte vengono eliminati.	Per i NEG serverless su un servizio di backend: 60 minuti Per tutti gli altri tipi di backend su un servizio di backend: 30 secondi Per i bucket di backend: 24 ore (86.400 secondi)
Timeout keepalive HTTP del client La quantità di tempo massima che la connessione TCP tra un client e il proxy del bilanciatore del carico può essere inattivo. La stessa connessione TCP può essere utilizzata per più richieste HTTP). Per i bilanciatori del carico delle applicazioni esterni globali e gli Application Load Balancer classici, il carico il proxy del bilanciatore è un GFE di primo livello. Per i bilanciatori del carico delle applicazioni esterni regionali, il proxy del bilanciatore del carico è Envoy software.	Per un bilanciatore del carico delle applicazioni esterno globale e Bilanciatore del carico delle applicazioni classico: 610 secondi Per un bilanciatore del carico delle applicazioni esterno regionale: 600 secondi
Timeout keepalive HTTP di backend La quantità di tempo massima che la connessione TCP tra il carico il proxy del bilanciatore e un backend possono essere inattivi. La stessa connessione TCP per più richieste HTTP). Per i bilanciatori del carico delle applicazioni esterni globali e gli Application Load Balancer classici, il carico il proxy del bilanciatore è un GFE di secondo livello. Per i bilanciatori del carico delle applicazioni esterni regionali, il proxy del bilanciatore del carico è Envoy software.	Per i servizi di backend: 10 minuti (600 secondi) Per i bucket di backend: 6 minuti (360 secondi)
Timeout di inattività della sessione QUIC Il periodo di tempo massimo durante il quale una sessione QUIC può rimanere inattiva tra (downstream) e il GFE di un bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico.	Per i bilanciatori del carico delle applicazioni esterni globali e gli Application Load Balancer classici: Il timeout di inattività della sessione QUIC è il minimo tra il client inattivo o il timeout di inattività del GFE (300 secondi). Il timeout di inattività di GFE è fisso su 300 secondi. Il timeout di inattività del client che è possibile configurare.

¹ Non configurabile per i backend NEG serverless. No e configurabili per i bucket di backend.

Timeout del servizio di backend

Il timeout del servizio di backend configurabile rappresenta la quantità massima di Tempo di attesa del bilanciatore del carico prima che il backend elabori una richiesta HTTP restituiscono la risposta HTTP corrispondente. Fatta eccezione per i NEG serverless, il valore predefinito il valore di timeout del servizio di backend è 30 secondi.

Ad esempio, se vuoi scaricare un file da 500 MB e il valore del backend il timeout del servizio è di 90 secondi, il bilanciatore del carico si aspetta che il backend l'intero file da 500 MB in 90 secondi. È possibile configurare il timeout del servizio di backend non è sufficiente per consentire al backend di inviare il messaggio completo Risposta HTTP. In questo caso, se il bilanciatore del carico ha ricevuto almeno come intestazioni della risposta HTTP dal backend, il bilanciatore del carico restituisce delle intestazioni della risposta e tutto il corpo della risposta che potrebbe ottenere all'interno dal timeout del servizio di backend.

Devi impostare il timeout del servizio di backend sul periodo di tempo massimo in cui che ti serviranno per elaborare una risposta HTTP. Dovresti aumenta il timeout del servizio di backend se il software in esecuzione sul tuo backend richiede più tempo per elaborare una richiesta HTTP e restituire l'intera risposta. Ad esempio, devi aumentare il timeout se vengono visualizzate risposte 408 HTTP con jsonPayload.statusDetail client_timed_out.

Il timeout del servizio di backend accetta valori compresi tra 1 e 2,147,483,647 secondi; tuttavia, valori più alti non sono opzioni di configurazione pratiche. Google Cloud non garantisce che una connessione TCP sottostante possa e rimarranno aperte per tutta la durata del timeout del servizio di backend. Cliente devono implementare una logica di ripetizione invece di fare affidamento su una connessione TCP essere aperti per lunghi periodi di tempo.

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

• Console Google Cloud: modifica il campo Timeout del parametro di servizio di backend.
• Google Cloud CLI: utilizzare il comando gcloud compute backend-services update per modificare il parametro --timeout del servizio di backend risorsa.
• API: per un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico, modifica il parametro timeoutSec per globale backendServices risorsa.
• API: per un bilanciatore del carico delle applicazioni esterno regionale, modifica il parametro timeoutSec per il regionBackendServices risorsa.

I timeout della connessione Websocket non sono sempre uguali a quelli del servizio di backend. I timeout della connessione Websocket dipendono dal tipo di bilanciatore del carico:

Modalità bilanciatore del carico	Valori predefiniti	Descrizione del timeout per WebSocket
Bilanciatore del carico delle applicazioni esterno globale	Timeout del servizio di backend: 30 secondi	Le connessioni WebSocket attive non utilizzano il servizio di backend configurato il timeout del bilanciatore del carico. Le connessioni vengono chiuse automaticamente dopo 24 ore (86.400 secondi). Questo limite di 24 ore è fisso e, se presente, sostituisce il timeout del servizio di backend per più di 24 ore. Le connessioni websocket inattive vengono chiuse dopo il timeout del servizio di backend. Sconsigliamo di utilizzare valori di timeout del servizio di backend maggiori di 24 ore (86.400 secondi) perché Google Cloud riavvia periodicamente i GFE per aggiornamenti software e altre attività di manutenzione ordinaria. Il tuo servizio di backend di timeout non ritarda le attività di manutenzione. Più a lungo valore di timeout del servizio di backend, più è probabile che Google Cloud termina le connessioni TCP per la manutenzione.
Bilanciatore del carico delle applicazioni classico	Timeout del servizio di backend: 30 secondi	Le connessioni WebSocket, inattive o attive, si chiudono automaticamente dopo il timeout del servizio di backend. Sconsigliamo di utilizzare valori di timeout del servizio di backend maggiori di 24 ore (86.400 secondi) perché Google Cloud riavvia periodicamente i GFE per aggiornamenti software e altre attività di manutenzione ordinaria. Il tuo servizio di backend di timeout non ritarda le attività di manutenzione. Più a lungo valore di timeout del servizio di backend, più è probabile che Google Cloud termina le connessioni TCP per la manutenzione.
Bilanciatore del carico delle applicazioni esterno regionale	Timeout del servizio di backend: 30 secondi	Le connessioni WebSocket attive non utilizzano il timeout del servizio di backend di tramite il bilanciatore del carico. Le connessioni websocket inattive vengono chiuse dopo il timeout del servizio di backend. Google Cloud riavvia periodicamente o modifica il numero di server Attività software di Envoy. Più lungo è il valore di timeout del servizio di backend, è più probabile che le attività Envoy riavviino o terminino le connessioni TCP.

I bilanciatori del carico delle applicazioni esterni regionali utilizzano routeActions.timeout dell'URL mappa e ignora il timeout del servizio di backend. Quando routeActions.timeout non è configurato. Il valore del backend è il timeout del servizio. Se viene specificato routeActions.timeout, il timeout del servizio di backend viene ignorato e il valore routeActions.timeout viene utilizzato come timeout per richiesta e risposta .

Timeout keepalive HTTP del client

Il timeout keepalive HTTP del client rappresenta la quantità di tempo massima che una connessione TCP possa essere inattiva tra il client (downstream) e uno dei i seguenti tipi di proxy:

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

Un timeout keepalive HTTP rappresenta il timeout di inattività TCP per l'oggetto e connessioni TCP. Il timeout keepalive HTTP del client non si applica a websockets.

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

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

• Console Google Cloud: modifica il campo Timeout keepalive HTTP di configurazione frontend del bilanciatore del carico.
• Google Cloud CLI: utilizza Comando gcloud compute target-http-proxies update o il comando gcloud compute target-https-proxies update per modificare il parametro --http-keep-alive-timeout-sec del proxy HTTP di destinazione o della risorsa proxy HTTPS di destinazione.
• API: modifica il parametro httpKeepAliveTimeoutSec per targetHttpProxies risorsa o la targetHttpsProxies risorsa.

Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del valore Timeout keepalive HTTP (TCP inattivo) utilizzato da client o proxy downstream. Se un client downstream ha un timeout keepalive HTTP (TCP inattivo) maggiore di il timeout keepalive HTTP del client del bilanciatore del carico, è possibile che venga che si verifichi. Dal punto di vista di un cliente downstream, un'azienda La connessione TCP può rimanere inattiva per un periodo superiore a quanto consentito dal caricamento con il bilanciatore del carico di rete passthrough esterno regionale. Ciò significa che il client downstream può inviare pacchetti dopo il caricamento considera che la connessione TCP è chiusa. In questo caso, il carico il bilanciatore del carico risponde con un pacchetto di reimpostazione TCP (RST).

Timeout keepalive HTTP di backend

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

• Per un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico, una prima TCP esiste una connessione tra il client (downstream) e un GFE di primo livello. I GFE del primo strato si connettono ai GFE del secondo strato e poi ai GFE del secondo strato e una seconda connessione TCP con i tuoi backend.

• Per un bilanciatore del carico delle applicazioni esterno regionale, esiste una prima connessione TCP tra (downstream) e un proxy Envoy. Il proxy Envoy apre quindi un secondo e la connessione TCP ai backend.

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

Il timeout keepalive del backend è fissato a 10 minuti (600 secondi) e non può essere modificata. Il backend del bilanciatore del carico Il timeout keepalive deve essere inferiore al timeout keepalive utilizzato dal software in esecuzione sui tuoi backend. Ciò evita una race condition in cui dei tuoi backend potrebbe chiudere le connessioni TCP con una reimpostazione TCP (RST). Poiché il timeout keepalive del backend per il bilanciatore del carico non è configurabile, devi configurare il software di backend in modo che il suo keepalive HTTP (TCP inattivo) di timeout è superiore a 600 secondi.

Nella tabella seguente sono elencate le modifiche necessarie per modificare il timeout keepalive per i comuni software dei server web.

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

Timeout di inattività della sessione QUIC

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

Il valore di timeout di inattività della sessione QUIC è definito come il minimo tra il timeout di inattività del client o il timeout di inattività del GFE (300 secondi). Il timeout di inattività di GFE è fisso su 300 secondi. Il timeout di inattività del client può essere configurato.

Nuovi tentativi

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

Modalità bilanciatore del carico	Logica di ripetizione
Bilanciatore del carico delle applicazioni esterno globale	Configurabile mediante un criteri relativi ai nuovi tentativi nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1. Il numero massimo di nuovi tentativi che possono essere configurati usando il criterio per i nuovi tentativi è 25. Il timeout predefinito per ogni tentativo (perTryTimeout) è di 30 secondi con una durata massima perTryTimeout configurabile di 24 ore. Senza un criterio di ripetizione, le richieste non andate a buon fine che non hanno Corpo HTTP (ad esempio, richieste GET) che generano HTTP Risposte 502, 503 o 504 (retryConditions=["gateway-error"]) sono stati riprovati una volta. Le richieste HTTP POST non vengono tentate di nuovo. Le richieste ricalcolate generano solo una voce di log per l'ultima risposta.
Bilanciatore del carico delle applicazioni classico	Impossibile modificare il criterio per i nuovi tentativi di connessione. Le richieste HTTP POST non vengono tentate di nuovo. Le richieste HTTP GET vengono sempre ritentate una volta per un periodo di tempo poiché l'80% o più dei backend è in stato integro. Se è presente un solo dell'istanza di backend di un gruppo e la connessione al backend di un'istanza di backend, la percentuale di istanze di backend in stato non integro è 100%, quindi il GFE non proverà di nuovo a eseguire la richiesta. Il bilanciatore del carico ritenta una richiesta GET non riuscita se la prima richiesta non è riuscito prima di ricevere le intestazioni delle risposte dall'istanza di backend. Le richieste ricalcolate generano solo una voce di log per l'ultima risposta. Per ulteriori informazioni, vedi Bilanciatore del carico delle applicazioni esterno logging e monitoraggio. Se le richieste non riuscite, il bilanciatore del carico sintetizza un Risposta HTTP 502.
Bilanciatore del carico delle applicazioni esterno regionale	Configurabile mediante un riprova nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries) è 1. Il numero massimo di nuovi tentativi possibili tramite il criterio per i nuovi tentativi è 25. Il timeout predefinito per ogni tentativo (perTryTimeout) è di 30 secondi con una durata massima perTryTimeout configurabile di 24 ore. Senza un criterio di ripetizione, le richieste non andate a buon fine che non hanno Corpo HTTP (ad esempio, richieste GET) che generano HTTP Risposte 502, 503 o 504 nuovi tentativi una volta. Le richieste HTTP POST non vengono tentate di nuovo. Le richieste ricalcolate generano solo una voce di log per l'ultima risposta.

Il protocollo WebSocket è supportato con GKE In entrata.

Gestione illegale di richieste e risposte

Il bilanciatore del carico blocca sia le richieste client sia le risposte del backend che raggiungono rispettivamente il backend o il client per vari motivi. Alcune sono strettamente legate alla conformità HTTP/1.1 e altre devono evitare che vengono trasmessi ai o dai backend. Nessuno dei controlli può essere disabilitato.

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

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

Gestione delle richieste

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

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

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

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

Gestione della risposta

Il bilanciatore del carico blocca la risposta del backend se: vero:

• La dimensione totale delle intestazioni della risposta supera il limite massimo di risposte per i bilanciatori del carico delle applicazioni esterni.
• La versione HTTP è sconosciuta.

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

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

Distribuzione del traffico

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

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

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

La modalità di distribuzione del traffico tra i backend dipende dalla modalità del carico con il bilanciatore del carico di rete passthrough esterno regionale.

Bilanciatore del carico delle applicazioni esterno globale

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

Il significato di capacità dipende in parte dalla modalità di bilanciamento. Per RATE è relativamente semplice: un GFE determina esattamente quante richieste può assegnate al secondo. Il bilanciamento del carico basato su UTILIZATION è più complesso: il carico e il bilanciatore del carico di emergenza controlla l'utilizzo attuale e poi stima una query che ogni istanza è in grado di gestire. Questa stima cambia nel tempo come istanza l'utilizzo e i modelli di traffico cambiano.

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

Per il bilanciatore del carico delle applicazioni esterno globale, il bilanciamento del carico è a due livelli. La valutazione determina la ponderazione o la frazione di traffico che deve essere inviata (gruppo di istanze o NEG). Il criterio di bilanciamento del carico (LocalityLbPolicy) determina come il traffico viene distribuito alle istanze più endpoint all'interno del gruppo. Per ulteriori informazioni, consulta la sezione Bilanciamento del carico criteri relativi alle località (API del servizio di backend documentazione).

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

Modalità di distribuzione delle richieste

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

1. Dal client al GFE di primo livello. I router perimetrali pubblicizzano l'indirizzo IP esterno della regola di forwarding ai confini della rete Google. Ogni annuncio elenca un hop successivo in un sistema di bilanciamento del carico di livello 3/4 (Maglev). I sistemi Maglev instradano il traffico a un Google Front End (GFE) di primo livello. (GFE).
   • Quando utilizzi il livello Premium, Google pubblicizza il tuo carico l'indirizzo IP del bilanciatore da tutti i punti di presenza, a livello mondiale. A ogni caricamento l'indirizzo IP del bilanciatore è un anycast globale.
   • Quando utilizzi il livello Standard, Google pubblicizza il tuo carico l'indirizzo IP del bilanciatore dai punti di presenza associati della regola di forwarding. Il bilanciatore del carico utilizza un IP esterno a livello di regione . L'uso di una regola di forwarding del livello Standard limita l'istanza backend NEG a livello di gruppo e di zona nella stessa regione del bilanciatore del carico di una regola di forwarding.
2. Dal GFE di primo livello a quello di secondo livello. GFE di primo livello termina TLS se necessario e quindi instrada il traffico ai GFE di secondo livello in base alla seguente procedura:
   • I GFE di primo livello analizzano la mappa URL e selezionano un servizio di backend oppure di backend.
   • Per i servizi di backend con NEG internet, i GFE di primo livello selezionano un gateway di forwarding esterno di secondo livello posizionato con il primo livello GFE. Il gateway di forwarding invia richieste all'endpoint NEG internet. Questo conclude il processo di distribuzione delle richieste per i NEG internet.
   • Per i servizi di backend con serverless NEG, Private Service Connect (PSC) NEG e bucket di backend, i GFE di primo livello selezionano un GFE di secondo livello nella regione corrispondente a quella del NEG o del bucket. Per più regioni nei bucket Cloud Storage, i GFE di primo livello selezionano i GFE di secondo livello regione il più vicina possibile ai GFE di primo livello (definiti dalla di andata e ritorno).
   • Per i servizi di backend con gruppi di istanze, NEG di zona con GCE_VM_IP_PORT endpoint e NEG ibridi, Il sistema di gestione della capacità di Google informa i GFE di primo livello circa e la capacità configurata per ogni backend. La capacità configurata per un di backend è definito modalità di bilanciamento, la capacità target della modalità di bilanciamento scaler di capacità.
     • Livello Standard: i GFE di primo livello selezionano un GFE di secondo livello nella regione contenente i backend.
     • Livello Premium: i GFE di primo livello selezionano i GFE di secondo livello da un insieme delle regioni applicabili. Le regioni applicabili sono tutte le regioni in cui i backend configurate, escluse le regioni in cui sono configurati backend con capacità pari a zero. I GFE di primo livello selezionano il secondo livello più vicino GFE in una regione applicabile (definita dalla tempo di round trip della rete). Se sono configurati in due o più regioni, i GFE di primo livello possono inoltrare le richieste ad altre regioni applicabili se una regione di prima scelta è pieno. Lo spillover in altre regioni è possibile quando tutti i backend la regione di prima scelta ha raggiunto il limite.
3. I GFE di secondo livello selezionano i backend. I GFE di secondo livello si trovano zone di una regione. Per selezionare un backend, utilizza il seguente processo:
   • Per i servizi di backend con NEG serverless, Private Service Connect I NEG, i bucket di backend e i GFE di secondo livello inoltrano le richieste sistemi di produzione IA. Con questo si conclude il processo di distribuzione della richiesta da questi backend.

   • Per i servizi di backend con gruppi di istanze, i NEG a livello di zona con GCE_VM_IP_PORT endpoint e NEG ibridi, integrità di Google il controllo dei sistemi di probe informa i GFE di secondo livello sullo stato del controllo di integrità delle istanze o degli endpoint di backend.

     Solo livello Premium: se il GFE di secondo livello non ha uno stato integro di backend o endpoint nella propria regione, potrebbe inviare richieste un altro GFE di secondo livello in una regione applicabile diversa con di backend. Lo sversamento tra i GFE di secondo livello in regioni diverse non escludono tutte le possibili combinazioni regione-regione. Per distoglie il traffico dai backend in una determinata regione, di backend in modo che non superino i controlli di integrità, imposta il dello scaler della capacità del backend a zero, quindi il GFE del primo livello esclude regione durante il passaggio precedente.

   Il GFE di secondo livello indirizza quindi le richieste alle istanze di backend degli endpoint in zone all'interno della loro regione, come discusso nel prossimo passaggio.

4. Il secondo livello GFE seleziona una zona. Per impostazione predefinita, i GFE di secondo livello usa l'algoritmo WATERFALL_BY_REGION, in cui ogni secondo strato Il GFE preferisce selezionare istanze di backend o endpoint nella stessa zona come zona che contiene il GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo il traffico tra le zone, senza percentuali di richieste, ogni GFE di secondo livello può inviare richieste in modo esclusivo nella stessa zona del GFE di secondo livello.

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

   • SPRAY_TO_REGION: i GFE di secondo livello non preferiscono selezionando le istanze di backend o gli endpoint nella stessa zona un GFE di secondo livello. I GFE di secondo livello tentano di distribuire traffico a tutte le istanze di backend o a tutti gli endpoint in tutte le zone della regione. Questo può portare a una distribuzione più uniforme del carico, a scapito dell'aumento il traffico tra le zone.
   • WATERFALL_BY_ZONE: i GFE di secondo livello preferiscono fortemente selezionando le istanze di backend o gli endpoint nella stessa zona un GFE di secondo livello. I GFE di secondo livello indirizzano le richieste solo ai backend in zone diverse dopo che tutti i backend nella zona attuale hanno raggiunto le loro capacità configurate.
5. Il secondo livello GFE seleziona le istanze o gli endpoint all'interno della zona. Di per impostazione predefinita, un GFE di secondo livello distribuisce le richieste tra i backend in in modo rotondo. Solo per i bilanciatori del carico delle applicazioni esterni globali, puoi modificare questa impostazione mediante un bilanciamento del carico criterio di località (localityLbPolicy). Il bilanciamento del carico il criterio relativo alla località si applica solo ai backend all'interno della zona selezionata di cui abbiamo parlato nel passaggio precedente.

Bilanciatore del carico delle applicazioni esterno regionale

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

La modalità di bilanciamento determina la ponderazione e la frazione di traffico che devono essere inviati a ciascun gruppo (gruppo di istanze o NEG). Criterio per le località di bilanciamento del carico (LocalityLbPolicy) determina il bilanciamento del carico dei backend all'interno del gruppo.

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

Per ulteriori informazioni, consulta le seguenti risorse:

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

Affinità sessione

Affinità sessione tenta il criterio del "best effort" per inviare le richieste da un determinato client alla purché sia integro e abbia la capacità, in base alla modalità di bilanciamento configurata.

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

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

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

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

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

Supporto HTTP/2

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

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

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

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

Stream simultanei HTTP/2 massimi

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

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

Limitazioni HTTP/2

• HTTP/2 tra il bilanciatore del carico e l'istanza può richiedere significativamente più connessioni TCP all'istanza rispetto a HTTP(S). Il pool di connessioni, dell'ottimizzazione che riduce il numero di queste connessioni con HTTP(S), attualmente non disponibile con HTTP/2. Di conseguenza, potresti vedere un'alta perché le connessioni al backend vengono effettuate con maggiore frequenza.
• HTTP/2 tra il bilanciatore del carico e il backend non supporta l'esecuzione il 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 server push.
• La percentuale di errori gRPC e il volume di richieste non sono visibili nella l'API Google Cloud o la console Google Cloud. Se l'endpoint gRPC restituisce un errore, i log del bilanciatore del carico e i dati di monitoraggio Codice di risposta HTTP OK 200.

Supporto HTTP/3

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

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

In particolare:

• QUIC di IETF è un protocollo del livello di trasporto che fornisce il controllo della congestione e simile a TCP, utilizza TLS 1.3 per la sicurezza e ha migliorato delle prestazioni.
• HTTP/3 è un livello dell'applicazione basato su QUIC di IETF e si basa su QUIC per gestire multiplexing, controllo della congestione, rilevamento delle perdite e ritrasmissione.
• HTTP/3 consente un avvio più rapido della connessione client, elimina l'head-of-line in multiplexing e supporta la migrazione delle connessioni quando le modifiche all'indirizzo IP del client.
• HTTP/3 è supportato per le connessioni tra i client e il bilanciatore del carico. e non connessioni tra il bilanciatore del carico e i backend.
• Le connessioni HTTP/3 utilizzano il BBR o un algoritmo di controllo delle congestioni.

HTTP/3 sul bilanciatore del carico consente di migliorare i tempi di caricamento della pagina web e di ridurre il rebuffering e migliorare la velocità effettiva nelle connessioni a latenza più elevata.

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

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

Come viene negoziato HTTP/3

Quando HTTP/3 è abilitato, il bilanciatore del carico 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 ricorrono sempre a HTTPS o HTTP/2 quando non è in grado di stabilire una connessione HTTP/3.
• I client che supportano HTTP/3 utilizzano le proprie conoscenze memorizzate nella cache di HTTP/3 in modo da evitare attacchi di andata e ritorno non necessari in futuro.
• A causa di questo fallback, l'abilitazione o la disabilitazione di HTTP/3 nel bilanciatore del carico il bilanciatore del carico non compromette la capacità di connettersi ai client.

L'assistenza è pubblicizzata nel Alt-Svc Intestazione della risposta HTTP. Quando HTTP/3 è abilitato, le risposte del bilanciatore del carico includi il seguente valore di intestazione alt-svc:

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

Nota: l'intestazione Alt-Svc annuncia più versioni di HTTP/3 al fine di Supportare le bozze precedenti utilizzate da alcuni client (ad es. h3-29).

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

Quando HTTP/3 è abilitato sul bilanciatore del carico HTTPS, in alcuni casi possono il client dovrà ricorrere 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 il protocollo Versioni HTTP/3 supportate dal bilanciatore del carico HTTPS.
• Quando il bilanciatore del carico rileva che il traffico UDP è bloccato o ha una frequenza limitata in modo tale da impedire il funzionamento di HTTP/3.
• Il client non supporta HTTP/3 e quindi non tenta di una connessione HTTP/3.

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

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

Configura HTTP/3

Sia NONE (predefinito) sia ENABLE abilitano il supporto HTTP/3 per il tuo carico con il bilanciatore del carico di rete passthrough esterno regionale.

Quando HTTP/3 è abilitato, il bilanciatore del carico lo annuncia ai client, il che consente i client che la supportano per negoziare una versione HTTP/3 con il bilanciatore del carico. I client che non supportano HTTP/3 non negoziano una connessione HTTP/3. Tu sì non è necessario disattivare esplicitamente HTTP/3, a meno che tu non abbia identificato il client guasto implementazioni.

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

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

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

Console: HTTPS

Nota: l'impostazione della negoziazione HTTP/3 non è attualmente supportata sulla destinazione pagina proxy e devono essere configurati modificando il bilanciatore del carico configurazione.

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

Vai a Bilanciamento del carico

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

Abilita HTTP/3

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

Disabilita HTTP/3

1. Seleziona il menu a discesa Negoziazione QUIC.
2. Per disabilitare esplicitamente HTTP/3 per questo frontend, seleziona Disabilitato.
3. Se hai più regole frontend che rappresentano IPv4 e IPv6, crea 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 uno dei seguenti:

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

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

API: HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

Sostituisci QUIC_SETTING con uno dei seguenti:

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

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

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

Limitazioni

• I bilanciatori del carico HTTPS non inviano una chiusura close_notify avviso all'arresto Connessioni SSL. Ciò significa che il bilanciatore del carico chiude la connessione TCP anziché eseguire un arresto SSL.
• I bilanciatori del carico HTTPS supportano solo i caratteri minuscoli nei domini in un attributo nome comune (CN) o attributo nome alternativo del soggetto (SAN) del certificato. I certificati con caratteri maiuscoli nei domini sono restituito solo se impostato come principale certificato nel proxy di destinazione.
• I bilanciatori del carico HTTPS non utilizzano l'estensione Server Name Indication (SNI) durante la connessione al backend, ad eccezione dei bilanciatori del carico con NEG internet di backend. Per maggiori dettagli, consulta Crittografia dal bilanciatore del carico di backend.
• Quando utilizzi bilanciatori del carico delle applicazioni esterni regionali con Cloud Run in in un ambiente VPC condiviso, reti VPC autonome i progetti di servizio possono inviare traffico Servizi Cloud Run di cui è stato eseguito il deployment in qualsiasi altro servizio a progetti nello stesso ambiente VPC condiviso. Si tratta di un modello problema e questa forma di accesso verrà bloccata in futuro.
• Google Cloud non garantisce che una connessione TCP sottostante possa e rimarranno aperte per tutta la durata del timeout del servizio di backend. I sistemi client devono implementare una logica per i nuovi tentativi invece di affidarsi a un TCP la connessione rimanga aperta per lunghi periodi di tempo.
• Non puoi creare un bilanciatore del carico delle applicazioni esterno regionale nel livello Premium utilizzando nella console Google Cloud. Inoltre, solo le regioni supporto del livello Standard sono disponibili per questi bilanciatori del carico nella console Google Cloud. Utilizza le funzionalità di tramite gcloud CLI o l'API. Utilizza il gcloud CLI o l'API.
• Cloud CDN consente di forzare l'utilizzo di un oggetto o di un insieme di oggetti ignorata dalla cache richiedendo una cache convalida. Se utilizzi un Bilanciatore del carico delle applicazioni esterno globale con servizio VPC condiviso tra progetti che fa riferimento: per impostazione predefinita, gli amministratori dei progetti di servizio non avranno autorizzazioni necessarie per richiedere l'annullamento della convalida della cache. Questo perché la cache l'annullamento della convalida sia configurato nel progetto frontend (ovvero il progetto che include regola di forwarding, proxy di destinazione e mappa URL del carico ). Di conseguenza, le invalidazioni della cache possono essere eseguite solo dalle entità che dispongono dei ruoli IAM per configurare le risorse relative al bilanciatore del carico progetti frontend (ad esempio il ruolo Amministratore rete Compute). Servizio che controllano il provisioning dei servizi di backend in un deve collaborare con l'amministratore del bilanciatore del carico del frontend per emettere l'annullamento della convalida della cache per i servizi tra progetti.

Passaggi successivi

• Per scoprire come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno globale, vedi Configurare un bilanciatore un bilanciatore del carico delle applicazioni esterno con Compute Engine di backend.
• Per scoprire come eseguire il deployment di un bilanciatore del carico delle applicazioni esterno regionale, vedi Configurare Bilanciatore del carico delle applicazioni esterno regionale con Compute Engine di backend.
• Se sei un utente esistente del bilanciatore del carico delle applicazioni classico, assicurati di consulta Pianifica la tua migrazione al bilanciatore del carico delle applicazioni esterno globale quando pianifichi un nuovo deployment con il bilanciatore del carico delle applicazioni esterno globale.
• Per scoprire come automatizzare la configurazione del bilanciatore del carico delle applicazioni esterno con Terraform, consulta Esempi di moduli Terraform per bilanciatori del carico delle applicazioni esterni.
• Per scoprire come configurare le funzionalità avanzate di gestione del traffico disponibili con il bilanciatore del carico delle applicazioni esterno globale, consulta Panoramica della gestione del traffico per Bilanciatori del carico delle applicazioni esterni globali.
  • Per scoprire come configurare funzionalità avanzate di gestione del traffico disponibile con il bilanciatore del carico delle applicazioni esterno regionale, consulta Gestione del traffico panoramica per Application Load Balancer esterni regionali.
    • Per trovare le località per i PoP di Google, consulta GFE. di località.
• Per saperne di più sulla gestione della capacità, vedi Gestione della capacità con il carico bilanciamento tutorial e Ottimizzazioni della capacità delle applicazioni con carico globale e il bilanciamento del carico.
  • Per scoprire di più sulla pubblicazione di siti web, consulta Pubblicazione siti web.
• Per scoprire come utilizzare Gestore certificati per eseguire il provisioning per gestire i certificati SSL, consulta la sezione Gestore certificati Panoramica.
• Per inserire la logica personalizzata nel percorso dei dati di bilanciamento del carico, configura Estensioni del servizio callout.